ICSE2009 SEAMS 2523 DaSilva Carlos

8/3/2019 ICSE2009 SEAMS 2523 DaSilva Carlos

1/10

Using Dynamic Workows forCoordinating Self-adaptation of Software Systems

Carlos Eduardo da SilvaUniversity of Kent

Computing LaboratoryCanterbury, Kent, CT2 7NF, UK

[email protected]

Rog erio de LemosUniversity of Coimbra

Dept. of Informatics Engineering3030-290 Coimbra, Portugal

[email protected]

Abstract

The self-adaptation of a software system is a complex process that depends on the system requirements, its oper-ational state and environment, which may change duringthe system operational lifetime. Hence, the process for co-ordinating the self-adaptation should also be adaptable tochanges that may occur during run-time. As a means for co-ordinating the self-adaptation process of software systems,the proposed approach employs workows that are dynam-ically generated for dealing with the variability associated with the self-adaptation process. In this context, our aim isto dene and develop techniques for automatically generateworkows for coordinating the self-adaptation of softwaresystems. For demonstrating the feasibility of the proposed approach, architectural reconguration of software systemsis used as an example, whereby the reconguration is man-aged by workows that are dynamically generated depend-ing on the availability of resources.

1. Introduction

It is commonly agreed that a self-adaptive software sys-tem is able to modify its own structure and/or behaviourat run-time due to changes in the system, its requirements,or the environment in which it is deployed. Comparedto traditional systems, one of the features of self-adaptivesoftware systems is that some design decisions are movedfrom development-time towards run-time. Because of this,processes usually executed in a controlled environment atdevelopment-time, need now to be executed at run-time ina dynamic and distributed environment without any humanintervention. In order to determine the actions to be taken

Carlos Eduardo da Silva is supported by the Programme Al an, theEuropean Union Programme of High Level Scholarships for Latin Amer-ica, scholarship No. E07D401107BR.

to adapt itself, a self-adaptive software system observes andanalyses itself and its environment, and if an adaptation isdeemed to be necessary, a plan is generated for altering thesystem in a controlled manner. These activities are usuallycaptured in terms of a feedback control loop containing fourkey phases, that is, monitoring, analysis, planning and exe-cution [17].

Since self-adaptation is a complex process that can im-pact multiple system components, some kind of coordina-tion is required for carrying out the adaptation in a con-certed fashion. As a means for coordinating the self-adaptation process, we employ in this paper workowmanagement technology. Typically, workow manage-ment technology coordinates and controls the ow of work

and information between participants of business processes[25]. A workow represents a business process in terms of activities (or tasks) and their relationships, rules and con-trol data in a form that can be manipulated by a WorkowManagement System (WfMS). A WfMS is a software sys-tem that provides support for the denition, managementand execution of workows. The process associated withthe self-adaptation of software depends on several factorsthat may change during the system operational lifetime,thus it is expected that the workow for coordinating theself-adaptation should also adapt depending on changes thatmay occur. In order to handle the variability associated withthe self-adaptation process, we propose the use of dynamicworkows. In this context, workow management technol-ogy can be used to coordinate the process of self-adaptationby representing the adaptation plan as a workow, and usinga WfMS for its coordination. This adaptation plan shouldbe dynamically generated to deal effectively with the vari-ability and uncertainty involved in the self-adaptation pro-cess. Otherwise, the self-adaptation process would cease tobe in synchrony with the actual system that it controls, thusrestricting what and how can be adapted. Hence the moti-vation for dening dynamic processes that would enable a


2/10

system to be more exible to what it should be able to adapt.Otherwise, the adaptation process may become brittle if theoperational prole of the system is not fully considered dur-ing development-time.

In this context, the aim of our work is to design and de-velop mechanisms for automatically generate workows forcoordinating the self-adaptation of software systems. In thispaper, we present our efforts in this direction, introducingan approach for generating workows dynamically, whichcan then be applied, as an example, to the architectural re-conguration of software systems. Based on the proposedapproach, the process for managing architectural recongu-ration is dynamically modied depending on the availabilityof resources. In order to evaluate the feasibility of the pro-posed approach, we have developed a web service applica-tion that relies on the dynamic reconguration of its archi-tecture for the provision of dependable services. Based onthe system requirements, alternative congurations, and the

attributes of the available resources, the appropriate tasksare composed in terms of workows for coordinating thearchitectural reconguration of software systems.

The rest of this paper is organised as follows. Section 2presents some background information related to workowsand dynamic workows. Our model for workow genera-tion is presented in section 3. Section 4 presents the adap-tation process applied to the architectural reconguration of fault-tolerant software systems. Section 5, for demonstrat-ing the feasibility of the proposed approach, presents a casestudy and some preliminary results. Section 6 discuss somerelated work and the conclusions of the paper are presentedin section 7.

