Muath Alkhalaf 1 Shauvik Roy Choudhary 2 Mattia Fazzini 2 Tevfik Bultan 1
Specification of Realizable Service Conversations Using Collaboration Diagrams Tevfik Bultan...
-
date post
20-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of Specification of Realizable Service Conversations Using Collaboration Diagrams Tevfik Bultan...
Specification of Realizable Service Conversations Using
Collaboration Diagrams
Tevfik BultanDepartment of Computer Science
University of California, Santa Barbara
Xiang FuSchool of Computer and Information Science
Georgia Southwestern State University
Outline
• Modeling Service Interactions as Conversations
• Specification of Conversations Using Collaboration Diagrams
• Realizability of Collaboration Diagrams
Characteristics of Web Services
• Loosely coupled, interaction through standardized interfaces• Standardized data transmission via XML• Asynchronous messaging• Platform independent (.NET, J2EE)
Data
Type
Interface
Behavior (Orchestration)
Message
BPEL4WS
Web Service Standards
Impl
emen
tatio
n P
latf
orm
s
Mic
roso
ft .
Net
, S
un J
2EE
WSDL
SOAP
XML Schema
XML
WS-CDLInteraction (Choreography)
Service Interactions
• One of the main goals of service oriented computing is to facilitate integration and composition of services
• Modeling, specifying and analyzing interactions among services are crucial problems that need to be addressed in order to achieve this goal
• Different service developers that want their services to take part in a composition have to agree on how services will interact with each other
• Web Service-Choreography Description Language (WS-CDL)– WS-CDL specifications describe “peer-to-peer collaborations of Web
Services participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.”
An Example
• Assume four peers (individual services):– Customer, Store, CDSupplier, BookSupplier
• Workflow:– Customer sends an order to the Store– Store checks the availability of the CDs and the books in the order
by sending a cdInquiry message to CDSupplier and a book Inquiry message to BookSupplier
– CDSupplier and BookSupplier send the cdAvailability and bookAvailibility back to the Store
– Store sends orderReply to the Customer
A Model for Composite Web Services
• A composite web service consists of
– a finite set of peers• Customer, Store, CDSupplier, BookSupplier
– and a finite set of messages• Customer Store: order• Store CDSupplier: cdInquiry• Store BookSupplier: bookInquiry• CDSupplier Store: cdAvailability• BookSupplier Store: bookAvailability• Store Customer: orderReply
Communication Model
• We assume that the messages among the peers are exchanged using reliable and asynchronous messaging– FIFO and unbounded message queues
• This model is similar to industry efforts such as – JMS (Java Message Service)– MSMQ (Microsoft Message Queuing Service)
orderCustomer Storeorder
Questions and Challenges
• Questions– How do we model the global interaction behavior?– How do we make sure that the global behavior is implemented
faithfully by the services that participate to the composition?
• Challenges– Distributed nature, no central control– Asynchronous communication
Modeling Interactions as Conversations
• A conversation is the global sequence of messages recorded in the order they are sent [Bultan, Fu, Hull, Su WWW’03]
Conversation
orderCustomer
CDStore
Store
cdInquiryorder
cdInquirycdAvailability
cdAvailability …
Specifying Conversations
• There are lots of allowable conversations for our simple example:
• There are also lots of unallowable conversations:
cdInqorder cdAvail …bookInqorder bookAvail
bookInqorder cdInq
…
cdInqorder bookInq
……
cdAvailorder cdInq
bookInqorder cdAvail
cdInqbookInq cdAvail
……
…
1:order
:Store
:CDSupplier
:Customer
:BookSupplier
A2,B2/2:orderReply1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
Specifying Conversations via Collaboration Diagrams
messagesequencelabel
mustprecede
More On Collaboration Diagramssequencelabel
mustprecede
A2, B2 / 2 : orderReply
message
asynchronouscommunication
synchronouscommunication
cdInquiry [has CD]
conditionalsend
order*iterativesend
1:order
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
A2,B2/2:orderReply
Dependency Among Message Send Events
• Message send events are ordered based on two rules– Implicit: The sequence labels that have the same prefix must be
ordered based on their sequence number– Explicit: The events listed before “/” must precede the current event
initial event
final event
Implementing a Conversation Specification
• Given a conversation specification in the form of a collaboration diagram– we would like to implement a composite service which generates
exactly the set of conversations specified by the collaboration diagram
• The composite web service that generates the exact set of conversations specified by the collaboration diagram realizes the collaboration diagram
• We use finite state machines as the computational model for peers– Note that, each peer has an unbounded input queue for the
incoming messages– This is similar to Communicating Finite State Machines model
Store
CDSupplier
?cdInquiry
!cdAvailability
!cdInquiry !bookInquiry
?order
?cdAvailability
!cdInquiry!bookInquiry
?cdAvailability
!bookInquiry
?bookAvailability
?bookAvailability
?bookAvailability
!cdInquiry
?cdAvailability
!orderReply
BookSupplier
?bookInquiry
!bookAvailability
Customer
!order
?orderReply
Implementation with Finite State Machines
Realizability of Collaboration Diagrams
• Not all collaboration diagrams are realizable!
• It is possible to specify interactions that cannot be realized by any peer implementation
• This is a problem!– Assume that we want to specify how several services should interact
with each other– If we write a specification that is not realizable
• the implementation will not be faithful to the specification no matter what we do
:Customer :Store
1:order
:Shipping :Depot
2:ship
Realizability of Collaboration Diagrams
:Customer :Store
1:order
:Shipping :Depot
3:ship
2:orderInfo
RealizableNot Realizable
Realizability of Collaboration Diagrams
RealizableNot Realizable
:Customer :Store
:Accounting
2:bill
1:order
:Customer :Store
:Accounting
3:bill
1:order
2:orderInfo
A Sufficient Condition for Realizability
• We call a send event e well informed – If e is an initial event– Otherwise, let e’ be an immediate predecessor of e
• If e’ is a synchronous send and not conditional or iterative– sender for e should be either the receiver or sender for e’
• If e is an asynchronous send or conditional or iterative– sender for e should be the sender for e’, e should not be
conditional or iterative, e and e’ should not send the same message
• A separated collaboration diagram is realizable if all its events are well-informed
Separated Collaboration Diagrams
• A collaboration diagram is separated if two different message send events send the same message only if their sequence labels have the same prefix
:P :Q
A1:x
A2:y
B1:y
B2:x
:R
B3:z
A collaboration diagram with well-informed eventsthat is not separated and not realizable
:Customer :Store
1:order
:Shipping :Depot
2:ship
Realizability of Collaboration Diagrams
:Customer :Store
1:order
:Shipping :Depot
3:ship
2:orderInfo
RealizableNot Realizable
this send eventis not well-informed
Realizability of Collaboration Diagrams
RealizableNot Realizable
:Customer :Store
:Accounting
2:bill
1:order
:Customer :Store
:Accounting
3:bill
1:order
2:orderInfo
this send eventis not well-informed
Related Work
• Message Sequence Charts (MSC) – Realizability [Alur, Etassami, Yannakakis ICSE 00, ICALP 01]– Implied scenarios [Uchitel, Kramer, Magee ACM TOSEM 04]
• Modeling agent conversations with Dooley graphs [Parunak, ICMAS 96]
• Conversation protocols [Fu, Bultan, Hull, Su WWW 03] [Fu, Bultan, Su, TCS 04, IEEE TSE 05]
• Modeling services using UML diagrams– [Benatallah, Sheng, Dumas, IEEE IC 03]– [Skogan, Gronmo, Solheim IEEE EDOCC 04]– [Blake ICWS 06]– …
Conclusions and Future Work
• Collaboration diagrams are an appropriate specification mechanism for service conversations
• We gave a realizability condition for a restricted class of collaboration diagrams
• We are currently working on – investigating the relationship between conversation protocols and
collaboration diagrams– investigating extensions of collaboration diagrams– synthesizing implementations from realizable collaboration diagrams
automatically
THE END