Unit II: Web Services and Primitive SOA: The Web Service Framework – Services (as

Web Services) – Service descriptions (with WSDL) – Messaging (with SOAP).

Web Services and Primitive SOA

Contemporary SOA is intrinsically reliant on Web servicesso much so that Web services
concepts and technology used to actualize service-orientation have influenced and
contributed to a number of the common SOA characteristics we identified in Chapter 3. An
understanding of SOA therefore begins with a close look at the overall framework that has
been established by the first and second-generation Web services extensions.
We can categorize concepts provided to us by these specifications into the following two
groups:
o Basic concepts that relate to primitive SOA and core Web services standards (covered
in this chapter).
o Advanced concepts that extend the basic framework to support numerous
supplementary features that relate to specific contemporary SOA characteristics
(covered in Chapters 6 and 7).
This chapter kicks things off with an introductory overview of the concepts of the first-
generation Web services framework as related to the realization of primitive SOA
characteristics.

The Web services framework

A technology framework is a collection of things. It can include one or more architectures,
technologies, concepts, models, and even sub-frameworks. The framework established by
Web services is comprised of all of these parts.
Specifically, this framework is characterized by:
o an abstract (vendor-neutral) existence defined by standards organizations and
implemented by (proprietary) technology platforms
o core building blocks that include Web services, service descriptions, and messages
o a communications agreement centered around service descriptions based on WSDL
o a messaging framework comprised of SOAP technology and concepts
o a service description registration and discovery architecture sometimes realized
through UDDI
 o a well-defined architecture that supports messaging patterns and compositions
(covered in Chapter 6)
o a second generation of Web services extensions (also known as the WS-*
specifications) continually broadening its underlying feature-set (covered in Chapters
6 and 7)

Another recommended addition to this list is the WS-I Basic Profile (introduced in Chapter 4
and further explained in later chapters). It provides standards and best practices that govern
the usage of WSDL, SOAP, and UDDI features. Therefore, much of what the Web services
framework is comprised of can be standardized by the Basic Profile.

In its entirety this technology framework is conceptually in alignment with the principles of
service-orientation. To further explore this synergy, the next three sections are intentionally
labeled to mirror the three sub-sections from Chapter 3 in which we first defined the parts of
primitive SOA (Figure 5.1).
Figure 5.1. The structural relationship between sections in Chapters 3 and 5.
Services (as Web services)
We use the terms "Web services" and "services" interchangeably throughout this book.
Let's start with an overview of the most basic Web services design concepts. Fundamentally,
every Web service can be associated with:
o a temporary classification based on the roles it assumes during the runtime processing
of a message
o a permanent classification based on the application logic it provides and the roles it
assumes within a solution environment
We explore both of these design classifications in the following two sections:
o service roles (temporary classifications)
o service models (permanent classifications)

5.2.1. Service roles

A Web service is capable of assuming different roles, depending on the context within which
it is used. For example, a service can act as the initiator, relayer, or the recipient of a
message. A service is therefore not labeled exclusively as a client or server, but instead as a
unit of software capable of altering its role, depending on its processing responsibility in a
given scenario.
It is not uncommon for a Web service to change its role more than once within a given
business task. It is especially not uncommon for a Web service within an SOA to assume
different roles in different business tasks.
 Provided here are descriptions of the fundamental service roles.
 Service provider
The service provider role is assumed by a Web service under the following conditions:
o The Web service is invoked via an external source, such as a service requestor (Figure
5.2).
Figure 5.2. As the recipient of a request message, the Web service is classified as a
service provider.
 o The Web service provides a published service description offering information about
its features and behavior. (Service descriptions are explained later in this chapter.)
The service provider role is synonymous with the server role in the classic client-server
architecture. Depending on the type of message exchange used when invoking a service
provider, the service provider may reply to a request message with a response message.
(Types of message exchanges are categorized as "message exchange patterns," which are
explained in the next chapter.)
The term "service provider" also is used to identify the organization (or individual)
responsible for actually providing the Web service. To help distinguish the service role from
the service's actual provider, the following, more qualified terms are sometimes used:
o service provider entity (the organization or individual providing the Web service)
o service provider agent (the Web service itself, acting as an agent on behalf of its
owner)
It is, however, most common to simply refer to the service being invoked as the service
provider.

Service requestor
Any unit of processing logic capable of issuing a request message that can be understood by
the service provider is classified as a service requestor. A Web service is always a service
provider but also can act as a service requestor.
A Web service takes on the service requestor role under the following circumstances:
o The Web service invokes a service provider by sending it a message (Figure 5.3).
Figure 5.3. The sender of the request message is classified as a service requestor.
 o The Web service searches for and assesses the most suitable service provider by
