Coordination and Trust in Open Distributed Systems - Semantic Scholar

Coordination and Trust in Open Distributed Systems 3

Naftaly H. Minsky

[email protected] Department of Computer Science Rutgers University New Brunswick, NJ, 08903 USA November 9, 1995

Abstract The essence of this paper is that (a) eective coordination between the members of an open group of agents relies on the existence of certain regularities in the group, which usually depend on the application at hand, and, (b) that such a regularities must be imposed on the individual members of the group, by some kind of higher authority. We have described here a mechanism that provides a exible and reliable means for establishing a wide range of such regularities, by declaring them explicitly as the law of the group.

3 Work supported in part by NSF grants No. CCR-9308773

1

1

introduction

Whatever primitives one uses for coordination | which may be message passing, Linda [3], the chemical abstract machines [2], Police [4], etc. | one must assume that the interacting agents trust each other to interpret uniformly the signals being exchanged between them. But what is the basis for such trust? The answer to this question depends on whether one deals with a close knit group of interacting agents, or with an open group. The trust between the members of a close-knit group, such as a string quartet, or a group of pilots ying in formation, is based on close familiarity with each other. The members of the string quartet, for example, spent many hours practicing together in order to gain such familiarity. In computing, a group of processes spawned by a carefully designed program are similarly \familiar" with each other, since they are all the product of the single mind of their designer. But no such familiarity exists among the members of an open group, such as the car drivers meeting at an intersection between roads, or a set of software processes which have been designed separately, by dierent people, with little, if any, knowledge of each other? For such disparate processes to have any degree of trust in each other there must be some evident regularities in the system. That is, the interacting agents must be known to conform to some principles, or protocols. The role of such regularities is illustrated by the critical role played by trac laws in the safety of vehicular trac, and by communication protocols in the reliability of message trac. But how does one establish such a regularity (or a protocol1) over an open group of agents? The conventional technique for establishing communication protocols is to program them into a layer of software placed between user processes and the communication network, and deployed in the kernels of operating systems. This works well for basic and stable protocols, but not for the more incidental, higher-level, protocols needed to support applications built on top of the general purpose communication network. Such protocols are too specialized, and change too frequently, to be \hard-wired" into the kernel of operating systems. To illustrate the nature of the problem, consider a server s, and an open and heterogeneous set C of clients whose access to s must be mutually exclusive. This can be achieved if the following token-ring protocol is satis ed: 1. Only a client that has a certain token T sends messages to s. 2. Initially only one process in C has the token T. 3. The token T is moved from one process to another along a ring, but is never duplicated. Unfortunately, given the open nature of the set C, one cannot trust all its members to have been correctly implemented to observe this protocol. It is possible to enforce the tokenring protocol by building a program that embodies it, to be used as a mediator between each client and the server | this is, for example, how the TCP/IP protocol is established. But how does one deploy such a mediator? And how can one be sure that each client actually uses the mediator supplied to it? Relying on such custom mediators for every required protocol, for any given application, would make distributed systems very complex, in exible and unreliable. We clearly need a better mechanism for imposing protocols or regularities over a given collection of distributed processes. 1 A regularity is really the consequence of a faithfully observed protocol, but we will frequently use these two terms interchangeably.

2

To this end, we propose here a concept of law-governed interaction (LGI). This is a mode of interaction between the members of a given group of agents which is governed by an explicit and strictly enforced set of rules, called the law of this group. This law is global, in the sense that all members of the group are made to obey it, but it is enforced locally, at each process. This concept, which is currently implemented by an experimental toolkit called Moses using binary message passing as the basic coordination primitive, is based on previous work by the author and his colleagues [7, 8, 6]. LGI constitutes an eective separation between policy and mechanism. It provides exible and reliable means for establishing a wide range of regularities necessary to support coordination and access control in distributed applications. The rest of this paper is organized as follows: Section 2 attempts to illustrate the expected range of applicability of the proposed mechanism, by describing two protocols within it; Section 3 introduces the LGI model; Section 4 shows in details how one of the protocol discussed in Section 2 can be implemented under LGI; and we conclude with a thought about some broader implications of this work. 2

