Web Services

Web Services

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.

SOAP

One key to making all this practical is the Simple Object Access Protocol (SOAP). ^[4] 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.

^[4] The full specification for SOAP 1.1 can be found at http://www.w3.org/TR/SOAP.

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 :

1. An envelope, which is the main container of the message

2. A set of encoding rules for application-defined data types

3. A convention for representing remote procedure calls and responses

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.

UDDI

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.

• Business information: General information about the business, such as a unique identifier, the business name , a short description of the business, contact information, categories that describe the business, and a URL that points to a Web site with more information about the business.

• Service information: A list of related business services offered . Each service contains a description of the service, a list of categories that describe it, and a list of references to information related to the service.

• Binding information: With each service entry is a list of binding templates that define the access point and point to construction specifications for invoking the Web service.

• Specification information: A service type is defined by a tModel, which can be shared by multiple businesses. A tModel specifies additional categorization information and pointers to technical specifications for the service type, which might be a WSDL document (see the next section).

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.

WSDL

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). ^[5] The WSDL specification describes in detail how to invoke a Web service and what to expect when it responds.

^[5] At first, I too felt overwhelmed by the number of specifications and document types that need to be managed to understand all the details of Web services; come to think about it, I still am.

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:

1. Types: The <types> element defines the data types used in messages.

2. Message: Each <message> element defines input and output structures for operations. In the case of SOAP messages, these are the method parameters.

3. Port type: Each <portType> element defines a set of operations, whereby each <operation> element defines an operation and the input and output messages associated with it.

4. Binding: Each <binding> element maps the operations and messages to a protocol—HTTP—and data-encoding system: SOAP.

5. Service: Each <service> element defines a collection of related ports. The <port> child element specifies the location of an instance of the Web service.

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.

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.

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.