A Design and an Observational Approach for Group Behavior Design Patterns Lionel Seinturier, Laurence Duchien, Gerard Florin CNAM-Laboratoire CEDRIC 292, rue Saint Martin, FR-75141 Paris cedex 03 e-mail: fseintur, duchien,
[email protected] 14 January 1997 Abstract This paper deals with the formal de nition of design patterns for group behaviors. The existing studies on distributed object-oriented applications seem to follow two ways. First, people from the analysis and design domain start with some high level algorithmic properties and de ne some models of distributed behaviors. For instance the design patterns [GHJV95] community follows this approach. Second, people from the operating system and network domains start with some low level primitives and de ne some observations of distributed runs. The de nition of a causality relation [Lam78] for distributed applications belongs to this approach. We show how the design and the observational approaches complement one another and are related for four design patterns. These patterns provide solutions for some standard distributed problems and are de ned in the scope of a methodology and a semi-formal proof system for distributed objects applications that we proposed in [Bon94, BDFS96].
Keywords: distributed objects, formal de nition of group behaviors, design vs observation
viewpoints, design patterns, epistemic logic
1 Introduction Object orientation provides a powerful mechanism for the design of complex applications. Its concepts are well understood and many methodologies exist. Yet the design of distributed object applications or cooperative applications seems to remain an open issue. With the existing approaches such as the OMG/CORBA, developers can write client objects and server objects, and make them interoperate in a distributed heterogeneous environment. These are mainly simple client/server interactions. Contracts [HHG90, WBWW90, Hol92, JBJE95] and interaction protocol languages [AG94b, AG94a, Bok96] provide a way to specify all the legal sequences of messages that can be exchanged. Nevertheless these approaches separate the design of the interactions from the design of the objects behaviors. In [Bon94, BDFS96] we give a rst version of a methodology and of a semi-formal proof system for distributed applications with both inter and intra objects parallelism. The methodology suggests to follow some trends. First we keep the same environment de nition and the same formalism from the begin to the end of the speci cation. The methodology uses state/transition 1
models and a knowledge based approach for all the speci cation levels. Second, a speci cation must lead to a code and some associated proofs. So, we always keep in mind that the code must be derived from the speci cation and that the proofs are based on the speci cation. We adopt a global development process including speci cation, coding, and proofs of distributed objectoriented applications. Third, in our speci cation process, we de ne data and behavioral aspects. Our objective is to always keep one's balance between these two features. We base the speci cation process on three levels: the group level, the object level, and the method level. The group represents a set of distributed entities involved in a distributed computation. An object is a local entity. The methods are the actions that are performed. The design of an application consists in re ning a model through these three points of view. We study a distributed application with two approaches: rst we describe the application with a design formalism, and then we check that the speci ed states and actions can be observed in a run. By this way we are able to put into connection the design and the debug of distributed applications [BDFS97]. Furthermore the complexity of distributed algorithms requires some automatic mechanisms to help designers. Design patterns addresses such complexity by de ning some solutions for standard problems. For instance in distributed environments one can de ne patterns for network routing or for the collection of a global state. So we detail a speci cation approach, and then, we always take care to be able to have an observational de nition of the speci cation. Moreover we de ne some patterns that correspond to classical problems in distributed environments. Then, we give some trends to re ne these group patterns in their object and method speci cations. Section 2 gives a fast overview of the methodology. Section 3 discusses a taxonomy of group and presents the de nition of group states and group transitions with the two approaches. Section 4 compares these approaches in the de nition of four interaction patterns for group behaviors: the phase, the distributed recursion, the distributed condition, and the distributed iteration. Section 5 shows how these models can be re ned at the object and method levels. Section 6 gives some conclusions and trends for future works.
2 Overview of the Methodology We suggest to design a distributed application with three points of view: the group level, the object level and the method level. In this section we give an overview of the three levels, and in Section 3 we develop the group level. The group level describes the behavior of the set of objects that run the application. A group is a set of heterogeneous, concurrent, and autonomous objects distributed across a network. They interact by remote method calls. We don't assume that one entity plays the role of a central scheduler for the members set. This means that even if we design some global behavior, no central schedule will ever be implemented. This leads to complex patterns of interaction and behavior between groups of distributed objects. In [Bon94, BDFS96] we choose the knowledge based approach of Fagin and al. [FHMV95] to design these interactions and these behaviors. We use a state/transition approach with a particular semantics. Each state is de ned with an epistemic formula that describes the level of knowledge of the group. Each transition is a transformation on the knowledge base of the group and models inter-objects parallelism (i.e. concurrent actions performed by the members of the group). This is the global evolution of the set of objects between two knowledge predicates. So the group speci cation models the behavior and the states of the 2
group. It allows to focus our attention on global interactions and to cut o from the synchronization and distribution problems that we meet when we specify each object directly in details. The object level describes the behavior of a member object of the group. It gives the synchronization policy for the object methods. This level is similar to the meta-level of re ective languages and meta-object protocols (e.g. Open C++ [Chi95], Act++ [KL89], CLOS [BDB+ 88], or ABCL/R [WY88, Yon90]). The object level behavior is de ned with a state/transition automaton. As we need to consider intra-object parallelism its semantics, that is presented in [SDF96], di ers from the usual semantics of nite state automata theory. Finally the method level describes the algorithmic structures used in each method. This is the base-level of re ective languages. A method state is a mapping from the set of instance and local variables to a set of values. A transition between two method states de nes some basic variables transformations with algorithmic structures such as loops, tests, arithmetic operations, reads and writes of variables.
3 Group Speci cation The group level of our methodology introduces the notion of groups of cooperating objects for the design of distributed applications. In this section we give more details about the notion of group, group states, and group actions.
3.1 Group De nition
In the speci cation process of a distributed algorithm we can assign a role to a group that is a unit of representation. For instance in election problems, the role of the group is to choose one coordinator. In our approach the global behavior of a distributed application results from the local actions of a group of objects and the cooperation (i.e. the interactions) among these objects. So each group in the distributed environment has a unique name and a type (i.e. the role described in a set of services or method interfaces). Next several properties can be assigned to the group. First we nd a property that determines a taxonomy of the group. Then, we de ne a behavioral property.
3.1.1 Membership taxonomy of a group We de ne a taxonomy of group based on membership. Martin in [Mar93] proposes the following classi cation: a group can be de ned or unde ned, static or dynamic. A group is said to be de ned if its members can be enumerated. This does not necessarily mean that a single entity knows all the members but that the list of members is distributed among some clearly identi ed group managers. A group is said to be unde ned if a standard enumeration of its membership can not be de ned (for instance the membership of a NNTP newsgroup). Members of such a group can be reached by broadcasting a request over a physical medium or by traversing a network of connected sites (or objects). A group is static if its members is de ned at the instantiation of the group and never changes during its lifetime. On the other hand, in a dynamic group, objects can be added and/or deleted after the instantiation of the group.
3
3.1.2 Behavioral properties We de ne behavioral properties of groups. The group behavior is in uenced by the quality of service proposed by the environment. We must consider two kinds of approaches. First, the distributed environment can provide services for group membership management and can guarantee properties concerning the delivery of messages. The two main delivery properties are the causal order and the total order. A group is said to be causally ordered if all the messages are delivered in the order they are sent. A group is said to be totally ordered if all the messages are delivered to all the members of the group in the same order. This kind of service corresponds already to a group speci cation that can be reused for a new group speci cation. Second, we can consider that each distributed algorithm is a problem of group management in which each property must be rede ned. According to the situation the solution to a distributed problem is di erent.
3.2 Group State Among other things distributed behaviors can be characterized in terms of states and state changes. So next paragraph takes the point of view of a design process and shows how a group state can be speci ed using concepts from epistemic logic. Paragraph 3.1.2 takes the point of view of the observation of a distributed run and gives the de nition of a group state based on the notion of consistent cuts.
3.2.1 Group states with a design point of view We propose to adopt a knowledge based approach with an epistemic logic formalism to design group states. Epistemic logic [MvdH95][FHMV95] is an instance of modal logic [vW51][Kri63]. Modal logic extends propositional logic with notions of necessity and possibility. It uses the usual operators of propositional logic : ^ _ ! $ and the symbols (called modalities) for the above mentioned notions. Thus a modal logic formula can be true or false but also can be necessary or possible. Epistemic logic interprets these two modalities with the notions of knowledge and possibility. Reasoning in terms of knowledge rather than on variables values provides a high level formalism that abstracts the details of the implementation. At the group level of our methodology a distributed application is speci ed with a state/transition automaton. Each state is associated with an epistemic formula that gives the level of distributed knowledge owned by the group of agents (epistemic logic uses the term agent for site) when the application is computed till this point. In a centralized environment all the data that are managed by an application are under the control of an unique processor. The situation is much more di erent in a distributed environment where each site only controls a small piece of information. Information is distributed among many sites and a single site may not own sucient facts to perform its computation. Most of the time it gains some facts through some interactions with its peers. So the management and the exchange of information is one of the principal tasks of a distributed application. Epistemic logic tries to address some of these issues by de ning the notion of knowledge. Knowledge can be understood as a predicate (for instance a Prolog predicate or a Boolean valued expression) with a modality or an operator describing its distribution among a set of agents. Epistemic logic uses the symbol K (knowledge) for the modality . The modality for possibility denoted by the symbol M is seldom used in epistemic logic. Then the operators E (everybody knows), and C (common knowledge) 4
are de ned. Other operators such as I (implicit or distributed knowledge), B (belief), D (common belief) can also be de ned but are not discussed in this paper.
Semantics Propositional epistemic logic is de ned with a set P of propositional constants and a set A of m agents. Its semantics uses the notion of possible worlds and Kripke models [Kri63]. A presentation of the details of the semantics is out of the scope of this paper (for instance see [MvdH95] for such a work). A Kripke model M is a tuple hS; ; R1; : : :; Rmi where S is a non empty set of states, : S ! (P ! ftrue; falseg) is a truth assignment to the propositions per state, and Ri S S are the accessibility relations for each agent. In the case of a distributed application S is the set of all the consistent cuts. Then the accessibility relation de nes for each state, the set of states that an agent considers as possible or visible. This relation translates the fact that in a distributed environment an agent has only a partial view of the state of its peers. Thus each agent needs to consider several possible global states. The epistemic formula Ki ' is true in a state s (we say that agent i knows the fact ' in state s) if and only if ' is true in all the states that are visible from s for i. Then we say that everybody in A knows the fact ' and we write E' if and only if all the agents in A know the fact ' (i.e. E' = K1' ^ : : : ^ Km '). Finally we say that the fact ' is a common knowledge of the group A (i.e. C' = E' ^ E 2 ' ^ : : : ^ E k ' ^ : : :) if and only if all the agents know the fact ' and all the agents know that all the agents know the fact ' : : : For instance the formula 8s 2 V isited; Ks (parent(s)) in the design of the distributed recursion pattern presented in sub-section 4.2 translates the fact that all the agents s in the set Visited know their parent.
3.2.2 Group states with an observational point of view The state of a group of distributed entities (processes or objects for instance) can be de ned as the composition of the local states of all the group members. Each member manages data and its local state can then be de ned as a mapping from a set of variables to a set of values. Among the set of all possible group states, only some of them are meaningful: these states are called observable. Their de nition is based on an order relation between local states that can be deduced from the message exchanges. In the next paragraphs we de ne such a relation and the associated observable global states.
Causality relation The most thoroughly studied order relation in the eld of distributed computer science is the Lamport's Happened before relation [Lam78]. He de nes a distributed algorithm as a set of n processes P1; : : :; Pn with an asynchronous message mode. Lamport distinguishes three kinds of events: internal events, send events, and receive events. eij denotes the j-th event of process i and E is the set of all the events.
De nition 1 The Happened before relation ! E E is the smallest transitive relation satisfying:
1. if eij and eik are internal events of process Pi and j < k then eij ! eik 2. if s is a send event and r is the corresponding receive event then s ! r
5
This de nition states that an internal event happens before any future internal event on the same process and that a send event happens before its corresponding receive event. This relation is said to be a causality relation because it captures the idea that the e ect of a send event is a receive event (by the same way the cause of the receipt is the send). Some events can be computed concurrently and are not comparable with this relation (these events are said to be independent). So the causality relation is a partial order. Fidge [Fid88] and Mattern [Mat88, SM92] de ne a representation of the causality relation with vector clocks. In this approach each event eij is associated with a n-dimensional vector (n being the number of processes of the distributed computation). The overall idea is that eij depends causally from the last local event of process Pi and from the n-1 last send events of processes other than Pi. Figure 1 gives the example of a distributed computation with three processes P1 , P2 et P3. Each initial event of process Pi is associated with a vector such as the i-th component is 1 and all the others are 0. Next if eij is an internal event or a send event, the i-th component of its vector is i and the others equals the corresponding components of ei;j ?1 vector (for instance component 2 of e23 in Figure 1 equals 3 and components 1 and 3 are those of e22 ). If eij is the receive event associated with the send event elm , the i-th component of its vector is i and the other components ekij equals max(eklm ; eki;j ?1) (for instance component 3 of e33 in Figure 1 equals 3, component 1 equals max(3; 2) = 3 and component 2 equals max(0; 3) = 3). P1
e11
e12
e13
0 1 0
P2
P3
3 0 0
2 0 0
1 0 0
e21
2 2 0 e22
2 3 0 e23
0 0 1
2 3 2 e31
e32
3 3 4
2 3 3 e33
e34
Figure 1: Time diagram with vector clocks of the causality relation
Observable global state The Happened before relation gives an order for the events of a distributed run. An observation of this execution is a sequence of global states and a global state is a composition of local states. Many global states can be captured for a single distributed run but only some of them are consistent with the Happened before relation: they are called consistent global states or consistent cuts [CL85].
De nition 2 A nite subset C E is a consistent cut of a distributed run i if e 2 C then fe0 2 E je0 ! eg C This de nition states that if an event e belongs to a consistent cut then all events e' that are causally dependant from e belong to the cut. In other words the causal past of each event of a consistent cut is also in the cut. For instance cut C2 in Figure 2 is consistent but cut C1 is not consistent because event e22 belongs to the cut and event e12 does not (e12 ! e22). A consistent cut separates a time diagram into past and future. 6
P1
e11
e12
P2
e21
P3
e13
e22
e23
e31
e32
e34
e33
C1
C2
Figure 2: Non consistent and consistent cuts Next the set of all possible consistent cuts can be de ned for a distributed run. This is the global state lattice. Figure 3 gives the global state lattice associated with the distributed run of Figure 2. Each axis is associated with a process. Points are consistent cuts. For instance point (2; 3; 1) corresponds to the cut containing the events e12, e23 and e31 . A segment in the lattice models a state change in one of the three processes and a path from the initial state to the nal state without return into the past corresponds to a particular observation of the distributed run. Several observations of the same distributed run can be computed and the lattice gives all the possible observations. 334
334
233
333
333
232
332
332
231
331
331
P3 P2 P1
221
221 330
011
111
111
211 320
321
211
101
001 310 000
100
200
000
300
100
Figure 3: The global state lattice and an observation of the distributed run The global state lattice gives all the consistent cuts that can be observed in a distributed run. We use these notions to relate the design point of view to the observational point of view. For instance in Section 4 we de ne four group behavioral patterns with state/transition automata. Each state is speci ed with an epistemic formula and we show how this speci cation is observed in a global state lattice.
3.3 Group Actions
In a group level speci cation a group action is a transition between two group states. So this is a transformation of a knowledge predicate to another knowledge predicate. For the purpose of 7
this paper we only use some basic transformations: the assignment, some basic set operations, the guarded command, and the null action skip. A guarded command is composed of a Boolean valued condition and some actions. We also consider two types of transitions: whether the transition increases the level of knowledge of the group, or the transition revokes some knowledge. For example, the actions that increase the knowledge are the computation of a distributed problem. The actions that revoke some knowledge are related to a fault or to a change of strategy due to an external intervention. Both are transformations of the knowledge base of the application. The group action is implemented by a set of local actions processed on a set of distributed objects. At the group level, the group abstraction hides some characteristics of the distributed problem such as the distribution or the synchronization aspects. In the next section to help the speci cation of distributed applications we give some group design patterns that de ne some usual behaviors.
4 Group Design Patterns In this paper we propose four behavioral design patterns for distributed applications. Based on the work of Alexander [AIS+ 77], Gamma and al. in [GHJV95] de ne a pattern as \a recurring solution to a standard problem". A pattern can be creational, structural, or behavioral. A pattern is said to be behavioral if it \characterizes the ways in which classes or objects interact and distribute responsability". A pattern addresses a design problem that appears frequently and proposes a standard solution. This is an abstract behavior that is reused and applied to the particular context of an application. Our four patterns describe behaviors at the group level of our methodology and are: the phase, the distributed recursion, the distributed condition, and the distributed iteration. These patterns can be seen as building blocks for distributed applications in the same way as sequences, tests, and loops are basic algorithmic structures for sequential applications. They can be adapted, reused and combined in the design of distributed applications. They correspond to abstract behaviors that need to be implemented with object and method level models.
4.1 The Phase
The phase pattern is the distributed generalization of the sequence statement in a sequential environment. The phase pattern provides a solution to a distributed problem. It models the actions performed by all the objects in the group. The phase pattern proposes an organization of the objects and the classes in the group and de nes the solution to the problem. The phase is the most general pattern of our methodology. The three other patterns can be seen as re nements of the phase. It begins in an initial state with an initial level of knowledge. It ends in a nal state with a nal level of knowledge. The phase is the transition between these two states. When the phase is performed both correspond to consistent cuts in the global state lattice and all the observations of the distributed run (i.e. all the paths in the lattice) contain these two states. For instance the left side of Figure 4 gives the design of a phase. With our formalism two states S2 and S3 are de ned and are associated with an epistemic formula. The transition is then a transformation on the knowledge base of the distributed application. Both S2 and S3 are consistent cuts in the global state lattice shown on the right side of Figure 4 (this lattice gives the observations of the run of 8
the phase in a group of three objects). Then all the consistent cuts between states S2 and S3 in the global state lattice belong to this particular phase. The top level speci cation of a application that terminates is then a single phase between an initial state and a nal state. These particular states (S1 and S4 in Figure 4) are always found in a distributed run (S1 and S4 are omitted in the model but are presented in the global state lattice). S4 S3
S2
PredicateBefore : initial level of knowledge P3 Distributed behaviour on a group
P2 P1
S3
S2
PredicateAfter : final level of knowledge
S1
Figure 4: Design and observational point of views for the phase
4.2 The Distributed Recursion The distributed recursion pattern is the generalization of a backtracking scheme in a sequential environment. This pattern is used each time a group of distributed objects needs to be traversed to broadcast information or to build a distributed data structure (e.g. a tree, a ring). During a distributed recursion (the term wave is often used for this pattern in network algorithms [Tel94, Gom95]), all the objects of the group are visited exactly once, and a local action is performed on each of them. This pattern assumes the use of remote method calls between the group members. Two steps can be distinguished: the descent step (that corresponds to the calls of the remote methods) and the owing back step (i.e. the returns of the remote methods). In this paper we only give the descent step. The full version can be found in [BDFS96] along with some correctness properties proofs. This pattern may be de ned as follows. The group (denoted by the set Sites) is a network with a topology. A member of the group only knows its immediate neighbors. Among the members of the group, one or several objects called initiators start the pattern and compute some local actions. Then all the members of the group are traversed and each of them executes exactly once some local actions associated with the pattern. In the remainder we present brie y the behavior with only one initiator. Figure 5 gives the group model of this pattern. Three global actions are de ned:
this distributed behavior starts with the transition labeled Initialization. The global action builds the set Visited of sites visited during the recursion (till this point only the initiator is visited so V isited := fI g). The sites that are at distance one from the elements of Visited 9
S1 = true S2 = 8s 2 V isited; Ks (parent(s)) S3 = 8s 2 Sites; Ks (parent(s))
S1 Initialization
Initialization : true ! V isited := fI g Boundary := fsjs 62 V isited ^ 9i 2 V isited; d(i; s) = 1g Growth : V isited 6= Sites ! Let b Boundary V isited := V isited [ b Boundary := fsjs 62 V isited ^ 9i 2 V isited; d(i; s) = 1g Flowing back : V isited = Sites ! skip
S2
Growth Flowing back
S3
Figure 5: Group model of the distributed recursion but are not themselves visited are said to be on the boundary. The initiator uses a remote method call to spread the wave to all the sites of the boundary. The predicate of state S1 translates in terms of knowledge the properties of the distributed environment (for instance the uniqueness of object identi ers) that are needed for the run of this pattern. Due to lack of space we do not give these elements here and we associate the predicate true to state S1 .
once a site s of the boundary receives the wave he records the sender identity as its parent.
s is added to Visited and a new boundary is computed. s computes some local actions and spreads the wave to the sites of its boundary. We de ne a transition labeled Growth around
the intermediate state S2 to model each step of the traversal. Each object performs the local actions only once (i.e. if an object can be reached by several paths, it runs the local actions only during the rst visit and returns the next ones). The global action Growth is a guarded command that is performed while all the sites are not visited i.e. while V isited 6= Sites. At the intermediate state each visited object knows exactly one parent in the recursion. So the predicate of state S2 is 8s 2 V isited; Ks (parent(s)).
once all the members are visited, the wave ows back to the initiator and the recursion ends.
This is the nal transition labeled Flowing back. This global action is a guarded command and speci es that the condition V isited = Sites must hold to re this transition. We do not give the details of this step so we associate this guarded command with the null action skip. All the objects in the group know exactly one parent in the recursion. So the predicate of state S3 is 8s 2 Sites; Ks (parent(s)).
Figure 6 gives a group of three objects linked with a simple network topology that performs a recursion. Figures 7 and 8 give two possible runs with the corresponding global state lattices (message m4 is omitted). Due to the undeterminism of the transmission delays in an asynchronous network, several runs can occur: we may have m1 ; m2 ; m3, m2 ; m1 ; m3, m1 ; m3 ; m2, or m2 ; m3; m1 . Table 1 shows the di erent steps of the rst two runs, and Figures 7 and 8 give the global state lattices generated. In both cases the initial and the nal states of the recursion are clearly identi ed: state S1 corresponds to consistent cut 000, and state S3 corresponds to consistent cut 222. Four instances of the intermediate state S2 exist. They do not correspond to the same 10
Initiator m1
1
2 m3 m2 m4
3
Figure 6: A simple example of a distributed recursion
P1
m1
P2
S3
2 0 0
1 0 0
222
221
1 1 0
1 2 0
m2 2 0 1
P3
P2
220
120
P3
211
2 2 2
m3
2
S2
P1
110 201
S1
2
S2
000
100
200
Figure 7: Runs of the distributed recursion of Figure 6 with the sequence m1 ; m2; m3
P1
1 0 1
222 221
2 1 0
P2 P3
S3
2 0 0
1 0 0
2 2 0
P2 220 211
2 2 2
P1
210
2
S2
101
201
S1
2
S2
000
100
200
Figure 8: Runs of the distributed recursion of Figure 6 with the sequence m2 ; m1; m3
11
P3
consistent cuts in the two runs. In the run m1 ; m2; m3 of Figure 7, S22 corresponds to consistent cut 110. In the run m2 ; m1 ; m3 of Figure 8, S22 corresponds to consistent cut 101. States S1 S21 S22 S23 S24 S3
Run m1 ; m2; m3 Run m2 ; m1 ; m3 Visited
f1g f1; 2g f1; 2; 3g f1; 2; 3g f1; 2; 3g
Visited
f1g f1; 3g f1; 2; 3g f1; 2; 3g f1; 2; 3g
Table 1: Visited set values and states instances for two runs of the distributed recursion This example brings two remarks about the distributed recursion pattern. First, it shows that the status of states S1 and S3 in the model of Figure 5 is slightly di erent from the status of state S2 . Indeed the recursion is a re nement of a phase. The initial and the nal states of the phase are mapped respectively onto the initial and the nal states of the recursion. So all the observations of the distributed recursion contain S1 and S3 . On the other hand an instance of the intermediate state S2 is not necessarily associated with the same consistent cut in two di erent runs of the recursion. Second, unlike for the phase or the distributed iteration presented in sub-section 4.4, no particular shape of a global state lattice can be associated with the behavioral model. Indeed in an asynchronous network with no mechanism to guarantee an order of messages deliveries, two runs of a distributed recursion with the same initial conditions may generate di erent global states lattices.
4.3 The Distributed Condition The distributed condition pattern is the generalization of the if statement in a centralized environment. The distributed condition pattern modi es the local behaviors of the objects of a group according to some conditions on the global state of the group. Two steps can be distinguished: rst, a global condition is evaluated and next, the result is broadcast to all the objects. Figure 9 gives the group model of this pattern. A state/transition diagram with the epistemic predicates and the global actions, and a pseudo-algorithmic code are provided. The two steps may be described as follows:
in the rst step (Global state collection phase) a particular object called the observer starts
the pattern. It computes a global state by querying the other objects in the group for their local states. This can be performed with some point to point exchanges or with a traversal such as the distributed recursion pattern presented in sub-section 4.2. The global condition evaluated by the coordinator is a function from the local objects states. We denote the local state of an object by lci and the action associated to this step by true ! coord:cond := f(lc1 ; : : :; lcm ). The predicate of state S1 is true1 . In state S2
As for the distributed recursion this predicate should translate in terms of knowledge the properties of the distributed environment such as the uniqueness of objects identi ers or the connexity of the group. 1
12
S1
S1 = true S2 = Kcoordinator (coord:cond) S3 = Eall (coord:cond) S4 = Eall (coord:cond)
Global state collection phase
S2
Global state collection phase : true ! coord:cond := f(lc1 ; : : :; lcm ) Then phase : coord:cond = true ! skip Else phase : coord:cond = false ! skip
Then phase
S3
Else phase
S4
/* Global state collection phase */ IF coord.cond THEN /* Then phase */ ELSE /* End phase */ END
Figure 9: Group model of the distributed condition pattern the coordinator knows the value of the condition so its predicate is the epistemic formula Kcoordinator (coord:cond).
in the second step the observer broadcasts the truth value of the condition to the other
objects in the group. If the condition holds the Then phase is performed, else the Else phase is performed. In both cases the objects perform the local behavior associated to the phase. At the end all the objects know the value of the condition evaluated by the coordinator. So the predicate of states S3 and S4 is Eall (coord:cond).
4.4 The Distributed Iteration
The distributed iteration pattern is the generalization of the loop statement in a sequential environment. This pattern is used each time a global behavior needs to be iterated until a condition holds. For instance the concept of stabilization [Dij74][Tel94] in distributed algorithms achieves some fault-tolerant behaviors with an optimistic approach. When some transient failure occurs, a global compensation behavior is performed until the group returns to a correct state. Rather than suspecting all the information received as in the pessimistic approach of distributed algorithms with failure detectors, self-stabilizing algorithms assume that all the objects behave correctly but that if some of them are corrupted then eventually they return to a correct operating mode within some nite time. These algorithms are used for instance to maintain a distributed data structure (e.g. a tree, a ring), or to guarantee an uniform access to a shared resource (e.g. a mutual exclusion access). The compensation policy is called the unstable step because the transient failures introduce some faulty behaviors. The compensation guarantees a return to the correct operating mode within some nite time. So the correct operating mode is called the stable step. This pattern may be de ned as follows. Two steps can be de ned: rst a global behavior is 13
S1 = loop invariant S2 = Eall (cond)
Iterated phase
S1 End phase
Iterated phase : cond = false ! skip End phase : cond = true ! skip S2
cond = false DO /* Iterated phase */
WHILE END
/* End phase */ Figure 10: Group model of the distributed iteration pattern performed while the global condition does not hold. This is the Iterated phase around state S1 in the model of Figure 10. Next, once the condition holds the iteration stops. This is the End phase from state S1 to state S2 . The predicate of state S1 translates the invariant property of the loop. In state S2 all the objects in the group know the value of the condition. So its predicate is Eall (cond). Figure 11 gives the global state lattice associated to this pattern. The Iterated phase generates a shape that is repeated a nite number of times until state S2 is reached. All the observations of this distributed run contain all the instances of state S1 . S2
....
P3 P2 P1
S1
Figure 11: Observational point of view for the distributed iteration
5 Re nement We call re nement the process that consists in deriving a child model from a parent model. By this way the re ned model introduces more details in the parent model and can be seen as an 14
implementation of the parent model. The basic assumption about the re nement process is that it must reduce the space of solutions of the problem and that the re ned model must not refute the parent model (i.e. the set of correct implementations of the re ned model must be a subset of the set of correct implementations of the parent model). Two categories of re nement need to be considered: a group model can be re ned into another group model to introduce more details in the speci cation or a group model can be re ned into an object model to provide an implementation for the distributed behavior. Most of the time the group to object re nement leads to some complex interaction policies and object behavior synchronizations. We felt the need to provide developers with some tools to implement the distributed patterns at the object level. So in [SDF96] we propose a meta-object protocol to carry out the implementation of these synchronization policies on top of a concurrent object language (we currently use the language of the distributed OO system GUIDE [BBD+ 91]). In the remainder of this section we give some details about the group to group and group to object re nements for the four distributed patterns.
The Phase The phase is the most general pattern for distributed behavior. The three other patterns are re nements of this one. The initial and nal states of the phase are mapped on the initial and nal states of the other patterns. The phase de nes a global action that is performed by all the members of the group. Each object in the group performs a local behavior that is a re nement of the phase. With our methodology we suggest to carry out this re nement with two steps: rst, as we assume the use of some concurrent objects, we specify a synchronization policy (i.e. an object level model), and second, we specify the algorithmic structures of the methods (i.e. an method level model). From a static point of view two sites a and b of the group can own two di erent local versions of a same global phase (for instance the local actions of a client and a server can be occurrences of the same global action). From a dynamic point of view all the local actions do not necessarily start and end at the same global time. But each local action of phase Pi is performed after the local actions of phase Pi?1 and before the local actions of phase Pi+1.
The Distributed Recursion The distributed recursion pattern is the generalization of a backtracking scheme. Several re nements can be introduced in the group model of this pattern. In this paragraph we present two group to group re nements. First, the owing back of the wave can be added to the model of Figure 5. This step corresponds to the returns of the remote method calls used to propagate the recursion from an object to the next ones. The transition labeled Flowing back is re ned by three transitions and a state. It can be described as follows: it starts with an initialization transition that is triggered once all the objects are visited; next, a transition around an intermediate state modelises each return of the remote method call from an object to its parent; nally, the last transition is triggered when the
owing back step reaches the initiator. These three actions re ne the skip action associated with the Flowing back transition of the parent model. The second re nement that can be introduced in the parent model deals with behaviors where several initiators start the recursion concurrently. Several waves are propagated in the network and we need to decide which behavior is performed when two waves reach concurrently an object. For instance in [BDFS96] we specify a distributed spanning tree construction algorithm using the recursion pattern with several initiators. In this 15
application the wave initiated by the object with the lowest identi er is canceled and thus only the wave initiated by the object with the highest identi er traverses all the network.
The Distributed Condition The goal of the distributed condition pattern is to modify the behavior of all the objects in a group. This pattern is associated with a Boolean valued expression. At the object level we de ne two re nements of this distributed condition: a static version and a dynamic version. The static version of the distributed condition pattern models a decision based on structural conditions. For instance consider a global action designed to service data in a group of objects. At the object level with a client/server communication scheme, this policy is re ned in two di erent behaviors: one for the server and one for the client. Two solutions can be proposed. One may de ne two classes and an object in the group plays the role of a server or a client. The second solution consists in de ning only one class with both behaviors. Then depending on some local conditions, the object chooses to play alternatively or concurrently the roles of a server or of a client. The dynamic version of the distributed condition pattern models a decision based on the local states of the group members. This kind of mechanism is used: to reach a consensus in a group (for instance to perform a transaction), to trigger a compensation behavior when a failure, to balance the load of the objects, : : : In all these situations one of the objects in the group needs to play the role of the coordinator. Two steps can be de ned in the coordinator behavior. First he needs to collect the local states of all (or some) of the objects in the group. This can be done on an active way (e.g. the coordinator queries the objects with some point to point mechanisms or traverses the group) or on a passive way (e.g. the coordinator receives the information from a failure detector). He evaluates a condition based on these local states. Second the coordinator noti es the other objects to change their local behaviors according to this condition.
The Distributed Iteration The goal of the distributed iteration pattern is to iterate a global behavior. This pattern is associated with a Boolean valued expression to stop the iteration. The self-stabilizing behavior described in section 4.4 is a special instance of this pattern. We give a group to object re nement for this behavior. The basic assumption about self-stabilization is that each object determines its behavior from its local state and the local states of its neighbors. So each object collects the local states of its neighbors, performs a local algorithm, modi es its local state, and repeats this process. All the objects repetitively perform this behavior. The basic idea is that, even if the objects do not perform this loop synchronously (i.e. if some objects run much more faster then others), then the algorithm must guarantee that after a nite number of iterations the global state of the group reaches a stable state. A global state collection mechanism needs to be added. This role is assigned to a dedicated object that queries or traverses the objects to collect their local states and then, noti es them when the group state stops changing.
6 Conclusion In [Bon94, BDFS96] we propose a methodology and a semi-formal proof system for distributed objects applications. We suggest to adopt three points view in the design of such an application: 16
the point of view the group of objects that runs the distributed behavior, the point of view of an object, and the point of view of each method within an object. In this paper we study with more details the group level. So Section 3 de nes a distributed application as a set of cooperating objects with some membership attributes and some behavioral properties of message deliveries. These characteristics may be provided by the environment or may be considered as behaviors that need to be speci ed by developers. Next the design of a distributed behavior requires the de nition of some group states and some group actions. We adopt two approaches for the study of group states: a design approach and an observational approach. By this way we are able to put into connection the design and the debug of distributed applications. We propose a formalism based on epistemic logic for the design approach, and we base the observational approach on the notion of consistent cuts in a distributed run. These two approaches are put into practise in Section 4 for the de nition of four group behavioral design patterns: the phase, the distributed recursion, the distributed condition, and the distributed iteration. We describe some solutions for these standard behaviors and we show how the two approaches can be compared for each of them. These patterns are abstract behaviors that can be reused, assembled, and inherited. They can be seen as the distributed counterparts of the usual sequence statement, recursion scheme, if and loop statements of centralized algorithms. Finally, Section 5 provides some sketches of re nement for the implementation of these patterns at the object level. This study tries to establish a connection between two existing approaches of distributed computer science. As our previous works dealt essentially with the design approach through a methodology, the study of the observational approach can certainly be enhanced. For instance we need to investigate more closely how the re nement features of our methodology are translated in the observational approach. We also plan to carry on with the comparison between the two approaches by de ning other group behavioral patterns.
17
References [AG94a]
R. Allen and D. Garlan. Formal connectors. Technical Report CMU-CS-94-115, Carnegie Mellon University, 1994.
[AG94b]
R. Allen and D. Garlan. Formalizing architectural connection. In Proceedings of ICSE'94, 1994.
[AIS+ 77]
C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A Pattern Language. Oxford University Press, 1977.
[BBD+ 91] R. Balter, J. Bernadat, D. Decouchant, A. Duda, A. Freyssinet, S. Krakowiak, P. Le Dot, M. Meysembourg, H. Nguyen, E. Paire, M. Riveill, C. Roisin, X. Rousset de Pina, R. Scioville, and G. Vandome. Architecture and implementation of Guide, an object-oriented distributed system. Computing Systems, 4(1):31{67, 1991. [BDB+ 88] D.G. Bobrow, L.G. DeMichiel, R.P. Babriel, S. Keene, G. Kiczales, and D.A. Moon. Common lisp object system speci cation. ACM SIGPLAN Notices, 23, September 1988. [BDFS96]
L. Bonnet, L. Duchien, G. Florin, and L. Seinturier. Some speci cation steps of a spanning tree algorithm with an object-oriented approach. In Proceedings of the 1st IFIP Workshop on Formal Methods for Open Object-Based Distributed Systems (FMOODS'96), Paris, France, March 1996.
[BDFS97]
F. Bergdolt, L. Duchien, G. Florin, and L. Seinturier. From the speci cation to the debug: a distributed application trace construction and its use in a distributed oo environment. In Proceedings of the 2nd European Research Seminar on Advances in Distributed Systems (ERSADS'97), Zinal, Switzerland, March 1997.
[Bok96]
B. Bokowski. Interaction protocol for composing concurrent objects. In Workshop for
[Bon94]
L. Bonnet. Speci cation et preuves d'algorithmes distribues en approche orientee objet. Master's thesis, CNAM-Cedric, December 1994.
[Chi95]
S. Chiba. A metaobject protocol for c++. In Proceedings of the 10th Annual Confer-
Doctoral Students at the 10th European Conference on Object-Oriented Programming (ECOOP'96), Linz, Austria, July 1996.
ence on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'95), volume 30 of ACM SIGPLAN Notices, pages 285{299. ACM Press, October
1995.
[CL85]
K.M. Chandy and L. Lamport. Distributed snapshots: Determining global states of distributed systems. ACM Transactions on Computer Systems, 3(1):63{75, February 1985.
[Dij74]
E.W. Dijkstra. Self-stabilizing systems in spite of distributed control. Communications of the ACM, 17:643{644, 1974.
[FHMV95] R. Fagin, J.Y. Halpern, Y. Moses, and M.Y. Vardi. Reasoning about Knowledge. MIT Press, 1995. 18
[Fid88]
C.J. Fidge. Timestamps in message-passing systems that preserve the partial ordering. In Proceedings of the 11th Australian Computing Conference, February 1988.
[GHJV95]
E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[Gom95]
R. Gomez. Conception et Speci cation d'algorithmes Distribues : la Vague Recursive. These de doctorat, Universite Paris VIII, April 1995.
[HHG90]
R. Helm, I.M. Holland, and D. Gangopadhyay. Contracts - specifying behavioural compositions in object-oriented systems. In Proceedings of the Con-
ference on Object-Oriented Programming: Systems, Languages and Applications (ECOOP/OOPSLA'90), volume 25 of SIGPLAN Notices, pages 169{180. ACM
Press, October 1990.
[Hol92]
I.M. Holland. Specifying reusable components using contracts. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP'92), LNCS 615, pages 287{308, Utrecht, The Netherlands, June 1992. Springer-Verlag.
[JBJE95]
I. Jacobson, S. Bylund, P. Jonsson, and S. Ehneboom. Using contracts and use cases to build pluggable architectures. Journal of Object-Oriented Programming, May 1995.
[KL89]
D.G. Kafura and K.H. Lee. Inheritance in actor based concurrent object-oriented languages. The Computer Journal, 32(4):297{304, 1989.
[Kri63]
S. Kripke. Semantic analysis of modal logic. Zeitschrift fur Mathematische Logik und Grundlagen der Mathematik, 9:67{96, 1963.
[Lam78]
L. Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558{565, July 1978.
[Mar93]
J.P. Martin. Syntaxe et semantique des services de communication de groupe. Master's thesis, CNAM-Cedric, June 1993.
[Mat88]
F. Mattern. Virtual time and global states in distributed systems. In Proceedings of the International Conference on Parallel and Distributed Algorithms, pages 215{226, 1988.
[MvdH95]
J.J. Meyer and W. van der Hoek. Epistemic Logic for AI and Computer Science. Cambridge University Press, 1995.
[SDF96]
L. Seinturier, L. Duchien, and G. Florin. Design and implementation of distributed oo applications with a meta-object protocol. Technical Report 9622, CNAM-Cedric, October 1996.
[SM92]
R. Schwarz and F. Mattern. Detecting causal relationships in distributed computations: In search of the holy grail. Technical Report SFB 124 - 15/92, University of Kaiserslautern, December 1992.
[Tel94]
G. Tel. Introduction to Distributed Algorithms. Cambridge University Press, 1994. 19
[vW51]
G.H. von Wright. An Essay in Modal Logic. North-Holland Publishing Company, 1951.
[WBWW90] R. Wirfs-Brock, B. Wilkerson, and L. Wiener. Designing Object-Oriented Software. Prentice Hall, 1990. [WY88]
T. Watanabe and A. Yonezawa. Re ection in an object-oriented concurrent language. In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA'88), volume 23 of SIGPLAN Notices. ACM Press, September 1988.
[Yon90]
A. Yonezawa. ABCL: An Object-Oriented Concurrent System. Computer Systems Series. MIT Press, 1990.
20
Contents 1 Introduction
1
2 Overview of the Methodology
2
3 Group Speci cation
3
3.1 Group De nition . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Membership taxonomy of a group . . . . . . . . 3.1.2 Behavioral properties . . . . . . . . . . . . . . . 3.2 Group State . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Group states with a design point of view . . . . . 3.2.2 Group states with an observational point of view 3.3 Group Actions . . . . . . . . . . . . . . . . . . . . . . .
4 Group Design Patterns 4.1 4.2 4.3 4.4
The Phase . . . . . . . . . . The Distributed Recursion . The Distributed Condition . The Distributed Iteration .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . .
3 3 4 4 4 5 8
8
. 8 . 9 . 12 . 13
5 Re nement
15
6 Conclusion
17
21
List of Figures 1 2 3 4 5 6 7 8 9 10 11
Time diagram with vector clocks of the causality relation . . . . . . . . . . Non consistent and consistent cuts . . . . . . . . . . . . . . . . . . . . . . . The global state lattice and an observation of the distributed run . . . . . . Design and observational point of views for the phase . . . . . . . . . . . . Group model of the distributed recursion . . . . . . . . . . . . . . . . . . . A simple example of a distributed recursion . . . . . . . . . . . . . . . . . . Runs of the distributed recursion of Figure 6 with the sequence m1 ; m2; m3 Runs of the distributed recursion of Figure 6 with the sequence m2 ; m1; m3 Group model of the distributed condition pattern . . . . . . . . . . . . . . . Group model of the distributed iteration pattern . . . . . . . . . . . . . . . Observational point of view for the distributed iteration . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
6 7 7 9 10 11 11 11 13 14 14
List of Tables 1
Visited set values and states instances for two runs of the distributed recursion . . 12
22
