The UDDI web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only.


Keith Pijanowski writes: In my previous SOA post I covered the UDDI Information model in a fair amount of detail. While describing the UDDI Information Model I stated that the UDDI specification standardizes two aspects of SOA Metadata. These two aspects are the Information model and the way that the information model is accessed and manipulated. In this post I want to cover this second aspect of UDDI which deals with accessing the UDDI Information Model.

It should be no surprise that the UDDI specification describes all UDDI data access in terms of web services. The UDDI specification uses the term “API Set” to refer to these web services. An API Set is essentially a single web service containing related operations. UDDI specifies 9 API Sets to be used for all forms of data access and data manipulation. The list of UDDI API Sets is shown in Figure 1. The WSDL documents for these services are also shown in Figure 1. These files can be found on the OASIS site.

Having a common API for accessing the information in a SOA Registry is important when an organization is looking to implement design time governance, run time governance, management of a SOA in the data center, and discovery in the software development lifecycle. By having a common API for accessing registry information you can purchase the tools that are right for you and be assured that they will work correctly with your SOA Registry.

Read the complete article by Keith Pijanowski. Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I