Towards a Dynamic CORBA Component Platform - Semantic Scholar

Towards a Dynamic CORBA Component Platform Rapha¨el Marvie

Philippe Merle

Jean-Marc Geib

Laboratoire d’Informatique Fondamentale de Lille UPRESA 8022 CNRS Bˆatiment M3 – UFR d’IEEA 59655 Villeneuve d’Ascq – France E-mail: fmarvie,merle,[email protected] Abstract Distributed object computing (DOC) middleware, even if commonly used, has several drawbacks to support large and complex distributed applications: no visibility of distributed object interconnections, no implementation separation between business logic and system services, and no application deployment process. In response to this, DOC middleware is evolving to distributed component computing (DCC) middleware such as the Enterprise Java Beans and the CORBA Component Model (CCM). Such middleware provides new solutions to exhibit component interconnections, to separate functional and non-functional aspects, and to deploy components. However, this new middleware generation does not allow applications to have a fine-grain control on their deployment process, i.e. the deployment process is hard-coded into DCC middleware and applications cannot adapt it to their requirements. In the context of the CCM, this paper promotes a flexible deployment process supported by a dynamic CORBA Component platform. This platform is composed of an OMG IDL compiler, generic container servers, and our CorbaScript engine (basis and first implementation of the OMG IDLscript specification). It allows software architects to dynamically drive the deployment of their distributed components, as well as to be reactive to their evolutions.

1 Introduction Today, most of large and complex distributed applications tend to be built on top of advanced distributed object computing (DOC) middleware, such as the Common Object Request Broker Architecture [14] (CORBA) of the Object Management Group (OMG), the Microsoft’s Distributed Component Object Model [6] (DCOM), or the Sun Microsystems’s Java Remote Method Invocation [16, 18] (Java RMI). Thanks to these approaches, applications are

viewed as a set of interconnected distributed objects. In the meantime, system services like naming, trading, notification, security, transaction, and persistence are also viewed as distributed objects. However, DOC middleware has several drawbacks to correctly support large-scale and configurable distributed applications. Firstly, connections between objects are encapsulated into objects and cannot be easily configured by external software architects. Thus, it is difficult to have a precise architectural view of distributed applications. Secondly, the use of system services, i.e. the non-functional aspects of an application, has to be hardcoded into objects and mixed with functional aspects. This tends to make developments more complex for domain experts: They must deal with their application business logic and with the complexity of system object services simultaneously. Finally, the deployment of objects is not addressed by DOC middleware: No standard paradigm exists to install objects in their execution sites automatically, there are only third parties ad hoc tools. To correct these drawbacks, DOC middleware is evolving to distributed component computing (DCC) middleware such as Sun Microsystem’s Enterprise Java Beans [10] (EJB), or the recent OMG’s CORBA Component Model [2] (CCM). Such middleware promotes the use of container servers, which host downloadable components and manage system services implicitly. Then, component implementations could only contain the application business logic. Moreover, required system service strategies are identified into external descriptors. Thus, various system strategies could be applied to the same component implementation. For instance, the EJB and CCM specifications define eXtended Markup Language (XML) vocabularies to describe security, transaction, and persistence requirements of component instances. In this context, component packages (i.e. implementation and descriptor) are deployed / downloaded into container servers. Such containers are configured using the descriptors to properly provide system services to hosted component instances. The DOC middleware archi-

