m() super.m (execution path) extension f n() f.m n() o.m extension e m() n() m() extensible object o composite object (o < e < f)

Transcription

1 Reective implementation of non-functional properts with the JavaPod component platform Eric Bruneton, Michel Riveill SIRAC Project (INPG-UJF-INRIA) INRIA, 655 av. de l'europe, Montbonnot Saint-Martin, France March 23, 2000 Abstract This position paper presents an extensible, reective middleware platform whose main goal is to separate, compose and associate with applications several non-functional properts. It presents then three non-functional properts we implemented on top of this platform, and the lessons learned from these experiments. 1 Introduction Middleware platforms like CORBA oer to applications several non-functional properts (transactions, persistence: : :) but the application programmer must use them explicitly. On the contrary, the Enterprise Java Beans (EJB) platform [9], by using a kind of reective [5] mechanism, allows for a complete separation of the functional and nonfunctional aspects. This approach is promising but is still limited: in particular, the set of provided non-functional properts is small and not extensible. Our main goal is therefore to design, implement and experiment with the JavaPod [1] platform, a reective middleware platform that should allow (a) to program separately functional aspects and non-functional aspects, (b) to program separately each non-functional aspect, and (c) to associate with an application several non-functional aspects, which should work together properly. The JavaPod platform should also be modular and extensible, to in collaboration with France Telecom, Rue du General Leclerc, Issy Moulineaux, France be able to oer an a priori unlimited set of nonfunctional aspects, and so that it can be tailored to various applications and execution environments. Finally, our platform should be able to oer a very general distributed programming model. In particular, this model should not be limited to the clnt, publish-subscribe or stream models. In order to achve these goals, we have dened an object composition model (section 2) that is used to separate and compose non-functional aspects, but also to obtain a modular platform, built on top of a small kernel. The architecture of this kernel (section 3) has been choosen to support any distributed programming model. Section 4 presents some connectors and non-functional aspects that have been implemented on top of our kernel. Section 5 presents the lessons learned from these experiments. 2 Object Composition Model Our object composition model is dened as follows. A composite object is a totally ordered set of atomic (non composite) objects. The smallest atomic object is called an extensible object. The others are called extensions. A composite object contains exactly one extensible object, which cannot be removed or replaced, and zero or more extensions, which can be added or removed dynamically. A composite object is an object, whose semantics is dened as follows. Its internal state (resp. set of methods) is the union of the internal states (resp. set of methods) of its members. Internal states are supposed to be accessible only through methods. A call to a method m on a composite object is exe- 1

