WS-ReliableMessaging Pattern Part II

1
WS-ReliableMessaging Pattern Part II

• Ingrid Buckley
• Dept. of Computer Science and Engineering
  Florida Atlantic UniversityBoca Raton, FL, USA
• October 2, 2008.

2
Agenda

• Motivation
• Objective
• Introduction
• WS-ReliableMessaging Pattern
• Analysis
• Questions
• Recommendations

3
Motivation

• SOAP over HTTP is not sufficient when an
  application-level messaging protocol must also
  guarantee some level of reliability and security.
• Providing a convenient means to achieve reliable
  messaging in web services.
• A Survey of Web service products and
  Dependability patterns highlighted the following
• The web services standard that are most used in
  industry and in commercial products
• In enumerating dependability patterns which
  included fault tolerance pattern we identified
  patterns that required improvements and areas
  that were not not yet supported.

4
Motivation

• To write patterns that are helpful to programmers
  to aid them in designing and implementing
  Reliability in web services and their
  applications.
• We intend to write patterns that describe web
  Service standards which aids in supporting best
  practice in the industry.

5
Objective

• To write a pattern that describes the
  WS-ReliableMessaging Standard.

6
Introduction

• It is often a requirement for two Web services
  that wish to communicate to do so reliably in the
  presence of software component, system, or
  network failures.
• The primary goal of the WS-ReliableMessaging
  specification is to create a modular mechanism
  for reliable transfer of messages.
• It defines a messaging protocol to identify,
  track, and manage the reliable transfer of
  messages between a source and a destination
• This specification has been designed for use in
  combination with other complementary protocols
• WS-Policy
• WS-Addressing
• WS-Security

7
WS-ReliableMessaging Pattern

• Intent
• WS-ReliableMessaging ensures guaranteed
  receipt in response to each message received it
  also provides, message state disposition, ordered
  delivery, duplicate elimination whenever messages
  are sent between endpoints.
• Context
• Companies, B2B applications and critical
  infrastructure systems that send and receive
  messages in real-time and where errors can
  interrupt a conversation, messages can be lost,
  duplicated or reordered and where the host
  system may experience failures and lose volatile
  state.

8
Problem

• Many errors can interrupt a conversation,
  messages can be lost, duplicated or reordered,
  the host system may also experience failures and
  lose volatile state.
• Some applications need to have reliable messaging
  in order to fulfill their business operations
  effectively and successfully, therefore lost,
  unordered and duplicate messages can have a
  negative affect on successful business
  operations.
• How do we ensure that messages that are sent with
  guaranteed receipt, sent in order, and without
  any duplication?

9
Problem

• The solution to this problem is affected by the
  following forces
• The receiving or sending host may become
  unavailable and some or all messages may not get
  sent or received.
• Messages may get lost during transmission.
• Unordered and delayed messages can lead to
  problems for online transactions especially in
  banking systems and critical infrastructures such
  as avionics systems.
• The response time to messages contributes to
  delay in sending a receipt when messages get
  lost or arrive to a recipient unordered, it may
  take more time to respond, thus increasing the
  response time.
• Host system may experience failure and become
  unavailable.

10
Solution

• Use a protocol that performs guaranteed receipt,
  ordered delivery and duplicate message
  elimination. This is achieved by first having an
  agreement which includes policy exchange,
  endpoint resolution and establishment of trust
  between end points.
• Structure

11
Figure 1 Class Diagram for the
WS-ReliableMessaging pattern
12
Solution

• Structure
• An Agreement is defined which enforces policy
  exchange, end point resolution and trust
  establishment between the application source and
  the application destination. The Application
  Source creates and sends messages to the RM
  source (Figure 1),
• A Message consist of content and information
  about where it is supposed to be delivered to.
  The RM Source transforms a message into a
  ReliableMessage by adding new properties to the
  message.
• A new Sequence is created by the RM destination
  at the request of the RM Source it acts like an
  envelope in which a ReliableMessage is placed
  before it is transmitted.
• The RM Source accepts messages and
  acknowledgements from the application source and
  RM Destination respectively, and transmits
  ReliableMessages to the RM destination.
• The RM Destination receives messages sent from
  the RM Source and sends a corresponding
  acknowledgement of receipt to the RM Source and
  delivers the ReliableMessage to the destination
  application.
• The Destination Application receives
  ReliableMessages from the RM Destination.

13
Solution

• Dynamics
• We describe the dynamics aspects of the
  WS-ReliableMessaging
• pattern using a sequence diagram for the use
  case Sending a