studying available service descriptions. (Service descriptions and service registries are
covered in the Service descriptions (with WSDL) section.)
The service requestor is the natural counterpart to the service provider, comparable to the
client in a typical client-server environment. It is important to note that a service provider is
not acting as a service requestor when it sends a message in response to a request message. A
service requestor is best viewed as a software program that initiates a conversation with a
service provider.

As with "service provider," this term is subject to some ambiguity. A service requestor can
represent both the Web service itself as well as the Web service owner. Therefore, the
following extended terms are available (but not really used that often):
o service requestor entity (the organization or individual requesting the Web service)
o service requestor agent (the Web service itself, acting as an agent on behalf of its
owner)

Intermediaries
The communications framework established by Web services contrasts the predictable nature
of traditional point-to-point communications channels. Though less flexible and less scalable,
point-to-point communication was a great deal easier to design. Web services communication
is based on the use of messaging paths, which can best be described as point-to-* paths. This
is because once a service provider submits a message, it can be processed by multiple
intermediate routing and processing agents before it arrives at its ultimate destination.
(Message paths are explained at the end of this chapter.)

Web services and service agents that route and process a message after it is initially sent and
before it arrives at its ultimate destination are referred to as intermediaries or intermediary
services. Because an intermediary receives and submits messages, it always transitions
through service provider and service requestor roles (Figure 5.5).

Figure 5.5. The intermediary service transitions through service provider and service
requestor roles while processing a message.

There are two types of intermediaries. The first, known as a passive intermediary, is typically
responsible for routing messages to a subsequent location (Figure 5.6). It may use
information in the SOAP message header to determine the routing path, or it may employ
native routing logic to achieve some level of load balancing. Either way, what makes this
type of intermediary passive is that it does not modify the message.
Figure 5.6. A passive intermediary service processing a message without altering its contents.

Like passive intermediary services, active intermediaries also route messages to a forwarding
destination. Prior to transmitting a message, however, these services actively process and
alter the message contents (Figure 5.7). Typically, active intermediaries will look for
particular SOAP header blocks and perform some action in response to the information they
find there. They almost always alter data in header blocks and may insert or even delete
header blocks entirely. (Header blocks are explained later in this chapter.)
Figure 5.7. An active intermediary service.

Initial sender and ultimate receiver

Initial senders are simply service requestors that initiate the transmission of a message.
Therefore, the initial sender is always the first Web service in a message path. The
counterpart to this role is the ultimate receiver. This label identifies service providers that
exist as the last Web service along a message's path (Figure 5.8).
Figure 5.8. Web services acting as initial sender and ultimate receiver.

Note that intermediary services can never be initial senders or ultimate receivers within the
scope of a service activity.

Service compositions
As the name suggests, this particular term does not apply to a single Web service, but to a
composite relationship between a collection of services. Any service can enlist one or more
additional services to complete a given task. Further, any of the enlisted services can call
other services to complete a given sub-task. Therefore, each service that participates in a
composition assumes an individual role of service composition member (Figure 5.10).
Figure 5.10. A service composition consisting of four members.
Typically, Web services need to be designed with service composition in mind to be effective
composition members. Service-orientation principles place an emphasis on composability,
allowing some Web services to be designed in such a manner that they can be pulled into
future service compositions without a foreknowledge of how they will be utilized.
The concept of service composability is very important to service-oriented environments (and
is explained as a service-orientation principle in Chapter 8). In fact, service composition is
frequently governed by WS-* composition extensions, such as WS-BPEL and WS-CDL,
which introduce the related concepts of orchestration and choreography, respectively (as
explained in Chapter 6).

5.2.2. Service models

The roles we've explored so far are agnostic to the nature of the functionality being provided
by the Web service. They are generic states that a service can enter within a generic context.
The manner in which services are being utilized in the real world, though, has led to a
classification based on the nature of the application logic they provide, as well as their
business-related roles within the overall solution. These classifications are known as service
models.

The sections that follow describe the basic set of common service models. Additional service
models are introduced in later chapters. Appendix B further provides a reference table listing
all service models covered in this book. It is important to note that a service can and
frequently does belong to more than one service model.
Business service model
Within an SOA, the business service represents the most fundamental building block. It
encapsulates a distinct set of business logic within a well-defined functional boundary. It is
fully autonomous but still not limited to executing in isolation, as business services are
frequently expected to participate in service compositions.
Business services are used within SOAs as follows:
o as fundamental building blocks for the representation of business logic
o to represent a corporate entity or information set
o to represent business process logic
o as service composition members

For future reference, when building an SOA around layers of abstraction, the business service
model can correspond to the business service layer introduced in Chapter 9. In this case the
business service would act as a controller, composing utility application services. (The
controller service model is explained shortly.)

