Service Discovery and Description

Defining messaging APIs is only the first challenge. To do global electronic commerce, businesses need to have to have a systematic way of publishing the API and providing a means of letting others discover that it exists (or, in a worldwide marketplace, even letting potential customers know that the business exists). The goal is to support late, run-time binding of applications to services.

The ebXML repository group is addressing this problem within the context of its own specification; however there are other efforts in the emerging web services community that also try to standardize how this might be implemented. The latter tend to be focused on serving the current HTTP-centric web service model, but the specifications will likely to be extended to support transport infrastructures that would be made accessible using JMS.

UDDI

In September 2000, Ariba, IBM, and Microsoft jointly announced the formation of the Universal Description, Discovery, and Integration (UDDI) initiative. The goal was to build broad industry support around a standard for the discovery of businesses and services on the Internet.

To accomplish this, the initiative would seek input from a large number of players both in the Internet space, and from traditional industries such as manufacturing, which will be big consumers of business-to-business solutions. Over an 18-month timeframe, the UDDI community will define standards and APIs that build on existing successful technologies like HTTP, XML, SOAP, DNS, etc. After managing this process, the committee will ultimately transfer the results to an external standards body (not formally identified by press time).

By the end of the year, there were over 130 vendors involved in the group, including most of the key players in the business-to-business infrastructure space. Indeed, even a number of companies with alterative solutions, such as HP with its eSpeak framework, have become involved.

Arguably, UDDI is putting itself in the same space as the ebXML Registry and Repository Team. The difference is really one of scope and focus. Organizations are beginning to deploy SOAP-based web services now, and a solution for service discovery and registration, again with SOAP as a focal point, is urgently required. The ebXML group is taking a more generalized approach to repositories, considering them as placed to register business processes, core components, etc.

UDDI proposes the construction of a centralized, but replicated repository of business information. The repositories will not hunt out services on the net like a web crawler. Rather, businesses will explicitly register with any convenient repository; these entries will be replicated among a global network of cooperating repositories, thus minimizing potential issues around politics and scalability. Thus, the model is more like DNS than a web search engine.

The specification will define the XML-based messages to query the repository to discover information about businesses and the interfaces that they support. The specification will also describe publishing interfaces businesses can use to register and update their entries.

Businesses register themselves in white, yellow, and green pages in the repository. Naturally, all registrations make use of XML documents. White pages contain general information about the business. Name, contact details like phone and address, web site location, registration numbers (such as DUNS codes), key personnel, etc. constitute typical white pages entries. This in itself solves a key business problem. Today, there is no single search engine that is global, comprehensive, and devoted to business. There are, of course, industry-specific databases, sometimes run by professional organizations. However, there is no general, central repository.

