The term Web services is the latest hot phrase in development circles. Although the
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
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
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
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
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
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
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
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
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
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.