Web Services Interoperability Stacks

An alphabet soup of technologies is swimming around the Web services space. We have XML, SOAP, WSDL, UDDI, WSEL, WSFL, and more. How can anyone make sense of what these technologies are and how they fit together? Well, that is one of the purposes of this book.

To help put a framework around these technologies, we refer to a trio of Web services interoperability stacks, first proposed to the W3C by IBM and Microsoft in March 2001 (http://www.w3.org/2001/03/WSWS-popa/paper51). This proposal factored Web services technologies into three stacks:

• The wire stack

• The description stack

• The discovery stack

The contents of the stacks presented in this book reflect a different factoring than originally proposed to the W3C, due in part to the additional standards efforts that have come into play since March 2001.

The Wire Stack

Figure 1.2 shows the wire stack as we define it.

The wire stack represents the technologies that determine how a message is sent from the service requestor to the service provider. The base of the wire stack is a network protocol. Web services can be based on a variety of standard, Internet wire protocols such as HTTP or HTTPS, SMTP, FTP, and so on, as well as sophisticated enterprise-level protocols such as RMI/IIOP and MQSeries.

For data encoding, Web services use XML. In addition, non-XML content can be referenced from a Web service invocation message, allowing full flexibility in the kinds of data used in the message. For data specification, Web services use XML Schema. This includes both custom schemas in the case of XML messaging or schemas conforming to a set of pre-defined rules, such as the SOAP encoding rules discussed in Chapter 3.

Built on top of the networking protocol and data-encoding layers are the XML messaging layers. For XML messaging, Web services use SOAP in all its data encoding, interaction style, and protocol binding variations. SOAP is used as a simple approach to wrapper an XML message in an envelope. The result is a solid, standards-based foundation for Web services.

Conceptually layered on top of the SOAP enveloping mechanism is a mechanism for envelope extensions called SOAP headers . With SOAP headers, orthogonal extensions such as a digital signature can be associated with the body of the message contained within the SOAP envelope. Chapter 3 will give details on the SOAP enveloping mechanism and the SOAP header facility.

The layers of this stack are well defined, either as standard networking protocols or as the SOAP specification itself. This stack is the most accepted and most widely deployed set of technologies for Web services.

At right in Figure 1.2 are three vertical columns representing associated technologies that impact multiple levels of the wire stack. Security, for example, can appear at each level—SSL at the network protocol level and digital signatures at the envelope extensions level, for instance. It is doubtful there will ever be a single standard that fits all aspects of Web services security needs. Chapter 5 goes into more detail on the current Web services–related security technologies like XML digital signatures and XML cryptography. Other vertical towers listed include Quality of Service and Manageability. These are just a handful of facets of Web services that can appear at several levels of the wire stack. There is no well-accepted standard for these facets, but work is underway in these areas.

The Description Stack

The wire stack is only where the capabilities of Web services begin. Even the simplest example of Web service use shows the need for a higher level of interoperability.

Consider the following situation (we'll see this example in greater detail in Chapter 3). A company has provided an inventory checking service, allowing customers to determine whether a particular number of items are in stock for a given product code (as represented as a stock keeping unit [SKU]). The Web service takes as parameters a string representing the SKU and an integer representing the number of units needed. If the company has on hand the requested number of units, the Web service responds with a Boolean true value; otherwise, the response is a Boolean false.

From a pure SOAP perspective, the interaction with this Web service is trivial. However, things get much more complicated when we consider how much common understanding must exist between the service requestor and the service provider. For the interaction to succeed, at a minimum, the service requestor needs to know the following:

• The address of the Web service.

• It should make requests and receive responses over HTTP.

• It should use SOAP 1.1.

• Requests and responses should use the SOAP data encoding.

• Requests will be RPC requests containing as parameters a string SKU and an integer indicating the desired quantity.

• Responses will be RPC responses containing a Boolean indicating the inventory check outcome.

Throw in security, payments, error handling, and other capabilities required to build enterprise-grade Web services, and the need for shared knowledge expands even further…. How can the service requestor acquire this information? Well, traditionally Web services have advertised their capabilities in some human readable form. Developers have read the description of these capabilities and configured user applications to be able to communicate with particular Web services.

While this approach works in principle, it is not scalable for many reasons:

• It requires costly (in terms of both time and money) manual configuration by highly skilled, and therefore scarce, personnel.

• It is error prone because it does not utilize formalized service specifications.

• It precludes automatic discovery and engagement of Web services; a priori knowledge is required for configuration of the user application.

• No built-in mechanism exists for change notifications and/or failure recovery; every time a Web service evolves, there is a risk that existing user applications will fail.

These are some of the reasons why industry leaders are developing the standards described in a service description stack. Figure 1.3 shows the service description stack.

Key to the entire service-oriented architecture approach is the service description itself. Many aspects of a Web service need to be communicated, and therefore the description stack has multiple levels. The focus on service description is to communicate those aspects of a service that might be important to the service requestor. Chapter 6 goes into detail on each of the technologies used for service description.

In Web services, XML is the basis of service description. XML schema is the base data type mechanism in the service description and all of the service description technologies in the stack are expressed using XML. Much of the power of Web services is derived from the power of XML.

The next two levels of the stack, service implementation and service interface, are described using the Web Services Description Language (WSDL). WSDL is a note to the W3C, and there is active work to refine this language into a standard. WSDL is the interface definition language for Web services; it is the key to understanding Web services. With WSDL, a developer describes the set of operations supported by a Web service, including the kinds of objects that are expected as input and output of the operations, the various bindings to concrete network and data encoding schemes. This level constitutes the core definition of the service's interface. The service implementation defines the network address where the service itself can be invoked. WSDL allows for automatic code-generation of Web service clients based on this information.

But IDL is not enough for Web services. Other aspects of the Web service could affect whether a service requestor would choose to bind to a Web service. For example, if two different service providers host implementations of the same service interface, perhaps a stock quote service, then from the IDL perspective, the services are almost indistinguishable: The network address is the only difference. However, the service providers might differ widely in their privacy policy, cost to use, timeliness of response, and so on. These non-operational characteristics might be critical to the service requestor. The role of the endpoint definition is to layer on top of the WSDL description information about characteristics of the Web service that are impacted by its implementation environment. Work in this area is at its very beginnings. The notion of a Web Services Endpoint Language (WSEL) has only been hinted at publicly. Other examples of this sort of description include the ebXML Collaboration-Protocol Profile and Agreement Specification (CPP).

At the top of the service description stack is the elusive promise of seamless, automatic service integration: the service orchestration layer. With service orchestration , the developer describes how a collection of Web services is combined to produce a more sophisticated Web service. For example, you would use service orchestration to model how a purchase order submission Web service could be combined with a notification service and a returns-processing service to produce a richer overall purchasing Web service. At this level, several alternative approaches exist. IBM has proposed the Web Services Flow Language, and Microsoft has Xlang. A single standard has not emerged in this space.

The orchestration of Web services poses significant challenges from both a technical and a business perspective. On the technical side, seamless service integration requires a significant technological foundation. Most important is the description of service behavior, defined by the rules for sequencing operation invocations and for sending and receiving messages. Next is the problem of composing services into process-based interactions. The problem is made harder by the requirement that some composition bindings must happen at runtime. Without this capability, it is difficult to map the technology to well-established business processes such as representation, referral, and brokering. On the business side, the problems are no less significant. From a business perspective, service integration is a workflow problem and as such could introduce dependencies on aspects of companies' core business models. Particularly difficult in this perspective is potentially the most valuable type of service integration—the one that spans enterprise boundaries.

The Discovery Stack

Given the ability to describe Web services, we are better off than we were, but we still have solved only part of the Web service integration problem. Service descriptions tell us how to bind to Web services, but how did the service requestor get the service description in the first place? Clearly, we need some form of a Web service discovery mechanism. The requirement here is for a directory or search engine for Web services. Service providers will need a publication mechanism so that they can provide information about the Web services they offer and make changes as their Web services evolve. Service requestors will need well-defined find APIs. This is the SOA service registry role we described earlier.

Figure 1.4 shows the third interoperability stack, the discovery stack. The discovery stack organizes technologies associated with Web service discovery.

The first level of the stack represents a simple inspection level. Inspection is a technique of discovering the service description given that the details about the service (a service identifier or URL, for example) are already known. Once again, no single standard exists in this space. IBM has ADS and Microsoft has DISCO .

The directory level represents the capability of discovering Web services and business partners using a capabilities-based lookup. Unlike previous distributed computing techniques that relied on well known names as the basis for remote discovery of services, Web services can use find techniques based on the kind of service or service capabilities. The UDDI standard is the proposed technology for Web services directory.

Chapter 7 is dedicated to explaining service discovery in much more detail, and in particular reviewing the UDDI standard.

Putting the Interoperability Stacks Together

Does any given Web service require all of these technologies in order to be considered a Web service? Certainly not.

Looking at the wire stack, no single network protocol—not even HTTP—is a required part of a Web service; any number of networking protocols can be used. Some Web services don't even need to use a network protocol. Techniques such as the Web Services Invocation Framework (WSIF) (http://www.alphaworks.ibm.com/tech/wsif) discuss the possibility of a Web service being a simple Java method invocation, where the service requestor and service provider are in the same Java Virtual Machine. Moving up the stack, we can discover that even SOAP is not a necessary technology for Web services. It is possible that a component accessed through a simple HTTP POST can be considered a Web service. In these cases, the commonality that makes these components Web services is the use of WSDL to describe the service.

So, is a service description required in order for a component to be considered a Web service? Again, not necessarily. Many Web services, particularly older Web services developed when SOAP was first introduced, do not have a corresponding service description. These components are considered Web services, but it is worth noting that without a service description, the Web service cannot be a part of the publish, find, bind operations in a service-oriented architecture. As the WSDL standard is adopted, you will see fewer Web services provided that do not have a corresponding WSDL description. Many developers have concluded that a Web service is simply "anything that can be described using WSDL."

Does a Web service have to appear in a UDDI registry in order to be considered a Web service? Clearly not. Many Web services advertised on the Web do not appear in UDDI and do not support the ADS or DISCO simple service discovery conventions.

So you will agree that any given Web service doesn't need all of these technologies to be considered a Web service. But are any of these technologies found in each and every Web service? If you follow the arguments above, clearly not. Is SOAP required in all Web services? No. Is WSDL? No. UDDI? No. There is no single Web services technology whose use determines that a component is a Web service. For this reason, defining what is a Web service remains difficult.

In addition to writing great specifications, the Web services industry has been busy building software that makes the standards come to life and solve meaningful business problems. This book uses Apache Axis at the heart of our Web services examples. Axis is an advanced Web services engine with a highly scalable and extensible architecture. We will examine Axis in great depth in Chapter 4.

There are, however, other great Web services implementations from multiple vendors. Chapter 8 looks at the currently available best-of-breed Web services tooling, its capabilities and its interoperability record.

Interoperability is key for Web services. In the World Wide Web, does my browser care about which Web server you are running? No. The same thing is true in Web services. Any service requestor should be able to consume any standard (no custom extensions) Web service provided via any Web services engine. We might be some distance from this holy grail, but the industry is working hard at it because everyone knows this is the only way to make Web services (and dynamic application integration) successful.