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, 2003WWW The E-Services Paradigm E-services : network-resident software services accessible via standardized protocols In e-commerce, telecom, science Possibility of automatic discovery, composition, invocation, monitoring Primary roots : Process description formalisms, including automata and workflow Data management (including models, transforms, mediation, transactions) Distributed computing middleware
May 24, 2003WWW E-Services Composition Web very flexible forms of distributed computing (SOAP, WSDL) Composition: distributed, flexible, and complex More flexible, less structured than CORBA Data 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, 2003WWW Fundamental Issues in Composition How to build composite e-services from atomic ones? Various standards proposed; different disciplines addressed Most pursue a procedural approach Approaches to “synthesize” (automatic composition) e-compositions from desired global properties How to analyze composite e-services? “Correctness”, behaviors, composable? compatibility? Tools for analysis of compositions Formal foundations not yet clear
May 24, 2003WWW Summary of Contributions Propose a model of global behaviors for composite e-services E-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 languages 2.The “prepone” and “join” closure of every regular language = global behavior of some composite e-service 3.The converse of 2. is not true Implications to composition design: Top-down is better than bottom-up Bounded queues vs unbounded
May 24, 2003WWW Outline A Model for E-services & Compositions Conversations Mealy Peers/Implementations Conversation Specifications (Top-Down) Related work Conclusions
May 24, 2003WWW An E-C schema is a triple (M, P, C ) Specifies the infrastructure of composition E-Composition Schema a uthorize M : finite set of message classes ware- house2 ware- house1 store bank P : finite set of peers (e-services) okok b ill 2 p ayment 2 o rder 1 r eceipt 1 o rder 2 r eceipt 2 p ayment 1 b ill 1 C : finite set of peer to peer channels “conservative” “aggressive”
May 24, 2003WWW Composition Infrastructure Possible models: Peer-to-peer (distributed control) Hub-and-spoke (centralized control) ware- house2 ware- house1 store bank okok a uthorize o rder 2 r eceipt 2 p ayment 1 b ill 1 o rder 1 r eceipt 1 b ill 2 p ayment 2 a k’k’ r o b2b2 p2p2 r2r2 o2o2 r1r1 o1o1 b1b1 p1p1 k a’a’ b p ware- house2 ware- house1 store bank mediator Our technical results do not rely on special roles of peers (in the spirit of P2P) w2w1 s b w2 w1 s b m
May 24, 2003WWW Communication Channels Channels are assumed to be reliable Asynchronous, for example, the following channel: ware- house1 store o rder 1 send Order 1 … o1o1 send Order 1 receive Receipt 1 … Queues are FIFO, unbounded length Can simulate synchronous and also bounded queues
May 24, 2003WWW Messages Messages are classified into classes Each class is associated with one channel Each message class may have additional attributes which can carry the contents of messages For this paper, analysis involves no contents Results immediately apply to “finite domain” contents ware- house1 store o rder 1
May 24, 2003WWW Peers (E-services) In the most general case, a peer can be a Turing machine input messages to other e-services Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice local store message 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 input messages to other e-services Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice local store message log
May 24, 2003WWW Outline A Model for E-services & Compositions Conversations Mealy Peers/Implementations Conversation Specifications (Top-Down) Related work Conclusions
May 24, 2003WWW Global Behaviors of Composition Center around composition (collaboration) Rather than individual E-services “Behavioral type” checking: composability is an important issue Our 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, 2003WWW o rder 2 p ayment 1 b ill 1 Conversations Watcher: “records” the messages (classes) as they are sent okok a uthorize r eceipt 2 o rder 1 r eceipt 1 b ill 2 p ayment 2 Watcher ware- house2 ware- house1 store bank ako1o1 b1b1 o2o2 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 p1p1 r1r1 r2r2 b2b2 p2p2
May 24, 2003WWW Outline A Model for E-services & Compositions Conversations Mealy Peers/Implementations Conversation Specifications (Top-Down) Related work Conclusions
May 24, 2003WWW Peers Revisited Again, ports and storages are ignored Internal logic of peers : finite state control input messages to other e-services Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice local store message log
May 24, 2003WWW Mealy Peers Mealy machines: Finite state machines with input (incoming messages) & output (outgoing messages) warehouse2 ?o2?o2 !r2!r2 !r2!r2 null !r2!r2 !b2!b2 !b2!b2 ?p2?p2 ?p2?p2
May 24, 2003WWW Executing a Mealy Composition Execution halts if All mealy peers are in final states All queues are empty warehouse2 ?o2?o2 !r2!r2 !r2!r2 null !r2!r2 !b2!b2 !b2!b2 ?p2?p2 ?p2?p2 bank ?a?a !k!k … store !a!a ?k?k … !o2!o2 w1 ?o1?o1 … ako2o2 !o1!o1 …
May 24, 2003WWW Outline A Model for E-services & Compositions Conversations Mealy Peers/Implementations Conversation Specifications (Top-Down) Related work Conclusions
May 24, 2003WWW E-C languages are not always regular Example: ECL a * b * a n b n E-Composition Language Regular ?b?b !a!a p1p1 p2p2 ?a?a !b!b a b Not context free for some Mealy compositions Causes: asynchronous communication & unbounded queue Bounded queues or synchronous: ECL always regular
May 24, 2003WWW Practical Implications Simply 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, 2003WWW An Alternative Given a regular language L as the global behavior, find Mealy peers so that the ECL L A quick answer: no But, wait…
May 24, 2003WWW Local view of a conversation for a peer: part of the execution that is related to the peer Defined as projection: p w for a conversation w Two 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 p i abc p i bac p i bca a for i p i abc p i bac p i bca bc for i Local Views a p2p2 p1p1 b c p4p4 p3p3
May 24, 2003WWW Given languages L i over i, i n Conversations (ECLs) L are closed under “projection-join”: Join
May 24, 2003WWW Local Prepone peer w should also allow a peer p !a!a !b!b c …ab… local view at p … ab……
May 24, 2003WWW A Synthesis Result Given a regular language L, we can find a Mealy composition such that its ECL is the closure: Intuitively: given a regular L (e.g., ako 1 …), we can find Mealy peers whose conversations are not arbitrary Opportunity for automatic composition But some Mealy compositions do not relate to any regular languages in this way
May 24, 2003WWW The Converse (General Case) There is an Mealy compositions whose ECL is not for every regular languages L a b ?a?a !c!c p2p2 !b!b !a!a p1p1 p3p3 ?c?c ?b?b c ECL = { a i bc i | i 0 }
May 24, 2003WWW 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 tree In particular, adding an mediator (hub-spoke) isn’t a bad idea! The Tree Case
May 24, 2003WWW Hub-and-spoke For 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, 2003WWW Summary of Technical Results 1.ECLs of some Mealy compositions are not regular, some others not context free 2.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, 2003WWW Outline A Model for E-services & Compositions Conversations Mealy Peers/Implementations Conversation Specifications (Top-Down) Related work Conclusions
May 24, 2003WWW Related Work Similar E-service models: BPEL4WS (WSFL, XLANG), BPML, WSCL Workflow, 1-safe Petri-nets -calculus: synchronous but can simulate unbounded buffer effect Other synchronous models CSP [Hoare ’85], I/O automata [Lynch-Tuttle ’87], interface automata [Henzinger et al ’01 ] Other asynchronous models Communicating FSA [Brand-Zafiropulo ’82], Message Sequence Charts [Alur et al ’00]
May 24, 2003WWW Conclusions Conversations are an interesting model for global behaviors Only 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? …