Yellow pages group businesses into categories, using a number of standard taxonomies. The North American Industry Classification System (NAICS, see http://www.census.gov/epcd/www/naics.html), which defines a hierarchical series of numeric identifiers that classify businesses into categories like "Book Publishers (code 51113)" is one such taxonomy.

The Universal Standard Products and Services Classification (UNSPSC, see http://www.unspsc.org) is another, with a more global focus. Finally, green pages will incorporate location-based classifications. Additional taxonomies will be introduced as the specification evolves.

Green pages contain information about how an organization conducts business. This includes descriptions of business processes, and descriptions about the services the organization provides as APIs. If a business supports other discovery services, such as its own service discovery repository, a reference to that will be contained here.

The community quickly published a number of specifications: the UDDI Programmer's API Specification; the UDDI Data Structures Reference; and the UDDI XML Schema (all three documents are available at http://www.uddi.org/specification.html). The API defines a simple mechanism for businesses to publish information, and to make inquiries of the repository using simple XML API inside SOAP, and based on a synchronous, request/response call model. Nevertheless, the community does not intend to limit itself to a single API; instead, it anticipates that it will support a number of different APIs for repository access.

By November 2000, a test implementation of the repository became publicly available for beta testing. This will probably be available for at least six months. This first version of the repository is free to access and register. Each of the three founding members hosts a replica of the repository. Businesses can register at any one; replication of the entry among the other systems is automatic. The link http://www.uddi.org/register.html provides access to all of the test systems so that businesses can make basic registrations now.

People interested in experimenting with UDDI (and in particular, WSDL, described in the next section) can download the IBM Web Services Toolkit from http://alphaworks.ibm.com/tech/webservicestoolkit, which supports some publication and interface discovery functions aligned to the current specification. The toolkit contains a web service browser - similar in function to a class browser in an IDE, but used to explore the services registered in a repository. As web services become more commonplace, service browsers will become essential development tools. The toolkit also provides a preview of the work IBM is doing to bind SOAP to MQSeries.

Example

The UDDI Programmer's API Specification outlines a relatively simple mechanism for querying a repository for information about a business and the services it offers. We will not cover this in detail here, but instead show some simple examples of UDDI in action.

The following dialogs show some typical requests and responses for queries against IBM's UDDI test installation, using the HTTP binding. First, a query using the UDDI find_business function, searching for "IBM". The request:

     POST /services/uddi/inquiryapi HTTP/1.1     Accept: text/xml     Cache-Control: no-cache     SOAPAction: " "     Content-Length: 216     User-Agent: Mozilla/4.0 (compatible; MSTE 5.01; Windows NT)     Host: www-3.ibm.com     Connection: Keep-Alive     <?xml version='1.0' encoding='UTF-8'?>     <Envelope xmlns='http://schemas.xmlsoap.org/soap/envelope/'>       <Body>         <find_business generic='1.0' xmlns='urn:uddi-org:api'>           <name>IBM</name>         </find_business>       </Body>     </Envelope> 

The response (note that a number of ServiceInfo elements have been removed for clarity):

     HTTP/1.1 200 ok     Date: Wed, 07 Feb 2001 00:15:43 GMT     Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Unix)     content-length: 2656     Connection: close     Content-Type: text/xml     <?xml version="1.0" encoding="UTF-8" ?>     <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">     <Body>       <businessList generic="1.0" xmlns="urn:uddi-org:api"          operator="www.ibm.com/services/uddi" truncated="false">       <businessInfos>         <businessInfo businessKey="">           <name>IBM Corporation</name>           <description xml:lang="en">At IBM, we strive to lead in the creation,                   development and manufacture of the industry's most advanced                   information technologies, including computer systems, software,                   networking systems, storage devices and microelectronics.           </description>           <serviceInfos>             <serviceInfo serviceKey=""                     businessKey="">               <name>Buy from IBM</name>              </serviceInfo>              <serviceInfo serviceKey=""                   businessKey="">                <name>                  Buy from IBM using business-to-business e-commerce applications                </name>              </serviceInfo>              <serviceInfo serviceKey=""                              businessKey="">                <name> Supply goods and services to IBM</name>              </serviceInfo>     <!---Removed some serviceInfo elements for clarity -->              <serviceInfo serviceKey=""                              businessKey="">                <name>UDDI Publish</name>              </serviceInfo>              <serviceInfo serviceKey=""                              businessKey="">                <name>UDDI Inquiry</name>              </serviceInfo>            </serviceInfos>          </businessInfo>          <businessInfo businessKey="">            <name>IBM Webservices Test Area</name>            <description xml:lang="en">Use this area for investigating visual                    Webservice components            </description>            <serviceInfos></serviceInfos>          </businessInfo>       </businessInfos>     </businessList>     </Body>     </Envelope> 

Even this early into the specification, IBM has a number of web services available. Note the businessKey attribute of the businessInfo element. The value of this is IBM's globally unique identification as a business entity. Now let's do try the UDDI find_service interface, searching for IBM's "UDDI Inquiry" service. This time, we will edit the HTTP headers out, as they are not significantly different from the previous example. The request:

     <?xml.version='1.0'.encoding='UTF-8'?>     <Envelope xmlns='http://schemas.xmlsoap.org/soap/envelope/'>       <Body>         <find_service generic='1.0' xmlns='urn:uddi-org:api'                businessKey=''>          <name>UDDI Inquiry</name>        </find_service>       </Body>     </Envelope> 

The response:

    <?xml version="1.0" encoding="UTF-8" ?>    <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">      <Body>        <serviceList generic="1.0" xmlns="urn:uddi-org:api"           operator="www.ibm.com/services/uddi" truncated="false">         <serviceInfos>           <serviceInfo serviceKey=""             businessKey="">            <name>UDDI Inquiry</name>          </serviceInfo>         </serviceInfos>        </serviceList>       </Body>     </Envelope> 

Note the serviceKey attribute of the serviceInfo element. We will use this to discover some details about the UDDI Inquiry service (again, dropping the HTTP headers for clarity). The request:

    <?xml version='1.0' encoding='UTF-8'?>    <Envelope xmlns='http://schemas.xmlsoap.org/soap/envelope/'>      <Body>        <get_serviceDetail generic='1.0' xmlns='urn:uddi-org:api'>          <serviceKey></serviceKey>        </get_serviceDetail>      </Body>    </Envelope> 

The response:

     <?xml version="1.0" encoding="UTF-8" ?>     <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">       <Body>         <serviceDetail generic="1.0" xmlns="urn:uddi-org:api"                operator="www.ibm.com/services/uddi" truncated="false">           <businessService businessKey=""                serviceKey2="">              <name>UDDI Inquiry</name>              <description xml:lang="en">                Inquire about UDDI registry information              </description>              <bindingTemplates>                <bindingTemplate bindingKey=""                   serviceKey="">                <description xml:lang="en">UDDI inquiry (servlet)</description>                <accessPoint URLType="http">                   http://www-3.ibm.com/services/uddi/inquiryapi                </accessPoint>                  <tModelInstanceDetails>                    <tModelInstanceInfo tModelKey="UUID:">                  </tModelInstanceInfo>                 </tModelInstanceDetails>               </bindingTemplate>               <bindingTemplate bindingKey=""                   serviceKey="">               <description xml:lang="en">UDDI Inquiry (web)</description>               <accessPoint URLType="http">                 http://www.ibm.com/services/uddi/find.htm</accessPoint>                 <tModelInstanceDetails>                   <tModelInstanceInfo                      tModelKey="UUID:">                   </tModelInstanceInfo>                 </tModelInstanceDetails>               </bindingTemplate>             </bindingTemplates>           </businessService>         </serviceDetail>       </Body>     </Envelope> 

The bindingTemplate element describes the service bindings for UDDI Inquiry. Binding templates are one of the fundamental structures defined by UDDI. They provide details about a service entry point, as well as information needed to access the service. There are two bindingTemplate elements here: one marked web (with an HTML page as access point) and another servlet (with what we can assume is a URL pointing to a servlet as the access point).

In UDDI, tModels are unique interface identities - the specification calls them fingerprints for services. For example, here one logical service, UDDI Inquiry, has multiple interfaces (web and servlet). Each of these has a unique identification, shown here as the tModelKey attribute on the tModelInstanceInfo element. Note also that each distinct binding template contains a serviceKey attribute referencing back to the service name. Simply by inspecting this structure, we can infer much about what kinds of queries are available in UDDI.

For those interested in exploring this further, Microsoft provides a tool that launches queries against the test repositories at http://msdn.microsoft.com/workshop/xml/articles/12182000-test.htm.

WSDL

The Web Services Description Language (WSDL) is a specification for describing the interfaces and deployment of web services in a standardized manner. IBM and Microsoft unveiled it at the end of September 2000 and submitted it to the UDDI initiative, where at press time it resides under the category "Potential Submissions." Copies of the spec are available from http://www.uddi.org/submissions.html.

WSDL evolved from two separate vendor initiatives: IBM's Network Accessible Service Specification Language (NASSL) and Microsoft's SOAP Contract Language (SCL). The specification's goal is to describe the interfaces of a web service without necessary documenting its behavior or the rules governing message exchange (the authors will explore this in later revisions). WDSL approaches this by describing web services as a collection of related endpoints. Endpoints are aggregations of ports, which are the concrete realizations of a message bound to a location and protocol such as HTTP, SOAP, or MIME.

The specification is complex and likely to evolve significantly in the near future, so I will not try to describe it here. It does, however, appear to solve a difficult problem: how does one tie the abstract concept of a service to a concrete description of the actual APIs that implement it. Different transport bindings result in different APIs (which, ultimately, is all the clients of the service are interested in), even though these bindings may package the same underlying abstract message.

At present, the specification only defines bindings to HTTP, SOAP, and MIME, so using it in a JMS implementation would require many assumptions that may ultimately go against the specification. Later revisions of WSDL will offer alternative bindings, and we can probably expect IBM to provide an implementation for its MQSeries MOM product, which of course supports a JMS API. Anybody interested in exploring WSDL now can look at the WSDL Toolkit on IBM's AlphaWorks (http://www.alphaworks.ibm.com).

This package generates Java stubs and skeletons from a WSDL document, using the Apache SOAP implementation for communications. The Web Services Toolkit (described in the UDDI section) also demonstrates how WSDL documents describing interfaces can be stored in a UDDI repository.

JAXR

The Java API for XML Registries is a project to create a client-side Java API that encapsulates the process of interacting with a registry. Like JAXP for parsers, the intention is to create a standard clientside API that provides query and publishing functions for a number of different registry systems.

The initial implementation targets the ebXML registry, but it could also provide access to UDDI registries. JAXR will make use of the messaging abstractions developed as part of JAXM, discussed below. Interestingly, one of the project goals is to enable the adoption of publish/subscribe models for XML messages between businesses.

JAXP is registered as JSR 000093 in the Java Community Process, and can be found at http://java.sun.com/aboutJava/communityprocess/jsr/jsr_093_jaxr.html. The group intends to publish a public draft of its specification by Q2 2001.