The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology

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

Consistency for Web Services Applications

Paul Greenfield

(+Alan Fekete, Dean Kuo, Surya Nepal)


Web Service VisionWeb 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…


Why Are Services Different?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 ExampleeProcurement Example Multi-step stateful customer-merchant dialogue

CustomerService

quote request

quote

purchase order

confirmation

invoice

payment

receipt

goods shipped

goods received

Merchant Service


What Could Go Wrong?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


Consistency & TransactionsConsistency & 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


Inconsistent Outcomes?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...


Our ApproachOur 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


Consistency, States & MessagesConsistency, 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?


Messaging History and StatesMessaging 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…


Contracts and ProtocolsContracts 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


ContractsContracts 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, …


Contracts and ProtocolsContracts and Protocols Specify messages services can send or receive

Conditions define when messages sent or receivedSend: invoiceCondition: sent purchase order confirmation andnot sent cancel acceptReceive: paymentCondition: 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, paymentquote request, quote, purchase order, cancellation request, purchase order confirmation, cancellation reject, invoice, paymentquote request, quote, purchase order, cancellation request, cancellation accept … … …


Service CompatibilityService 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’…


Static Consistency CheckingStatic 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


Tool Development So FarTool 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


On-going WorkOn-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…


SummarySummary 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

Documents

The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology