description about WS-extension services

1. SOA UNIT IV
4.1WS-Reliability Messaging
4.2WS-Transaction
4.3WS-Addressing
By
Dr.Smitha.P.S
Associate Professor
Velammal Engineering College

2. 4.1 WS-Reliability (WS-R)
• WS-Reliability (WS-R) WS-Reliability is supported
by Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle
Corp., Sonic Software, and Sun Microsystems.
• The purpose of the specification is to define
reliability in the context of current Web Services
standards.
• In WS-Reliability , Reliable Messaging (RM) is
defined as: The execution of a transport-agnostic,
SOAP-based protocol providing quality of service
in the reliable delivery of messages.

3. Scope of WS-Reliability
• Scope of WS-Reliability
WS-Reliability defines a protocol for exchanging
SOAP messages reliably. Reliability features are
specified in SOAP headers independently of the
underlying protocol. The specification also
contains a binding to HTTP.
• W3C SOAP1.1/1.2 WS-Reliability defines reliable
messaging protocol embedded in the SOAP
Header. SOAP1.1 and SOAP1.2 are the base
protocols.

4. The WS-R Model
• The WS-Reliability specification considers a set of
abstract operations that are used to model
reliability contracts between the (reliable)
messaging middleware (i.e. Sending and
Receiving RMPs) and its users (i.e. Producers and
Consumers of messages).
• RMP stands for Reliable Messaging Processor.
RMPs are modules that enforce reliable
messaging. RMPs constitute the reliable
messaging middleware.

5. The WS-R Model
• Submit used by the application layer to send a
message reliably
• Deliver used to deliver the payload to the
(receiving) application layer
• Respond used by the (receiving) application
layer to route a response
• Notify used to notify to a producer of an
error, or to transferring a response

6. The WS-R Model

7. WS-R Model
• Acknowledgment indications (ACKs) are signaled
when messages are successfully delivered (it
implies the successful execution of the Deliver
operation).
• Currently the specification defines the following
reliability features:
• Guaranteed message delivery (At-Least-Once) delivery
semantics
• Guaranteed message duplicate elimination (At-Most-Once)
• Guaranteed message delivery and duplicate elimination
(Exactly-Once)
• Guaranteed message ordering for delivery within a group of
messages

8. SOAP Message Exchange Patterns (MEP)
<soap : Envelope . . . >
<soap : Header>
<Request . . . >
. . .
<ReplyPattern>
<Value> Callback </Value>
<ReplyTo>
</ReplyTo>
<BareURI> http :// wsr−sender . org / abc/ wsrm Listener </BareURI>
</ReplyPattern>
. . .
</Request>
</soap : Header>
<soap : Body>
. . .
</soap : Body>
</soap : Envelope>
Reply patterns are specified with the <ReplyPattern> construct, inside <Request> tags
Possible values for <ReplyPattern> are: Response, Callback and Poll.

9. • Message Identification and Grouping Messages
always have a group. Each group has a global
identifier. Unique sequence numbers are used to
identify messages inside a group.
• Fault Codes The specification defines two
kinds of faults: message format and message
process- ing faults. Message Format Faults are:
InvalidRequest, InvalidPollRequest,
InvalidMessageId, InvalidMessageParameters,
InvalidReplyPattern and InvalidExpiryTime.

10. Reliability Agreements
• GuaranteedDelivery (enabled/disabled): for setting Guaranteed Delivery.
• NoDuplicateDelivery (enabled/disabled): for setting message delivery without duplicates, or Duplicate
Elimination.
• OrderedDelivery (enabled/disabled): for setting Guaranteed Message Ordering.
• GroupMaxIdleDuration (number of seconds): For setting the elapsed time limit from the last message
sent or received in a group, after which the group can be terminated.
• GroupExpiryTime (number of seconds): For setting the date and time after which the group can be
terminated.
• ExpiryTime (number of seconds): For setting the date and time after which a message must not be
delivered to the receiving application.
• RetryMaxTimes (integer number): For setting the maximum number of times a message must be resent if
not acknowledged.
• RetryTimeInterval (number of seconds): For setting the minimal elapsed time between two re-sending of
the same message.
• ReplyPattern (Response, Callback, Poll): For setting the mode of response for acknowledg- ments and
faults.

