Section: Scientific Foundations
OpenCCM
This part of the project deals with the design and the production of new tools for component based platforms. This work was initiated in the Computer Science Laboratory of Lille (LIFL) and is now one of the projects of the ObjectWeb Consortium [73] under the name OpenCCM. Our goal is a complete platform for the OMG's CORBA Component Model (CCM). We want to fully capture all the aspects of this standard and contribute to it. Our ambition is to produce the first referenced CCM platform in an open source format. Actually OpenCCM is already a LGPL software accessible at http://openccm.objectweb.org . Beyond this production we aim to investigate three points as research topics: open the platform to allow extensibility and adaptability, open the run-time containers to weave non-functional aspects, and give the capability to freely assemble components in an open environment. These three points are detailed in the next sections. This work is related to other works on open middleware: the Fractal model [67] for component middleware (ObjectWeb, INRIA Sardes project, France Telecom), reflexive middleware approaches (Dynamic TAO [78] , Flexinet [72] , OpenCorba [81] , OpenORB [99] ), adaptable middleware approaches (ARCAD RNTL project [82] ), virtual machines (VVM) and QoS driven Middleware [74] .
Open Middleware for the CCM
The OpenCCM project proposes an open framework to produce and exploit CORBA Components. One can specify such a component in the new OMG IDL3 language, which is an extension of the old CORBA IDL2 language. The framework can produce IDL2 schemas from IDL3 descriptions, and the associated stubs for various programming languages (Java, C++, IDLscript, etc.) [87] . The framework is itself composed of reusable components around an IDL3 global repository. This architecture is open and extensible. The components are written in the Java language and are also CORBA components, so that they can be assembled to create several configurations. Therefore the platform can be instantiated in several ways for middleware such as ORBacus, OpenORB or Borland Enterprise Server.
Current work plans to complete the framework with the Component Implementation Definition Language, the Persistent State Definition Language, and the JORM framework. This will allow the platform to automatically generate containers with persistency capabilities. We work also on the assembly and packaging tools using the XML descriptors of CCM, and we also work on the transformation tools towards C++.
Open Containers
A major goal of component based platforms is to be able to separate functional aspects (ideally programmed by an expert of the domain addressed) from the non-functional aspects (ideally programmed by an expert of computer system techniques). This separation can be implemented by a technical separation between the components (functional aspects) and the containers (non-functional aspects). A container hosts components, so that the components inherit the non-functional aspects of the container.
Actually containers (such as the EJB or CCM containers) can only contain a limited set of non-functional aspects (activation/termination, communications and events, security, transactions and persistency). These containers are not extensible, neither statically nor dynamically. So they cannot respond to specific needs such as fault tolerance, replication, load balancing, real-time or monitoring.
In contrast to this, we plan to design open containers. We investigate a generic model for containers and then weaving mechanisms which will allow an application to specify particular needs. An application will be able to reclaim the deployment of well-fitted containers. We work on a specific API to develop non-functional aspects for our containers. In a first step we have to specify a large number of non-functional aspects to find the way to compose them. Non-functional aspects can be seen as interceptors, so we work on composition of interceptors to produce containers. In a second step we investigate the possibility to dynamically manipulate the containers to change the configuration of non-functional aspects.
Open Environment
An open environment for component-based applications has to deal with several problems. For instance, we have to allow assemblies and deployment on demand. In this part we plan three goals: a virtual machine for programming distributed deployments, a trader of components to realize assemblies from 'off the shelf components, a repository to manipulate and drive assemblies of components.
Current middleware proposes fixed deployment strategies which are not adaptable to specific needs. These deployment tools are mainly 'black boxes' and ad-hoc for a particular environment. In the CCM context we can exploit the XML based OSD language which is used to describe assemblies. This is a good basis to describe deployments. But the CCM does not define an API to control the deployment, and today the associated tools have not be realized in an open manner. Actually we work on a set of operations to deploy OSD assemblies. We investigate several useful properties (such as optimised deployment, parallel deployment, fault tolerant deployment, transactional deployment) implemented by these operations. This will lead to an open API for adaptable deployment strategies [85] , [86] . We plan to use IDLscript to specify such strategies.
Assemblies can be constructed on demand with 'Components Off The Shelves'. We work on this point with our TORBA environment [80] . Within TORBA we can instantiate components for trading from trading contracts (specified in our TDL - Trading Description Language). This is the basis for an open infrastructure for components brokering that we plan to investigate here.
In an open framework for components we have to manipulate assemblies in all the phases of the design work and also during execution. Assemblies have to be manipulated by various users, each with his/her own concerns (e.g., assemble, deploy, distribute, non-functional aspects set-up, monitoring). We plan to construct a global repository for all these activities. Moreover this repository has to be opened for new activities. In this way we want to define an environment which allows for the definition, at a meta level, of the different concerns that we want to exist on the repository [84] . Then the environment will be able to automatically generate a new view on the repository to capture the specified activity [79] .
