by Thomas Erl 		 First Generation Standards
divider
 UDDI In and Out
 of the Enterprise
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. 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.
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
 

return to homepage


SOA: Principles
of Service Design
by Thomas Erl

An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation).


Service-Oriented Architecture:
Concepts, Technology, and Design
by Thomas Erl

The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design.
Service-Oriented Architecture:
A Field Guide
to Integrating
XML and Web Services
by Thomas Erl

The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices.

For more information about either book, visit: www.soabooks.com

About SOA Systems

SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program.

For more information see:

•  www.soasystems.com

•  www.soatraining.com



   
   
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.
<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>
Note: 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.
<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>
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.
   <discoveryURLs>
     <discoveryURL useType=
       "businessEntity">http://test.uddi.microsoft.com/discovery
       ?businesskey=e9355d51-32ca-49cf-8eb4-1ce59afbf4a7
   </discoveryURL>
   </discoveryURLs>
The name element simply contains the official 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.
   <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.
     <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.
       <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.
       <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.
       <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:
<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.

   
   
Home   Copyright © 2003-2007 SOA Systems Inc.