11. WS-ReliableMessaging (WS-RM)
• WS-ReliableMessaging is a protocol standard that
addresses reliable messaging. It emerged from the
joint efforts of IBM, BEA Systems, Microsoft and TIBCO
Software representatives.
• The primary goal of WS-RM specification is to create a
modular mechanism for reliable message delivery. It
defines a messaging protocol to identify, track, and
manage the reliable delivery of mes- sages between
exactly two parties, a source and a destination.
• It also defines a SOAP binding that is required for
interoperability. Additional bindings may be defined.
This mechanism is extensible allowing additional
functionality, such as security, to be tightly integrated.
• WS-RM integrates with and complements the WS-
Security, WS-Policy, and other Web services
specifications. Combined, these allow for a broad
range of reliable, secure messaging options.

12. Scope of WS-Reliable Messaging
• WS-ReliableMessaging provides an interoperable protocol
that a Reliable Messaging (RM) Source and Reliable
Messaging (RM) Destination use to provide Application
Source and Destination a guarantee that a message that is
sent will be delivered.
• It is the responsibility of the RM Source and RM Destination
to fulfill the these guarantees, or raise an error.
• WS-RM is described in a transport-independent manner
allowing it to be implemented using different network
technologies. To support interoperable Web services, a
SOAP binding is defined within the specification.

13. WS-Reliable Messaging
• WS-ReliableMessaging provides an interoperable protocol that a Reliable Messaging (RM)
Source and Reliable Messaging (RM) Destination use to provide Application Source and
Destination a guarantee that a message that is sent will be delivered. The guarantee is
specified as a delivery assurance. The protocol supports the endpoints in providing these
delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the
delivery assurances, or raise an error.
• There are four basic delivery assurances (Fig. 3) that endpoints can provide:
• AtMostOnce Messages will be delivered at most once without duplication or an error will be
raised on at least one endpoint. It is possible that some messages in a sequence may not be
delivered.
• AtLeastOnce Every message sent will be delivered or an error will be raised on at least one
endpoint. Some messages may be delivered more than once
• ExactlyOnce Every message sent will be delivered without duplication or an error will be
raised on at least one endpoint.
• InOrder Messages will be delivered in the order that they were sent. This delivery assurance
may be combined with any of the above delivery assurances. It requires that the sequence
observed by the ultimate receiver be non-decreasing. It says nothing about duplications or
omissions.

14. WS-Reliable Messaging Model
Figure 3: WS-Reliable messaging Model

15. Protocol Elements
The protocol elements are:
• Sequences The RM protocol uses a <Sequence> header block to track and manage the reliable
delivery of messages. Messages for which the delivery assurance applies MUST contain a
<Sequence> header block.
• Sequence Acknowledgments The RM Destination informs the RM Source of successful message
receipt using a <SequenceAcknowledgement> header block.
• Request Acknowledgement The purpose of the <AckRequested> header block is to signal to the
RM Destination that the RM Source is requesting that a <SequenceAcknowledgement> be
returned.
• Sequence Creation The RM Source MUST request creation of an outbound Sequence by sending a
<CreateSequence> element in the body of a message to the RM Destination.
• Sequence Termination After an RM Source receives the <SequenceAcknowledgement> acknowl-
edging the complete range of messages in a Sequence, it sends a <TerminateSequence> el- ement,
in the body of a message to the RM Destination to indicate that the Sequence is complete, and that
it will not be sending any further messages related to the Sequence.
• An example scenario involving these elements is shown in figure 4

