An Infrastructure for Development of Dynamically Adaptable Distributed Components

An Infrastructure for Development of Dynamically Adaptable Distributed Components Renato Maia, Renato Cerqueira, and Noemi Rodriguez Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Rua Marquês de São Vincente, 225 RDC, Gávea, Rio de Janeiro, RJ, Brazil. {maia,rcerq,noemi}@inf.puc-rio.br Abstract. Dynamic adaptation has become an essential feature in distributed applications, mainly because current technology enables complex tasks to be performed by computers in application domains unsuited for service interruption. This paper presents an infrastructure that uses an interpreted language to provide simple but powerful features that enable coarse and fine-grained adaptations in component-based systems, using the CORBA Component Model (CCM) as a basis. To extend the static nature of CCM, we propose dynamic containers, which enable development of dynamically adaptable components that admit changes on component structure and implementation. The extended set of mechanisms for component manipulation can be used to create adaptation abstractions that simplify the programmer s task. In this paper, we present a tool that provides support for the protocols and roles abstractions, which allows programmers to adapt running applications, establishing new interactions among its components. 1 Introduction Much research work has focused on techniques that support software evolution, that is, techniques that allow changes to existing software to be introduced in faster and easier ways. However, most of the effort on this matter concentrates on providing flexibility statically, that is, on designing the source code used to generate the system with flexible architectures or structures [1, 2]. On the other hand, there are currently many software systems that should never be stopped, such as those for process control, e-business, life support or military applications. In these systems, interruption of service is highly undesirable, and the issue of software evolution becomes extremely expensive and troublesome. As a consequence, development of the first working version of the system becomes critical. Such projects are very risky, because of the high probability of underestimated time and cost constrains. In face of those problems, the software community has recognized the necessity of mechanisms to allow dynamic adaptation of computer systems [3], that is, the ability to change during execution. However, as in the static approach,

most of the proposed solutions are based on architectures or structures that are applied to specific portions of the system: those related to a given set of possible anticipated changes. This adds extra effort on system design, which now must predict possible points of modification; this effort can prove useless in the future if none of the predicted modifications are necessary. Besides, the use of those techniques generally increases the complexity of system design. The main reason for this is the lack of appropriate abstractions: mechanisms that provide flexibility are generally added to the system by merging new, adaptation-related components with those related to the application domain. We propose a framework for the development of components that uses computational reflection features as an abstraction to hide the details of dynamic adaptation mechanisms. This framework is built with the interpreted language Lua [4]. The use of a dynamically-typed interpreted language allows us to combine flexibility and simplicity. As a basic layer, our framework provides LuaCCM, an implementation of the CORBA Component Model (CCM). CCM extends the OMG object model with introspective interfaces and entities that allow developers to implement, configure, and manage component-based applications in a standardized way. One important advantage of using CCM as a basic layer is that the adaptation code produced with our framework can be mapped to other CCM implementations. However, CCM is a complex model and remains in the class of techniques that add complexity to the development process. The idea of our framework is to use LuaCCM as a basis for the construction of different adaptation abstractions. In this paper, we illustrate this layered approach with the discussion of a tool that supports the protocols and roles abstractions as proposed in [5]. This paper is organized as follows: Sect. 2 presents a brief overview of the main CCM concepts; Sect. 3 presents some details about the features provided by LuaCCM; In Sect. 4 we discuss how these features can be used to implement abstractions to perform dynamic adaptations, as well as the implementation of a tool based on the concept of protocols and roles and examples of its use to perform dynamic adaptation of a system; In Sect. 5 some related works are discussed and, finally, some final remarks are presented in Sect. 6. 2 CORBA Component Model The last version of CORBA defines the new CCM specification [6], which is a component model defined on top of CORBA architecture and is primarily intended to solve some problems of CORBA related to extension mechanisms and standardization of common tasks involved in object handling, such as instantiation, activation, request dispatching, etc. [7]. A CCM component is defined as a set of ports and can additionally support interfaces and provide attributes like a usual CORBA object. The ports of a component are used to establish connections and are divided into four categories: facets, receptacles, event sources, and event sinks. Facets are ports that provide some interface and may be connected to receptacles, which are ports where an object implementing some interface