2 cuted by the greatest member in which m is dened (an exception is returned if there is no such member). In extensions, a special form of method call is available, noted super.m. A call to super.m in an extension e is executed by the greatest member in which m is dened, and that is strictly smaller than e. The gure below illustrates these denitions. o.m f.m super.m (execution path) extension f extension e extensible object o composite object (o < e < f) This model has been implemented in a new language called ejava. This language is a superset of Java, and has exactly the same syntax as Java. It also has the same semantics, except for objects that are instances of a subclass of the predened classes ExtensibleObject and Extension (only these objects can be members of a composite object). The gure below shows a very simple ejava program. public final class C extends ExtensibleObject { private int i; public int get () { return i; public void set (int i) { this.i = i; public final class D extends Extension { public int get () { System.out.println("get called"); return super.get(); public void reset () { ((C)this).set(0); C c = new C(0); c.set(3); // prints nothing // ((D)c).reset(); // throws an exception c.setextensions(new Extension[] {new D()); c.get(); // prints "get called" ((D)c).reset(); // ok This example shows that ejava and Java have the same syntax, but not the same semantics: the call to super in the D class, and the explicit casts to C and D would not be valid in Java. This example also shows that extensions can be added dynamically, and that extensions can override and add new methods in a composite object. 3 Component Model The JavaPod kernel denes the, container, component and connector concepts: A provides an execution environment (adress space, threads, protocols: : :) for containers. It is located in one host. A container is a system object corresponding to exactly one component. It contains information and behaviors that are common to a whole component (component adress, persistance model: : :). A component is an arbitrary graph of objects. A connector is a set of related s and etons that can belong to several containers, and that can implement several interfaces. For example, a publish-subscribe connector can contain one publisher, several receiver etons implementing the same functional interface, and several s implementing a control interface used to subscribe and unsubscribe. A allows a component to call some methods, declared in the 's interface, but externally implemented. Symetrically, a eton allows some component's methods, declared in the eton's interface, to be called externally. A connector reference idents and describes a unique connector. For example, a reference to a clnt- connector idents the eton, and describes the ejava extensions to be used to instantiate a new clnt for this connector. The JavaPod platform does not use component references (as in CORBA), nor interface references (as in ODP [8]), but only connector references. The JavaPod platform kernel is implemented by a few ejava classes and interfaces, corresponding to the previous concepts. This kernel only denes a framework: it does not provide any implementation (except a generic, on the y compiler) and must therefore be completed with ejava extensions in order to be usable. For example, the s generated by the compiler are extensible objects that do only one thing: they reify calls to the 's interface methods, and pass them to a 2

3 generic method declared (but not implemented) in the Stub class. This method must be overriden by ejava extensions in order to obtain usefull s. The gure below illustrates the previous concepts and their relations: component connector eton container 4 JavaPod Extensions This section shows how we used our composition model to extend the kernel in order to provide several types of connector (clnt- and stream) and several easily composable non-functional properts (mobility, replication and protection by capabilits). The clnt- connector is implemented by several extension layers. The transport protocol (stp) is a extension to messages between s. The gate transport protocol () uses stp to messages between gates (i.e. s and etons). The layer uses in each an extension to store a mapping between container IDs and containers. It also uses an extension per container to store a container ID and a mapping between gate IDs and gates, and an extension per gate to store the gate ID. The - () gate extension allows to make conversions between connector references (that can be sent over a network) and s and etons (that can be used by a component). Finally, the clnt- protocol () denes a gate extension, and a symetrical clnt gate extension which overrides the 's generic method by using the and extensions. clnt a connector (container extensions not shown) Stream connectors use specic gate extensions. These extensions stream data in several packets, by using extensions. They also implement a ow control algorithm which uses emitter and receiver buers. isp isp an input stream connector The m layer is a mobile version of the layer wich allows mobile components and works as follows. Each message is sent to the last known location of the destination gate. If this gate is not found, the message is sent to a centralized localization, which then forwards the message to the actual gate location, and informs the er of the new gate location. The m layer is used to provide mobile components, but is not sucnt. Indeed, a container extension is needed to actually migrate a component (along with its container and all its gates). This extension communicates with the localization during a migration, to inform it of the new component location. This extension must also wait, before a migration, for each thread that is currently executing in the component to stop. For this, it uses an exe container extension that keeps track of all threads executing in a component (this extension is also used by the layer to launch threads for incoming requests). A replicated component [4] is always accessed locally: before doing a remote method call on a replicated component, a local replica of this component is obtained rst. The call is then made on this replica. The replicas consistency is managed by a distributed consistency protocol, implemented by \system" components 1 communicating through remote method calls. crsp l a connector for a replicated component For replicated component clnts, a specic extension (called crsp), placed on top of the normal extension, overrides the method in order to obtain a local replica before doing the 1 so called because they provide system services, like CORBA object services. 3

4 actual call (by calling super.). This specic extension uses the previous system components to get the local replica. Another extension (called l) mods the normal extension, in order to always messages to the local site (i.e. to the local replica, and not to the original component). Component protection by hidden software capabilits (see [3] for details) can be implemented by using lters between a clnt and a. A clnt lter essentially sets the access rights the clnt wish to give on the objects it s. For this, a clnt lter installs lters on each ed object. A lter essentially checks that received method calls are eectively authorized. C O filter clnt filter filter S method invocation ed object In a distributed context, these lters are not suf- cnt: a random secret number representing the actual capability, and known only by the and its clnts, must be used also. This number must be encrypted when sent over the network. In our implementation, clnt and lters are represented by special extensions, called hsc. The c layer is used on top of the or m layer to provide encrypted communications. This layer uses an extension per container to associate with each container an RSA key pair. It also uses gate extensions to encrypt messages before ing them with the layer, and to decrypt them before passing them to upper layers. hsc c hsc c a connector for a protected component These three non-functional aspects (mobility, replication and protection) can be easily composed, by judiciously mixing some of the previous extensions. For example, we can use mobility with clnt and stream connectors, combine mobility and protection, or compose protection and replication. 5 Discussion As shown in the previous section, our composition model can eectively be used to separate nonfunctional aspects from each other and from functional code, and to compose several non-functional aspects. The previous section's examples show kinds of protocol stacks. Our model can indeed be used to simulate protocol stacks, but is in fact much more exible. For example, container extensions also make use of our model, but not in a \protocol stack" way. Our model is also more exible than class inheritance (class composition requires one class per combination: for 3 optional aspects, 8 = 2 3 classes are necessary). It is also more exible than object composition through delegation (method overriding can be simulated through delegation but not in a practical way). Our composition model could be implemented with a meta-object tower, but this would be less natural, and less ecnt (in our implementation, a call is red only once, and the target member is found in one step, by using method tables). Our model can also be used to partition the meta-level into \meta-spaces" (e.g. marshalling, invocation: : :), but does not impose a xed set of meta-spaces. Finally, it is easy to dene a basic protection mechanism, by associating with each extension class a set of permissions to or override specic methods. However, our composition model is a only tool: although powerful, it is not sucnt to ensure that the proposed extensions can be composed easily. For this, the main problem to solve is to nd the right extensions granularity and interfaces. For example, we could have implemented the clnt- connector with only one extension, instead of three. But, in this case, it would have been impossible to reuse this extension in a clnt- connector for a mobile, replicated or protected component. We have implemented, until now, three nonfunctional properts. However, our architecture is extensible and allows us to oer more nonfunctional properts to application. This possibility brings open questions: will our existing ex- 4

5 tensions be reusable and composable with future extensions, or will we need to modify their granularity and interfaces? In the latter case, will we progressively converge toward \good" interfaces? In any case, our model will not solve by itself problems that are due to non-functional aspects inter-dependencs. For example, although mobility and clnt- model seem \orthognal", they must be coordinated (through the exe extension), since a component in which threads are running can not move. Similarly, protection and replication mecanisms implicitly require a clnt- model and, therefore, can not be composed with stream connectors. Unfortunately, these kinds of problems will become harder to solve with more nonfunctional aspects. Because of these problems, we think that extensions must be designed and implemented by middleware \experts", and not by application programmers. In fact, this separation of roles was a motivation to build a platform that allows to separate functional and non-functional code. Our rst experiments show that remote method calls are as ecnt with our clnt- connectors as with Java RMI. This means that the overhead introduced by our composition model is small, compared to message transmission delays. However, our model introduces a non negligible space overhead: 3Ko are needed to serialize a container with an empty component, two etons and a total of 15 extensions. Small components (like EJB beans) must therefore be avoided. 6 Conclusion In order to build a middleware platform that, like the EJB platform, allows to separate, compose and associate with applications several non-functional aspects (persistance, fault-tolerance: : :), we dened a new, reective 2 object composition model. We used this model to implement, on top of a small middleware platform kernel, two types of connector (clnt- and stream), and three nonfunctional properts (mobility, replication and protection by hidden capabilits). We were able to program each of these properts separately, and to compose them easily. 2 an ejava extension can be seen as a \typed" meta-object that res calls to a xed set of base level methods. We must now nd if our proposition \scales" well, i.e. if it can handle more non-functional properts. For this, it would be nice if we could nd design patterns or conception methodologs to implement non-functional properts as ejava extensions so that they can work together. But, for the moment, we don't know how to do this, or even if it's possible. References [1] E. Bruneton, and M. Riveill, \JavaPod : une plate-forme a composants adaptable et extensible", INRIA, research report 3850, January [2] F. Costa, G. Blair and G. Coulson, \Experiments with Reective Middleware", ECOOP'98 Reection Workshop, Brussels, Belgium, July [3] D. Hagimont, and L. Ismal, \A Protection Scheme for Mobile Agents on Java", Proc. Third ACM/IEEE Int. Conf on Mobile Computing and Networking (MobiCom'97), Budapest, September [4] D. Hagimont, and D. Louvegns, \Javanaise: Distributed Shared Objects for Internet Cooperative Applications", Middleware'98, The Lake District, England, September [5] G. Kiczales, J. des Rivres, and D.G. Bobrow, \The Art of the Metaobject Protocol", MIT Press, [6] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.-M. Loingtr, and J. Irwin, \Aspect-Ornted Programming", ECOOP'97, Jyvaskyla, Finland, June [7] J. McAer, \Meta-level architecture support for distributed objects", Proceedings of Reection'96, G. Kiczales (ed), 39-62, [8] \ODP Reference Model: Overvw", ITU-T ISO/IEC Recommendation X.901 International Standard , [9] \Enterprise Java Beans", 5