Discovering Web Services

A UDDI registry contains information about businesses and the services they offer. UDDI also contains references to industry-specific specifications a service may support, such as taxonomies and identification systems. Consumers of services can search a registry for businesses, services, or service types, either programmatically or using a Web-based interface. A UDDI business registry uses standard industry taxonomies or classification schemes, such as D-U-N-S, SIC codes, and others, to categorize businesses and the services they offer. All APIs within the UDDI specification use XML, are wrapped in a SOAP envelope, and use HTTP as the transport.

What Is a Registry?

A registry is analogous to a phone book, in that it provides the ability for service consumers to easily locate their desired business entities and the services they provide. A registry provides "white pages" that allow a consumer to look up an address, contact information, and known identifiers. This is similar to looking up either the phone number or address of a business when you know the business's name.

A registry also provides "yellow pages," which include classification information based on standard taxonomies. For example, the phone directory provides yellow pages that can be used to find an all-night pizza shop on Christmas Eve in Baltimore near the Inner Harbor. The typical implementation of yellow pages could be thought of as name-value pairs. The yellow pages metaphor allows any valid taxonomy identifier to be attached to the business white pages. The yellow pages take into account a geographical taxonomy.

Finally, a registry also provides "green pages," which describe services the business offers. Imagine looking in the phone book for the Internal Revenue Service or another government entity, trying to discover what services it offers. The "green pages" indicate the services offered and references it to a specified business process.

A registry contains four types of information:

• Business entity. Every business entity holds a unique identifier, the business name, simple contact information, a brief description of the business, a listing of categories that describes and classifies the business, and a URL that points to additional information about the business.

• Business service. Every business service entity includes a business description of the service, a listing of categories that describe and classify the service, and a URL to information about the service.

• Specification pointers. Each business service entity includes a list of binding templates that point to additional information about a service. A binding template may point to a URL that provides information on how a service is invoked. The specification points also contain information that associates the service with a service type.

• Service types. A technical model (tModel for short) defines a service type. Multiple businesses may offer the same type of service as defined by the tModel. A tModel defines the information contained for the service, such as the tModel name, the name of the organization that issued the tModel, the categories that define the service type, and pointers to specifications for the service type, including interface definitions, message protocols and formats, and security protocols. Typically, this is the WSDL document for a service.

A registrar is an organization that executes registration services on behalf of other organizations. A registrar can help a business define and assemble its registry information, including the list of services the organization provides.

In a service-oriented architecture, we learned that this paradigm uses the find, bind, and execute approach. We learned that any service-oriented approach requires a "catalog" of services. UDDI covers the "find" aspects of a service-oriented architecture. UDDI usage is not limited to just Web services and can contain entries of other service types.

The Role of UDDI in Web Services

Figure 6.1 shows how a UDDI registry is populated with business and service information as well as how consumers use this information. Let us look at the steps involved in interacting with a registry:

1. Standards bodies and software companies define specifications specific to the vertical and register them in UDDI. These are referred to as tModels. For securities, the SEC may create tModels that define the format for a CUSIP or symbol.

2. Organizations register descriptions of their businesses and the services they provide. Each entry is assigned a Unique Universal Identifier (UUID) key. UUID keys are guaranteed to be unique across time and space and are immutable. A UUID appears as a formatted hexadecimal string, such as C1B9EF7A-322F-332A-8A3C-3214DA2E5EE1. A UUID is meaningful within the context of the registry in which it is contained. Businesses and services registered in multiple registries may be assigned different UUIDs.

3. Business applications, search engines, and intermediaries use UDDI registries to find services that satisfy the criteria they seek. They may search using any of the relevant classification schemes.

4. After a service has been found and bound, it can be executed by invoking the appropriate service interface.

Figure 6.1: UDDI interaction

Role of the UDDI Provider

UDDI is fundamental to a Web services infrastructure and provides the mechanism for organizing and managing services. The basic functions of a UDDI provider are advertising, discovery, and storage.

A UDDI provider provides a consistent way for businesses to advertise their services and make them available to others (advertising). Businesses and consumers need the ability to discover services contained in the registry (discovery). This information needs to persist the underlying XML and other resources (storage).

