Das primäre Ziel von UDDI ist die spezifikation von einem Framwork für die Beschreibung und Auffindung von Web Services.
Der kern von UDDI dreht sich um eine Idee der sog. business regestry. Ein registry an sich ist ein ausgereifter naming und directory Service. Speziel definiert UDDI Datastrukturen und APIs zum veröffentlichen (publishing) von Service-beschreibungen in der registry und zum Abfragen der registry(Suceh nach Diensten).
UDDI API sind selbst durch WSDL mit SOAP - bindigs beschreiben, so kann man auf ein business registry wie auf einen Web Service zugreifen (Seine Charakteristiken könne in der gleicher Regisrtry beschrieben werden).
UDDI, als es entstand, wurde als ein UBR1) gesehen. Das Ziel ist die Unterstützung eines weltweiten Verzeichnises, wo jeder seine angebotene Services veröffentlichen und auffinden könnte. So könnte ein UBR jeden Service, der jemals auf der Welt deployt worden ist, enthalten.
Mit der Zeit entwickelte sich die Spezifikation auch für unterstützung von privaten registry Implementirungen, welche mit public registrys kommunizieren sollen.

• White Pages - Kontaktinformation (telehpno, email, …), angebotene Dienste. UDDI-client kann die angebotene Web Services fienden.
• Yellow Pages - Klassifizirung von Unternehmen und Diensten anhand der Taxonimien (standartisiert oder Benutzerdefiniert). Die Suche nach Web Services kann Anhand der Klassifikation realisiert werden. (Klassifizurungsschema)
• Green Pages - Beschriebugn wie ein gegebenr Web Service aufgerufen werden kann. Es ist mit Hilfen fon Verweisen auf die servicebeschrebende Dokumente, welche typisch ausserhalb der Registry gelagert werden (z.B. auf der Websete des Serviceproviders)

• businessEntity - Es beschriebt eine Organisation welche Web services bereitstellt.
  Kann mehrere bussiness Services enthalten
• businessService - Gruppe der in Beziehung stehender Web Services die von der businessEntity angeboten werden. Üblicherweise wird es ein Dienst sein (wie z.B. Beschaffung, Reservierungssystem, usw.), nur mit Verschieden Adressen, mehreren Versionen und Technologien (z.B Protoklole) bereitgestellt.
  Kann mehrere bindingTemplates enthalten.
• bindingTemplate - Dieser Element enthält die technische Informationen welche nötig sind um bestimmten Web Service zu nutzen. Hauptsächlich definiert es die Adresse an welcher der Web Service zu finden ist, zusammen mit einer Reihe von Detailierten Informationen und tModels.
• tModel - = Technical Model ist ein generischer Kontainer für aller art Spezifikationen. Es kann z.B. einen WSDL Interface, eine Klassifikation, ein Kommunikationsprotokol sein, oder es könnte die Semantik eiene Operation beschreiben.
  Im unterschied zu anderen Entities stehen tModels inkeine Parent-child Bezihung und könne von businessEntity, businessService und bindingTemplate referenziert werden.

Beispiel einer tModel:

<tModel tModelKey="uddi:uddi.org:v3_publication">
    <name>uddi-org:publication_v3</name>
    <description>UDDI Publication API Version 3.0</description> 
    <overviewDoc> 
        <overviewURL useType="wsdlInterface">
            http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Publication_SoapBinding 
        </overviewURL>
    </overviewDoc>
    <overviewDoc> 
        <overviewURL useType="text">
            http://uddi.org/pubs/uddi_v3.htm#PubV3
        </overviewURL > 
    </overviewDoc> 
    <categoryBag> 
        <keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlSpec" tModelKey="uddi:uddi.org:categorization:types"/>
        <keyedReference keyName="uddi-org:types:soap" keyValue="soapSpec" tModelKey="uddi:uddi.org:categorization:types"/>
        <keyedReference keyName="uddi-org:types:xml" keyValue="xmlSpec" tModelKey="uddi:uddi.org:categorization:types"/>
        <keyedReference keyName="uddi-org:types:specification" keyValue="specification" tModelKey="uddi:uddi.org:categorization:types"/>
    </categoryBag> 