2. Background

2.1. Workow Management Technology

Workow management technologies allow people andorganization to automate, manage, and improve businessprocesses by coordinating and controlling the ow of work and information between participants. A business processis dened as a set of one or more linked procedures or taskswhich collectively realise a business objective or policygoal, dening functional roles and relationships. The busi-ness process is dened through a workow (or process def-inition) in a form which supports automated manipulationor enactment by a Workow Management System (WfMS).A workow identies the various tasks and their relation-ships, rules and control data, and may contain referencesto sub-processes, separately dened, which make up part of the overall process denition. A WfMS is a software systemwhich provides support for the denition, management andexecution of workows through the use of software runningon one or more workow engines, which is able to inter-

pret the workow, interact with workow participants, andwhen required invoke the use of IT tools and applications[25].

Workow management technology has reached a signif-icant level of maturity by supporting heterogeneous envi-ronments and technologies, and different distributed com-puting architectures. In addition to that, workows supportthe specication of complex processes by using modellinglanguages that are able to express complicated coordinationpatterns [24]. Workow management technology has beenapplied to a variety of domains beyond traditional businessprocesses [12], and it has also been shown to be a suitabletechnology for coordinating software self-adaptation [20][22].

2.2 Dynamic Workows

Dynamic workows provide support for modifying theworkow specication during run-time in order to handlechanging requirements, availability of resources, and dif-ferent working contexts. This is achieved with the supportof the WfMS, which should be able to respond to changesthat might occur in the workow specication [13]. Theimplementation of dynamic workows varies from the dy-namic restructuring of the workow activities to the supportfor exible composition and exible deployment. Flexiblecomposition can be achieved through alternative inputs oroutputs [11], and tasks that can be dynamically instanti-ated until the denition of the workow is needed [1] [6][13]. The exible deployment may be supported through

late binding mechanisms [11], which allow the completionof activities using available resources when they are actu-ally needed [12] [13]. Our approach follows the techniquesassociated with exible composition mechanisms wheretasks are dynamically instantiated when needed. How-ever, instead of selecting the tasks from a repository of pre-specied tasks, the objective of the proposed approach is todynamically generate these tasks.

The techniques for the generation of workows can bedivided in static and dynamic [2]. Static techniques re-ceive as input an abstract model of the tasks that shouldbe carried-out. This abstract workow describes the set of tasks and the data dependency among them, and the gener-ation process consists of selecting the actual resources forexecuting the tasks specied in the abstract model, gener-ating a concrete workow which identies the actual re-sources associated with the tasks. On the other hand, dy-namic generation techniques automatically create the ab-stract process model and select the appropriate tasks thatdene the workow. The generation of abstract workowsis usually achieved based on a library of tasks with asso-ciated pre- and post-conditions, where different techniquescan be applied for nding the sequence of tasks for a par-


3/10

ticular objective [3] [16]. The mapping of an abstract work-ow to a concrete workow involves choosing the appro-priate resources for the specied tasks respecting the datadependency between them. One of the approaches for gen-erating concrete workows is to dene abstract tasks withquery clauses that will be used for identifying the actual re-source [2], or using logical information in the tasks to querysome type of registry service [6] [15].

3. Model and Infrastructure for WorkowGeneration

Workow generation is a composition process involvingtasks and the dynamic interconnection of tasks, in a way thatthe sequence of tasks achieves a particular objective. This issimilar to the process for dynamically recongure softwarearchitectures in which the interconnection between compo-nents may change on the y. Hence the similarities be-tween workows and architectural congurations in whichtasks are equivalent to components, and the connectors areequivalent to interconnections between tasks. In this view,some of the concepts and techniques applied in the contextof dynamic reconguration of software architectures can beeasily adapted for dealing with dynamic workows. Basedon this, we have adopted as a basis for generating dynamicworkows the three-layer reference model for self-managedsystems introduced by Kramer and Magee [14]. Taking asa basis the three-layer reference model, the resources to becontrolled at the component control layer are the workowtasks instead of components. At the change management

layer, the plans to be managed are workows themselves.Finally, at goals management layer, goals are objectives as-sociated with workows, from which workows are gener-ated.

Based on the three-layer reference model, the proposedapproach for generating dynamic workows can be sum-marised as follows. At the goals management layer, abstractworkows are generated according to a particular objective(or goal). These workows are used as a basis for generat-ing the concrete workows, which correspond to the plansof the change management layer. Once a concrete workowhas been selected, it is executed at the component controllayer. In case of an error during the execution of a concreteworkow, a new concrete workow is generated. If it is notpossible to generate a concrete workow based on a partic-ular abstract workow, a new abstract workow should thenbe identied.

3.1. Model for Workow Generation

Our model for workow generation is based on a widerange of concepts and techniques from other domains [9],[16] [19]. In our approach, the generation of an abstract

