Messaging (with SOAP)

Because all communication between services is message-based, the messaging framework chosen must be standardized so that all services, regardless of origin, use the same format and transport protocol. Additionally, within SOAs, so much emphasis is placed on a message-centric application design that an increasing amount of business and application logic is embedded into messages. In fact, the receipt of a message by a service is the most fundamental action within SOA and the sole action that initiates service-oriented automation. This further demands that the messaging framework be extremely flexible and highly extensible.

The SOAP specification was chosen to meet all of these requirements and has since been universally accepted as the standard transport protocol for messages processed by Web services. Since its initial release, SOAP has been further revised to accommodate more sophisticated message structures in support of enterprise distributed applications and enterprise SOAs.

Here we examine the high-level concepts behind the SOAP messaging framework. We begin with a look at how SOAP messages are structured, and then move on to an overview of SOAP's underlying node network. We conclude this section and this chapter with a brief explanation of message paths as they relate to SOAP messaging and other concepts we covered previously.

Note

The following is not a tutorial on the SOAP language; only concepts and terms are discussed in this section. The SOAP language is introduced in the SOAP language basics section in Chapter 13.

In Plain English

Now that we've completed the required application form, we need to figure out how to get this information to the agency. Because Bob only knew the name of the company, we need to look up its mailing address in the phone book. We add the mailing address to an envelope, place the application form inside, and throw it in a mailbox.

A phone book is commonly compared to a service registry, and a mailing address is the equivalent of a WSDL endpoint (or port). An envelope represents a standardized medium for transporting mailmuch like SOAP represents a standardized format for transporting messages.

When we are ready to let our letter go, we place it in a mailbox, the same way service requestors hand over SOAP messages to SOAP nodes to perform the actual transmission.

Finally, the route traveled by the letter from us to the Reconnect agency is much like the message path a SOAP message follows from service requestor to service provider.

 

5.4.1. Messages

Even though it was originally named the Simple Object Access Protocol, the SOAP specification's main purpose is to define a standard message format. The structure of this format is quite simple, but its ability to be extended and customized has positioned SOAP messaging as the driving force behind many of the most significant features of contemporary SOAs. This section takes a closer look at the details of the SOAP message format.

Note

As of version 1.2 of the SOAP specification, the word "SOAP" is no longer an acronym that stands for "Simple Object Access Protocol." It is now considered a standalone term.

 

Envelope, header, and body

Every SOAP message is packaged into a container known as an envelope. Much like the metaphor this conjures up, the envelope is responsible for housing all parts of the message (Figure 5.21).

Figure 5.21. The basic structure of a SOAP message.

Each message can contain a header, an area dedicated to hosting meta information. In most service-oriented solutions, this header section is a vital part of the overall architecture, and though optional, it is rarely omitted. Its importance relates to the use of header blocks through which numerous extensions can be implemented (as described next).

The actual message contents are hosted by the message body, which typically consists of XML formatted data. The contents of a message body are often referred to as the message payload.

Header blocks

A primary characteristic of the SOAP communications framework used by SOAs is an emphasis on creating messages that are as intelligence-heavy and self-sufficient as possible. This results in SOAP messages achieving a level of independence that increases the robustness and extensibility of this messaging frameworkqualities that are extremely important when relying on communication within the loosely coupled environment that Web services require.

Message independence is implemented through the use of header blocks, packets of supplementary meta information stored in the envelope's header area. Header blocks outfit a message with all of the information required for any services with which the message comes in contact to process and route the message in accordance with its accompanying rules, instructions, and properties. What this means is that through the use of header blocks, SOAP messages are capable of containing a large variety of supplemental information related to the delivery and processing of message contents.

This alleviates services from having to store and maintain message-specific logic. It further reinforces the characteristics of contemporary SOA related to fostering reuse, interoperability, and composability. Web services can be designed with generic processing functionality driven by various types of meta information the service locates in the header blocks of the messages it receives.

The use of header blocks has elevated the Web services framework to an extensible and composable enterprise-level computing platform. Practically all WS-* extensions are implemented using header blocks. (Chapter 17 provides various examples of what SOAP headers look like.)

Examples of the types of features a message can be outfitted with using header blocks include:

• processing instructions that may be executed by service intermediaries or the ultimate receiver
• routing or workflow information associated with the message
• security measures implemented in the message
• reliability rules related to the delivery of the message
• context and transaction management information
• correlation information (typically an identifier used to associate a request message with a response message)

