This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Messaging Services
The messaging services component of the framework contains the most fundamental Web services specifications and technologies, including eXtensible Markup Language (XML), SOAP, and WS-Addressing. Collectively, these specifications form the basis of interoperable messaging between Web services. XML (discussed in Chapter 2) provides the interoperable format to describe message content between Web services and is the basic language in which the Web services specifications are defined.
3.3.1 SOAP
SOAP, one of the significant underpinnings of Web services, provides a simple and relatively lightweight mechanism for exchanging structured and typed information between services. SOAP is designed to reduce the cost and complexity of integrating applications that are built on different platforms. SOAP has undergone revisions since its introduction, and the W3C has standardized the most recent version, SOAP 1.2.
SOAP defines an extensible enveloping mechanism that scopes and structures the message exchange between Web services. A SOAP message is an XML document that contains three distinct elements: an envelope, a header, and a body. The envelope is the root element of the SOAP message. It contains an optional header element and a mandatory body element. The header element is a generic mechanism for adding extensible features to SOAP. Each child element of header is called a header block. SOAP defines several well-known attributes that you can use to indicate who should deal with a header block and whether processing of it is optional or mandatory. The body element is always the last child element of the envelope, and it is the container for the payload—the actual message content that is intended for the ultimate recipient who will process it. SOAP defines no built-in header blocks and only one payload, which is the Fault element used for reporting errors.
SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. You can defer selection of the appropriate mechanism until runtime, which gives Web service applications or support infrastructure the flexibility to determine the appropriate transport as the message is sent. In addition, the underlying transport might change as the message is routed between nodes. Again, the mechanism that is selected for each hop can vary as required. Despite this general transport independence, most first-generation Web services communicate using HTTP, because it is one of the primary bindings included within the SOAP specification.
SOAP messages are transmitted one way from sender to receiver. However, multiple one-way messages can be combined into more sophisticated message exchange patterns. For instance, a popular pattern is a synchronous request/response pair of messages. The messaging flexibility that SOAP provides allows services to communicate using a variety of message exchange patterns, to satisfy the wide range of distributed applications. Several patterns have proven particularly helpful in distributed systems. The use of remote procedure calls, for example, popularized the synchronous request/response message exchange pattern. When message delivery latencies are uncontrolled, asynchronous messaging is needed. When the asynchronous request/response pattern is used, explicit message correlation becomes mandatory.
Messages can be routed based on the content of the headers and the data inside the message body. You can use tools developed for the XML data model to inspect and construct complete messages. Note that such benefits were not available in architectures such as DCOM, CORBA, and Java Remote Method Invocation (RMI), where protocol headers were infrastructural details that were opaque to the application. Any software agent that sends or receives messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and the ultimate receiver is called an intermediary. Intermediaries model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.
To allow parts of the message path to be identified, each node participates in one or more roles. The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node, other than the sender, belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays, which is typically the application, or in some cases, infrastructure that is performing work on behalf of the application. The body of a SOAP envelope is always targeted at the UltimateReceiver. In contrast, SOAP headers might be targeted at intermediaries or the UltimateReceiver
SOAP is discussed in detail in Chapter 4, "SOAP."
3.3.2 WS-Addressing
WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with message exchange. WS-Addressing decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web service message. This specification defines XML elements to identify Web services endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing defines two interoperable constructs that convey information that transport protocols and messaging systems typically provide. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. These two constructs are endpoint references and message information headers.
A Web services endpoint is a referenceable entity, processor, or resource in which Web services messages can be targeted. Endpoint references convey the information needed to identify/reference a Web services endpoint, and you can use them in several different ways. Endpoint references are suitable for conveying the information needed to access a Web services endpoint, but they also provide addresses for individual messages that are sent to and from Web services. To deal with this previous usage case, the WS-Addressing specification defines a family of message information headers that allows uniform addressing of messages independent of underlying transport. These message information headers convey end-to-end message characteristics, including addressing for source and destination endpoints and message identity.
Both of these constructs are designed to be extensible and reusable so that other specifications can build on and leverage endpoint references and message information headers. WS-Addressing is covered in detail in Chapter 5, "WS-Addressing."