Motivating Examples

We will discuss here two regularities which are dicult to implement by traditional means, but very easy to establish under LGI. 2.1

Preventing Deadlocks by the Ordering of Resources

Consider a distributed set of servers that manage various resources, each of which might be locked by any member of an open and heterogeneous set of clients. A well known [11] technique for preventing deadlocks in this situation is to establish a linear order among the resources, and to require the following constraint to be satis ed:  No process locks a resource lower than the maximal resource already held by it.

This is a typical case in which a regularity in the individual behavior of many independent agents produces a desired global consequence | freedom from deadlocks in this case. Unfortunately, this simple regularity is dicult to ensure by traditional methods. One clearly cannot rely on voluntary compliance with this regularity by all heterogeneous clients. And there is no scalable way for the servers to enforce this regularity, because an individual server has no way of knowing which resources are already held by its client. (It can be enforced in one of the following ways: (a) by using a centralized lock manager, or (b) by providing global information to each server by a systematic multicast of all locking operations to all the servers that supply resources. But neither of these solutions is scalable.) Under LGI, on the other hand, this regularity can be imposed locally on each client, without any centralized control, and with no multicasting. 2.2

Responsive Servers

Consider an heterogeneous set of servers that require prepayment for every service they provide. Let a service request be a message of a form order(specs,fee),

3

where specs speci es the nature of the order and fee is the payment for it in some form of digital cash [12]. Suppose that a client cannot predict the time it would take the server to carry out his order, in particular because the server may have a backlog of prior orders. Moreover, suppose that the server may end up declining the order, because the fee is too small, or because the server is too busy. This situation presents the following diculties: First, once an order is sent, the client may be stuck, waiting inde nitely for the service to be performed, with its money tied up in an order that may eventually be declined. Second, the client has no assurances that if the order is declined its money will be ever returned. To alleviate these diculties, it would be useful to provide clients with the assurance that the following property, which we call the responsive servers property (or, RSP), is satis ed:  Once a client sends a message order(specs,fee) to a server, it is guaranteed to receive one of the following two responses within a bounded delay D:

1. The message accept(specs), which signi es that the server agrees to carry out the service. 2. The message decline(spec,fee), which signi es that the server declines the service order, returning, in this message, the fee sent by the client. If these conditions can be ensured, independently of the structure and behavior of the servers involved, it would clearly simplify the programming of the clients, in spite of the fact that RSP has nothing to say about the quality or the duration of the requested services themselves. Short of programming all servers carefully to guarantee timely response, as speci ed above, we know of no current technique for ensuring RSP. Under LGI, on the other hand, this property can be ensured, for arbitrary servers, as we show in Section 4. 3

Law-Governed Interaction

The concept of 4-tuple:

law-governed interaction

(LGI) for message passing can be de ned as a

hG ; M; L; Ei

;

where G is a distributed group of agents (or processes); M is the type of messages used for this mode of interaction; L is the law that governs the exchange of messages of type M | also called \L-regulated messages" | between the members of the group; and E is a distributed mechanism that enforces the law. Broadly speaking, the law can determine who in the group can send which L-regulated messages to whom, and it can cause the sending or the arrival of such a message to have certain side eects. (Henceforth, whenever there is no danger of confusion we will refer to an L-regulated messages simply as a \message.") 3.1

Agents and Groups

Every group under LGI is supported by what we call a secretary. It is a logical server2 that maintains the law of this group and certain status information of its members, and acts as a name-server for them. The secretary also provides means for admitting new members into 2 \Logical server," because, for the sake of fault tolerance and scalability, the secretary may have to be distributed and replicated, for well known reasons.

4

