310 likes | 409 Views
On the Formalization and Comparison of Coordination Models and Languages. Gianluigi Zavattaro. Department of Computer Science University of Bologna. Plan of the Talk. Coordination Infrastructures Data- vs Event-driven coord. (informally) Shared Dataspaces (formally)
E N D
On the Formalization and Comparison of Coordination Models and Languages Gianluigi Zavattaro Department of Computer ScienceUniversity of Bologna
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
A Data-driven Coordination Infrastructure TSpaces Coordination Infrastructures: a Classification • An Event-driven Coordination Infrastructure Talarian SmartSockets Validation02 - Genova - 22/11/2002
Common Features • No direct Communication • Communication mediated by the infrastructure • Space Uncoupled Communication • No channel topology • Time Uncoupled Communication • Asynchronous communication • Associative Communication • Communication based on content or subject Validation02 - Genova - 22/11/2002
Motivation • How much critical is the choice of the kind of infrastructure in the design of a coordinated system? • Are event- and data-driven infrastructures interchangeable? • Can each event-driven system be reduced to an equivalent data-driven system without altering the internal behavior of the processes, and vice versa? Validation02 - Genova - 22/11/2002
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
The Units of Coordination • Event-driven coordination • Processes raise events • An event is delivered to the processes which subscribed their interest to its specific type • Data-driven coordination • Processes produce data • A datum may be accessed (read or consumed) from all process in the system Validation02 - Genova - 22/11/2002
The production of the Units of Coordination is Non-Blocking Creation • An event can be raised whatever is the current state of the system • A datum can be produced whatever is the current content of the shared repository Validation02 - Genova - 22/11/2002
Lifetime • An event plays a role in the system until its multicast finishes • Implicitly received/removed from the system • A datum remains in the shared repository until it is explicitly withdrawn • Explicitly read/consumed Validation02 - Genova - 22/11/2002
Visibility • An event is visible only and exactly to the subscribed processes • Restricted visibility • A datum can be read/consumed by each process in the system • Global visibility Validation02 - Genova - 22/11/2002
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
A Shared DataspaceProcess Calculus (DS) C ::= 0 | <a> | P | C|C P::= out(a).P | in(a).P | rd(a).P | eval(P).P | K • With a taken from Names and constant definition K=P Validation02 - Genova - 22/11/2002
<c> T DS semanticsGraphically out(c).P rd(b).Q <b> <a> <b> in(a).R eval(T).S Validation02 - Genova - 22/11/2002
DS semanticsReduction relation (some rules) out(a).P <a> | P in(a).P | <a> P rd(a).P | <a> P | <a> eval(P).Q P | Q • Assuming commutativity and associativity of parallel comp. Validation02 - Genova - 22/11/2002
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
A Publish/Subscribe Process Calculus (PS) C ::= 0 | on(e,P) | P | C|C P::= pub(e).P | sub(e,P).P |unsub(e,P).P | new(P).P | K • With e taken from Events and constant definition K=P Validation02 - Genova - 22/11/2002
P on(e,P) on(f,S) on(e,Z) Z U PS semanticsGraphically sub(e,P).Q unsub(f,S).T pub(e).R new(U).V Validation02 - Genova - 22/11/2002
PS semanticsLabeled Transition Syst. (some rules) sub(e,P).Q on(e,P) | Q unsub(e,P).Q | on(e,P) Q on(e,P) e on(e,P) | P pub(e).P e P P e P’ Q e Q’ P | Q e P’ | Q’ Validation02 - Genova - 22/11/2002
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
Reducing DS into PS • Mapping entities of Dataspaces into entities in Pub/Sub • Data = listeners • Output = listener production • Input = listener consumption • Read = Input+Output Validation02 - Genova - 22/11/2002
The Reduction Function [[ 0 ]] = 0 [[ K ]] = K (with K = [[ P ]]) [[ out(a).P ]] = sub(ea,0).[[ P ]] [[ in(a).P ]] = unsub(ea,0).[[ P ]] [[ rd(a).P ]] = unsub(ea,0).sub(ea,0).[[ P ]] [[ eval(P).Q ]] = new([[ P ]]).[[ Q ]] Validation02 - Genova - 22/11/2002
Plan of the Talk • Coordination Infrastructures • Data- vs Event-driven coord. (informally) • Shared Dataspaces (formally) • Publish/Subscribe (formally) • Dataspace Pub/Sub • Pub/Sub Dataspace + Global Op. Validation02 - Genova - 22/11/2002
Impossibility of any satisfactory reduction No Reduction of DS into PS • A satisfactory reduction should preserve at least termination • [[ C ]] may terminate iff C may terminate • The existence of a terminating computation is • Decidable in DS (reduction of DS to finite P/T nets) • Undecidable in PS (reduction of RAMs into PS) Validation02 - Genova - 22/11/2002
Reducing PS into finite P/T nets out(a).P in(a).Q <a> P Q Validation02 - Genova - 22/11/2002
Random Access Machine (RAM) • Registers: r1 … rn hold natural numbers • Program: sequence of numbered instructions • Inc(rj): add 1 to the content of rj and go to the next instruction • DecJump(rj,s): if the content of rjis not 0 then decrease by 1 and go to the next instruction; otherwise jump to instruction s Validation02 - Genova - 22/11/2002
Registers Instructions on(r1,pub(r1)) … on(i1,[[ins1]]) … on(r1,pub(r1)) on(in,[[insn]]) on(rm,pub(rm)) … on(rm,pub(rm)) Encoding RAM in PS(the idea) DecJump(rj,s): Non-det. choice between Decrement = loop until decrement succeeds Jump = publish rj and jump to instruction s Validation02 - Genova - 22/11/2002
Properties of the RAM encoding • Only termination is preserved: RAM iff [[ RAM ]] Oss: By C we mean the existence of a completed finite computation • Can we define also a divergence preserving encoding?Answer: no because the existence of an infinite computation is decidable Validation02 - Genova - 22/11/2002
Decidability of Divergence • We express PS in terms of P/T nets with transfer arcs (divergence is decidable [DFS98]) sub(e,P).Q pub(e).R on(e,P) Q start(P,a) R Validation02 - Genova - 22/11/2002 P
P P Adding Global Operation • We extend DS with a global operation (inspired by copy-collect) ccollect(a,P).Q <a> <c> <a> <b> Validation02 - Genova - 22/11/2002
Reducing PS into DS • Listeners = data • on(e,P) = lsteP • Subscribe = data production • [[ sub(e,P) ]] = out(lsteP) • Unsubscribe = data consumption • [[ unsub(e,P) ]] = in(lsteP) • Publish = count each kind of listeners • [[ pub(e) ]] = ccollect(lsteP1,P1)…ccollect(lstePn,Pn) Validation02 - Genova - 22/11/2002
Conclusion Termination Undecidable Divergence Decidable + Glob. Operators PS calculus DS calculus Termination Decidable Validation02 - Genova - 22/11/2002