16. Faults
WS-RM defines the following fault codes, which can be detailed within the
<SequenceFault> element.
• Sequence Terminated This fault is sent by either the RM Source or the RM
Destination to indicate that the endpoint that generates the fault has
either encountered an unrecoverable condition, or has detected a
violation of the protocol and as a consequence, has chosen to terminate
the sequence.
• Unknown Sequence This fault is sent by either the RM Source or the RM
Destination in response to a message containing an unknown sequence
identifier.
• Invalid Acknowledgement This fault is sent by the RM Source in response
to a <Sequence- Acknowledgement> that violates the cumulative
acknowledgement invariant.
• Message Number Rollover This fault is sent to indicate that message
numbers for a sequence have been exhausted.
• Last Message Number Exceeded This fault is sent by an RM Destination to
indicate that it has received a message that has a <MessageNumber>
within a Sequence that exceeds the value of the <MessageNumber>
element that accompanied a <LastMessage> element for the Sequence.
• Create Sequence Refused This fault is sent in response to a create
sequence request that cannot be satisfied

17. CreateSequence
• A Sequence is created using
a CreateSequence interaction, and terminated when
finished with a TerminateSequence interaction.
Example of a CreateSequence message:
<soap:body>
<wsrm:createsequence>
<wsrm:acksto>
<wsa:address>http://Business456.com/serviceA/789</w
sa:address>
</wsrm:acksto>
</wsrm:createsequence>
</soap:body>

18. Sequence header and message
number
• Each message in a sequence has a message number,
which starts at one and increments by one for each
message.
Example of a Sequence Header and message number:
<soap:header>
<wsrm:sequence>
<wsrm:identifier>http://Business456.com/RM/ABC</w
srm:identifier>
<wsrm:messagenumber>1</wsrm:messagenumber>
</wsrm:sequence>
</soap:header>

19. sequenceAcknowledgement
• The message number is used to Acknowledge the
message in an SequenceAcknowledgement header.
Example of a SequenceAcknowledgement Header:
<soap:header>
<wsrm:sequenceacknowledgement>
<wsrm:identifier>http://Business456.com/RM/ABC</wsr
m:identifier>
<wsrm:acknowledgement range lower="1" upper="1" />
<wsrm:acknowledgement range lower="3" upper="3" />
</wsrm:sequenceacknowledgement>
</soap:header>

20. 4.2 WS-TRANSACTION
• Atomic transactions have an all-or-nothing property. The actions taken
prior to commit are only tentative (i.e., not persistent and not visible to
other activities).
• When an application finishes, it requests the coordinator to determine
the outcome for the transaction. The coordinator determines if there
were any processing failures by asking the participants to vote. If the
participants all vote that they were able to execute successfully, the
coordinator commits all actions taken. If a participant votes that it needs
to abort or a participant does not respond at all, the coordinator aborts all
actions taken.
• Commit makes the tentative actions visible to other transactions. Abort
makes the tentative actions appear as if the actions never happened.
• Atomic transactions have proven to be extremely valuable for many
applications. They provide consistent failure and recovery semantics, so
the applications no longer need to deal with the mechanics of
determining a mutually agreed outcome decision or to figure out how to
recover from a large number of possible inconsistent states.
• Atomic Transaction defines protocols that govern the outcome of atomic
transactions. It is expected that existing transaction processing systems
wrap their proprietary mechanisms and interoperate across different
vendor implementations.

21. Namespace
• The XML namespace [XML-ns] URI that MUST be used by
implementations of this specification is:
http://schemas.xmlsoap.org/ws/2004/10/wsat
• This is also used as the CoordinationContext type for atomic
transactions. The following namespaces are used in this document:
Prefix Namespace
S http://www.w3.org/2003/05/soap-envelope
wscoor http://schemas.xmlsoap.org/ws/2004/10/wscoor
Wsat http://schemas.xmlsoap.org/ws/2004/10/wsat
• If an action URI is used then the action URI MUST consist of the wsat
namespace URI concatenated with the "/" character and the element
name. For example:
• http://schemas.xmlsoap.org/ws/2004/10/wsat/Commit

