Developing Adapters for Structural Adaptation of Component-based Applications

Imen Ben Lahmar and Djamel Belaıd

Institut Mines-Telecom; Telecom SudParis; CNRS UMR SAMOVAR9 rue Charles Fourier, 91000 Evry, France

Email: {imen.ben lahmar, djamel.belaid}@telecom-sudparis.eu

Abstract—Building upon the Service Oriented Architec-ture, applications can be defined as an assembly of abstractcomponents that are resolved by integrating transparentlyfunctionalities provided by heterogeneous resources. However,applications in pervasive environments have to operate underhighly dynamic and unpredictable context. This may giverise to several problems denoting that there are mismatchesbetween their descriptions and the execution environments(e.g., heterogeneity of services discovery protocols). Therefore,there is a crucial need to adapt applications in order toovercome these mismatches. In this work, we present a dynamicstructural adaptation approach for abstract applications. Ourapproach is based on the transformation of applications byinjecting adapters into their descriptions with respect to theirfunctional behaviour. We propose a fine-grained template todefine these adapters. We also give an overview of some resultsof our evaluations to validate our approach.

Keywords-Structural adaptation, component-based applica-tions, adapter template, pervasive environments.

I. INTRODUCTION

Driven by the widespread of communication technologies

and mobile devices, there is a growing trend nowadays

for pervasive computing that allow users to access any

information using any device and any network at any time

[13]. In pervasive environments, applications are coopera-

tively executed by integrating transparently functionalities

provided by heterogeneous software and hardware resources.

Towards this evolution, Service Oriented Architecture

(SOA) has emerged as a computing paradigm that changed

the traditional way of how applications are designed. One

particular approach for developing SOA-based applications

is to use component-based application development. Build-

ing upon the SOA, it is possible to describe an application as

an assembly of abstract components (i.e., services). Thus, an

application can be crafted using a set of abstract components

requiring and providing services to/from one another. This

allows its execution by composing different components

provided by various devices.

However, applications in pervasive environments have to

operate under highly dynamic and unpredictable operating

conditions. User needs may change dynamically, availability

of resources may vary, devices may come and go at runtime,

etc.

These may give rise to several problems that can be

detected at init time or during the applications execution

denoting that there are mismatches between their descrip-

tions and the execution environments. These mismatches

imply that an application cannot be executed in the given

context or the new context if it changes. To overcome these

mismatches, we require to adapt the application’s structure

with respect to its functional behaviour in order to be

resolved and executed using the available resources of an

execution environment.

Let’s consider for example a user equipped with a mobile

phone. On the device, she/he has an application that provides

the functionality of displaying a video. The user is also able

to control the playback of the application. The application

can be represented by an assembly of abstract components,

which describe only their required or provided services

namely, controlling, displaying video and file retrieval. If the

user is in a pervasive environment consisting of a number of

devices, she/he may be able to use the functionalities pro-

vided by the other devices such as a larger screen to display

a video. This way the application can be resolved using the

hardware and software resources in the environment without

to be limited to the resources of the user’s phone.

The issue of resolution of abstract applications have been

tackled by many approaches [1] [3] [4] [11]. Nevertheless,

the resolution of abstract applications does not seem to

be a trivial task as many problems may be detected at

init time or during their execution that prevent them to be

executed successfully. For example, if the devices supporting

the video player application have heterogeneous interfaces

of connection (e.g., Bleutooth and Wifi), this implies a

mismatch between the application’s description and the

execution environment as it cannot be resolved in the given

context. To deal with such mismatch, the application must

be able to be adapted for its execution.

In literature, we distinguish two main adaptive techniques;

parametric and compositional mechanisms to adapt appli-

cations in pervasive environment [10]. The parametrization

technique aims at adjusting internal or global parameters,

while the compositional adaptation implies the modification

of a structure or a behaviour of an application in response

to the changes in its execution environment.

In [2], we proposed a structural adaptation approach that

modifies applications structures by adding adapters. These

adapters exhibit an extra-functional behaviour with respect to

the functional behaviours of applications. We have proposed

2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises

978-0-7695-5002-2/13 $26.00 © 2013 IEEE

DOI 10.1109/WETICE.2013.40

105

2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises

978-0-7695-5002-2/13 $26.00 © 2013 IEEE

DOI 10.1109/WETICE.2013.40

90

2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises

978-0-7695-5002-2/13 $26.00 © 2013 IEEE