These and many other features are available, and the selection is continually growing. Because header blocks can be based on the use of different supplementary extensions, SOAP allows the recognition and processing of header blocks to be marked as optional. This way messages can be safely outfitted with header blocks that implement non-critical features from newer extensions.

Note

Processing instructions provided in SOAP header blocks are different from the processing instructions natively supported by the XML language.

Case Study

Invoices sent via SOAP messages to TLS are required to contain a number of standard header blocks for them to be accepted and processed by the TLS Accounts Payable Service.

Specifically, the required header blocks include:

• A correlation identifier that conforms to a standard format and is further extended with a value derived from the date and time of the message transmission. The correlation identifier therefore relates the original submission to the eventual response.
• Organization-level security credentials used for authentication purposes. Each vendor has a security account with the TLS B2B system, and the assigned credentials are required with every message transmission.

The Accounts Payable Service expects these pieces of meta information, and the gathered rules and instructions shape its subsequent processing of the message contents.

 

Message styles

The SOAP specification was originally designed to replace proprietary RPC protocols by allowing calls between distributed components to be serialized into XML documents, transported, and then deserialized into the native component format upon arrival. As a result, much in the original version of this specification centered around the structuring of messages to accommodate RPC data.

This RPC-style message runs contrary to the emphasis SOA places on independent, intelligence-heavy messages. SOA relies on document-style messages to enable larger payloads, coarser interface operations, and reduced message transmission volumes between services.

Note

Don't confuse document-style SOAP messages with document-centric XML documents. The latter term generally refers to published documents represented by XML and is used to distinguish these types of XML documents from those that contain application data (which are typically referred to as data-centric XML documents).

Case Study

Traditionally, the submission of an invoice involved a number of interactions between RailCo and its customer, including:

• The generation and mailing of the invoice document.
• The generation and mailing of an account statement, showing all currently outstanding amounts owed by the customer.
• The generation and mailing of a quantity discount reminder, explaining RailCo's volume pricing policy, and showing how close the customer is to reaching a quantity discount based on parts ordered to date.

When forced to submit invoices electronically to TLS via the Invoice Submission Service, all three of these documents needed to be included in the same message. As a result, a single document-style message used by RailCo is capable of providing an invoice, an account statement, and volume discount pricing formulas (Figure 5.22).

Figure 5.22. The RailCo Invoice Submission Service packaging the contents of three documents into one SOAP message.

 

Attachments

To facilitate requirements for the delivery of data not so easily formatted into an XML document, the use of SOAP attachment technologies exist. Each provides a different encoding mechanism used to bundle data in its native format with a SOAP message. SOAP attachments are commonly employed to transport binary files, such as images.

Case Study

TLS accounting policy requires that all issued purchase orders in excess of $100,000 require the signature of a senior manager. Further, these purchase orders are not allowed to be issued in the standard electronic format, as the signature is required to be an ever-present part of the document. To accommodate this requirement, the Purchase Order Service was designed with an alternative operation.

The accounting system currently used by TLS offers the ability to scan any accounting-related documents. The scanned images are archived on a separate server and linked to the corresponding accounting records via the archive image path. When PO cost totals exceed the $100,000 limit, a custom-developed extension to the accounting system invokes the alternative Purchase Order Service operation and passes it a copy of the signed PO document image. The service, in turn, generates a SOAP message in which the PO document image exists as a SOAP attachment.

 

Faults

Finally, SOAP messages offer the ability to add exception handling logic by providing an optional fault section that can reside within the body area. The typical use for this section is to store a simple message used to deliver error condition information when an exception occurs.

Case Study

The before mentioned SOAP message containing a SOAP attachment is also outfitted with a fault area housing exception information relating specifically to the attached data. Should the recipient of the SOAP message be unable to properly process the attachment or should the attachment encounter delivery problems, standard fault codes and descriptions are used to generate a response message that is returned to TLS.

 

5.4.2. Nodes

Although Web services exist as self-contained units of processing logic, they are reliant upon a physical communications infrastructure to process and manage the exchange of SOAP messages. Every major platform has its own implementation of a SOAP communications server, and as a result each vendor has labeled its own variation of this piece of software differently. In abstract, the programs that services use to transmit and receive SOAP messages are referred to as SOAP nodes (Figure 5.23).

Figure 5.23. A SOAP node transmitting a SOAP message received by the service logic.

Regardless of how they are implemented, SOAP nodes must conform to the processing standard set forth in the versions of the SOAP specification they support. This critical characteristic is what preserves the vendor-neutral communications framework upon which SOA is based. It is what guarantees that a SOAP message sent by the SOAP node from service A can be received and processed by a SOAP node (supporting the same version of the SOAP standard) from any other service.

