Consistency for Web Services Applications

Consistency for Web Services Applications Paul Greenfield

Web Service Vision • Internet-scale distributed applications • Composed from autonomous & opaque ‘services’ • Custom code, packages, partners (Amazon, DHL, …) • Service behaviour/expectations ideally defined by contracts • Services often stateful with multiple related interactions • Platform and language agnostic • Limited trust between participants • Running over public networks? • Services open to all (authenticated?) callers? • No direct access to internal state • Nice vision, but will prove hard to realise • All the old distributed computing problems still around • Inconsistent outcomes & other errors quite likely…

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

eProcurement Example • Multi-step stateful customer-merchant dialogue • Normal case simple; complexities come from application exceptions, asynchronicity & concurrency

What Could Go Wrong? All participating services must always reach agreed consistent outcomes • 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…

Consistency & Transactions • Traditional distributed transaction problem • Already solved by X-Open, CICS, … • What about WS transaction standards? • WS-AT assumes trust and timeliness • Conventional ACID transactions with 2-phase commit • Good support for consistency and isolation • 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

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 • Introduces ‘correctness’ & ‘compatibility’ • Being able to reach inconsistent outcomes is a design fault...

Our Approach • Tools, programming models, patterns • Detect correctness/consistency faults at design time • Test for compatibility between services • Detect consistency faults at run time • Patterns for defining correct application protocols • Using relationship between states & messages • Transform consistency into protocol correctness • Use protocol verification tools to detect inconsistent outcomes and other errors at design time • Basis of run time checking protocol as well

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/received • Try expressions over messaging history…

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 protocol correctness problem… • So we need to look at protocols…

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

Contracts • 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, … • Specify messages each service can send or receive • Conditions state when messages can be 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

Contracts and Protocols • Given 2 contracts we can derive (enumerate) the corresponding application protocol • Just the set of all possible message sequences quote request, quote, purchase order, purchaseorder confirmation, invoice, payment quote request, quote, purchase order, cancellation request, purchase order confirmation, cancellationreject, invoice, payment quote request, quote, purchase order, cancellation request, cancellation accept … … … • Asynchronous messages commonly needed • 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

Static Consistency Checking • Design-time tools for finding errors • Define contracts of participating services • Generate application protocol message sequences • 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

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 • Referring only to messages sent or received • Agreement on delivery and payment • Merchant sent receipt & received goods received • Customer received receipt & sent goods received • Many alternative acceptable outcomes possible

Service Compatibility • Or… checking if 2 services are ‘compatible’ • All possible interactions lead to correct outcomes • Customer and merchant interactions will always terminate & reach consistent outcomes… • Both sides always only send ‘acceptable’ messages • Is my client compatible with Amazon’s service? • Not all messages have to be used… • Merchant may support more payment types than customer • Contracts can support negotiation • Cancellation allowed, payments accepted, …

Tool Development • Correctness checking from SSDL Rules • Extend SSDL Rules with local consistency constraints • Assuming global constraints can be derived from local constraints • 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

Protocol Design • 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…

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 solutions to isolation • More formal correctness proofs • Multi-party extensions • Use of local consistency constraints • Validity of state-message assertion…

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 • Working on dynamic checking protocol • Based on local consistency and reflected state

Consistency for Web Services Applications