</tModel>

tModel kann nicht nur für protokole und Interface benutzt werden. als Beispiel werden sie in UDDI für Klassifikation und Identifikation benutzt. Jeder kann eine Klassifikationschema als tModel definieren (z.B gerographische ienteilung der Welt in Europa, Austalia, Asien, NSAmerika, Agfrika) Volle Beschriebung der Klassifizierung kann in der overviewDoc verbleiben auf die tModel referenziert. So können Einträge in der Registry auf dieses tModel referenzieren mit ienem der Definirtem Wert (z.B. “Europa”). UDDI ermöglicht sozusagen die benutzerdefinierten Taxonomien. Ausserdem diefiniert UDDI Kategorisationsscheme (spezielles tModel), welches zur klassifizirung anderer tModelle benutzt werden kann. Dises predefiniertes Schema heist uddi-org:types. Es erlaubt dem entwickler zu bestimment ob seintModel eine WSDL Dokument oder SOAP Message bestimmen, die Client können dan nach WSDL oder SOAP suchen.

• UDDI Inquiry API - Diese Schnittstelle enthält Eintrittspunkte, wie find_business, find_service, find_binding und find_tModel, für die Beantwortung von Suchkriterien sowie Operationen für die Ermittlung von Details, wie get_businessDetail, get_serviceDetail, get_bindingDetail und get_tModelDetail.
• UDDI Publishers API - Diese Schnittstelle geht in Richtung der Service-Anbieter und ermöglicht das Hinzufügen, Modifizieren und Entfernen von Elementen der UDDI-Registry mit beispielsweise den Funktionen save_business, save_binding, save_tModel, delete-business, delete_service, delete-binding und delete-tModel.
• UDDI Security API - Hierbei können Authentifizierungsangaben formuliert werden mittels get_authToken und discard_authToken.
• UDDI Custody and Ownership Transfer API - Diese Verbindungsform dient der Beaufsichtigung (Custody) und ermöglicht, Service-Informationen in diesem Sinne zwischen den Publishers auszutauschen (mittels get_transferToken, transfer_entities und transfer_custody.
• UDDI Subscription API - Hierbei wird die weitere Eintragung von Web Service Anbietern unterstützt mit beispielsweise den Operationen delete_subscription, get_subscriptionResults, get_subscriptions und save-subscription.
• UDDI Replication API - Diese Form unterstützt die Replikation von Informationen und deren Abgleichung zwischen verschiedenen Registries.

Für den Nutzer von Web Service ist die Inquiry API die wohl wichtigste. Es geht hierbei um eine simple Abfrageform der Web-Service-Informationen, die gegenwärtig auch einen effizienten Umgang mit der UDDI ermöglicht. Unabhängig davon werden natürlich flexiblere Ansätze untersucht, wie zum Beispiel die UDDI Search Markup Language (USML) oder die Unterstützung von Peer-to-Peer-Techniken.

Die UDDI und die WSDL ergänzen sich in zweckmäßiger Weise. So findet der Anwender folgende Verbindungsmöglichkeiten von der WSDL zum UDDI:

1. Die find_tModel-Nachricht erzeugt eine Liste von tModel-Keys, die zur wsdlSpec und z.B. “book pricing”(Benutzer definierte Klassifizierung) kompatibel sind
2. Die Anwendung des get_tModelDetail liefert spezielle Informationen zur Service-Schnittstelle.
3. Die Prüfung der overviewDoc eines empfangenen tModels ermöglicht den Zugriff zu speziellen WSDL-Schnittstelleninformationen.

• Using WSDL in UDDI Registry

• public - hierbei ist ein uneingeschränkter Zugriff zu den Web-Service-Informationen erlaubt.
• private - hier gelten Einschränkungen, die zum Beispiel durch ein Intranet bzw. die Anwendung von Firewalls implizieren.
• shared bzw. semi-private - hierbei ist die Web-Service-Anwendung innerhalb bestimmter Partner erlaubt bzw. eingegrenzt.

Ein Beispiel der Zusammnearbeit: Store Procedure als “Service implementation”

• Web Service
• WSDL
• SOAP

• OASIS UDDI v3.0.1