workow considers a library of tasks templates (with theirrespective pre- and post-conditions), the workow objec-tive, and the workow initial state. The process of gen-erating workows consists in nding a sequence of taskstemplates, starting from the workow initial state, which isable to meet the workow objective. This is achieved by us-ing a backward search from the workow objective (whichshould correspond to the post-condition of a task template)to the workow initial state (which should correspond tothe pre-condition of a task template) through a breadth-rstsearch algorithm, which returns the rst workow found(the shortest one), as long as there is one. For that, we mod-ify and combine the algorithms presented in [16] and [19]for generating abstract workows from task templates. Itis important to note that at this level, the resources associ-ated with the tasks are referred to by a logical name, whichshould be sufcient to identify the actual resources at thenext stage.

A task template captures through a sub-workow anyoperation, or sequence of operations. In our model, ev-ery task template is a sub-workow with two possible out-comes: commit or failure. A commit represents the suc-cessful execution of the associated operation meaning thatthe post-condition of the task template has been met. Whenthe operation fails, the task template nishes with a failure,which signals that the post-condition has not been met. Atask template also allows to include an exception handlingpath in sub-workow for dealing with the possible failuresin the execution of the operation. In our model, exceptionsare not propagated outside the tasks templates.

Every generated workow consists also of two possibleoutcomes: commit or failure. They are structured in such away that, whenever there is a failure in one of its tasks, theworkow stops its execution and nishes. For that, the gen-erated workows are structured in a manner similar to theapproach presented by Andrzejak et al. [3] in which a Fail-ure task represents a kind of guard task that is activatedwhen one of the tasks fails, thus cancelling the execution of all remaining tasks.

Once an abstract workow has been identied, the nextstep is to map this abstract workow into a concrete one.This mapping consists in populating the tasks in the ab-stract workow with the actual resources that will be usedfor executing the task. Since the actual resources are asso-ciated with the logical names, the process veries the stateof these resources to determine the necessity of augmentingthe workow with other tasks, or reducing it by eliminat-ing tasks for which the desired workow objective can beachieved by using a subset of the resources.

The separation between abstract and concrete workowsis similar to that of strategies and tactics [7]. This separationis interpreted as follows. Once a strategy has been selected,it can be implemented using different tactics. At the strategy


4/10

Workflow generator

Generateabstractworkflow

Generateconcreteworkflow

WfMS

Selectconfiguration

Connectconfiguration

Executeconcreteworkflow

TargetSystem

Abstractconfigurations

Registry

Requirements

Task librarySelected abstract

configuration Selected concrete configuration

Concrete workflow

Available Resources Available instances

Abstract workflow

Key: ActivityComponentExceptional flow Generation activitiesNormal flow

Figure 1. Infrastructure for workow generation.

level, we establish the composition of tasks without identi-fying the actual resources that are used by the workow.In this way, the abstract workow can be implemented us-ing different combination of resources (which is done at thetactics level). At the tactics level, resources are allocated toeach task of the abstract workow for dening the concreteworkow.

3.2. Infrastructure for Workow Genera-tion

The diagram of Figure 1 presents an overview of the in-frastructure for dynamically generating workows. The di-agram is presented in the context of architectural recong-uration, which will be detailed in section 4.1. The Tasklibrary is a repository where all task templates with its as-sociated pre- and post-conditions are stored, and the Work-ow generator is responsible for generating the abstractand concrete workows. In the present context, the genera-tion process is controlled by the WfMS , that is responsiblefor providing the Workow generator the appropriate in-formation according to the step in the generation process.

For generating an abstract workow the Workow gen-erator receives from the WfMS the workow initial stateand objective. In the context of architectural recongura-tion, the initial state would correspond to the actual archi-tectural conguration of the system (conguration A), andthe objective would correspond to the desired architecturalconguration (conguration B). One of the ways of chang-ing an architectural conguration A into an architecturalconguration B is disconnecting all involving componentsof conguration A, reaching a state of non-conguration,and then connecting all components of conguration B. The

rst step demands tasks templates related to the disconnec-tion of components, while the templates of the second stepare related to the connection of components. In this con-text, we assume that the workow generation process is ap-plied for the connection of the involved components, wherethe initial state corresponds to the non-conguration state,and the workow objective corresponds to the desired con-guration B. In this scenario, the available task templatesare related to the connection, blocking and unblocking of components, and the generated abstract workow consists

of the sequence of task templates that takes this state of non-conguration and nishes with the desired conguration B.This abstract workow is then sent to the next activity in thegeneration process (generate concrete workow) and to theWfMS , which will look for the appropriate resources to beused for generating the concrete workow.