22. Atomic Transaction Context
• Atomic Transaction builds on WS-Coordination, which
defines an activation and a registration service.
• The Atomic Transaction coordination context must
flow on all application messages involved with the
transaction.
• A coordination context may have an Expires attribute.
This attribute specifies the earliest point in time at
which a transaction may be terminated solely due to
its length of operation. From that point forward, the
transaction manager may elect to unilaterally roll back
the transaction, so long as it has not transmitted a
Commit or a Prepared notification.
• The Atomic Transaction protocol is identified by the
following coordination type:
http://schemas.xmlsoap.org/ws/2004/10/wsat

23. Atomic Transaction Protocols
This specification defines the following protocols for
atomic transactions.
• Completion: The completion protocol initiates
commitment processing. Based on each protocol's
registered participants, the coordinator begins with
Volatile 2PC then proceeds through Durable 2PC. The
final result is signaled to the initiator.
• Two-Phase Commit (2PC): The 2PC protocol coordinates
registered participants to reach a commit or abort
decision, and ensures that all participants are informed
of the final result. The 2PC protocol has two variants:
– Volatile 2PC: Participants managing volatile resources such
as a cache should register for this protocol.
– Durable 2PC: Participants managing durable resources such
as a database should register for this protocol.
• A participant can register for more than one of these
protocols by sending multiple Register messages.

24. 1.0Completion Protocol
• The Completion protocol is used by an
application to tell the coordinator to either try to
commit or abort an atomic transaction. After the
transaction has completed, a status is returned
to the application.
• An initiator registers for this protocol using the
following protocol identifier:
http://schemas.xmlsoap.org/ws/2004/10/wsat/
Completion

25. Completion Protocol

26. Completion Protocol
The coordinator accepts:
Commit
Upon receipt of this notification, the coordinator knows that the
participant has completed application processing and that it should
attempt to commit the transaction.
Rollback
• Upon receipt of this notification, the coordinator knows that the
participant has terminated application processing and that it should
abort the transaction.
The initiator accepts:
Committed
Upon receipt of this notification, the initiator knows that the
coordinator reached a decision to commit.
Aborted
• Upon receipt of this notification, the initiator knows that the
coordinator reached a decision to abort.
• Conforming implementations must implement Completion.

27. 2.0Two-Phase Commit Protocol
• The Two-Phase Commit (2PC) protocol is a Coordination protocol that
defines how multiple participants reach agreement on the outcome of an
atomic transaction. The 2PC protocol has two variants: Durable 2PC and
Volatile 2PC.
Volatile Two-Phase Commit Protocol
• Upon receiving a Commit notification in the completion protocol, the root
coordinator begins the prepare phase of all participants registered for the
Volatile 2PC protocol.
• All participants registered for this protocol must respond before a Prepare
is issued to a participant registered for Durable 2PC.
• Further participants may register with the coordinator until the
coordinator issues a Prepare to any durable participant.
• A volatile recipient is not guaranteed to receive a notification of the
transaction's outcome.
• Participants register for this protocol using the following protocol
identifier:
http://schemas.xmlsoap.org/ws/2004/10/wsat/Volatile2PC

28. Durable Two-Phase Commit Protocol
• After receiving a Commit notification in the
completion protocol and upon successfully
completing the prepare phase for Volatile 2PC
participants, the root coordinator begins the
Prepare phase for Durable 2PC participants.
• All participants registered for this protocol must
respond Prepared or ReadOnly before a Commit
notification is issued to a participant registered
for either protocol.
• Participants register for this protocol using the
following protocol identifier:
• http://schemas.xmlsoap.org/ws/2004/10/wsat/D
urable2PC

29. 2PC Diagram and Notifications