the group, and for removing existing members. These operations, which are subject to the law of the group, will not be discussed here in detail. The LGI model assumes no knowledge of the structure and behavior of the agents that belong to a group, or of the language in which they are programmed, if any3. In other words, agents are treated here simply as black boxes that can send messages, and to which messages can be delivered. An agent x which is a member of a group g with law L can send an L-regulated message m to another member y of this group, by means a call lg send(m,y,g); and x can receive an L-regulated message from y by a similar call to routine lg receive. These routines are supplied by Moses to any agent under LGI. Note, however, that a given agent may belong to several groups, and may, thus, exchange messages regulated by the law of any of them. Also, the membership of an agent in an LGI group does not preclude it from exchanging regular, unregulated, messages with other agents. 3.2

The Regulated Events

The law deals with several types of events such as the sending of an L-regulated message by an agent, and the arrival of such a message to it. Each of these, so called regulated events, occurs at an individual agent, called the home of the event. The following are three of the regulated events under LGI (another type of such events will be introduced later).  sent(x,m,y) | occurs when agent x sends a message m addressed to y. The sender x is the home of this event.  arrived(x,m,y) | occurs when a message m sent by x arrives at y. The receiver y is

the home of this event.

 rejected(x,m,y) | occurs when an agent x is noti ed that a message m it previously sent to y cannot be delivered, for whatever reason. The home of this event is x.

We assume no prior knowledge of, or control over, the occurrence of these events. But the eect that any given event e would actually have, when it occurs at a given agent x, is prescribed by the law of the group. This prescription, called the ruling of the law for this event, is a (possibly empty) sequence of primitive operations (discussed later) which are to be carried out at object x as the immediate response to an event e. 3.3

The Law

Structurally, the law L is a pair hR; CSi; where R is a global and xed4 set of rules de ned for the entire group, and CS is a set fCSx j x 2 Gg of what we call control states, one per member of the group. The control state CSx : This is the part of the law L that is associated with the individual member x of a group. It is a bag of terms, called the attributes of this member. The main role of these attributes is to enable L to distinguish between dierent kinds of members, so that the ruling of the law for a given event may depend on its home. Some of the attributes 3 An agent may, in particular, be a person interacting with other members of his group directly from a terminal. 4 However, as explained in [7], we intend to provide means for the global changing of R

5

of an agent have a prede ned semantics, such as the attribute self(n) that de nes n to be the unique identi er for this agent (unique within the group). In general, however, the semantics of attributes is de ned, for a given group, by its law. For instance, in a token-ring group to be discussed later, each member x would have an attribute next(x1) that de nes x1 to be the next member on the ring. Also, in this particular group, the attribute token in CSx would indicate that agent x has the token. The Primitive Operations: The operations that can be included in the ruling of the law for a given regulated event e, to be carried out at the home of this event, are called primitive operations. They are \primitive" in the sense that they can be performed only if thus authorized by the law. These operations include:

 Operations that change the CS of the home agent. Speci cally, we have the operation +t, which adds the term t to the control state, and the inverse operation -t.  Operation forward(m,y,x) emits to the network the message m addressed to y, where x identi es the sender of the message. (When a message thus forwarded to y arrives, it would trigger at y the event arrived(x,m,y).) The most common use of this operation is in a ruling for event sent(x,m,y), where operation forward (with no

arguments) simply completes the passing of the intended message.

 Operation deliver(m) delivers the message m to the home-agent. The most common use of this operation is in a ruling for event arrived(x,m,y), where operation deliver

(with no arguments) simply delivers the arriving message to the home agent.

There are few additional primitive operations, two of which will be discussed later. The global set of rules R: The function of R is to evaluate a ruling for any possible regulated-event that occurs at an agent with a given control-state. In our current model, R is represented by a very simple Prolog program. When this \program" R is presented with a goal e, representing a regulated event, and with a variable CS, representing the control-state of the home agent, it produces a list of primitive-operations representing the ruling of the law for this event. For the details of this formulation the reader is referred to [7], here we will illustrate it by the following simple example. Establishing a Token-Ring Protocol | an Example: Returning to the token-ring protocol mentioned in the introduction, consider a group that consists of a server s, and a set of clients whose use of s must be mutually exclusive. We now show how this protocol is established by letting this group be governed by law L1 of Figure 1. Initially, the clients are organized into a ring as follows: each client has a term next(n) in its CS, where n is the name of the next agent in the ring, and exactly one of these clients has the term token in its CS, indicating the possession of a token. The set R of this law consists of four rules. Each is followed with a comment (in italic), which, together with the following discussion, should be understandable even for a reader not familiar with Prolog.5 Now, to understand this law, rst note that due to Rule R1, a message addressed to an agent s would be forwarded only if the sender has an attribute 5 For a reader who is familiar with prolog we point out that the a term t@CS in a rule evaluates to true if the tern t is present in the CS of the home agent, and the term do(p) adds the primitive operation p to the ruling of the law.