DOI 10.1109/WETICE.2013.40

92

2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises

978-0-7695-5002-2/13 $26.00 © 2013 IEEE

DOI 10.1109/WETICE.2013.40

92

a template to define these adapters, which consist of a

compulsory adaptive logic component and an optional extra-

functional one.

In this paper, we propose a fine-grained description of

the adapter template. Using this fine structure will facilitate

the creation and integration of adapters into an application’s

structure and hence render the adaptation automatic. We

also present some experimentation results to validate our

approach.

The paper is structured as follows. Section II provides

an overview of existing related work. In Section III, we

give a fine description of the adapter template to define

adapters that are dynamically injected into a structure of

an application. We present some implementation details and

evaluation results in Section IV. Finally, Section V concludes

the article with some future directions.

II. RELATED WORK

The problem of adapting component-based applications

has been extensively studied in the literature. In this section,

we cite approaches that propose solutions to the structural

adaptation issue.

[5] [8] have investigated matching of Web service inter-

faces by providing a classification of common mismatches

between service interfaces and business protocols, and intro-

ducing mismatch patterns. These patterns are used to help

programmers to develop adapters by assisting them through

a semiautomated code development. A mismatch pattern

includes a template of adaptation logic that resolves the

detected mismatch. Developers can instantiate the proposed

template to develop adapters. For this purpose, they have

to specify the different transformation functions. They use

aspect-oriented approach to generate adaptation logic in

the form of adaptation aspects woven into the runtime to

the adapted services. However, their proposed mismatch

patterns are limited to the interfaces and protocols mis-

matches. Moreover, the specification of adapters supplies

some pseudo code predefined by the developers. Thus, it

is not possible to integrate them dynamically at runtime

without the assistance of the developers.

[6] presents a formal methodology for adapting compo-

nents with mismatching interaction behaviour. For this, com-

ponents interfaces are extended with a description of their

behaviours. Based on these aspects, they propose to specify

adapters that consist of a set of correspondences between

actions and parameters of the communicating components.

Adapters are generated automatically to solve behavioural

mismatches of web services. This is done by building a

BPEL1 process of an adapter based on the BPEL processes

of the communicating web services to allow them to suc-

cessfully interoperate [7]. The BPEL process of an adapter

should mediate the interaction of two services by matching

1Business Process Execution Language

an asynchronous invoke operation with a receive one and

vice-versa. The major limitation of their approach is that the

adapters supply information about components behaviours.

Otherwise, the adaptation cannot be handled.

Another adaptation approach [12] aims to allow the

interoperability between components supporting different

interaction protocols at runtime. Their approach is based on

mediating connectors that are used to dynamically cope with

components’ behavioral diversity. The approach first decom-

poses the components’ behavior into elementary behaviors

representing their intents. Then, there is a need to check

the possibility for the two protocols to communicate. If the

two protocols are not complementary, the framework should

identify the mismatches in order to find out the suitable

mediating connector to use. Towards these mismatches,

they propose a list of mediator patterns given a mediator

connector template. Based on the identified mismatches and

their relative solutions, they intend to define a composition

strategy to build a mediating connector’s behavior starting

from the elementary mediating behaviors.

In [9], authors propose too to use mediation patterns to

overcome behavioral mismatches for web services interac-

tion. They have identified six mismatch patterns and pointed

out that all possible protocol mismatches can be composed

by these basic patterns. They propose an approach to semi-

automatically generating mediators for reconciling protocol

mismatches. The purpose is to introduce mediators when

composing services together in order to make both of the

requester and provider interfaces fit each other smoothly.

Each mediator is based on transformation rules to deal with

these interfaces. Therefore, a mediator pattern consists of

input interfaces that are used to receive messages sent from

a service requestor, output interfaces that are used to send

messages to a provider and a rule engine to determine

which transformation rule defined in the rule base should

be activated. However, these proposed mediators connectors

are limited to the protocol or signature level. Moreover, the

generation of adapters is semi-automatic as the developers

should specify the message mappings and adjust the selected

patterns.

III. SPECIFICATION OF ADAPTERS FOR STRUCTURAL

ADAPTATIONS

In [2], we proposed a dynamic structural adaptation

approach for abstract applications, which consists of trans-

formation of applications to overcome captured mismatches

at init time or during their execution. These mismatches may

denote the heterogeneity of devices or components character-

istics, e.g., heterogeneity of networks connections, protocols

interaction, etc. The transformation is ensured by injecting