Utility service model

Any generic Web service or service agent designed for potential reuse can be classified as a
utility service. The key to achieving this classification is that the reusable functionality be
completely generic and non-application specific in nature.

Utility services are used within SOAs as follows:

o as services that enable the characteristic of reuse within SOA
o as solution-agnostic intermediary services
o as services that promote the intrinsic interoperability characteristic of SOA
o as the services with the highest degree of autonomy
When working with the service abstraction layers described in Chapter 9, a utility service is
most commonly associated with the application service layer. As a result, a utility service can
be referred to as a utility application service.

Controller service model

Service compositions are comprised of a set of independent services that each contribute to
the execution of the overall business task. The assembly and coordination of these services is
often a task in itself and one that can be assigned as the primary function of a dedicated
service or as the secondary function of a service that is fully capable of executing a business
task independently. The controller service fulfills this role, acting as the parent service to
service composition members.
Controller services are used within SOAs as follows:
o to support and implement the principle of composability
o to leverage reuse opportunities
o to support autonomy in other services

Figure 5.12. A service composition consisting of a master controller, a sub-controller, four

business services, and one utility service.

The controller service model is used frequently when building SOA with specialized service
abstraction layers, as explained later in Chapter 9.
Service descriptions (with WSDL)
When we covered loose coupling in Chapter 3 as part of our primitive SOA discussion, we
introduced the essential need for service descriptions. This part of SOA provides the key
ingredient to establishing a consistently loosely coupled form of communication between
services implemented as Web services.
For this purpose, description documents are required to accompany any service wanting to act
as an ultimate receiver. The primary service description document is the WSDL definition
(Figure 5.14).
Figure 5.14. WSDL definitions enable loose coupling between services.

Figure 5.15. Each service requestor is using the WSDL of a service provider to ensure that
messages sent will be understood and accepted.
Note that because it is TLS that defines the terms of message exchange with other parties,
RailCo developed both of its services to meet TLS's requirements.

5.3.1. Service endpoints and service descriptions

A WSDL describes the point of contact for a service provider, also known as the service
endpoint or just endpoint. It provides a formal definition of the endpoint interface (so that
requestors wishing to communicate with the service provider know exactly how to structure
request messages) and also establishes the physical location (address) of the service.
Let's dig a bit deeper into how the service description document itself is organized. A WSDL
service description (also known as WSDL service definition or just WSDL definition) can be
separated into two categories:
o abstract description
o concrete description
Figure 5.16 shows how these individual descriptions comprise a WSDL definition. Note the
logical hierarchy established within the parts of the abstract definition. We will explain each
of these parts shortly.
Figure 5.16. WSDL document consisting of abstract and concrete parts that collectively
describe a service endpoint.

5.3.2. Abstract description

An abstract description establishes the interface characteristics of the Web service without
any reference to the technology used to host or enable a Web service to transmit messages.
By separating this information, the integrity of the service description can be preserved
regardless of what changes might occur to the underlying technology platform.
Below is a description of the three main parts that comprise an abstract description.
portType, operation, and message

The parent portType section of an abstract description provides a high-level view of the
service interface by sorting the messages a service can process into groups of functions
known as operations.

Each operation represents a specific action performed by the service. A service operation is
comparable to a public method used by components in traditional distributed applications.
Much like component methods, operations also have input and output parameters. Because
Web services rely exclusively on messaging-based communication, parameters are
represented as messages. Therefore, an operation consists of a set of input and output
messages.

5.3.3. Concrete description

For a Web service to be able to execute any of its logic, it needs for its abstract interface
definition to be connected to some real, implemented technology. Because the execution of
service application logic always involves communication, the abstract Web service interface
needs to be connected to a physical transport protocol. This connection is defined in the
concrete description portion of the WSDL file, which consists of three related parts:
binding, port, and service

A WSDL description's binding describes the requirements for a service to establish physical
connections or for connections to be established with the service. In other words, a binding
represents one possible transport technology the service can use to communicate. SOAP is
the most common form of binding, but others also are supported. A binding can apply to an
entire interface or just a specific operation.

Related to the binding is the port, which represents the physical address at which a service
can be accessed with a specific protocol. This piece of physical implementation data exists
separately to allow location information to be maintained independently from other aspects of
the concrete description. Within the WSDL language, the term service is used to refer to a
group of related endpoints.

5.3.4. Metadata and service contracts

So far we've established that the abstract and concrete descriptions provided by a WSDL
definition express technical information as to how a service can be interfaced with and what
type of data exchange it supports.
WSDL definitions frequently rely on XSD schemas to formalize the structure of incoming
and outgoing messages. Another common supplemental service description document is a
policy. Policies can provide rules, preferences, and processing details above and beyond what
is expressed through the WSDL and XSD schema documents. (Policies are explained in
Chapter 7.)
So now we have up to three separate documents that each describe an aspect of a service:
o WSDL definition
 o XSD schema