6

I nitially:

The group consists of a collection of agents organized into a ring via a term

the CS of each agent. Exactly one of these agents has the term

token in

next(N)

in

its CS.

R1. sent( , ,s) :- token@CS, do(forward). A message sent to resource s is forwarded only if the sender has the token. R2. arrived( , ,s) :- do(deliver). Any message that arrives at s would be delivered. R3. sent( ,takeToken,D) :- token@CS, next(D)@CS, do(-token), do(forward(takeToken)). A takeToken message sent by the holder of a token to its neighbor would cause the token to be removed from the CS of the sender, and the message takeToken to be forwarded. R4. arrived( ,takeToken, ) :-

do(+token), do(deliver(memo(``token arrived''))).

The arrival of the takeToken message causes a token to be added to the CS of the home agent, and an appropriate memo to be delivered to it.

Figure 1: Law L1 token in its CS. This is what gives the term token its meaning as a permission to send messages to s. When such a message arrives at s it is delivered to its destination, by Rule R2. Second, by Rules R3 and R4, the holder of a token can move it to the next agent of the ring by sending the message takeToken to it. This is done as follows: When a message takeToken is sent, Rule R3 validates that the sender itself possesses the token, and that the message is addressed to the next agent on the ring. If these conditions are satis ed, then the token is removed from the sender, and the message is forwarded. When a takeToken message arrives at an agent, Rule R4 adds the term token into its control state, and delivers an appropriate memo to the receiver, to let it know that it now possesses the token. 3.4

The Distributed Enforcement Mechanism

The law is enforced, in principle, as follows: There is a controller associated with each member of a given group, logically placed between the agent and the communications medium, as is illustrated in Figure 2. All controllers have identical copies of the global set of rules R of the group in question, and each controller maintains the control state of the agent under its jurisdiction. Every controlled-event e, associated with a given group, that occurs at a given member x of this group, is intercepted by the controller of x, in a manner not discussed here. This controller evaluates the ruling of the law L for e, and it carries out this ruling, as is illustrated in Figure 2. The essential aspect of this architecture is that all controllers share the same R. It is in this sense that the law is said to be global to the group. We do not discuss here the manner in which the same R is deployed in all controllers. We do point out, however, that in our current implementation, there is one controller per machine, which handles all agents resident in this machine, and maintains all their control states. This controller operates as a daemon, in its own address space. Finally, note that this enforcement mechanism, by a software controller, is not secure, in 7

R

x

agent

CSx sent

-token forward

deliver

arrived

communication network

R

R controller

R

Legend: a regulated event---------------------a primitive operation ------ --------

Figure 2: Enforcement of the Law

8

the following sense: Consider a member y of group G with law L that receives a message m from another member x of G . Under our current enforcement mechanism y cannot be really sure that m is an L-regulated message; namely, that it has been forwarded by a controller of x interpreting law L, because the message might have been generated by some program that just made it look as an L-regulated message. This lack of security is, of course, shared by conventional hand-coded protocols. If anything, LGI should enhance security because it relies on a single controller that can be maintained by the kernel. Of course, this is not sucient for applications that, out of concern about malicious agents, require strict security. We are developing a secure enforcement mechanism, for these applications; but this is beyond the scope of this paper. 3.5

Obligations