tectural drawback is solved by applying design patterns: EJB components can be connected through JavaBeans design patterns [4], and the CCM introduces the concept of port as discussed in Section 2.1. Thanks to DCC middleware, applications are now viewed as a composition of packaged, deployable, and distributed components. Even if DCC middleware brings a first answer to distributed application deployment, it does not meet all the requirements of large-scale and configurable distributed applications. Firstly, all the applications are deployed in the same manner, whatever their specificities, as the deployment process is imposed by the middleware. Secondly, software architects cannot gain control over the deployment process, thus being able to adapt it to their application needs. Finally, the classical three steps schema—building and packaging components, deploying them, and running applications—is not flexible enough for certain use cases. For instance, applications for mobile users require components to be deployed at runtime according to a context, like the user connection host. This paper intends to propose a flexible deployment process, i.e. software architects could have a fine-grain control over the deployment of their distributed componentbased applications. This fine-grain control encompasses with downloading component implementations into container servers, instantiating them, configuring their nonfunctional and functional properties, and interconnecting component instances. To express these deployment actions, our approach promotes the use of our scripting language which provides introspection and dynamic invocation at runtime. Then, thanks to these scripting facilities, software architects can easily focus on their deployment actions without dealing with technical middleware aspects such as stub generation and complex rules of programming models. Our dynamic CORBA Component platform [9] tends to experiment and implement these aspects in the context of the CCM, which represents one of the most complete industrial component model at the moment. This platform is currently composed of three main elements: an OMG IDL compiler, generic container servers, and a dynamic deployment console. From abstract component descriptions, the OMG IDL compiler produces component skeletons mainly implementing network request unmarshaling and a component introspection API. Generic container servers provide a public API to control the installation of component implementations downloaded from standard Web servers. The dynamic deployment console permits software architects to script their deployment actions. It is based on our CorbaScript [8, 11, 12] engine which is the basis and first implementation of the recent OMG IDLscript specification [15]. This scripting engine is used to control both APIs to respectively interconnect component instances and download component implementations at runtime.

Section 2 of this paper presents an overview of the CCM and its key elements for a dynamic deployment approach. Section 3 explains how our dynamic CCM platform is designed. Section 4 illustrates how our platform is used from the CorbaScript engine. Section 5 discusses related work on similar component platforms. Finally, section 6 concludes this paper, summarizing benefits and outlining in-progress and forthcoming work.

2 The CORBA Component Model The CORBA Component Model (CCM) represents the answer of the OMG to the evolution from DOC to DCC middleware, and will be the basic model of the forthcoming CORBA 3 specification. The CCM is a server side component framework which intends to ease the development of distributed applications made of heterogeneous components. This last point is an improvement of the CCM compared to other models. EJBs are only intended to be used in Java and DCOM is mainly intended to be used in MSWindows environments. The CCM has been thought taking interoperability into account: Components can be made in various languages for various operating systems, and used upon various CCM platforms. The CCM specification defines four models which are briefly presented in this section from a dynamic deployment centered point of view. Vending machine

Heat probe

Provider

Consumer

Figure 1. The application.

Water supply

11 00 00 11 00 11 00 11

vending

Power supply

machine

toy-

First, let us present the toy-application, a vending machine, used in this paper to illustrate the various ideas of the CCM and of our platform. As well as the vending machine available at the end of a corridor, this application is composed of various elements: a power supply, a water supply, a heat probe, and the vending machine. Two components— a customer and a provider—are added to simulate a vending machine in use. Figure 1 presents an overview of this application.

2.1 The abstract model The CCM abstract model offers developers to define interfaces and properties of components. The OMG IDL (In-

terface Definition Language) has been extended to express component interconnections. In this paper, IDL3 refers to this new language release and IDL2 to the old one. A component can offer multiple interfaces, each one defining a particular point of view to interact with the component. Two interaction modes are provided: facets for synchronous invocations, and event sinks for asynchronous notifications. Moreover, a component can define its required interfaces, which define how the component interacts with others: receptacles for synchronous invocations, and event sources for asynchronous notifications.

VendingMachine Base reference

ConsumerFacet Facet ProviderFacet

TemperatureEvt

Event sink

component VendingMachine { provides ConsumerFacet consumer ; provides ProviderFacet provider ; consumes TemperatureEvt temperature ; uses PowerPlug power ; uses WaterSupply water ; emits EmptyEvt empty ; readonly attribute DrinkSeq drinks ; }; home VendingMachineHome manages VendingMachine {} ;

VendingMachine component PowerPlug

11111 00000 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111

PowerSupply Component

Facet Implementation

Event sink Implementation

Figure 3. IDL3 definition of the vending machine component type.

Receptacle WaterSupply

EmptyEvt

Event source

Attribute

drinks

Figure 2. The CCM abstract model applied to the vending machine.

The four kinds of interfaces are named ports and are illustrated in Figure 2. The ConsumerFacet interface is composed of synchronous operations used by a consumer component. The TemperatureEvt event sink defines how the vending machine can receive notifications from a heat probe component. Connections between components can be easily described and checked at design time with IDL3, e.g. the PowerPlug facet of the PowerSupply component can be connected with the PowerPlug receptacle of the vending machine because these two ports have compatible interfaces (here the same one). Figure 3 presents the definition of the VendingMachine component type in IDL3. Each port is defined using a dedicated keyword: provides for facets, consumes for event consumers, uses for receptacles, and emits/publishes for event sources. In the context of the CCM, interfaces that are provided or used are defined as IDL2 interfaces, when events are defined as valuetypes. The abstract model also defines instance managers— component homes —which are based on two design patterns [5]: factory and finder. A home is defined to create and retrieve a specific component type, and can only manage instances of this type. Nevertheless, it is possible to define several home types for a single component type.

Already defined in the CORBA 2.x specification, the Interface Repository (IFR) allows programs to dynamically discover IDL interfaces, which is a key feature for component introspection. Dynamic Invocation Interface (DII) allows one to send requests dynamically without requiring prior knowledge of the component interface (such as stubs). Extending IDL2, IDL3 brings new means to dynamically discover and use component instances. Component ports can be discovered in two ways: First, using the extended IFR taking IDL3 ports and homes into account, and second, using component IDL2 interfaces directly. Moreover, the base component interface provides operations to discover and to manage ports dynamically such as retrieving a specific facet of the component and listing the various available facets. Thus, it is possible to dynamically manipulate ports in order to connect component instances together, as heavily done in our platform.

2.2 The programming model The CCM programming model defines the Component Implementation Definition Language (CIDL) which is used to describe the implementation structure of a component and its system requirements: the set of implementation classes, the abstract persistence state, transactions, security, multi-threading, etc. This language is associated with the Component Implementation Framework (CIF). This framework allows developers to merge the component functional part they have produced and the non-functional part generated from IDL3 and CIDL descriptions. The functional part includes the implementation of the provided interfaces (facets and event sinks). Figure 4 presents how components are produced in the context of the CIF. Using the IDL3 definition as well as the CIDL description of the component, a compiler produces the skeleton of the component implementation. This

IDL3 CIDL Compiler Lang/CIF

Deployment API

Functional (to write)

CI & AF

Non-functional (generated)

$ install

XML

Container

Host Deployment API

.zip

IDL2

CI ComponentInstallation AF AssemblyFactory

CI & AF

Archives Assembly Deployment API IDL

Figure 4. The CCM programming model.

Deployment API

CI & AF

CI & AF

skeleton includes the non-functional part of the component implementation, i.e. unmarshaling GIOP requests, port management, transaction, persistence, security, and multithreading requirements. These skeletons are implemented on top of APIs provided by containers. Thus, a developer only has to write the functional code in order to complete the component implementation. The compiler also produces the IDL2 mapping as well as a XML descriptor for the component implementation. The IDL2 will be used by component clients. The XML descriptor will be used during the deployment of the component implementation as discussed in the following subsection. The implementation generated part also provides a dynamic introspection API. It includes the operations to discover component ports in a generic manner (same operations for any component type), or in a specific one (operations generated according to the component type). These operations are used in our dynamic platform to introspect and interconnect component instances at runtime.

2.3 The deployment model The CCM deployment model is based on the use of software packages, i.e. “ZIP” archives containing component descriptors and implementations. Descriptors are written using the Open Software Description (OSD) language which is a XML vocabulary. This language allows architects to describe four kinds of descriptors. The Software Package Descriptor provides global information about a package such as the author of the package, the license, as well as interfaces, properties, dependencies, and implementations of a component. The CORBA Component Descriptor contains technical information about the component implementation. This information is generated from the CIDL description and the administrator only has to set the policies (like security). The Component Assembly Descriptor describes the initial configuration of the application. It defines which components to use and how to interconnect them. The Property File Descriptor contains the value of the component properties. These are used while configuring the various component instances.

Figure 5. The CCM deployment model. Figure 5 presents the deployment process, which allows architects to easily install an application on various sites. A ComponentInstallation and an AssemblyFactory have to be running on any site an application could be installed. These two objects are used by the deployment tool to install the packages of the application, and to create an instance of it. AssemblyFactory objects manage Assembly objects that represent deployed applications. The deployment tool provides an OSD assembly descriptor to the Assembly object that really performs the deployment of the application. Thus, the deployment process is fixed in this object, and cannot be controlled by an architect nor by the application. Our approach promotes a more flexible process, through fine-grain control provided by its associated platform.

2.4 The execution model The CCM execution model defines containers as the technological artifacts. A container is a runtime environment for component instances and their homes. Several containers could be hosted by a same container server. Figure 6 presents the container architecture, underlining in which way a container is more than a simple execution environment. Containers hide the complexity of most of the system services like the POA, transaction, security, persistence, and notification services. Thus, containers take part in the management of non-functional aspects of a component. Clients interact with a component instance through the generated IDL2 interfaces. An interesting extension to these container servers is the ability to download archives from repositories. Thus, downloading packages can be done at any time, and more precisely only when a component is required. A generic container server could exploit a component package (loading a component home and the component implementation, creating a home instance, and making the home available),

Container Server Client

IDL2

Container

Home Callbacks

External IDL2

CORBA

POA

Component

Container

on a dynamic deployment process, the compiler only generates extended component skeletons including the port management and the introspection aspects. To be portable on various ORBs, extended component skeletons inherit from GIOP skeletons produced from IDL2 definitions. These various compilation steps are illustrated in Figure 7.

Internal

A.P.I.

Functional Implementation

ORB

Transactions

Security

Persistence

Notification IDL3

IDL3 Compiler

src Language Compiler

src Extended Skeleton

bin Component Implementation

src Skeleton IDL2 Compiler

Figure 6. The CCM execution model: A container architecture.

IDL2

Written

Language Compiler

src

allowing fine-grain deployment. Thus, architects can control the installation of each component of their applications. This avoids the classical three steps schema: (a) building and packaging an application, (b) deploying the application, (c) running the application. Our generic container servers provides this interesting extension.

3 Our dynamic platform According to the previous section, it could be possible to dynamically load components into generic container servers, to create instances, then to introspect and interconnect these instances. Based on these facilities, we intend to program the deployment process more than to perform it in a fixed manner. To do so, we intend to provide a platform that takes full advantage of the dynamic CCM mechanisms presented in the previous section. This section presents the three main elements of this dynamic platform: an IDL3 and CIDL compiler, generic container servers, and a console to deploy distributed components as well as applications.

Client code

bin Client application

Stub Generated src

Figure 7. From IDL3 to components. Thus, a developer can use his/her favorite development environment to implement the functional part of components inheriting the extended base implementation of skeletons. The compiler allows a CORBA developer to keep his/her skills although moving towards components and to take full benefit of their advantages. The choice of writing a new compiler, instead of extending an existing one, is based on the fact that our compiler can be used on top of different ORBs, while an existing one is dedicated to a specific ORB. Our compiler is implemented in Java to be fully portable on various operating systems. The IDL3 parser has been produced with the JavaCC [13] tool which is a Java parser generator. Moreover, produced IDL2 files can be compiled with various ORB’s IDL2 native compilers. Thus, our platform should be portable and could be used in a multi-ORB context.

3.1 IDL3 and CIDL compiler

3.2 Generic container servers

Our IDL3/CIDL compiler has two goals: mapping IDL3 to IDL2 definitions and generating the non-functional part of a component implementation. Both operations are imposed by the CCM specification. The IDL3 language is only used as a definition language: The specification precisely defines mapping rules from IDL3 to IDL2 definitions. Then, any existing IDL2 compiler could be used to generate stubs and skeletons for a given programming language. Component stubs are identical to CORBA 2.x object stubs but component skeletons are sensibly different. In addition to the classical unmarshaling role, they have to provide the system non-functional part, the port management and introspection implementations. As our current work focuses

In our context, generic container servers are not only execution environments. They also take part in the deployment process. In order to improve the latter, they implement the dynamic loading extension as illustrated in Figure 8. Component implementations are fed into classical Web servers (a). Thus, it is not necessary to define a new kind of repository for package archives. Then, these servers are viewed as Web Package Repository that can be accessed by container servers using HTTP to download archives. At runtime, a software architect can request container servers to load component implementations (b). Then, if not already available, the container server downloads archives from Web servers ( ). Finally, software architects could

instantiate component implementations by requesting container servers ( d). Component Implementation (a) feed in packages (b) load component

Web Package Repository

(c) download package

Container

Console (d) instanciate

Figure 8. Using generic container server facilities.

its associated home. Then, scripts can invoke home operations to create component instances. Once instances have been created, scripts configure and connect them together in order to create a new running application. In order to allow such a generic deployment, the console uses two kinds of introspection to discover the environment: on the global system and on one component instance. The introspection of the system permits to discover where to deploy the component, using the host name or a set of criteria that describes the host. In the latter, a trader is used to find back containers that match the component implementation constraints. The introspection on specific instances allows the script to discover how they can be connected together. Providing two compatible components, the script can automatically find how to connect them together.

3.4 Runtime summary Generic container servers are made of three main system components: a sandbox, a retorter, and a home manager. The sandbox is the execution environment, for example a Java Virtual Machine. The retorter is a system component that can load into the sandbox a component implementation from a URL. The home manager permits automatic instantiation of a component home. Any request of component instantiation is sent to the home as defined in the CCM specification.

3.3 The console The console is the basis of our flexible deployment process. Instead of deploying an application using a fixed CCM deployment tool, the console allows architects to program the deployment process. In order not to introduce complexity in the deployment process, scripts are used to offer deployment programming. Scripting is known as being much more simple to learn and use than compiled languages. These scripts are written in the OMG IDLscript language and are executed by our CorbaScript engine. IDLscript is a powerful object-oriented language allowing users to interactively discover and invoke operations on any CORBA objects. The IDL2 type system is dynamically discovered by the engine thanks to the Interface Repository. Object and component operations are invoked through the DII mechanism. Moreover, type checking is performed by the engine at runtime to control operation parameters and narrow object references to the most derived interface supported. However, all these technical aspects are fully hidden by the CorbaScript engine and users interact with CORBA Objects / Components easily as illustrated in Section 4. During deployment, scripts cooperate with each container server where component instances have to be installed. The container operations are directly invoked to download a component implementation and to instantiate

Figure 9 presents an overview of our dynamic environment to deploy, execute, and administrate distributed components-based applications. Built upon an ORB and its common object services, it relies on the use of generic container servers and of the deployment console. The generic container servers offer a deployment interface for end-user in order to perform on-demand dynamic deployment of components and applications. This environment is used dynamically with the CorbaScript engine as illustrated in the following section. Component instances Generic Container Servers

Web Package Repository

$ Deployment Interface

Deployment Console CorbaScript Engine

ORB Interface Repository Simple Trader

Name Service

Figure 9. Overview of our dynamic environment.

4 Scripting our CCM platform This section presents the use of our CCM platform from the software architect point of view. In that, the vending machine example (see Section 2) is used. The operations presented here could be those of an administrator who incrementally deploys the application using interactively a Cor-

baScript engine or a predefined deployment script. He/she can easily be compared to a Unix administrator using a shell. The application deployment process is made of three steps: the retrieving of component instance references, the introspection of the various component instances, and the connection of these instances. Finally, the application could be used. These operations are discussed in the following sections.

4.1 Retrieving component instance references First of all, it is necessary to find back instances of the component types HeatProbe and PowerSupply. In order to present various solutions to do so, the HeatProbe instance is searched through a simplified trader, and the PowerSupply instance through the CCM component home finder, to create a new instance. In order to use the trader, name service, and home finder, it is necessary to get their references. To find these references back, our CorbaScript engine provides the standard resolve initial references() operation which requests the ORB and returns the reference of the required service. # retrieving our simplified trader trader=CORBA.ORB.resolve_initial_references( "SimpleTrader") # retrieving the name service ns=CORBA.ORB.resolve_initial_references( "NameService") # retrieving the component home finder chf=CORBA.ORB.resolve_initial_references( "ComponentHomeFinder")

Once the three services have been found, the administrator has to search the component instances, a heat probe and a power supply. The heat probe instance is searched in the simplified trader through its search() operation, which searches a component instance according to a set of criteria, like the component properties.

# searching a power supply home powerHome=chf.find_home_by_type( PowerSupplyHome.id()) # creating a power supply instance power=powerHome.create()