may be registered. Similarly, event sources are ports that send events and may be connected to event sinks to establish an event-based communication channel. Additionally, CCM also defines the concept of component homes that are some limited form of component used specifically to retrieve and manage instances of some component definition. Through a component home one can create new instances or recover persistent component instances. Fig. 1 shows a graphical representation of the main CCM concepts and Fig. 2 shows an example of a component definition described using the extended version of IDL defined by the new version of the CORBA specification. Fig. 1. Graphical representation of CCM concepts. 1 component MyComponent supports SupportedInterface 2 : SuperComponent 3 { 4 attribute string my_ atribute ; 5 provides FacetInterface my_ facet ; 6 uses ReceptacleInterface my_ receptacle ; 7 publishes PublishedEvent my_ event_ source ; 8 consumes ConsumedEvent my_ event_ sink ; 9 }; Fig. 2. Example of component definition in IDL 3.0. The central concept in CCM is that of container. The container provides an execution environment for component instances with many features like management of connections on ports or implementations of event channels. Besides that, the container also manages creation, activation and incarnation (in case of persistent components that are recovered by a new instance incarnating some previously saved state) of instances of component implementations, which are called executors. This management is defined by a set of different policies as specified in CCM specification. However, taking into consideration the nature

of the CORBA architecture, the implementation of a container requires some previous knowledge of component definition (e.g. for implementation of port handling), as well as of the component implementation (like policies that define how to activate instances). As a solution, CCM defines four different categories of components and a set of policies that may be used to define how to handle component instances of some component implementation. Additionally, specific tools are used to generate part of the container implementation related to some component definition (e.g. management of ports); this generated code is incorporated into the component implementation. This way, the same component can be deployed in different container implementations. 3 LuaCCM LuaCCM is an implementation of CCM using the Lua programming language. Lua is a general-purpose dynamically-typed interpreted language with usual control structures (while, if, etc.), function definitions with parameters, local variables, and data-description facilities. Initially, Lua was devised to be an extension language to customize industrial applications, but today it is being used in thousands of products and prototypes worldwide. Its success is partially related to one of its main characteristics: extensibility. Lua provides reflective facilities that enable the extension of its semantics, making it extremely flexible. Another important feature are the data-description facilities provided by Lua that are based on a single data structure called table. Lua tables are associative arrays that can hold values indexed by any valid value of the language. This feature can be used to represent objects by tables containing values that represent attributes, as well as functions that represent methods, since Lua functions are first-class values. Object-oriented facilities are partially supported by syntactic sugar that simplifies invocation and declaration. Additionally, using the extension facilities of Lua, it is also possible to define object behavior-sharing mechanisms though hierarchies of object classes or prototypes [8]. In spite of all its flexibility, Lua is also a very small and simple language. Our group investigates how the features of Lua can be used to improve the development of dynamically adaptable systems [9 13]. One of the products of this work is LuaOrb, which uses the extension mechanisms of Lua to define a dynamic binding of CORBA. With LuaOrb, it is possible to invoke CORBA object operations as common Lua object methods. Additionally, LuaOrb enables the development of CORBA objects using Lua. LuaOrb is implemented on top of a C++ ORB (any one compatible with CORBA 2.3 specification) and uses the CORBA Dynamic Invocation Interface to dynamically generate requests to CORBA objects according to the information provided by the CORBA Interface Repository. Similarly, it uses the Dynamic Skeleton Interface to receive and dispatch requests to the corresponding implementation of a particular servant. A LuaOrb servant implementation is a simple Lua object, i.e. a table containing values and functions. This way, we are able to dynamically change objects by replacing the functions that implement their operations.

