Specification%20of%20Realizable%20Service%20Conversations%20Using%20Collaboration%20Diagrams

1
Specification of Realizable Service
Conversations Using Collaboration Diagrams

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu

Xiang Fu School of Computer and Information
Science Georgia Southwestern State
University xfu_at_canes.gsw.edu
2
Outline

• Modeling Service Interactions as Conversations
• Specification of Conversations Using
  Collaboration Diagrams
• Realizability of Collaboration Diagrams

3
Characteristics of Web Services

• Loosely coupled, interaction through standardized
  interfaces
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)

WS-CDL
Interaction (Choreography)
BPEL4WS
Behavior (Orchestration)
Interface
WSDL
Implementation Platforms
Microsoft .Net, Sun J2EE
SOAP
Message
XML Schema
Type
XML
Data
Web Service Standards
4
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.

5
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

6
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

7
Communication Model

• We assume that the messages among the peers are
  exchanged using reliable and asynchronous
  messaging
• FIFO and unbounded message queues

Customer
Store
order
order

• This model is similar to industry efforts such as
  
• JMS (Java Message Service)
• MSMQ (Microsoft Message Queuing Service)

8
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

9
Modeling Interactions as Conversations

• A conversation is the global sequence of messages
  recorded in the order they are sent Bultan, Fu,
  Hull, Su WWW03

Customer
Store
cdInquiry
cdAvailability
CDStore
Conversation

cdInquiry
order
cdAvailability
10
Specifying Conversations

• There are lots of allowable conversations for our
  simple example
• There are also lots of unallowable conversations

cdInq
order
cdAvail

bookInq
order
bookAvail

bookInq
order
cdInq

cdInq
order
bookInq

cdAvail
order
cdInq

bookInq
order
cdAvail

cdInq
bookInq
cdAvail
11
Specifying Conversations via Collaboration
Diagrams
sequence label
must precede
Customer
message
1/A1cdInquiry
CDSupplier
1order
A2,B2/2orderReply
A2cdAvailability
Store
1/B1bookInquiry
BookSupplier
B2bookAvailability
12
More On Collaboration Diagrams
sequence label
must precede
message
A2, B2 / 2 orderReply
asynchronous communication
conditional send
cdInquiry has CD
synchronous communication
iterative send
order
13
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
1order
1/A1cdInquiry
1/B1bookInquiry
A2cdAvailability
B2bookAvailability
A2,B2/2orderReply
final event
14
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

15
Implementation with Finite State Machines
Store
Customer
?order
?orderReply
!cdInquiry
!bookInquiry
!order
!bookInquiry
!cdInquiry
CDSupplier
?cdAvailability
?bookAvailability
!cdAvailability
!bookInquiry
!cdInquiry
?cdInquiry
?cdAvailability
?bookAvailability
?bookAvailability
BookSupplier
?cdAvailability
!bookAvailability
!orderReply
?bookInquiry
16
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

17
Realizability of Collaboration Diagrams
Realizable
Not Realizable
1order
1order
Customer
Store
Customer
Store
2orderInfo
2ship
Shipping
Depot
3ship
Shipping
Depot
18
Realizability of Collaboration Diagrams
Realizable
Not Realizable
1order
1order
Customer
Store
Customer
Store
2bill
3bill
2orderInfo
Accounting
Accounting
19
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

20
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

A1x
A2y
B3z
P
Q
R
B1y
B2x
A collaboration diagram with well-informed
events that is not separated and not realizable
21
Realizability of Collaboration Diagrams
Realizable
Not Realizable
1order
1order
Customer
Store
Customer
Store
2orderInfo
2ship
Shipping
Depot
3ship
Shipping
Depot
this send event is not well-informed
22
Realizability of Collaboration Diagrams
Realizable
Not Realizable
1order
1order
Customer
Store
Customer
Store
this send event is not well-informed
2bill
3bill
2orderInfo
Accounting
Accounting
23
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

24
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

25
THE END