some adapters exhibiting extra-functional behaviours into

an application’s structure without modifying its functional

behaviour. Its modified structure will allow it to overcome

106919393

the captured mismatches and to be executed in the given

context.

A. Structure of the Adapter Template

As the basis for our approach, we propose to use adapters

to provide solutions for the detected mismatches between

an abstract application and its execution environment. Pre-

viously, we defined an adapter template to be used for the

description of these adapters [2]. Following this template,

an adapter consists of a compulsory ”adaptive logic” and an

optional ”extra-functional” components as shown in Figure

1.

Figure 1. Structure of the adapter template

The adaptive logic component is considered as the main

element of the adapter template. Thus, each adapter should

contain at least the adaptive logic component. This compo-

nent encapsulates the adaptation logic and it has a generated

implementation byte code, since it depends on the business

interfaces of components. The adaptive logic component

may use a service provided by an extra-functional compo-

nent allowing, for example, encryption, compression, etc.

The extra-functional component has an abstract description

to be resolved when it is needed.

This structure of the adapter template allows the sepa-

ration of the adaptive logic from the functional logic of

the application and the extra-functional one. Thus, it is

possible to modify the adaptive logic without modifying the

functional behaviour of the application.

B. Fine-Grained Adapter Template

In [2], we identified a list of adapters that allows encryp-

tion, decryption, compression, splitting, etc. The structure of

these adapters follows the adapter template previously pre-

sented. These adapters may be used solely (e.g., proxy and

caching) or composed with other ones (e.g., compression and

decompression) to adapt an application’s structure. Whatever

the type of an adapter, its adaptive logic is generated as it

depends on the business interfaces of the communicating

components.

However, the generation of the adaptation logic does not

seem to be a trivial task as it depends on the complexity

of the injected adapter. For example, the generation of the

adaptive logic component of a proxy adapter is not handled

in the same way as the the adaptive logic components of the

splitting and merging adapters.

To avoid the generation of the whole adaptive logic com-

ponent, we propose to separate it into two components; 1) a

generated component that is the same for all adapters and 2)

an implemented component that represents the adaptive logic

of a specific adapter. This will minimize the generated part

in terms of time and code and hence facilitate the creation

of adapters.

For this purpose, we distinguish two composites to repre-

sent the fine-grained adapter template. These composites are

associated either with a caller component, which requires the

target service, or with a callee one that provides the intended

service.

If the adapter is associated with a caller component, its

adaptive logic consists of a generated proxy thats provides

the required service. Its contains also an implemented AL-

Adapter component that provides a service used by the proxy

component as shown in Figure 2.

Figure 2. Structure of an adapter template associated with a callercomponent

However, if the adapter is associated with a callee com-

ponent, its adaptive logic is structured following Figure 3.

The implemented ALAdapter component requires a service

offered by a generated proxy component, that in turns

invokes the service of the callee component.

Figure 3. Structure of an adapter template associated with a calleecomponent

Both of these composites consist of a generated proxy

component and an implemented ALAdapter one to represent

the adaptation logic of adapters. Each adapter should have

a proxy component whose interfaces match with the offered

and/or required services of the communicating components.

The implemented ALAdapter components represent the

adaptive logics and they are predefined by developers if

needed.

Using this specific structure of the adapter template has

an advantage, on the one hand, to extract the generated part

107929494

from an adaptive logic of an adapter. Thus, the generation of

the adaptive logic of an adapter is limited to the generation of

a proxy component that plays an intermediary role between

application’s components and an adapter composite. On the

other hand, whatever the complexity of the adaptive logic of

an adapter, the ALAdapter is implemented and predefined.

Thereby, the separation between the implemented (i.e., AL-

Adapter) and generated (i.e., Proxy) parts of an adaptive

logic minimizes the generated part in terms of time and code

and hence facilitates the creation of adapters.

C. Examples of Adapters DescriptionsWe have identified a list of adapters to restructure an

application allowing for example encryption, decryption,

compression, splitting, etc. In this section, we present some

examples of adapters that are defined using the fine-grained

adapter template to adapt the video player application de-

scribed in the introductory section.Assume that the video player application consists of

three abstract components namely a Controller component,

a DisplayVideo component and a FileServer component

as shown in Figure 4. The Controller component sends

commands to the DisplayVideo component that requests

the FileServer to get back the video. The resolution of the

application leads to use concrete components provided by

two devices; a user’s phone and a Flat Screen. The user