Note that so far, our law has been purely reactive. That is, it prescribes what should be done in response to certain events, but it cannot initiate any action on its own. To provide our model with certain pro-active capabilities, in some analogy with but weaker than the pro-active capabilities proposed by Andreoli et al. [1], we now introduce a concept of \obligation." This concept is based broadly on the societal notion of obligation, and more directly on the concept of enforced obligation introduced by this author [9], and on the work of Maibaum [5] and of Feather[10], on formal speci cation of temporal constraints. For a complete treatment of this concept the reader is referred to [6]. Broadly speaking, an obligation imposed on a given agent serves as a kind of motive force that ensures that a certain action (called sanction ) will be carried out at this agent, at a speci ed time in the future (when the obligation is said to come due ), provided that a certain condition on the control state of the agent is satis ed at that time. We now give some more details of this concept, and illustrate its use with law L2 of Figure 3, which establishes a token-ring protocol that does not allow the token to stay more than 5 seconds at any given agent. The primitive operation impose obligation(p,dt) carried out at agent x would cause the event obligationDue(p) to occur at x in dt seconds, (provided that this obligation has not been repealed in the meantime, by means of the inverse primitive operation repeal obligation.) The occurrence of event obligationDue(p) at x, prompts the controller of x to evaluate the ruling of the law for this event, and then carry it out. This ruling is, thus, the sanction for this obligation. Under Law L2, in particular, the arrival of a token at a given agent x causes operations impose obligation(yield token,5) to be carried out at this object (see Rule R4). If x sends the token away voluntarily, then, by Rule R3, this obligation would be repealed. Otherwise event obligationDue(yield token) would occur, causing, by Rule R5 the token to be forcibly send away along the ring. Finally, we note that our concept of obligation can be viewed as a kind of triggers. But they are tightly regulated triggers, because the imposition of obligations, the sanction associated with them, and the ability to repeal a pending obligation, are all governed by the law of a group. 3.6

Fault Tolerance

Since LGI assumes nothing about the interacting agents, it is completely tolerant to all their failures, even of a Byzantine kind. For example, under law L2 above, the token will 9

I nitially: Exactly one agent in the group has token in its control state, and it also has the term obligation(yield token,5). Each process has a next(y) term, which organizes the group of agents into a ring.

