Specification of Realizable
Service Conversations Using
Collaboration Diagrams
Tevfik Bultan
Xiang Fu
Department of Computer Science
University of California, Santa Barbara
bultan@cs.ucsb.edu
School of Computer and Information Science
Georgia Southwestern State University
xfu@canes.gsw.edu
Outline
• Modeling Service Interactions as Conversations
• Specification of Conversations Using Collaboration Diagrams
• Realizability of Collaboration Diagrams
Characteristics of Web Services
Interaction (Choreography)
Behavior (Orchestration)
WS-CDL
BPEL4WS
Interface
WSDL
Message
SOAP
Type
Data
XML Schema
XML
Web Service Standards
Implementation Platforms
Loosely coupled, interaction through standardized interfaces
Standardized data transmission via XML
Asynchronous messaging
Platform independent (.NET, J2EE)
Microsoft .Net, Sun J2EE
•
•
•
•
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
Customer
order order
Store
• This model is similar to industry efforts such as
– JMS (Java Message Service)
– MSMQ (Microsoft Message Queuing Service)
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]
order
Customer
Store
cdAvailability
cdInquiry
CDStore
Conversation
order
cdInquiry
cdAvailability
…
Specifying Conversations
• There are lots of allowable conversations for our simple example:
order
cdInq
cdAvail
order
bookInq
bookAvail
order
bookInq
cdInq
order
cdInq
bookInq
…
…
…
…
• There are also lots of unallowable conversations:
order
cdAvail
cdInq
order
bookInq
cdAvail
bookInq
cdInq
cdAvail
…
…
…
Specifying Conversations via Collaboration Diagrams
:Customer
must
precede
sequence
message
label
1/A1:cdInquiry
1:order
A2,B2/2:orderReply
:CDSupplier
A2:cdAvailability
:Store
1/B1:bookInquiry
:BookSupplier
B2:bookAvailability
More On Collaboration Diagrams
must
precede
sequence
label
message
A2, B2 / 2 : orderReply
asynchronous
communication
conditional
send
cdInquiry [has CD]
synchronous
communication
order*
iterative
send
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
1:order
1/A1:cdInquiry
1/B1:bookInquiry
A2:cdAvailability
B2:bookAvailability
A2,B2/2:orderReply
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
Implementation with Finite State Machines
Store
Customer
?order
!cdInquiry
?orderReply
!bookInquiry
!order
!bookInquiry
!cdInquiry
?cdAvailability
?bookAvailability
!bookInquiry
CDSupplier
!cdAvailability
!cdInquiry
?cdAvailability
?bookAvailability
?cdInquiry
?bookAvailability
BookSupplier
?cdAvailability
!orderReply
!bookAvailability
?bookInquiry
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
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
:Store
:Store
2:orderInfo
2:ship
:Shipping
:Customer
:Depot
3:ship
:Shipping
:Depot
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
2:bill
:Store
:Customer
:Store
3:bill
2:orderInfo
:Accounting
:Accounting
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 wellinformed
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
A1:x
A2:y
:P
B3:z
:Q
:R
B1:y
B2:x
A collaboration diagram with well-informed events
that is not separated and not realizable
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
:Store
:Store
2:orderInfo
2:ship
:Shipping
:Customer
:Depot
3:ship
:Shipping
this send event
is not well-informed
:Depot
Realizability of Collaboration Diagrams
Not Realizable
Realizable
1:order
1:order
:Customer
2:bill
:Store
this send event
is not well-informed
:Customer
:Store
3:bill
2:orderInfo
:Accounting
:Accounting
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