This chapter is from the book

In Chapter 6 we established a series of composition and activity
management concepts, each with a different scope and purpose, but all somewhat
related within the context of composable SOA. Those initial concepts are complemented
by additional WS-* extensions that govern specific areas of the SOAP messaging
framework, the creation and exchange of metadata, and the introduction of message-level
security. (Figure 7.1 introduces the individual concepts and shows how they
typically inter-relate.)

As we explore the various extensions in this chapter, it becomes increasingly
clear that SOAP messaging is the lifeblood of contemporary service-oriented
architecture. It realizes not only the delivery of application data, but also
the composable nature of SOA. The innovation of SOAP headers accounts for almost
all of the features covered in Chapters 6 and 7.

To demonstrate common concepts, this chapter borrows terms provided by the
following current Web services specifications:

As with Chapter 6, we only explore concepts related to WS-* extensions in
this chapter. Language element descriptions and examples for the first five
specifications in the preceding list are provided in Chapter 17.

Markup code examples for WS-Eventing and the WS-Notification framework are
not provided. These two specifications provide different languages that cover
much of the same ground and are more relevant to the subject matter in this
book on a conceptual level.

In Plain English sections

This chapter also contains In Plain English sections for every primary concept
discussed. Note that these intentionally simplistic analogies continue where
they left off in Chapter 6.

How case studies are used:

Several of the examples in Chapter
6 are revisited here as we take a closer look at how interaction among specific
TLS Web services is affected by the new concepts introduced in this chapter.

7.1 Addressing

What addressing brings to SOAP messaging is much like what a waybill brings
to the shipping process. Regardless of which ports, warehouses, or delivery
stations a package passes through en route to its ultimate destination, with a
waybill attached to it, everyone it comes into contact with knows:

where it’s coming from

the address of where it’s supposed to go

the specific person at the address who is supposed to receive
it

where it should go if it can’t be delivered as planned

The WS-Addressing specification implements these addressing features (Figure
7.2) by providing two types of SOAP headers (explained shortly). Though
relatively simple in nature, these addressing extensions are integral to
SOA’s underlying messaging mechanics. Many other WS-* specifications
implicitly rely on the use of WS-Addressing.

For an overview of the WS-Addressing language, see the WS-Addressing
language basics section in Chapter 17.

In Plain English

As our car washing company grows, so do the administration duties. Every week
Chuck reviews the mail and takes care of necessary paperwork. This week he
receives two letters: one from our insurance company and the other from the tax
office.

The first letter includes our renewed insurance policy statement, along with
an invoice for another year of coverage. The "from" address on this
letter is simply the name and location of the insurance company’s head
office. The enclosed statement contains a letter written by our account
representative, outlining some of the changes in this year’s policy and
requesting that we mail our check directly to him. Chuck therefore encloses our
payment in an envelope with a "to" address that includes an
"attention" line stating that this letter should be delivered directly
to the account representative.

The next letter contains another bill. This time, it’s a tax statement
accompanied by a letter of instruction and two return envelopes. According to
the instructions, we are to use the first envelope (addressed to the A/R office)
to mail a check if we are paying the full amount owing. If we cannot make a full
payment, we need to use the second envelope (addressed to the collections
department) to send whatever funds we have.

These scenarios, in their own crude way, demonstrate the fundamental concepts
of endpoint references and message information headers, which are explained in
the following sections.

7.1.1 Endpoint references

Early on in this book we established that the loosely coupled nature of SOA
was implemented through the use of service descriptions. In other words, all
that is required for a service requestor to contact a service provider is the
provider’s WSDL definition. This document, among other things, supplies
the requestor with an address at which the provider can be contacted. What if,
though, the service requestor needs to send a message to a specific instance of
a service provider? In this case, the address provided by the WSDL is not
sufficient.

Traditional Web applications had different ways of managing and communicating
session identifiers. The most common approach was to append the identifier as a
query string parameter to the end of a URL. While easy to develop, this
technique resulted in application designs that lacked security and were
non-standardized.

The concept of addressing introduces the endpoint reference, an
extension used primarily to provide identifiers that pinpoint a particular
instance of a service (as well as supplementary service metadata). The endpoint
reference is expected to be almost always dynamically generated and can contain
a set of supplementary properties.

Figure 7.3 A SOAP
message containing a reference to the instance of the service that sent it.

An endpoint reference consists of the following parts:

address—The URL of the Web service.

reference properties—A set of property values associated
with the Web service instance. (In our previous In Plain English
example, the "attention" line used in the first scenario is
representative of the reference ID property.)

reference parameters—A set of parameter values that can
be used to further interact with a specific service instance.

service port type and port type—Specific service
interface information giving the recipient of the message the exact location of
service description details required for a reply.

policy—A WS-Policy compliant policy that provides rules
and behavior information relevant to the current service interaction (policies
are explained later in this chapter).

