conversation specification: a new approach to design and specification of e-service composition t....
Post on 22-Dec-2015
215 views
TRANSCRIPT
Conversation Specification:A New Approach to Design and
Specification of E-Service Composition
T. Bultan X. Fu R. Hull J. Su
University of California at Santa Barbara
Bell Labs, Lucent Technologies
May 24, 2003 WWW 2003 2
The E-Services ParadigmE-services : network-resident software
services accessible via standardized protocols In e-commerce, telecom, sciencePossibility of automatic discovery, composition,
invocation, monitoring
Primary roots :Process description formalisms, including automata
and workflowData management (including models, transforms,
mediation, transactions)Distributed computing middleware
May 24, 2003 WWW 2003 3
E-Services CompositionWeb very flexible forms of distributed
computing (SOAP, WSDL)Composition: distributed, flexible, and complex
More flexible, less structured than CORBAData management plays a large role
Increased structure helps understanding fundamental issues“Glue” languages: WSFL, XLANG, BPEL4WS, BPML“Behavioral” signatures: automata-based, WSCL,
“session types”Formalisms to describe e-services: DAML-S pre- and
post-conditions
May 24, 2003 WWW 2003 4
Fundamental Issues in Composition
How to build composite e-services from atomic ones?Various standards proposed; different disciplines
addressedMost pursue a procedural approachApproaches to “synthesize” (automatic composition)
e-compositions from desired global propertiesHow to analyze composite e-services?
“Correctness”, behaviors, composable? compatibility?Tools for analysis of compositions
Formal foundations not yet clear
May 24, 2003 WWW 2003 5
Summary of Contributions Propose a model of global behaviors for composite e-
servicesE-service interactions via messaging (e.g. in the spirit of
JMS, BizTalk): asynchronous + FIFO queue Use formal language techniques
Technical results concerning Mealy machines as participating e-services:1.Global behaviors are not always regular languages2.The “prepone” and “join” closure of every regular
language = global behavior of some composite e-service3.The converse of 2. is not true
Implications to composition design: Top-down is better than bottom-upBounded queues vs unbounded
May 24, 2003 WWW 2003 6
OutlineA Model for E-services & Compositions
Conversations
Mealy Peers/Implementations
Conversation Specifications (Top-Down)
Related work
Conclusions
May 24, 2003 WWW 2003 7
An E-C schema is a triple (M, P, C )Specifies the infrastructure of composition
E-Composition Schema
authorize M : finite set of message classes
ware-house2
ware-house1
store bank
P : finite set of peers(e-services)
ok
bill 2
paym
ent 2o
rder1
receipt1
order2
receipt2 pa
yment 1
bill 1
C : finite set of peer to peer channels
“conservative” “aggressive”
May 24, 2003 WWW 2003 8
Composition InfrastructurePossible models:
Peer-to-peer (distributed control)Hub-and-spoke (centralized control)
ware-house2
ware-house1
store bankokauthorize
order2
receipt2
paymen
t 1
bill 1
order
1
rece
ipt 1 b
ill2
pay
men
t 2ak’
ro
b2p2
r2o2
r1o1
b1p1
ka’
bp
ware-house2
ware-house1
store bank
mediator
Our technical results do not rely on special rolesof peers (in the spirit of P2P)
w2w1
s b
w2w1
s b
m
May 24, 2003 WWW 2003 9
Communication ChannelsChannels are assumed to be reliableAsynchronous, for example, the following channel:
ware-house1store
order1
send Order1…
o1
send Order1receive Receipt1
…
Queues are FIFO, unbounded lengthCan simulate synchronous
and also bounded queues
May 24, 2003 WWW 2003 10
MessagesMessages are classified into classes Each class is associated with one channel
Each message class may have additional attributes which can carry the contents of messagesFor this paper, analysis involves no contentsResults immediately apply to “finite domain”
contents
ware-house1store
order1
May 24, 2003 WWW 2003 11
Peers (E-services) In the most general case, a peer can be a
Turing machine
inputmessages
to othere-services
Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice
local storemessage log
Essence of BPEL4WS, BPML, etc. standards:Finite control + data structures Infinite state system and thus difficult to analyze
Our approach:Finite control + (finite number of) message classes
(+ finite domain contents)Open to extend to allow data structures (not in this paper)
Impossible to analyze
inputmessages
to othere-services
Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice
local storemessage log
May 24, 2003 WWW 2003 12
OutlineA Model for E-services & Compositions
Conversations
Mealy Peers/Implementations
Conversation Specifications (Top-Down)
Related work
Conclusions
May 24, 2003 WWW 2003 13
Global Behaviors of CompositionCenter around composition (collaboration)
Rather than individual E-services“Behavioral type” checking: composability is an
important issueOur focus:
Is the specification of a composite E-service “correct”?How, when, and what do peers communicate?Correctness: properties of communication during
possible executions
Ignore port-level details
May 24, 2003 WWW 2003 14
order2
paymen
t 1
bill 1
ConversationsWatcher: “records” the messages (classes) as
they are sent
okauthorize
receipt2
order
1
rece
ipt 1 b
ill2
pay
men
t 2Watcher
ware-house2
ware-house1
store bank
a k o1 b1o2
A conversation is a sequence of messages the watcher sees in a successful run (or session)
E-composition (ec) language: the set of all possible conversations
p1r1 r2 b2
p2
May 24, 2003 WWW 2003 15
OutlineA Model for E-services & Compositions
Conversations
Mealy Peers/Implementations
Conversation Specifications (Top-Down)
Related work
Conclusions
May 24, 2003 WWW 2003 16
Peers Revisited
Again, ports and storages are ignored Internal logic of peers : finite state control
inputmessages
to othere-services
Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice
local storemessage log
May 24, 2003 WWW 2003 17
Mealy PeersMealy machines: Finite state machines with input
(incoming messages) & output (outgoing messages)
warehouse2
?o2 !r2
!r2
null
!r2!b2!b2
?p2?p2
May 24, 2003 WWW 2003 18
Executing a Mealy Composition
Execution halts ifAll mealy peers are in final statesAll queues are empty
warehouse2
?o2 !r2
!r2
null
!r2!b2!b2
?p2?p2
bank
?a
!k
…
store
!a
?k
…
!o2
w1
?o1
…ak o2
!o1
…
May 24, 2003 WWW 2003 19
OutlineA Model for E-services & Compositions
Conversations
Mealy Peers/Implementations
Conversation Specifications (Top-Down)
Related work
Conclusions
May 24, 2003 WWW 2003 20
E-C languages are not always regularExample: ECL a*b* anbn
E-Composition Language Regular
?b!a
p1 p2
?a
!b
a
b
Not context free for some Mealy compositionsCauses: asynchronous communication &
unbounded queueBounded queues or synchronous: ECL always
regular
May 24, 2003 WWW 2003 21
Practical ImplicationsSimply composing peers without a global
sense can make the E-composition behaviors very complicated
Non regular means many model checking tools are out of reach (for correctness)
Bottom up won’t always work well
May 24, 2003 WWW 2003 22
An AlternativeGiven a regular language L as the global
behavior, find Mealy peers so that the ECL L
A quick answer: no
But, wait…
May 24, 2003 WWW 2003 23
Local view of a conversation for a peer: part of the execution that is related to the peer
Defined as projection: pw for a conversation wTwo conversations cannot be distinguished if
they have exactly the same set of local views
If abc is a part of a conversation, so are bac and bca
piabcpi
bacpi bcaa for i
piabcpi
bacpi bcabc for i
Local Views
a p2p1b
cp4p3
May 24, 2003 WWW 2003 24
Given languages Li over i, i n
Conversations (ECLs) L are closed under “projection-join”:
Join
LL )(πpeerpeers
*)(π1 iiiiii LwniwL
May 24, 2003 WWW 2003 25
Local Prepone
peerw should also allow
a peer p
!a!b c … a b …
local view at p
…
)(πpeer w
ab ……
May 24, 2003 WWW 2003 26
A Synthesis ResultGiven a regular language L, we can find a Mealy
composition such that its ECL is the closure:
))((πneLocalPrepo peer*
peers L
Intuitively: given a regular L (e.g., ako1…), we can find Mealy peers whose conversations are not arbitraryOpportunity for automatic composition
But some Mealy compositions do not relate to any regular languages in this way
May 24, 2003 WWW 2003 27
The Converse (General Case)There is an Mealy compositions whose ECL is not
for every regular languages L
))((πneLocalPrepo peer*
peers L
a
b
?a
!cp2
!b
!a p1 p3 ?c
?b
c
ECL = { aibci | i 0 }
May 24, 2003 WWW 2003 28
When the peer-channel graph is a tree, then the Mealy composition has an ECL equal to
for some regular languages L
Intuitively: the global behavior of bottom-up composition is still predictable if the composition infrastructure is a treeIn particular, adding an mediator (hub-
spoke) isn’t a bad idea!
The Tree Case
))((πneLocalPrepo peer*
peers L
May 24, 2003 WWW 2003 29
Hub-and-spokeFor every star-shaped E-composition
infrastructure, and every regular language L, we can construct an Mealy composition whose ECL L
Good news for hub-and-spoke!
May 24, 2003 WWW 2003 30
Summary of Technical Results1.ECLs of some Mealy compositions are not regular,
some others not context free2.The “prepone” and “join” closure of every regular
language = ECL of some composite Mealy E-services
3.The converse of 2. is not true in general, true in special cases
However: if bounded queue or synchronous:ECL of every Mealy composition is regular
Design time decision! Need to be explicit in specifications (BPEL4WS, BPLM, …)
May 24, 2003 WWW 2003 31
OutlineA Model for E-services & Compositions
Conversations
Mealy Peers/Implementations
Conversation Specifications (Top-Down)
Related work
Conclusions
May 24, 2003 WWW 2003 32
Related WorkSimilar E-service models:
BPEL4WS (WSFL, XLANG), BPML, WSCLWorkflow, 1-safe Petri-nets
-calculus: synchronous but can simulate unbounded buffer effect
Other synchronous modelsCSP [Hoare ’85], I/O automata [Lynch-Tuttle ’87],
interface automata [Henzinger et al ’01 ]
Other asynchronous modelsCommunicating FSA [Brand-Zafiropulo ’82],
Message Sequence Charts [Alur et al ’00]
May 24, 2003 WWW 2003 33
ConclusionsConversations are an interesting model for
global behaviorsOnly a beginning, more need to be
understood (see also [Hull et al PODS ’03])Would like ECLs to be regular, some sufficient
conditions are given in [Fu-Bultan-S. CIAA ’03] Infinite domain message contents?Design tools, e.g., verification tools?Spawning new processes?…