- Web services and the service-oriented architecture (SOA)
- Web Services Description Language (WSDL)
- Simple Object Access Protocol (SOAP)
- Universal Description, Discovery, and Integration (UDDI)
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 Universal Description, Discovery, and Integration (UDDI)
One of the fundamental components of a service-oriented architecture is a mechanism for Web service descriptions to be discovered by potential requestors. To establish this part of a Web services framework, a central directory to host service descriptions is required. Such a directory can become an integral part of an organization or an Internet community, so much so, it is considered an extension to infrastructure.
This is why the Universal Description, Discovery, and Integration specification has become increasingly important. A key part of UDDI is the standardization of profile records stored within such a directory, also known as a registry. Depending on who the registry is intended for, different implementations can be created.
A public business registry is a global directory of international business service descriptions. Instances of this registry are hosted by large corporations (also referred to as node operators) on a series of dedicated UDDI servers. UDDI records are replicated automatically between repository instances. Some companies also act as UDDI registrars, allowing others to add and edit their Web service description profiles. The public business registry is complemented by a number of service marketplaces offering generic Web services for sale or lease.
Private registries are service description repositories hosted within an organization (see Figure 3.28). Those authorized to access this directory may include select external business partners. A registry restricted to internal users only can be referred to as an internal registry.
)
Figure 3.28 Service descriptions centralized in a private UDDI registry
The discovery process can occur in various situations depending on why service information is required. For instance:
-
An organization seeking to establish new business relationships for online transactions can search for (and compare) suitable business partners using a public business registry.
-
When building an inter-enterprise integration channel, the architect working for an organization's business partner will need to learn about the organization's external contact points. Service interfaces and the logic they express will form the basis for the Web services designed by the business partner. Access to the organization's private registry allows the architect to efficiently gather this information.
-
An architect designing a new e-Business application may first want to research the availability of generic programming logic within an organization. By reading through existing service descriptions, opportunities for reuse may be discovered. Centralizing service descriptions in an internal registry provides a convenient resource repository for public endpoint descriptions within an enterprise.
-
That same architect may also want to shop for a third-party Web service providing pre-built application logic that could be incorporated (locally or remotely) within the e-Business application. Service marketplaces offer venues to purchase or lease third-party Web services.
-
A developer building new services will need to access interface definitions for existing services. The internal registry spares the developer from having to worry about whether the service interfaces being incorporated are current.
UDDI registries organize registry entries using six primary types of data:
-
business entities
-
business services
-
specification pointers
-
service types
-
business relationships
-
subscriptions
Business entity data, as represented by the businessEntity element, provides profile information about the registered business, including its name, a description, and a unique identifier.
Here is a sample XML document containing a businessEntity construct.
Example 3.13. An actual business entity document retrieved from a public service registry
<businessEntity xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
businessKey="e9355d51-32ca-49cf-8eb4-1ce59afbf4a7"
operator="Microsoft Corporation"
authorizedName="Thomas Erl"
xmlns="urn:uddi-org:api_v2">
<discoveryURLs>
<discoveryURL useType=
"businessEntity">http://test.uddi.microsoft.com/discovery
?businesskey=e9355d51-32ca-49cf-8eb4-1ce59afbf4a7
</discoveryURL>
</discoveryURLs>
<name xml:lang="en">
XMLTC Consulting Inc
</name>
<description xml:lang="en">
XMLTC has been building end-to-end enterprise
eBusiness solutions for corporations and
government agencies since 1996. We offer a
wide range of design, development and
integration services
</description>
<businessServices>
<businessService
serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a"
businessKey="e9355d51-32ca-49cf-8eb4-1ce59afbf4a7">
<name xml:lang="en-us">
Corporate Home Page
</name>
<bindingTemplates>
<bindingTemplate
bindingKey="48b02d40-0312-4293-a7f5-4449ca190984"
serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a">
<description xml:lang="en">
Entry point into the XMLTC Web site
through which a number of resource
sites can be accessed
</description>
<accessPoint URLType="http">
http://www.xmltc.com/
</accessPoint>
<tModelInstanceDetails />
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="Namespace" keyValue="namespace" />
</categoryBag>
</businessService>
</businessServices>
</businessEntity>
This document can be retrieved manually or programmatically using the URL http://test.uddi.microsoft.com/discovery?businesskey=e9355d51-32ca-49cf-8eb4-1ce59afbf4a7
Let's take this document apart to study the individual constructs.
Example 3.14. The parent businessEntity element with a number of attributes
<businessEntity xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" businessKey="e9355d51-32ca-49cf-8eb4-1ce59afbf4a7" operator="Microsoft Corporation" authorizedName="Thomas Erl" xmlns="urn:uddi-org:api_v2">
When I registered XMLTC Consulting Inc. it was given a unique identifier of e9355d51-32ca-49cf-8eb4-1ce59afbf4a7, which was then assigned to the businessKey attribute of the businessEntity parent element. Since Microsoft acted as the node operator providing an instance of the UDDI registry, its name is displayed in the businessEntity element's operator attribute.
The discoveryURL element identifies the address used to locate this XML document.
Example 3.15. The discoveryURLs construct containing the original URL
<discoveryURLs>
<discoveryURL useType="businessEntity">
http://test.uddi.microsoft.com/discovery
?businesskey=e9355d51-32ca-49cf8eb4-1ce59afbf4a7
</discoveryURL>
</discoveryURLs>
The name element simply contains the official business name.
Example 3.16. The name element providing the business name
<name xml:lang="en"> XMLTC Consulting Inc </name>
Business service records representing the actual services offered by the registered business are nested within the businessEntity construct.
Example 3.17. The businessServices construct
<businessServices>
<businessService
serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a"
businessKey="e9355d51-32ca-49cf-8eb4-1ce59afbf4a7">
<name xml:lang="en-us">
Corporate Home Page
</name>
<bindingTemplates>
<bindingTemplate
bindingKey="48b02d40-0312-4293-a7f5-4449ca190984"
serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a">
<description xml:lang="en">
Entry point into the XMLTC Web site
through which a number of resource
sites can be accessed
</description>
<accessPoint URLType="http">
http://www.xmltc.com/
</accessPoint>
<tModelInstanceDetails />
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="Namespace" keyValue="namespace" />
</categoryBag>
</businessService>
</businessServices>
A business service is identified with a unique value assigned to the serviceKey attribute. Its parent businessEntity element is referenced by the businessKey attribute.
Example 3.18. The businessService element's serviceKey and businessKey attributes
<businessService serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a" businessKey="e9355d51-32ca-49cf-8eb4-1ce59afbf4a7"> ... </businessService>
The only business service associated with this business entity is the business's Web site home page, as identified by the name element.
Example 3.19. The name element with the service name
<name xml:lang="en-us"> Corporate Home Page </name>
Each business service provides specification pointers. Also known as binding templates, these records consist of addresses linking the business service to implementation information. Using service pointers, a developer can learn how and where to physically bind to a Web service.
Example 3.20. The bindingTemplates construct housing concrete location information
<bindingTemplates>
<bindingTemplate
bindingKey="48b02d40-0312-4293-a7f5-4449ca190984"
serviceKey="1eeecfa1-6f99-460e-a392-8328d38b763a">
<description xml:lang="en">
Entry point into the XMLTC Web site
through which a number of resource
sites can be accessed.
</description>
<accessPoint URLType="http">
http://www.xmltc.com/
</accessPoint>
<tModelInstanceDetails />
</bindingTemplate>
</bindingTemplates>
The bindingTemplate construct displayed in the preceding example establishes the location and description of the service using the accessPoint and description elements.
Various categories can be assigned to business services. In our example, the URL we identified has been classified as a namespace using the keyedReference child element of the categoryBag construct.
Example 3.21. The categoryBag element providing a categorization using the nested keyedReference element
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="Namespace" keyValue="namespace" />
</categoryBag>
There is no formal relationship between UDDI and WSDL. A UDDI registry provides a means of pointing to service interface definitions through the use of a tModel. Though it would most likely be a WSDL document, it does not have to be. The tModel represents the definition of the UDDI service type, and also can provide information relating to message formats, as well as message and security protocols.
Finally, business relationship and subscription data is represented by publisherAssertion and subscription elements, respectively. publisherAssertion constructs provide a means of establishing the relationship of the current businessEntity with another. Subscription allows subscribers to be notified when business entity profile information is updated.
You can interface programmatically with a UDDI registry. The UDDI specification provides a number of APIs that can be grouped into two general categories: inquiry and publishing. For instance, you could issue a SOAP message to search for a company by name with the following payload:
Example 3.22. The find_business construct encasing a command for the UDDI inquiry API
<find_business xmlns="urn:uddi-org:api_v3">
<findQualifiers>
<findQualifier>
uddi:uddi.org:findQualifier:exactMatch
</findQualifier>
</findQualifiers>
<name>
XMLTC Consulting Inc
</name>
</find_business>
Although this brief overview has discussed the fundamentals of UDDI (with a focus on the structure of business entities), it has not delved into the heart of a UDDI registry: the tModel. This important construct provides access to the technical details required for requestors to interface and interact with available Web services.
SUMMARY OF KEY POINTS
-
UDDI directories can be implemented as public business registries, private registries, and internal registries.
-
Registry entries consist of the following profile information: business entities, business services, specification pointers, service types, business relationships, and subscriptions.
-
UDDI provides inquiry and publishing APIs, allowing applications to interface programmatically with a registry.
To learn more about the tModel and UDDI in general, visit www.specifications.ws.