Component-based design and connector synthesis(Lecture 2)
Massimo Tivoli and Marco AutiliEmail: {massimo.tivoli, marco.autili}@univaq.it
GSSI PhD in Computer Science L’Aquila, ItalyNov 11th, 2013
Roadmap of this lecture
•By Massimo Tivoli•automatic synthesis of modular connectors via composition of protocol mediation patterns [ICSE2013]
•By Marco Autili
•automatic synthesis of service choreographies [FASE2013,SERENE2013,WCRE2013,RESS2011]
Problem and motivations
•How to achieve interoperability among heterogeneous NSs by solving protocol mismatches?
•State-of-the-art solutions•hand-coded software connectors•automatically synthesized software connectors
•Their drawbacks•connector development is a never-ending and error-
prone task•NSs interoperability depends on the interoperability of
the respective underlying technologies•not all possible protocol mismatches are solvable•current solutions produce monolithic connectors
Our solution
•A method for the automatic synthesis of modular connectors•composition of independent mediators•each mediator realizes a mediation pattern•patterns as primitive solutions to recurring protocol mismatches
•Advantages•correctness as freedom from possible mismatches•connector evolution
Preamble - Interaction Protocol Specification (IPS)
• It is an Interface Automaton (IA) slightly revised in order to account for semantically equivalent actions
• Note that the action sets of an IA must be disjoint
ba'
a
b
a
a'
Preamble - composition of two IPSs
IPS2
IPS1 IPS2
ba'
a
b
a
a'
IPS1ca
a'
c
a'
a
IPS1 || IPS2
b
c
a b c a
cinconsistency
they became hiddenin the composition
Preamble – connector algebra
• Mediator patterns ( )
• Connectors as composition of primitive mediators
aa
Cons(a)NoOp
aa
Prod(a)
ba
Trans(a,b)
ba
a1
a
Split(a,[a1,…,an])
a1
aan…
an… a1
a
Merge([a1,…,an],a)
a1
aan…
an…
a1
Order([a1,…,an],π, [a'1,…,a'n])
(π is a permutation of 1,…,n)
a1 an…
an…
…
a'π(n)…a'π(1)
a'π(1) a'π(n)
Composition Iteration
The purchase order mediation scenario
• From the Semantic Web Service (SWS) Challenge: http://sws-challenge.org/wiki/
• Two NSs implemented using different standards and protocols: the Moon Client (MC) and the Blue Service (BS)
MOONClient(MC)
Login CreateOrder SelectItem SetItemQuantity
CloseOrderConfirmItemClose PayThirdParty
Login CreateOrder SelectItem SetItemQuantity
PayThirdParty
Close
ConfirmItemCloseOrder
BLUEService
(BS)StartOrder AddItemToOrder GetConfirmation PlaceOrder Quit
GetConfirmation
StartOrderAddItemToOrder
AddItemToOrder
Quit
GetConfirmation
PlaceOrder
Communicationmismatches concernthe semantics andgranularity of protocolactions
The purchase order mediation scenario
<<OWLClass>>PayThirdParty
<<OWLClass>>GetConfirmation
<<OWLClass>>ConfirmItem
<<OWLClass>>PlaceOrder
<<OWLClass>>CloseOrder
<<OWLClass>>CreateOrder
<<OWLClass>>StartOrder
<<OWLClass>>Login
isPartOf{some}
isPartOf{some}<<OWLClass>>
Close
<<OWLClass>>Quit
isPartOf{some}
• From the Semantic Web Service (SWS) Challenge: http://sws-challenge.org/wiki/
• Two NSs implemented using different standards and protocols: the Moon Client (MC) and the Blue Service (BS)
subsumptionprop{card}
objectProperty –ontological relation
<<OWLClass>>…
ontological concept
Domain Ontology (DO)
<<OWLClass>>AddItemToOrder
{hasPart some SelectItem, SetItemQuantity}
<<OWLClass>>SelectItem
{isPartOf some addItemToOrder}
<<OWLClass>>SetItemQuantity
{isPartOf some addItemToOrder}
isPartOf{some} isPartOf{some}
To solve communicationmismatches, it is necessaryto use ontology knowledgein order to align the twoprotocols to the sameconcepts and language
The purchase order mediation scenario
• From the Semantic Web Service (SWS) Challenge: http://sws-challenge.org/wiki/
• Two NSs implemented using different standards and protocols: the Moon Client (MC) and the Blue Service (BS)
MOONClient(MC)
Login CreateOrder SelectItem SetItemQuantity
CloseOrderConfirmItemClose PayThirdParty
Login CreateOrder SelectItem SetItemQuantity
PayThirdParty
Close
ConfirmItemCloseOrder
BLUEService
(BS)StartOrder AddItemToOrder GetConfirmation PlaceOrder Quit
GetConfirmation
StartOrderAddItemToOrder
AddItemToOrder
Quit
GetConfirmation
PlaceOrder
Coordinationmismatches concernthe control structureof the protocols
11 Automatic Synthesis ofCommunication Mediators
Method overview
PP
RR
DODO Synthesis ofCommunication
Mediators
Synthesis ofCommunication
Mediators
1.11.1
WW
Wi
Wj
AutomaticSynthesis ofCoordination
Mediators
AutomaticSynthesis ofCoordination
Mediators
22
M=(||Mk)M=(||Mk)
Mx
My
AlphabetAlignmentAlphabetAlignment
1.21.2P wrapped-by WP wrapped-by W
R wrapped-by WR wrapped-by W
Automatic synthesis of communication mediators
• Synthesis of communication mediators out of subsumption relations
<<OWLClass>>PlaceOrder
<<OWLClass>>CloseOrder
CloseOrder is subsumed by PlaceOrder
PlaceOrder CloseOrder x2
CloseOrder x2
M2 =
PlaceOrder
x2
x2
||
Automatic synthesis of communication mediators
• Synthesis of communication mediators out of subsumption relations
<<OWLClass>>PlaceOrder
<<OWLClass>>CloseOrder
CloseOrder is subsumed by PlaceOrder
PlaceOrder CloseOrder x2
CloseOrder
M2 =
PlaceOrder
Automatic synthesis of communication mediators
• Synthesis of communication mediators out of subsumption relations
<<OWLClass>>PlaceOrder
<<OWLClass>>CloseOrder
CloseOrder is subsumed by PlaceOrder
PlaceOrder CloseOrder
CloseOrder
M2 =
PlaceOrder
Automatic synthesis of communication mediators
• Synthesis of communication mediators out of aggregation relations
CreateOrder and Login are part of StartOrder
<<OWLClass>>CreateOrder
<<OWLClass>>StartOrder
<<OWLClass>>Login
isPartOf{some}
isPartOf{some}
StartOrder
M5 =
Login
Login
CreateOrder
CreateOrder
Login
StartOrder
CreateOrder
Alphabet alignment
• When synthesized out of a subsumption (resp., aggregation) relation, a mediator is used as a wrapper for output (resp., input) actions of a protocol
StartOrder
M5 =
Login
Login
CreateOrder
CreateOrder
Login
StartOrder
CreateOrder
PlaceOrder CloseOrder
CloseOrder
M2 =
PlaceOrder
StartOrder PlaceOrder
StartOrder
PlaceOrder
P =
Alphabet of P ={StartOrder, PlaceOrder}
• P is an excerpt of the BLUE service• As second protocol, let us consider an excerpt of the MOON client
whose alphabet is {Login, CreateOrder, CloseOrder}
Alphabet alignment
• P wrapped-by M5
StartOrder? PlaceOrder!
Login?
CreateOrder?
CreateOrder?
Login?
PlaceOrder!
Login?
CreateOrder?
CreateOrder?
Login?
StartOrder?
M5 P
? denote input actions
! denote output actions
PlaceOrder? CloseOrder!M2
Alphabet alignment
• ((P wrapped-by M5) wrapped-by M2)
Alphabet of the wrapped version of P = {Login, CreateOrder, CloseOrder}
CloseOrder
Login
Login
CreateOrder
CreateOrder
Login
CloseOrder
CreateOrder
Automatic synthesis of coordination mediators
• The synthesis algorithm considers finite sets of finite traces
wrappedversion of
MC
wrappedversion of
BS
Login! CreateOrder! SelectItem! SetItemQuantity!
Clo
seO
rder?
ConfirmItem?Close! PayThirdParty?
Login? SelectItem?
ConfirmItem! CloseOrder! Close?
ConfirmItem!
CreateOrder? SetItemQuantity?SelectItem?
SetItemQuantity?
Automatic synthesis of coordination mediators
• In particular, it considers pairs of semantically-related traces
wrappedversion of
MC
wrappedversion of
BS
Login! CreateOrder! SelectItem! SetItemQuantity!
Clo
seO
rder?
ConfirmItem?Close! PayThirdParty?
Login? SelectItem?
ConfirmItem! CloseOrder! Close?
ConfirmItem!
CreateOrder? SetItemQuantity?SelectItem?
SetItemQuantity?
strong notion => possible under-use of protocols
Automatic synthesis of coordination mediators
• For each pair of semantically-related traces, compute the difference pairC
lose
Ord
er?
ConfirmItem?PayThirdParty?
wrappedversion of
MCLogin! CreateOrder! SelectItem! SetItemQuantity!
Close!
ConfirmItem! CloseOrder!
ConfirmItem!
SelectItem?
SetItemQuantity?wrappedversion of
BSLogin? SelectItem?
Close?
CreateOrder? SetItemQuantity?
Automatic synthesis of coordination mediators
Clo
seO
rder?
ConfirmItem?PayThirdParty?
ConfirmItem! CloseOrder!
ConfirmItem!
SelectItem?
SetItemQuantity?
since (i) the original traceswere semantically-related,(ii) possible hidden actions havebeen removed, and (iii) loop/cyclesare considered k times, these tracescan differ for three reasons only
Automatic synthesis of coordination mediators
Clo
seO
rder?
ConfirmItem?PayThirdParty?
ConfirmItem! CloseOrder!
ConfirmItem!
SelectItem?
SetItemQuantity?1) unshared actions
[| Trans(PayThirdParty,PayThirdParty’
)* |]
since (i) the original traceswere semantically-related,(ii) possible hidden actions havebeen removed, and (iii) loop/cyclesare considered k times, these tracescan differ for three reasons only
Automatic synthesis of coordination mediators
Clo
seO
rder?
ConfirmItem?PayThirdParty?
ConfirmItem! CloseOrder!
ConfirmItem!
SelectItem?
SetItemQuantity? 2) extra/missing sends correspondingto redundant messages
[| Prod(SetItemQuantity)* |][| Prod(SelectItem)* |]
[| Cons(ConfirmItem)* |]
since (i) the original traceswere semantically-related,(ii) possible hidden actions havebeen removed, and (iii) loop/cyclesare considered k times, these tracescan differ for three reasons only
Automatic synthesis of coordination mediators
Clo
seO
rder?
ConfirmItem?PayThirdParty?
ConfirmItem! CloseOrder!
ConfirmItem!
SelectItem?
SetItemQuantity? 3) complementary shared actions thatappear in a different order
[| Order([ConfirmItem,CloseOrder],(2,1),
[ConfirmItem’,CloseOrder’])* |]
since (i) the original traceswere semantically-related,(ii) possible hidden actions havebeen removed, and (iii) loop/cyclesare considered k times, these tracescan differ for three reasons only
Correctness and connector evolution
•M enjoys the same correctness properties of a monolithic connector obtained via quotient•M||(R wrapped-by W) refines Inv((P wrapped-by W))•M||(P wrapped-by W) refines Inv((R wrapped-by W))
•Relevant changes can be applied on M by simply acting on its constituent mediators, without entirely re-synthesizing its protocol• the most interesting scenario is related to changes at the
level of the protocol ontology-> syntactic changes correspond to simple relabeling-> protocol-level changes imply to re-iter the synthesis on the affected traces only
Related work
• Formal approaches to protocol conversion [Calvert, Lam 1990 & Lam 1998]
• Specification of protocol adapters [Yellin, Strom 1997]• they do not support reordering (Order primitive) and different granularity
of protocol languages (Split and Merge primitives)
• Automatic mediation of business processes [Vaculin et al. 2007 & 2008]• due to the lack of a formal characterization, it is difficult to assess
respective advantages and disadvantages
• Connector wrappers as protocol transformations [Garlan et al. 2003]• Algebra of stateless connectors [Bruni, Lanese, Montanari 2006]
• they support modularity• the focus is on connector design and specification => no automation
• Converter synthesis [Passerone et al. 2002]• they assume an “inconsistency-free” specification of the converter• in the practice, providing such a specification is not a trivial task
• Generation of component adapters [Canal, Poizat, Salaün 2008]• it requires to know many implementation details about the adaptation
Roadmap of this lecture
•By Massimo Tivoli•automatic synthesis of modular connectors via
composition of protocol mediation patterns [ICSE2013] •By Marco Autili
•automatic synthesis of service choreographies [FASE2013,SERENE2013,WCRE2013,RESS2011]
Component-based design and connector synthesis(Lecture 2)
Thank you for your attention!
Any questions?
GSSI PhD in Computer Science L’Aquila, ItalyNov 11th, 2013
Massimo Tivoli and Marco AutiliEmail: [email protected]
Bibliography
• [ICSE2013] M. Tivoli and P. Inverardi, Automatic Synthesis of Modular Connectors via Composition of Protocol Mediation Patterns, in: ICSE, 2013
• [FASE2013] M. Autili, D. Di Ruscio, A. Di Salle, P. Inverardi and M. Tivoli, A model-based synthesis process for choreography realizability enforcement, in: FASE, pages 37-52, 2013
• [SERENE2013] M. Autili, A. Di Salle and M.Tivoli, Synthesis of resilient choreographies, in: SERENE, pages 94-108, 2013
• [WCRE2013] M. Autili, P. Inverardi, and M. Tivoli, CHOReOS: Large Scale Choreographies for the Future Internet, in: WCRE, 2013
• [RESS2011] M. Autili, D. Di Ruscio, P. Inverardi, J. Lockerbie and M. Tivoli, A Development Process for Requirements Based Service Choreography, in: RESS, 2011