LuaCCM extends LuaOrb with the concepts defined in the CCM specification. However, CCM is tightly coupled with the idea of statically defined components. Unlike other language mappings, LuaCCM defines the idea of a dynamic component, i.e. a component that can be changed at runtime. To allow that, we define the concept of a dynamic container, which can self-adapt to implement the facilities required by some component deployed at runtime. Additionally, dynamic containers also provide reflective facilities to adapt deployed component instances by changing their implementation, as well as changing the facilities provided according to the new implementation. We next present the details of the LuaCCM dynamic container and the reflective facilities provided to perform fine-grained adaptations on LuaCCM components. 3.1 Dynamic Containers LuaCCM dynamic containers are entirely implemented in Lua, as sets of Lua objects and LuaOrb servants. LuaOrb servants implement the external container interfaces, i.e. interfaces provided to component clients. The container creates a LuaOrb servant for each component instance. This LuaOrb servant implements the component main interface, which provides the operations of the supported interfaces, as well as operations to manipulate its ports. When the request of a facet is received, the container also creates a LuaOrb servant that implements the facet interface and dispatches all requests to the implementation of the component instance. Similarly, the container creates a LuaOrb servant at the request of each event sink of a deployed component instance. This servant implements an event consumer that delivers all consumed events to the implementation of the component instance. The container also creates a context object, i.e. an object that provides the interfaces used to access the facilities provided by the container to the component implementation, such as retrieving the objects connected to its receptacles or sending events though its event sources. CCM component implementations can be separated in independently activated parts called segments that implement different ports. Fig. 3 depicts the infrastructure created by the LuaCCM container for a component instance. Basically, the facilities provided by the LuaCCM container to a component instance are implemented by two elements: a wrapper object and a context object. The wrapper object is responsible for creating LuaOrb servants that represent the component, receiving requests or events and dispatching them to the component executor. Additionally, the wrapper object also implements the operations of the main component interface related to port handling, like the operations used to get facets or connect objects to receptacles. The context object is responsible for holding the references of objects connected to component receptacles and delivering the events sent through component event sources. Each time an implementation of a new component definition is installed, the container creates a definition manager, which retrieves the component definition (e.g. from a package descriptor or a component interface repository) and dynamically generates the implementation of the facilities provided to the new component by defining a wrapper object class and a context object class. Every

Fig. 3. LuaCCM container structure. time a new instance of that component definition is created, those classes are instantiated to produce the wrapper object and the context object for that particular instance. This behavior enables the dynamic adaptation of the container. Suppose that some component definition is modified and the corresponding definition manager is notified. Then, the wrapper and context object classes are adapted to implement new facilities according to the new component definition. As a result, every instance of the wrapper and context classes reflects the adaptation and provides the new facilities to every instance of that component definition installed in the container. Alternatively, the adaptation can be performed on a single instance of a component by adapting only the wrapper and context objects of that instance: that can be done replacing the functions provided by the wrapper and context classes. On the other hand, the dynamic container must also provide facilities to adapt the component executors. For example, if a new facet is added to the component definition, then the component executor must provide the new facet implementation. This is done by the definition of a segment constructor, i.e. a function used to create an object that implements an added facet or event sink and is added to the component executor as a new segment. The segment constructor is added to the wrapper class definition as a new field and can be used by the wrapper object to retrieve a facet or event sink implementation when necessary. When the adaptation is done only in a single instance of a component, the segment constructor is added directly as a field of the wrapper object. It is worth noticing that all component interactions are done by means of the wrapper and context objects. This enables the introduction of interceptors to handle the interactions of the component. The use of interceptors is useful to change the current behavior of a component, e.g. the services provided by a facet. As segment constructors, interceptors are defined as fields in the wrapper object or class. When a wrapper object receives a request to a port, it checks

if there is a defined field that specifies an interceptor for that port; if so, the interceptor is invoked to treat the request properly. The next section describes how the features of the dynamic container are used to implement the reflective facilities provided by LuaCCM components that allow fine-grained adaptations by changes on component definition and implementation. 3.2 Reflective Components LuaCCM dynamic containers can be dynamically adapted to provide the required facilities for a new component definition. Similarly, the same feature can be used to adapt the container to some modification on component definition. We propose the use of reflective facilities to manipulate components. Basically, we define mechanisms for introspection and intercession [14] of components definition and implementation. The CCM specification defines interfaces for introspection of component definition that are supported by all components. Those interfaces are used to retrieve information about the ports of a component, like their names, interfaces provided or requited, events emitted or consumed, etc. Additionally, those interfaces provide generic operations to manipulate component ports, for example to connect an object to a component receptacle given the name of the receptacle. However, CCM does not provide mechanisms to define changes on component structure (i.e. definition) or implementation. As a new intercession mechanism, we provide an interface called ::LuaCCM::Adaptable that provides operations to add or remove component ports, as well as to attach interceptors to existing ports. Fig. 4 illustrates the interfaces defined by LuaCCM, suppressing exception statements for sake of simplicity. The operations on ::LuaCCM::Adaptable interface for addition of ports receive as arguments the name of the new port and, in the case of facets or receptacles, the interface provided or required, and, in case of event sources and sinks, the event emitted or consumed. Notice that add facet and add consumer operations receive an additional parameter containing a piece of Lua code that defines the implementation of the added facet or event sink segment. Similarly, the operation intercept, used to attach an interceptor to a component port, also receives a parameter containing a piece of Lua code that defines the implementation of the port interceptor. LuaCCM interceptors are common Lua objects that provide interception operations, namely a before operation and an after operation. Both operations receive the self parameter used to identify the interceptor object that is notified of the method called, plus the request parameter, which is a table containing information about the intercepted request, such as the port name, port segment, operation name and parameters, etc. As one may suppose, the before operation is invoked just before an interaction is started through the component port, such as the execution of an operation on a facet or on an object connected to a receptacle, or even before the processing of a received event, or the emission of a new event. Additionally, the interaction can be cancelled and never passed to the component executor. To do so, the before operation must define the return values of the intercepted operation in the table containing information about the

