1. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Consistency for Web Services Applications Paul Greenfield (+Alan Fekete, Dean Kuo, Surya Nepal)

2. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Web Service Vision  Internet-scale distributed applications  Composed from autonomous & opaque ‘services’  Service behaviour/expectations ideally defined by contracts  Services often stateful with multiple related interactions  Limited trust between participants  Running over public networks?  Services open to all (authenticated?) callers?  No direct access to internal state possible or allowed  Nice vision, but will prove hard to realise  All the old distributed computing problems still around  Inconsistent outcomes & other errors quite likely…

3. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Why Are Services Different?  Autonomous  Participants can behave as they wish… …as long as they comply with their contract  Cannot assume central coordinator or controller  Opaque  Only know about contracts & defined behaviour  Cannot look inside services to determine their state  Limited trust  Would you trust callers to release locks?  Makes traditional distributed transactions infeasible

4. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. eProcurement Example  Multi-step stateful customer-merchant dialogue

5. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. What Could Go Wrong?  Failure to terminate (deadlocks, starvation, …)  Merchant & customer waiting for each other  Unprocessed messages left after termination  Payment reminder after customer terminated  Inconsistent outcomes  Services must finish in globally consistent states  Customer must reflect merchant’s state & vice versa  …both think payment has been made or not…  Problem long solved by transactions…  All participating services must always reach agreed consistent outcomes

6. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Consistency & Transactions  Traditional distributed transaction problem  Already solved by X-Open, CICS, …  What about WS transaction standards?  WS-AT assumes trust and timeliness  Good support for consistency and isolation  Very limited applicability in open services world  WS-BA termination protocol only  Coordinating termination, possibly invoking compensators  Doesn’t really address consistency or isolation  BTP, WS-CAF, …  Patterns and related protocols only

7. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Inconsistent Outcomes?  How could a distributed application finish with its participating services in inconsistent states?  How can the merchant and customer disagree?  Paid and not paid, goods delivered and goods not received??  What exchange of messages lead to this outcome???  Messages rejected or unprocessed?  Incompatibility between customer & merchant processes?  Protocol errors and faulty designs  Being able to reach inconsistent outcomes is a design fault...

8. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Our Approach  Tools, programming models/patterns to…  Detect correctness/consistency faults at design time  Test for compatibility between participating services  Test that nothing bad can possibly happen  Detect consistency faults at run time  Patterns for defining correct application protocols  … based on relationship between states & msgs  Transforms consistency to protocol problem and…  … lets us use protocol verification tools to detect inconsistent outcomes and other errors at design time  Basis of run time checking protocol as well

9. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Consistency, States & Messages  Set of participating services must finish in one of an agreed set of consistent distributed ‘states’  (payment sent & payment received and goods received & goods sent) or …  Specified using global constraint expressions?  Expressions over internal service state?  Not possible given opaque nature of services  Not possible for external coordinator to observe states  All we know is what messages have been sent and received between the participants  So can we use expressions over messaging history?

10. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Messaging History and States  All internal state that needs to be referenced in consistency expressions will be unambiguously reflected in protocol messages  ‘Payment complete’  receipt message  We assert this is true for significant no. of applications  Just reflects normal business practices  Occurrence of message is proxy for state change  Allows consistency expressions referring only to messages exchanged between participants  Lets us transform consistency problem into a protocol correctness one…  So we need to look at protocols and correctness…

11. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Contracts and Protocols  Application protocol  Set of all possible message sequences that can be exchanged between participating services  Results from interactions between contracts…  Contract  Abstract definition of externally observable messaging behaviour of a service  Specify messages that can be sent and received  Specify causal relationship between these messages  (extension) Specify local acceptable consistency constraints at termination

12. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Contracts  More than WSDL needed…  Asynchronous messages very common  Add complexity to protocol & application design  Timeouts, exceptions, cancellation, …  … add the possibility of races, deadlocks, …  Sending late fee while payment in transit  Could result in inconsistent outcomes  Needed simple & expressive contract language  Defined condition-based contracts language  Similar to ECA programming languages  Concise & expressive way to specify behaviour  Especially when asynchronous messages allowed  More concise than BPEL4WS, CSP, …

13. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Contracts and Protocols  Specify messages services can send or receive  Conditions define when messages sent or received Send: invoice Condition: sent purchase order confirmation and not sent cancel accept Receive: payment Condition: sent invoice and not sent cancel accept  Used in SSDL Rules protocol framework  Given 2 contracts we could derive (enumerate) the corresponding application protocol  Just the set of all possible message sequences quote request, quote, purchase order, purchase order confirmation, invoice, payment quote request, quote, purchase order, cancellation request, purchase order confirmation, cancellation reject, invoice, payment quote request, quote, purchase order, cancellation request, cancellation accept … … …

14. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Service Compatibility  Two services are ‘compatible’…  If their contracts result in ‘correct’ application protocol  Is my client compatible with Amazon’s service?  All possible interactions lead to correct outcomes  Customer and merchant interactions will always terminate & reach consistent outcomes…  Both sides always only send ‘acceptable’ messages  Not all messages have to be used…  Merchant may support more payment types than customer  Contracts can support negotiation  Cancellation allowed, payments accepted, …  Could negotiate to null and still be ‘correct’…

15. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Static Consistency Checking  Design-time tools for finding errors  Define contracts of participating services  Check that all sequences meet correctness criteria  Always terminate  No unprocessed messages at termination  Message-based consistency constraints always hold  Find and fix contract errors that result in failures  Proof-of-concept built using SPIN  Model-checker used for protocol verification  Contracts specified in PROMELA  Global consistency constraints in LTL  Constraints and contracts written by hand using WS-BA protocol elements for termination

16. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Model Checking  SPIN generates all possible message sequences  Including all allowable orderings  Some messages marked as ‘final’  SPIN checks …  All messages compatible with contracts  No messages left unprocessed at termination  All sequences result in termination  And… global consistency constraints satisfied  Expressions referring only to messages sent or received  Example - agreement on delivery and payment  Merchant sent receipt & received goods received  Customer received receipt & sent goods received  Many alternative acceptable outcomes possible

17. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Tool Development So Far  Correctness checking from SSDL Rules  Extend SSDL Rules with local consistency constraints  Assuming global constraints can be derived from local constraints – formal proof still to be done  Generate PROMELA & LTL definitions  Run contract compatibility/correctness check  Generate SSDL rules from program definition  Event-based programming model (GAT)  Also generate C# code from GAT description  Extending SSDL rules to invoke WS-BA termination paths

18. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Protocol Design Lessons  Designing error-free contracts proved hard  Race conditions and unprocessed messages  Use of WS-BusinessActivity helped  Standard toolkit of termination protocol paths  Resolved many termination-related problems  State must always be reflected in messages  Changes to merchant’s ‘paid’ state always signalled  Merchant reaches ‘paid’ state  receipt message sent  Must be unambiguous  Receipt message can only mean merchant is ‘paid’  Just reflects traditional business processes…

19. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. On-going Work  Run-time consistency checking  Protocol to check consistency at termination  Static checking just proves presence of design flaws  Check for local consistency and ask neighbours  Reflected state links participants  No need for global constraints and coordinator  Isolation patterns and protocols  Looking into pattern-based answers to isolation  More formal correctness proofs  Multi-party extensions  Use of local consistency constraints  Validity of state-message assertion…

20. The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts. Summary  Consistency, correctness and compatibility  Impediments hindering the Web Services vision  Tool-based approach to finding design flaws  Consistency-related state signalled by messages  Consistency constraints can refer only to messages  Allows use of protocol verification tools  Check for correctness, including consistent outcomes  Proof-of-concept and follow-on tools produced  WS-BA proved very useful as termination toolkit  Working on dynamic checking protocol  Based on local consistency and reflected state  See VLDB 2005 paper