There are two cases that must be considered when gener-ating a concrete workow in the context of architectural re-conguration. The rst case concerns the disconnection of an existing conguration, where all the involved resourcesare known, and cannot be changed, while the second case,which is the case being focused, concerns the connection

of an architectural conguration, where the components in-volved can be changed for different reasons. When gener-ating a concrete workow for connecting an architecturalconguration, the WfMS is responsible for dealing with thesituations where the involved components may change, pro-viding the workow generator the actual resources that willbe used for mapping an abstract workow into a concreteworkow.

The concrete workow is then executed by the WfMS,effectively altering the system architecture. In case of a


5/10

Connect configuration

TargetSystem

Monitoringresources


Registry

AvailableResources

Requirements

Selectedconcreteconfiguration

ReconfigurationCommands

Selectedabstractconfiguration

Identifyconcrete

configurations

Selectconcrete

configuration

Connectconcrete

configuration

Select configuration

Identifyabstract

configurations

Selectabstract

configuration

WfMS

Component Activity Tactic activities


Availableinstances

Concreteconfigurations

Key: Strategy activitiesExceptional flowNormal flow

Figure 2. Overview of the process for controlling architectural reconguration.

failure during the execution of the concrete workow, afeedback is provided to the workow generator through theWfMS for generating a new concrete workow, and if it isnot possible to nd a concrete workow based on an ab-stract workow, a feedback is provided through the WfMSfor generating a new abstract workow.

4. Architectural Reconguration Based on Dy-namic Workows

In the following, the dynamic generation of workowsis applied to the architectural reconguration of a softwaresystem. For that, we have dened a reconguration processbased on a feedback control loop, and used dynamic work-ows to control and coordinate this process. The workowscoordinating the reconguration process are generated ac-cording to the resources available. In other words, the sys-tem resources not only constraint its architecture, but alsoaffect the workows that manage the architectural recong-uration.

In the following, we present dynamic workows appliedto architectural reconguration process, and provide detailson how workows are generated for coordinating architec-tural reconguration.

4.1. The Reconguration Process

Taking as basis the three-layer reference model intro-duced by Kramer and Magee [14], in this paper we arespecically concerned with the workows that dene theplans of the change management layer, even though work-

ows can be generated for managing the activities associ-ated with each of the three layers.

Figure 2 presents an overview of the reconguration pro-cess. This process considers the connection of architec-tural congurations. We assume that if there is an exis-tent conguration, this conguration is fully disconnectedbefore the reconguration process starts, thus assuming anon-conguration state as initial state for the recongura-tion process. In order to control the architectural recong-

uration of the Target System , the WfMS requires as in-put the system requirements, architectural congurations,and the resources available. The Requirements enumer-ate the properties that specify the quality of services (QoS)expected from the system. The Abstract congurationsis a repository that contains a set of abstract architecturalcongurations. An abstract conguration is an architec-tural conguration that identies the structure of the sys-tem and the functional and non-functional requirements of the involved components, independently of the actual com-ponents instances. A concrete conguration, on the otherhand, is an architectural conguration where all compo-nents instances and their respective attributes are identied.The Registry is where all available resources and their re-spective attributes are stored. In this approach, we assumethat the Registry is responsible for monitoring the avail-able resources of the system, and for providing an accurateview of the system to the WfMS . If there are changes in theresource availability during the reconguration process, forexample, a failure of a component, the process will querythe Registry again for obtaining an updated view of theavailable resources.

The dened reconguration process is also divided in


6/10

two different levels of concerns: strategies and tactics, cor-responding to the partition that is key to Cheng et al ap-proach [7]. At the strategy level, associated with the Se-lect conguration activity, an abstract conguration is se-lected based on the system requirements and the availableresources, while at the tactics level, associated with theConnect conguration activity, a concrete conguration isdened based on the selected abstract conguration and inthe available instances. In this way, an abstract architecturalconguration can be instantiated using different concretecongurations containing different combinations of compo-nents. At the strategy level, the Identify abstract cong-urations activity takes into account the requirements andavailable resources for identifying the set of abstract con-gurations that can be instantiated, and the Select abstractconguration activity is responsible for selecting one con-guration from this identied set. The selected abstractconguration is used as input for the tactics level. At the

tactics level, the Identify concrete congurations activitybuilds all the possible concrete congurations involving theavailable instances, while the Select concrete congura-tion is responsible for selecting one concrete congurationconsidering the available alternatives. The Connect con-crete conguration activity is responsible for connectingthe components instances according to the concrete cong-uration, effectively, altering the system. If there is a failureduring the connection of resources, new instances need tobe selected, and if there are no available instances that meetthe specications of the selected conguration, an alterna-tive conguration needs to be selected.

Since faults can occur during architectural recongura-tion, it is fundamental for the process controlling the recon-guration to be fault-tolerant, so the integrity of the systemcan be maintained. This is achieved by structuring the re-conguration process according to strategies dened in [8]in which the activities are structured using atomic actions,thus allowing the handling of failures during the recongu-ration.

