p/s-com: building correct by design publish/subscribe architectural styles with safe reconfiguration

The Journal of Systems and Software 83 (2010) 412–428

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier .com/locate / jss

P/S-CoM: Building correct by design Publish/Subscribe architectural styleswith safe reconfiguration

Imen Loulou a, Mohamed Jmaiel a, Khalil Drira b,c,*, Ahmed Hadj Kacem a

a National Engineering School of Sfax, Research Unit ReDCAD, B.P.W., 3038 Sfax, Tunisiab CNRS, LAAS, 7 avenue du colonel Roche, F-31077 Toulouse, Francec Université de Toulouse, UPS, INSA, INP, ISAE, LAAS, F-31077 Toulouse, France

a r t i c l e i n f o a b s t r a c t

Article history:Received 25 September 2008Received in revised form 2 June 2009Accepted 12 September 2009Available online 30 September 2009

Keywords:Software architecturePublish/Subscribe styleEvent-based communicationFormal specificationReconfiguration modelingGraph rewriting

0164-1212/$ - see front matter � 2009 Elsevier Inc. Adoi:10.1016/j.jss.2009.09.031

* Corresponding author. Address: CNRS, LAAS, 7F-31077 Toulouse, France. Tel.: +33 5 61 33 63 22; fa

E-mail address: [email protected] (K. Drira).

We present P/S-CoM, a formal approach supporting the correct modeling of Publish/Subscribe architec-tural styles and safe reconfiguration of dynamic architectures for event-based communication. We elab-orate a set of patterns and we define the corresponding composition rules to build correct by designPublish/Subscribe styles. The defined patterns and rules respect the principle of information dissemina-tion guaranteeing that the produced information reaches all the subscribed consumers. The patterns aremodeled as graphs and the semantics of each pattern and each rule is specified formally in Z notations.We implement these specifications under the Z-Eves theorem prover which we use to prove specificationconsistency. The Z specification of the designed architectural style is also built by composition by apply-ing the composition rules coded in Z. We consider the interconnection topology between event dispatch-ers as well as the subscription model using elementary refinements of the style specification. Moreover,we model the reconfiguration of Publish/Subscribe architecture via guarded graph-rewriting rules whosebody specifies the structural constraints and whose guards define the pre- and post-conditions ensuringin this way the preservation of stylistic constraints. Similarly, we interpret reconfiguration rules in Znotations, and we implement these rules under Z-Eves for proving that all reconfigurations are style pre-serving. This results in a unified formal approach which handles both the static and the dynamic aspectsof Publish/Subscribe software architectures.

� 2009 Elsevier Inc. All rights reserved.

1. Introduction

Software architectures play an important role in softwaredevelopment. As abstract models of the run-time structure theyhelp bridging the gap between user requirements and implemen-tation (Shaw and Garlan, 1996).

In software architecture research, architectural styles are usedto define a domain specific architecture description, including for-mal definitions of what architectural elements are, what theirinvariant properties are, how elements can be combined and whichconstraints apply (Abowd et al., 1995; Aldini and Bernardo, 2005;Dean and Cordy, 1995; Métayer, 1998; Moriconi et al., 1995; Oqu-endo and May, 2006). A software architectural style providesopportunity for specific analysis of system behavior and propertiesand guides decisions for system monitoring, diagnosis, andchanges (Cheng et al., 2002). For self-adaptation, each style mayuniquely guide the choice of metrics, help identifying strategic

ll rights reserved.

avenue du colonel Roche,x: +33 5 61 33 64 11.

points for system observation, and suggest possible adaptations(Cheng et al., 2005).

An increasingly commonly used architectural style for compo-nent-based systems is Publish/Subscribe. The strength of thisevent-based interaction style lies in the full decoupling in time,space, and synchronization (Eugster et al., 2003) between the com-ponents that generate events, called producers, and the receivers,called consumers. This decoupling is realized by the event servicewhich is the glue that ties together distributed components in Pub-lish/Subscribe architectures. The event service could be centralizedand implemented as a single entity called dispatcher or distributedand implemented as a network of dispatchers. Many variants1 ofthe Publish/Subscribe style could be distinguished according to thedispatcher network topology (acyclic, hierarchic, etc.), the interac-tion modes between clients and dispatchers (Push, Pull, etc.), andthe subscription models (topic-based, content-based, etc.). Usingthe Publish/Subscribe style, it becomes relatively easy to add orremove components in a system, introduce new events, register

1 Publish/Subscribe styles in short.

http://dx.doi.org/10.1016/j.jss.2009.09.031

mailto:[email protected]

http://www.sciencedirect.com/science/journal/01641212

http://www.elsevier.com/locate/jss

I. Loulou et al. / The Journal of Systems and Software 83 (2010) 412–428 413

new consumers on existing events, or modify the network of dis-patchers. Over the past couple of years, event-based systems haveappeared in many application domains (Pietzuch et al., 2007), suchas business management systems, large-scale data dissemination,Internet-scale applications, and autonomic computing.

The gain in flexibility is counterbalanced by the difficulty to thedesigner in ensuring the correctness and the reliability of the Pub-lish/Subscribe style he/she designed. By correct, we mean that theprinciple of information dissemination, requiring that producedinformation reaches all subscribed consumers, is taken into consid-eration. In addition, the decoupling property is considered, and theinteraction rules, governing the different types of components inPublish/Subscribe architectures, are respected. Another major is-sue is to ensure a safe reconfiguration. The reconfiguration of asoftware architecture describes how it can evolve, by means ofarchitectural changes resulting from adding/removing componentsand connections (Cugola et al., 2004; Parzyjegla et al., 2006; Wer-melinger and Fiadeiro, 1999). The architecture must be left in acorrect state (w.r.t. its style) after reconfiguration, by maintainingits conformity to its architectural style. The difficulty of designingand building software systems can be reduced by focusing on thearchitectural level. Indeed, by abstracting away from implementa-tion details, an architectural description makes the design intellec-tually tractable. Moreover, the ambiguity which may be introducedby an informal description can be eliminated by using formal spec-ifications that expose the properties most crucial to the success ofthe design activity. Such descriptions constitute the key technicaldocument used to determine whether a proposed new system willmeet its most critical requirements.

In recent years, researchers have focused on techniques toimplement Publish/Subscribe systems with scalable, distributedarchitectures. Several infrastructures were proposed such as SIENA(Carzaniga et al., 2001), HERMES (Pietzuch and Bacon, 2002), JEDI(Cugola et al., 2001). Other approaches (Baldoni et al., 2006; Baresiet al., 2005; Fenkam et al., 2003) include formal computationalmodels for the Publish/Subscribe paradigm, techniques for systemspecification, and for reasoning about the correctness of programs.The characteristics of these approaches (Baldoni et al., 2006; Baresiet al., 2005; Fenkam et al., 2003) is more about researching the fun-damental behavior of the Publish/Subscribe paradigm than aboutthe Publish/Subscribe software architecture design. We think thatthe description of Publish/Subscribe systems at a high level ofabstraction remains to be clearly stated and formally defined.Moreover, some recent research (Jaeger et al., 2006; Parzyjeglaet al., 2006; Zieba and van Sinderen, 2006) conducted on the dy-namic reconfiguration of Publish/Subscribe systems rather ad-dresses issues like notification and subscription loss as well asduplication during reconfiguration.

This paper makes a contribution in this direction by proposing avisual and formal approach which aims to help the architect to de-sign correct Publish/Subscribe architectural styles. Instead ofdesigning an architectural style from the scratch and verifyingrepeatedly its satisfaction to the Publish/Subscribe style properties,we rather propose a correct by design approach where propertiesare verified once and for all. We elaborate a reusable set of provedpatterns and we define the corresponding composition rules tobuild correct Publish/Subscribe architectural styles. The definedpatterns and rules respect the correctness properties. The patternsare modeled as graphs and the semantics of each pattern and eachrule is specified formally in Z notation (Spivey, 1989). We imple-ment these specifications under the Z/EVES theorem prover whichwe use to prove specification consistency. The Z specification of thedesigned architectural style is also built by composition accordingto the composition rules applied by the architect and which arecoded in Z. Furthermore, we show how to consider the intercon-nection topology between event dispatchers as well as the sub-

scription model using elementary refinements of the obtainedstyle specification.