30. 2PC Diagram and Notifications
The participant accepts:
Prepare
Upon receipt of this notification, the participant knows to enter phase 1 and vote on the outcome of the
transaction. If the participant does not know of the transaction, it must vote to abort. If the participant has
already voted, it should resend the same vote.
Rollback
Upon receipt of this notification, the participant knows to abort, and forget, the transaction. This notification
can be sent in either phase 1 or phase 2. Once sent, the coordinator may forget all knowledge of this
transaction.
Commit
Upon receipt of this notification, the participant knows to commit the transaction. This notification can only be
sent after phase 1 and if the participant voted to commit. If the participant does not know of the transaction, it
must send a Committed notification to the coordinator.
The coordinator accepts:
Prepared
Upon receipt of this notification, the coordinator knows the participant is prepared and votes to commit the
transaction.
ReadOnly
Upon receipt of this notification, the coordinator knows the participant votes to commit the transaction, and
has forgotten the transaction. The participant does not wish to participate in phase 2.
Aborted
Upon receipt of this notification, the coordinator knows the participant has aborted, and forgotten, the
transaction.
Committed
• Upon receipt of this notification, the coordinator knows the participant has committed the transaction. That
participant may be safely forgotten.
Replay
Upon receipt of this notification, the coordinator may assume the participant has suffered a recoverable
failure.It should resend the last appropriate protocol notification.
Conforming implementations MUST implement the 2PC protocol.

31. Atomic Transaction Protocols
3.0 PhaseZero Protocol
• The name "PhaseZero" suggests a phase that occurs before the start of
the first of the two phases in the 2PC sequence. In application scenario,
the inventory module checks the availability of components with the
database module and then asks the database module to mark the
components as "booked". This requires the database module to know
about the requirement of booking components for this order before the
start of the 2PC sequence. Once the 2PC sequence has started, the
inventory module will not have the chance of sending any more data to
the database module.
• Similarly, the assembly line management module also needs to tell the
database module to book the assembly line capacity before the start of
the 2PC sequence. The PhaseZero protocol provides an opportunity for
applications to send data updates before the start of the 2PC sequence.
• Therefore, both the inventory and the PC assembly line management
modules will register for the PhaseZero protocol. You can think of
PhaseZero protocol as an opportunity for middleware applications to flush
any outstanding data to database applications before the start of the 2PC
sequence.

32. Atomic Transaction Protocols
4.0CompletionWithAck Protocol
This protocol is the same as the completion
protocol, except for one detail. The participant
which registers for the CompletionWithAck protocol
will need to send an acknowledgment back to the
coordinator after receiving the outcome notification.
5.0 OutcomeNotification protocol
This protocol is for applications that want to act as
silent listeners in an AT. Such applications will have
no active participation in the transaction, but they
will be informed about its outcome.

33. ATOMIC TRANSACTION PROCESS
• The atomic transaction coordinator is tasked with the
responsibility of deciding the outcome of a transaction. It
bases this decision on feedback it receives from all of the
transaction participants.
• The collection of this feedback is separated into two
phases. During the prepare phase (Figure 6.22), all
participants are notified by the coordinator, and each is
asked to prepare and then issue a vote. Each participant's
vote consists of either a "commit" or "abort" request
(Figure 6.23).
• Figure 6.22. The coordinator requesting that transaction
participants prepare to vote.

34. ATOMIC TRANSACTION PROCESS
• Figure 6.23. The transaction participants
voting on the outcome of the atomic
transaction.

35. ATOMIC TRANSACTION PROCESS
After the votes are collected, the atomic transaction coordinator
enters the commit phase. It now reviews all votes and decides
whether to commit or rollback the transaction. The conditions of a
commit decision are simple: if all votes are received and if all
participants voted to commit, the coordinator declares the
transaction successful, and the changes are committed. However, if
any one vote requests an abort, or if any of the participants fail to
respond, then the transaction is aborted, and all changes are rolled
back (Figure 6.24).

36. WS-Transaction
<Envelope
xmlns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsc="http://schemas.xmlsoap.org/ws/2002/08/ws
coor" xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
<Header>
<wsc:CoordinationContext>
<wsu:Identifier> ... </wsu:Identifier>
<wsu:Expires> ... </wsu:Expires>
<wsc:CoordinationType> ... </wsc:CoordinationType>
<wsc:RegistrationService> ...
</wsc:RegistrationService>
</wsc:CoordinationContext>
</Header>
<Body> ... </Body>
</Envelope>

