The term Web services is the latest hot phrase in development circles. Although the term has the word Web in it, it is not a Web application–specific technology. Instead, it uses Web technologies, such as Web servers and HTTP, to provide a set of services that can be invoked by other programs on the network.
The concept of Web services dates back to the early 1990s with Sun Microsystems's "the network is the computer" campaign. The idea was that with a strong and reliable network as the infrastructure, business problems could best be solved by distributing the solution of discrete problems to specialized components across the network. This decentralization of the processing mechanism has significant advantages as the system evolves, because relatively fewer places need to be updated when things change. Standards-based Web services first got some serious attention when Microsoft unveiled its .NET strategy. Web services play an important part in .NET applications.
Simply put, a Web service is a collection of functions packaged and published on a network for use by other client programs. From the highest levels of abstraction, a Web service is simply another type of remote procedure call (RPC). The difference, however, is what Web services bring to the concept of RPC. Much as component models—COM and JavaBeans—have made component reuse practical, Web services make RPC practical by providing a set of standards for discovering and invoking the services.
Component models define how components interoperate and how they can be found and examined programmatically. Both COM and JavaBeans have an introspection mechanism that allows other components to bind to them late and programmatically construct the appropriate function calls. Web services define a similar mechanism for the discovery of functional metadata.
Any Web service can interact with any other Web service. They can aggregate themselves to provide higher-level functions. After all, they are software components themselves, and all components have the potential to invoke Web services.
One key to making all this practical is the Simple Object Access Protocol (SOAP). SOAP is built on top of XML; that is, a SOAP message is simply an XML-formatted document that validates against a certain DTD or schema. When used with HTTP, SOAP messages—documents—can be sent to Web servers, which invoke the specified function defined by the Web service.
A SOAP message consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. The envelope is the top element of the XML document. The header is a way messages can be extended in the future with prior knowledge, similar to the use of the <META> tag in HTML. SOAP defines namespaces for the envelope and the encoding used by the communicating parties to ensure that the message is interpreted correctly.
In general, a SOAP message specifies three parts:
In the following example, the address-lookup problem discussed earlier in this chapter might have been solved in part with a Web service. An example of the SOAP message that might have been used follows:
POST /CityStateLookup HTTP/1.1 Host: www.wae-uml.org Content-Type: text/xml; charset="utf-8" SOAPAction: "http://www.wae-uml.org/examples/CityStateLookup" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:LookupCityState xmlns:m="http://www.wae-uml.org/examples/ CityStateLookup"> <zip>29072</zip> </m:LookupCityState > </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The SOAP response to this message is:
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:LookupCityStateResponse xmlns:m="http://www.wae-uml.org/examples/ CityStateLookup"> <City>Lexington</State> <State>SC</State> </m:LookupCityStateResponse > </SOAP-ENV:Body> </SOAP-ENV:Envelope>
The rules and encodings for more complex data structures can get a little involved and are beyond the scope of this simple introduction. Fortunately, most tools today make the use of Web services very easy. In fact, in some tools like Visual Studio .NET make it is possible to couple an application to a Web service with simple drag-and-drop operations and a minimal amount of coding.
In order to make Web services practical, you need more than SOAP. You also need a mechanism for publishing and describing Web services to potential clients. This mechanism is a standard: Universal Description, Discovery, and Integration (UDDI). A UDDI Business Registry is a set of replicated registries of information about Web services on the network. Registration of a service involves four core data structure types: business information, service information, binding information, and specification information.
The general usage scenario is for a programmer to use a Web-based interface or specialized tool to query the UDDI registry via its inquiry API. The programmer can read about the business, search by categories, and follow URLs with a browser to obtain more detailed information. After finding the service that will do the job, the programmer selects an appropriate binding template and tModel. With this information and the information that it points to, the programmer can write the code that will use the Web service in an application.
This information described in a UDDI business service is packaged in an XML structure as defined by the UDDI specification and managed by UDDI registries. In general, this information categorizes and points to URLs that describe Web services but doesn't provide enough detail for a programmer to code a system that can accept and send SOAP-based Web service messages.
What is needed next is a more detailed specification of the SOAP interface. The UDDI specification is focused only on finding the right service, not on explaining how to use it. The tModel structure in the service description points to the next specification and document in the mix, the Web Services Description Language (WSDL). The WSDL specification describes in detail how to invoke a Web service and what to expect when it responds.
A WSDL description defines a Web service as a collection of network end points, or ports. Each port defines a collection of operations that can be invoked. Each operation includes a set of input and output messages: the parameters. A binding maps a port type to a specific protocol, HTTP, and data format, SOAP. A port instantiates a port type and binding at a specific network address.
A WSDL document contains five major elements:
In general, the first three elements are an abstract description of the service. The binding connects these abstract descriptions and associates them with transport and encoding protocols. The service element provides the final piece of information and the instance of the Web service.
When all the pieces—UDDI, WSDL, and SOAP—are put together and with the right tool support, Web services can become a reality. Figure 4-6 shows how an application developer uses a UDDI registry to find and to locate a service that will make the development of the client application easier. With this service and by following the link to the WSDL document that provides the details, the developer can either use a tool or do the appropriate coding that will allow the client application to use the Web service. In the running client application, SOAP and HTTP are used to communicate with an instance of the Web service.
Figure 4-6. Web services in the development and runtime environment
In Figure 4-7, a Web service developer codes—builds—a Web service and deploys it to an appropriate host. A WSDL document that describes in detail how to use this service is created. Also created is a UDDI document that describes the business and is used to publish the Web service on a UDDI registry.
Figure 4-7. Development of a Web service
Like distributed objects and XML, Web services are not required by Web applications; nor is the use of Web services only for Web applications. The two are independent. Web services might be an important part of your Web architectures. Those services depend on HTTP, as do Web applications as a principal communications protocol. In many ways, Web services can be thought of and even modeled as a Web application. For the most part, Web applications produce HTML responses to HTTP requests, whereas Web services provide SOAP responses to HTTP/SOAP requests.
What makes these two technologies truly akin is that they use HTTP, a connectionless protocol designed for scalability and robustness. Many issues related to modeling and designing Web applications are a direct result of the use of HTTP. It should not be a surprise that the same issues can be found in modeling and designing Web services. Although this book is not directly devoted to an exploration of how to build Web services, it is hoped that an understanding of the issues involved in building Web applications can be applied to the building of scalable, robust Web services.