You now know how to create the messages (using SOAP) and how to format the messages and provide information about the services (using WSDL). The next step is to find a place or a service where you can look up the service that is required in the system architecture. To perform this task, Universal Description, Discovery and Integration (UDDI) is used. If any business processes are to be offered as Web Services, they are listed in a registrylike structure. UDDI is often compared to the Yellow Pages directory. Once the Web Service is systematically documented in the UDDI service, developers can search for organizations providing specific business services over this service. UDDI not only acts as an online directory, it also provides a description of the services or methods offered by each of these Web Services. Hence, UDDI also separates implementation and interface definition. Considering the interface definition part, any UDDI-registered Web Service must be associated with a tModel service type. This tModel is an interface with definitions of the methods offered by the service. A tModel is an interface with some set of design goals and specifications commonly used across all registering services. Because all the registering Web Services must be associated with a tModel, clients can switch between Web Services with great ease and no change in the existing application. Also, UDDI uses a SOAP-based XML messaging system along with a simple HTTP protocol to pass messages to Operator sites. Any Web Service registering on UDDI has to add a wsdlspec, which is a method informing users that this service is a WSDL-based service, because there are other kinds of services, too. Accessing UDDI programmatically is achieved through the UDDI programmer's API. There are four main types of data managed by UDDI. They are
The UDDI API, based on the functionality, is divided into three main types:
Limitations of UDDIThe limitations of UDDI are
|