• message in a reliable manner.
• UC Sending a message in a reliable manner
  (Figure 2)
• Summary An application source wishes to send a
  message to a destination source.
• Actors Application Source, RM Source, RM
  Destination, Application Destination
• Precondition The Application Source and the
  Destination Source must establish an agreement
  prior to communicating with each other see figure
  3.

14
Solution

• Dynamics
• Description
• The Application Source creates and sends a
  message to the RM Source.
• The RM Source request a new sequence from the RM
  Destination and adds new properties to the
  message received, thus transforming the message
  into a reliablemessage.
• The RM Source transmits the reliablemessage
  wrapped in this new sequence to the RM
  Destination.
• The RM Source sends a terminate sequence request
  to the RM Destination when it has no more
  messages to transmit in a given sequence.
• The RM Destination creates new sequences at the
  request of the RM Source, It receives messages
  within the sequence it creates which are
  transmitted by the RM Source. The RM Source
  delivers reliablemessages to the application
  destination.
• The RM Destination sends a corresponding
  acknowledgment to each message received from the
  RM Source in response to each message that is
  accepted. It terminates and reclaims resources
  attached to a sequence after a terminate sequence
  request is transmitted by the RM Source.
• The Destination Application receives messages
  from the RM Destination.
• Post condition
• An acknowledgement is sent for all messages
  received by the RM Destination.

15
Figure 2 Sequence Diagram illustrating the
sending a Reliable message
16
Solution

• Dynamics
• We describe the dynamics aspects of the
  WS-ReliableMessaging pattern using a sequence
• diagram for the use case Establishing an
  agreement/contract.
• UC Establishing an agreement/contract (Figure
  3)
• Summary An application source wishes to send a
  message to a destination source.
• Actors Application Source, Application
  Destination.
• Description
• The Application Source sends a request to make an
  agreement/contract to the Application Destination
  who agrees to make an agreement/contract with the
  Application source.
• The Application source sends the terms of the
  agreement/contract to the Destination Application
  who reviews the terms and accepts the terms of
  the agreement/contract.
• The application destination signoff on the
  agreement/contract and requests a signoff from
  the Destination Application signoff on the
  agreement/contract to make it binding.
• Post condition
• The agreement/contract is signed off on by both
  the application and destination source.

17
Figure 3 Sequence Diagram for use case
Establishing an agreement/contract
18
Implementation

• To implement the WS-ReliableMessaging, the
  following is required
• Use an adaptive mechanisms that dynamically
  adjust re-transmission time and the back-off
  intervals that are appropriate to the nature of
  the transports and intermediaries used. Because
  the RM Source has to re-transmit messages for
  which no acknowledgments were received. This
  re-transmission cannot be specified at all times
  because the nature and dynamic characteristics of
  the underlying transport and potential
  intermediaries are unknown in the general case.
  Over-aggressive re-transmissions have been
  demonstrated to cause transport or intermediary
  flooding which are counterproductive to the
  intention of providing a reliable exchange of
  messagesOas07.
• Delivery assurance for each message is achieved
  based on either AtleastOnce, AtMostOnce or
  ExcatlyOnce and in order assertions.
• Endpoint referencing must be obtained by the RM
  Source that uniquely identifies the RM
  Destination.

19
Implementation

• A security context has to be developed separately
  if secured exchange of messages is
  requiredOas07, one possible option is the use
  of security tokens to protect a reliable message.
• The sequence number of messages starts at one(1)
  and is incremented by one(1) for all other
  subsequent messages in a given sequence. However
  this may present some implementation problems
  since most systems expect elements or processes
  to begin numbering at zero. The programmer
  therefore has to ensure that sequence numbers
  begin at the same starting point between
  endpoints to avoid discrepancies.

20
Consequences

• The WS- ReliableMessaging pattern presents the
  following advantages
• The state of messages sent between endpoints can
  be determined by means of a Sequence wrapper
  which has state tracking properties included.
• Enterprises are able to obtain a higher degree of
  reliability for network communication because
  endpoints create and terminate messages
  sequences. In addition a receipt of
  acknowledgement t is sent every time a message is
  sent and with re-transmission of messages is done
  for messages that were not received.
• Quality of service defined by contracts can be
  maintained between businesses thus increasing
  reliability and supporting the accountability of
  business partners.
• The WS_Policy standard is used to govern policies
  that can be attached to the agreements that
  govern the operations agreed to by communicating
  endpoints.
• WS-Addressing is utilized to achieve endpoint
  referencing this specifies the endpoint
  reference to where the receipt of acknowledgement
  is to be sent in response to a message. In this
  way messages cannot be intercepted easily.