4.2. Workows

In our approach, the two processes for controlling work-ow generation and architectural reconguration are inter-connected in a way that the workows used for control-ling architectural reconguration also control the processfor generating workows. The reconguration process isresponsible for providing the necessary information to theworkow generator depending on the stage of the genera-tion process. This corresponds providing an abstract cong-uration for generating an abstract workow, and a concreteconguration for generating a concrete workow. Whenthere is the need to generate a new workow, the workowthat coordinates the selection of a conguration noties the

workow generator. In this way, whenever there is, for ex-ample, a failure during the execution of the generated work-ow, a new concrete workow is generated using updatedinformation from the reconguration process, and if thereis not enough resources for generating a concrete workow(i.e., it is not possible to identify a concrete conguration),a new abstract workow is generated after the selection of anew abstract conguration. In the following, we present theworkows dened for controlling these two processes.

The workows in our approach are modelled using theYAWL workow modeling language [23]. Y AWL is basedon Petri nets, extended with additional features for model-ing complex workows. A workow in Y AWL is a set of nets that form a hierarchy in a tree-like structure. Each nethas got tasks, and one input condition and one output con-dition. This notation can represent different coordinationpatterns, and supports atomic tasks or composite tasks. Asa reference for the workows to be presented in this paper,

Figure 3 presents a sub-set of the symbols of the Y AWL lan-guage.

Figure 3. Sub-set of the symbols used in theYAWL language.

In this work, we are focused on generating the work-ow associated with the Connect concrete congurationactivity, which is associated with the tactics level of thereconguration process, shown in Figure 2. We proceednow to present the different workows associated with thislevel. Figure 4 depicts the workow associated with theConnect conguration activity . It receives as input theselected abstract conguration and the abstract workow,both dened at the strategy level. After that, the set of avail-able instances is obtained ( Obtain available instances ),and used for identify all the possible concrete congura-tions ( Identify concrete congurations ). In the sequence,a concrete conguration is selected ( Select concrete con-guration ), and then used for generating the concrete work-ow ( Generate concrete workow ) that will be executedin the Connect concrete conguration task. If this task nishes with a failure, the workow is restarted, consid-ering the abstract conguration and the abstract workowreceived. Once a new concrete conguration has been se-lected, a new concrete workow is generated and executed.If it is not possible to nd a concrete conguration for the


7/10

selected feasible conguration with the available instances,this workow nishes with a failure, returning the processto the strategy level, where a new abstract conguration willbe selected, and a new abstract workow will be generated.If the conguration is established, this workow commits.

Figure 4. Tactics level workow.

Figure 5 presents the workow associated with the Con-nect Concrete Conguration task. This workow con-trols the execution of the generated concrete workow. Thegenerated concrete workow is used as sub-workow forthe Connect instances tasks, where the system congu-ration is effectively altered. For now, all components in-volved in a concrete architectural conguration are discon-nected, and the blocking of the involved components is partof the Connect Concrete Conguration workow and notthe generated concrete workow. If there is a failure whileconnecting the components, all active connections are dis-connected and the components unblocked, before workownishes with a failure. Otherwise the workow commits.

Figure 5. Workow associated with the Con-nect Concrete Conguration task.

For now, the workow associated with the disconnectionof the active connections is not generated using the denedmodel. This is done by using a simple undo scheme, inwhich the log of the workow execution is used to identifythe executed tasks, and the information about the tasks thatundo the ones executed is part of the task library.

4.3. Workow Generation for ArchitecturalReconguration

In our approach, we are restricting architectural recon-guration to the connection/disconnection of componentsand connectors, not considering the change of componentparameters as part of the reconguration process. Thus

the tasks templates available are related to operations nec-essary for changing a conguration according to the un-derlying component model used (i.e. connect/disconnect,block/unblock, start/stop operations). To deal with compo-nents failures, the dened task templates are also structuredaccording to the strategies based on atomic action identiedin [8].

Figure 6 presents the sub-workow dened as a task tem-plate for the connection of two components. This is an ex-ample of a task template with an exception handling pathin it. After the verication of the pre-condition, the com-ponents can be connected. The connection is dependent onthe communication technology used. If there is a failureduring the connection of the components, the connection isaborted and this workow nishes with a failure. In casethere is a failure in the post-condition associated with thisworkow, the components are disconnected, and it nisheswith a failure. The workow commits when the componentsare successfully connected and the post-condition met.

Figure 6. Task template for connecting twocomponents.

The workow initial state and objective are representedusing, respectively, pre- and post-conditions. They are ex-pressed in terms of the elements of an abstract architecturalconguration, where the involved components are identiedusing logical names. These logical names are also used in

