Software Component Re-engineering for their Runtime Structural Adaptation

Gautier Bastide, Abdelhak SeriaiEcole des Mines de Douai,941 rue Charles Bourseul,

59508 Douai, France{bastide, seriai}@ensm-douai.fr

Mourad OussalahLINA,

2 rue de la Houssiniere,44322 Nantes, France

oussalah@lina.univ-nantes.fr

Abstract

Adapting software components to be used in a particularapplication is a crucial issue in software component-basedtechnology. In fact, software components can be used incontexts with characteristics different from those envisagedwhen designing the component. To deal with this issue, wepropose in this paper an approach aiming at adapting asoftware component structure in order to preserve servicecontinuity. This adaptation, achieved by component frag-mentation, allows its structure reconfiguration and its re-deployment while preserving its behavior and its services.The structural adaptation process is based on two phases.The first one consists of the component re-engineering inorder to introduce runtime adaptation facilities. The sec-ond phase, achieved since runtime, aims at reconfiguringthe component structure according to the user needs.

1 Introduction

Component-based software engineering (CBSE) focuseson reducing application development costs by assemblingreusable components [5]. However, in many cases, exist-ing components can not be used in an ad-hoc way. In fact,using a software component in a different manner than forwhich it was designed is a challenge because the new use-context can be inconsistent with assumptions made by thecomponent designer. For example, let us consider a soft-ware component which has been designed as a monolithicunit to be deployed on a centralized infrastructure. If weimagine that this component is required to create a new ap-plication. However, due to load balancing performance, se-curity policy or other motivations, this component has tobe distributed. Either, this component is developed again,either it is adapted in order to satisfy the new needs.

While being based on the above considerations, we pro-

pose a software component restructuring approach1. Webase ourselves on previous results [1]. In these works, struc-tural adaptation is achieved by a static way. In this case,a component has to be stopped for adapting it. Neverthe-less, in many cases where service continuity is required,the proposed approach cannot be used. Therefore, we pro-pose, in this paper, an approach allowing runtime structuraladaptation. In this case, adaptation is achieved through aprocess based on two phases. The first one, achieved be-fore deployment, consists of generating components whosestructure is runtime-adaptable, from existing components.This component generation, called re-engineering phase, isbased on source-code analysis and code-generation. Thesecond phase, achieved since runtime, allows the applica-tion administrator to adapt a runtime-adaptable component,by the reconfiguration of its internal structure.

We discuss the proposed approach as follows. Section 2presents the structural adaptation and section 3 details thetwo phases of our process. Section 4 presents an evaluationof our approach. Section 5 reviews related work. Finally,conclusion and future works are presented in section 6.

2 Structural adaptation of components

Structural adaptation of a software component consistsof updating its structure while preserving its behavior andits services. The structure of a component consists of thelist of the structural entities, defined in this component. Astructural entity refers to all elements identifiable in a singleway and contained in the component structure. The struc-tural entities can be external or internal ones. In fact, the ex-ternal structural entities are the interfaces, the classes or themethods directly implementing services provided by theseinterfaces. The internal structural entities are the internalmethods, variables or classes.

In this paper, we focus on adapting a component by

1This work is supported by the CPER TAC of the region Nord-Pas deCalais and the european fund FEDER.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

its fragmentation in some sub-components where the setof provided services must be the same ones as those pro-vided by the component before its adaptation. Each gen-erated sub-component can be considered as a deploymentunit which can be handled independently. This property isuseful for adapting components to their deployment envi-ronment, taken into account resource-constrained, networkperformance evolutions, resource availability, etc.

3 Structural adaptation process

The runtime structural adaptation of a component by itsfragmentation in elementary components is based on intro-ducing automatically a new property into the component(re-engineering phase), which allows it to adapt its struc-ture since runtime (Fig. 1).

Figure 1. Structural adaptation process

3.1 Software component re-engineering

The re-engineering phase aims at automatically generat-ing components which are able to be structurally adaptedsince runtime. This operation is achieved through the trans-formation of the component structure to be conformed to acanonical format using code-analysis and code-generation.In fact, a component conformed to a canonical formatis a composite-component whose sub-components calledunbreakable-components, cannot be fragmented.

3.1.1 Unbreakable-component specification

The first stage of the re-engineering process consists ofspecifying the components which will be used as buildingblocks for runtime structure-reconfiguration. These sub-components provide each one an sub-set of the services pro-vided by the initial component. By default, each interfaceprovided by the component to adapt is reified in component,so as to ensure a large flexibility of the component. Theunbreakable-component specification can also be achievedby an administrator using a script based on an XML lan-guage. This script consists of specifying the unbreakable-components through their provided interfaces.

