Building Recon guration Primitives into the Law of a System Naftaly H. Minsky
Victoria Ungureanu Junbiao Zhang
y
Wenhui Wang
z
Department of Computer Science Rutgers University New Brunswick, NJ 08903 fminsky,ungurean,wenhui,
[email protected]
Abstract
Given a certain class C of recon gurations, deemed to be potentially important for a given system, we de ne a recon guration suite SC to be a set of primitive operations that satisfy the following conditions: Any recon guration in C can be carried out by a sequence of primitives from SC . The correctness of SC should be independent of the functionality of the system, and invariant of its recon gurations (for a given set of possible con gurations of the system at hand). We describe a mechanism for implementing such recon guration suites, for a system that operates under law-governed interaction (LGI), currently supported by an experimental toolkit called Moses. LGI is a mode of interaction between the members of a given group (or system) of agents, which is governed by an explicit and strictly enforced set of rules, called the law of this group. The existence of such a law under LGI provides us with an architectural model of the system, which can be made to include the de nition of recon guration suites.
1 Introduction
One can distinguish between two types of dynamic recon gurations: a programmed recon guration, which is predesigned into the system, and an adhoc recon guration, which is performed in response to an unplanned change in system requirements, or to an unpredictable change in the environment in which the system operates. Both types of recon gurations are Work partially supported by NSF y Work partially supported by NSF z Work partially supported by NSF
grants No. CCR-9308773 grants No. CCR-9308773 grants No. CCR-9308773
problematic. Programmed recon gurations are frequently inapplicable, because of the diculty to predict precisely how a system will need to be changed, and ad-hoc recon guration are dicult to carry out reliably, and generally involve massive disruptions in the normal operation of the system [1]. We adopt here a middle ground between the above two extremes, as follows: for a given class, or set, of recon gurations C , deemed to be potentially important for a given system, we propose to construct a suite of primitives SC , called a recon guration suite, that can be used to carry out any of the recon gurations in C , in an ad-hoc manner. For example, consider a system that contains a collection of agents (or processes) organized into a ring and engaged in a token-ring protocol. Suppose that we have the following means for removing agents from the ring, and for inserting agents into it, while the system operates | without destroying the structure of the ring and without losing the token:
Given an arbitrary member x of the ring, a message remove sent to x removes it from the ring.
Given an arbitrary member x of the ring, and an arbitrary agent y not in the ring, a message insert(y) sent to x would insert y into the ring, following x.
It is clear that under these assumptions it is possible to carry out an arbitrary modi cation of the ring by an appropriate sequence of remove and insert messages, which thus constitute a recon guration suite for a token ring. In general, one would like such a recon guration suite SC to satisfy the following conditions:
1. The correctness of SC should be independent of the functionality of the system, and invariant of its recon gurations (for a given set of possible con gurations of the system at hand). 2. The primitives in SC should be ecient, particularly in terms of the degree of disruption of the normal operation of the system which is caused by them. For example, according to condition (1) above, our token-ring recon guration suite should work independently of the nature of the agents involved. In particular, any agent inserted into a ring should be guaranteed to function correctly as a member of this ring. And to satisfy condition (2) above, one should try to insert an agent into a ring without passivating any other member of it. We describe here a mechanism for implementing such recon guration suites, for a system that operates under law-governed interaction (LGI) [2], currently supported by an experimental toolkit called Moses. LGI is a mode of interaction between the members of a given group (or system) 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 agent. The existence of such a law under LGI provides us with an architectural model of the system, which can be made to include the de nition of recon guration suites. The rest of this paper is organized as follows: Section 2 introduces the LGI model, and illustrates it by showing how a token-ring protocol can be established by a law under LGI. Sections 3 and 4 introduce examples of the use of LGI for recon guration: Section 3 shows how a recon guration suite for a token ring can be built into the law of a system, and Section 4 shows how code replacement can be supported under LGI. Finally, Section 5 outlines the essentials of this paper.
2 Law-Governed Interaction
The concept of law-governed interaction (LGI) for message passing can be de ned as a 4-tuple: 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 e ects. (Henceforth, whenever there is no danger of confusion we will refer to an L-regulated message simply as a \message.")
2.1 Agents and Groups
Every group under LGI is supported by what we call a secretary. It is a logical server1 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 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 any2. 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.
2.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. 1 \Logical server," because, for the sake of fault tolerance and scalability, the secretary may have to be distributed and replicated. 2 An agent may, in particular, be a person interacting with other members of his group directly from a terminal.
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.
R
x
CSx sent
-token forward communication network
Structurally, the law L is a pair hR CSi where R is a global and xed3 set of rules de ned for the entire group, and CS is a set fCSx j 2 Gg of what we call control states, one per member of the group.
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 commonuse 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 control state CSx: This is the part of the law
The global set of rules R: The function of R is
agent
deliver
arrived
R
R controller
R
Legend: a regulated event---------------------a primitive operation ------ --------
Figure 1: Enforcement of the law | occurs when an agent x is noti ed that a message m previously sent to y cannot be delivered. The home of this event is x. We assume no prior knowledge of, or control over, the occurrence of these events. But the e ect 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. rejected(x,m,y)
2.3 The Law
;
;
x
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 di erent kinds of members, so that the ruling of the law for a given event may depend on its home. Some of the attributes 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
L
3 However, as explained in [3], we intend to provide means for the global changing of R
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 formulationthe reader is referred to [3].
2.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 1. 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. 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.
2.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. [4], we now introduce a concept of \obligation." This concept is broadly based on the societal notion of obligation, and more directly on the concept of enforced obligation introduced by Minsky [5], and on the work of Maibaum [6] and of Feather [7], on formal speci cation of temporal constraints. For a complete treatment of this concept the reader is referred to [8]. 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. 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.
2.6 Establishing a Token Ring Protocol | an Example
To illustrate the use of LGI, we consider an application in which a set of agents, acting as clients must use a server s in a mutually exclusive manner. This can be done by a token ring protocol that ensures the following conditions: (i) only a single token exists in the system, (ii) only the agent which has the token can access the server, (iii) the token has to be passed clockwise around the ring, and (iv) an agent must not keep the token longer than 5 seconds. The law establishing this protocol is presented in Figure 2. We make the following assumptions about the control state of the set of clients in question. First, the clients are organized into a ring, via an attribute next(x1) in their control state; and second, only one of them has an attribute token, representing the possession of a token. Our law contains a set R of ve 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.4 Now, to understand this law, rst note that due to Rule R1 a message addressed to the server s would be forwarded only if the sender has the attribute 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 giveToken to it. This is done as follows: when a message giveToken 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 giveToken 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. The arrival of a token at a given agent x causes operation 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 point out that the correctness of this 4 For a reader who is familiar with Prolog we point out that a term t@CS in a rule evaluates to true if the term 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.
protocol is independent of the behavior of the agents involved in the ring. In particular, the token would circulate along the ring even if any numbers of agents on it fail | provided the controllers do not fail. The fault tolerance of LGI under failures of controllers has been discussed in [2].
Link Message Next pointer Change primitive
[remove]
x
x z
y
z
y
I nitially: R
1.
R
2.
R
3.
The group consists of a collection of agents organized into a ring via a term next(N) in the CS of each agent. Exactly one of these agents has the term token in its CS.
sent( , ,s) :token@CS do(forward) | do(deliver(memo(``message not sent''))).
!
A message sent to server s is forwarded only if the sender has the token.
arrived( , ,s) :-
do(deliver).
Any message that arrives at s would be delivered. sent( ,giveToken,next) :token@CS, next(N)@CS, do(-token), do(repeal obligation(sendToken, ), do(forward(giveToken,N)).
The holder of the token can pass it along the ring. Once he has passed the token, his pending obligation is cancelled.
R
4.
R
5.
arrived( ,giveToken, ) :do(impose obligation(sendToken,Clock+5)), do(+token), do(deliver(memo(``token arrived''))).
The e ect of receiving a giveToken message is that the token is added to the control state and the obligation to pass the token in 5 sec is incurred.
obligationDue(sendToken) :next(N)@CS, do(-token), do(forward(giveToken,N)).
Ful ll the obligation to pass the token.
Figure 2: Token passing with 5 seconds time limit
3 A Recon guration Suite for Token Rings
In the introduction we have proposed a recon guration suite for token rings, consisting of the pair of primitives remove and insert de ned as follows: Given an arbitrary member x of the ring, a message remove sent to x removes it from the ring. Given an arbitrary member x of the ring, and an arbitrary agent y not in the ring, a message
Forwarding "link" message
Figure 3: Removing a ring member insert(y) sent to x would insert y into the ring, following x. We will now present a design of this suite. Our design ensures that these primitives cannot be executed concurrently. This is done basically as follows. An agent can invoke one of these primitives only if it has the term baton in its control state. We assume that there is only one agent in the system that has such a baton; we will refer to this agent as the coordinator. When the coordinator initiates a primitive, it temporarily loses its baton, until the change operation is concluded. (We do not discuss here how the baton is initially deployed and how it might be transferred from one agent to another.) We will now discuss how each of the two primitives in this suite is implemented by the law presented in Figure 4.
Removal of an Agent From the Ring
To remove an arbitrary agent, say x, from the ring, the coordinator c sends a remove message to x. By Rule R6, this message is forwarded to x only if c has the baton (which is removed from its control state). When x receives the remove message (Rule R8), it sends to its successor y the message link(x,y,c). By Rule R10 an agent receiving the message link(x,y,c) checks if its current successor is x; if it is not, then the link message is forwarded to its successor, thus circulating around the ring until it arrives at the only agent z whose successor is x. By Rule R10, again, agent z updates its next(x) attribute to be next(y) | which is what removes x from the ring | and sends an acknowledgment message changePerformed to c. By Rule R11, when the coordinator c receives a changePerformed message, the term baton is returned to its control state. Note that this set of rules is robust enough to pre-
R
6.
R
7.
R
8.
R
9.
sent(C,remove,X) :baton@CS, do(-baton),
do(forward).
An agent that has the baton may sent a remove message, loosing the baton, until the removal transaction completes, as we shall see. sent(C,[insert(Y)],X) :baton@CS, do(-baton) ,
do(forward).
Only a member which has the baton may sent an insert message.
arrived(C,remove,X) :next(Y)@CS, do(forward(link(X,Y,C),Y)).
The e ect of receiving a remove is that a link message is sent to the next agent in the ring.
arrived(C,[insert(Y)],X) :next(Z)@CS, do(next(Z) next(Y)), do(forward(link(ignore,Z,C),Y).
Modify the next term so it contains Y. Send a link message to Y.
R
10.
R
arrived(S,link(X,Y,C),Y) :- next(N)@CS, (X = N |X = ignore ) do(next(N) next(Y)), do(forward(changePerformed,C)) | do(forward(link(X,Y,C),N))).
!
If the current successor of the destination is X, the value will be updated to Y. Otherwise the message is forwarded to the next agent in the ring..
11.
arrived( ,ChangePerformed,C) :- do(+baton).
The e ect of receiving a changePerformed message is that the baton is added to the control state.
Figure 4: Recon guration suite for a token ring vent possible token losses during system transition. Referring to the above example, there are two possible cases in which the token could be inadvertently lost:(i) x has the token when it receives the remove message; (ii) the token is being sent to x before it is actually removed. However, since whenever x gets the token, it has the obligation to send it away to its successor, and since the next attribute of x is not modi ed by its removal, the token will be eventually sent to y, although x is not really in the ring anymore. After that, the token will be correctly circulating in the new ring.
Insertion of an agent
To insert an agent y after x in the ring, the coordinator c sends an insert(y) message to x (Rule R7).
When this message is received by x, the following actions will be taken (Rule R9): (i) the next term is modi ed to point to y, and (ii) a link(ignore,z,c) message is sent to y where z was the previous successor of x. After y sets its successor to z, the insertion is completed, which (as in the case of deletion) triggers the acknowledgment message changePerformed to be sent to c. Note that once agent y is thus inserted into the ring, it is guaranteed to function correctly as a member of this ring, independently of the program that drives it.
Discussion
Note that unlike in [9], both primitives in this suite are carried out without stopping the normal operation of any member of the ring. Moreover, the coordinator is not required to have any knowledge of the structure of the ring in order to invoke the change primitives on it. So far we have assumed the existence of a single ring in the system. However, the law can be extended to deal with any number of rings, simply by associating a baton with each.
4 Code Replacement
Another example of dynamic recon guration is changing the program of a given agent of a system without shutting the entire system down. This is useful, in particular, when repairing bugs or introducing new functionalities. We will discuss here such code replacement using the client-server model from [1] as an example. Under this model, the system consists of a number of clients and servers; the problem is to update the code of a given server s without losing any requests from its clients. The solution introduced here involves only the server whose program is being modi ed. Neither the clients of this server, nor any other agent needs to be passivated, even when dependent transactions are present in the system. This is done, essentially, by having the controller of each server absorb the requests arriving to it while the update of its program is in progress. The solution presented in [1] for this problem passivates5 all the clients that might send messages to s, even when only independent6 transactions 5 A node is in a passive state if (1) it is not currently engaged in a transaction that it initiated, (2) it will not initiate new transactions. 6 An independent transaction is a two-party transaction whose completion does not depend on any other transaction. A dependent transaction is a two-party transaction whose completion may depend on the completion of other consequent transactions.
I nitially:
Every server has in the control state the terms: (1) lastRequest(X) where, X is the label of the last request delivered to the server; (2) notServed(S), where S is the list of requests delivered to the server, but not serviced yet; (3) pending(P), where P is the list of requests not delivered to the server. The initial values of this terms are, respectively, lastRequest(0), notServed([]) and pending([]).
R
1.
arrived( ,reprogram(P),S) :notServed([])@CS start(P) ;
!
do(+updating(P)).
When a reprogram message arrives at a server's controller, if the server is inactive (the notServed list is empty) the controller will start the new version. Otherwise, the controller will add the term updating(P) to the CS.
R
2.
R
3.
sent( C,request(Request),S) :-
do(forward).
Any request for a server is forwarded.
arrived( C,request(Request),S) :not(updating(P)@CS) (lastRequest(L)@CS, L1 is L+1, do(lastRequest(L) lastRequest(L1)), do(deliver([Request,L1]),C), notServed(S)@CS, add element(L1,S,S1), do(notServed(S) notServed(S1)) ; (pending(L)@CS,append(L,[Request,C],L1),do(pending(L) pending(L1))).
!
If the version has to be changed, the new request is not delivered but enqueued. Otherwise the new request is assigned a label and delivered to the server and the notServed list is updated to contain the label of the new request.
R
4.
sent(S,response(Message,RequestNo), C) :- do(forward), notServed(S)@CS, del element(RequestNo,S,S1), do(notServed(S) notServed(S1)), (updating(P)@CS, S1 =[]) (start(P), do(-updating( )),lastRequest(L)@CS, pending(P)@CS, deliverPendingRequests(L,P,[]) ; true.
!
When a server responds to request, the controller removes its label from the list of notServed requests and forwards the answer. If it is in the process of changing the version of the server and the server is inactive it will start the new version to which it will deliver the enqueued requests.
R
5.
R
6.
R
7.
arrived(S,response(Message, ), C) :-
Any message for a client is delivered.
do(deliver(Message)).
deliverPendingRequests(L,P,S) :(P=[[Request,C]|T] L1 is L+1, add element(L1,S,S1), do(deliver([Request,L1],C)),deliverPendingRequests(L1,T,S1)) ; do(lastRequest( ) lastRequest(L)), do(pending( ) pending([])), do(notServed([]) notServed(S)).
!
Every request in the queue will be dequeued, assigned a label and delivered to the server. start(P) :-
:::
The old version of the server will be removed and the new program P will be started.
Figure 5: Changing the version of a server
are allowed. In the presence of dependent transactions, one may also have to passivate some servers, under this solution. To facilitate our reprogram primitive, we maintain the following terms in the control state of each server s: (i) the term lastRequest(r), where r is the label of the last request delivered to s; (ii) the term notServed(l), where l is the list of labels of the requests delivered to s, but not serviced yet; (iii) the term pending(p), where p is the list of requests arrived for s but not delivered. A server that has the term notServed([]) in its control state is called inactive, because it has no pending requests to serve. And it is only when a server is in this state, that a new version of its program would be installed. Now, to replace the program of a server s with a new program p one is expected to send the message reprogram(p) to s. What happens once this message arrives at s, and the general exchange of messages between servers and their clients, is de ned by the partial law displayed in Figure 5. First note that any request sent by a client will be forwarded by Rule R2 and any response from a server arriving at a client will be delivered by Rule R5. Now, by Rule R1, when a message reprogram(p) arrives at a server s one of the following two things would happen: if s is inactive then the program-change will be performed right away, according to Rule R7, which is left unspeci ed here. Otherwise, the controller adds the term updating(p) in the control state, which will serve as an indication that the change process is underway. Rule R3 describes the actions taken by a controller when a request arrives at server s. If no update was initiated for s, the controller will: (i) generate a new label l1 for the request,(ii) update the lastRequest term to be l1, (iii) include l1 in the notServed list, and (iv) deliver the labeled request to s. Otherwise, if the version of the server has to be changed, the request will not be delivered, but enqueued in the pending list. Finally, Rule R4 responds to a request. First, the message will be forwarded to the client which issued the request. Secondly, the label of the corresponding request is removed from the notServed list. In the case that a change was initiated (the term update(p) is present in the control state of s) and the server is now inactive (the list notServed is now empty) it will start the new program p. After the change is executed, the request from the pending list will be labeled and delivered to the server in the order of arrival (Rule R6).
5 Conclusions
Our ability to create recon guration suites which are independent of the functionality of the system, rests squarely on the existence, under the LGI, of an enforced global law of a system. Such a law can establish regularities without which it would have been impossible to formulate such recon guration primitives. The law also provides a convenient medium for the formulation of such suites of primitives, which thus become part of the architectural model of the system. The degree to which we are able to formulate ecient primitives, involving minimal recon guration delays, and minimal disturbance of the normal operation of the system, is also due to the existence of a global law. It would have been impossible, for example, to reprogram an arbitrary server in the system without passivating its clients | as shown in Section 4 | if it were not for the assurance, provided by the law, that the controller of the server absorbs all messages arriving during the update process. Another aspect of recon guration under LGI, which is beyond the scope of this paper, is the possibility to use the law for establishing controls over the use of the various recon guration primitives. The law can be used, for example, to establish desired policies concerning who can add which agent to which token-ring, and who can reprogram which server, and under which circumstances.
References
[1] J. Kramer and J. Magee. The evolving philosophers problem: Dynamic change management. IEEE Transactions on Software Engineering, 16(11):1293{1306, November 1990. [2] N.H. Minsky. Coordination and trust in open distributed systems. Technical report, Rutgers University, LCSR, October 1995. (available through http://www.cs.rutgers.edu/~minsky/index.html). [3] N.H. Minsky. The imposition of protocols over open distributed systems. IEEE Transactions on Software Engineering, February 1991. [4] J.M. Andreoli, H. Gallaire, and R. Pareschi. Rulebased object coordination. In P. Ciancarini, O. Nierstrasz, and A. Yonezawa, editors, ObjectBased Models and Languages for Concurrent Systems, Lecture Notes in Computer Science, pages
1{13. Springer-Verlag, 1995. Number 924. [5] 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.
[6] 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. [7] Feather Martin S. An implementation of bounded obligations. In Proceedings of the 8th Knowladge Based Software Engineering Conference, pages 114{122, Chicago, Ill, September 1993. [8] J. Leichter and N.H. Minsky. Obligations in lawgoverned distributed systems. Technical report, Rutgers University, LCSR, 1995. [9] G. Etzkorn. Change programming in distributed systems. In Intl. Workshop on Con gurable Distributed Systems, pages 140{151, March 1992.