1 module LuaCCM { 2 typedef string LuaCode ; 3 4 interface Adaptable { 5 void add_ facet ( in string name, in string iface, 6 in LuaCode code ); 7 void add_ receptacle ( in string name, in string iface, 8 in boolean ismultiple ); 9 void add_ emitter ( in string name, in string event_ type ); 10 void add_ publisher ( in string name, in string event_ type ); 11 void add_ consumer ( in string name, in string event_ type, 12 in LuaCode code ); 13 void remove_ port ( in string name ); 14 void intercept ( in string point, in LuaCode code ); 15 void unintercept ( in string point ); 16 }; 17 18 interface AdaptableContainer : :: Components :: Container { 19 Adaptable get_ component_ adaptor ( in string name ); 20 }; 21 }; Fig. 4. LuaCCM adaptation interface. intercepted request. In case of intercepted event ports, since the event handler method returns no value, the before operation must define an empty list of return values prior to canceling the processing of the event. Similarly, the after operation is invoked after an interaction is performed through the component port. Fig. 5 illustrates the definition of an interceptor. 1 interceptor = { 2 before = function ( self, request ) 3 <implementation> 4 end, 5 after = function ( self, request ) 6 <implementation> 7 end, 8 } Fig. 5. LuaCCM interceptor definition. The reflective features of LuaCCM components can be used to provide a seamless mechanism of dynamic adaptation without additional effort of the system developer. However, dynamic adaptation is generally a complex task, mainly

because it is a peculiar form of system development that is done while the system is running. Like usual system development, dynamic adaptation can be improved by the use of programming abstractions and tools based on those abstractions. In the next section, we discuss how the features provided by LuaCCM infrastructure can be used as a basis for implementation of programming abstractions for dynamic adaptation of computer systems. 4 Adaptation Abstractions LuaCCM provides reflective mechanisms to perform fine-grained adaptations on component systems through the use of interfaces that can be used by any CORBA application to introduce changes on the system. However, the direct use of these interfaces remains a complex task. Using Lua s facilities, we can use LuaCCM as a basis for providing the programmer with different abstractions that organize the adaptation in a structured and modularized way. This organization makes the adaptation easier to design and understand, since a set of changes related to some particular subject or purpose can be separated into groups defining some particular aspect or functionality of the system. As a validation of this approach, we implemented a tool based on abstractions called protocols and roles. 4.1 Protocols and Roles [5] proposes the abstractions of protocols and roles to describe dynamic adaptations of running applications developed using the middleware Comet. A role is an abstraction used to define a set of characteristics (defined as a set of changes) that a component must provide prior to producing new behavior (or performing a new role ). More specifically, those changes are defined as a set of new connectors (i.e. ports) and changes on original connectors by use of interceptors. On the other hand, a protocol is an abstraction used to describe how a set of roles are applied to different components, and how those modified components are connected to produce the new aspect or functionality of the system. The protocol is defined by a set of scripts, each one defining how roles are applied and components are combined to produce one different feature. The protocols can optionally define an internal state. With the data-description facilities of the Lua language, we can provide a simple way to describe roles for CCM components, i.e. describe a list of added and intercepted ports, including the interfaces or events used, as well as the port or interceptor implementation when necessary. The structure of a role description in Lua using our proposed tool is illustrated in Fig. 6, where the role defines a new facet called inspector, including its implementation code defined as a string (Lua uses the [[ ]] delimiters to declare multi-line spanning strings) that creates an object (table) with two operations. The added facet provides the operation get field, which returns a string representation of the value of a field on the object implementing some component segment. Additionally, we