3.1.2 Canonical-component generation

To generate such component from an existing one, we useour static structural adaptation process [1]. This transforma-tion process, achieved by an automatic way, is composed ofthree stages: first, the initial component is fragmented into aset of new components providing each one only one serviceof the initial component, while guaranteeing component in-tegrity and coherence. Then, the interface-components areassembled, taking into account their dependencies (i.e. hor-izontal assembly). Finally, this assembly is encapsulatedinto a composite-component, providing the same servicesthan those of the initial component (i.e. vertical assembly).

3.2 Runtime structural adaptation

The second phase of our approach aims at achieving theruntime reconfiguration of the component in order to matchits structure with specific needs related to its use. The com-ponent structure corresponding to the use context is de-scribed by an adaptation script given by the administrator.

3.2.1 Runtime adaptation management

To adapt a component structure consists of generating a newcomponent whose structure matches with user needs. Thespecification of the new needed structure is achieved by theapplication administrator. It consists of specifying, using ascript, the new components to generate, through their sub-components (i.e. unbreakable-components) and their de-ployment host. Each specified component is composed of aset of unbreakable-components which is a sub-set of thosecontained in the adaptable component.

3.2.2 Runtime reconfiguration process

The component which has to be adapted in order to satisfyuser needs, is conformed to a canonical format since run-time. Thus, the generation of the new structure is obtainedstarting from this format. This operation consists of build-ing, on the fly, new components by assembling the existingunbreakable-components: each new component becomes acomponent-composite whose components are unbreakable-components. In fact, each new composite-component en-capsulates all the interfaces provided and required by itssub-components. The latter will not be visible any moreand they will be accessible only by the interfaces from itscontainer-component. Thus, each composite provides theset of services provided by its sub-components. Moreover,it defines as required interfaces, those required by its sub-components, excluded those provided by others of its sub-components. Thereafter, the new generated componentswill be handled like deployment units.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

Figure 2. Runtime reconfiguration process

The reconfiguration of the component conformed to thecanonical format is achieved as follow (Fig. 2): first ofall, (1) the new components defined during the specifica-tion stage are created. The provided interfaces are thosespecified in the adaptation script and the required interfacesare those required by its sub-components, excluded thosewhich it provides. Then, (2) the sub-components corre-sponding to interfaces provided by the components to gen-erated are added to the composite. Then, (3) the directconnections between the composite and its sub-componentsare disconnected then (4) re-connected with interfaces pro-vided by the composite sub-components previously gener-ated. This operation is achieved using export connections.(5) The required interfaces of the sub-components and sub-composites are then re-connected. If an interface requiredby a sub-component is provided by another sub-componentof the sub-composite then connection is achieved by a di-rect way. In contrary, when an interface required by a sub-component is provided by another application component,it is needed to destroy existing connections and to create anexport connection with the required interface of the corre-sponding sub-composite. Lastly, (6) connections betweenrequired interfaces of the sub-composites and their corre-sponding provided interfaces or a required interface of thecomposite must be setup. In the first case, the interface isprovided by another sub-composite: a direct connection be-tween these two interfaces is created. In the second case,the service is provided by another component: an exportconnection is set up between the required interface of thesub-composite and the corresponding one of the composite.

3.2.3 Runtime component-redeployment

The runtime redeployment consists of deploying, on remotesites, the sub-components generated during the reconfigura-tion of the adaptable component.

The redeployment process is achieved as follow: first, acopy of the component to be redeployed must be sent to theremote site without stopping the local component. Then,the calls of services provided by the component to trans-fer are intercepted by a connection component introducedbeforehand. When the component to be redeployed is in astable state (no service is executed), this one is stopped andits state is transferred to the remote component. The mes-sages put on standby during the stop of the component arethen redirected to the new component located on the remotesite. This process is detailed in the figure 3.

Figure 3. Runtime redeployment process

To ensure the runtime redeployment of the sub-components resulting from the adaptation, we must, on theone hand, add to each component, new interfaces allowingthem to carry out the state transfers from local componentsremote ones. We consider a software component state as theset of the states of its resources. The added interfaces allowthe component to save or load its state.

In addition, we introduce special components, calledconnector components, aiming at achieving connection be-tween the generated components and guaranteeing the com-posite integrity. Their roles are (1) to intercept the messagesentering the component which has to be redeployed, sincethe component unavailability, (2) to carry out the state trans-fer between the two component copies and finally (3) to en-sure communications between remote components.

4 Evaluation of our approach

As we previously mentioned in our motivations, ourapproach aims at ensuring service continuity in resource-constrained environment. However, an overhead is intro-

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

