One perceived obstacle to widespread, easy access to Web Services is limited ability to locate suitable Web Services. If an enterprise needs a service that it doesn’t already use, how does it discover providers that offer the service? Today, enterprises make use of various directories to identify a vendor or products or services of interest. The directo- ries offered by the phone company are an example of one such type of directory, but industry-specific directories are also possible. To provide information on Web Services available over the Internet, a comparable type of Internet facility has been conceived.
A consortium of companies, including Ariba, IBM, and Microsoft, began developing the concept of an Internet business directory. The result is the UDDI Project. UDDI con- tinues to be a collaborative effort of concerned businesses. Unlike the topics that have been discussed so far, UDDI is more than a specification or standard. It encompasses an infrastructure that implements the standard and allows Internet-wide, all-inclusive search and discovery of Web Services.
UDDI includes a structured way to describe a business, the services that are offered by the business, and the programmatic interface to the services. Data is organized so that a business may offer multiple services, and a service (which may have been devel- oped by a separate organization) may be offered by more than one business.
UDDI is a Web accessible directory and is built on SOAP over HTTP. A UDDI reg- istry is basically a Web Service. Two sets of SOAP interfaces have been defined. One set of interfaces for potential subscribers supports searching for services or direct retrieval of details about known services of interest. While UDDI is built on SOAP, it should be pointed out that the services described in the directory are not required to be SOAP services. The directory’s discovery services can also be used to mitigate problems that occur during runtime access of the registered Web Service. If a service is not accessible at a previously published location, the registry can be updated to refer to a location where the service can be accessed. Service subscribers can then update their location caches. The second set of interfaces is for use by service providers and supports saving descriptions, deleting descriptions, and security for access to these services.
The infrastructure conceived by the UDDI Project is a single, distributed network of directory operators called the UDDI Business Registry. Business and service descrip- tions published by the Business Registry are intended to be publicly available to anyone without restriction. Publishing and deleting information are subject to authorization checks. Publishing a description at one node results in the description being propagated to and available at all nodes. IBM, Microsoft, SAP, and HP operate nodes.
An alternative to public business registries are private registries that make Web Ser- vices known to a community of potential subscribers. The community can be based on a common line of business, such as building construction or manufacturing lawn fur- niture, or the community could be a single company. Private registries cater to sub- scribers who have common interests and needs. Unlike the business registry, access to
a private registry may not be open to everyone, and controlling access to the informa- tion becomes important.
A business registry contains a variety of company-specific data so that a potential subscriber can decide whether it wants to do business with the service provider and, if it does, what must be done to use the service. Besides the name of the company, the registry can include other identifying information, such as tax number, a text descrip- tion, and contact information. Industry segment or business categorization descriptors support use of the registry for searches based on industry. Potential subscribers can locate companies that offer the type of services they need. Finally, the registry can con- tain technical and programmatic descriptions of the Web Services offered by the com- pany so that programmers have the information they need to interface with the Web Services offered.
Five structures have been defined for UDDI entries. They are businessEntity, busi- nessService, bindingTemplate, tModel, and publisherAssertion. The diagram in Figure 2.4, taken from UDDI Version 2.0 Data Structure Reference, UDDI Open Draft specification 8, June 2001, illustrates their relationship.
The businessEntitystructure represents a business. The structure is made up of a Uni- versally Unique ID (UUID) that is assigned to each business entity, and can also include a business name, description, and the contacts that are in the white pages. These identifiers and categories are descriptors that can be used to classify businesses and the services they provide. Finally, the structure optionally includes one or more
businessServicestructures.
The businessServicestructure includes data about a service being offered by the busi- ness. This structure contains a UUID that is assigned to each business service, an optional text-based description of the service and category descriptors, and zero or more binding templates.
The bindingTemplatestructure identifies how and where a service can be accessed. Each binding template is assigned a UUID and contains an address that can be used to
call a Web Service. This address can be a URL or an e-mail address. The tModelIn-
stanceDetailselement of the binding template identifies a specific tModelthat contains the details of the interface used to access the Web Service. The bindingTemplateincludes zero or more tModels.
The tModelstructure contains the technical specification of the Web Service inter- face. It contains a UUID for the tModel, a name, and a description. tModelscan contain identifier and category descriptors.
The publisherAssertionprovides a way for two businesses to assert a joint relationship. For this to work, both businesses must agree to the assertion before it is published.
While UDDI depends on SOAP for its API structure, the services listed in a UDDI Registry need not be limited to SOAP-based services. Likewise, SOAP subscribers are not limited to using UDDI registries to locate Web Services. Subscribers can learn of the existence of a Web Service through word of mouth, from an advertisement, or by look- ing up the desired service in a paper-based phone directory. Once the service has been located, details of the service can be provided to the subscriber by email, on a floppy disk, or in a manual. There is no tight coupling between SOAP and UDDI. UDDI is not needed in order for SOAP to succeed. For all these reasons, adoption of UDDI is not happening as quickly as its backers expected. As we will see in the next section, the same holds true for the relationship between UDDI and WSDL.
Figure 2.4 UDDI data structure relationship.
WSDL
To ease the burden of developing SOAP code, a vendor standard for an XML-based language to describe the SOAP interface has been developed. The initial Web Services Description Language (WSDL)(Microsoft 2001) specification was a joint development of Ariba, IBM, and Microsoft. The WSDL 1.1 specification was turned over to the W3C, which published it as a note (W3C 2001b) in March 2001. The W3C Web Services Description Working Group is now working on further development of the language. Earlier, we discussed concerns about the verbosity of XML. WSDL expands XML several times over. Luckily, WSDL is usually only used during design and develop- ment of Web Services applications. We should also note that even though WSDL is
Business Entity Business Entity
Publisher Assertion Business Service Business Service Binding Template Binding Template tModel tModel 48 Chapter 2
text-based, human beings were not meant to comprehend WSDL. It is a machine-gen- erated and machine-processed markup language used with software development tools. Finally, WSDL is its own markup language. It is not SOAP. So if someone looks at it and it does not look familiar, this is understandable.
Since we don’t expect that human beings will have to dissect a WSDL specification, we won’t go into the details of WSDL. Instead, we’ll discuss its structure and describe how it specifies the interfaces to Web Services.
WSDL documents describe logical and concrete details of the Web Service. The log- ical part of the WSDL document describes characteristics of Web Services that are determined by the service developer and are valid regardless of the actual implemen- tation. The concrete part of the document describes aspects of the service that are decided by the service provider. This supports the independent development of Web Services that may be offered by different service providers. Figure 2.5 shows the parts of a WSDL document.
To define an interface with WSDL, we begin by defining the types of data exchanged across the interface. The type portion of a WSDL document declares the namespaces and datatypes used in the Web Services messages that constitute the service. It defines application-specific data types. Data is then organized into messages. In the case of SOAP, message descriptions only apply to the body of the SOAP message. Headers are defined elsewhere within the WSDL document. portType defines the operations sup- ported by a logical endpoint and the messages sent or received. For instance, a SOAP service provider receives a message and generates a response to the received message. The messages received and sent in response are defined in the message portion of the WSDL message.
Up to this point, no implementation-specific information should be specified. For instance, the protocol used to transmit the messages, the encoding used for the data, and the location of the actual ports that are the connection points should not have been given. These features are regarded as differentiators for different Web Services providers. The service provider rather than the service developer makes these choices. The bindings, ports, and service portions of a WSDL document specify this informa- tion. First, bindings are used to specify the underlying protocol used to transport the messages in a portType (portTypes were previously defined in the logical portion of the WSDL document). The binding also specifies the encoding for the messages that are part of the operations in the portType. A port specifies the address at which the ser- vice is available. Finally, a service specifies the ports at which the service is available.
WSDL is not tightly coupled to SOAP, and the interface WSDL describes can be accessed via other protocols. Several bindings extend WSDL to account for differences in underlying transport protocol. There is a SOAP binding, an HTTP GET or POST binding without SOAP, and an SMTP binding. The SOAP binding describes how to specify whether a message body is a document type or an RPC type. If the message is an RPC, it describes how to identify arguments. The SOAP binding also includes the definition of header elements and header fault elements.
Because Web Service descriptions allow independently specified components, there is a lot of redundancy in a WSDL document. Operations reference messages. Bindings reference operations, and messages further define how the operations and messages are transmitted. This redundancy, combined with the use of XML, is responsible for the large size of a WSDL document compared to the actual SOAP messages it defines. This is the price of modularity.
Figure 2.5 WSDL document components.
WSDL is loosely coupled with SOAP and UDDI. There is a SOAP binding for WSDL, but there are also HTTP GET and POST bindings and an SMTP binding. SOAP interfaces can be specified by other means. There is guidance for using WSDL to provide the tModel and binding template of a UDDI entry, but UDDI could be used with other description languages, and there are other ways to distribute WSDL interface specifications.
A SOAP service provider is not required to use WSDL. WSDL’s verbosity makes it difficult for human beings to understand and is an impediment to its acceptance. Developers who use WSDL are those using development tools that automatically gen- erate and consume WSDL interface descriptions.