can use the extension mechanisms of Lua to define special semantics for role definitions, in such a way that the changes described can be translated to a sequence of operation calls on the adaptable interface of a LuaCCM component. As an example, Fig. 7 shows the sequence of operation calls to apply the changes defined by the role on Fig. 6 using the LuaCCM adaptable interface. 1 Inspectable = loaf. Role { 2 provides = { 3 inspector = { 4 interface = " eventflow :: distdebug :: Inspectable ", 5 code = [[{ 6 get_ field = function ( self, port, field ) 7 local executor = self. context : get_ executor ( port ) 8 return executor [ field ] 9 end, 10 }]], 11 }, 12 }, 13 } Fig. 6. Example of role definition using LuaCCM that provides inspection facilities. 1 adaptor = component : provide_ facet (" adaptation ") 2 adaptor : add_facet ( 3 " inspector ", " eventflow :: distdebug :: Inspectable ", 4 [[{ 5 evaluate = function ( self, port, field ) 6 return self. context : get_ executor ( port, field ) 7 end, 8 }]]) Fig. 7. Example of role definition using LuaCCM that provides reflective facilities. The implementation of the protocol abstraction in Lua is even simpler. A protocol can be described as a set of functions implementing the scripts used to apply roles and connect components. Alternatively, those functions can be stored in a table or used to define an object. In the last case, the protocol can use the internal state provided by the Lua object in the execution of protocol scripts. Fig. 8 illustrates the definition of a protocol, defined as a Lua object, that uses the Inspectable role of Fig. 6 to inspect components. The next section presents a dynamic adaptation of a hypothetical event-based application using

our tool based on protocols and roles. All the examples illustrated in the current and next sections are based on examples described in [5]. 1 InspectionProtocol = { 2 inspect = function ( self, component, port, field ) 3 Inspectable : assign ( component ) 4 local inspector = component : provide_ facet (" inspector ") 5 local value = inspector : get_ field ( port, field ) 6 Inspectable : unassign ( component ) 7 return value 8 end, 9 } Fig. 8. Example of protocol definition as a Lua object. 4.2 Use Examples To illustrate the use of our tool, we implemented an event-based application using our prototype of LuaCCM, which implements all the featured presented in this paper. This example application consists of an event producer component and two other components that process the produced events. The component server produces events and sends them through an event source called produced. On the other side, the components client1 and client2 receive the produced events through an event sink called raw. The events are processed and sent back to the server, as requests for a new event, through the event source done, which is connected to the request event sink on the server. Fig. 10 shows the definition of the example application components, interfaces and events in IDL 3.0. As an example of a possible adaptation, we discuss the dynamic inclusion of a mechanism for event flow synchronization that avoids that some client component gets stuck with an overloaded amount of unprocessed events. To do so, we define two roles: the FlowWatcher role that defines the new functionality required by the synchronized processing component, and the FlowRegulator role that defines the new functionality required by the producer component. The interfaces used by the flow synchronization roles are listed in Fig. 11 The FlowWatcher adds the functionality needed to analyze the flow of events received by a processor component, in order to identify flow glitches, i.e. when the amount of received events is greater than the processing capacity of the component. The new functionality is provided by the interception of port raw and addition of two ports: the facet limit, used to define a processing time upper limit used to trigger the synchronization, and the receptacle regulator, that provides the interface used to regulate the event production rate at the server when a glitch is identified. Fig. 12 shows the definition of the FlowWatcher. The flow analysis is done by the interception of port raw, which captures the

Fig. 9. Example event based application architecture. 1 module eventflow { 2 interface Instrumented { 3 attribute string name ; 4 attribute float speed ; 5 }; 6 interface Controlable { 7 void start (); 8 void stop (); 9 void pause (); 10 void continue (); 11 }; 12 eventtype SerialEvent { 13 public long seq_no ; 14 }; 15 component Producer supports Instrumented { 16 provides Controlable controller ; 17 consumes SerialEvent request ; 18 publishes SerialEvent produced ; 19 }; 20 home ProducerHome manages Producer {}; 21 22 component Processor supports Instrumented { 23 consumes SerialEvent raw ; 24 emits SerialEvent done ; 25 }; 26 home ProcessorHome manages Processor {}; 27 }; Fig. 10. Example event based application using LuaCCM.

