a model of an e-service (peer)

1

University of Pennsylvania

Grigoris Karvounarakis February 2004

Conversation Specification: A New Approach to Design and Analysis of E-

Service Composition

T. 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 simple example application

store

warehouse1

bank

warehouse2

a

k

o1

o2

p1r1r2

b1

p2 b2

a: authorize

k: ok

o: order

r: receipt

b: bill

p: payment

6



Definitions

e-composition schema (ec-schema) is a triple (M,P,C)M = message classesP = e-services (peers)C = communication channels

Σin

p

Σout

p

: set of message classes accepted by p as input

: set of message classes produced by p as output

7



A simple example application

store

warehouse1

bank

warehouse2

a

k

o1

o2

p1r1r2

b1

p2 b2

M = {A,K,O,R,P,B}

P = {store, bank, warehouse1, warehouse2}

C = {(store, bank, a), (store, warehouse1, o), …}

Σin

store

Σout

store

= {r, k}

= {o, a}

8



Mealy ec-implementations

(T, s, , , F, δ)Σin

p Σout

p

δ: 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



W = ako1b1 p1 r1

!a ?k

?r1

!o1 !o2

?r2

!o2

?r2

!o1

?r1

Store


?a !k

!p1

?b1 ?b2

!p2

?b2

!p2

?b1

!p1

Bank

?o1 !b1 ?p1

!r1!r1!r1

!b1 ?p1

Warehouse1ε

W = ako1b1 p1 r1W = ako1b1 p1 r1W = ako1b1 p1 r1W = ako1b1 p1 r1W = ako1b1 p1 r1W = ako1b1 p1 r1

10




!a ?k

?r1

!o1 !o2

?r2

!o2

?r2

!o1

?r1

Store

?a !k

!p1

?b1 ?b2

!p2

?b2

!p2

?b1

!p1

Bank

?o1 !b1 ?p1

!r1!r1!r1

!b1 ?p1

Warehouse1ε

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



Ec-languages are not regular

p1 p2

c1 = (p1, p2 ,{a})

c2 = (p2, p1 ,{b})

!a ?b

p1

?a

!b

p2

L = {a b | n≥0}, not regular!n n

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

p1

L1 = {a}

p2

c1=(p1, p2 ,{a})p3 p4

c2 = (p3, p4 ,{b})

c2 = (p4, p3 ,{c})

… but their composition is not {a, bc}!

C(I) = {ε, a, bc, abc, bac, bca}

L2 = {bc}

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



PREPONE is not enough

p1 p2

c1 = (p1, p2 ,{a})

c2 = (p2, p1 ,{b})

L = {ab, bac}

closure(L) = Lp3

c3=(p2, p3 ,{c})

I(p1)

!a ?b

I(p2)

!b ?a !c

… but C(I) != closure(L)(e.g., it also includes abc)

19



Local prepone

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)))

*

*

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))

a model of an e-service (peer)

Documents