Web Services

Web services provide a standards-based implementation of an SOA. Web services define a suite of technologies and protocols that greatly simplify creating solutions based on a set of collaborating applications. Among the many technologies and principles associated with Web services, two features are key:

• A communication contract between the service provider and service consumer

• Interoperability

Communication Contract

A protocol stack is commonly used as a metaphor for communication between systems, the most well-known incarnation being the Open Systems Interconnect (OSI) layer model. A protocol stack describes communication as a set of layered services on both sides of the communication, with “higher” layers using the services of the lower layers. For example, an application protocol such as FTP or HTTP can use a TCP/IP transport protocol, which in turn uses an Ethernet card to move bits and bytes over the connection.

A communication contract defines all layers of this protocol stack in detail. As an example, the telephone system provides the hardware layer as voice communication in a certain frequency range (400 – 4000 Hz) and MTDF dialing. However, it does two participants little good if they use compatible telephony hardware but speak different languages. If you have ever received a phone call from a confused international caller or a fax machine, you know that the communication can fail even if the communication layer works beautifully.

The Web services contract works similarly. It needs to address two primary aspects of the communication:

• A common communications channel

• Data representation and message schemas

Common Communications Channel

In order for the applications to communicate, they must use compatible protocols. TCP/IP has become the default core communication protocol stack. Most, if not all, operating systems provide built-in TCP/IP functionality. Any application that uses a properly configured TCP/IP stack can communicate with other applications that use TCP/IP stacks on the same local network.

Figure 6.2 shows the communication channel between two applications with compatible protocol stacks.

Figure 6.2: Communication channel and TCP/IP protocol stacks

As an example, Application A may make a request for a Web service exposed by Application B. Application A’s protocol stack breaks down the application-level request into one or more low-level data packets to be streamed across the network. Application B’s protocol stack translates the packets back into an application-level call to the service. The service reply undergoes an equivalent process.

The ubiquity of the TCP/IP protocol stack makes it the ideal foundation for interoperable communications. However, TCP/IP is a low-level protocol and does not define the content of any messages between the applications. Like a phone line, it provides a channel for communication but does not specify a common language to be spoken.

HTTP is a protocol layered on top of TCP/IP that provides the most basic conventions for making a request to an external resource. The simplicity of HTTP has helped it gain wide support as the protocol used to transport information across the Internet and across corporate firewalls. Thus, HTTP has become both a blessing and a curse. Its universal use makes it ideal for routing messages, but its capability to permeate most corporate firewalls concerns many IT security administrators.

With the addition of HTTP, the resulting protocol stack now appears as shown in Figure 6.3.

Figure 6.3: Communication protocol stacks with addition of HTTP

Data Representation and Message Schemas

The second part of the communication contract deals with what is being passed across the communications channel, comparable to the language spoken across a telephone line. This part of the contract needs to define three things:

• The data representation format

• The message schema

• The binding of messages to services

Data Representation Format

If applications are to successfully communicate with each other, they must all agree to a common set of data definitions for data passed over the connection. The Web services protocol stack already constrains the data passed back and forth to be in a textual format. But what does that textual data represent? Does it represent a serialized object? An array of integers? Or an XML document?

There are basically two ways to provide information about what the data represents: provide an external description or use self-describing data.

An external description defines the schema of the data in some form external to the data itself. The interface definition languages (IDL) used by Distributed RPC, DCOM, or CORBA technologies are examples of languages designed to write external descriptions. This external approach to data description limits interoperability because all computers involved in the collaboration must have access to the external description.

Self-describing data includes an embedded description of the data with the data itself. Using this approach enhances interoperability because the data can be parsed without having to consult an external description of the data.

Web services use XML as the data representation format. XML provides the following advantages:

• It is text based and therefore compatible with the communication channel

• It is an industry standard with broad industry and user support

• It is self-describing

• It is interoperable

• XML parsers exist for virtually all platforms, and many development tools are available to ease the development of XML applications

Message Schema

The message is the fundamental unit of communication in Web services and therefore it is imperative that all collaborating parties have a precise understanding of the message contents.

The communication contract must specify all the request messages associated with a service and any associated response messages. Then the contents for each message must be specified. This task typically involves identifying the data elements of each message, specifying the data type of the elements, and specifying any constraints associated with the types or between types.

SOAP divides a message into two sections: an optional header and a mandatory body. The header contains information associated with the communication and services infrastructure. The body contains the business-oriented content of the message while the header contains metadata.

Message Binding

After the messages have been defined, they must be associated with a communication channel. In addition to HTTP, SOAP can work with other text-based communication protocols such as SMTP. As a result, a service may support more than one communication protocol.

Web services use Web Services Description Language (WSDL) to provide a detailed specification of all the messages supported by a service. In turn, WSDL uses the XML Schema Definition (XSD) standard to document the internal structure of each message and any constraints on any of the message elements.

WSDL groups messages into operations. An operation is the logical unit of interaction with a service, which is defined as a request message and any associated response messages.

Finally, WSDL binds operations to one or more protocols, such as HTTP and SMTP, and then groups these bound operation together in a service. In addition to specifying the operations associated with a service, the WSDL service specification also documents the communication channel-specific address of the service. For instance, the service specification would document the URL to identify a service that is exposed through SOAP over HTTP.

Interoperability

Interoperability was a major factor in the previous discussion of communication channels and message descriptions. Several other features of Web services significantly aid interoperability.

Open Standards

One of the key disadvantages of using a traditional approach to distributed communication is that applications are dependent on proprietary communication technology, protocols, and data formats.

Web services are entirely based on a set of widely-supported, platform-independent, open standards. As a result, virtually every major platform has one or more implementations of the Web services protocol stack. This significantly reduces the effort and cost associated with implementing and deploying solutions based on collaborating applications.

Service Repository

The final piece of the Web services puzzle is service discovery. How does a service consumer application find the services it needs to collaborate with? The answer is to provide a federated service repository that contains descriptions of the services and associate these descriptions with various metadata elements that are useful for identifying particular services. For instance, the service repository should return pointers to services based on several different criteria such as developing organization, hosting organization, industry type, and business process supported.

Using a service repository significantly reduces coupling between the service provider and service consumer. The reduction results from the consumer only needing a reference to the service, rather than hard-coding all the details needed to access the service within the service consumer. This allows the service provider to change many pieces of the communications contract without requiring any changes to the service consumer. The provider only needs to update the registry. Applications that make full use of the UDDI specification will automatically use the new settings the next time they access the service.

UDDI

The Universal Discovery, Description, and Integration (UDDI) specification solves the service discovery problem for Web services. Interoperability was one of the primary goals of UDDI, so it is not surprising that UDDI uses many of the technologies and protocols already discussed in this chapter.

At its core, UDDI is simply a repository containing links to WSDL service descriptions. UDDI defines several XML descriptions of various metadata that may be associated with a service. These descriptions include, information about the organization providing the service, the business process supported by the service, and the service type. Finally, UDDI exposes its functionality as a set of SOAP services.