A model of an e-service (peer)

1. Conversation Specification: A New Approach to Design and Analysis of E-Service CompositionT. Bultan, X. Fu, R. Hull, J. Su(UCSB and Bell Labs) presented by: Grigoris Karvounarakis Univ. of Pennsylvania DB seminar February 26, 2004

2. A model of an e-service (peer) (Read input from input queue) + (Send output to other service) + halt input queue …

3. Discrete vs. interactive services • Discrete: RPC-like, output only depends on input • Interactive: long-running services, responding to asynchronous events/messages

4. What about composition? • A lot of research on modeling and implementing e-services (local properties of atomic e-services)… • … but no work on formalizing their composition and the relationship between global properties of composite e-service and local properties of atomic e-services • This paper: a framework for modeling and specifying the global behavior of e-service compositions

5. a k store warehouse1 bank warehouse2 r2 o1 r1 b2 p1 p2 o2 b1 A simple example application a: authorize k: ok o: order r: receipt b: bill p: payment

6. Σ in p Σ out p Definitions e-composition schema (ec-schema) is a triple (M,P,C) M = message classes P = e-services (peers) C = communication channels : set of message classes accepted by p as input : set of message classes produced by p as output

7. a k store warehouse1 bank warehouse2 r2 o1 r1 b2 p1 p2 o2 b1 A simple example application M = {A,K,O,R,P,B} P = {store, bank, warehouse1, warehouse2} C = {(store, bank, a), (store, warehouse1, o), …} Σ in = {r, k} store Σ out = {o, a} store

8. Σ Σ out in p p Mealy ec-implementations (T, s, , , F, δ) • δ:one of the “peers”: • consumes a non-empty input • produces a non-empty output • makes a move on empty string ec-configuration: (Q1, t1, Q2, t2,…, Qn, tn, w) w is a halting conversation for I if: (ε, s1, ε, s2,…, ε, sn, ε) →*(ε, t1, ε, t2,…, ε, tn, w)

9. ?r1 !p1 ?r2 !p2 !o1 ?b1 !o2 ?b2 !a ?k ?a !k !o2 !o1 ?b2 ?b1 ?r1 !p1 ?r2 !p2 Store Bank ?p1 !b1 !r1 !r1 !r1 ?o1 !b1 ?p1 ε Warehouse1 W = ako1b1p1 r1 W = ako1b1 p1 r1 W = ako1b1 p1 r1 W = ako1b1 p1r1 W = ako1b1 p1 r1 W = ako1b1 p1 r1 Mealy ec-implementations W = ako1b1 p1r1

10. ?r1 !p1 ?r2 !p2 !o1 ?b1 !o2 ?b2 !a ?k ?a !k !o2 !o1 ?b2 ?b1 ?r1 !p1 ?r2 !p2 Store Bank ?p1 !b1 !r1 !r1 !r1 ?o1 !b1 ?p1 ε Warehouse1 Mealy ec-implementations W = ako1b1 r1 p1

11. Ec-languages Ec-language (C(I)): set of all halting conversations w for mealy implementation I. This example: L = ak SH( (o1 SH(r1, b1 p1) )*, (o2 SH(r2, b2 p2) )* ) (is it the same?: L = ak ( (o1 (r1 || b1 p1) )* || (o2 (r2 || b2 p2) )* ) ) Is it the case that such ec-languages are always regular?

12. n n L = {a b | n≥0}, not regular! Ec-languages are not regular ?a c1 = (p1, p2 ,{a}) !a ?b p2 p1 !b p1 p2 c2 = (p2, p1 ,{b}) In general: not even guaranteed to be context-free …

13. Properties of ec-languages • Context Sensitive • There exists a quasi-realtime automaton M with 3 queues that accepts C(I) • Book & Greibach: “Quasi-realtime languages are the languages accepted by nondeterministic multitape Turing machines in real time. The family of quasi-realtime languages forms an abstract family of languages closed under intersection, linear erasing, and reversal. It is identical with the family of languages accepted by nondeterministic multitape Turing machines in linear time. Every quasi-realtime language can be accepted in real time by a non-deterministic one stack, one pushdown store machine, and can be expressed as the length-preserving homomorphic image of the intersection of three context-free languages” • C(I) is regular when queue length is bounded by a fixed constant • (of course it is also regular if communication is synchronous …)

14. The synthesis problem • Given an ec-schema S and some peer implementations, we can build an ec-implementation I (expecting that the composition will generate some language L). • Can we characterize the relationship between C(I) and the languages accepted by the peers (which are regular, since peers are FSAs)? • The inverse problem is also interesting: given an ec-implementation I, can we find a regular language at its “core?”?

15. PREPONE • Swap messages in a conversation when they are “independent”: • Disjoint senders/receivers • Receiver of 2nd is also sender of 1st • Ec-languages are: • Closed under PREPONE • The family of C(I)s is strictly contained in the family of context-sensitive languages (since not all cf languages are closed under PREPONE)

16. Joining local views c2 = (p3, p4 ,{b}) c1=(p1, p2 ,{a}) p4 p3 p1 p2 c2 = (p4, p3 ,{c}) L1 = {a} L2 = {bc} … but their composition is not {a, bc}! C(I) = {ε, a, bc, abc, bac, bca}

17. Joining local views Li = {w | for all I, πp (w) in Li} closure(L): minimal superset of L closed under prepone and join closure(L)≤ C(I) Unfortunately, there are cases when closure(L)!=C(I)

18. !a !b !c ?b ?a I(p1) I(p2) PREPONE is not enough c1 = (p1, p2 ,{a}) L = {ab, bac} closure(L) = L c3=(p2, p3 ,{c}) p2 p1 p3 c2 = (p2, p1 ,{b}) … but C(I) != closure(L) (e.g., it also includes abc)

19. Applies locally (on each peer), i.e.: LPi • Extends prepone by allowing to swap messages m1, m2 when receiver(m1) = sender(m2) • (doesn’t this mean we get all permutations? What about possible dependencies?) • ecc(L) = i LPi (πpi(L)) • ecc(L) = i LPi (L(I(pi))) * * Local prepone

20. A different approach Start from a conversation specification S for ec-schema S, build an ec-implementation I that conforms to S or realizes S. For every regular language L we can construct a Mealy ec-implementation I such that: C(I) = ecc(L) (construct automaton for L and “project” it on individual peers)

21. The inverse problem • It is not the case of course that for every I there exists a regular language s.t. C(I) = ecc(L) • … but this is true for tree-based schemas (i.e., schemas whose undirected corresponding graph is a tree)

22. Bottom-Up vs. Top-Down • Two approaches for designing composite e-services: • Bottom-Up: Synthesize from atomic e-services • Design each service individually and compose them (through join and prepone) yields C(I) >= closure(L) • Conversely, given a I, we cannot find a regular language that it implements • Top-Down: may be conceptually cleaner • First, define a conversation specification S of the composition • For every regular language we can construct a Mealy ec-implementation I that realizes it (i.e., C(I) = ecc(L))