37. WS-Transaction
The activation service returns this CoordinationContext header upon the
creation of a new activity.
It is within the CoordinationType child construct that the activity protocol
(WS-BusinessActivity, WS-AtomicTransaction) is carried.
The Identifier and Expires elements
These two elements originate from a utility schema used to provide
reusable elements.
WS-Coordination uses the Identifier element to associate a unique ID value
with the current activity.
The Expires element sets an expiry date that establishes the extent of the
activity's possible lifespan.
Example:Identifier and Expires elements containing values relating to the
header.
<Envelope ...
xmlns:wsu= "http://schemas.xmlsoap.org/ws/2002/07/utility">
...
<wsu:Identifier> http://www.xmltc.com/ids/process/33342
</wsu:Identifier>
<wsu:Expires> 2008-07-30T24:00:00.000 </wsu:Expires>
...
</Envelope>

38. WS-Transaction
Example:The CoordinationType element representing the WS-
BusinessActivity protocol
<wsc:CoordinationType>
http://schemas.xmlsoap.org/ws/2004/01/wsba
</wsc:CoordinationType>
Designating the WS-AtomicTransaction coordination type
In the next example, the CoordinationType element is assigned the WS-
AtomicTransaction coordination type identifier, which communicates the
fact that the header's context information is part of a short running
transaction.
Example:The CoordinationType element representing the WS-
AtomicTransaction protocol.
<wsc:CoordinationType> http://schemas.xmlsoap.org/ws/2003/09/wsat
</wsc:CoordinationType>

39. ACID transactions
The term "ACID" is an acronym representing the following four
required characteristics of a traditional transaction:
• Atomic
Either all of the changes within the scope of the transaction
succeed, or none of them succeed. This characteristic introduces
the need for the rollback feature that is responsible for restoring
any changes completed as part of a failed transaction to their
original state.
• Consistent
None of the data changes made as a result of the transaction can
violate the validity of any associated data models. Any violations
result in a rollback of the transaction.
• Isolated
If multiple transactions occur concurrently, they may not interfere
with each other. Each transaction must be guaranteed an isolated
execution environment.
• Durable
Upon the completion of a successful transaction, changes made as
a result of the transaction can survive subsequent failures.

40. CASE STUDY

41. 4.3 WS-Addressing
Addressing extensions are integral to SOA's
underlying messaging mechanics. Many other
WS-* specifications implicitly rely on the use
of WS-Addressing.
Figure 7.2. Addressing turns messages into
autonomous units of communication.

42. Endpoint references
• 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.

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

44. End point References
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.
• 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.

45. Message information headers
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).

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

47. WS-Addressing
(001) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/02/addressing">
(002) <S:Header>
(003) <wsa:MessageID>
(004) http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA
(005) </wsa:MessageID>
(006) <wsa:ReplyTo>
(007) <wsa:Address>http://example.com/business/client1</wsa:Address>
(008) </wsa:ReplyTo>
(009) <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
(010) <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
(011) </S:Header>
(012) <S:Body>
(013) ...
(014) </S:Body>
(015) </S:Envelope>
Lines (002) to (011) represent the header of the SOAP message where the mechanisms defined in
the specification are used. The body is represented by lines (012) to (014).
Lines (003) to (010) contain the message information header blocks. Specifically, lines (003) to
(005) specify the identifier for this message and lines (006) to (008) specify the endpoint to which
replies to this message should be sent as an Endpoint Reference. Line (009) specifies the address
URI of the ultimate receiver of this message. Line (010) specifies an Action URI identifying expected
semantics.

48. Message information headers
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).
• Action A URI value that indicates the message's overall purpose
(the equivalent of the standard SOAP HTTP action value).

49. Message information headers
• 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.

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

51. Addressing and SOA
Figure 7.5. Addressing relating to other parts of SOA.

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

53. CASE STUDY