R1. sent( , ,s) :- token@CS, do(forward). A message sent to resource s is forwarded only if the sender has the token. R2. arrived( , ,s) :- do(+deliver). Any message that arrives at s would be delivered. R3. sent( ,takeToken,D) :- token@CS, next(D)@CS, do(-token), do(repeal obligation(yield token, )), do(forward(takeToken)). The holder of the token can pass it along the ring, this would cause its pending obligation to yield the token to be repealed. R4. arrived( ,takeToken, ) :do(+token), do(impose obligation(yield token,5)), do(deliver(memo(``token arrived'')). When the takeToken message arrives, it carries the token into the control state and the process is informed, simultaneously incurring an obligation to yield the token in 5 seconds. R5. obligationDue(yield token) :- next(Peer)@CS, do(-token), do(forward(takeToken,Peer)).

Ful ll the obligation to yield the token.

Figure 3: Law L2

10

continue to go around the ring even if all the agents involved fail. Moreover, since, outside of obligations, LGI's semantics are purely reactive in nature, LGI can trivially maintain its guarantees even in the face of benign failures by controllers. But LGI is sensitive to two kinds of failures of the fail-stop type: (a) the failure of a secretary, which may have an adverse aect on the long term existence of the group, even if it has no eect on the immediate interaction between its members; and (b) the failure of a controller, if it carries a pending obligation, which would never come due if the controller fails. The treatment of these failures by fairly standard fault tolerance techniques, is beyond the scope of this paper. 4

Establishing the Responsive Servers Regime under LGI

We introduce here law L3 displayed in Figure 4, which establishes the responsive servers regime (RSP) described in Section 2.2. This law assumes that initially every agent in the group has in its control state the term cash(b), where b is an integer that thus represents the cash invested in this agent; and term escrow(0), which states that the agent has zero amount in escrow (the signi cance of escrow under L3 will become clear later). We rst discuss the various messages that can be exchanged under this law between a client c and a server s, and the eect of these messages. interaction. First, consider a message order(specs,9) sent by c to s. Due to Rule R1 of L3, this message would be forwarded to s only if c has more than $9 in cash, and only after the cash of c is decremented by 9. By Rule R2, the following operations would be carried out when this message arrives at s: (a) the escrow account of s is incremented by 9; (b) an obligation respond(c,specs,9) is imposed on s, to become due in 60 seconds (used in this law just as an example); and (c) the order is delivered to the agent of s. As we shall see below, the money deposited into escrow will be withdrown from it when a responce to the order in question is given. Note that this money cannot be used by s to make his own orders, because, by Rule R1, orders can utilize only money de ned as cash. As long as the obligation respond(c,specs,9) is pending, s can respond voluntarily to the order he recieved from c, either by accepting or be declining it, as follows:  To accept an order(specs,fee) recieved from c, the server s sends a message accept(specs) to it. This message is governed by Rules R3 and R5. By Rule R3, the sending of an accept message causes the following operations to be carried out: (a) 9 dollars are removed from the escrow and added to the cash value of s, thus making this money usable by s for making its own orders; (b) the relevant respond(...) obligation is repealed, since it is obviously not needed any longer; and (c) the accept message is forwarded to c. By Rule R5, the arrival of a message accept(specs,fee) causes the term receipt(accept(specs,fee),Time)

to be added to the CS of the reciever c, which can serve as a time-stamped record of the promise of the server to carry out the service. Note that the parameter 9 in this message does not cause any transfer of cash.  To decline an order(specs,9) recieved from c, the server s sends a message decline(specs,9) to it. This message is governed by Rules R4 and R6. By Rule R4,

11

I nitially:

Every agent in the group starts with a term

cash(b), where b escrow(0).

is an integer that thus

represents the cash invested in this agent; and with term

R1. sent(C,order(Specs,Fee),S) :cash(D)@CS, ( D > Fee), do(decr(cash(D),Fee)), do(forward). A message order( ,Fee) can be send only by one whose cash balance is larger than Fee. This balance is decremented by the sending. R2. arrived(C,order(Specs,Fee),S) :do(incr(escrow(D),Fee)), do(impose obligation(respond(C,Specs,Fee),60)), do(deliver). When an order arrives, its Fee is added to the cash of the reciepient, the order is delivered to him, and an obligation is imposed to respond to the order in 60 seconds (see Rule R7). R3. sent(S,accept(Specs),C) :obligation(respond(C,Specs,Fee),T)@CS, do(decr(escrow(D),Fee)), do(incr(cash(D),Fee)), do(repeal obligation(respond(C,Specs,Fee), )), do(forward). An agent can send an accept message only if it has a matching obligation to respond; this obligation is automatically repealed by this response. R4. sent(S,decline(Specs,Fee),C) :obligation(respond(C,Specs,Fee),T)@CS, do(decr(escrow(D),Fee)), do(repeal obligation(respond(C,Specs,Fee), ))), do(forward). Similar to the previous rule, except that the decline message carries with it the Fee found in the obligation to respond, after removing it from the balance. R5. arrived(S,accept(Specs,Fee),C) :do(+receipt(accept(Specs,Fee),Time)), do(deliver). Upon its arrival, an accept message is recorded in the CS of agent C, and delivered to its agent. R6. arrived(S,decline(Specs,Fee),C) :do(incr(cash(D),Fee)), do(deliver). Get the money and deliver the message R7. obligationDue(respond(C,Specs,Fee)) :do(decr(escrow(D),Fee)), do(forward(decline(Specs,Fee),C,Self)).

The sanction consists of (a) decrementing the balance, to allow for the money to be returned, and (b) forwarding the decline message to the original client, which has the same eect as the decline message sent voluntarily under Rule R6.

Figure 4: Law L3 of Responsive Servers 12

