Relationship between endpoint contracts and consistency in Service-Oriented Systems

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

Relationship between endpoint contracts and consistency in Service-

Oriented SystemsDean Kuo

School of Computer ScienceThe e-Science North West Centre

The University of [email protected]

Work completed at CSIRO ICT Centre Australia with Alan Fekete, Paul Greenfield, Surya Nepal


mailto:[email protected]


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


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


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


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


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

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.


Endpoint Contracts - BPEL• 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

Rec Quote Req

Send Quote

Rec Purchase Order

Send Confirmation

……..


Rec Cust CancelReq

Send Cancel Ack

Rec Cust CancelReq

Send Cancel Ack

Send Cancel reject

Send MerchantCancel

Rec MerchantCancel Ack

What messages are exchanged whencustomer and provider cancel simultaneously?

Rec Quote Req

Send Quote

Rec Purchase Order

Send Confirmation

……..

………

Send Reject Quote


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 confirmationCond: (rec PO) & (not sent confirmation) & (not sent merchant cancel) & (not rec cust cancel or sent cancel rejected)

Msg: send invoiceCond: (sent confirmation) & (not sent invoice) & (not sent merchant cancel) & (not rec cust cancel or sent cancel rejected)


Rec: Cust Cancel ReqCond: …

Send: Cancel AckCond: …

Rec: Cust Cancel ReqCond: …

Send: Cancel AckCond: …

Send: Cancel rejectCond: …

Send: Provider CancelCond: …

Rec: Provider Cancel AckCond: …

Rec: Quote ReqCond: …

Send: QuoteCond: …

Rec: Purchase Order Cond: …

Send: ConfirmationCond: …

…….. ………

Send: Reject QuoteCond: …

Rules based approach• Downside: Specification becomes too fragmented

– Lose the ordering properties, making it hard to visualise


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


Rec Quote Req

Send QuoteCond: …

Rec Purchase OrderCond: …

Send ConfirmationCond: …

……..

………

Rec Cust CancelReqCond: …

Send Cancel AckCond: …

Send Cancel RejectCond: …

Send ProviderCancelCond:

Rec ProviderCancel AckCond:


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


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


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


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


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


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


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

Relationship between endpoint contracts and consistency in Service-Oriented Systems

Documents

Transcript of Relationship between endpoint contracts and consistency in Service-Oriented Systems