UDDI provides the plumbing, so each business does not have to re-create the infrastructure to support interoperability. This is where the principle of registries and repositories is formed. This common infrastructure supports metadata storage, schemas, programming interfaces, role-based authentication, and database connectivity, so a service can be located either programmatically or through human interaction, via Web pages.

UDDI is a registry that allows for registration of services, discovery of metadata, and classification of entities into predefined categories. It is not a repository, in that it does not have the ability to store XML resources such as WSDL or business process definitions that may be required to form trading agreements, nor does it present specify a security model. A repository is meant to store data, including XML documents, schemas, and other types, and supports extensive classification.

The term registry, when used in conjunction with Web services, means a shared resource between enterprises, accessible as a Web-based service, and the enabler of loosely coupled dynamic services. A registry can be thought of as a catalog of items, whereas a repository is the holder of items.

UDDI provides the ability to support maintenance of registry information through a set of administration pages. It is usually up to each UDDI provider to determine how to support security and registration to a UDDI registry. UDDI can be extended to support authentication using LDAP, Active Directory, or other custom credential stores.

Figures 6.2 through 6.6 are representative screen shots for registering Flute Bank in Microsoft's Test UDDI Registry.

Figure 6.2: Creating a business entity

Service Interfaces

A service interface is a published interface used to invoke a service. An interface can be implemented using any number of technologies, including WSDL, XML-RPC, COM+, CORBA (IDL), Java RMI, and others. A service interface can be described using multiple methods. A service can be described by using prose or a formal description language. In service-oriented architecture, the best approach to describing services should be XML. There is merit in this approach for other forms of application development as well. In a Web services paradigm, interfaces are usually described via a service interface description language, usually WSDL.

Figure 6.3: Details for the business entity

Figure 6.4: Creating a business service

Figure 6.5: Creating a binding template

Figure 6.6: Creating a tModel

A service interface document can reference other service interface documents using import elements. The service implementation document contains a description of a service that implements a service interface. The import element in the service document contains three attributes: namespace, location, and binding. The namespace attribute contains the URL that matches the targetNamespace in the document. The location attribute contains a URL that references the WSDL document. The binding attribute on the port element holds a reference to the binding in the document.

UDDI Informational Structural Model

UDDI contains four primary core data structure types: businessEntity, businessService, bindingTemplate, and tModel. Additional structures can also be defined, each of which is used to represent specific data types and is organized in a relationship. For example, multiple distinct businesses can publish information in a UDDI registry about the services they offer. The information for each business and the services it offers exists as a separate instance of the core data structures within the UDDI registry.

Figure 6.7 shows that each businessEntity can contain one or more distinct businessService structures, and each businessService can contain one or more instances of bindingTemplate structures. Each core data structure is uniquely identifiable, based on uddiKeys. By default, each is publisher-assigned but can be extended so users can offer their own under challenge. Each keyed structure has an attribute that is of type Key: businessEntity has a businessKey attribute, businessService has a serviceKey attribute, and so on.

Figure 6.7: UDDI core data structures

UDDI provides many options for customization via extensions to cover. UDDI.org provides a best-practices document at www.uddi.org.

businessEntity

The businessEntity structure contains information about a particular business organization and holds references to the services it offers. businessEntity is the highest in the hierarchy and contains descriptive information. As mentioned earlier, each businessEntity is identified by its businessKey. If its businessKey is not specified at publication time, the registry will automatically generate a key.

Figure 6.8 shows an example of a businessEntity and its relationship to other components of UDDI. Let us look a simple example of a businessEntity for Flute Bank:

 <discoveryURL useType="businessEntity">     http://www.flutebank.com?businessKey=uddi:flutebank.com:registry:support:22 </discoveryURL> ... <contact useType="Technical support">     <personName>Administrator</personName>     <phone>868-555-1212</phone>     <email>[e-mail]</email> </contact> ... <identifierBag>     <keyedReference        tModelKey="uddi:ubr.uddi.org:identifer:dnb.com:D-U-N-S"        keyName="Flute Bank"        keyValue="22-422-2232" /> </identifierBag> ... <categoryBag>     <keyedReference        tModelKey="uddi:ubr.uddi.org:categorization:geo3166-2"        keyName="Connecticut, USA"        keyValue="US-CT" /> </categoryBag> 