the sending of an decline message causes 9 dollars to be removed from the escrow, and transferred in the message forwarded to c; the respond(...) obligation is then repealed, as in the previous case, and the decline message is forwarded. By Rule R6, the arrival of a message decline(specs,9) at c causes 9 dollars to be returned to its cash value. If server s did not respond to order(specs,9) from c in time, then obligation respond(c,specs,9) (imposed by the arrival of this order) would come due, triggers the sanction de ned by Rule R7. This sanction is as follows: (a) 9 dollars are withdrawn from the escrow of s; (b) a decline message is forwarded to client c, with precisely the same eect that a voluntary decline would have. Note that, as required in Section 2.2, c is guaranteed to recieve a responce form s within a bounded delay D, provided tha there is a bound B on a mesage trasit time. In our case we will get, approximately: D = 2 3 B + 10

Finally, a comment about the fault tolerance of this law in implementing RSP. As long as controllers do not fail, RSP is not sensitive to the failore of an agent. Because it is the controller that maintains the money, and deals with the obligations. The failore of a controller is, of course a more serious matter. However, in the case of fail-stop failore by a controller, our law can be modi ed to produce fault tolerance for RSP. But this is beyond the scope of this paper. 5

Conclusion

Although this paper is formulated in terms of coordination by means of message passing, its essence is valid for coordination in general, which might use such models as Linda, the chemical abstract machines, Police, etc. The essence of this paper is that (a) eective coordination between the members of an open group of agents relies on the existence of certain regularities in the group, which usually depend on the application at hand, and, (b) that such a regularities must be imposed on the individual members of the group, by some kind of higher authority. For coordination by message passing, we have described here a mechanism that provides a exible and reliable means for establishing a wide range of such regularities, by declaring them explicitly as the law of the group. But similar mechanisms should be provided for other types of coordination as well. (A rst step towards such a mechanism for Linda has been taken, in [8].)

13

References

[1] J.M. Andreoli, H. Gallaire, and R. Pareschi. Rule-based object coordination. In P. Ciancarini, O. Nierstrasz, and A. Yonezawa, editors, Object-Based Models and Languages for Concurrent Systems, Lecture Notes in Computer Science, pages 1{13. Springer-Verlag, 1995. Number 924. [2] G. Berry and G. Boudol. The chemical abstract machine. In Symposium of Programming Languages. ACM, ACM, January 1990.

on Principles

[3] N. Carriero and D. Gelernter. Coordination languages and their signi cance. nications of the ACM, 35(2):97{107, February 1992. [4] Paolo Ciancarini. Coordinatioon languages for open system design. In the IEEE Conf. on Computer Languages, pages 252{260, July 1990.

Commu-

Proceedings of

[5] S.J.H. Kent, T.S.E. Maibaum, and W.J. Quirk. Formally specifying temporal constraints and error recovery. In Proceedings of the IEEE Int. Symp. on Requirement Engineering, pages 208{215, San Diego, CA, January 1993. [6] J. Leichter and N.H. Minsky. Obligations in law-governed distributed systems. Technical report, Rutgers University, LCSR, 1995. [7] N.H. Minsky. The imposition of protocols over open distributed systems. actions on Software Engineering, February 1991.

IEEE Trans-

[8] N.H. Minsky and J Leichter. Law-governed linda as a coordination model. In P. Ciancarini, O. Nierstrasz, and A. Yonezawa, editors, Object-Based Models and Languages for Concurrent Systems, Lecture Notes in Computer Science, pages 125{146. SpringerVerlag, 1995. Number 924. [9] N.H. Minsky and A. Lockman. Ensuring integrity by adding obligations to privileges. In Proceedings of the 8th International Conference on Software Engineering, pages 92{102, August 1985. [10] Feather Martin S. An implementation of bounded obligtions. In Proceedings of the 8th Knowladge Based Software Engineering Conference, pages 114{122, Chicago, Ill, September 1993. [11] A. Tanenbaum. [12] B. Yee.

. Prentice Hall, 1995.

Distributed Operating Systems

. PhD thesis, Carnegie Mellon University, May 1994.

Using Secure Coprocessors

14