One of the clauses in the W3C definition of a web service states that its "definition can be discovered by other software systems." In order to make this possible, the web service standards include:
A language used to define the interfaces provided by a web service, in a manner that is not dependent on the platform on which it is running or the programming language used to implement it
A provision for a registry within which these definitions can be placed
Since all access to web services uses XML messaging, it is appropriate that the language used to describe a web service should itself be XML-based. The Web Service Description Language (WSDL) was originally defined by Microsoft, IBM, and Ariba, and is now subject to standardization by the W3C consortium. W3C recently published a draft of its official variant of WSDL (Version 1.2), which can be downloaded from its web site at http://www.w3c.org. At the time of this writing, however, most existing WSDL-aware software (including that provided by Sun Microsystems) is based on WSDL Version 1.1.
As you'll see in Chapter 5, WSDL describes a web service by defining the messages that it accepts and the reply messages that it returns. These messages are actually defined first in abstract terms and then bound to one or more message and transport protocols. Today, of course, web services use SOAP as the messaging protocol, and therefore almost all WSDL files will define a binding of the service to SOAP messages delivered over the HTTP protocol. WSDL is not a difficult metalanguage to learn, and it is useful to be able to glance at a WSDL file to get an overview of the interface of a service. However, you don't really need to be able to do much more than this because WSDL definitions are usually both created and consumed by software tools. As you'll see later in this chapter, once you obtain the WSDL definition of a service, the first thing to do is generate a Java interface from it that provides the same operations as the service itself. Not only is a Java interface much easier to understand than the corresponding WSDL, but you can also use the interface when writing your client application, or when creating an implementation of the service itself, if that is your assigned task.
Given that WSDL definitions are central to web services, how would you go about finding such a definition? One way to do so is to contact the service owner and ask for it. WSDL definitions are plain-text XML documents and can be readily exchanged using email or placed at a known URL for download from the Internet (most tools that consume WSDL let you specify its location either as a URL or as a file in an accessible filesystem). In many cases, however, you might not know who owns a service or even exactly what services are available. You might, for example, want to find out which organizations provide online book-selling services and then examine their service definitions to see if any of them provide the facilities that you need. To make this possible, WSDL definitions can be published in a registry. There are two major registry standards in use today, both of which can store web service information � the ebXML registry/repository and the UDDI registry. Both of these registry types, which are discussed in Chapter 7, allow the service owner to advertise service information that includes the location of a WSDL definition plus associated documentation and contact numbers that will be of use to potential consumers of the service. A registry can also contain classification information that can make services easy to find. For example, a service provider can specify that it is a bookseller operating in the United States. A potential client for a bookseller's web service based in the United States can locate all such providers by searching the registry using these specific criteria. Not surprisingly, both the ebXML and UDDI registries are themselves XML-based web services.
 |
|
|