Moreover, we propose an approach which benefits from theexpressive power of functional notations and graph grammars todescribe and to reason about architectures. We model reconfigura-tion rules via a new notation based on graph-rewriting rules and Znotation. This integration offers to software architects an intuitiveand formal way to specify the dynamic aspect of software architec-ture based on visual notations. We also propose to specify theinterpretation of each reconfiguration rule in Z notation, thusobtaining a unified approach. These rules take into account bothstructural and functional constraints of a system in their applica-tion conditions ensuring, in this way, the preservation of stylisticconstraints during its evolution. We develop under Z/EVES theo-rem prover the proof that a reconfiguration operation respect thedefined architectural style.

The remainder of this paper is organized as follows: in Section2, we present a survey of the related work results. Section 3 pro-vides some background information on the Z notation. In Section4, we present the main features of Publish/Subscribe architecturalstyle. In Section 5, we describe our methodology to design a cor-rect style. We also explain how to refine a designed style to con-sider the interconnection topology and the subscription model. InSection 6, we show how to prove the consistency of specifica-tions. Section 7 presents our approach to model reconfigurationand we explain the verification process. To illustrate our ap-proach, Section 8 presents a case study handling group communi-cation in the context of crisis and emergency managementactivities occurring during a crisis situation. In Section 9, we de-scribe the functionalities of the P/S-CoM plugin we are develop-ing. In Section 10, we give our concluding remarks and thefuture work perspectives.

2. Related work

This survey addresses research made in the area of softwarearchitecture description and focuses on works addressing both sta-tic and dynamic aspects of Publish/Subscribe systems.

Considerable research has been done on the description of thestatic as well as the dynamic aspects of software architectures.We can classify together works describing the system architecturelike Architecture Description Languages (ADLs). Among the mostprominent we can cite p-Method (Oquendo and May, 2006), Rapid(Luckham et al., 1995), Wright (Allen and Garlan, 1997), and ACME(Garlan et al., 2000). They provide modelling tools that help thedesigners to structure a system and to compose its elements. Often,ADLs allow to describe predefined dynamics. That is, they are inter-ested in systems having a finite number of configurations known inadvance. Few of them (Allen and Garlan, 1997; Garlan et al., 2000;Oquendo and May, 2006) allow various architectural styles to bedistinguished. ADLs can be classified as language-oriented works,whereas we propose a model-oriented approach which providesa more abstract view of a software architecture. ADLs rather offeran architecture view which is more close to the implementation.Additionally, ADLs allow to design architectural styles from thescratch, whereas we propose a correct by design formal approachbased on the pattern composition. It should be stressed that wedo not propose an alternative to ADLs approaches. Our modelscan be integrated into p-Method (p-ADL) or into other ADLs. Func-tional languages have also been proposed. They introduce abstractnotations allowing to describe dynamic software architectures interms of properties. In de Paula et al. (2000), the authors developeda formal framework, specified in Z, to describe the dynamic config-uration of software architectures. They did not address the designphase. Other works (Hirsch et al., 1999; Métayer, 1998) use graph

414 I. Loulou et al. / The Journal of Systems and Software 83 (2010) 412–428

grammar techniques. Graph grammars consist in using graphs forrepresenting software architectures. They are appropriate for for-mal modelling dynamic structures and software architectures. Inthis context, Métayer (1998) describes the software architecturalstyle using a context-free graph grammar and verifies the confor-mity of an architecture to its style. In this work, the author ad-dressed the client–server problem. Reconfiguration was describedwith a set of graph-rewriting rules which describe the topologicalchanges.

Other past research addressed implementing efforts for Pub-lish/Subscribe systems with scalable, distributed architectures.Several infrastructures were proposed such as SIENA (Carzanigaet al., 2001), HERMES (Pietzuch and Bacon, 2002), and JEDI (Cugo-la et al., 2001). Foundational research has also addressed formalreasoning for Publish/Subscribe systems using model checking(Baresi et al., 2005; Fenkam et al., 2003). Other approaches in-clude formal computational models for the event-based paradigmlike Baldoni et al. (2006) where authors define a computationalmodel to capture connectivity in the communication topologyof P2P systems. The work which is most closely related to ourwork is described in Baresi et al. (2005). The authors introducedan approach to model and validate Publish/Subscribe systems atthe architectural level. The modeling phase specifies how compo-nents react to events. It distinguishes between the dispatcher andthe other components. The dispatcher oversees the communica-tion and is supplied as a predefined parametric component. Theother components are specified as UML statechart diagrams.The validation uses model checking (SPIN) to prove propertiesof the federation defined as live sequence charts (LSCs). However,authors did not consider neither the communication between dis-patchers nor the interconnection topology. So, we cannot reasonabout the event dissemination inside an event service. They didnot consider the subscription mechanism which constitutes theway subscribers can express the events they are interested in.This feature allows to precise which events are produced or con-sumed by which components.

Recent research address the dynamic reconfiguration of Pub-lish/Subscribe systems. However, the major issues which havebeen addressed are about notification and (un)subscription lossas well as duplication during reconfiguration (Cugola et al., 2004;Parzyjegla et al., 2006). In Parzyjegla et al. (2006) for instance, pre-sented algorithms prevent the loss and duplication of notificationsand maintain the message ordering. In Cugola et al. (2004), authorspresented a description and analysis of an algorithm to deal withthe reconfiguration of the dispatching infrastructure.

Other directions in the field of autonomic communicating sys-tems focus on the Publish/Subscribe communication infrastructure(Keeney et al., 2007; Polyzos et al., 2005; Valetto et al., 2005). InKeeney et al. (2007) authors use the Publish/Subscribe content-based event delivery mechanism, to implement a knowledgedelivery service, which enables the efficient routing of distributedheterogeneous knowledge to, and only to, agents that have ex-pressed an interest in that knowledge. In Valetto et al. (2005), Pub-lish/Subscribe mechanism is used to describe the SIP (SessionInitiation Protocol) event framework for asynchronous event noti-fication over SIP entities.

Our work will help the architect to design a correct and elabo-rated Publish/Subscribe style by simply composing the necessaryprovided patterns. Our formalization allows us to characterizekey structural properties of the Publish/Subscribe architecturalstyle formally and at a high level of abstraction. We also addressthe dynamic aspect by offering a new notation which is sufficientlyexpressive and easy to understand. To ensure that the system isevolving correctly, we elaborate a verification process which vali-dates each rule, whose interpretation is specified in Z notation,using the Z/EVES theorem prover.

3. Background

3.1. Z notation

The Z notation is based upon set theory and mathematical lan-gage. The mathematical logic is a first-order predicate calculus. To-gether, they make up a mathematical language that is easy to learnand to apply. The mathematical language is used to describe vari-ous aspects of a design: objects, and the relationships betweenthem. Mathematical objects and their properties can be collectedtogether in schemas: patterns of declaration and constraint. Theschema language is used to structure and compose descriptions:collating pieces of information, encapsulating them, and namingthem for reuse. Reusability is vital to the successful applicationof a formal technique. The schema language can be used to de-scribe the state of a system, and the ways in which that statemay change. It can also be used to describe system properties,and to reason about possible refinements of a design. A character-istic feature of Z is the use of types. Every object in the mathemat-ical language has a unique type.

� Basic type or given set: A basic type is a set whose internal struc-ture is not defined. We may introduce elements of such a set,and associate properties with them, but we can assume nothingabout the set itself. If an object is a given set, or basic type, thenwe declare it by writing its name between brackets: for exam-ple, the declaration [Producer] introduces a new basic type calledProducer.

� Sequences: A sequence is an ordered collection of objectsdenoted between angle brackets: for example, the expressionha; b; ci denotes the sequence containing the objects a; b, andc, in that order. If X is a set, then the set of all finite sequencesof objects from X is denoted seq X. The number of elements ina sequence is often of interest: if S is a sequence, then we write#S to denote the length of S. If S is a sequence of at least nobjects, then the expression S i denotes the ith object in S.

� State Schema: A state schema consists of two parts: a declarationof variables; and a predicate constraining their values:

� Operation Schema: To describe an operation upon the state, weuse two copies of the state: one representing the state beforethe operation; the other representing the state afterwards. Todistinguish between the two, we decorate the components ofthe second schema, adding a single prime to each name. Thereis a convention for including two copies of the same schema,one of them decorated with a prime. If Schema describes thestate of a system, then DSchema is a schema including bothSchema and Schema0. Some operations involve either input tothe system and/or output from it. If a component representsan input, then its name should end with a query (?); if it repre-sents output, then its name should end with a shriek (!).

� Renaming: It is sometimes useful to rename the components of aschema; in this way, we are able to introduce a different collec-tion of variables with the same pattern of declaration and con-straint. If Pattern is a schema, then we write:

I. Loulou et al. / The Journal of Systems

Pattern½new=old�

to denote the schema obtained from Pattern by replacing compo-nent name old with new.

� Generic schema: Although we may rename the components of aschema, we cannot change their types. If we wish to use thesame structure for a variety of different types, we may definea generic schema: a schema with one or more formal parame-ters. The following schema introduces two variables, a and c,under the constraint that a is an element of c. The variable c isan element of the power set of X (denoted P X). The power setof X defines the set of all subsets of X.

The types of a and c are parameterized by the formal parameterX, which may be instantiated with any set. This schema may beused whenever we wish to introduce two objects that are relatedin this way. If we choose Z to be the actual parameterðSchema One½Z�Þ, we obtain the following schema:

� Finite set: A finite set is one whose elements are countable up tosome natural number n. For a given set X, the set of all finite sub-sets of X is denoted FX.

� Conjunction: Suppose that S and T are two schemas, we writeS ^ T to denote the conjunction of these two schemas: a newschema formed by merging the declaration parts of S and T andconjoining their predicate parts. Schema conjunction allows usto specify different aspects of a specification separately, and thencombine them to form a complete description. We may also con-join two schemas by including one in the declaration part of theother. This has the same effect as schema conjunction, in that thedeclarations are merged and the predicates are conjoined.

� Relation: In a formal specification, it is often necessary todescribe relationships between objects. These relationships canbe described using simple mathematical objects called relations.Relation is a set of ordered pairs, a subset of a Cartesian product.If X and Y are sets, then X M Y denotes the set of all relationsbetween X and Y. If R is an element of the set X M Y, then wesay that X and Y are the source and target sets of R.– Domain: The domain of a relation R is the set of elements in X

related to an element in Y: domR.– Range: The range of R is the set of elements of Y to which

some element of X is related: ranR.– Relational inverse: Relations are directed, and it is always pos-

sible to reverse this direction using the relational inverseoperator �. Source and target are exchanged, and so are theelements of each ordered pair. The relation R� maps y to xexactly when R maps x to y.

– Relational image: If R is an element of X $ Y , and A is a subsetof X, then we write R� fAg � to denote the relational image ofA under R. This is the set of all elements in Y to which someelement of A is related.

– Range restriction: If R is an element of X $ Y , and B is any sub-set of Y, then R . B denotes the range restriction of R to B: thisis the set of pairs:

fx : X ; y : Y j ðx; yÞ 2 R ^ y 2 B � ðx; yÞg

Any pair whose second element lies outside B is ignored.

4. Publish/Subscribe architectural style

The communication path over which event communication be-tween producing and consuming entities takes place includes oneor more intermediate middleware components called dispatchers.The event service is divided into two categories according to thenumber of dispatchers in the communication path over whichevent communication between producing and consuming entitiestakes place (Meier and Cahill, 2002). In the centralized event ser-vice, the communication path between producing and consumingentities includes a single intermediate dispatcher. In contrast, thedistributed event service involves two or more dispatchers throughwhich events are routed from producers to consumers. Dispatcherscooperate together to route information from the producers to thesubscribed entities. Entities connect to the most convenient, i.e.,physically closest, dispatcher. Each dispatcher manages the eventsof the entities physically connected to it and cooperates with otherintermediates to route them to remote entities. This interaction isgoverned by a principle of information dissemination stating thatthe produced information has to reach all subscribed consumers.

Cooperative distributed dispatchers cooperate with each othereither in a hierarchical, in an acyclic peer-to-peer or in a generalpeer-to-peer topology (Mahambre et al., 2007; Carzaniga et al.,2001).

In a hierarchical topology, dispatchers are connected in a hier-archy of parentchild relationships, hence forming a tree-like struc-ture. Each dispatcher in the topology has several clients that couldbe publishers, subscribers, or intermediate brokers (dispatchers).JEDI (Cugola et al., 2001) uses a hierarchical overlay topology forevent dispatching.

In an acyclic peer-to-peer topology, dispatchers communicatewith each other symmetrically as peers, adopting a protocol thatallows a bidirectional flow of subscriptions, advertisements, andnotifications. In this topology, any two dispatchers are connectedwith at most one path.

Removing the constraint of an acyclic graph from the acyclicpeer-to-peer topology, we obtain a general peer-to-peer topology.The topology is robust and resilient to failure, but may also lead tocycles.

Another characteristic is worth a particular attention: the sub-scription model. Subscribers must follow certain semantics, calleda subscription schema, when specifying their interest in an event;ditto publishers, when publishing or advertising an event. Theexisting literature distinguishes mainly between topic-based, con-tent-based and type-based models (Mahambre et al., 2007; Eugsteret al., 2003; Cugola et al., 2001).

In a topic-based subscription model, publishers generate eventsbelonging to one or more topics, while subscribers express interestin some of these topics and will therefore receive notificationsabout events published in that particular topic. Topics can overlap,leading to a hierarchy. In a content-based subscription model, sub-scriptions are based on the events actual content, which enablesfine-grained search. In a type-based subscription model, eventsare classified according to their type which ties together common-alities in structure and content.

5. A methodology to design a correct Publish/Subscribe style

The architectural style describes the kinds (types) of compo-nents and the kinds of relationships which can connect them aswell as the architectural properties which must be satisfied by allconfigurations belonging to this style. Similarly to Métayer

and Software 83 (2010) 412–428 415


(1998) and Hirsch et al. (1999), we represent software architec-tures using graphs, whose items suitably represent the architec-tural components and their interconnections. Nodes representthe component types and edges represent the communicationlinks.

In our approach, we provide a reusable set of simple patternswhich can be composed to build a Publish/Subscribe architecturalstyle. Patterns are also represented by graphs and come with theirformal semantics expressed in Z notation.

In this section, we show how to identify the generic buildingpatterns and the corresponding composition rules to design a cor-rect Publish/Subscribe style. By correctness, we mean threeproperties:

� The decoupling has to be respected. Producers and consumerscommunicate only via the event service.

� The produced information have to reach all the subscribedconsumers.

� The interaction schemas must be in conformity with the com-munication rules.

5.1. Generic patterns

The interactions between the components and the event dis-patchers are specified for architectures that use a centralized or adistributed event service. The interaction schemas must be in con-formity with the communication rules. By ensuring this property,we ensure the dissemination of events between producers and dis-patchers, on the one hand, and between dispatchers and consum-ers, on the other hand. The dissemination of events from producersto interested consumers is completely ensured if we guarantee therouting inside an event service which will be done later.

The communication between producers and event dispatcherscan be established through the push mode if the producer is the ini-tiator. The pull mode is used for interaction when the event dis-patcher is the initiator of communication. The communicationbetween consumers and event dispatchers can be establishedthrough the pull mode when the consumer is the initiator of com-munication. The push mode is used when the event dispatcher isthe initiator of communication.

To characterize the generic patterns, our idea is to consider onthe one hand the number of interaction links between clients (pro-ducers, consumers) and event dispatchers. Two cases are hencedistinguished: the first case corresponds to the situations whereone link is considered between each pair of interacting entities.The second case corresponds to the situations where two linksare considered. On the other hand, we distinguish the differentmodes of interaction. This allows us to characterize, for each ofthe previous two cases, the different patterns of correspondingarchitectures.

For example, if we consider the communication between pro-ducers and dispatchers for architectures using a centralized event

(Prod,Producer,P) (SDisp,EvDispatcher,D)PushP

(a) Pattern C_P1

(Prod,Producer,P) (SDisp,EvDispatcher,D)PullD

(b) Pattern C_P2

Fig. 1. The communication patterns betwe

service; the first case where one link of communication is consid-ered involves two patterns ðC P1 and C P2Þ depicted in Fig. 1aand b, respectively. In C P1, producers may actively produceevents towards the event dispatcher using the push mode,whereas in C P2, the event dispatcher may actively pull informa-tion from producers using the pull mode. The second case wheretwo links of communication are considered, involves one patternðC P3Þ depicted by Fig. 1c. We have to notice that the communi-cation is not necessarily done simultaneously via the two modes.The pattern expresses that it is possible to communicate throughtwo modes.

A node is described with three labels: Role; Type; Variablename, respectively. So, a node N labeled ðProd;X; PÞ denotes thatP is a set of producer components typed X. The type and variablenames will be instantiated by the architect while the role is keptunchanged. However, the Role label of dispatcher nodes has to beinstantiated by the architect to take the value SDisp to denote asingle dispatcher or the value NDisp to denote a network of dis-patchers. An edge has a direction which indicates the source andthe target of a communication. It is described with a label whichcan be modified by the architect.

