First Steps to an Interaction and Communication Manager between Remote Objects Laurent Berger
Mireille Blay-Fornarino Olivier Jautzy
Anne-Marie Pinna-Dery
[email protected],
[email protected],
[email protected],
[email protected]
1 Introduction
Object oriented programming has already proved its interest to implement complex applications. Distributed applications can also be developped with object technologies but this implies to manage communications between remote objects. Tools such as CORBA [GX92], RPC [Cor91] and Java RMI [SUN96] facilitate the communication implementation by hidding network accesses. Distributed applications are now needed in software developments, for example in domains such as Human Machine Communication and groupware to separate graphical development and functional core [RP95b, Cou87, HBR+ 94], or to localize each agent of a collaborative work on di erent sites [RP95a, Kar94]. This evolution of distributed applications increases the need to specify explicitly the communication and interaction semantics between objects [Bos94, Rum92]. However the above-mentioned tools do not allow to express the semantics of interactions between objects. Few works deal with the way to express and to manage interactions between remote objects independently of their intrinsic behavior [HO93, Pin93, Fro94, NGGS93, Hol92, SN92] . However in these approaches the programmer may implement the interactions in the method code, link the objects at the class level, mixing intrinsic and communication knowledge. We observe, looking at programs written in an object-oriented language, that a signi cant fraction of method code is devoted to the communication of the object with other objects. Then, the problem is : can we de ne outside the objects a model to express and manage interaction between remote objects? This model should be appropriated to specify various aspects of component interactions such as synchronization, delocalization, negotiation and data exchange [BG96a, BG96b]. It also has to deal with network failures, deadlocks and cycles or non determinism occuring in an interacting object graph. Moreover, an Interaction and Communication Manager (ICM) stem from the model, allows, by specifying the interactions, to keep inside the interacting objects only their intrinsic functionalities. So to determine the speci cation of an Interaction and Communication Manager (ICM), we rst enumerate the main interaction and network properties (see sections 1.1 and 1.2) expected the model. Secondly we illustrate the model speci cations with a concrete example in section 2. We then propose a distributed architecture (see section 3).
1.1 Interaction properties
In this section, we resume the essential properties expected from an interaction manager. The seems to be a fundamental paradigm required for such a manager. For example, a client software component that displays real-time data usually needs to be updated as soon as the information changes on the source side, so that the model has to cope with the expression of such a behavior. Another sort of reactivity consist in delaying the update according to some parameters such as the object state or a request from a client. As a consequence, reactivity consists in sending messages before or after the asked message. That is, an ICM prescribes what should be done in response to some message requests, but it also has to initiate actions on the interacting objects. Own properties and behavior are then needed by the interaction model. In particular, automata are often used to design the internal states of communications. Another example is the management, by the interaction model, of the delay between two client calls to a server. The introduction of a condition such as an if-then-else instruction is also necessary for expliciting contextual reactions. The reactions can indeed depend on the state of the communication and a condition has to be checked on the state of the interaction to determine how to react. reactivity
1
1.2 Network communication properties
The main goal of platforms such as Corba or Java RMI is to achieve object distribution transparency, which means that the interaction between a client component and a server component through the server interface is independent of their physical location, access path[Pin93]. Our aim is to give to our model this level of transparency of the communication constraints. We also have to consider failure cases : what happens if an object cannot answer because the machine where it is localized is down ? What happens if the network communication loses messages ? The manager must be able to detect failures and to signal or correct them. The integration of transaction in our model has also to be studied. When must we provide the Atomicity Consistency Isolation and Durability (A.C.I.D.) properties of transactional communications [Mul89, Gra93, Cas94] ? At present, we are not able to statuate if the notion of transaction has to be explicitly managed by the ICM or if the proposed meta-protocol is sucient to implement transactions. Morover, object distribution implies to design synchronous or asynchronous reactivity. That is, if a message m is received by an interacting object, according to the interaction model we will react before or after the execution of the corresponding method (synchronous) or in parallel (asynchronous). The main diculty of the ICM speci cation is to decide which minimal set of properties has to be included in the model in order, for example, to detect and manage deadlocks.
2 An Example : the dining philosophers We illustrate our needs and our aim thanks to the well known problem occuring in a secluded community of ve \chinese\ philosophers who are engaged in only two activities : thinking and eating. We have a table with ve plates and ve chopsticks. In the center of the table is a bowl of rice (endlessly replenished). To eat, each philosopher needs to pick up the chopsticks on his left and right, but only one at a time. Our aim is to design this problem by expressing communication outside the objects, in some ICMs.
2.1 Part of the syntax
This example deals with reactivity problems. So, let us show the simpli ed syntax about the model reactivity. Rule -> LeftMessagesList ``->'' RightMessagesList LeftMessagesList -> AndMessagesList | OrMessagesList | Message AndMessagesList -> Message ``&'' AndMessagesList | Message OrMessagesList -> Message ``|'' OrMessagesList | Message RightMessagesList -> Message ``;'' RightMessagesList | Message ``//'' RightMessagesList | Message
Operator priority rules are the following : & >> | and ; >> // (parenthesis allow priority enforcement). Left messages correspond to the noti cation of received messages, and right messages express the corresponding actions. In the present state, we have introduced two operators for each part. & expresses that all the messages must be arrived, and | that just one message has to be arrived before reacting1 . According to the speci cation described in sections 1.1 and 1.2, the model allows reactions to be sequenced (operator ;) or paralleled (operator //). The sequential reaction a to a received message m is to execute m and then to send the message a ( m -> m ; a) or to ask for the execution of the message a and then to execute m ( m -> a ; m). At present, we have implemented this operator in a synchronous way, expecting the end of the execution of the message before the ;. The parallelization implies an asynchronous reactivity (operator //). Following the same syntax, a parallel reaction a to a message m will be written in the rule: m -> m // a. The reaction a and the execution of m are not ordered.
2.2 Modeling with ICMs
The behavior of chopsticks and philosophers are simpli ed to their own behavior. Chopsticks have a semaphore behavior (free/put and not free/get). The philosophers are either thinking or eating. 1 The operator | is equivalent to two rules with the same right side.
2
Our solution is based on two ICMs : the forEating manager which manages the communication between a philosopher and two chopsticks and the forSharingARessource manager that manages the shared chopsticks to avoid deadlocks. This ICM is used to manage interactions between two forEating managers (see Figure 1). for Eating1 Chop stick2
Phi1
Interaction and Communication model
forSharingARessource Phi2 Chop stick1
shared ressource
forEating2 Chop stick3
Figure 1: Modeling of dining philosophers : focus on two philosophers Let us see more precisely the ICMs of our example. First of all, let us express the communications between a philosopher and the left and right chopsticks. Theses communications are part of the following ICM. forEating(Phi,LeftChopstick,RightChopstick) ...... thinking(Phi) -> thinking(Phi); (get(LeftChopstick);add(SharedC,LeftChopstick) // get(RightChopstick);add(SharedC,RightChopstick)) ; eating(Phi,LeftChopstick,RightChopstick) eating(Phi) -> eating(Phi,LeftChopstick,RightChopstick); (put(LeftChopstick);retract(SharedC,LeftChopstick) // put(RightChopstick);retract(SharedC,RightChopstick)) ; thinking(Phi)
But, we are then facing a deadlock. So, we propose to use the following forSharingARessource ICM 2 . This ICM exploits the deactivation property of ICMs to avoid deadlocks The activate and deactivate methods are de ned on each ICM. When an ICM is deactivated, it stops the communication in a current context that has to be re-considered when it receives a re-activation message 3. forSharingARessource(ICM1, ICM2, Ressource) get(Ressource) -> if Emetteur=ICM1 then else end if; put(Ressource) -> if Emetteur=ICM1 then else end if;
deactivate(ICM2) deactivate(ICM1) activate(ICM2) activate(ICM1)
Having de ned the ICMs, we can use them to coordinate the philosophers and the chopsticks. We then declare the following interactions4 . foreating1 := forEating(phi1,chopstick1,chopstick2) foreating2 := forEating(phi2,chopstick2,chopstick3)..... forSharingARessource(foreating1,foreating2,chopstick2)
2 The syntax, for this ICM is in fact a little more complex, using the notation for the list; several ICM can be implied in such an ICM. 3 The SharedC variable in a forEating ICM is used to be able to free the chopsticks when a forEating ICM is deactivated. 4 The forSharingARessource should probably be automatically created.
3
2.3 Integration of ICM in object oriented languages : discussion
We propose to design ICM in an object oriented language by the de nition of a minimal but sucient meta object protocol. Di erent meta object protocols have been proposed in litterature [McA95, BFC+ 96, CM93]. In a non-distributed approach for interaction like dependencies between objects, we only deal with the received messages [DFP95]. A meta object protocol is proposed by Chiba with Open C++ [CM93, Chi93] to integrate Remote Procedure Call and broadcasting in term of distribution metaclasses. The importance of the knowledge of the message sender is shown by Chiba. In a distributed approach, it is useful also to propose a meta object protocol composed of the sent and arrived behavior ; the distinction between the message sending and receipt allows to control the network transfer and to detect failure: a message which is sent must be received and sending messages must eventually be reordered at the reception. It will be important to associate a time-out to decide if a message is lost and has to be re-sent. Note that if the interaction and communication models are fully exploited, only ICM objects are able to send messages to others objects. The meta object protocol of ICM management is not actually validated. The model presented in this paper needs to implement some capabilities of the objects to be coordinated, such as the noti cation of the received messages to the ICMs, the capability to execute a message in a synchronous or an asynchronous way or to prepare for transactions. We are also working on the behavior of the ICMs to manage synchronous and asynchronous reactions (with acknowledge, in a blocking way), to allow transactional reactions and to manage atomicity and to automatically ensure shared resources management.
3 A distributed architecture
The architecture is based on a set of Interaction and Communication Managers, each ICM manages the interaction and the communication of a set of remote objects. Objects are dispatched on several sites. A possible architecture for the dining philosophers example is to localize each philosopher and its chopstick in a di erent site. Sk
Si
Phi2
Phi1 shared chopstick2
For−eating(P,LC,RC) 3
5/6
7
aknowledge(Get)
Get)
Chopstick3
ask(
send(Eat)
(Think)
RC Right Chopstick
P Philosopher
Sl
5/6
4
1 received
t)
Ge
k(
LC Left Chopstick
as
aknowledge(Get)
chopstick2
chopstick1
2
execute−with− response(Think)
forEating2
forEating1
Think
Think(P) −> Think(P) ; (Get(LC) // Get(RC)) ; Eat(P,LC,RC)
Figure 2: Architecture for the dining example The locality of the ICM components is not xed, it depends on the implementor of the manager. However, in order to minimize the network accesses, an object migrating technic should be used to enforce an optimized repartition. In the gure 2 forEating managers are localized on the site where the maximum of communicating objects are localized but the con guration problem is not resolved for the shared-chopstick2 (instance of the forSharingAressource manager). As in FLO[Duc95], we propose an object oriented architecture based on meta-object protocol. A message that occurs at an object x member of an interaction manager, is intercepted by the controller of x and addressed to the dependency manager. Let us see network trac between an ICM and communicating objects (see Figure 2). We suppose that an object and its meta-object are localized on the same site. The metaobject knows which managers are concerned by a message. When the meta-object intercepts a message (reception), it forwards the incoming message to the concerned ICMs if they exist, otherwise, the object execute directly the corresponding method. The ICM role is to ask for reaction from communicating objects and to manage ordering when needed. The ICM consists 4
of an automaton allowing such an ordering (see Appendix). When an ICM is created, the given communicating objects are registered in term of a name server that accesses remote objects. Some security should be associated with the ICM such as the authentication check of interacting objects and the replication to prevent failure cases of strategic ICMs. The network communication is managed transparently to the user. Synchronous and asynchronous communications are needed : ask to wait for a result or an ending message and send without waiting for a result.
4 Conclusion Several experimentations have already be done to validate our ideas. At the origin of this study is the FLO model. With FLO, objects can be linked in a synchronous way, in a monolithic platform[DFP95]. The implementation of synchronous ICM in Open C++ [HC97, Chi93] o ers a test platform for the communication aspects. This implementation is based on Open C++ meta classes allowing Remote Procedure Call communication. Actually this experimentation is limited to a bidirectional implementation of managers allowing only Client Server communication via RPC. This is not sucient and we are developping Corba metaclasses and extended models. The introduction of more complete interactive and communication models to LactE[PR93] allows the testing of concurrency problems. LactE is an actor language that integrates the asynchronous, synchronous and future message passing and that facilitates the rst prototyping. The implementation of the philosophers dining is a well adapted example to prove the interest of explicit ICMs. The experimentation has already shown some advantages of explicitly de ned semantics of interaction between remote objects (reuse, extensibility, lisibility...). We think that this work will allow us to prove or verify some communication properties. Each object keeps its own semantics (behavior, properties and internal automaton) and an ICM describes more precisely the inter-automata and communication. We think that we will be able to exploit the set of intra and inter automata to verify the correctness of the written code and also to determine failure or deadlock cases. When the prototyping step will be satisfactory the real integration of our ideas to an object oriented language (Open C++ or SmallTalk,...) will be initiated. The objective is to use this integration to implement groupware applications and to allow communication between objects in di erent programming languages.
5 Appendix : implicit automata An ICM can be viewed as an automaton (see Figures 3 and 4). This automaton is created by merging all the rules automata. An ICM automaton can be merged with the intra-automaton of each interacting object. The merging of inter and intra automata can be used to check coherence : a message does not exist in the current state of the object or a message is never called. Figure 3 is the result of the merging of the forEating inter-automaton (see Figure 4) and the philosopher intra-automaton (an automaton with two states : thinking and eating).
5
SR=()
else
acknowledge Put(RC)
acknowledge Put(RC)
SR=(LC)
RC
in
te va ti
va
SR
ac
Put(RC) acknowledge Put(LC)
In
A
ti
i ct
acknowledge Get(RC)
Inactivate
va
d(T
sen
te
Get(RC)
te
k
hin
SR=()
Get(LC)
acknowledge Get(LC) acknowledge Get(RC)
) ing
SR=(LC)
ac
execute−with−response (Thinking)
In
SR=()
SR=(RC)
Put(LC)
acknowledge Get(LC)
LC in SR Inactivate
else
g)
in
acknowledge Put(LC)
Put(LC)
Put(RC)
at
execute−with−response (Eating)
SR=(LC,RC)
E d(
n
se
SR=(RC)
Figure 3: Merged Automaton forEating ICM and philosopher intra-automaton
SR=() execute−with−response (Thinking)
SR=(LC)
Get(LC)
Get(RC)
acknowledge Get(LC) acknowledge Get(RC)
acknowledge Get(RC)
if(SR())
arrived(Thinking)
SR=(RC) acknowledge Get(LC) lse
e
g)
e)
in
at
at
iv
SR=()
t Ac
(
ge
SR=(LC,RC)
E d(
n
se
a ss
me
se
nd
(T
hi
message(Inactivate)
nk
in
SR=()
se
el acknowledge Put(LC) Put(RC)
SR
Put(LC)
SR=(LC)
SR=(RC) else Put(LC)
Put(RC)
acknowledge Put(LC)
execute−with−response (Eating)
Figure 4: Inter-Automaton for forEating ICM 6
acknowledge Put(RC)
LC in SR
in
acknowledge Put(RC)
RC
else
if(SR())
arrived(Eating)
g)
References
[BFC+ 96] F. Baude, N. Furmento, D. Caromel, R. Namyst, J.M. Geib, and J.F. Mhaut. C++// on top of PM2 via SCHOONER. In STRATAGEM'96, Sophia-Antipolis (France), Juillet 1996. [BG96a] J.P. Briot and R. Guerraoui. A Classi cation of Various Approaches for Object Based Parallel and Distributed Programming. Technical report, University of Tokyo and Ecole Ploytechnique Federale de Lausanne, 1996. [BG96b] J.P. Briot and R. Guerraoui. Objets pour la programmation parallele et repartie : interets, evolution et tendances. In TSI, June 1996. [Bos94] Jan Bosch. Relations as rst-class entities in layom. Not Yet Published. Available on http://www.pt.hk-r.se/ bosch, 1994. [Cas94] P. Casadessus. Conception et mise en oeuvre d'un noyau transactionnel dans un environnement parallele. These de doctorat, Universite de Paris 6, Novembre 1994. 172 pages. [Chi93] S. Chiba. Open C++ release 1.2 Programmer's guide. Technical report, Department of Science, university of Tokyo, 1993. [CM93] Shigeru Chiba and Takashi Masuda. Designing an extensible distributed language with a metalevel architecture. In European Conference on Object Oriented Programming (ECOOP), LNCS 707, pages 482{501, Kaiserslautern, July 1993. [Cor91] John R. Corbin. The Art of distributed applications : programming techniques for remote procedure calls. Sun technical reference library- Springer, 1991. [Cou87] J. Coutaz. The construction of user interfaces and the object paradigm. In ECOOP'87, European Conference on Object-Oriented Programming, pages 135{144, Paris, 1987. [DFP95] Stephane Ducasse, Mireille Fornarino, and Anne-Marie Pinna. A Re ective Model for First Class Relationships. In Proceedings of OOPSLA'95, pages 265{280, 1995. [Duc95] Stephane Ducasse. FLO: the Manual Reference. I3S, 1995. RR-95-05. [Fro94] Svend Frolund. Constraint-Based Synchronization of Distributed Activities. PhD thesis, University of Illinois at Urbana-Champaign, 1994. [Gra93] J. Gray, editor. Transaction processing : concepts and techniques. Morgan Kaufmann Publishers, San Francisco (California), 1993. 1070 pages. [GX92] Object Management Group and X/Open. The Common Object Request Broker : Architecture and Speci cation. Digital Corporation et HP Compagny and HyperDesk Corporation, 1992. [HBR+ 94] Ralph D. Hill, Tom Brinck, Steven L. Rohall, John F.Patterson, and Wayne Wilner. The Rendezvous Architecture and Language for Constructing Multi-User Applications. ACM Transactions on Computer-Human Interaction, 1(2), 1994. [HC97] T. Haquet and B. Cazaux. Flo++ dependances entre objets distants. Rapport de projet de n d'etude, ESSI, 1997. [HO93] W. Harrison and H. Ossher. Subject-oriented programming (A critique of pure objects). In OOPSLA'93, pages 411{428, Washington DC, October 1993. ACM SIGPLAN Notices Vol.28, n. 10. [Hol92] Ian M. Holland. Specifying reusable components using Contracts. In O. Lehrmann Madsen, editor, Proceedings of ECOOP'92, volume 615 of Lecture Notes in Computer Science, pages 287{308. Springer-Verlag, 1992. [Kar94] A. Karsenty. GroupDesign : un collecticiel synchrone pour l'edition partagee de documents. PhD thesis, Universite de PARIS XI, ORSAY, February 1994. [McA95] Je McA er. Meta Level Programming With Coda. In Springer Verlag, editor, European Conference on Object Oriented Programming, volume 952 of Oltho LNCS, pages 190{214, August 1995. [Mul89] Sape Mullender. Distributed systems. ACM press, Frontier series, 1989. [NGGS93] David Notkin, David Garlan, William G. Griswold, and Kevin Sullivan. Adding Implicit Invocation to Languages: Three Approaches. In Shojiro Nishio and Akinori Yonezawa, editors, First International Symposium on Object Technologies, volume 742 of Lecture Notes in Computer Science. ACM, October 1993. [Pin93] Xavier Pintado. Gluons: a support for software component cooperation. In Shojiro Nishio and Akinori Yonezawa, editors, First International Symposium on Object Technologies, volume 742 of Lecture Notes in Computer Science, pages 43{60, 1993. [PR93] Jean-Christophe Pazzaglia and Jean-Pierre Regourd. Galaxy, a distributed AI tool. In Arti cial Intelligence, Thirteenth International Conference, pages 579{588, Hudders eld, May 1993.
7
[RP95a]
R.Bastide and Ph. Palanque. Formal speci cation and veri cation of CSCW using the interactive cooperative object formalism. In Human-Computer Interaction (HCI'95), pages 213{232, Hudders eld, 27-29 August 1995. [RP95b] R.Bastide and Ph. Palanque. A petri net based environment for the design of event-driven interfaces. In 16th International Conference on Application and theory of Petri Nets (ATPN'95), Torino, 20-22 June 1995. [Rum92] J. Rumbaugh. Horsing around with associations. Journal of Object Oriented Programming, 4(6):20{29, February 1992. [SN92] K.J. Sullivan and D. Notkin. Reconciling environment integration and software evolution. Transactions on Software Engineering and Methodology, 1(3):228{268, July 1992. [SUN96] SUN. Remote Method Invocation Tutorial. Site web, SUN, 1996. http://www.javasoft.com:80/products/jdk/1.1/docs/guide/rmi/index.html.
8