pre- and post-conditions associated with the tasks templatesof the generated abstract workow. In this context, the pre-condition states that all components are disconnected, andthe post-condition states that all components are connected.

The mapping of an abstract workow into a concrete oneuses the logical names to identify the component instancesin the concrete conguration. At this point, the componentsinstances are known, and their state are queried in order toidentify the necessity of any additional tasks in the concreteworkow.


8/10

5. Case Study Application

For demonstrating the feasibility of using dynamic work-ows for coordinating software adaptation, we have devel-oped a web service application that relies on the dynamic

reconguration of its architecture for the provision of de-pendable services. This application addresses the problemof obtaining stock quotes from the Web. The stock quotesare collected from different sources, and different fault tol-erance strategies are applied in order to obtain correct stock quotes. These different strategies are captured by alterna-tive architectural congurations. The coordination of thearchitectural reconguration is obtained through the usageof workows that are dynamically modied during run-timedepending on the availability of resources.

The software architecture of this case study consists of aFrontEnd component, two different components that repre-sent the different fault-tolerance strategies ( Voter and Com-parator ), and different sources of stock quotes (for exam-ple, BridgeYahoo and BridgeGoogle - a bridge handles ar-chitectural mismatches between the online sources and oursystem, and provides a well dened interface for accessingdifferent online sources of stock quotes). The Voter com-ponent requires three different sources of stock quotes, andperforms majority voting on the values received, while theComparator component applies comparison between twosources of stock quotes for detecting inconsistencies.

For implementing this application, we have used the in-frastructure presented in Figure 1. All architectural ele-ments are implemented using Java language, and the com-

munication among them uses web services technology. Forour approach, we have developed an extension of xADL 2.0that allows the architectural elements and the workow en-gine to communicate through web services. Our extensionto xADL 2.0 adds some tags to represent the informationused by the WfMS, such as, the WSDL address, and theattributes of the resources. Our extension of xADL allowsalso to represent architectural congurations, resources, andsystem requirements. For now the requirements are ex-pressed in terms of the attributes and the respective valuesthat must be met by the system.

For evaluating the current approach, we have conductedsome experiments using the Workow generator for build-ing the workow during run-time according to the selectedarchitectural conguration. In these experiments, faultswere injected in the system for crashing different compo-nents at different stages of the reconguration process in or-der to investigate its robustness in the presence of failures.The architectural conguration was successfully modiedduring run-time based on the system requirements, the al-ternative conguration, and the attributes of the availableresources. Based on the selected conguration, the work-ows are successfully generated for changing the system.

Figure 7 presents an example of an abstract and con-crete architectural congurations. The abstract congura-tion identies the functional and non-functional require-ments associated with each component using its logicalname. For example, C1:FrontEnd indicates that the com-ponent with logical name C1 has got functional require-ments associated with components of type FrontEnd .

C2:Comparator

C3:Bridge

C4:Bridge

NFR

NFR

NFR

C1:FrontEnd

NFR

C2:Comparator

:Cmp02

C3:Bridge

:BridgeYahoo

C4:Bridge

:BridgeGoogle

C1:FrontEnd

:Gui

Attributes

Attributes

AttributesAttributes

Abstract architectural configuration

Concrete architectural configuration

Figure 7. Example of abstract and concretearchitectural congurations.

In the concrete conguration we have the instances asso-ciated with each component identied, and their respectiveattributes. C1:FrontEnd:Gui indicates that the componentwith logical name C1 of type FrontEnd has got the compo-nent instance identied by Gui associated with it.

Figure 8 presents an abstract workow generated basedon the abstract conguration of Figure 7. This workow

identies the tasks templates to be used, and uses the logicalnames of the components to populate the templates.

Figure 8. Example of a generated abstractworkow.

A concrete workow that connects the instances is dy-namically dened by populating the abstract workow withthe components instances that are part of the concrete con-guration. Figure 9 presents an example of a concrete work-ow for the presented conguration.

In this case study, faults were injected during the pro-cess for evaluating the fault-tolerance of the proposed ap-proach. Although the workows are successfully generatedduring run-time based on the available resources, and thesystem is successfully congured when there are enoughresources, experiments in more complex scenarios must be


9/10

Figure 9. Example of a generated concreteworkow.

realised for a better evaluation of the presented approach.These experiments may include a different number of task templates and different components states, recongurationof systems where the selected components are already con-nected, or the replacement of one component in a existentconguration. Moreover, this example has also shown howthe proposed approach support the handling of faults duringthe reconguration.

6. Related Work

Existent approaches for self-adaptation [7] [10] have fo-cused on the selection of an adaptation plan using rule-based mechanisms, where each available plan is dened atdesign-time for each condition that triggers an adaptation.In a such approach all possible actions and associated ac-tivation rules are kept in a repository. Sykes et al. [21]present an approach for the generation of reactive plans of autonomous systems from high level goals. A reactive planis a set of condition-action rules that specify the behaviour

