Figures in connection with Conversation Patterns

1. Figures in connection withConversation Patterns November 19, 2002 conversation pattern figures

2. Do until halt nondeterministic choice: read an input; send an output to some other peer; halt; end choice To other e-services . . . input queue A single peer conversation pattern figures

3. Peer 1 Peer 2 Watcher Peer n …… A representative e-composition, with watcher conversation pattern figures

4. Peer1 Peer2 Peer3 Peer4 Peer5 Watcher A representative e-composition, with watcher conversation pattern figures

5. Peer1 Peer2 Peer3 Peer4 Peer5 Do until halt nondeterministic choice: read input letter and record; send output letter to some other peer and record; halt; end choice Watcher . . . input queue A representative e-composition, with watcher A single peer conversation pattern figures

6. authorize store bank ok payment1 receipt2 receipt1 payment2 order1 order2 bill2 bill1 ware- house2 ware- house1 conversation pattern figures

7. Note that in the Mealy peer implementations, the channel name and the message name are identical. So we write, e.g., “|a” rather than “|a:a” r2| r1| Note: for my Mealy machines, an edge label “w|v” means that to traverse this edge the machine must read word w from input and produce word v as output (the channel used for v is not shown). If w or v are empty word, then it may be shown or left blank. |o1 |o2 authorize |a k| store bank ok |o1 |o2 r2| r1| payment1 receipt2 receipt1 payment2 order1 Mealy peer implementation for store order2 bill2 bill1 |p1 |p2 b2| ware- house2 ware- house1 b1| |k a| b1| b2| |p1 |p2 “warehouse” example Mealy peer implementation for bank |b1 a k shuff( ( o1(shuff( r1 , p1b1) )* , ( o2(shuff( r2 , p2b2) )* ) |r1 p1| |b1 o1| o1| |r1 The language recognized (where shuff indicates the shuffle operator) |b1 |r1 p1| |r1 p1| ε|ε Mealy peer implementation for warehouse1, assuming no inner shuffle operator (i.e., accepted word is ... (o1b1p1r1)* ... Mealy peer implementation for warehouse1, assuming the inner shuffle operators conversation pattern figures

8. Note that in the Mealy peer implementations, the channel name and the message name are identical. So we write, e.g., “|a” rather than “|a:a” !b1 !p1 ?r1 ?r2 !p2 !r1 ?p1 ?b2 !o1 !o2 ?b1 ?o1 !r1 !a ?k !k ?a !b1 !r1 ?b1 ?b2 !o1 !o2 ?p1 !p1 ?r2 ?r1 !p2 ε Warehouse1 Store Bank conversation pattern figures

9. a|b |a b| a b Z X Y e-composition whose CPL is { w | |a(w)| = |b(w)|, and for each prefix v of w, |a(v)|  |b(v)| } assuming that the following Mealy peers are used. for X for Y for Z Note: The resulting CPL is context-free but not regular. This is easily extended to create a machine that accepts a CPL that is context-sensitive but not context free (essentially anbncn), In the paper, let’s present the above example and use it to illustrate notion of “pre-pone”. The above example is easily generalized to get the anbncn case. conversation pattern figures

10. authorize store bank ok b payment receipt r bill p order o a r ware- house b r p ε simplified “warehouse” example fsa accepting the CPL for simplified warehouse example (I think) (Don’t need to use pre-pone in this particular case, I think) (can construct Mealy peers from this, but I ran out of time...) a k ( o(shuff( r , p b ) )*) The language recognized (where shuff indicates the shuffle operator) conversation pattern figures

11. ?a c1=(p1,p2 ,{a}) !a ?b p1 p2 c2=(p2,p1 ,{b}) !b p1 p2 conversation pattern figures

12. A Mealy e-composition accepting anbcn (I think) |b a| b| |a c| |c for X for Y for Z Intuition: X produces a bunch of a’s and then one b Y produces one c for each a Z is happy to consume the c’s, but it *must* consume the b first. so, to make an accepting execution of the e-composition, Y must “wait” until X has produced the b, before it can start to send c’s to Z. a X Y b c Z conversation pattern figures

13. c2 p1 p3 c1 c3 p2 ?b !b ?a !a !c ?c p1 p2 p3 c1=(p1,p2,{a}) c2=(p1,p3,{b}) c3=(p2,p3,{c}) conversation pattern figures

14. MRFC Media Resource Function Controller S-CSCF Service Call Session Control Function AppServer Application Server HSS Home Subscriber Service High-level architecture of proposed 3GPP IP Multimedia Core Network Subsystem (IMS) conversation pattern figures

15. Policy Administration Point Policy-enabled Application or Service PolicyRepository PolicyEnforcementPoint i.e., the Rules Engine PolicyDecisionPoint PolicyExecution Point Network Resources Relevant Data Policy-enabled Resources Policy Management Infrastructure Typical reference architecture for policy enablement conversation pattern figures