The vending machine component instance is deployed on its execution site, here the generic container server named beck. For this, the administrator drives the generic container server to load the component and home implementations, as well as to create an instance of the latter. The generic container server is searched in the Naming Service using the standard resolve() operation. Then, our generic container server API is used to load the component package, using its download() operation, and to create a home instance, using its instantiate() operation. Finally, as for the power supply, the home is used to create a component instance of the VendingMachine type, using the standard create() operation. # retrieving the generic container server beck=ns.resolve([["lifl",""],["beck",""]]) # loading the package beck.download( "http://components.lifl.fr/machine.zip") # creating the home instance machineHome=beck.instantiate( "fr.lifl.cim.goal.VendingMachineHome") # creating the vending machine instance machine=machineHome.create()

From now on, probe, power, and machine variables respectively refer to a HeatProbe, a PowerSupply, and a VendingMachine component instance.

4.2 Introspecting component instances

# searching the heat probe instance probe=trader.search([["type","HeatProbe"], ["site","LIFL"],["room","322"]])

In order to dynamically use the various component instances, it is necessary to discover their interfaces. Two means of performing introspection are presented here: operations offered by the CCM, and the traditional means offered by our CorbaScript interpreter, using the Interface Repository.

The power supply instance is created for the application. This instantiation is a two step operation. First, a power supply home is searched through its type using the find home by type() operation offered by the standard ComponentHomeFinder interface. Once the component home has been found, the administrator requests a component instance creation using the create() operation available on any component home, and generated by our IDL3 compiler.

The component skeletons generated by our IDL3 compiler include introspection operations. For each component defined using IDL3, the CCM mapping includes an operation to provide the facet list of the component (provide all facets()). Here, this operation is used on the power and machine instances. For each component facet, information provided contains the type of the facet as declared in the Interface Repository, the name of the facet as defined in IDL3, and the reference of this facet as provided by the component instance.

# introspecting the power supply instance >>> power.provide_all_facets() [Components::Facet("IDL:PowerPlug:1.0", "plug", PowerPlug("IOR:..."))] # introspecting the vending machine # instance >>> machine.provide_all_facets() [Components::Facet("IDL:ConsumerFacet:1.0", "consumer", ConsumerFacet("IOR:...")), Components::Facet("IDL:ProviderFacet:1.0", "provider", ProviderFacet("IOR:..."))]

Once the facets have been discovered, it is possible to retrieve one’s reference in order to use it. In that, our IDL3/CIDL compiler produces an operation for each declared facet. Thus, it is possible to retrieve the customer facet reference (see Figure 2) of the vending machine and the facet plug of the power supply in order to use them. # retrieving the customer facet of the # vending machine instance customer=machine.provide_customer() # retrieving the plug facet of the # power supply instance plug=power.provide_plug()

The second way of introspecting an instance is implicitly provided by our CorbaScript engine. Using the Interface Repository, the engine could offer the administrator all the information related to defined IDL2 interfaces. In that, CorbaScript includes on each object an attribute ( type) providing a description of the type. Thus, it is possible to introspect the customer facet of the vending machine. This means is the only one available as the CCM does not provide operations to introspect a facet. # introspecting the consumer facet >>> consumer._type < OMG IDL interface ConsumerFacet { DrinkList availableDrinks(); void select ( in Drink d ); void pay ( in float amount ); Drink take ( ); }; >

This runtime type discovery is also possible in Java and C++. However, the complexity of this operation makes it only usable by experts who have to implement it for each program depending on the context of use. Using CorbaScript brings an answer to these two remarks: Introspection is easy to use by anybody and is integrated in the environment to manipulate component instances and containers.

4.3 Connecting component instances Beyond introspection operations, our IDL3/CIDL compiler generates the connect / disconnect operations associated with each output port. An operation is provided for each defined receptacle: the connect power() operation allows architects to connect the vending machine instance to the power supply instance through the plug facet. # connecting the vending machine to the # power supply plug machine.connect_power(power.provide_plug())

For the heat probe, communication is asynchronous and performed using events. In this case, the vending machine subscribes to the heat probe in order to receive temperature events. The reference of the TemperatureEvt event consumer of the vending machine is retrieved and connected to the temperature event source of the heat probe. The operations permitting the consumer retrieval (get temperature consumer()) and source subscription (connect temperature()) are also generated from IDL3. # subscription of the vending machine to # the heat probe probe.connect_temperature( machine.get_temperature_consumer())

