JavaPod: an Adaptable and Extensible Component ... - CiteSeerX

JavaPod: an Adaptable and Extensible Component Platform Eric Bruneton, Michel Riveill

SIRAC Project (INPG-UJF-INRIA) INRIA, 655 av. de l'Europe, 38330 Montbonnot Saint-Martin, France January 25, 2000

1 Introduction

atomic object is called an extensible object. The others are called extensions. A composite object contains at least an 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 de ned as follows. Its internal state (resp. set of methods) is the union of the internal state (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 executed by the greatest member in which m is de ned (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 de ned, and that is strictly smaller than e. The gure below illustrates these de nitions.

The goals and motivations of our work are those of the aspect-oriented programming model [2], applied to distributed applications. In other words, we want to be able: ( ) to program separately functional aspects and non functional aspects (distribution, persistance, fault-tolerance ), ( ) to program separately each non functional aspect, and ( ) to associate with an application several non functional aspects, which should work together properly (problem of aspect composition). Several works (like [4]) have shown that re exivity in a middleware platform can be used to achieve ( ). Enterprise Java Beans (EJB) is an example of an \industrial" platform that uses this technique (an EJB container is a kind of meta-object). But few experimental platforms explicitely address ( ) and ( ). On the contrary, our work focuses essentially on these two points. This position paper presents a new object composition model which can solve ( ) and can help to solve ( ) and ( ). Indeed, this model oers a pratical tool which can be used to compose separately programmed aspects, but does not de ne how to use it in pratice (that is to say, how to separate aspects from each other { especially if they are not independent { in such a way that they can be composed easily). a

:::

b

c

a

b

c

m()

a

b

n()

c

super.m (execution path)

extension f

f.m n() o.m

m() n()

extension e m()

extensible object o composite object (o < e < f)

This model has been implemented in a new langage called ejava. This langage 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 prede ned classes ExtensibleObject and Extension (only these objects can be members of a composite object).

2 Object Composition Model Our object composition model is de ned as follows. A composite object is a totally ordered set of atomic (non composite) objects. The smallest in collaboration with France Telecom, 38-40 Rue du General Leclerc, 92794 Issy Moulineaux, France 

1

3 Discussion

ber 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 de ne a basic protection mechanism, by associating with each extension class a set of permissions to invoke or override speci c methods.

The JavaPod platform [1] is in fact a middleware platform kernel, which only de nes an architecture. This architecture contains the following elements: stubs, skeletons, containers, servers, and connectors1 . This framework is implemented, in ejava, by 4 classes of extensible objects (one per architecture element) and a few other classes. It must be completed by extensions in order to obtain a usable platform. A JavaPod stub is a composite object. Its extensible object is completely generic, since it does only one thing: it rei es method calls and passes them to a generic invoke method, which does nothing by default, but can be \overridden" by extensions. The stub extensions can be programmed like a class hierarchy, but more exibly. For example, one can program an extension that de nes a framework of client-server stub, and that leaves some unimplemented methods: export, import, marshall, unmarshall Other extensions can then implement or override one or more of these methods. They can themselves introduce new methods, which can in turn be implemented or overridden by other extensions. This organisation can be used to compose several independant aspects, each one programmed in its own extension: monitoring, replication, speci c marshalling rules, protection by capacities Each extension only needs to override one or two of the previous methods, depending on its function, to add preor post-computations, or to completely rede ne them. In this context, our composition model is more

exible than class inheritance (class composition requires one class per combination: for 3 optional aspects, 8 = 23 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 can be implemented with a meta-object tower, but this would be less natural, and less ecient (in our implementation, a call is rei ed only once, and the target mem-

:::

4 Current status & future work Our object composition model is only a tool to help solve ( ) and ( ). We must now nd how to use it correctly, nd its limitations Our approach to solve these problems is pragmatic: in the \restricted" area of middleware platform, we try, by successive approximations, to build a platform that can oer to applications a rich set of easily con gurable, easily composable non functional properties (various connectors, mobility, protection, replication, transactions ). This task is similar to the design of a usefull, reusable class library, but is more complicated due to the nature of the considered domain. We already have a small prototype, with client-server (as ecient as Java RMI), event and stream connectors, and with mobile components. b

c

:::

:::

:::

References

:::

[1] E. Bruneton, and M. Riveill, \JavaPod : une plate-forme a composants adaptable et extensible", INRIA, research report 3850, January 2000. [2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C.V. Lopes, J.-M. Loingtier, and J. Irwin, \Aspect-Oriented Programming", ECOOP'97, Jyvaskyla, Finland, June 1997. [3] C.P. Lunau, \Is Composition of Metaobjects = Aspect Oriented Programming", ECOOP'98 AOP Workshop, Brussels, Belgium, July 1998. [4] J. McAer, \Meta-level architecture support for distributed objects", Proceedings of Re ec1 a connector is an abstract, distributed object, made tion'96, G. Kiczales (ed), 39-62, 1996.

of stubs and skeletons, which can represent any type of binding: client-server, events, streams The other terms derive from CORBA and EJB. :::

2