phone provides the Controller and FileServer components,

while the DisplayVideo component is provided by the Flat

Screen device.

Figure 4. Structure of the video player application

Assume that the user’s phone and the Flat Screen device

do not support the same connection interface (e.g., Bleutooth

and Wifi). To fulfill the execution of the video player

application, it is possible to adapt its structure by injecting

a proxy adapter in a third device that should support the

both connections interfaces. The proxy adapter represents a

specific case of the fine description of the adapter template as

it does not rely on any extra-functional service. Its adaptive

logic provides the functionality of forwarding a call of a

service to the target component. Therefore, its fine structure

contains only a proxy component as shown in Figure 5.In another context, assume now that the both devices

support for example a Wifi network whose bandwidth is

very weak. This may affect the transfer of frames to the

DisplayVideo component. To adapt the application to this

context, it is possible to use the compression and decom-

pression adapters for a quick transfer of messages over the

network.Figure 6 shows a fine description of the compression and

decompression adapters. The compression adapter is asso-

ciated with the FileServer component to send compressed

Figure 5. Fine structure of the proxy adapter

frames, while the decompression adapter is associated with

the DisplayVideo component to decompress the received

frames. To inject the compression adapter, there is a need

to generate the implementation of its proxy component as

it requires the FileServer service. Similarly, to integrate

the decompression adapter, there is a need to generate

the implementation of the proxy component that has to

provide the FileServer service to the display component.

The ALAdapter components of the adapters are implemented

and they require some extra-functional services allowing the

compression and decompression of messages.

The caching adapter may be used to adapt the video

player application in order to reduce the response time

to the DisplayVideo’s requests if it is above a certain

threshold. In this case, the caching adapter will be local

to the DisplayVideo component to cache the responses

received from the FileServer component. Figure 7 shows

a fine description of a caching adapter. The proxy of the

adapter is generated to provide the FileServer service to the

DisplayVideo component, while the ALCaching component

is implemented and has a reference to an extra-functional

service allowing the caching of messages, the access to

stored messages, etc.

Figure 7. Fine structure of the caching adapter

108939595

Figure 6. Fine structure of the compression and decompression adapters

IV. IMPLEMENTATION AND EVALUATION

A. Implementation

The adaptive logic of an adapter is composed of a proxy

component which has a generated implementation byte code,

and an ALAdapter component whose its implementation

is predefined. Hence, we require a byte code generator

for proxy components and implementations for ALAdapter

components.

For this, we implemented, as a proof of concept, java

prototypes of ALAdapters implementations that encapsulate

the adaptive logic of compression, encryption, etc.

For the proxy component, we developed a generator that

takes as parameters a list of interfaces names and returns

an object implementing these interfaces. For this, we used

the open source software JAVA programming ASSISTant

(Javassist2) library to generate the byte codes of the proxy

components of the adapters. Indeed, Javassist enables Java

programs to define a new class at runtime and to modify

a class file when the Java Virtual Machine (JVM) loads

it. Moreover, we used the java API java.lang.reflect to

obtain reflective information about classes and objects. This

information is used by the Javassist library to generate a

proxy component that implement specifics interfaces.

B. Evaluation

In this section, we are interested in knowing how quickly

the structural adaptation takes place to overcome the mis-

matches between applications descriptions and the execution

environment. Irrespective of the situation and the used

adapter, we need to generate the byte code of the proxy

component. Therefore, we have evaluated the structural

adaptation by calculating the time required for the generation

of the byte code of the proxy’s implementation. Through

the evaluations, we also aim to identify which factors have

2http://www.csg.is.titech.ac.jp/ chiba/javassist/

an important influence on the time required for a proxy

generation.

For this, we varied the number of methods and interfaces

between 1 to 200 as shown in Figure 8. To observe the

impact of methods’ variability, we fixed the number of

interfaces to 1. However, the number of methods is fixed

to 1 to evaluate the impact of the variability of number of

interfaces on the proxy generation’s time.

Figure 8. The effect of the variability of the number of methods andinterfaces on the generation of a proxy implementation

We deduce from Figure 8 that the number of interfaces

has more impact on the time needed for the generation of

the byte code of a proxy than the number of methods of an

interface. Indeed, the time required for the generation of a

proxy includes the time for loading interfaces classes from

a disk memory and the time of byte code class generation.

We also note that the time required for the generation of

a proxy takes few milliseconds. For example, to generate a

byte code of a proxy containing 200 methods and 1 interface,