Each of these patterns is formally specified with a generic sche-ma. The pattern C P3, for example, is specified with the genericschema C P3½Producer; EvDispatcher�. Since we are not interested,here, in the specification details of the components (producersand dispatchers), we introduce them as basic types.

In the declaration part of the schema C P3½Producer;EvDispatcher�, we declare a set of producing entities ðPÞ, and a sin-gle event dispatcher ðDÞ. All communication links are also declared.We specify them as relations ðPushP; PullDÞ. The first predicate[Pred-1] states that the communication between the producersand the dispatcher can be established through the push mode(when the producer is the initiator), and the pull mode (whenthe dispatcher is the initiator of communication). The two lastpredicates [Pred-2] and [Pred-3] are about the domain and therange of the defined relations. The formal specification of the pat-terns C P1 and C P2 defines only one relation for the communica-tion according to Figs. 1a and b, respectively. As it is shown in theschema C P1½Producer; EvDispatcher�, events are sent to the dis-patcher via the push mode (relation PushP), which is initiated bythe producers.

(Prod,Producer,P) (SDisp,EvDispatcher,D)

PullD

PushP

(c) Pattern C_P3

en producers and a single dispatcher.


The schema C P2½Producer; EvDispatcher� rather states thatevents are pulled (relation PullD) by the dispatcher.

We also characterize three patterns (depicted in Fig. 2) to modelthe communication between consumers and dispatchers. The pat-tern C C1 depicted in Fig. 2a states that the dispatcher has to pushevents to consumers. The pattern C C2 states that the consumershave to pull events from the dispatcher. Sometimes, we need to en-able the two modes so that both the dispatcher and the consumerscan initiate the communication. This case is modeled by the pat-tern C C3 depicted in Fig. 2c.

Each of these patterns has also been defined in Z notation. Thepattern C C1, for instance, is specified with the generic schemaC C1½Consumer; EvDispatcher�. The schema states that the eventdispatcher can push events (relation PushD) to consumers. Thepredicate part is about the domain and the range of the definedrelation PushD.

The pattern C C2 is described with the schema C C2½Consumer;EvDispatcher�. It states that events can be pulled by consumersfrom the event dispatcher.

The pattern C C3 is described with the schema C C3½Consumer;EvDispatcher�. It states that events can either be pushed toconsumers by the event dispatcher, or pulled by consumersthemselves.

In addition, we take into consideration the fact that an entitycan behave as both a producer and a consumer (Prod/Cons). Tocharacterize the corresponding generic patterns, we have to offerat least two links between a Prod/Cons entity and an event dis-patcher: one link for the producer communication and one linkfor the consumer communication. So, we have characterized otherdesign patterns.

However, architectures exploiting a distributed event serviceneed, in addition, the details concerning the interactions betweendispatchers, on the one hand, and some other details about theinteraction between clients and dispatchers, on the other hand.

These details are related to the principle of information dissemina-tion. Accordingly, we consider three constraints:

� C1: if two dispatchers communicate together then it is necessarythat the information coming from the first reaches the second.So, the communication has to be bidirectional.

� C2: all event dispatchers have to be interconnected (direct ortransitive connection).

� C3: each client (producer, consumer, or both denoted) must havea single access point in the network of dispatchers.

For example, the formal specification of the pattern involved bythe second case, where producers may actively produce events to-wards event dispatchers using the push mode and event dispatch-ers may actively pull information from producers using the pullmode, is described with the schema D P3½Producer; EvDispatcher�.The predicates [Pred-5] and [Pred-6] describe the constraints C1and C2, respectively. The constraint C3 is specified with thepredicate [Pred-7]. It states that a producer entity is connected toat most one dispatcher. We also have to notice that eventdispatchers communicate together using the push mode in orderto propagate events (specified with the relation PushDD in thepattern schema).

5.2. How to compose a style?

In this section, we define the allowed composition operations todesign a correct Publish/Subscribe style and we show how to con-struct the formal specification of the designed style based on pat-tern specifications and according to the applied compositionoperations.

� Add_pattern: When the architect adds a pattern, its correspond-ing schema name is included in the declaration part of the styleschema as follows:

(Prod,Producer,A) (NDisp,EvDispatcher,D)PushP

(Cons,Consumer,B)PushD

(PrCons,Prod_Cons,C)

Push PushPC

D_P1 D_C1

D_PC1

Fig. 3. Graph obtained by composition of patterns.

(Cons,Consumer,C) (SDisp,EvDispatcher,D)

PushD

PullC(Cons,Consumer,C) (SDisp,EvDispatcher,D)

PushD

(Cons,Consumer,C) (SDisp,EvDispatcher,D)PullC

(a) Pattern C_C1

(b) Pattern C_C2

(c) Pattern C_C3

Fig. 2. The communication patterns between consumers and a single dispatcher.


Where Pari are the formal parameters of the added pattern gen-eric schema.

� Modify_labels: The architect can rename the edge labels, thenode labels corresponding to the formal parameters and thedeclaration variables. The specification is accordingly modifiedas follows:

The first part corresponds to the supplied formal parameters. Inthe second part, we use the renaming option in Z notation wherethe new names of variables are given by the architect.

� Merge_Prod, Merge_Cons or Merge_PC: Given two graphs, we canmerge their producer nodes (resp. Cons; Prod=Cons) in twocases:– If the nodes in question are connected to the same event dis-

patcher node, then they must be connected with the sametypes of links.

– If the nodes in question are not connected to the same eventdispatcher node, the merging is possible regardless of thetypes of links.

� Merge_disp: Given two graphs, we can merge their dispatchernodes if both of them correspond to a single dispatcher (SDisp)or a set of dispatchers (NDisp). In addition, we distinguish twocases:– If we have two separate graphs, the merging is possible

without any constraint.– If these graphs have a common node (Prod or Cons or

Prod=Cons), then this node must communicate in the samemanner with the two dispatcher nodes, otherwise it becomesmeaningless to merge them.

When the merging is applied, this is described by renaming thevariable D ðEvDispatcher or F EvDispatcherÞ so that the two graphshave the same variable referring to the same node. For example,the graph depicted in Fig. 3 is obtained by adding the patternsD P1; D C1 and D PC1, renaming some variables and merging theirdispatcher nodes. The resulting specification is as follows:

The formal specification of the pattern D P1 is defined by the gen-eric schema D P1½Producer; EvDispatcher�. The predicates [Pred-3],[Pred-4] and [Pred-5] describe the constraints C1; C2, and C3,respectively, given in Section 5.1 and which are related to the prin-ciple of event dissemination. The pattern states that events arepushed by the producers to the dispatchers via the relation PushP.The dissemination of events between the dispatchers is made viathe push mode (defined by the relation PushDD).


The pattern D C1 is formally described with the generic stateschema D C1½Consumer; EvDispatcher�. Since the pattern belongsto the situations of architectures using a distributed event service,we specify here the constraints C1; C2, and C3 given in Section 5.1.They are described here with the predicates [Pred-3], [Pred-4] and[Pred-5], respectively. The pattern states that events are pushed bythe dispatchers to the consumers via the relation PushD. The dis-semination of events between the dispatchers is made via the pushmode (defined by the relation PushDD)

The formal specification of the pattern D PC1 is defined by the gen-eric schema D PC1½Prod Cons; EvDispatcher�. The constraints C1; C2,and C3 given in Section 5.1 are described here with the predicates[Pred-5], [Pred-6] and [Pred-7], respectively. The pattern states thatevents may be pushed by the dispatchers to the Prod/Cons entitiesvia the relation Push and pushed by the Prod/Cons entities to thedispatchers via the relation PushPC. The dissemination of events be-tween the dispatchers is made via the push mode (defined by therelation PushDD).

5.3. Interconnection topologies

We provide to the architect the possibility to refine designedstyles in order to consider the interconnection topology of theunderlying dispatchers. For this purpose, we propose to specifythe hierarchical, acyclic peer-to-peer, and general peer-to-peertopology in Z notation, so that, the interested architect can choosethe desired topology and the style specification will be refined sys-tematically by creating a new schema which is a conjunction of thestyle and the topology schemas. For example, the Z specification ofacyclic-peer-to-peer topology is as follows:

Let us suppose that the architect has composed the graphstyle depicted in Fig. 3 and he/she decided to specify the topol-ogy underlying the dispatchers, let us say acyclic-P2P. Followingour approach, the architect has only to choose the desiredtopology and the resulting specification will be simply obtainedby the conjunction of the style schema and the schemaacyclic P2P½EvDispatcher�.

