UDDI

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

  • businessEntity

  • businessService

  • bindingTemplate

  • tModel

The UDDI API, based on the functionality, is divided into three main types:

  • Inquiry API This API is used to primarily find things and get their details.

  • Publishers API This API is primarily used to save and delete references to Web Services and to handle security issues.

  • The Inquiry API This API has patterns to provide a querying mechanism, which are as follows:

    • The browse pattern Hierarchical data lookup mainly requires this kind of browsing. This kind of browsing follows a style of finding information initially on broad terms and then narrowing the results by performing the drill-down pattern search.

    • The drill-down pattern Once you get the main key to your information using the first pattern, you can find details about that information using the drill-down pattern.

    • The invocation pattern Because UDDI is like a registry service, it can be updated. When a search is performed for a service, the results are cached so the next request does not require a search. However, if the UDDI files have been updated, any service accessed with such cached data will result in an error. The invocation pattern is used to retrieve the new names, and if the new name differs from the value cached, this value is updated.

Limitations of UDDI

The limitations of UDDI are

  • The main drawback of UDDI is the absence of object-oriented APIs to access and use UDDI. Because UDDI is described using XML, Java addresses this with the Java API for XML Registries (JAXR), which is a consistent API for accessing different XML-based registeries, including UDDI.

  • It has no support for the semantic description of services.

  • It does not yet specify any content language for advertisements.



Sams Teach Yourself BEA WebLogic Server 7. 0 in 21 Days
Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days
ISBN: 0672324334
EAN: 2147483647
Year: 2002
Pages: 339

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net