Relationship between endpoint contracts and consistency in Service-Oriented Systems

1. Relationship between endpoint contracts and consistency in Service-Oriented Systems Dean Kuo School of Computer Science The e-Science North West Centre The University of Manchester dkuo@cs.man.ac.uk Work completed at CSIRO ICT Centre Australia with Alan Fekete, Paul Greenfield, 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. 1

2. Discussion • How do we • Specify Consistency properties • Two types of properties • Application dependent • Application independent • Model service endpoint contracts • Verify application protocols defined by endpoint contracts will always maintain consistency • Limitations

3. Consistency Properties I • Application independent properties • The application protocol will eventually terminate • No deadlocks • Always, no service sends or receives any messages once an interaction instance has terminated • Leaving messages unprocessed is an indication services may have terminated in incompatible messaging states • Customer service terminates once it sends payment but then receives a late fee invoice • Bad design practice if messages are left unprocessed

4. Consistency Properties II • Dependent on the application • Termination properties • Always, at termination, all services reach an agreed outcome • For example, customer and merchant services agree an item has been delivered and payment has been received. • Intermediate properties • Always, payment must be received before goods are shipped • Consistency Properties can be formally specified using temporal logic

5. Modeling Endpoint Contracts • Model must be sufficiently expressive • Contain enough details to derive if an application defined by two endpoint contracts will always maintain consistency • However, the model must be simple • Overly complex models will make it difficult to specify an endpoint contract

6. Endpoint Contracts - WSDL • Message exchange patterns (MEPS) • Specifies the in and out messages • Can not specify general message ordering properties • Can not specify messages that are optional • Is getting a quote optional or mandatory? • No possibility of deriving whether an application protocol defined by two service contracts will always maintain consistency

7. Endpoint Contracts - BPEL Rec Quote Req • Workflow languages • Easily describe simple message flows • Application exceptions can occur at anytime • Asynchronous behaviour is unavoidable • E.g. Cancellation • However, we need to specify what happens when either party cancels the ordering process • Purchaser • Can cancel the process anytime before sending a purchase order to the merchant • Can request to cancel an order but the merchant decides if the request is accepted or rejected • Merchant may need to cancel anytime during the ordering process until the sale is closed Send Quote Rec Purchase Order Send Confirmation ……..

8. Rec Quote Req Send Reject Quote Send Quote Rec Cust Cancel Req Send Cancel Ack What messages are exchanged when customer and provider cancel simultaneously? Rec Purchase Order Send Confirmation …….. Send Cancel Ack Send Merchant Cancel Rec Cust Cancel Req ……… Send Cancel reject Rec Merchant Cancel Ack ?

9. Rules based approach • Using conditions to specify when messages can be sent and received • Conditions mention what msgs sent and/or received • Used in SSDL Rules framework • Upside: simple expression of specifying (esp asynchronous) messaging behaviour Msg: send confirmation Cond: (rec PO) & (not sent confirmation) & (not sent merchant cancel) & (not rec cust cancel or sent cancel rejected) Msg: send invoice Cond: (sent confirmation) & (not sent invoice) & (not sent merchant cancel) & (not rec cust cancel or sent cancel rejected)

10. Rules based approach • Downside: Specification becomes too fragmented • Lose the ordering properties, making it hard to visualise Send: Provider Cancel Cond: … Send: Confirmation Cond: … Send: Reject Quote Cond: … Rec: Cust Cancel Req Cond: … Send: Cancel Ack Cond: … Send: Quote Cond: … Rec: Quote Req Cond: … …….. ……… Send: Cancel Ack Cond: … Rec: Provider Cancel Ack Cond: … Send: Cancel reject Cond: … Rec: Cust Cancel Req Cond: … Rec: Purchase Order Cond: …

11. Hybrid Approach • A service contract is best specified as a set of message flows • Conditions define the relationship between the flows • We have successfully specified a number endpoint contracts

12. Rec Quote Req Rec Cust Cancel Req Cond: … Send Quote Cond: … Rec Purchase Order Cond: … Send Provider Cancel Cond: Send Confirmation Cond: … …….. Send Cancel Ack Cond: … Send Cancel Reject Cond: … Rec Provider Cancel Ack Cond: ………

13. Features • Succinct compared to workflow languages when dealing with asynchronous messaging behaviour • Is more expressive than message exchange patterns (MEPS) • Sufficient information to derive whether an application maintains consistency

14. Verifying Consistency • Consistency Properties • Always eventually terminate, agreed final termination messaging state, no message sent or received after termination. • Manual verification is too labour intensive and time consuming • Automated verification? • Requirements for verification tool • Support temporal logic to express consistency properties • Always, eventually, … • Describe endpoint contracts • Reason about the connection

15. Verification Tools • Model checkers • SPIN, … • Initial motivation was to learn about asynchronous application protocol design • Just how hard or easy is it to design application protocols • We have used SPIN to specify endpoint contracts and consistency properties • Successfully verified a number of use cases • Ordering a book, payment, … • Used the hybrid approach in specifying endpoint contracts

16. Using Model Checkers • Showed the hybrid method is viable • Model checking code reflects the hybrid approach in modeling endpoint contract • Showed viability of using tools to verify consistency • Designing application protocol was difficult due to asynchronous messaging behaviour • Too many possible sequences of message exchange • Adopted a termination protocol similar to WS-BusinessActivity • Added a transition

17. Limitations • Hybrid approach for specifying endpoint contracts does not scale for complex multistage application protocols • One strategy is to reach intermediate agreement • However, we need to solve the composition problem • Even worse with multiple parties • Model checker limits • State space explosion as model checkers rely on a brute force search

18. What Now • Find a more abstract, succinct with sufficient expressiveness to model endpoint contracts • Find other tools for automate or semi-automated verification • Experience in application protocol design can be documented as patterns • But we first need to gain experience in designing complex multi-party application protocols

19. Conclusion • Consistency properties for service oriented systems can be defined in terms of messaging state • Asynchronous messaging behaviour is unavoidable in service oriented systems • The simplest method for modeling endpoint contracts is to use the hybrid approach • A set of message flows and with conditions • We can use model checkers to automate verification • Define consistency properties in temporal logic