4.4 Using the application The use of the vending machine can be performed from a component instance of type Consumer after an instance has been connected to the machine. It is also possible to use the vending machine instance interactively from a CorbaScript interpreter. The customer facet being available, operations to use the vending machine can be directly invoked. # using the vending machine instance # through its consumer facet >>> consumer.availableDrinks() DrinkList(Drink.Cola,Drink.Water, Drink.Orange) >>> consumer.select(Drink.Water) >>> consumer.pay( 3.0 ) >>> consumer.take() Drink.Water

An administrator could also benefit from this interactive use of an instance. If a component instance of the application has to be changed, like a power supply plug, it is easy to do it dynamically using CorbaScript. First, a new instance

is created. Then, the old one is disconnected. Finally, the new one is connected to the machine. # looking for another PowerSupply home, and # instance creation anotherH=chf.find_home_by_type( AnotherPowerSupplyHome.id()) power2=anotherH.create() # disconnecting the old instance and # connecting the new one trash=machine.disconnect_power() machine.connect_power(power2.provide_plug())

4.5 To summarize This section has shown how simple CorbaScript use is to dynamically retrieve and exploit component instances and system services in order to build, deploy, configure, and administrate a distributed CORBA component-based application. It is not any more required to be an expert in programming. However, it is necessary to know the deployment process in order to perform it and be able to control it using our platform. The next step of our project is to simplify the deployment process. In the same way as CorbaScript hides the complexity of CORBA dynamic mechanisms, we are working on the specification and implementation of a deployment service offering high-level operations hiding complexity and automating the deployment process. This deployment machine will be implemented in CorbaScript to benefit from its simplicity and dynamicity. At the moment, CorbaScript is written in C++, and available [8] on the major ORBs: MICO, omniORB 2, ORBacus, Orbix 2000, TAO, and VisiBroker. Performance of CorbaScript is really dependent of the DII implementation offered by the underlying ORB. For example, on top of ORBacus, a script invoking operations on a C++ component is quite as fast as the same program written in Java, and only 2.5 times slower than this program written in C++. Thus, the overhead brought by CorbaScript is acceptable according to the deployment flexibility gained. Moreover, a script can be written interactively while a Java/C++ program has to be compiled.

5 Related Work There are no industrial CCM platforms available at the moment. This is mainly due to the youth of the CCM specification. As most of the main ORB providers have contributed to the specification, some platforms must be en route. Considering EJB platforms, they are sort of basic CCM platforms. Nevertheless, they are dedicated to

the Java language, while we intend to offer a platform for Java components as well as for C++ ones. On the research side, the TAO research team is the only one known (to us) as working on a CCM platform. They intend to provide a CCM platform improved for real time applications [17]. They are working on solutions to reduce the overhead due to the accumulation of layers implied by the component specification—ORB, POA, container, skeleton, component—while being compliant with the specification. Our dynamic platform is compatible with any of these approaches. Each solution will improve one or more parts of the model making it better suited for certain uses without becoming incompatible with the others, thanks to CORBA interoperability. Olan [1, 3] was an academic project that intended to offer a distributed component model. Its main goals were to make it easier to build and deploy distributed applications and to allow dynamic configuration of components. Olan is not an implementation of the CCM specification but can be seen as a “source of inspiration” of the CCM. Olan is one of the forerunner proposals in thinking of software production as a whole. This environment offered means to express design, compilers to help code generation, tools to build an application through composition, and tools to deploy and dynamically reconfigure an application. Building an application was performed through a graphic console offering simple actions to connect components together, to generate wrappers when necessary, and to configure these assemblies (components and connectors). This graphic console was an easy way to manipulate the Olan Configuration Language (OCL) which is an ADL [7] (Architecture Definition Language), the basis of the Olan approach to build distributed applications. However, the Olan deployment platform and its tools cannot inter-operate with other platforms. This problem is addressed by the CCM. Then, our platform could inter-operate with future CCM platforms.

6 Conclusion To support large-scale distributed applications, middleware is evolving from Distributed Object Computing (DOC) to Distributed Component Computing (DCC). Then, the deployment of distributed component-based applications becomes an open research challenge. In the context of the CORBA Component Model specification, we propose a flexible approach to have a fine-grain control over the deployment of such applications. This flexibility is reached by scripting the deployment process using the CorbaScript engine, which is the basis of our dynamic CORBA Component platform. It allows one to easily interact with generic container servers, using introspection, dynamic invocation, and on-demand downloading. Moreover, an IDL3 compiler is used to map IDL3 to IDL2 descriptions and to generate

