Download (direct link):
¦ The client must know what protocol to use to connect to the server. This protocol might be HTTP, SMTP, or FTP. The binding element performs this function.
¦¦ The client must know the location of the service so that it can be called. This address of the service is specified with the service element.
The WSDL description of a soap service contains all of the preceding information. This data is enough for a potential user of the service to invoke it. The data defines how to access the service, the format of all data sent and received, and the interaction between client and server. These functions provide a formalized way that is unambiguous in how it defines this information. One nice attribute of this type of formalized description is that a computer can parse this definition and generate a code stub to invoke it. This means people don't need to dig into the WSDL description of the service because they can let automatic tools handle this task.
WSDL is a very important part of soap services because it allows potential users of a service to evaluate the service and learn how to use it. Without a WSDL description of a soap service, the user must depend on verbose descriptions of the soap service, which make precise understanding difficult. Without this detailed and precise definition of soap services, it's difficult for programmers to invoke them correctly because misinterpretation is so easy with informal descriptions. A wrong understanding of a soap service interface means the user will not interface correctly to the soap service. This means that a lot of experimentation is required to get it right — which is very resource-intensive. In essence, WSDL transforms a soap service into a commodity that any client can easily utilize.
UDDI — Universal Description, Discovery, and Integration
We know how to define what a soap service does, but how do users discover what soap services are available for consumption? That's the job of UDDI — it allows a soap service to be registered so that users can find the WSDL of the soap service. UDDI allows the provider of a soap service to advertise it by providing a central directory service for publishing technical information about soap services. This central database of soap services
236 Chapter 12
is called a registry. UDDI is implemented as a soap service that allows manipulation of this registry containing definitions of soap services. Some people believe this is a necessary element for the widespread adoption of soap services . Similar to other soap service protocols, the agreement between all the vendors is its most valuable attribute. The idea behind UDDI is to provide a public place for soap services to be cataloged.
The details of how UDDI works are not critical to understanding the value of soap services. After all, you don't need to know how directory services at the telephone company work to understand why the service is useful and how to use it. The UDDI registry is essentially a yellow pages for soap services and allows for lookup of services. Users find great value when they have many choices for a soap service, as the ideas in this book illustrate — it is the value of the best of many. Service providers find value in this because it allows them to become one of the choices users have; when market uncertainty is high, this is potentially worth a lot of money to the service provider with the best service. UDDI lowers the entry barriers for new providers wishing to enter the market because its service enables users to know what their choices are. The important point about UDDI is that it defines the infrastructure needed for users to discover what services they have access to.
Putting the Soap Service Puzzle Together
So far, I have presented the framework defining what a soap service is and how to use one. I started at the bottom by defining XML, which is the language used to describe technical aspects of soap services in a precise way. Then this chapter discussed how this XML information is packaged into a SOAP message that is independent of any vendor's proprietary architecture. WSDL is discussed as the standard describing how to use a particular soap service. Finally, UDDI defines the infrastructure to build registries of technical information about soap services. Together these standards allow a commoditization of soap services. These are the main puzzle pieces that define how soap services work and why they have such value.
Figure 12.3 illustrates how these pieces fit together. First, the user discovers all the possible soap services from the registry and how to use them, then picks the best soap service for their particular needs from many choices. The user now has details of how to invoke the desired service and can do so directly.
Web Applications and Services 237
Registry with WSDL descriptions
Web service 1
Web service 2
Web service 3
Web service 4
UDDI web service
SOAP envelope with XML encoded message