this takes less than 400 ms.

We evaluated the both factors (number of interfaces and

109949696

methods) by varying the number of interfaces between 1 and

30, and the number of methods between 1 and 40, as shown

in Figure 9.

Figure 9. Generation of a proxy component by varying together the numberof methods and interfaces

We observe that the growth slope of the proxy generation

is largely small when it has 1 interface and 40 methods,

than the generation of a proxy having 30 interfaces. This

proves once again that the number of interfaces influences

more than the number of the methods on the time required

for the generation of a proxy’s byte code. Nonetheless, the

generation of a proxy does not take much time that is in

order of few milliseconds.

V. CONCLUSION

In this paper, we presented a fine-grained adapter template

to define adapters that are useful for a structural adaptation

of component-based applications. These adapters provide

an extra-functional behavior with respect to the functional

behavior of the application. They consists of a generated

proxy component that depends on the interfaces of the

communicating components, an implemented adaptive logic

component and an optional extra-functional one.

Using this fine description of the adapter template, the

generated part of an adapter is minimized in terms of time

and code and this facilitates the creation of adapters that

can be injected dynamically into an application structure. We

have shown through the evaluation results that the generation

of the adapters can be done in few milliseconds.

We are looking forward to validate the modified structure

of applications as a result of a structural adaptation. We

are interesting by the formal representation and verification

techniques which help us to check that the injected adapters

overcome the captured mismatches and do not modify the

functional behaviour of an application.

REFERENCES

[1] Christian Becker, Marcus Handte, Gregor Schiele, and KurtRothermel. Pcom - a component system for pervasive com-puting. In the Second Conference on Pervasive Computingand Communications, PerCom 2004, pages 67–76, Orlando,FL, USA, 2004.

[2] Imen Ben Lahmar, Djamel Belaıd, and Hamid Mukhtar. APattern-based Adaptation for Abstract Applications in Per-vasive Environments. International Journal On Advances inSoftware, 3(3&4):367 – 377, 2011.

[3] Imen Ben Lahmar, Djamel Belaıd, and Hamid Mukhtar.Middleware for task resolution and adaptation in pervasive en-vironments. Evolving Systems Journal, 3(4):221–233, 2012.

[4] Sonia Ben Mokhtar, Nikolaos Georgantas, and Valerie Issarny.COCOA: COnversation-based service COmposition in pervA-sive computing environments with QoS support. Journal ofSystems and Software, 80(12):1941–1955, 2007.

[5] Boualem Benatallah, Fabio Casati, Daniela Grigori,H. R. Motahari Nezhad, and Farouk Toumani. Developingadapters for web services integration. In Proceedings of theInternational Conference on Advanced Information SystemsEngineering, CAiSE, pages 415–429, 2005.

[6] Andrea Bracciali, Antonio Brogi, and Carlos Canal. A formalapproach to component adaptation. Journal of Systems andSoftware, 74(1):45–54, 2005.

[7] Antonio Brogi and Razvan Popescu. Automated gen-eration of bpel adapters. In Proceedings of the 4thinternational conference on Service-Oriented Computing, IC-SOC’06, pages 27–39, Berlin, Heidelberg, 2006. Springer-Verlag.

[8] Woralak Kongdenfha, Hamid Reza Motahari-Nezhad,Boualem Benatallah, Fabio Casati, and Regis Saint-Paul.Mismatch patterns and adaptation aspects: A foundationfor rapid development of web service adapters. IEEETransactions on Services Computing, 2(2):94–107, 2009.

[9] Xitong Li, Yushun Fan, Stuart Madnick, and Quan Z. Sheng.A pattern-based approach to protocol mediation for webservices composition. Information and Software Technology(IST) Journal, 52:304–323, March 2010.

[10] Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten,and Betty H.C. Cheng. Composing adaptive software. Journalof IEEE Computer, 37:56–64, 2004.

[11] Hamid Mukhtar, Djamel Belaıd, and Guy Bernard. Dynamicuser task composition based on user preferences. ACMTransactions on Autonomous and Adaptive Systems, 6(1):1–17, 2011.

[12] Romina Spalazzese and Paola Inverardi. Mediating connectorpatterns for components interoperability. In Proceedings ofthe fourth European Conference on Software Architecture,ECSA’10, pages 335–343, Copenhagen, Denmark, 2010.

[13] Mark Weiser. The computer for the twenty-first century.Scientific American, 9:94–100, 1991.

110959797