duced when the component is conformed to the canonicalformat. In fact, the generation of unbreakable-componentsinvolves the introduction of mechanisms allowing us toguarantee their behavior. They consist of the behav-ioral dependences setup (Ccomp) and the shared-resourcemanagement i.e. notification (Cnotif ) and synchroniza-tion (Csynch). Thus, the more the component containsunbreakable-components, the more the overhead is consid-erable and the more it has a flexible structure because thenumber of possible assembly combinations is high. So,component flexibility involves a component-performancedegradation which can be reduced through service paral-lelization (Gparal) when sub-components are distributed.

Cglobal = Ccomp + Cnotif + Csynch − Gparal (1)

The overhead related to the behavioral dependencessetup (2) is essentially due to the transformation of method-calls within an implementation-class into calls of servicesprovided by other unbreakable-components. Another causeof this overhead is due to the transfer of service-invocationsfrom one component to another deployed on a remote host.It depends on technical features of the available infrastruc-ture and its use ratio. It is considerable but needed for com-ponent distribution.

Ccomp = m ∗ a ∗ ∆ Where ∆ = CS/C − CM/O + CTS (2)

m : Number of provided services a : Number of service-calls

CTS : Transferring-message cost to a remote component

CS/C : Cost of a service-call CM/O : Cost of a method-call

Because of the resource sharing between severalunbreakable-components, we introduced notification (3)and synchronization (4) operations. Notification mecha-nisms allows a component to notify resource-update, bysending a message to all other components sharing the sameresource. The notification cost depends on the infrastructurefeatures and the bandwidth available. Synchronization al-lows a component to manage the multiple and simultaneousaccess to a resource by the setup of the critical-sections.

Cnotif = n∗m∗r∗c∗CR/C Where CR/C = n∗2∗CS/C +CR/M

(3)Csync = n∗m∗c∗CSc/C Where CSc/C = n∗4∗CS/C +CAsc/M

(4)

m : Number of services provided by the initial component

c : Number of critical-sections within a service

n : Number of unbreakable-components r : Number of shared-resources

CR/C : Update-notification cost CR/M : Update-resource cost

CSc/C : Critical-section setup cost CAsc/M : Critical-section starting cost

5 Related work

Software restructuring, also called refactoring when usedin the context of object-oriented frameworks [4], is a tech-nique that may be applied to improve the structure of a

software system. Among restructuring techniques, appli-cation partitioning refers to, breaking up of this applicationinto software part while preserving the semantics of originalapplication. However, few works focusing on partitioningsoftware components were proposed.

The Coign project [2] is an automatic partitioning systembased on Microsoft’s COM model. Coign aims at trans-forming applications built from distributable COM compo-nent in binary form into distributed ones. However, Coigndoes not take into account all partitioning issues.

Jamwal and Iyer propose in [3] to create breakable ob-jects, called BoBs, in order to build flexible architectures.A BoBs is an entity in a program that can be readily splitinto sub entities. Bob imposes restrictions on breakable ob-ject. For example, in their Java implementation, BoB classresembles a Java class except the restrictions that are placedon certain features (e.g. no public fields).

All existing approaches which aims at partitioning com-ponent structure are based on specific component models.And, no approach allowing an administrator to generatesuch components from an existing ones has been proposed.

6 Conclusion and future work

We presented in this article an approach allowing run-time adaptation of component structure. Adaptation isachieved through a process composed of two phases. Thefirst one allows us to transform a software component intoa canonical format permitting it to be runtime-adaptable.The second phase allows an administrator to adapt softwarecomponent structure since runtime. The proposed approachhas been implemented and a prototype is available.

In the current advance state of our approach, the adap-tation release and specification are achieved by an admin-istrator which specifies the needed component structure ac-cording to the deployment context. One of our future goalsis to automate these tasks and thus, to make a componentable to adapt itself according to its execution context.

References

[1] G. Bastide, A. Seriai, and M. Oussalah. Adapting softwarecomponents by structure fragmentation. In Proc. of Symp. onApplied Computing (SAC), pages 1751–1758, 2006.

[2] G. C. Hunt and M. L. Scott. The coign automatic distributedpartitioning system. In Proc. of Symp. on Operating SystemDesign and Implementation, pages 187–200, 1999.

[3] V. Jamwal and S. Iyer. Bobs: breakable objects. In Proc. ofOOPSLA ’05, pages 98–99. ACM Press, 2005.

[4] W. F. Opdyke. Refactoring Object-Oriented Frameworks.PhD thesis, Urbana-Champaign, IL, USA, 1992.

[5] C. Szyperski. Component software: beyond object-orientedprogramming. ACM Press/Addison-Wesley, 1998.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007