21
Consequences

• Consequences
• A guaranteed receipt of acknowledgment is issued
  for each message that is received between
  endpoints with duplicate elimination and ordering
  and re-transmission for lost messages.
• Terminate message sequence requests are sent to
  recipients to communicate that no more messages
  will be sent for a given sequence therefore
  system resources attached to sequence can be
  freed and used to conduct other operations
  faster.
• The pattern also has some possible
  liabilities
• Introduces a high time overhead with the
  re-transmission of messages and acknowledgements.
  Due to the fact that the RM Source will
  re-transmit messages for which no receipt of
  acknowledgments were received. This could result
  in high volume requests thus flooding the RM
  Destination depending on the re-transmission
  interval set (see implementation).
• High demand on resources used to track the state
  of each message transmitted by RM Source is
  required.

22
Known Uses

• The following commercial products utilizes the
  WS-ReliableMessaging Pattern
• SAP NetWeaver Process Integration 7.1Sap07 is a
  platform for process integration using the
  exchange of XML messages.
• Apache Sandesha Apache Axis Apa05 is an
  implementation of the Web Services
  ReliableMessaging (WS-ReliableMessaging),
  published by the IBM, Microsoft, BEA and TIBCO
  Software as a joint specification, on top of
  Apache Axis (The Next Generation SOAP). 
• WebSphere MQ Web08 is an application
  integration tool used for passing messages
  between applications and Web services

23
Related Patterns

• The WS-Reliability Buc08b is an alternative
  used to send messages in a reliable manner.
  WS-ReliableMessaging sends a receipt of
  acknowledgements to confirm reception of each
  message received as a part of its solution. This
  can be done using the Acknowledgment Buc08, I
  am Alive Sar02, and Are you Alive Sar02
  patterns.
• The Strategy pattern Gam96 can be used as a
  part of the implementation of the re-transmission
  of messages to ascertain the best re-transmission
  time and back-off interval to be used for lost
  messages and receipts of acknowledgment.

24
Analysis

• WS-Reliability and WS-ReliableMessage offer the
  same service, which is sending messages in a
  reliable manner. However the two protocols
  utilize different means of performing this common
  service.
• WS-Reliability engages the producer and consumer
  of messages in the entire cycle of sending a
  reliable message. The producer specifies the mode
  of response that is required from a consumer and
  remains active through the entire process until
  an acknowledgement is received. In contrast,
  WS-ReliableMessaging uses two components to
  control the execution of a reliable message.
• From the time a message is initially sent by the
  sender until it is received by the recipient, the
  sender and the receiver do not have participate
  in every aspect of sending the reliable message.
• Additionally WS-ReliableMessaging must use a
  sequence to wrap all messages (individual and
  series of messages) whereas WS-Reliability sends
  messages either individually or in groups,
  assigning a unique group id and a unique sequence
  number for group messages.

25
Analysis

• The sequence number is optional for individual
  messages as defined in WS-Reliability. Moreover
  WS-ReliableMessaging mandates that all sequences
  be ended when no more messages will be sent using
  that sequence.
• WS-Reliability uses a GroupExpiryTime to
  terminate group messages and an ExpiryTime for
  individual message.
• The main difference between WS-Reliability and
  WS-ReliablwMessage is that the former uses SOAP
  MEPs to respond to the receipt of messages.
• WS-ReliableMessaging allows acknowledgments to
  be sent with or without using the SOAP body.
• Table 1 shows a comparison of the WS-Reliability
  and WS-ReliableMessage Patterns.

