Web Services Architecture and Its Specifications [Electronic resources] : Essentials for Understanding WS-* نسخه متنی

UDDI

UDDI is a specification for interacting with a Web services registry. This registry can be the public implementation hosted on the Internet or any private registry hosted on the Internet, an extranet, or internally to an organization. While the UDDI nomenclature is developed around the notion of businesses, services, and behaviors (tModels), it can be applied more generally as a registry of any Web service. UDDI also makes heavy use of metadata associated with each registry entry.

In our example scenario, the protocol for interacting with the Order service described earlier in the WSDL section in Chapter 11, "Metadata Example," is registered as a behavior (tModel). Once this behavior is registered, the order management service, as an implementation of this behavior, can be added to the registry as well. Information about the order management service can then be retrieved through a series of search and retrieval operations.

In our example scenario, Microsoft Press hosts an extranet UDDI registry to help partners and customers locate the appropriate Web services to support their applications.

UDDI tModels

UDDI tModels are used to register specific behaviors. For our example scenario, a single tModel is registered for the order management service. A tModel entry consists of descriptive information, a unique identifier, metadata, and administrative details.

UDDI tModels
(01)  <tModel
(02)      tModelKey="uuid:984765-2222-3333-4444-123456129874"
(03)      operator="mspress.microsoft.com"
(04)      authorizedName="admin@mspress.microsoft.com">
(05)   <name>MSPress Purchase Order</name>
(06)   <description xml:lang="en">PO service behavior</description>
(07)   <overviewDoc>http://ex.mspress.microsoft.com/po/po.wsdl</overviewDoc>
(08)   <identifierBag>...</identifierBag>
(09)   <categoryBag>...</categoryBag>
(10) </tModel>

Line 02 Each tModel is assigned a universally unique identifier, UUID, when it is registered. This UUID serves as a key for retrieving more information about the entry.

Line 03 The operator attribute is used primarily when UDDI registries are federated to indicate which instance originally stored the entry.

Line 04 The authorizedName attribute specifies which UDDI registry account is used to create and maintain the entry.

Lines 0506 A human-readable name is provided for convenience, along with descriptions of the tModel in multiple languages.

Line 07 The overviewDoc element can be used to reference documentation or other resources for the behavior. In our example, it directly references the WSDL description for the Purchase Order Web service.

Lines 0809 Additional metadata can be associated with each entry to help with searching and discovery. The identifierBag element can contain a list of unique identifiers that are associated with the entry, and the categoryBag element can be used to specify a list of taxonomy values.

Once the tModel is registered in UDDI, implementations of that tModel follow. In UDDI nomenclature, the organization hosting the Web service is registered as a BusinessEntity, with multiple BusinessService(s). A bindingTemplate associates a BusinessService with its implementation. Examples of this nested structure are shown below.

UDDI Business Entities
(01)   <businessEntity
(02)       businessKey="uuid:11111111-2222-3333-4444-555555554444"
(03)       operator="mspress.microsoft.com"
(04)       authorizedName="admin@mspress.microsoft.com">
(05)    <discoveryURLs>
(06)     <discoveryURL useType="businessEntity">
ws.mspress.microsoft.com?be=11111111-2222-3333-4444-555555554444
(07)     <discoveryURL>
(08)    </discoveryURLs>
(09)    <name>Order Management Service</name>
(10)    <description xml:lang="en">
Services related to customer service and order management.
(11)    </description>
(12)    <contacts>
(13)      <contact useType="Sales">
(14)       <personName>Chris Kurt</personName>
(15)       <email>mailto:christopher_kurt@hotmail.com</email>
(16)      </contact>
(17)    </contacts>
(18)    <businessServices>...</businessServices>
(19)    <identifierBag>...</identifierBag>
(20)    <categoryBag>...</categoryBag>
(21)   </businessEntity>

Lines 0204 Similar to the structure of the tModel, a UDDI BusinessEntity contains attributes for a unique identifier, the hosting operator, and the registering account used for the entry.

Lines 0508 Each UDDI BusinessEntry is directly accessible through a URL, allowing an application to retrieve the resource directly from the registry. The direct access path(s) are included in the entry. The value of this element is typically assigned by the UDDI registry service itself and is not part of the registration messages used to create the entry.

Lines 0911 Human-readable names and descriptions can be provided with the entry. The name element is required.

Lines 1217 Optional contact information can be included in the registry entry. This can be used by an administrator to reach the person or team responsible for some aspect of the Web service or application it supports.

Line 18 The set of business services provided as a part of this entry are contained in the businessServices element. More information on business services is provided below.

Lines 19-20 Similarly to the tModels, each BusinessEntity can be adorned with various sorts of identifier and categorization metadata.

Each business entity may contain zero or more business services. A business service is used to group related endpoints together and can provide more detailed metadata about the service through finer-grained categorization.

UDDI Business Services
(01)   <businessEntity ...>
(02)       ...
(03)    <businessServices>
(04)     <businessService>
(05)         businessKey="uuid:11111111-2222-3333-4444-555555554444"
(06)         serviceKey="uuid:90807060-2222-3333-4444-555555554444">
(07)      <name>Purchase Orders</name>
(08)      <description>Service for purchase order processing.</description>
(09)      <bindingTemplates>
(10)          ...
(11)      </bindingTemplates>
(12)      <categoryBag>...</categoryBag>
(13)    </businessService>
(14)   </businessServices>
(15)  </businessEntity>

Lines 0413 Each business service has a unique identifier and the identifier for the business entity it is associated with. This allows updates of just a single business service without retransmitting the entire entry each time a change is made.

Lines 0708 Each business service has its own name and description elements.

Lines 0911 Zero or more binding templates can be included in a business service to associate the business service with specific endpoints.

Line 12 Categorizations specific to this business service can be registered, building on the metadata contained in the business entity.

Drilling down one level further, each business service can contain zero or more bindingTemplate elements. These binding templates are used to associate the service with a specific endpoint or to redirect to binding template registered as a part of a different business service.

UDDI Binding Templates
(01)  <businessService ...>
(02)   <bindingTemplates>
(03)    <bindingTemplate
(04)        serviceKey="uuid:90807060-2222-3333-4444-555555554444"
(05)        bindingKey="uuid:33333333-2323-aefa-1234-555555554444">
(06)    <accessPoint URLType="http">
(07)        http://ex.mspress.microsoft.com/orders
(08)    <accessPoint>
(09)    <tModelInstanceDetails>
(10)        uuid:984765-2222-3333-4444-123456129874
(11)    </tModelInstanceDetails>
(12)   </bindingTemplate>
(13)  </bindingTemplates>
(14) </businessService>