of the system, where actions are mapped into componentinterfaces that dene the functional requirements of the sys-tem. Different from these approaches, our approach aims tobuild automatically an adaptation plan during run-time, thusproviding the means for dealing with uncertainty associatedwith the self-adaptation process.

Our approach is not the rst to employ workows man-agement technology for coordinating software (self-) adap-tation [20] [22]. However, these approaches either restrictthe support to software adaptation [20], or deal with the co-ordination of mobile agents responsible for executing theadaptation [22]. Moreover, both approaches suffer from thesame limitations of having to dene adaptation plans dur-ing design-time. In our approach, we focus on building andmodifying workows during run-time, providing the meansfor handling failures during the execution of an adaptationplan, and do not restrict adaptation since workows are dy-namically dened according to the available resources.

Autili et al. [5] present an approach for context-awareself-adaptation. In their approach, applications are adaptedat deployment time for the target environment. Their focusis on the selection of the best adaptation alternative basedon the current environment state and the required resources

of the application. In our approach, we focus on the dy-namic modication of the adaptation process, assuming theexistence of mechanisms responsible for selecting an archi-tectural conguration for the system.

Concerning workow generation, Shankar and Campbell[19] present a policy-based approach using event-condition-action (ECA) rules, where a workow is built based on pre-and post-condition of different rules actions that are trig-gered by a single event. This approach requires the deni-tion of rules in a manner that the right actions will be acti-vated by a single event. Moreover, this approach does notdeal with issues like the variability in the resources avail-ability. Another approach for automatic workow genera-tion is presented by Lu et al [16]. They have developed aformal model in which workows are assumed to be con-structed from a library of parametrised tasks with pre- andpost-conditions, and algorithms that synthesise a workowbased on the pre- and post-conditions of workows. Their

approach considers workow generation as search prob-lem in a search space graph, and assumes a particular task model, where tasks can have alternative outputs with differ-ent post-conditions. Our approach uses ideas from [19] and[16], and is very similar to the ideas presented by Lee et al.[15], in which an abstract workow is mapped into a con-crete one and then executed in a computing grid. However,in their approach they are focused on optimising the map-ping between the abstract and the concrete workows. Inour approach, we are not restricted to a pre-dened abstractworkow, as the abstract workow can also change.

Several approaches apply AI planning techniques forgenerating workows in different domains, such as, gridcomputing [9], web service composition [2], and perva-sive computing [18]. Arshad et al [4] have used planningtechnology for reconguration planing. However, their ap-proach can only deal with a xed initial set of components,and the generated plan is not executed, as the generation in-frastructure is isolated, with the execution of the generatedplan indicated as future work. In our approach, we are notrestricted to a xed set of resources for generating adapta-tion plans, and we are able to modify the adaptation plan todeal with failures during its execution.

7. Conclusions

This paper has proposed an approach that employs dy-namic workows for controlling and coordinating the self-adaptation of software systems. The main focus of this ap-proach is towards mechanisms for automatic generation of workows. These generated workows have been appliedin the context of architectural reconguration of softwaresystems, and in order to handle faults during the adapta-tion, atomic actions were used as a means for structuringthe workows.


10/10

The feasibility of the proposed approach was demon-strated in the context of a web service application for ob-taining dependable stock quotes. In this application, theworkows for coordinating the reconguration of the sys-tem changed depending on the availability of resources. Forevaluating the fault-tolerance of the approach, faults wereinjected in the system components at different stages of thereconguration process, and the system has been success-fully congured when there are enough resources for estab-lishing a conguration. Although the preliminary results areencouraging, more detailed studies, involving more com-plex scenarios and other kinds of applications, have to beperformed for a better evaluation of the proposed approach.

Currently, we are investigating existing techniques forworkow generation in order to optimise the generationprocess, and for that we intend to make better use of tech-niques based on workow meta-models. Our long term planis the application of the mechanisms for workow genera-

tion in the context of other processes of software engineer-ing, such as component-based integration testing.

References

[1] M. Adams, A. H. M. ter Hofstede, D. Edmond, and W. M. P.van der Aalst. Worklets: A service-oriented implementationof dynamic exibility in workows. In Proc. of the OTM CoopIS06 , volume 4275 of LNCS , pages 291308, Berlin,2006. Springer-Verlag.

[2] A. Alamri, M. Eid, and A. E. Saddik. Classication of the state-of-the-art dynamic web services composition tech-niques. Int. J. Web Grid Serv. , 2(2):148166, 2006.

[3] A. Andrzejak, U. Hermann, and A. Sahai. Feedbackow-an adaptive workow generator for systems management.In Proc. of the ICAC05 , pages 335336. IEEE ComputerSociety, 2005.