1 module eventflow { 2 module flowsync { 3 interface Rateable { 4 void set_ rate ( in double rate ); 5 }; 6 interface Limited { 7 attribute double value ; 8 }; 9 }; 10 }; Fig. 11. Interface used by flow synchronization roles time immediately before the event is processed by the component, and later calculates the total processing time, when event processing is completed. If the event processing time is larger than the limit defined at the limit facet executor (LuaOrb maps attributes to Lua object fields), then the object connected to the regulator receptacle is used to define a proper event production rate. However, the original event producer component does not provide functionality to regulate event production rate. Therefore, we define the FlowRegulator role to add this functionality to the server component. This is done by adding a new facet and the interception of port produced, that is used to send produced events. The added facet is called rater and is used to define the rate of events produced by the component, that is stored as a field of the context object (the context object can be used as a state shared by all component segments). This way, every time a new event is produced and sent through the produced port, it is intercepted by the FlowRegulator role that calculates the time elapsed since the last event was produced. If this time is shorter than the current event production rate, then a delay is inserted prior to sending the event. Fig. 13 shows the definition of the FlowRegulator role. In spite of the functionality provided by the roles appliance, to produce the desired result we also need to establish new connections using the added ports. Therefore, to conclude our example we define a flow synchronization protocol as illustrated in Fig. 14. This protocol creates an object with the sync operation used to synchronize two components by applying the previously presented roles and establishing the required connections between the modified components. LuaCCM provides simplifications to handle component ports as object fields as shown on sync operation. Those simplifications hide part of CCM complexity related to connection of ports. 5 Related Work Several works address the problem of modifying computer systems at runtime [3]. However most of the mechanisms proposed in literature are aimed at coarsegrained adaptations through the use of reconfigurations using different approaches,

1 FlowWatcher = loaf. Role { 2 provides = { 3 limit = { 4 interface = " eventflow :: flowsync :: Limited ", 5 code = [[ { value = 0.05 } ]], 6 }, 7 }, 8 uses = { 9 regulator = { interface = " eventflow :: flowsync :: Rateable "}, 10 }, 11 before = { 12 raw = { 13 code = [[ 14 function ( self, request ) 15 request. start_ time = get_ time () 16 end 17 ]], 18 }, 19 }, 20 after = { 21 raw = { 22 code = [[ 23 function ( self, request ) 24 local now = get_ time () 25 local time_ spent = now - ( request. start_ time or now ) 26 local limit = request. context : get_ executor (" limit ") 27 if time_ spent > limit. value then 28 local regulator = request. context : get_ connection_ regulator () 29 if regulator then regulator : set_ rate ( time_ spent ) end 30 end 31 end 32 ]], 33 }, 34 }, 35 } Fig. 12. FlowWatcher role definition.

1 FlowRegulator = loaf. Role { 2 before = { 3 produced = { 4 code = [[ 5 function ( self, request ) 6 local now = get_ time () 7 local last = self. last or now 8 self. last = now 9 local time_ spent = now - last 10 if request. context. rate and 11 time_ spent < request. context. rate then 12 sleep ( request. context. rate - time_ spent ) 13 end 14 end 15 ]], 16 }, 17 }, 18 provides = { 19 rater = { 20 interface = " eventflow :: flowsync :: Rateable ", 21 code = [[{ 22 set_ rate = function ( self, rate ) 23 self. context. rate = rate 24 end, 25 }]], 26 }, 27 }, 28 } Fig. 13. FlowRegulator role definition. 1 FlowSyncProtocol = { 2 sync = function ( self, server, client ) 3 FlowRegulator : assign ( server ) 4 FlowWatcher : assign ( client ) 5 client. regulator = server. rater 6 end, 7 unsync = function ( self, server, client ) 8 client. regulator = nil 9 FlowRegulator : unassign ( server ) 10 FlowWatcher : unassign ( client ) 11 end, 12 } Fig. 14. Flow synchronization protocol definition.