5.4. Subscription model

The architect can also refine the designed styles in order to con-sider the underlying subscription model. This feature allows thearchitect to define and check which events are produced (con-sumed) by which components. For this purpose, we can refinefirstly the specifications of communicating entities and the eventdispatchers, so that they are not considered as basic types any-more. For example, let us suppose that the architect of the style de-picted in Fig. 3 decides to choose the topic-based model. In thiscase, producers maintain the list of topics on which they want topublish events, consumers maintain the list of topics they areinterested in, producer/consumer components keep the two listsand event dispatchers keep the list of supported topics. So, theresulting specification is as follows:

½TOPIC�

Where TOPIC is introduced as a basic type. Secondly, we can addthe necessary constraints in the predicate part of the schema Style1to precise the topics allowed for each component type. We willillustrate in Section 8 how much it is interesting to specify the sub-scription model and its impact on the system understanding.


6. Proving consistency

In general, to check the consistency of a specification we haveto prove that at least one model exists. In Z, if we deal with aschema describing the state of a system, it consists to provide aschema which instantiates it. A Z schema may be inconsistent,i.e. it includes a predicate which cannot be satisfied or a contra-diction between predicates. If such a schema is elaborated to de-scribe the state of a system, then that system could not berealized. Suppose that State describes the state of the system,and that StateInit characterizes an initial state. If we can provethe following theorem:

Theorem Consistency

9 State � StateInit

then this ensures that an initial state exists, and hence the require-ments upon the state components are consistent. This result iscalled the initialization theorem.

For example, to check the consistency of the schemaC P3½Producer; EvDispatcher�, we proceed as follows: we assumethat the initial configuration contains one producer p1 and one dis-patcher d1 which are connected via the links declared in the sche-ma pattern:

Fig. 4. Consistency proof of the pattern C P3.

(Cons,Controller,C) (SDisp,Manager,M)Push_M

A style graph

Fig. 5. Example of an architectural style

The initialization theorem is therefore:

Theorem Consistent CP39 C P3½Producer; EvDispatcher� � InitC P3

We develop the proof of this theorem under the Z/EVES theoremprover as it is shown in Fig. 4. The value Y in the column Proofmeans that the theorem is successfully proved. Accordingly, thepattern specification consistency is proved.

Besides, to prove that any constructed specification correspond-ing to a designed style, following our approach, is consistent, theidea is to prove that all pattern specifications are consistent andthat all composition rule specifications preserve consistency. Sowe implemented under Z/EVES the proof of the initialization theo-rems of all pattern specifications and an analytic proof is done forall composition rules. We also proved the consistency of all topol-ogy schemas and the refinement operations.

7. The dynamic aspect of Publish/Subscribe architectures

In this section, we show how we model the reconfiguration ofPublish/Subscribe architectures and also explain how to preservethe style properties during reconfiguration.

