Compile Time and Runtime Reflection for Dynamic Evaluation of Messages : Application to Interactions between Remote Objects

Transcription

1 Compile Time and Runtime Reflection for Dynamic Evaluation of Messages : Application to Interactions between Remote Objects Laurent Berger I3S - CNRS UPRESA Bât ESSI 930 Rte des Colles - BP Sophia-Antipolis Cedex, France +33(0) berger@essi.fr ABSTRACT This paper shows how compile time and runtime reflection and object-oriented programming can be used to make the implementation of the problems posed by the dynamic evaluation of messages easier. It describes these problems through interactions, i.e. inter object communications, in a distributed architecture defined in C++ and CORBA. The proposed solutions are based on design patterns with the compile time and runtime reflection through the open compiler Open C++. Keywords meta-object protocol, compile time and runtime reflection, design patterns 1 INTRODUCTION When the behavior of an object dynamically varies according to the execution and in a way independent of the object state, we are leading to dynamically evaluate the messages. In interpreted, untyped and not distributed environments some papers [6, 14, 13] have proposed severals mechanisms for the dynamic evaluation of messages. We were confronted with this same problem of dynamic evaluation of messages when we wished to allow the definition and the management of interactions, i.e. any inter object communication, between objects in a distributed architecture defined with the C++ language [28] and CORBA [23]. The step to allow this dynamic evaluation of messages consisted in the use of compile time and runtime reflection with Open C++ [10]. The compile time reflection generates mechanisms used at runtime to allows dynamic evaluation of messages in C++, such as the sending message catching mechanism, the type parameters reflection and the dynamic call of reflection method. For each of these mechanisms, which are part of our runtime meta-object, we have proposed a solution based upon design patterns. We have defined a compile time meta-object protocol, which is presented in this paper, using the generalpurpose compile time reflection provided by Open C++ to generate a runtime meta-object specialized in the interaction management. This paper is organized as follows. The next section shows the architectural framework used and the language which allows the description of interactions. Section 3 describes the proposed solutions in term of compile time reflection of encountered problems, i.e. the compile time meta-object we have defined in Open C++. Section 4 shows the architecture of our runtime meta-object. 2 ARCHITECTURAL FRAMEWORK FOR INTERACTION MANAGEMENT The Figure 1 shows the architectural framework, using CORBA for the network communication management between different sites 1 of the application, used for our interaction development. CORBA allows that different sites, which compose an application, to be developed in different object-oriented languages and on different platforms, i.e. in a heterogeneous environment. We can see in this figure that each site has a meta-level available at runtime to manage the dynamical aspects of interactions. A site meta level Global Server Object with interactions Object without interaction Figure 1: System overview Network (CORBA ORB) 2.1 Interaction description Language The properties of our interaction approach is, through a language named an Aspect Language [18], to specify the interactions outside the objects using only their interface. This specification is also independent of the physical locality of 1 A site contains one or more application objects.