as for instance the ones discussed in [15]. Our group have been investigating different dynamic adaptation techniques based on the features provided by interpreted languages. In that sense, using the features of the Lua language, we have proposed many platforms and architectures using different approaches to perform dynamic adaptations, such as LuaOrb [9] that provides a dynamic binding for CORBA that can be used to perform fine-grained adaptations on CORBA objects [16]; ALua [10], an event-based asynchronous platform for parallel applications that allows dynamic definition of code to be executed on different computing nodes; and LuaTS [12], a reactive event-driven tuple space. Similarly, other works use the features of the Lua language to perform reconfigurations, like LuaSpace [11], that provides features that add flexibility to perform reconfiguration of CORBA-based applications. The architecture for self-adaptive CORBA based applications proposed in [13] provides mechanisms to start reconfigurations based on monitoring facilities. Other groups have also proposed infrastructures to perform fine-grained adaptations, like the Lasagne model presented in [17] that uses additional information inserted on component requests to dynamically select different adaptations on system components by selection of wrappers that intercept component interactions. Every collaboration started by a new client request defines the set of wrappers that must be applied to the component prior to handling request properly. Differently from the LuaCCM model, Lasagne provides means to consistently apply adaptations over a distributed environment, as well as to maintain different client-specific views of the performed changes. Still on the subject of fine-grained adaptations, [5] points out the necessity of abstractions for such adaptations by the proposition of the protocol and roles abstractions to describe dynamic adaptation of applications developed using the Comet asynchronous event-based middleware. Our work uses the LuaCCM features to provide the same abstractions for CCM applications with a complexity compatible to the original approach on Comet middleware, validating the applicability of those abstractions on more complex component models. By adopting a layered approach, we hope to be able to provide a range of abstractions built on LuaCCM, instead of focusing only on one specific adaptation abstraction. 6 Final Remarks In the past we have explored the flexibility that the use of an interpreted, dynamically-typed language can bring to component-based programming. We believe that the work in this paper goes one step further in this direction. On one hand, we discussed how Lua (or an alternative language with similar features) allows simple adaptation abstractions to be built on top of a standard model for component management and configuration. On the other, we showed that component models themselves can be more flexible and admit more powerful adaptation mechanisms when designed with such a language. The basic LuaCCM features, inherited directly from CCM, allow for coarse-grained adaptation, providing mechanisms for application reconfiguration through the definition of new

connections. With dynamic containers and reflective components, we gain the possibility of fine-grained adaptation, through changes on component definition and implementation. Such adaptations are important to add more flexibility prior to better adapt the system in face of requirement changes not predicted on its original design. In this work we explored only the protocols and roles abstractions. However, we intend to implement other adaptation abstractions with similar purposes, such as the idea of dynamic contracts based on the coordination-oriented approach proposed in [18]. A contract defines the computation related to coordination of interactions between system components, which is merged into component implementation prior to result in a coordinated group of components. We intend to use the fine-grained adaptations mechanisms of LuaCCM to provide means to specify and change contract definition at runtime. Alternatively, we plan to investigate the use of aspect-oriented abstractions that can be implemented using the interception facilities of LuaCCM components and may be useful to define and adapt crosscutting concerns of component-based systems. We believe the mapping of these abstractions to LuaCCM will be easy, and will enable us to experiment with coordination, aspects and other abstractions in component-based applications. The use of a C++ ORB in the implementation of LuaOrb provides means of reducing performance problems due to the use of an interpreted language like Lua. Additionally, Lua presents good performance results if compared with other scripting languages [19]. However, we intend to provide performance comparisons of LuaCCM with other CCM implementations, like MICO and OpenCCM. We would specifically like to study adaptations that need some type of atomicity. One example is that of adaptations spanning different containers. Although it is possible to apply a sequence of modifications over different containers, there is no guarantee of atomicity: it is possible that client applications see inconsistent states where only some of the containers have been modified. Another example is that of a sequence of modifications over one same container that should be viewed as a single adaptation step. We intend to study the requirements of these adaptations and eventually include new mechanisms to support them in LuaCCM. Finally, we believe that the features provided by LuaCCM compose an appropriate environment for experimentation on dynamic adaptation, especially on evaluation of different approaches considering aspects like simplicity or applicability. References 1. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, Boston, USA (1994) 2. Gouveia, J., Koutsoukos, G., Andrade, L., Fiadeiro, J.: Tool support for coordination-based software evolution. In Pree, W., ed.: Proceedings of TOOLS Europe 2001, Zurich, Switzerland, IEEE Press (2001) 184 196