Architectures represent instances of the architectural style of asystem. As for styles, we represent architectures with graphs. Inthe architecture graph (right side of Fig. 5, a node represents acomponent instance. It is divided into two parts separated by adashed line in nodes of Fig. 5. The upper part contains two labels,the Instance and the Type, respectively. The lower part contains onelabel representing the Role (eg. Cons, EvDispatcher). Only the labelInstance could be modified by the architect since the two others re-sult from the style graph. For example, in the style graph depictedon the left of the Fig. 5, the first node models a set ðCÞ of compo-nents of type Controller that act as event consumers ðConsÞ. Thesecond node models a single component ðMÞ of type Manager thatacts as an event dispatcher. The manager could push events to acontroller component via the link Push M. One possible instanceof this style may contain two controllers and the manager commu-nicating through the link Push M as it is depicted on the right of thesame Fig. 5.

The four basic reconfiguration operations, provided by most oflanguages and systems (Métayer, 1998; Allen et al., 1998; Werme-linger and Fiadeiro, 1999), are the creation and removal of compo-nents and connections (Wermelinger and Fiadeiro, 1999). Graphgrammars showed their relevance to express such reconfiguration

M:Manage r EvDispatcher

c2 :Controller Cons

Push_M

An architecture graph

c1 : Controller Cons Push_M

graph and a conforming instance.

Rule Name

Left graph(L)

Right graph(R)

Pre-conditionsPost-conditions

Fig. 6. The visual notation of a graph transformation rule.


operations in particular in the works described in Wermelingerand Fiadeiro (1999) and Métayer (1998). A graph transformationrule rewrites a graph into another graph, deleting some elements(nodes and edges), generating new ones and preserving others.The basic approach to transform a graph G into a graph G0 is to re-place a sub-graph m of G by a graph d. G0 is the graph resulting fromthese two operations. G is called the host graph, m is called mothergraph and d is called daughter graph. In this approach, a graphtransformation rule is described in the basic model by a pair ofgraphs ðL;RÞ. This rule is applicable to a graph G if there is an occur-rence of L in G. As a consequence, its application implies the re-moval of the occurrence Del ¼ ðL n ðL \ RÞÞ and the insertion of acopy of Add ¼ ðR n ðL \ RÞÞ.

In Publish/Subscribe architectural style, we also need to specifyconstraints on some attribute values related to the subscriptionmodel, for instance. Furthermore, we need to define the post-con-ditions of an operation to describe what must be ensured after theapplication of an operation. For example, any reconfiguration ruledefined to modify the network of dispatchers, has to ensure at leastthe constraints C1; C2, and C3 (described in Section 5.1) after itsapplication. It has also to ensure that the topology is preservedafter reconfiguration.

So, we adopt a visual notation which contains a structural partfollowing the basic graph-rewriting approach, and an analytic partspecified in Z notation, as it is depicted in Fig. 6. Given a rule r, it isapplied to a graph g by the following steps:

1. A subgraph isomorphic to L is identified in g.2. If no isomorphic subgraph exists, r cannot be applied to g.3. The pre-conditions and the post-conditions parts are evaluated.

They must be satisfied otherwise r cannot be applied.4. The elements of the subgraph isomorphic to the retraction

Del ¼ ðL n ðL \ RÞÞ are removed from g, leaving the host graph.5. A graph isomorphic to the insertion Add ¼ ðR n ðL \ RÞÞ is

inserted into the host graph g.

7.1. Formal semantics of graph-rewriting in Z notation

We propose to describe the semantics of a reconfiguration rulein the Z notation so as to carry out analysis and verification. Eachrule is described with an operation schema as follows:

Where:

� ini? is an input parameter of the reconfiguration rule,� DSchema name indicates that the rule will change the system

state.� The functional constraints are about the attribute values, the

number of component instances, etc.

7.2. Style preservation during evolution

In order to verify that a given reconfiguration rule makes thesystem evolve correctly (w.r.t. its architectural style), we proposeto use the precondition theorem provided in Z notation. This theo-rem is described as follows:

Theorem Correctness

8 State; in? : INPUTjpreconditionðState;in?Þ� preOp

where:

� State is the schema name of the designed style,� in? the input parameters of the rule,� preconditionðState; in?Þ are the pre-conditions upon state vari-

ables and input parameters which must be satisfied beforehand,� Op is the rule schema name,� and pre Op characterizes the collection of before states and

inputs for which some after state can be shown to exist.Formally:

pre Op ¼ 9 State0; out! : OUT � Op

This theorem states the following: whatever could be the sys-tem state ðStateÞ, with the input parameters and the assertedpre-conditions, a correct after state can be shown to exist ðState0Þ.

In order to check that a reconfiguration rule is style preserving,we develop the proof of this theorem under the Z/EVES theoremprover. Trying to prove this theorem under Z/EVES will uncoverthe missing hypotheses which characterize the collection of beforestates and inputs for which some after state can be shown to exist.It has to be stressed that this theorem supposes that the rule is cor-rect. Accordingly, if the identified hypothesis are coherent with therule context, then we can say that the rule is definitely correct andthus style preserving. However, if the proof process requireshypotheses which imply that the before state is not correct w.r.tthe style, then we can say that the rule is not correct and thusnot style preserving.

To sum up the checking process, we have to stress that two ben-efits can be taken when trying to prove the precondition theorem.If the rule is proved to be correct, then we can add the identifiedmissing hypothesis in the rule schema, so that we explicit the pre-condition of the rule. However, if the rule is proved to be incorrect,it is interesting to precise here that the hypothesis required by theprover will guide the user to identify the causes of the incorrect-ness, actually. Accordingly, he/she can correct the rule.

8. Case study

To illustrate our approach, we choose a case study in the con-text of CEO-like (Crisis Emergency Operation) activities occurringduring a crisis situation (Guennoun et al., 2008). The applicationinvolves structured groups of robots or military personnel whocooperate for the realization of a common mission. An emergencyoperation team involves various jobs: a global controller of themission, several coordinators, and several sections of investigators.The controller manages the whole coordinators and each coordina-tor supervises a section of investigators.


Each job is associated with the following functions (Guennounet al., 2008):

� The controller is the entity that supervises all the application;he/she receives the reports of all coordinators that synthesizethe current context and inform him/her of mission advance.

� According to actions and objectives assigned by the controller, acoordinator manages a section of investigators by giving ordersand assigning tasks to be performed. He/She must also collect,interpret and synthesize information received from its investi-gators and post them towards the controller.

� Investigators explore the operational field, to observe, analyzeand submit reports describing the situation to their assignedcoordinator. Investigators also act for helping, saving andrepairing.

As depicted in Fig. 7, investigators provide continuous descrip-tive feedbacks ðD InvÞ and periodical produced feedbacks ðP InvÞ.D Inv data aim to describe the environment observed by an inves-tigator. It corresponds to a description of its immediate environ-ment like the topography of the investigated area, temperature,wind strength, etc. P Inv data express the analysis of the situationby an investigator. It may correspond, for example, to comments

P_Coord

D_Inv,P_InvD_Inv,P_Inv

D_Inv

Section (S2)

Coordinator ofSection (S2)

Controller

Investigators

Fig. 7. CEO s

(Cons,Controller,Cont) (NDisp,ManaPush_M

(PrCons,Coordinat

Push_CM

Fig. 8. CEO

linked to D Inv data (e.g. analysis of the dangerousness of the sit-uation) or to reports related to the furtherance of the mission (e.g.actions underway and need of reinforcements).

Having discovered a critical situation, the concerned investiga-tor provides feedbacks D Inv to the other investigators. The coordi-nators complete the received analysis to send them ðP CoordÞthereafter to the controller.

We propose to model this CEO application following the event-based architectural style. So, the propagation of events betweenparticipants is mediated through a network of event dispatcherscalled managers. Both investigators and coordinators are associ-ated with producer–consumer components and the controller be-haves as a consumer entity.

8.1. Style design

To design the corresponding architectural style, we apply therule Add Pattern to the pattern D C1 and to D PC1 twice. Then,we apply the composition rule Modify labels to supply the desiredparameters and to rename some declaration variables. After that,we apply the rule Merge disp twice to obtain the node M represent-ing the group of managers. So the resulting graph is depicted inFig. 8.

P_Coord

D_Inv,P_Inv D_Inv,P_Inv

D_Inv

D_Inv

Section (S1)

Coordinator ofSection (S1)

cenario.

ger,M)

or,Coord)

Push_MC

(PrCons,Investigator,Inv)

Push_IM

Push_MI

style.


The formal specification is built progressively as the style wasdesigned, based on the applied rules.

½Controller; Investigator; Coordinator;Manager�

To explicit the declaration and the predicate part, we propose toexpand the obtained schema. According to the formal specifica-tions of the patterns D C1 and D PC1 given in Section 5.2, the ex-panded specification is therefore as follows:

Once the style is designed and the specification is built, thearchitect can refine the style with additional properties. Accordingto the description of the CEO application, he/she should precisethat there is only one coordinator per section. He/She also can de-fine the adopted subscription model to specify which informationis consumed or produced by which component. The constraintsdescribing the exchanged event topics ðD Inv ; P Inv ; P CoordÞare not defined in the style specification yet. One solution for defin-ing such additional constraints is to add this information in thegraph itself using either a label or a color for every event topic.The disadvantage of this solution is the overload of the graph ifseveral topics are concerned.

Moreover, architecturally one could understand that the con-troller can consume the events coming from both investigatorsand coordinators, which is not in conformity with the descriptionof the application. Another property has to be defined: the investi-gators communicate with each other only if they belong to thesame section. So does a coordinator. He communicates only withthe investigators belonging to his section.

We propose to make it possible to the user to refine the speci-fication of involved components and to add the necessary con-

straints in the predicate part of the style schema. As asubscription model, we choose the content-based and we proposethe following refinement:

½IDENTIFIER; CONTENT;NAME; TOPIC�

And the formal specification of the Emergency system with theadded constraints is therefore:

We explain in the following the specification refinement:

� The component types Controller, Manager, Investigator and Coor-dinator are not considered as basic types anymore. For example,

we refine the coordinator type with information concerning theproduced and consumed events and the section name hebelongs to. These information will serve to specify some con-straints as explained in the following.


� We add a new schema describing the type EVENT following thecontent-based model definition. An event may have the follow-ing attributes: a global identifier, a topic, a section name andcontents. When a given component produces an event, the attri-bute section name will take the name of the associated section.

� Pred-14 states that the controller receives only events which thetopic is P Coord.

� Pred-15 states that every coordinator receives only events com-ing from the investigators belonging to his section and whichthe topic is D inv or P Inv .

� Pred-16 states that every coordinator produces only eventswhich the topic is P Coord.

� Pred-17 states that every investigator receives only events com-ing from the investigators belonging to his section and whichtopic is D Inv .

� Pred-18 states that every investigator can produce only eventswhich topic is D Inv or P Inv .

� Pred-19 states that managers support only events which topic isD Inv ; P Inv or P Coord.

� Pred-20 states that there is only one coordinator per section.

Let us consider now the interconnection topology underlyingthe network of managers. In the acyclic as well as in the hierarchicaltopology, the lack of redundancy in the topology constitutes a lim-itation in assuring connectivity, since a failure in one manager misolates all the subnets reachable from those managers directly con-nected to m. Since the CEO situations are critical, one should betterchoose the general P2P topology where we find multiple pathsrelating any two dispatchers. The resulting specification is built asa conjunction of both the style schema and the topology schema:

8.2. Reconfiguration specification

In this section, we present the specification of some rules allow-ing evolving our Emergency refined subscription system while tak-ing into account its defined properties.

� Insertion of a coordinator: this rule inserts an instance of a com-ponent of type Coordinator and connects it to a manager. The ruleis visually expressed in Fig. 9 and formally described by theschema Insert Coordinator. According to this schema, a coordina-tor c1 will be added to the set of coordinators Coord and con-nected to the manager m1 via the links Push CM and Push MC.The rule will be applied only if the coordinator c1 will supervises

Fig. 9. Insertion of

a section of investigators which has not a coordinator yet. Thiscondition is required by the predicate [P1] of the rule schemain order to respect the predicate [Pred-20] of the schemaEmergency refined subscription.

� Link substitution: An existing link between two managers isremoved from the topology and a new link is added instead.

The rule is formally defined with the schema Link Substitute.The predicate [P1] requires that once this rule is applied, thetopology of the managers remains interconnected. This condi-tion is made in order to respect the predicate [Pred-10] of theschema Emergency. In addition, we have to ensure that the con-nection/disconnection respects the predicate [Pred-3] whichrequires a bidirectional communication between managers. Thiscondition is expressed by the predicate [P2] in the rule schema.It should be noticed that [Pred-3] and [Pred-10] are specifiedrespectively according to the constraints C1 and C2 mentionedin Section 5.1.The rule described hereafter disconnects the manager m3 fromm2 and connects it to the manager m1 instead. This reconfigura-tion is expressed with [R1].

a coordinator.


8.3. Safe reconfiguration checking

In this section, we show how we use the theorem prover of Z/EVES to formally verify for each reconfiguration rule that it ensuresa safe reconfiguration of the system.

8.3.1. Validation of Insert CoordinatorAs explained in Section 7.2, the first step of the verification pro-

cess is to try to prove the precondition theorem for the concernedreconfiguration rule. Accordingly, we tried to prove the followingtheorem for the Insert Coordinator rule,

Theorem precondition coord

8 Emergency refined subscription;

m1? : Manager; c1? : Coordinator

jc1? R Coord

^m1? 2 M

^ ð8x; y : Coord [ fc1?gjx–y� x:Sect coord–y:Sect coordÞ

� pre Insert Coordinator

However, this theorem cannot be proved since the pre-condi-tions described in the operation schema are not sufficient. Afterseveral iterations with the theorem prover, we succeeded to provethe following (the proof window is depicted in Fig. 10):

The prover uncovers the missing hypotheses [Post1] and [Post2]which are not specified in the operation schema Insert Coordinator.Since the set of coordinators has been changed ðCoord0Þ, Z/EVESprover checks all the properties related to this set and describedin the schema style Emergency refined subscription. Whence thepost-conditions related to the predicates [Pred-15] and [Pred-16].Accordingly, we can confirm that the operation is definitely correct

Fig. 10. Proof of the rule Insert Coordinator.

and thus style preserving. Therefore, the second step of the verifi-cation process is to add the identified missing hypothesis ([Post1]and [Post2]) in the operation schema, so that we explicit the pre-condition of the operation which characterizes the collection of be-fore states and inputs for which some after state can be shown toexist.

8.3.2. Validation of Link SubstituteWe have proceeded in the same way to verify wether the rule

Link Substitute preserves the stylistic constraints. The theoremhas been successfully proved from the first iteration. The operationLink Substitute is style preserving and describes all necessary pre-and post-conditions to leave the system Emergency� refinedsubscription in a correct state.

9. Implementation: the P/S-CoM plugin

We developed in Java a plugin that we integrated in the Fujabaenvironment in order to assist software architects in the P/S-CoMdesign process. The plugin functionalities include:

� Style design1. Assist the architect to visually design his/her Publish/Sub-

scribe style by applying the appropriate composition ruleson the concerned patterns.

2. Build the formal specification progressively and automati-cally as the style is designed by the architect, based on theapplied composition rules.

3. Allow the refinement of the style specification by adding thetopology description.

4. We use the standard UML visual notation for representingstyles as handled by architects. Once the style is designedand refined, the style graph will be represented followingextended component diagrams. For this purpose, we areworking on defining the necessary stereotypes in order torepresent the concepts we introduced in P/S-CoM (Role, edgelabel,. . .). The stereotypes extend the component and con-nector metamodels of UML 2.0.

� Reconfiguration design1. Allow the description of reconfiguration rules.2. Generate automatically the formal specification (in Z nota-

tion) of the described reconfiguration rules.

We have achieved developing the first step of the style designphase and we are working on the rest of functionalities. To designa style, we provide a structural profile proposed in Kacem et al.(2006) as an extension of UML 2.0 to support the concept of archi-tectural style. The profile is composed of three parts: Structural-Name which specifies the style name, StucturalFeature in whichwe can design the style and Guards in which we describe the ana-lytic constraints.

Our plugin architecture is composed of six packages. For exam-ple, the package metamodel describes the class diagram of the plu-gin metamodel which describes the concept of a pattern. Thediagram contains six classes including MyNode and MyEdge classes.The package dialog specifies the dialogue boxes displayed to thearchitect during the design process. The package actions describesthe classes involved in handling actions initiated by the architects.The associated class diagram is depicted in Fig. 11. The class New-PublishSubscribeDesignAction, for example, is used to create a newP/S-CoM diagram. The class NewStructuralProfileAction is used tocreate a new structural profile containing the StructuralName,StucturalFeature and Guards parts. The class NewMyPatternAction

Fig. 11. Class diagram of actions package.

Fig. 12. Examples of P/S-CoM interfaces.


is associated to the composition rule Add_Pattern. The classEditPatternAction is used for pattern relabeling rules. As it is shownby the class diagram, other classes are involved to ensure the de-sign of a style.

Fig. 12a shows the interface displaying the visual description forthe architect when he/she wants to add a pattern. He/she can reusethe three types of communication patterns we formally presentedin Section 5.1: Producer–Dispatcher, Consumer–Dispatcher andProducerConsumer–Dispatcher communications. He/she also canmodify the parameters of the reused pattern while being guidedand controlled by the composition rules. Fig. 12b shows the archi-tectural style of the CEO case study.

10. Conclusion

In this paper we have presented P/S-CoM, a formal approachsupporting the modeling of correct Publish/Subscribe architecturalstyles and safe reconfiguration of dynamic architectures for event-based communication. Our formalization allows us to characterizekey structural properties of the Publish/Subscribe architecturalstyle formally and at a high level of abstraction. We elaborated areusable set of proved patterns and the corresponding compositionrules to build architectural styles. Our approach ensures the prin-ciple of information dissemination stating that the produced infor-mation must reach all the subscribed consumers. Patterns are


represented by graphs and come with their formal semantics ex-pressed in Z notation. The designed style is also supported by itsformal specification which is built progressively as the style wasdesigned, based on the applied composition rules. Elementaryrefinements of the style specification could be done in order toconsider the subscription model as well as the interconnectiontopology. Furthermore, we have proposed a formal approach forthe specification of the dynamic aspect of Publish/Subscribe archi-tectures. This approach is based on graph-based semantics and theformal language Z. It allows us to formally describe the dynamicsof a software architecture using graph-rewriting rules. In order toguarantee the safe reconfiguration, we have elaborated a verifica-tion process to check that all the defined operations preserve theproperties of the architectural style during reconfiguration. Thisprocess has been implemented and successfully validated underthe Z-EVES theorem prover. From an experimental point of view,we are developing a plugin for the Fujaba environment to assistarchitects in the P/S-CoM visual design process.

References

Abowd, G.D., Allen, R., Garlan, D., 1995. Formalizing style to understanddescriptions of software architecture. ACM Trans. Softw. Eng. Methodol. 4 (4),319–364.

Aldini, A., Bernardo, M., 2005. On the usability of process algebra: an architecturalview. Theor. Comput. Sci. 335 (2–3), 281–329.

Allen, R., Douence, R., Garlan, D., 1998. Specifying and analyzing dynamic softwarearchitectures. In: FASE, pp. 21–37.

Allen, R., Garlan, D., 1997. A formal basis for architectural connection. ACM Trans.Software Eng. Methodol. 6 (3), 213–249.

Baldoni, R., Scipioni, S., Tucci-Piergiovanni, S., 2006. Communication channelmanagement for maintenance of strong overlay connectivity. In: ISCC ’06:Proceedings of the 11th IEEE Symposium on Computers and Communications.IEEE Computer Society, Washington, DC, USA, pp. 63–68.

Baresi, L., Ghezzi, C., Zanolin, L., 2005. Modeling and validation of publish/subscribearchitectures. In: Beydeda, S., Gruhn, V. (Eds.), Testing Commercial off the ShelfComponents And Systems, pp. 273–292.

Carzaniga, A., Rosenblum, D.S., Wolf, A.L., 2001. Design and evaluation of a wide-area event notification service. ACM Trans. Comput. Syst. 19 (3), 332–383.

Cheng, S.-W., Garlan, D., Schmerl, B., 2005. Making self-adaptation an engineeringreality. In: Proceedings of the Conference on Self-Star Properties in ComplexInformation Systems. LNCS, Vol. 3460. Springer-Verlag, pp. 158–173.

Cheng, S.-W., Garlan, D., Schmerl, B.R., Sousa, J.P., Spitnagel, B., Steenkiste, P., 2002.Using architectural style as a basis for system self-repair. In: WICSA 3:Proceedings of the IFIP 17th World Computer Congress – TC2 Stream/ 3rd IEEE/IFIP Conference on Software Architecture. Kluwer B.V., Deventer, TheNetherlands, pp. 45–59.

Cugola, G., Di Nitto, E., Fuggetta, A., 2001. The JEDI event-based infrastructure andits application to the development of the OPSS WFMS. IEEE Trans. Softw. Eng. 27(9), 827–850.

Cugola, G., Frey, D., Murphy, A.L., Picco, G.P., 2004. Minimizing the reconfigurationoverhead in content-based publish-subscribe. In: SAC ’04: Proceedings of the2004 ACM symposium on Applied computing. ACM Press, New York, NY, USA,pp. 1134–1140.

de Paula, V.C.C., Ribeiro-Justo, G.R., Cunha, P.R.F., 2000. Specifying and verifyingreconfigurable software architectures. In: PDSE ’00: Proceedings of theInternational Symposium on Software Engineering for Parallel and DistributedSystems, pp. 21–31.

Dean, T.R., Cordy, J.R., 1995. A syntactic theory of software architecture. IEEE Trans.Softw. Eng. 21 (4), 302–313.

Eugster, P.T., Felber, P.A., Guerraoui, R., Kermarrec, A.-M., 2003. The many faces ofpublish/subscribe. ACM Comput. Surv. 35 (2), 114–131.

Fenkam, P., Gall, H., Jazayeri, M., October 2003. A systematic approach to thedevelopment of event based applications. In: The 22nd Symposium on ReliableDistributed Systems (SRDS 2003), Florence, Italy, pp. 199–208.

Garlan, D., Monroe, R.T., Wile, D., 2000. Acme: architectural description ofcomponent-based systems. In: Leavens, G.T., Sitaraman, M. (Eds.),Foundations of Component-based Systems. Cambridge University Press, pp.47–68.

Guennoun, K., Drira, K., Wambeke, N.V., Chassot, C., Armando, F., Exposito, E., 2008.A framework of models for qos-oriented adaptive deployment of multi-layercommunication services in group cooperative activities. Comput. Commun. 31(13), 3003–3017.

Hirsch, Dan, Inverardi, Montanari, Ugo, 1999. Modeling software architectures andstyles with graph grammars and constraint solving. In: Donohoe, P. (Ed.), FirstWorking IFIP Conference on Software Architecture. Kluwer AcademicPublishers, San Antonio, TX, pp. 127–142. February.

Jaeger, M.A., Mühl, G., Werner, M., Parzyjegla, H., 2006. Reconfiguring self-stabilizing publish/subscribe systems. In: State, R., van Meer, S., O’Sullivan, D.,Pfeifer, T. (Eds.), 17th IFIP/IEEE International Workshop on Distributed Systems:

Operations and Management (DSOM 2006), LNCS, vol. 4269. Springer, Dublin,Ireland, pp. 233–238. October.

Kacem, M.H., Jmaiel, M., Kacem, A.H., Drira, K., 2006. An uml-based approach forvalidation of software architecture descriptions. In: Draheim, D., Weber, G.(Eds.), 2nd International conference on Trends in Enterprise ApplicationArchitecture (TEAA 2006), Lecture Notes in Computer Science, vol. 4473.Springer-Verlag, Berlin, pp. 158–171.

Keeney, J., Lewis, D., OSullivan, D., 2007. Ontological semantics for distributingcontextual knowledge in highly distributed autonomic systems. J. Network Syst.Manage. 15 (1), 75–86. March.

Luckham, D.C., Kenney, J.L., Augustin, L.M., Vera, J., Bryan, D., Mann, W., 1995.Specification and analysis of system architecture using Rapide. IEEE Trans.Softw. Eng. 21 (4), 336–355.

Mahambre, S.P., Madhu Kumar, S.D., Bellur, U., July–August 2007. A taxonomy ofqos aware, adaptive event-dissemination middlewatre. IEEE InternetComputing 11 (4), 35–44.

Meier, R., Cahill, V., 2002. Taxonomy of distributed event-based programmingsystems. In: Bacon, J., Fiege, L., Guerraoui, R., Jacobsen, A., Mühl, G. (Eds.),Proceedings of the 1st International Workshop on Distributed Event-basedSystems (DEBS’02).

Métayer, D.L., 1998. Describing software architecture styles using graph grammars.IEEE Trans. Softw. Eng. 24 (7), 521–533.

Moriconi, M., Qian, X., Riemenschneider, R.A., 1995. Correct architecturerefinement. IEEE Trans. Softw. Eng. 21 (4), 356–372.

Oquendo, F., 2006. p-Method: a model-driven formal method for architecture-centric software engineering. ACM SIGSOFT Softw. Eng. Notes 31 (3), 1–13.

Parzyjegla, H., Muhl, G.G., Jaeger, M.A., 2006. Reconfiguring publish/subscribeoverlay topologies. In: ICDCSW ’06: Proceedings of the 26th IEEE InternationalConference Workshops on Distributed Computing Systems. IEEE ComputerSociety, Washington, DC, USA, p. 29.

Pietzuch, P.R., Bacon, J., 2002. Hermes: a distributed event-based middlewarearchitecture. In: International Conference on Distributed Computing Systems,Workshops (ICDCSW ’02). IEEE Computer Society, Vienna, Austria, pp. 611–618.July.

Pietzuch, P.R., Mühl, G., Fiege, L., 2007. Distributed event-based systems: Anemerging community. IEEE Distributed Systems Online (DSOnline) 8 (2), 2.

Polyzos, G.C., Ververidis, C.N., Efstathiou, E.C., 2005. Service discovery and provisionfor autonomic mobile computing. In: WAC. Lecture Notes in Computer Science,vol. 3854. Springer, pp. 222–236.

Shaw, M., Garlan, D., 1996. Software Architecture: Perspectives on an EmergingDiscipline. Prentice-Hall.

Spivey, J.M., 1989. The Z Notation: A Reference Manual. Prentice-Hall Inc., UpperSaddle River, NJ, USA.

Valetto, G., Goix, L., Delaire, G., 2005. Towards service awareness and autonomicfeatures in a sip-enabled network. In: WAC. Lecture Notes in Computer Science,vol. 3854. Springer, pp. 202–213.

Wermelinger, M., Fiadeiro, J.L., 1999. Algebraic software architecturereconfiguration. SIGSOFT Softw. Eng. Notes 24 (6), 393–409.

Zieba, B., van Sinderen, M., 2006. Preservation of correctness during systemreconfiguration in data distribution service for real-time systems (dds). In:ICDCSW ’06: Proceedings of the 26th IEEE International Conference Workshopson Distributed Computing Systems. IEEE Computer Society, Washington, DC,USA, p. 30.

Imen Loulou received the Master degree in Computer Science from the Faculty ofEconomics and Management of Sfax (Tunisia), in October 2003. She is preparing thePh.D. degree in Computer Science at FSEGS, University of Sfax (Tunisia). She is since2007, an Assistant Professor of Computer Science at the Faculty of Sciences of Gabès(Tunisia). She is member of the ReDCAD Research Unit (http://www.redcad.org).Imen Loulou’s research interests focus on formal design of software architectures,component-based architectures and architecture-based software evolution.

Mohamed Jmaiel obtained his diploma of engineer in Computer Science from Kiel(Germany) University in 1992 and his Ph.D. from the Technical University of Berlinin 1996. He joined the National School of Engineers of Sfax (Tunisia) as AssistantProfessor of Computer Science in 1995. He became an Associate Professor in 1997and full Professor in January 2009. He participated to the initiation of many grad-uate courses at the University of Sfax. His current research areas include softwareengineering of distributed systems, formal methods in model-driven architecture,component oriented development, self-adaptive and pervasive systems, autonomicmiddleware. He published more than 100 regular and invited papers in interna-tional conferences and journals, and has co-edited four conferences proceedingsand three journals special issues on these subjects. More details are available on hishome page: http://www.redcad.org/~MohamedJmaiel.

Khalil Drira received the Engineering and Master (DEA) degrees in Computer Sciencefrom ENSEEIHT (INP Toulouse), in June and September 1988 respectively. He obtainedthe Ph.D. and HDR degrees in Computer Science from UPS, University Paul SabatierToulouse, in October 1992, and January 2005 respectively. He is since 1992, Chargé deRecherche, a full-time research position at the French National Center for ScientificResearch (CNRS). Khalil DRIRA’s research interests include formal design, imple-mentation, testing and provisioning of distributed communicating systems and

http://www.redcad.org

http://www.redcad.org/~MohamedJmaiel


cooperative networked services. His research activity addressed and addresses dif-ferent topics in this field focusing on model-based analysis and design of correctnessproperties including testability, robustness, adaptability and reconfiguration. He is orhas been involved in several national and international projects in the field of dis-tributed and concurrent communicating systems. He is author of more than 150regular and invited papers in international conferences and journals. He is or has beeninitiator of different national and international projects and collaborations in the fieldof networked services and distributed and communicating systems. Khalil DRIRA is orhas been member of the programme committees of international and national con-ferences. He is member of the editorial board of different international journals in thefield of software architecture and communicating and distributed systems. KhalilDRIRA has been editor of a number of proceedings, books and journal issues in thesefields. More details are available on his home page: http://www.laas.fr/~khalil/

Ahmed Hadj Kacem was born in Sfax (Tunisia) on the 1st of April 1967. He receivedthe Master degree (DEA) in Computer Science and the Ph.D. degree in ComputerScience from UPS, University Paul Sabatier Toulouse III, respectively in 1991 and1995. He joined the University of Sfax (Tunisia) as a professor in 2007 and head ofdepartment of Computer Science in 2008 at the Faculty of Economics and Manage-ment of Sfax. He participated to the initiation of many graduate courses. He is memberof the ReDCAD Research Unit (http://www.redcad.org). His current research areasinclude formal design of multi-agent systems and adaptive software architectures. Heis involved in several research projects in the field of distributed systems. He is authorof more than 60 regular papers in international journals and conferences.

http://www.laas.fr/~khalil/

http://www.redcad.org

p/s-com: building correct by design publish/subscribe architectural styles with safe reconfiguration

Documents