Figure 6.8: businessEntity

In the above example, the businessEntity specifies basic information about Flute Bank, such as contact information, Dun & Bradstreet number, andlocation. We will drill deeper into each of the elements of a business entity throughout this chapter.

businessService

In UDDI, a businessService entry indicates a logical service and holds descriptive information about a Web service in business terms. A businessService is a child of a businessEntity that provides the service. Information about how a businessService can be instantiated is contained within a bindingTemplate.

Each businessService is has a unique identifier. This value is assigned by each UDDI operator and cannot be edited by the publisher. It also contains the key to its parent businessEntity. Let us look at an example:

 <businessService businessKey="uuid:43CC32A4-4442B-2E4A-22318EAD5521"  serviceKey="">  <name>Flute Bank ATM Pin Service</name>  <description>This service is used for Flute Bank customers to reset their ATM                                                                       PIN<description> <bindingTemplates>    ... </bindingTemplates> <categoryBag>    <keyedReference       <keyName="Flute Bank ATM Services"        keyValue=54328910"        tModelKey="UUID:DB44690D-9AF8-4D24-A9AD-04621E34E274"/>  <</categoryBag> </businessService> 

Figures 6.9 and 6.10 show the elements of a businessEntity and businessService. In both examples, name is required, but its description is optional. The bindingTemplate element is required and specifies technical information on various implementations of the service. We will expand on this later. The category bag is used similarly to businessService and allows for the service to be classified using multiple taxonomies.

Figure 6.9: businessService

Figure 6.10: bindingTemplate

bindingTemplate

A bindingTemplate contains information necessary for a client to invoke a service. It specifies the information for a particular Web service and provides the URL of the service where it can be invoked. The bindingTemplate also contains references to tModels as well as service-specific settings. A bindingTemplate is a child of a businessService.

The key to a bindingTemplate is that it allows a service to expose what transports (e.g., bindings) it supports. A service can choose to support multiple binding protocols, including HTTP, HTTPS, SMTP, and so on. Let us look at an example of a bindingTemplate:

 <bindingTemplates>  <bindingTemplate bindingKey="" serviceKey=""     <description>Flute ATM Service via HTTP</description>     <accessPoint URLType="http">        http://www.flutebank.com/services/accesspoint> </bindingTemplates> 

In the above example, the bindingTemplate specifies a URL for accessing Flute Bank's ATM service using the HTTP protocol. The accessPoint URLType specifies the actual protocol to be used. Valid values are mailto, http, https, ftp, fax, phone, and other.

tModel

Organizations require a mechanism to publish information about the specifications and their respective versions used for their services. WSDL is one of the service specifications that can use this approach. Since it is possible to have multiple revisions of a specification active at any time, a need arises to distinctly identify public specifications, and the specification in use needs to be discoverable. The information about the specification contains metadata and is called a tModel within UDDI (Figure 6.11).

Figure 6.11: tModel

tModels provide an approach that allows for reuse and standardization within a Web services framework. The concept behind tModels is useful for discovering information about services exposed for broad usage. Suppose OfficeMin purchased shopping cart/catalog software from Aspectsoft that lets customers purchase tax preparation software and cellular phones at discounted prices via the Web site. OfficeMin decides to advertise its new e-commerce site within a public UDDI registry.

Let us look at a scenario where tModels can be used. The OfficeMin Web-master has decided to incorporate shopping cart software as part of the Web site. The software is Web service enabled and can use features of a UDDI registry. The software first contacts a UDDI registry, to determine shipping providers (UPS, FedEx, DHL, and Airborne) based on classification information. It also downloads shipping rate tables for all fifty states from each of the providers. The shopping cart also contacts the UDDI registry to determine tax information for each of the fifty states. Finally, the software uses the UDDI registry to locate several payment acceptance companies, to handle credit card acceptance.

