Web Services Reliability Specification ( WS-Reliability )

1. Web Services Reliability Specification (WS-Reliability) Sunil Kunisetty Oracle Corp. Jacques Durand Fujitsu Software

2. What is WS-Reliability? Transport agnostic SOAP-based message protocol to send critical messages in a reliable way according to an agreed Quality of Service

3. Quality of Service (QoS) • Guaranteed Delivery • Effort to deliver at least once, ornotify failure • No Duplicate Delivery • Guarantee to deliver at most once • Exactly Once Delivery • Combining above two agreements • Ordered Delivery • Messages delivered in the order they are sent

4. Why Reliable Messaging? • Provide applications with “built in” reliability at the messaging layer, in the context of: • Multiple transports (reliable or not) • Loosely coupled services (SOA architecture) • One-way messages (MOM platforms)

5. Context and Status • Open public standard process • First version was announced in Jan 2003 • Oracle, Fujitsu, Sun, Sonic, Hitachi, NEC • Submitted to OASIS WS Reliable Messaging TC (Feb 2003) • All major industry players were invited • SeeBeyond, HP, SAP, Nokia, Cyclone Commerce, webMethods, Choreology and few others joined • Design validated by Implementations • 5 companies implemented; 2 interop demos • Working draft (v 0.51) in Sep 2003 • Just wrapped up a Committee Draft (v 0.992)

6. Overview (1) • Simple & Robust • Minimal set of ‘signals’ • Yet, supports varied use cases • Protocol survives ‘signal’ loss • Deployment friendly • Accommodates Client firewall model • Works well with limited resource too • Efficient persistence management model • Clear rules on Sender and Receiver sides

7. Overview (2) • Open and Composable • Abstract “RM Agreement” can map to any policy representation. • WSDL extensions option for supported RM features • Supports SOAP 1.1 and SOAP 1.2 • Normative HTTP binding defined • Extensible for use with other public standards

8. RM Elements PollRequest Request Response wsrm:MessageId wsrm:RefToMessageIds wsrm:NonSequenceReplies wsrm:SequenceNum wsrm:SequenceNumRange wsrm:SequenceReplies wsrm:ExpiryTime wsrm:ReplyRange any wsrm:ReplyPattern any wsrm:AckRequested wsrm:DuplicateElimination wsrm:MessageOrder any wsrm: http://www.oasis-open.org/committees/wsrm/schema/1.1/{SOAP1.1|SOAP1.2}

9. Reply Patterns • Response • RM-Reply (RM Acks and RM Faults) is sent back as a response in the same underlying connection • Primarily for WSDL 1.1 Request-Response Operations • Callback • RM-Reply is sent as a request in a different connection • Primarily for WSDL 1.1 One-way Operations • Poll • Scenarios: Behind the firewall Senders, Avoid retries, Thin client, Security constraints for Callback listeners • RM-Reply based on the a Poll Request

10. Fault Handling • Robust fault handling mechanism • Mechanism to batch faults • Mechanism to send faults for Poll requests • Independent of SOAP Fault mechanism • Fault Types • Message Format: Not well-formed headers • Message Processing: Processing errors • Faults are non-critical signals • Loss of faults are not critical to the protocol

11. Message Management • Messages: Either alone or in sequences (groups) • Message Groups • Simple life-cycle mgmt. • No prior hand shaking & no extra ‘signals’ • Group Termination options: • Timeouts (GroupMaxIdleDuration,GroupExpiryTime) • Message markers (@last=‘true’, max sequence number)

12. RM Agreement (QoS) • Defined abstractly, open to concrete representations by external policy or agreement mark-up • Abstract Items: • GuaranteedDelivery, NoDuplicateDelivery, OrderedDelivery etc. • Scopes • Per group, per message, per interaction • Sender-side deployment only

13. Agreement Criteria • Business requirements + Messaging constraints • Who sets the RM Agreement parameters? • Business partners • RM Provider based on network conditions and load • Parameters that affect the load / overhead • ReplyPattern • Resending Effort (number of retries, time interval) • Message ExpiryTime: date/time after which a message can be dropped

14. QoS Representation • The Challenge • Representation of QoS features supported by a WS need be standardized for interoperability • Many proprietary choices, but none usable in an Royalty Free OASIS specification - TODAY • Option: Define a simple & an efficient model using extensible mechanism in WSDL • Atomic QoS Properties • Plus basic composition • All, Choice, One-or-More, & Zero-or-More

15. An Example <fnp:compositor uri=“http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/all“> <fmp:feature uri=“http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/feature/rel”> <fnp:compositor uri=“http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/one-or-more”> <fnp:property name=“wsrm:NoDuplicateDelivery”> <value>true</value> </fnp:property> <fnp:property name=“wsrm:GuaranteedDelivery”> <value>true</value> </fnp:property> </fnp:compositor> </fnp:feature> </fnp:compositor>

16. Summary • Public Royalty Free specification • Doesn’t depend on proprietary private specifications. • Protocol is extensible and can work with other public specifications such as WS-Security • Interoperable Proof of Concept implementations

17. Stand-out Features • Simple, flexible, and fundamental persistence storage management model • ‘Reply Patterns’ accommodating different deployment constraints & use cases • Comprehensive Polling support • Abstract RM Agreement • Sender-side deployment only • Simple and convenient WSDL representation option

18. Q & A