o policy
Each of these three service description documents can be classified as service metadata, as
each provides information about the service. Service description documents can be
collectively viewed as establishing a service contracta set of conditions that must be met and
accepted by a potential service requestor to enable successful communication.

Note that a service contract can refer to additional documents or agreements not expressed by
service descriptions. For example, a Service Level Agreement (SLA) agreed upon by the
respective owners of a service provider and its requestor can be considered part of an overall
service contract (Figure 5.17).

Figure 5.17. A service contract comprised of a collection of service descriptions and possibly
additional documents.

5.3.5. Semantic descriptions

Most of the metadata currently provided by services focuses on expressing technical
information related to data representation and processing requirements. However, these
service description documents generally do not prove useful in explaining details about a
service's behavioral characteristics. In fact, the most challenging part of providing a complete
description of a Web service is in communicating its semantic qualities.
Examples of service semantics include:
o how a service behaves under certain conditions
o how a service will respond to a specific condition
o what specific tasks the service is most suited for
Most of the time service semantics are assessed by humans, either verbally by discussing the
qualities of a service with its owner, or by reading supplementary documentation published
alongside service descriptions. The ultimate goal is to provide sufficient semantic information
in a structured manner so that, in some cases, service requestors can go as far as to evaluate
and choose suitable service providers independently.
Semantic information is usually of greater importance when dealing with external service
providers, where your knowledge of another party's service is limited to the information the
service owner decides to publish. But even within organizational boundaries, semantic
characteristics tend to take on greater relevance as the amount of internal Web services
grows.

Although service policies can be designed to express preferences and assertions that
communicate aspects of service behavior, efforts are currently underway (primarily by the
W3C) to continually extend the semantic information provided by service description
documents. For the time being, we must focus on the service description capabilities offered
to us through WSDL definitions, XSD schemas, and policies.

5.3.6. Service description advertisement and discovery

As we've established, the sole requirement for one service to contact another is access to the
other service's description. As the amount of services increases within and outside of
organizations, mechanisms for advertising and discovering service descriptions may become
necessary. For example, central directories and registries become an option to keep track of
the many service descriptions that become available. These repositories allow humans (and
even service requestors) to:
o locate the latest versions of known service descriptions
o discover new Web services that meet certain criteria
When the initial set of Web services standards emerged, this eventuality was taken into
account. This is why UDDI formed part of the first generation of Web services standards.
Though not yet commonly implemented, UDDI provides us with a registry model worth
describing.

Private and public registries

UDDI specifies a relatively accepted standard for structuring registries that keep track of
service descriptions (Figure 5.18). These registries can be searched manually and accessed
programmatically via a standardized API.
Figure 5.18. Service description locations centralized in a registry.

Public registries accept registrations from any organizations, regardless of whether they have
Web services to offer. Once signed up, organizations acting as service provider entities can
register their services.

Private registries can be implemented within organization boundaries to provide a central

repository for descriptions of all services the organization develops, leases, or purchases.
Following are descriptions of the primary parts that comprise UDDI registry records.

Business entities and business services

Each public registry record consists of a business entity containing basic profile information
about the organization (or service provider entity). Included in this record are one or more
business service areas, each of which provides a description of the services offered by the
business entity. Business services may or may not be related to the use of Web services.
Binding templates and tModels
You might recall that WSDL definitions stored implementation information separately from
the actual interface design. This resulted in an interface definition that existed independently
from the transport protocols to which it was eventually bound. Registry records follow the
same logic in that they store binding information in a separate area, called the binding
template.

Each business service can reference one or more binding templates. The information
contained in a binding template may or may not relate to an actual service. For example, a
binding template may simply point to the address of a Web site. However, if a Web service is
being represented, then the binding template references a tModel. The tModel section of a
UDDI record provides pointers to actual service descriptions (Figure 5.19).
Figure 5.19. The basic structure of a UDDI business entity record.

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.

.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.

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:
o processing instructions that may be executed by service intermediaries or the ultimate
receiver
o routing or workflow information associated with the message
o security measures implemented in the message
o reliability rules related to the delivery of the message
o context and transaction management information
o 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.
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.

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.

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.

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.
o SOAP sendera SOAP node that transmits a message
o SOAP receivera SOAP node that receives a message
o SOAP intermediarya SOAP node that receives and transmits a message, and
optionally processes the message prior to transmission
o initial SOAP senderthe first SOAP node to transmit a message
o ultimate SOAP receiverthe last SOAP node to receive a message
Figure 5.27 illustrates how SOAP nodes transition through these roles.
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.