the component introspection API. To improve our dynamic approach, we are working on taking full advantage of the CORBA CosTrading. Instead of finding component instances, component implementations, and containers using names, we would like to export any element of the system through the trading service. Then, a deployment script would search containers and components according to the context. Finally, building a portable Java graphic console will be the last stage, making it easy to use and administrate our dynamic platform. During all these stages, experimentations will be performed to validate our approach and platform. Building a complete CCM platform is a huge task. Thus, we have only focussed on the aspects of the CCM related to our research topics. Due to its youth, some aspects of the CCM are still under-specified, implying the specification not to be fully implementable yet. We have tried, when underlining such points, to contribute to the OMG Components Finalization Task Force, as well as introducing more dynamicity like we did with IDLscript. The best advice we may provide to anyone who wishes to implement the CCM, is to address his / her requirements one by one, staying compatible with the specification, and not intending to implement the full specification at first.

References [1] R. Balter, L. Bellissard, F. Boyer, M. Riveill, and J.Y. VionDury. “Architecturing and configuring distributed applications with Olan,” In Proc. IFIP Int. Conf. on Distributed Systems Platforms and Open Distributed Processing (Middleware’98), The Lake District, September 1998. [2] BEA et al. CORBA Components: Joint Revised Submission. OMG TC Document orbos/99-07-f01..03,05g orbos/99-08f05..07,12,13g. Object Management Group, August 1999. [3] L. Bellissard, F. Boyer, M. Riveill, and J.-Y. Vion-Dury. “System Services for Distributed Application Configuration,” In Proc. of the 4th IEEE Int’l Conf. on Configurable Distributed Systems, (ICCDS’98), Annapolis MD, May 4-6, 1998. [4] A. DeSoto. Using the Bean Development Kit - a Tutorial. November 1997. Url: http://java.sun.com/beans/docs/Tutorial-Nov97.pdf [5] E. Gamma, R. Helm, R. Johnson, J. Vlissides, and G. Booch. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Westley Professional Computing, USA, 1995. [6] R. Grimes. Professional DCOM programming. Wrox Press ltd., Birmingham, Canada, 1997. [7] V. Issarny, T. Saridakis, and A. Zarroz. A survey of architecture definition languages. Technical report, C3DS Project, June 1998.

[8] LIFL. The CorbaScript Home Page. 1997-2000. Url: http://corbaweb.lifl.fr/CorbaScript/index.html [9] R. Marvie, P. Merle, and J.-M. Geib. “A Dynamic Platform for CORBA Component-based Applications,” In Proc. of the ACIS 1st Int’l Conf. on Software Engineering Applied to Networking & Parallel/Distributed Computing, SNPD’00, Reims, France, May 18-21, 2000. [10] V. Matena and M. Hapner. Enterprise Java Beans Specification v1.1 - Public Draft. Sun Microsystems, May 1999. [11] P. Merle, C. Gransart, and J.-M. Geib. CorbaScript and CorbaWeb: A Generic Object Oriented Dynamic Environment upon CORBA. In Proc. of TOOLS Europe 96, Paris, June 1996. [12] P. Merle, C. Gransart, and J.-M. Geib. “Using and Implementing CORBA Objects with CorbaScript,” In ObjectOriented Parallel and Distributed Programming, ed. Hermes, Paris, 2000. [13] Metamata. Java Compiler Compiler. Fremont, USA, 1999. Url: http://www.metamata.com/javacc/index.html [14] Object Management Group. CORBA/IIOP 2.3.1 Specification. OMG TC Document formal/99-10-07, October 1999. [15] OOC and LIFL. CORBA Scripting - Joint Revised Submission. OMG TC Document orbos/99-07-17. Object Management Group, August 1999. [16] Sun Microsystems. Java Remote Method Invocation Specification. Revision 1.50, JDK 1.2, October 1998. [17] N. Wang, D. Schmidt, and D. Levine. “Optimizing the CCM for High-Performance and Real-Time Applications,” Middleware’2000, New York, April 2000. [18] A. Wollrath, R. Riggs, and J. Waldo. “A Distributed Object Model for the Java System,” USENIX Computing Systems, vol. 9, November/December 1996.