Node types

As with the services that use them, the underlying SOAP nodes are given labels that identify their type, depending on what form of processing they are involved with in a given message processing scenario.

Below is a list of type labels associated with SOAP nodes (in accordance with the standard SOAP Processing Model). You'll notice that these names are very similar to the Web service roles we discussed at the beginning of this chapter. The SOAP specification has a different use for the term "role" and instead refers to these SOAP types or labels as concepts.

• SOAP sendera SOAP node that transmits a message
• SOAP receivera SOAP node that receives a message
• SOAP intermediarya SOAP node that receives and transmits a message, and optionally processes the message prior to transmission
• initial SOAP senderthe first SOAP node to transmit a message
• ultimate SOAP receiverthe last SOAP node to receive a message

Figure 5.27 illustrates how SOAP nodes transition through these roles.

Case Study

When the RailCo Invoice Submission Service sends a SOAP message containing an invoice, the underlying SOAP server software (representing the initial SOAP sender node) executes the transmission of the SOAP message via HTTP.

Prior to the TLS Accounts Payable Service actually receiving the invoice message, the TLS SOAP server or listener (representing the ultimate SOAP receiver node) receives the message first (Figure 5.24).

Figure 5.24. The positioning of SOAP nodes within a message transmission between RailCo and TLS.

 

SOAP intermediaries

The same way service intermediaries transition through service provider and service requestor roles, SOAP intermediary nodes move through SOAP receiver and SOAP sender types when processing a message (Figure 5.25).

Figure 5.25. Different types of SOAP nodes involved with processing a message.

SOAP nodes acting as intermediaries can be classified as forwarding or active. When a SOAP node acts as a forwarding intermediary, it is responsible for relaying the contents of a message to a subsequent SOAP node. In doing so, the intermediary will often process and alter header block information relating to the forwarding logic it is executing. For example, it will remove a header block it has processed, as well as any header blocks that cannot be relayed any further.

Active intermediary nodes are distinguished by the type of processing they perform above and beyond forwarding-related functions. An active intermediary is not required to limit its processing logic to the rules and instructions provided in the header blocks of a message it receives. It can alter existing header blocks, insert new ones, and execute a variety of supporting actions.

5.4.3. Message paths

A message path refers to the route taken by a message from when it is first sent until it arrives at its ultimate destination. Therefore, a message path consists of at least one initial sender, one ultimate receiver, and zero or more intermediaries (Figure 5.26). Mapping and modeling message paths becomes an increasingly important exercise in SOAs, as the amount of intermediary services tends to grow along with the expansion of a service-oriented solution. Design considerations relating to the path a message is required to travel often center around performance, security, context management, and reliable messaging concerns.

Figure 5.26. A message path consisting of three Web services.

Note also that a message path is sometimes not predetermined. The use of header blocks processed by intermediaries can dynamically determine the path of a message. This may be the result of routing logic, workflow logic, or environmental conditions (Figure 5.27).

Figure 5.27. A message path determined at runtime.

When used within the context of SOAP nodes, this term is qualified and therefore referred to as a SOAP message path. While a message path in abstract can be purely logical, the SOAP node perspective is always focused on the actual physical transport route. A SOAP message path is comprised of a series of SOAP nodes, beginning with the initial SOAP sender and ending with the ultimate SOAP receiver. Every node refers to a physical installation of SOAP software, each with its own physical address.

Case Study

Revisiting our invoice submission scenario one last time, we can establish both logical and physical views of the path along which the invoice SOAP message travels.

From a logical perspective, the message path is always the same. The RailCo Invoice Submission Service requestor acts as the initial sender and is therefore the starting point of the path. The first service provider the message encounters is the TLS Load Balancing intermediary. This service then becomes the next service requestor and forwards the message to the Accounts Payable Service provider. As the last service provider along the path, this Web service becomes the ultimate receiver. This establishes a logical message path consisting of three services.

The corresponding SOAP message path is not as predictable. Because the Load Balancing Service will only decide which physical server to route a message to when it actually receives and processes the message, the ultimate SOAP receiver is not determined until runtime.

SUMMARY OF KEY POINTS

• The SOAP messaging framework fulfills the need for SOA's reliance on "independent units of communication," by supporting the creation of intelligence-heavy, document-style, and highly extensible messages.
• SOAP messaging establishes a standard message structure that includes an extensible header section used by numerous WS-* extensions to implement enterprise-level features.
• The SOAP node view of the Web services framework abstracts the physical communications framework, which consists of a series of SOAP servers.