The shopping cart was able to configure itself using tModels for:

• A list of the fifty states

• Shipping companies

• Tax tables

• Payment gateway providers

• Format information for valid credit cards

A tModel key can be thought of as a pointer to a service description. Many services will use a given domain value, such as state postal code abbreviations, zip codes, and classifications. This information is not duplicated for each individual service. Instead, a tModel key points to information about specifications via tModel entries and references. This approach has several advantages. For developers, tModels allow quick identification of compatible services, using a common point of reference. For software vendors and standards bodies, tModels provide the ability to quickly identify implementations of Web services compatible with that tModel.

tModels in Web services store the reference to WSDL in the UDDI. A tModel also contains metadata about the technical documents as well as an entity key that uniquely identifies the tModel. UDDI itself uses tModels within its own information model, to store metadata. Some of the UDDI tModels for internal usage are:

• Transport descriptions, such as HTTP, HTTPS, and SMTP (uddi-org:types)

• Postal address formats (tModels support one for each country as well as several for multilingual countries.)

• Categorization, identifiers, and namespaces (One identifier may be used to attach a tModel to an organization, such as an IRS Taxpayer Identification Number, as in the following example.)

 <identifierBag>     <keyedReference tModelKey="uddi:ubr.uddi.org:identifier:irs.gov.tt:TIN"     keyName="Flute Bank"     keyValue="868-668-921"        </keyedReference> </identifierBag> 

To understand how tModels work, let us first look at the WSDL for the Flute Bank News Web service, shown in Listing 6.1.

Listing 6.1: Flute Bank News WSDL

 <?xml version="1.0"?> <definitions name="NewsService-interface"   targetNamespace="http://www.flutebank.com/NewsService-interface"   xmlns:tns="http://www.flutebank.com/NewsService-interface"   xmlns:xsd="http://www.w3.org/2001/XMLSchema "   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"   xmlns="http://schemas.xmlsoap.org/wsdl/">   <message name="SymbolRequest">   <part name="symbol" type="xsd:string"/>   </message>   <message name="SymbolResponse">   <part name="news" type="xsd:string"/>   </message>   <portType name="NewsService">   <operation name="getNews">        <input message="tns:SymbolRequest"/>        <output message="tns:SymbolResponse"/>   </operation>   </portType>   <binding name="SymbolBinding" type="tns:NewsService">   <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>   <operation name="getNews">       <soap:operation soapAction="http://www.flutebank.com/GetNews"/>   <input>   <soap:body use="encoded" namespace="urn:symbol-news"             encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>       </input>       <output>         <soap:body use="encoded" namespace="urn:symbol-news"             encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>       </output>     </operation>   </binding> </definitions> 

When we publish the above WSDL, we will create the related UDDI tModel, shown in Listing 6.2.

Listing 6.2: UDDI tModel for Flute Bank News service

 <?xml version="1.0"?> <tModel tModelKey="">   <name>http://www.flutebank.com/NewsService-interface</name>   <description xml:lang="en">Service definition for Flute Bank News service.                                                                         </description>   <overviewDoc>   <description xml:lang="en">WSDL Service Interface Document</description>   <overviewURL>http://www.flutebank.com/service/news-interface.wsdl#SymbolBinding                                                                         </overviewURL>     </overviewDoc>   <categoryBag>     <keyedReference tModelKey="UUID:B1FAC26D-4569-4421-9E20-36A752A62ED4"                     keyName="uddi-org:types" keyValue="wsdlSpec"/>     <keyedReference tModelKey="UUID:DB44690D-9AF8-4D24-A9AD-04621E34E274"                     keyName="Flute Bank News services"                     keyValue="54328910"/>   </categoryBag> </tModel> 

Note that the keyedReference points to the version of the WSDL specification the service uses. This allows a service to understand what type of WSDL it may receive. By using tModels, you can use UDDI to represent data and metadata about services, business entities, and other parties. The UDDI specification defines many commonly used tModels but creating your own may be worth considering for scenarios UDDI does not handle.