2 the interacting objects. The methods, not polluted by the interaction management, describes the intrinsic behavior of objects without taking into account future participations of objects in interactions. An example of a comparison of shared diaries in Smalltalk [2], a version not using the interactions and a version using them, can be found in [4]. The interaction description is implemented in the form of interaction rules with our language. An interaction rule describes, for a given message 2, the partially ordered set corresponding to its execution. This description needs a sending message operator (denoted.), two reactive operators (one used for synchronous sending, denoted ;, the other used for asynchronous sending, denoted //), and a conditional operator. The language allows to specify the states and the properties (for example the cardinality [22, 20, 24] or the delayed execution) of interactions. Here is an example of a simple interaction rule : Student.takeExamen! Prof.writeSubjet ; Student.takeExamen ; ( Student.waitNote // Student.goToBeach // Prof.correctCopies) ; Student.obtainNote 2.2 Related works on interactions Some works about the interactions have been already implemented in not distributed, not concurrent, untyped and not compiled environments [6, 14]. Researchs concerning interactions in distributed environments [16] or concurrent environments [19, 1, 5] have also been taken, but without inclusion of all interaction properties described above, that is to say the interaction dynamic instantiation, their description outside the interacting objects and an independence towards the physical locality of objects. In the same way, the researchs on distributed architectures [17, 11, 27, 8, 29, 25, 9], of which the goal is to make easier the development of distributed applications, does not integrate the interaction support. CORBA provides to the user, through the Event Service [21] and the Relationship Service [22], mechanisms to help him to manage, by means of notifications, the interactions taking them into account at the object class level, which is quite different to our approach. 2.3 A name server for a decentralized architecture As we can show in the Figure 1, the architecture framework is composed of several sites and a global server which is, in fact, a name server. It role is only to dispose the list of all the available sites in the system and to notify these sites when the system is modified, i.e. when a site is added or removed. So the global server is not used when two sites communicate among themselves. In this way the architecture used is a decentralized architecture. This decentralized architecture allows to avoid, on the one hand, the bottleneck at the global server level and, on the 2 A message is the pair object in which is addressed the message and signature of the method. other hand, a complete blocking of the system, compared to a similar centralized architecture, i.e. without a fault tolerant system, when a network error occurs on the global server. 3 COMPILE TIME REFLECTION Being in a strongly typed environment we must, by respecting the typing rules set by the language (C++ in our case), manage the dynamical aspects of the interactions. The interactions modify the sending message semantic which requires consequently the implementation of a sending message catching mechanism to ensure the correct execution of interactions when an interacting message is triggered. This execution implies the execution of messages presented in the interaction rules. In a compiled and strongly typed environment several problems arise to allow the execution of a message about which we not have at compile time any accurate information at our disposal. At first the problem of parameter passing with the respect of the strong typing set by the language arises. After that the problem of the method call itself arises because, by the compiled approach, it is impossible to ask a dynamic eval of the message as we can do it in an interpreted environment. The meta-object available at compile time, with the use of Open C++, allows implementation of this message catching mechanism and the definition of meta-information for the dynamic evaluation of messages. We use a compile time reflection in this case to reduce the runtime meta-object embedded in the program and to speed up performance of the execution. This compile time reflection provides hooks to transform, during the compilation, specific expressions and declarations in the program using a meta-object that is part of the compiler. We can show this compile time meta-object as a set of macro systems, but with more semantic information than true macro systems have. 3.1 Sending message catching When at least one interaction rule is associated with a message, the sending message semantic for this message is modified because this or these rules are executed instead of the message itself 3. Therefore we need a sending message catching mechanism to modify the sending message semantic. The C++ language does not provide any sending message catching mechanism, neither at compile time nor at runtime. Some catching mechanisms exist in open object-oriented languages [12]. We have chosen to use the method wrapper [7]. This method adds, for each method in an object, a new method with the same signature (only the method name changes) which will be called instead of the original method and which contains the new sending message semantics (point 1 of the Figure 2). To solve this sending message catching problem, we have used Open C However this message can be executed if it is part of the interaction rule. 4 We refer to the version 2 of Open C++, so the meta-object exists only at compile time.

3 The message catching mechanism must be implemented both for local objects and for remote objects. It is then necessary to modify the sending message semantic to take into account this locality. CORBA uses the, with the inheritance and virtual methods, to mask the object physical locality. Unfortunately, this technology cannot be applied when the components already exist. The object physical locality occultation requires that the proposed solution allows to dispose of metamorph objects. Our architecture dissociates consequently the interface and the object implementation using the Bridge/Body Design Pattern. The implementation of this design pattern is shows by the point 2 of the Figure 2. interface sending message 1 functional stub 2 proxy 3.2 Solution of typing problem for parameter passing When a message is caught by the catching mechanism, its parameters must be able, in particular, to be transmitted to interaction rules when they must be executed and to any other mechanism taking part in the interaction rule execution. To avoid the parameter typing problem a list of any type parameters must be transmitted to the various mechanisms which deal with interaction rule execution. This can be achieved with the and mechanisms available in C++. Indeed, the allows the parameter reflection whereas the will make all these reflected parameters compatible at the typing level by showing that they have a common type. This is achieved by the use of the Strategy Design Pattern for the and by the use of the inheritance for. This reflection can imply that an important number of objects, not defined by the application itself, exist at runtime. However, to limit the number of instances of these reflected parameters at runtime, this reflection is realized only when it is a necessity and the reflected parameter instances are reused as soon as possible. method wrapper (sending message catching mechanism) original message class definition public private interfaces meta compiler Figure 2: Overview of the sending message catching mechanism meta compiler 1 {z } types of interacting message parameters 2 We can note that the definition of the primary class becomes the functional class and that it disposes of the sending message catching mechanism and that two new classes have been generated. The proxy class manages calls to remote objects whereas the stub class redirects the received messages either to the object, if it is local, or to its proxy, if it is remote, (the stub class is then the handle to access to the object) at the time of the interaction execution on the functional object. The proxy mechanism implements the Surrogate Design Pattern and sends requests to the site managing the remote object (i.e. the site to which the object is local) asking it a message execution on this object. This implies that each site has at its disposal a request server which will execute messages on the object site on the other sites behalf as part of the interaction execution. The role of this request server is then to treat the message execution requests for an object, local to the server, provided from other sites. The message execution by the request server is based upon the message execution on a local object. The request server must then determine the method name to execute, the object name on which the execution must be applied, and the list of parameters to transmit at the method call time. Once these information are available, it executes the message as it is described in the following two paragraphs. Figure 3: Message execution on a local object mechanism : parameters management The implementation needs that all the possible parameter types are identified by the compilation process in order to generate the required classes to allow their instantiation at runtime. This implies the use of an open compiler, Open C++ in our case, to determine, on one hand, the types to encapsulate (step 1 of the Figure 3) and, on other hand, to generate the classes (step 2 of the Figure 3). The instantiation use the Virtual Constructor Design Pattern. 3.3 Resolution of the dynamic method call execution problem in a compiled environment When an interacting message is caught, and once the merging of interaction rules to execute finished, we must execute each message appearing in the merged rule [3]. This execution implies the call of methods associated to messages. In fact the method wrappers are called instead of the original methods to ensure the execution of interaction rules associated with these messages but, to avoid cyclic calls, the original method for the interacting message is called. Being in a compiled environment we cannot ask the evaluation of an expression containing the call of methods, as this

4 can be made in an interpreted environment. A solution consists in defining a structure with the compiled method code. However this solution does not satisfy the imposed typing conditions. The, and then the method and call reflection, allows to solve this typing problem. The is also used to make each reflected method compatible with the others at the typing level. The implementation of this reflection is based upon the Command Design Pattern and requires knowledge at the compile time of all methods that could be executed within an interaction rule to generate the reflected method code. In this solution the reflection can also imply that objects, not defined by the application, are present at runtime. However, their number is limited in the way that the reflection was implemented over the classes and not over the class instances. 4 RUNTIME REFLECTION The meta-object available at runtime, showed in the Figure 4, allows an application to manage interactions in C++ and CORBA. The implementation of this meta-object is based upon a set of three independent units in a relation with a fourth unit, named Catching Message Unit. The data transmitted between different units form a set of interaction rules. When a message is caught by the Catching Message Unit,this unit receives from the Selection Unit the list of interaction rules which must be executed instead of the caught message. If this list is empty, signifying that no interaction is available for this message, then the original message is executed, otherwise the interaction list is sent to the Merging Unit which merges the interactions and the result of which, an interaction rule, is sent to the Execution Unit to be executed. This last unit is itself composed of two sub-units. These sub-units manage the execution of a message on a local object for the one and on a remote object for the other one. Meta-object Execution Unit be added either by the addition of a sub unit in the Execution Unit or by the addition of a meta-object protocol upon the Execution Unit. The addition of a sub-unit implies the use of a security or fault-tolerant library. A secure and fault-tolerant library using CORBA can be found in [26]. In the case of the addition of a meta-object protocol the Execution Unit is seen as the base-level program. An example of meta-object protocol, using Open C++ and CORBA, for fault-tolerant can be found in [15]. 5 CONCLUSION We have designed and implemented an architecture allowing the expression of interactions in a compiled, strongly typed, concurrent and distributed environment while maintaining the main properties of interactions, i.e. dynamic instantiation of interactions and the interaction definition only through the interface of objects which will interact in an independent way of the objects physical locality. We have been confronted to the requisite dynamic evaluation of messages. To solve this problem we have introduced a meta-object at the compile time by the use of Open C++, but also defined a runtime metaobject in charge of the interaction dynamic management at runtime. So we use the general-purpose compile time metaobject provided by Open C++ to implement a runtime metaobject specialized for interaction management. The compile time meta-object executes meta computation as much as possible by generating code in the base-level program and linking the base-level objects with their runtime meta-object. The table 1 summaries problems and solutions described in this section. Mechanism Solutions Design Patterns Message Catching Method Wrapper Surrogate - Bridge/Body Parameter Passing Strategy Dynamic Method Call Command Table 1: Compile Time Reflection Mechanism Summary Selection Unit Catching Message Unit Merging Unit Communication between 2 j meta-object units Object Figure 4: Overview of the meta-object available at runtime managing of the interactions The architecture provided by the runtime meta-object makes easier semantic changes in a unit and addition of new behaviors. For example, security and fault-tolerant properties can Throughout its modular conception, in the form of units, the runtime meta-object makes, on one hand, modification of the already available unit semantics easier and, on other hand, the addition of new behaviors, such as the security management, when an interaction is executed at inter object communication level (for example to ensure that an object communicates only with an object that interacts with it) and at network communication level (data encryption transferred by network or fault tolerant communication). It is also possible to combine different runtime meta-objects in order to manage other concurrent or distributed aspects. To preserve the incremental and modular compilation as it exists in C++ we have been constrained to reflect each method defined in a class on which at least one instance can be part of an interaction. The reflection of the methods which are effectively part of an interaction only is an important optimization because this can reduce significantly the number of instan-

5 tiated objects by our architecture. This implies however to know at compile time the class interacting interface, which can be realized by an extension of the C++ syntax, with the use of Open C++, or by the definition of a specialized interface description language (IDL), as in the case of CORBA. References [1] G. Agha and S. Frølund. A Language Framework for Multi-Object Coordination. In Proceedings of ECOOP 93, pages , [2] K. Beck. Smalltalk, Best Practice Patterns. Prentice Hall, ISBN x. [3] L. Berger. Définition et Implémentation d un Modèle de Coordination entre Objets Distants. Rapport de recherche I3S, RR-97-24, [4] L. Berger, A-M. Dery, and M. Fornarino. Interactions between objects : an aspect of object-oriented languages. In ECOOP 98 Workshop on Aspect-Oriented Programming, July [5] S. Bijnens, W. Joosen, and P. Verbaeten. Language Constructs for Coordination in an Agent Space, [6] J. Bosch. Relations as First-Class Entities in LAYOM, Available on [7] J. Brant. Method Wrappers. Smalltalk goody, Applications/MethodWrappers.html. [8] V. Cahill. An Overview of the Tigger Object-Support Operating System Framework. In SOFSEM 96: Theory and Practice of Informatics, volume 1175 of LNCS, pages 34 55, November [9] D. Caromel and J. Vayssière. A Java Framework foe Seamless Sequential, Multi-Threaded, and Distributed Programming. In ACM Workshop Java for High- Performance Network Computing, [10] S. Chiba. A Metaobject Protocol for C++. In the ACM Conference on OOPSLA, pages , October [11] S. Chiba and T. Masuda. Designing an Extensible Distributed Language with a Meta-Level Architecture. In Proceedings of ECOOP 93, pages , [12] S. Ducasse. Des Techniques de Contrôle de l Envoi de Messages en Smalltalk. In L objet, numéro spécial Smalltalk en France : état de l art et de la pratique. Hermes édition, [13] S. Ducasse. Intégration Réflexive de Dépendances dans un Modèle à Classes. Thèse de doctorat, Université de Nice-Sophia Antipolis, January [14] S. Ducasse, M. Fornarino, and A-M. Pinna. A Reflective Model for First Class Relationships. In Proceedings of OOPSLA 95, pages , [15] J.C. Fabre and T. Pérennou. A Metaobject Architecture for Fault Tolerant Distributed Systems : the Friends Approach. In Special Issue on Dependability of Computing Systems, pages IEEE Transactions on Computers, January [16] S. Frølund. Constraint-Based Synchronization of Distributed Activities. PhD thesis, University of Illinois at Urbana-Champaign, [17] C. Horn and V. Cahill. Supporting Distributed Application in the Amadeus Environment. In Computer Communications, volume 14, pages , July [18] G. Kiczales, J. Lamping, A Mendhekar, C. Maeda, C lopes, J-M. Loingtier, and J. Irwin. Aspect-Oriented Programming. In Proceeding of ECOOP 97, volume 1241 of LNCS, pages , June [19] C. Laffra and J. Van Den Bos. PROCOL, A Concurrent Object-Oriented Language with Protocols Delegation and Constraints. Acta Informatica, 28: , [20] P.A. Muller. Modélisation objet avec UML. Eyrolles, [21] Event Service Specification, Part 4 of CorbaServices Doc. Number , library/corbserv.htm. [22] Relationship Service Specification, Part 9 of CorbaServices Doc. Number , omg.org/library/corbserv.htm. [23] The common Object Request Broker : Architecture and Specifications, Object Management Group and X/Open, [24] Objectory Process 4.1 : Your UML Process, Rational Corp., [25] D. C. Schmidt. Applying Patterns and Frameworks to Develop Object-Oriented Communication Software, volume 1 of Handbook of Programming Languages. MacMillan Computer Publishing, [26] C. Silva and L. Rodrigues. A Fault-Tolerant Secure CORBA Store using Fragmentation-Redundancy- Scattering. In ECOOP 98 Workshop, July [27] R.J. Stroud. Transparency and Reflection in Distributed Systems. In ACM Operating System Review, volume22, pages , April [28] B. Stroustrup. The C++ Programming Language. Addison-Wesley, 2 edition, [29] C. Videira-Lopes and G. Kiczales. D : A Language Framework for Distributed Programming. Thesis proposal, Northeastern University, College of Computer Science, February 1997.