Date post: | 16-Jan-2016 |
Category: |
Documents |
Upload: | matilda-april-woods |
View: | 218 times |
Download: | 5 times |
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)
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 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…
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?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
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 ExampleeProcurement Example Multi-step stateful customer-merchant dialogue
CustomerService
quote request
quote
purchase order
confirmation
invoice
payment
receipt
goods shipped
goods received
Merchant Service
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?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
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 & 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
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?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...
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 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
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 & 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?
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 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…
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 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
The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts.
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, …
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 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 … … …
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 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’…
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 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
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 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
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 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…
The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts.
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