a tool for choreography analysis using collaboration diagrams tevfik bultan university of california...
Post on 19-Dec-2015
220 views
TRANSCRIPT
A Tool for Choreography Analysis Using Collaboration Diagrams
Tevfik BultanUniversity of California
Santa Barbara
Xiang FuHofstra University
Chris FergusonUniversity of California
Santa Barbara
Outline
• Modeling Service Interactions as Conversations
• Specification of Conversations Using Collaboration Diagrams
• Analyzing Collaboration Diagrams
• Collaboration Diagram Extensions
• Tool Architecture and Experiments
Web Services
The World Wide Web Consortium (W3C) defines a Web service as – "a software system designed to support interoperable machine-to-
machine interaction over a network”
• Web services support basic client/server style interactions
Service Requester
Service Provider
Request
Response
SOAP
WSDL
Client Server
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.”
Web Services Standards Stack
Data
Type
Service Orchestration
Protocol
Web Services Business Process Execution Language (WS-BPEL)
Web Services Description Language (WSDL)
Simple Object Access Protocol (SOAP)
XML Schema (XSD)
Extensible Markup Language (XML)
AtomicService
AtomicService
OrchestratedService
SOAP
WSDL
WSDL
Choreography Web Services Choreography Description Language (WS-CDL)
WS-BPEL
OrchestratedService
WS-BPEL
SOAP
SOAP
SOAP
SOAPWS-CDL
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 bookInquiry 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
Asynchronous Communication Model
• We assume that the messages among the peers are exchanged using reliable and asynchronous messaging– FIFO and unbounded message queues
orderCustomer Storeorder
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 allowed conversations for our simple example:
• There are also lots of un-allowed 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
A1:cdInquiry B1:bookInquiry
{1,2,A1,A2,B1,B2}
{2,A1,A2,B1,B2}
1:order
{2,A2,B1,B2} {2,A1,A2,B2}
{2,B1,B2} {2,A1,A2}
A2:cdAvailability
{2,A2,B2}
B1:bookAvailability
{2,B2}
{2}
B2:bookAvailabililty
{2,A2}
2 : orderReply
A1:cdInquiry
A1:cdInquiry
B1:bookInquiry
B2:bookAvailability A2:cdAvailability
A2:cdAvailability B2:bookAvailability
Automata (Conversation Protocol)Construction
1:order
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
A2,B2/2:orderReply
1:order
:Store :CDSupplier
:Customer
:BookSupplier
A2,B2/2:orderReply
1/A1:cdInquiry
A2:cdAvailability
1/B1:bookInquiry
B2:bookAvailability
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 or not conditional or iterative– sender for e should be either the receiver or sender for e’
• If e’ is an asynchronous send and conditional or iterative– sender for e should be the sender for e’ and the receiver for
e should be the receiver for e’ – e should not be conditional or iterative, – e and e’ should not send the same message
• A collaboration diagram is realizable if all its events are well-informed
: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
Collaboration Diagram Extensions
• Collaboration Diagram Sets– The conversation set if the union of the conversation sets of each
collaboration diagram in the collaboration diagram set
• Collaboration Diagram Graphs– Conversation set is obtained by concatenating the conversation sets
of different collaboration diagrams according to the collaboration diagram graph
Collaboration Diagram Sets
• Collaboration diagram sets are more expressive than individual collaboration diagrams
:P :Q
1:x
2:y
:P :Q
2:x
3:y
3:z
1:z
This collaboration diagram set specifies a set of interactions that cannot be specified by any single collaboration diagram
PQ: x
PQ: y
PQ: z
PQ: z
PQ: x
PQ: y
Corresponding conversation protocol
:P :Q1:x
2:y
PQ: x
QP: y
Collaboration Diagram Graphs
• Collaboration diagram graphs are more expressive than collaboration diagram sets
This collaboration diagram graph specifies a set of interactions that cannot be specified by any collaboration diagram set
Corresponding conversation protocol
Analyzing Collaboration Diagram Extensions
• Realizability of collaboration diagram sets and collaboration diagram graphs cannot be determined using the well-informed event rule we discussed earlier
• However, collaboration diagram sets and collaboration diagram graphs can be converted to conversation protocols
• We can use the earlier results on realizability of conversation protocols to determine realizability of collaboration diagram sets and collaboration diagram graphs
RealizabilityAnalyzer
DependencyGraph
Constructor
AutomataConstructor
ConversationProtocol
Translator
CollaborationDiagrams
Realizability Analysiswith WSAT
PromelaTranslator
LTL Model Checkingwith SPIN
PeerSynthesizer
A Tool for Analyzing Collaboration Diagrams
• The tool is implemented as an Add-In to Sparx Systems Enterprise Architect UML Editor
Experiments
Problem Instance Realizability 1 Realizability 2 States
Factory Manager YES NO 383
Order Item NO NO 42 (after fix)
Purchase Order YES NO 246
Company Store YES YES 22
Information Exchange YES YES 50
Voting Booth NO NO 59 (after fix)
Causality Model YES NO 116
orderWindow:OrderEntryWindow
order:Order
macallanLine:OrderLine
deliveryItem:DeliveryItem
macallanStock:StockItem
reorderItem:ReOrderItem
1:prepareOrder
2:prepareOrderLine
3:check
4:remove?
5:needToReorder
6:newReOrder7:newDelivery?
Order Item Example
Conclusions
• Collaboration diagrams are an appropriate specification mechanism for service conversations– There are conditions which guarantee realizability of collaboration
diagrams
• Collaboration diagrams can be generalized to collaboration diagram sets and collaboration diagram graphs– Results on realizability of conversation protocols can be used to
determine realizability of collaboration diagram sets and collaboration diagram graphs
• We implemented these results in a collaboration diagram development tool
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]– …
:P :Q
1:x
2:y
:P :Q
:R
3:z
1:y
2:x
An unrealizable Collaboration Diagram Set which consists ofrealizable collaboration diagrams.
:R
:P :Q
1:x
2:y
3:z
An unrealizable Collaboration Diagram Set which consists ofrealizable collaboration diagrams.
:R :P :Q :R
1:y
2:x