Secure Systems Research Group - FAU 1 WS-ReliableMessaging Pattern Part II Ingrid Buckley Dept. of...

Secure Systems Research Group - FAU1

WS-ReliableMessaging Pattern Part II

Ingrid BuckleyDept. of Computer Science and Engineering

Florida Atlantic UniversityBoca Raton, FL, USA

October 2, 2008.


Agenda

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


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:1. The web services standard that are most used in industry and

in commercial products

2. In enumerating dependability patterns which included fault tolerance pattern we identified patterns that required improvements and areas that were not not yet supported.


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.


Objective

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


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


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.


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?


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


• 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:

Solution


Figure 1: Class Diagram for the WS-ReliableMessaging pattern


SolutionStructure: • 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.


SolutionDynamics:

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.


SolutionDynamics: Description:

1. The Application Source creates and sends a message to the RM Source.2. 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.

3. The RM Source transmits the reliablemessage wrapped in this new sequence to the RM Destination.

4. The RM Source sends a terminate sequence request to the RM Destination when it has no more messages to transmit in a given sequence.

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

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

7. The Destination Application receives messages from the RM Destination.Post condition: An acknowledgement is sent for all messages received by the RM Destination.


Figure 2: Sequence Diagram illustrating the sending a Reliable message


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


Figure 3: Sequence Diagram for use case: Establishing an agreement/contract


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 messages[Oas07].

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


Implementation• A security context has to be developed separately if secured

exchange of messages is required[Oas07], 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.


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.


ConsequencesConsequences:• 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.


Known Uses

The following commercial products utilizes the WS-ReliableMessaging Pattern:

• SAP NetWeaver Process Integration 7.1[Sap07] 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


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.


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.


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.


WS-Reliability vs WS-ReliableMessaging Standard\Properties WS-Reliability WS-ReliableMessaging

Components 1.Producer2.Consumer3.Sending RMP4.Receiving RMP

1.Application Source2.Destination Source3.RM Source4.RM Destination

Protocol Preconditions 1.SOAP-based Protocol2.Quality of Service(QoS) defines quality of messaging service to communication endpoints3.wire protocol must have specific message headers and specific message choreographies between endpoints4.Defined Contract between the two RMP and endpoints

1.Must have endpoint referencing that uniquely identifies RM destination endpoint.2.RM Source must create a new Sequence with unique identifier with the RM Destination.3.The RM Source MUST be capable of formulating messages that adhere to the RM Destination's policies.4.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:1.AtLeastOnce 2.AtMostOnce 3.ExactlyOnce4.InOrderReliability Features:1.Duplicate Elimination2.Message state Disposition3.Ordering4.Guaranteed receipt


Messaging Context andMessaging Agreement

Assumptions:1.SOAP Intermediary transparency2.Message IntegrityContext1.Four Operations (Submit Deliver, Respond, Notify) used to model reliability contracts between RMP’s.2.The RMP must know which SOAP MEP is being used when sending or receiving a reliable message.3.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 1.SOAP1.1/1.22.OASIS ebXML Message Service Specifcation 2.03.OASIS Message Security 1.04.WS-I Basic Profile 1.1

1.WS-Addressing2.WS-Security3.WS-SecureConversation4.WS-Trust5.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.

WS-Reliability vs WS-ReliableMessaging


Classification of Dependability Patterns


Future Work

• Fault-Tolerance Patterns:

– Active Replication : A Technique for error masking


References[Apa05] The Apache Software Foundation,“ Apache Sandesha Apache Axis”,

http://ws.apache.org/sandesha/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?CNT=overview.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://soanetworkarchitect.com/files/65856409/Best_Practices SOA_Gateway_v2.pdf, May, 2008.[Fuj08] Fujitsu Limited, “INTERCHANGE”, http://www.fujitsu.com/global/services/software/interstage, 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_ASystemOfPatternsForFaultTolerance.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

Secure Systems Research Group - FAU 1 WS-ReliableMessaging Pattern Part II Ingrid Buckley Dept. of...

Documents

Transcript of Secure Systems Research Group - FAU 1 WS-ReliableMessaging Pattern Part II Ingrid Buckley Dept. of...