3. Liu, X., Yang, H., eds.: Proceedings of the International Symposium on Principles of Software Evolution 2000, Kanazawa, Japan, IEEE Press (2000) 4. Ierusalimschy, R., Figueiredo, L.H., Celes, W.: Lua an extensible extension language. Software: Practice and Experience 26 (1996) 635 652 5. Peschanski, F., Briot, J.P., Yonezawa, A.: Fine-grained dynamic adaptation of distributed components. In Endler, M., Schmidt, D., eds.: Proceedings of Middleware 2003. Volume 2672 of Lecture Notes in Computer Science., Rio de Janeiro, Brazil, Springer-Verlag (2003) 123 142 6. Object Management Group Needham, USA: CORBA Component Model - Version 3.0. (2002) document: formal/2002-06-65. 7. Wang, N., Schmidt, D.C., O Ryan, C.: An overview of the CORBA component model. In Heineman, G., Councill, B., eds.: Component-Based Software Engineering. Addison-Wesley Professional, Boston, USA (2000) 8. Stein, L.A., Lieberman, H., Ungar, D.: A shared view of sharing: The Treaty of Orlando. In Kim, W., Lochovsky, F.H., eds.: Object-Oriented Concepts, Databases and Applications. ACM Press/Addison-Wesley, Boston, USA (1989) 31 48 9. Cerqueira, R., Cassino, C., Ierusalimschy, R.: Dynamic component gluing across different componentware systems. In: Proceedings of DOA 99, Edinburgh, Scotland, IEEE Press (1999) 362 373 10. Ururahy, C., Rodriguez, N., Ierusalimschy, R.: ALua: Flexibility for parallel programming. Computer Languages 28 (2002) 155 180 11. Batista, T., Rodriguez, N.: Dynamic reconfiguration of component-based applications. In: Proceedings of PDSE 2000, Limerick, Ireland, IEEE Press (2000) 32 39 12. Leal, M., Rodriguez, N., Ierusalimschy, R.: LuaTS - a reactive event-driven tuple space. Journal of Universal Computer Science 9 (2003) 730 744 13. Moura, A.L., Ururahy, C., Cerqueira, R., Rodriguez, N.: Dynamic support for distributed auto-adaptive applications. In Wagner, R., ed.: Proceedings of ICDCS 2002, Vienna, Austria, IEEE Press (2002) 451 458 14. Demers, F.N., Malenfant, J.: Reflection in logic, functional and object-oriented programming: a short comparative study. In: Proceedings of Workshop on Reflection and Metalevel Architectures and their Applications in AI (IJCAI 95), Montreal, Canada, IJCAII/AAAI/CSCSI, Morgan Kaufmann (1995) 29 38 15. Tosic, V., Pagurek, B., Esfandiari, B., Patel, K.: On various approaches to dynamic adaptation of distributed component compositions. Technical Report OCIECE-02-02, Ottawa-Carleton Institute for Electrical and Computer Engineering (OCIECE), Ottawa, Canada (2002) 16. Martins, M.C., Rodriguez, N., Ierusalimschy, R.: Dynamic extension of CORBA servers. In Amestoy, P., Berger, P., Daydé, M., Duff, I., Frayssé, V., Giraud, L., Ruiz, D., eds.: Proceedings of Euro-Par 99. Volume 1685 of Lecture Notes in Computer Science., Toulouse, France, Springer-Verlag (1999) 1369 1376 17. Truyen, E., Vanhaute, B., Jørgensen, B.N., Joosen, W., Verbaeton, P.: Dynamic and selective combination of extensions in component-based applications. In: Proceedings of ICSE 2001, Toronto, Canada (2001) 233 242 18. Andrade, L.F., Fiadeiro, J.L.: Coordination: The evolutionary dimension. In Pree, W., ed.: Proceedings of TOOLS Europe 2001, Zurich, Switzerland, IEEE Press (2001) 136 147 19. Calpini, A.: Computer language shootout. http://dada.perl.it/shootout/ (2003)