26
WS-Reliability vs WS-ReliableMessaging
Standard\Properties WS-Reliability WS-ReliableMessaging
Components Producer Consumer Sending RMP Receiving RMP Application Source Destination Source RM Source RM Destination
Protocol Preconditions SOAP-based Protocol Quality of Service(QoS) defines quality of messaging service to communication endpoints wire protocol must have specific message headers and specific message choreographies between endpoints Defined Contract between the two RMP and endpoints Must have endpoint referencing that uniquely identifies RM destination endpoint. RM Source must create a new Sequence with unique identifier with the RM Destination. The RM Source MUST be capable of formulating messages that adhere to the RM Destination's policies. If a secure exchange of messages is required then the RM Source and RM Destination must have a security context.
Defined Features Guaranteed delivery or At-Least-Once Delivery semantics. Guaranteed message duplicate elimination, or At-Most-Once delivery semantics. Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics. Guaranteed message ordering for delivery within a group of messages. Delivery Assurance options AtLeastOnce AtMostOnce ExactlyOnce InOrder Reliability Features Duplicate Elimination Message state Disposition Ordering Guaranteed receipt
27
WS-Reliability vs WS-ReliableMessaging
Messaging Context and Messaging Agreement Assumptions SOAP Intermediary transparency Message Integrity Context Four Operations (Submit Deliver, Respond, Notify) used to model reliability contracts between RMPs. The RMP must know which SOAP MEP is being used when sending or receiving a reliable message. The use of SOAP Message Exchange Patterns. RM Source must assign each message within a sequence a message number. Within every Acknowledgement Message it issues, the RM Destination MUST include one or more AcknowledgementRange child elements that contain, in their collective ranges, the message number of every message accepted and exclude those not accepted by the RM Destination. While the Sequence is not closed or terminated, the RM Source SHOULD retransmits unacknowledged messages.
Protocol Operations The protocol is defined by a set of abstract operation Submit, Deliver, Notify and Respond. No requirements are defined about how they should be implemented. The protocol uses a defined set of operations Send, Deliver, Transmit and Acknowledge.
Relation to other Specification SOAP1.1/1.2 OASIS ebXML Message Service Specifcation 2.0 OASIS Message Security 1.0 WS-I Basic Profile 1.1 WS-Addressing WS-Security WS-SecureConversation WS-Trust SOAP1.1/1.2
Post-conditions An acknowledgement must be sent in response to every failed message. The RM Destination must send a receipt of acknowledgment for every message received from the RM Source.
Messages Types Individual messages must use a unique group id and no sequence number is required. Group message includes more that one message and must use a unique group id and sequence number. All messages are sent in a sequence whether individual or string of messages A sequence should contain a unique sequence number and a message number.
28
Classification of Dependability Patterns
29
Future Work

• Fault-Tolerance Patterns
• Active Replication A Technique for error
  masking

30
References

• Apa05 The Apache Software Foundation, Apache
  Sandesha Apache Axis, http//ws.apache.org/s
  andesha/sandesha1.html, 2005
• Axw07 Axway,Synchrony Gateway,
  http//www.axway.com/products/synchrony_
  gateway.php, 2007.
• Bea07 BEA, BEA WebLogic Integration 10.2,
  http//www.bea.com/framework.jsp?CNToverview.htm
  FP/content/products/weblogic/integrate/, 2007
• Buc08 I. Buckley, E.B Fernandez, A Survey of
  Fault Tolerance Patterns, Department
• of Computer Science and Engineering,
  Florida Atlantic University, 2007.
• Buc08b I. Buckley, E.B Fernandez,
  WS-Reliability and WS-ReliableMessaging
  Patterns, Department of Computer Science and
  Engineering, Florida Atlantic University, 2007.
• Ebx02 OASIS, ebXML Messaging Service TC 2.0
  http//www.oasis-open.org/committees/download.php/
  272/ebMS_v2_0.pdf, April, 2002.
• For08 Forum Systems Inc., Introduction to SOA
  Gateways Best Practices. Benefits
• Requirements, http//soanetworkarchi
  tect.com/files/65856409/Best_Practices
  SOA_Gateway_v2.pdf, May, 2008.
• Fuj08 Fujitsu Limited, INTERCHANGE,
  http//www.fujitsu.com/global/services/software/in
  terstage, 2007.
• Gam94 E. Gamma, R. Helm, R. Johnson, J.
  Vlissides. Design Patterns Elements of Reusable
  Object-Oriented Software,
• Addison-Wesley, Boston, Mass.,
  1994.
• Oas04 OASIS, Web Services Reliable Messaging
  TC WS-Reliability 1.1, http//docs.oasis-open.org
  /wsrm/ws-reliability/v1.1/wsrm-
  ws_reliability-1.1-spec-os.pdf, 2004.
• Oas07 OASIS, Web Services Reliable Messaging
  (WS-ReliableMessaging) Version
• 1.1, http//docs.oasis-open.org/ws
  -rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.pdf, 2007.
• Sar02 T. Saridakis, A System of Patterns for
  Fault Tolerance, Procs. of EuroPLoP
  http//hillside.net/europlop/HillsideEurope/Papers
  /Euro PLoP2002/2002 Saridakis_ASystemOfPatternsFor
  FaultTolerance.pdf, 2002.
• Sap07 SAP Community Network, SAP NetWeaver
  Process Integration 7.1, http//www
  01.ibm.com/software/integration/wmq/index.html,
  2007.
• Web08 IBM, WebSphere MQ, http//www
  01.ibm.com/software/integration/wmq/in ex.html