Additional parts exist, which mostly identify corresponding WSDL information.
With the exception of the address, all parts are optional.

7.1.2 Message information headers

In the previous chapter we covered the various primitive message exchange
patterns of which complex activities are comprised. These MEPs have predictable
characteristics that can ease the manner in which Web services are designed but
also can limit the service interaction scenarios within which they participate.

In sophisticated service-oriented solutions, services often require the
flexibility to break a fixed pattern. For example, they may want to dynamically
determine the nature of a message exchange. The extensions provided by
WS-Addressing were broadened to include new SOAP headers that establish message
exchange-related characteristics within the messages themselves. This collection
of standardized headers is known as the message information (or
MI) headers (Figure
7.4).

Figure 7.4 A SOAP
message with message information headers specifying exactly how the recipient
service should respond to its arrival.

The MI headers provided by WS-Addressing include:

destination—The address to which the message is being
sent.

source endpoint—An endpoint reference to the Web service
that generated the message.

reply endpoint—This important header allows a message to
dictate to which address its reply should be sent.

fault endpoint—Further extending the messaging
flexibility is this header, which gives a message the ability to set the address
to which a fault notification should be sent.

message id—A value that uniquely identifies the message
or the retransmission of the message (this header is required when using the
reply endpoint header).

relationship—Most commonly used in request-response
scenarios, this header contains the message id of the related message to which a
message is replying (this header also is required within the reply
message).

(Also of interest is the fact that the WS-Addressing specification provides
an anonymous URI that allows MI headers to intentionally contain an invalid
address.)

Outfitting a SOAP message with these headers further increases its position
as an independent unit of communication. Using MI headers, SOAP messages now can
contain detailed information that defines the messaging interaction behavior of
the service in receipt of the message. The net result is standardized support
for the use of unpredictable and highly flexible message exchanges, dynamically
creatable and therefore adaptive and responsive to runtime conditions.

7.1.3 Addressing and transport protocol independence

Historically, many of the details pertaining to how a unit of communication
arrives at point B after it is transmitted from point A was left up to the
individual protocols that controlled the transportation layer. While this level
of technology-based abstraction is convenient for developers, it also leads to
restrictions as to how communication between two units of processing logic can
be achieved.

The standardized SOAP headers introduced by WS-Addressing remove much of this
protocol-level dependence. These headers put the SOAP message itself in charge
of its own destiny by further increasing its ability to act as a standalone unit
of communication.

7.1.4 Addressing and SOA

Addressing achieves an important low-level, transport standardization within
SOA, further promoting open standards that establish a level of transport
technology independence (Figure
7.5). The use of endpoint references and MI
headers deepens the intelligence embedded into SOAP messages, increasing
message-level autonomy.

Empowering a message with the ability to self-direct its payload, as well as
the ability to dictate how services receiving the message should behave,
significantly increases the potential for Web services to be intrinsically
interoperable. It places the task-specific logic into the message and promotes a
highly reusable and generic service design standard that also facilitates the
discovery of additional service metadata.

Further, the use of MI headers increases the range of interaction logic
within complex activities and even encourages this logic to be dynamically
determined. This, however, can be a double-edged sword. Even though MI headers
can further increase the sophistication of service-oriented applications, their
misuse (or overuse) can lead to some wildly creative and complex service
activities.

Finally, by supporting the referencing of service instances, SOAs can be
scaled in a standardized manner, without the need to resort to custom or
proprietary application designs (scalability is a key QoS contribution). Having
stated that, it should be pointed out that by providing functionality that
enables communication with service instances, WS-Addressing indirectly supports
the creation of stateful services. This runs contrary to the common
service-orientation principle of statelessness (as explained in Chapter 8) and
emphasizes the need for this feature to be applied in moderation.

Case Study

In the previous chapter we provided several examples that explained the steps
behind the vendor invoice submission process. One of these steps required that,
upon receiving an invoice from a vendor, the TLS Accounts Payable Service
interacts with the TLS Vendor Profile Service to have the received invoice
validated against vendor account information already on file.

Due to the volume of invoice submissions received by TLS, there can be, at
any given time, multiple active instances of the Accounts Payable Service.
Therefore, as part of the message issued by the Accounts Payable Service to the
Vendor Profile Service, a SOAP header providing a reference id is included. This
identifier represents the current instance of the Accounts Payable Service and
is used by the Vendor Profile Service to locate this instance when it is ready
to respond with the validation information (Figure
7.6).

Figure 7.6 Separate
service instances communicating using endpoint references and MI headers across
two pools of Web services within TLS.

SUMMARY OF KEY POINTS

Addressing extensions, as implemented by the WS-Addressing
specification, introduce two important concepts: endpoint references and message
information headers.

Endpoint references provide a standardized means of identifying a
specific instance of a Web service.