[4] N. Arshad, D. Heimbigner, and A. L. Wolf. Deploymentand dynamic reconguration planning for distributed soft-ware systems. Software Quality Journal , 15(3):265281,2007.

[5] M. Autili, P. D. Benedetto, P. Inverardi, and D. A. Tamburri.Towards self-evolving context-aware services. In Proc. of the DisCoTec CAMPUS08 , 2008.

[6] F. Casati, S. Ilnicki, L. jie Jin, V. Krishnamoorthy, and M.-C.Shan. Adaptive and dynamic service composition in eow.In Proc. of the CAISE00 , volume 1789 of LNCS , pages 1331. Springer-Verlag, 2000.

[7] S.-W. Cheng, D. Garlan, and B. Schmerl. Architecture-based self-adaptation in the presence of multiple objectives.In Proc. of the ICSE SEAMS06 , pages 28, New York, NY,USA, 2006. ACM Press.

[8] R. de Lemos. Architectural reconguration using coordi-nated atomic actions. In Proc. of the ICSE SEAMS 06 , pages4450, New York, NY, USA, 2006. ACM.

[9] E. Deelman, J. Blythe, Y. Gil, C. Kesselman, G. Mehta,K. Vahi, K. Blackburn, A. Lazzarini, A. Arbree, R. Ca-vanaugh, and S. Koranda. Mapping abstract complex work-

ows onto grid environments. J. of Grid Computing ,1(1):2539, 2003.

[10] J. C. Georgas and R. N. Taylor. Towards a knowledge-basedapproach to architectural adaptation management. In Proc.of the WOSS04 , pages 5963. ACM, 2004.

[11] J. J. Halliday, S. K. Shrivastava, and S. M. Wheater. Flexible

workow management in the openow system. In Proc. of the EDOC01 , pages 8292. IEEE Computer Society, 2001.[12] T. Heinis, C. Pautasso, and G. Alonso. Design and eval-

uation of an autonomic workow engine. In Proc. of the ICAC05 , pages 2738. IEEE Computer Society, 2005.

[13] P. J. Kammer, G. A. Bolcer, R. N. Taylor, A. S. Hitomi,and M. Bergman. Techniques for supporting dynamic andadaptive workow. Computer Supported Cooperative Work ,9(3/4):269292, 2000.

[14] J. Kramer and J. Magee. Self-managed systems: an archi-tectural challenge. In Proc. of the FOSE07 , pages 259268,Washington, DC, USA, 2007. IEEE Computer Society.

[15] K. Lee, N. W. Paton, R. Sakellariou, E. Deelman, A. A. A.Fernandes, and G. Mehta. Adaptive workow process-

ing and execution in pegasus. In Proc. of the GPC-WORKSHOPS08 , pages 99106, Washington, DC, USA,2008. IEEE Computer Society.

[16] S. Lu, A. Bernstein, and P. Lewis. Automatic workow ver-ication and generation. Theor. Comput. Sci. , 353(1):7192,2006.

[17] H. M uller, M. Pezz e, and M. Shaw. Visibility of control inadaptive systems. In Proc. of the ULSSIS 08 , pages 2326.ACM, 2008.

[18] A. Ranganathan and R. H. Campbell. Autonomic perva-sive computing based on planning. In Proc. of the ICAC04 ,pages 8087, 2004.

[19] C. Shankar and R. Campbell. Ordering management actionsin pervasive systems using specication-enhanced policies.In Proc. of the PERCOM06 , pages 234238. IEEE Com-puter Society, 2006.

[20] S. K. Shrivastava, L. Bellissard, D. F eliot, M. Herrmann,N. de Palma, and S. M. Wheater. A workow and agentbased platform for service provisioning. In Proc. of the EDOC00 , pages 3847, Washington, DC, USA, September2000. IEEE Computer Society.

[21] D. Sykes, W. Heaven, J. Magee, and J. Kramer. From goalsto components: a combined approach to self-management.In Proc. of the ICSE SEAMS08 , pages 18, 2008.

[22] G. Valetto and G. Kaiser. Using process technology tocontrol and coordinate software adaptation. In Proc. of the ICSE03 , pages 262272, Washington, DC, USA, 2003.IEEE Computer Society.

[23] W. M. P. van der Aalst and A. H. M. ter Hofstede. Yawl: Yetanother workow language. Inf. Syst. , 30(4):245275, 2005.

[24] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kie-puszewski, and A. P. Barros. Workow patterns. Distrib.Parallel Databases , 14(1):551, 2003.

[25] WfMC. Terminology and glossary, 3rd edition. TechnicalReport WfMC-TC-1011, Workow Management Coalition,1999.

Documents

ICSE2009 SEAMS 2523 DaSilva Carlos