1

Adaptive SOA Solution StackKrzysztof Zielinski, Tomasz Szydło, Robert Szymacha, Jacek Kosinski, Joanna Kosinska, Marcin Jarzab

{kz,tszydlo,szymacha,jgk,kosinska,mj}@agh.edu.plDepartment of Computer Science

AGH University of Science and TechnologyAl. Mickiewicza 30, 30-059 Krakow, Poland

Abstract—Keywords: Services Architectures, ServicesManagement, Operational Model, Quality of Services

The paper presents the concept of an Adaptive SOA SolutionStack (AS3). It is an extension of the S3 model, implemented viauniform application of the AS3 element pattern across differentlayers of the model. The pattern consists of componentsconstituting an adaptation loop. The functionality of eachcomponent is specified in a generic way. Aspects of thesepatterns are analyzed in relation to individual S3 layers. Theability to achieve multilayer adaptation, provided by severalcooperating AS3 elements is also discussed. Practical usageof the proposed concepts for Adaptive Operational Systems,Integration and Service Component layers are presented in theform of three case studies. Each study describes the architectureof the proposed system extensions, selected software technologies,implementation details and sample applications. Related workis discussed in order to provide a background for the reportedresearch. The paper ends with conclusions and an outline offuture work.

I. INTRODUCTION

Over the last several years adaptive systems have attractedsignificant attention. Development of these systems are drivenby the emergence of new software technologies enablingdynamic and reconfigurable software development, such asDynamic AOP [1], OSGi [2] and virtualization technologies,e.g. Xen [3], VMware [4] and Solaris Containers [5], offeringruntime control of computer resources.

Adaptive systems focus on the development of systems thatmodify their structure and behavior in response to changes inthe execution environment [6]. These systems monitor state,correlate information and perform actions according to user-defined policies. They are considered a simpler form of Au-tonomic Computing [7][8][9] systems, capable of performingself-management on their own, based on knowledge collectedduring operation.

Adaptive systems ameliorate the complexity of computingsystems, expressed not only by the number of connectedhardware and software components but also by the growingspace of configuration parameters and management strategiesoffered through middleware and virtualized computationalplatforms. Better utilization of modern IT infrastructures isa prerequisite for achieving the required QoS (Quality of Ser-vice) and end-user satisfaction, characterized by QoE (Qualityof Experience).

All these aspects can be considered in the context of SOA(Service Oriented Architecture) [10][11] – the most popular

paradigm for implementing enterprise software systems. SOAenables the development of applications by combining loosely-coupled and interoperable services. The complexity of thisprocess and the need to guarantee QoE and QoS make adaptivesystems especially suitable for SOA deployment.

A. Adaptive SOA Research Issue

SOA application development, deployment and executionrequirements may be analyzed in the context of the SOASolution Stack (S3) [11] proposed by IBM. It is a highlygeneric model, taking into account all presented aspects,with particular attention to SOA policy-driven governance.This justifies its selection as a starting point for research onintegrated SOA adaptive systems.

Research addressing adaptive SOA applications[12][13][14] concentrates mainly on the application level.Adaptability aspects cover SOA application deployment [15],dynamic selection of services [13] and dynamic servicecomposition [16][14]. The key observation is that S3 layersare not independent of one another and decisions made ona given layer may influence the behavior of other layers.Any parameter set by lower layers can be considered asa constraint for the adaptability strategies implemented onhigher layers. This is a well-known problem in hierarchicalsystem optimization. Its practical solution in the context ofSOA systems requires not only adaptation strategies capableof being applied across several layers of the system, but alsoa uniform approach to extending each layer with adaptabilitymechanisms. This distinguishes the proposed approach fromother studies focusing on selected layers, such as adaptiveESB [17] or Middleware [18].

In the context of existing work on adaptive SOA, there arestill some critical issues that have not been well explored:• Construction of a uniform adaptive system model which

could be applied to any layer of SOA-based computingsystems including virtualized computational resources.Such a model should include basic components with well-defined interfaces, suitable for constructing an adaptationloop.

• Selection of a software implementation technology thatcan be applied across S3 layers, providing interoperabilityof adaptability extensions. The same category of adapt-ability components from different layers should be easyto integrate and use in adaptation loops spanning morethan one layer.

2

• The adaptation strategy must process large amounts ofdata collected during SOA application runtime. Thus,efficiency and scalability issues require particular at-tention. This calls for research on selective and dy-namic instrumentation of the system to add monitoringand management functionality. The collected information(facts) should be processed efficiently by decision enginesimplementing the adaptability strategy.

• SOA systems are characterized by high levels of elasticityand dynamicity as runtime composition is one of themost important features of these systems. The sameaspect refers to adaptability extensions which may bereconfigured on demand, without restarting or suspendingthe system. This requires further research on dynamic andreconfigurable software development.

• The proposed framework is characterized by agnosticadaptation strategy selection. In spite of this, adoptionof probability and statistical theories for predicting theQoS of computing resources and services could playan important practical role. Recently, runtime utilizationmodels [15] for SOA systems have emerged as a focusof intensive research.

B. Main Contribution

The main research contribution of this study is an integratedapproach to adaptive SOA system development. The integratedapproach means that adaptability aspects are introduced in auniform way to each layer of the S3 model. This leads to amultilayer adaptive system which offers full control over QoSand QoE parameters, taking advantage of modern softwareand hardware technologies. The proposed approach has thefollowing specific features:

• A pattern-based approach to adaptive extensions. Theextension of each S3 layer follows the same proposedpattern consisting of typical components which, together,create an adaptation loop. This pattern focuses on policy-driven management systems and is similar to the Auto-nomic Computing model [19].

• A flexible approach to adaptation loop component selec-tion. Components can be implemented using existing soft-ware packages such as Event Processors or Rule Engines,wrapped with suitable interfaces ensuring interoperability.The OSGi [2] technology is used for this purpose –therefore components can be deployed as bundles.

• A practical presentation of the proposed concepts, appliedto several layers of the S3 model. It provides guidancefor system developers on how to construct adaptive loopsfor different layers. The key point is that the same patternis used in a uniform way for various layers, such asvirtualized computer resource management and adaptiveESB deployment.

• Assessments and evaluation of the proposed solutions.The presented concept is verified by implementation ofthe Adaptive Operational System layer, Adaptive Integra-tion layer and Adaptive Service Components layer of theS3 model.

The paper is organized as follows: Section II introducesthe work by presenting and analyzing the S3 model andstating the requirements of adaptive extensions for each layer.Section III presents the concept of Adaptive S3 (AS3) elements– a compound pattern for adaptive loop construction. InSection IV the Adaptive S3 model is described. Section Vpresents the Adaptive Operational Systems layer built withXen Virtual Machines and Solaris Containers as an initial casestudy of the proposed model. Adaptive ESB and Adaptive SCAare presented in Sections VI and VII respectively. Section VIIIprovides an overview of related work. Finally, Section IXconcludes the paper and outlines future work.

II. MOTIVATION

SOA application development and deployment should beconsidered in the context of the SOA Solution Stack (S3)proposed by IBM [11], which provides a detailed architecturaldefinition of SOA split into nine layers. This model is depictedin Fig. 1. Each layer has a logical and physical aspect. Thelogical aspect includes all the architectural building blocks,design decisions, options, key performance indicators, and soon. The physical aspect covers the applicability of each logicalaspect in reference to specific technologies and products andis out of scope of our analysis. The S3 model is based on twogeneral assumptions:

1) The existence of a set of service requirements that areboth functional and nonfunctional and collectively estab-lish the SOA objective. Nonfunctional service aspectsinclude security, availability, reliability, manageability,scalability, latency, and the like.

2) A single layer or some combination of layers can fulfillspecific service requirements and, for each layer, servicerequirements are satisfied by a specific mechanism.

Figure 1. SOA Solution Stack (S3) model

Adaptability can be described as an activity whose goal isto guarantee the required level of nonfunctional parametersspecified by QoE or QoS for each layer.

The nine layers of the S3 stack are as follows: OperationalSystems, Service Components, Services, Business Process,Consumer, Integration, QoS, Information Architecture, andGovernance and Policy. A brief description of each layer ispresented below as a background for further discussions inthis section. Only the Consumer layer is not described, as itconstitutes a topmost, nontechnical layer wherein the global

3

effects of system activity are observed and evaluated by endusers.

Operational Systems – This layer includes all applicationand hardware assets running in an IT operating environmentthat supports business activities (whether custom, semicustomor off-the-shelf). As this layer consists of existing applicationsoftware systems, SOA solutions may leverage existing ITassets. Currently, this layer typically includes a virtualized ITinfrastructure that results in improved resource manageabilityand utilization. This property could be effectively exploitedin the development of an adaptive virtualized infrastructure,guaranteeing the required level of computational or commu-nication resources accessibility.

Service Components – This layer contains software compo-nents, each of which is an incarnation of a service or serviceoperation. Service components reflect both the functionalityand QoS for each service they represent. Each service com-ponent:

• Provides an enforcement point for ensuring QoS andservice-level agreements,

• Flexibly supports the composition and layering of ITservices,

• Conceals low-level implementation details from con-sumers.

In effect, the service component layer ensures proper align-ment of IT implementations with service descriptions. ServiceQoS depends on the efficiency of internal components used forservice provisioning. It opens a space for adaptability withinthe Service Component layer. The observed service QoS isnot only the result of Service Component activity but alsodepends on computational resources used in execution. Thisbehavior illustrates the role of the Operational Systems layerand facilitates multilayer adaptability.

Services – This layer consists of all services defined withinSOA. In the broadest sense, services are what providersoffer and what consumers or service requesters use. In S3,however, a service is defined as an abstract specification ofone or more business-aligned IT functions. This specificationprovides consumers with sufficient information to be able toinvoke the business functions exposed by a service provider.It is necessary to point out that services are implemented byassembling components exposed by the Service Componentlayer and that this assembly process might be performeddynamically with the support of adaptability mechanisms.

Business Process – In this layer, the organization assemblesthe services exposed in the Services layer into composite ser-vices that are analogous to key business processes. In the non-SOA world, business processes exist as custom applications.In contrast, SOA supports application construction by intro-ducing a composite service which orchestrates informationflow among a set of services and human actors. Again, thesecomposite services can be constructed dynamically, accordingto a specific adaptation policy.

Integration – This layer integrates layers 2 through 4. Itsintegration capabilities, supported by ESB, enable mediation,routing and transporting service requests from the client to thecorrect service provider. This layer is particularly well suited

for adaptability mechanisms, which is further illustrated by thediscussion of Adaptive ESB.

Quality of Service – Certain characteristics of SOA mayexacerbate well-known IT QoS concerns: increased virtualiza-tion, loose coupling, composition of federated services, hetero-geneous computing infrastructures, decentralized service-levelagreements, the need to aggregate IT QoS metrics to producebusiness metrics and so on. As a result, SOA clearly requiressuitable QoS governance mechanisms.

Information Architecture – This layer covers key dataand information-related issues involved in developing businessintelligence with the use of data marts and warehouses. Itincludes stored metadata, required for correct interpretationof actual business information.

Governance and Policy – This layer covers all aspectsof managing the business operations’ lifecycle. This layerincludes all policies, from manual governance to autonomouspolicy enforcement. It provides guidance and policies formanaging service-level agreements, including capacity, per-formance, security, and monitoring. As such, the Governanceand Policy layer can be superimposed onto all other S3layers. From a QoS and performance standpoint it is tightlyconnected to the QoS layer. The layer’s governance frameworkincludes service-level agreements based on QoS and keyprocess indicators, a set of capacity planning and performancemanagement policies to design and fine-tune SOA solutionsas well as specific security-enabling guidelines for compositeapplications.

It is evident that the final three layers are directly relatedto adaptability. They provide key mechanisms required by theadaptation loop, thereby affecting the first five layers listedabove.

This observation constitutes our motivation for the presentedwork on Adaptive S3.

III. CONCEPT OF ADAPTIVE S3 ELEMENT

The concept of the proposed Adaptive S3 (AS3) element ispresented in Fig. 2 and refers to a single S3 layer. S3 layer isdefined as a set of components, such as architectural buildingblocks, architectural decisions and interactions among compo-nents and layers. This definition emphasizes the existence ofmany options that can be subjected to architectural decisionstaken during the SOA application design phase or postponeduntil runtime. The structure of the AS3 element follows thetypical control loop construction patterns and consists of thecomponents listed below.

The Managed Resource is instrumented with sensors andeffectors. The term Resource is used here in an abstract way,meaning anything (e.g. virtual machine, application server orESB) that can be monitored and managed. The instrumentationprocess equips the Resource with the ability to expose its stateand data required to characterize its activity. The same processalso installs mechanisms for changing Resource parameters orconfiguration, according to decisions imposed by the controlloop. The key point is that instrumentation should be non-intrusive, selective and dynamic (performed during runtime).

Data communicated by sensors is collected by the Monitor-ing Component. This component is responsible for calculating

4

Resource

...

Adaptive

Manager

Exposition

Monitoring Management

Instrumentation

Monitored

dataFacts out

To other

AMDecisions Actions

Figure 2. AS3 element model

selected metrics and processing events. Simple events maybe assembled into complex ones, important for the adaptationstrategy. Complex Event Processors such as Esper [20], orDrools [21] can be used to perform this activity in a scalableand efficient way.

The aggregated data – the output of the Monitoring Com-ponent – is forwarded to the Exposition Component. Theexposition process is related to the Adaptive Manager used forselection of control actions. It transforms monitored data intoa format used by given manager representations. Therefore,the Exposition Component plays the role of a harmonizationlayer.

To enact the adaptation strategy, an Adaptive Man-ager (AM) is used. It may be based on the standard theory ofregulation, fuzzy logic or neural networks. In the proposedstudy, policy-based management has been chosen. Such asolution is suitable when a decision has to be based on manydifferent parameters and a precise mathematical model of themanaged system is not available. The adaptation actions areselected by the Policy Engine (PE). Rule Engines such as Jess[22] or Drools [21] can be used in scalable implementations.

The action selected by the Adaptive Manager is convertedby the Exposition Component to a format acceptable by theManagement Component. This component enforces manage-ment actions using effectors which instrument the ManagedResource.

Adaptive Service layer of composite services can be con-structed dynamically, akin to adaptive services, which are builtfrom components in the adaptive Service Components layer.The same applies to the adaptive Business Process layer whereprocesses are constructed from services. These three layers areconceptually very similar. The abstraction level (granularity)is, however, significantly greater in the Service and BusinessProcess layer, as explained by ongoing studies [13][14][16].Thus, the pattern specified by the proposed AS3 element couldbe applied here. The Business Process layer activity concernsmainly the choreography and orchestration processes whichmay be performed with the aid of the adaptive Integrationlayer, investigated in more detail in Section VI.

The presented AS3 element constitutes a standard adapta-tion loop. The activity of this loop could be event-driven or

performed at regular intervals. It could act autonomously or incooperation with other similar elements. For this purpose theAS3 element sends out monitored data and facts, and is ableto receive decisions and actions taken by other AS3 elements.Adaptive Managers from different AS3 elements are also ableto cooperate with one another. This feature makes AS3 suitablenot only for single-layer adaptation but also for making globaldecisions which affect many layers. This issue will be furtherexplained in the next section.

IV. ADAPTIVE S3 STACK

The proposed AS3 element can be applied in a uniform wayacross the S3 stack layers described in Section II. This leadsto the Adaptive SOA Solution Stack, depicted in Fig. 3. Everylayer of this stack is marked with a symbol of the AS3 element.This stack is presented in a slightly modified way comparing tothe original S3 model as the Integration layer is placed directlyabove the Operational Systems layer. In the standard S3 modelthe Integration layer is vertical, to signify its importance foreach horizontal layer. Fig. 3 assumes that every higher layerrelies on the functionality of the lower layers. This is why theIntegration layer is placed just above the Operational Systemslayer.

Operational Systems

Virtualized Execution Infrastructure (VEI)

Integration (ESB)

Service Components (SCA)

Services

Business Process SOA

As

pe

cts

Policy

Observability Manageability

Applications

Figure 3. Adaptive SOA Solution Stack

The Operational Systems layer is usually represented asa Virtualized Execution Infrastructure (VEI). Computationaland communication resources are virtualized, which resultsnot only in better hardware utilization but also higher man-ageability. For instance, a Xen Virtual Machine or a SolarisContainer with CPU and memory usage guarantees could beallocated to process a single service instance with a requiredQoS level. Computational resource allocation might be dynam-ically changed according to the observed load and decisionsperformed by the adaptation strategy. This leads us directly tothe AS3 element concept.

The same considerations apply, in a natural way, to otherlayers of the AS3 stack, giving rise to an adaptive Integrationlayer, Service Components layer, etc.

Adaptation abilities and metrics are discussed extensivelyin the literature [23]. The definition of an adaptation strategyas well as its associated parameters, e.g. threshold points etc.,is always very much domain-specific and must be analyzedin the context of a given application domain, along with apreliminary experimental study. This is why the AS3 model is

5

presented as a framework which needs further refinement. Inthe presented case studies, data is collected from the experi-mental implementation and not from simulation experiments.With large data sets, the efficiency of the AS3 stack could bea significant issue. This is why the following measures havebeen taken:• Each AS3 layer is controlled independently, with dedi-

cated AS3 elements which may be connected in a hierar-chical structure. This concept is similar to the one used byIBM [19] and Motorola [24] in their Autonomic Elementscooperation scheme to control complex systems.

• Each AS3 element is able to communicate monitored dataand facts to other elements. This communication can beperformed very selectively to reduce the amount of datawhich needs to be processed. Event processors can beused for this purpose [20] – a standard solution used bymodern event-driven systems.

• Adaptive Managers activity could be also organized intohierarchical systems. Local decisions could be coordi-nated by higher-level policies. If Rule Engines [21][22]are used for the implementation of the Adaptive Managermodule, this approach is fully supported. Additionally,the RETE algorithm used by Rule Engines offers highscalability even with a single Rule Engine.

The full potential of the proposed approach is manifested inthe cooperation abilities of AS3 components representing dif-ferent layers. For instance, it is possible to monitor the wholeAS3 stack by collecting information from the MonitoringComponent of every deployed AS3 element. This reasoningmay also refer to other types of AS3 components – thus, wecan identify the following important aspects:

1) Observability – the monitoring data and facts are prop-agated from lower layers to higher ones. This couldbe achieved by connecting Monitoring and ExpositionComponents from different AS3 elements;

2) Manageability – management actions are sent betweenManagement Components and can be transformed byExposition Components;

3) Policy – this aspect refers to cooperation between PEcomponents. A hierarchical connection scheme seemsto be the most natural solution.

Together, these three aspects are illustrated as a verticallayer which cuts across all layers of the proposed AS3 model.

Global

Adaptive Manager

ESB

Adaptive

Manager

Monitoring Management

Instrumentation

Virtualized Resources

Adaptive

Manager

Monitoring Management

Instrumentation

SCA

Adaptive

Manager

Monitoring Management

Instrumentation

Exposition Exposition Exposition

VEI ESB SCA

Figure 4. AS3 model case study

A key implementation issue concerns interoperability ofcomponents belonging to different AS3 elements. This issuecan be resolved by applying a common software technology

for all AS3 elements – something that will be discussed inmore detail in subsequent sections.

The AS3 model presents a reference architecture whichis technology-agnostic. While full implementation of thisarchitecture would require significant effort, a good startingpoint is the construction of adaptive layers. The next stepwould be to consider the cross-layer adaptation processes.An example of an AS3 model implementation is presented inFig. 4. In contrast to the AS3 model itself, the implementationdepends on a specific technology – JMX [25], Xen, SolarisContainers, ESB, SCA, etc. This is summarized in Table I.The presented case studies should be considered as proofsof concept. Software technology coherency ensures naturalinteroperability of individual components. In Fig. 4 this isillustrated by connections between Exposition Componentsand the Global Adaptive Manager. Any matching AS3 inputand output elements could be connected in a similar way.

Table IAS3 LAYERS IMPLEMENTATION EXAMPLES

AS3 layer Implementation ManagedResource

AdaptabilityDecision

ServiceComponents

Adaptive SCA Composite Changingof Composition

Integration Adaptive ESB Complex ServiceChoreography

Modificationof Message Routing

OperationalSystems

VirtualExecutionInfrastructure

VirtualAppliances,VM, Containers

Changingof OS ResourcesAllocation

V. ADAPTIVE OPERATIONAL SYSTEMS LAYER

Modern execution environments for SOA operate over vir-tualized execution resources deployed in a physical infrastruc-ture. This leads to the Operational Systems layer with threebasic sublayers: physical, virtualization, and infrastructure,which together constitute the execution infrastructure for SOAapplications.

Each of these sublayers can be further structured withservice orientation principles in mind, resulting in a so-called Service Oriented Infrastructure (SOI) [26]. SOI enablesmoving from dedicated infrastructures for specific applicationsto an architecture in which IT resources and infrastructures’system tools are exposed as services, being defined in resourcepools allocated on demand using virtualization techniques.

Adaptive management of SOI involves open mechanisms formonitoring and management of infrastructure resources andservices. In general, we can distinguish at least two types ofresources whose parameters must be subject to monitoring:(i) Middleware which is an application container for givenSOA services, and (ii) Virtual Execution Infrastructure, inwhich application containers operate. Monitoring processesapply to such parameters as actual resource usage, QoSattributes (if SLA contracts are maintained) and informationabout service availability. Their principal task is to collectcomprehensive information about the history and state ofservices necessary during planning and realization of specificadaptation strategies.

When analyzing the relationship between SOI and the S3Model Operational Systems layer, which includes all appli-cation assets running in a virtualized IT infrastructure, is

6

the main point of interest. SOI tools should enable effectiveprovisioning of databases, transaction processing systems,middleware (e.g. J2EE or .NET) and SOA services runningin a virtualized infrastructure. In fact, the SOI architecturetends to deliver services that can be described as a Platformas a Service (PaaS) and Infrastructure as a Service (IaaS).

Currently many virtualization technologies exist based ondomains [27], virtual machines [28] and OS containers [29].When comparing domains to virtual machines, they can beclassified as hardware or firmware functions that providestronger isolation compared to virtual machines. Both enableserver virtualization and subdivide physical resources (CPU,RAM, network), but domains typically have lower overhead.A disadvantage of domains is the fixed number of hosted OSinstances. Virtual machines are also managed by a hypervisorwhich itself is an operating system implemented in software,without fixed limits on the number of running OS instances.OS containers can run in VMs, but have minimal overheadand their isolation is accomplished by restricting the scopeof system calls to the container from which they are invoked.Thus, there is no need for CPU-intensive emulation performedin hypervisors.

Domains and virtual machines host OS instances that canalso be virtualized through OS virtualization techniques andso-called multilevel virtualization. This approach is very flex-ible in terms of computational isolation and level of resourcemanagement, but it also introduces complexity in terms ofmonitoring and management.

Despite the fact that virtualization is a very effective mech-anism for consolidation of workloads and provides meansfor assigning resource consumption boundaries, finding ap-propriate resource attributes values that guarantee a givenservice level is not a trivial task. Considering such factors, onecomes to the conclusion that there is a need for a workloadmonitoring and modeling tool that enables monitoring andplanning system performance in virtualized environments. Thistype of software platform should automate the managementof virtualized resources and provision of information aboutrunning workloads in a given service center.

A. Architecture

The architecture based on the SOI concept assumes a map-ping between a typical IT infrastructure and a set of services.Such services are usually based on shared virtualized resources(servers, communication infrastructure, data storage and appli-cations). To ensure flexible mechanisms for creation of SOAenvironments that exploit the SOI architecture concept, suit-able SOA Virtualized Infrastructure mechanisms for regulatingresource access should exist. These mechanisms are calledResource Management Systems (RMS) and are particularlyimportant in situations where resources are shared.

The usage of virtualization techniques is a natural evolutionof existing RMS in distributed environments. Hence, the solu-tion presented in this section can be treated as the answer to thequestion whether the virtualization offered by available tech-nologies is mature enough to develop virtual computers andvirtual communication infrastructures to effectively organize

processing in distributed environments. A key point to addressis whether efficient management of on demand resources withvirtualization techniques is possible using such mechanismsas dynamic infrastructure instantiation and resource allocationaccording to the requirements of applications or changingenvironmental conditions. These mechanisms should be ableto fully utilize the available infrastructure and decrease theoperational costs through resource usage reduction, with noimpact on the service QoS level.

The Operational Systems layer that includes the virtualizedIT infrastructure and hardware assets is used for adaptivevirtualized infrastructure development. A Virtual ExecutionInfrastructure model that takes this approach into account hasbeen proposed and analyzed in the context of SOA-relatedtechnologies. The novelty of the proposed approach can beexpressed as several important aspects [30]:• The VEI environment enables creating a container for

resource allocation (grouping virtual resources) in thecase of synchronized usage.

• Once deployed, the VEI container can be modified duringruntime so the running application can obtain or releaseaccess to physical resources during execution.

• The VEI runtime management can be performed manu-ally or by a policy engine, executing policy rules definedby the system administrator.

• The VEI container deployment and runtime managementshould be neutral from the perspective of SOA middle-ware usage.

To other AM

...

Adaptive Manager

Policy

repository

Policy

Engine

Domains(LDOM/LPAR)

OS OS...

Hypervisor...

VMs(Xen/VMware)

OS OS...

Hypervisor...

Container Container...

OS

OS(OpenVZ,Solaris Containers)

Domains Hypervisors

Dynamic

LoadingRepository

Auto

Configuration

Self

OrganizationDiscovery

Exposition – Service Oriented Infrastructure

Monitoring

OS Domains Hypervisors

Management

OS

Monitored data Facts out Decisions Actions

Virtualized Resources

Figure 5. Architecture of Adaptive Operational System layer

The VEI system architecture presented in Fig. 5 leveragesthe pattern introduced in Section III. More precisely, itscomponents are specified as follows:• Virtualized Resources – this sublayer consists of the

heterogeneous resources comprising the infrastructure. Italso creates an abstraction of physical resources throughproper instrumentation mechanisms. Instrumentation re-lies on provision of dynamic resource grouping and isused by the management subsystem. Resource groupingrelies on VM virtualization or container creation anddynamic modification of its configuration accomplishedvia virtual networks (as well as via modification of itsdynamic parameters). This subsystem is also responsi-

7

ble for provisioning components enabling distribution ofoperating system images over the virtualized resourceinstances.

• Monitoring – this sublayer collects and aggregates in-formation about the virtualized resources. Its operationrelies on unification of information coming from differentcomponents (such as CPU, RAM) of virtual resources.Subsequently, this information is delivered to components(in the Exposition layer) as rule engine facts describingthe system state.

• Exposition layer – components added to adjust and unifyvirtualization mechanisms to simplify the interfaces re-alizing basic VEI system functions related to resourcemanagement. These components are exposed as SOIservices and provide the following functionality:

– self-configuration and reconfiguration (sometimesalso called auto-configuration) supports the diversityof managed virtualization technologies. The systemmust be able to adapt to specific virtualization plat-forms and automatically install appropriate versionsof components that are dynamically loaded and pro-vide sensors and effectors to be used in a given hy-pervisor and OS. This ensures that the system is easyto deploy. Self-organization would enable dynamiccreation of lists that contain all available physicalnodes (which are further virtualized) and domainswith hosted OS instances. Such functionality coversmany requirements related to managed elements thatshould be automatically discovered by the AdaptiveManager during system startup or whenever a newelement appears [8],

– representing monitoring data and system configura-tion using facts,

– provisioning services for searching and localizationof resources (specifically, VEI system componentsrealizing resource management); registration and re-trieval of other components,

– resource management policy enforced via exposedeffectors.

• Management – components of this sublayer executeproper actions that are determined by the Adaptive Man-ager subsystem. The main operations that are executed bythese components implement the controlling properties ofthe application’s execution environment (VEI). These op-erations include resource optimization decisions. Actionsthat result from and are connected with changes in systemcomponents introduce adaptability into the OperationalSystems layer.

• Adaptive Manager – implemented as a Policy Engine(Drools Rule Engine), which performs management ac-tions referring to resource allocation for VEI.

B. Implementation Details

Adaptive Operational System layer is based on virtualizationtechnologies. Feature analysis and practical verification offunctionality underpin our selection of virtualization tech-nologies in different types as hardware virtualization (Oracle

LDOM), paravirtualization (Xen) and operating system con-tainers (Solaris Containers).

The need for resource management based on complexheterogeneous mechanisms (mentioned above) has led us tochoose Java Management Extensions (JMX) technology fordeveloping the prototype of the Adaptive Operational Systemslayer (more specifically, its resources and instrumentationlayer). By using this technology we can create and unifydiverse methods of distributed object management in theform of a uniform and clear programming interface. A moreextended study on implementing such complex systems ispresented in [31].

C. Case StudyThe prototype VEI implementation was tested on dedicated

hardware and a dedicated network. This infrastructure con-sisted of a set of connected servers. The scenario assumed test-ing the proposed solution in conditions similar to a distributedenvironment. Therefore, resources were divided into threeindependent computing clusters and connected with networkdevices whose configuration corresponded to communicationparameters available in WAN networks.

The system was tested through measurement of parametersthat describe the resource level usage (e.g. average CPU us-age). The sample application was a concurrent implementationof particle interactions computing service for computers withdistributed memory, running in an MPI environment.

The experiment ran two instances of the test application intwo groups of distributed resources connected with a WANnetwork with limited bandwidth. Optimization consisted incorrecting virtual machine distribution (via VM migration) toeliminate the WAN bottleneck.

The purpose of the experiment was to show the abilityto improve application operation through autonomic modifi-cations of VM deployment according to information derivedfrom monitoring network communication1. This optimizationwould be essential for distributed applications which need toexchange large amounts of data.

To conduct measurements, two VEI instances were createdand the test application executed within them. The initialvirtual machine deployment was random. The system collectedinformation from network communication monitoring modulesand enforced its optimization decisions by changing VMdeployment. The optimization algorithm was implemented asa rule system.

Fig. 6 shows the load carried by the test application de-pended on the actions taken by the system. In the initial phase,when migration is taking place, access to resources is limited– hence the application achieves lower performance comparedwith optimization-free execution. Once the migration processconcludes, a significant performance increase is observed. Thisis because the bottleneck (in the form of the WAN networkcommunication) has disappeared. The next result is a reductionin application response time.2

1Executing two tightly bound VMs within one physical node results in thecommunication having practically unlimited bandwidth.

2The profit would be more significant for applications with long executiontimes.

8

Figure 6. The load carried by two VEI instances and the whole system

Another test was performed on a Solaris 10 instance witha number of running containers. Solaris Resource Managerenables specifying resource consumption limits for given con-tainer instances through the use of FSS (Fair Share Sched-uler) [32], allowing optimal use of virtualized system re-sources. The system administrator must specify the importanceof each workload running in a given container by assigning toit a number of shares according to the FSS model. In Solaris,these limits are expressed via resource control entities thatcan be set statically or changed dynamically during runtime.The latter case occurs in dynamic environments when newSOA services are provisioned over virtualized resources andnew limits on resource consumption must be assigned. Anotherscenario involves migration of the VM which hosts the Solarisinstance – in this case operating conditions change as thetarget node might contain more resources and the internalconfiguration of FSS should be adjusted. The adaptationstrategies can be expressed with control algorithms based onthe control theory [33] and structured as open or closed-loopcontrollers. Given (i) Sw – shares assigned to workload W ,(ii) N – number of active workloads, (iii) Si – shares assignedto active workload i = 1, . . . , N , the relative entitlement Ew

of workload W can be expressed with the following equation[34][35]:

Ew = Sw/N∑1

Si (1)

Transformation of equation (1) yields the following formula,to be used by the open-loop controller, where (i) Nw is thenumber of workloads; (ii) number of active workloads changesat time t according to activity state vector At = [At

1, . . . , AtNw

]where At

i = 0 if Wi is not active and Ati = 1 if Wi is active,

i = 1, . . . , Nw,

Stw = (Uw

Nw∑i6=s

Si ∗Ati)/(1− Uw) (2)

Practical exploitation of such a controller is depicted inFig. 7. The goal of the management policy expressed inDrools was to guarantee CPU consumption on the level of 70percent. It can be observed that following the activation of thepolicy, the settling time is approximately 2 minutes and thetarget workload is able to consume enough CPU resources.

The presented scenarios describe one of the many practicalaspects of system operation and prove the concept of applyingvirtualization techniques as an effective way of regulatingaccess to resources and binding services to resources througha dedicated execution environment is useful in practice.

Figure 7. The open loop controller for adaptive management of CPUconsumption of Solaris container

VI. ADAPTIVE ESB

This section presents how the AS3 element concept canbe applied to constructing the Adaptive ESB, which is themain building block of the Adaptive Integration layer. Asmentioned earlier, the Enterprise Service Bus is an integrationtechnology that allows architects to compose applications withservices using various communication protocols. ESB providesmechanisms for message normalization and routing betweenselected components. A generic structure of an Adaptive ESBfunctional element is shown in Fig. 8. As it was alreadydescribed the policy engine perceives the system as an abstrac-tion exposed by the exposition layer, which can be definedas a complex service execution model or a simple set ofservices involved in execution. In both cases an adaptationpolicy has to be defined. This policy is used to represent a setof considerations guiding decisions. Each adaptation policymay express different goals of system adaptation, such asminimizing system maintenance costs or ensuring particularQoS parameters. Design-time decisions cannot, however, takeinto account every context of service execution and lower-layer architectural configuration. Hence, runtime architecturaldecision processing is particularly important for the S3 stack.The ESB layer must therefore be equipped with suitableadaptability mechanisms enabling the enforcement of thesedecisions.

A. Architecture

The Adaptive ESB functional element is constructed aroundthe AS3 element pattern defined in Section III and depictedin Fig. 8. A number of distributed adaptive elements canbe managed by a global Policy Engine in accordance witha high-level strategy. The instrumentation layer enriches theESB with additional elements, providing adaptability transfor-mations necessary to achieve adaptive ESB (described in thefollowing sections). The monitoring layer is responsible for

9

Monitored data Facts out To other AM Decisions Actions

Enterprise Service Bus

...

Adaptive Manager

Policy

repository

Policy

Engine

Exposition

Model Analyzer

System

Exposition

Agent

Service

Matchmaker

Monitoring

Monitoring

Agent

Management

Management

Agent

Instrumentation

Service

Repository

NMR Routing

Table

Interceptor

Dispatcher

Interceptor

Dispatcher

CEP

Facts

Engine

Metrices

Repository

...

Figure 8. Adaptive ESB functional elements

supplying notifications of events occurring in the executionenvironment. As the volume of monitoring information gath-ered from the ESB could overwhelm the Exposition layer,events are correlated with one another and notifications aresent only about complex events. Complex Event Processingcan be compared to an inverted database containing storedstatements: as data arrives in real time, these statements areexecuted and notifications are sent to registered listeners. TheAdaptive Manager layer analyses facts and infers decisionswhich are then implemented in the execution environment.Facts representing the state of the system or events occurringin the system are supplied by the Exposition layer.

The approach presented in this section is a model-drivenadaptation policy for SOA. The system analyzes compositeservices deployed in the execution environment and adapts toQoS and QoE changes. The user composes the applicationin a chosen technology and provides an adaptation policyalong with a service execution model. The architecture-specificservice composition layer continuously modifies the deployedservice in order to enforce the adaptation policy. The abstractplan, providing input for architecture-specific service compo-sition, can be hidden and used only by IT specialists duringapplication development. System behavior is represented bythe service execution model.

The composite service execution model is an abstractionof the execution environment. It covers low-level events andrelations between services and exposes them as facts in amodel domain for the Policy Engine. Decisions taken in themodel domain are translated to the execution environmentdomain and then executed. The Model Analyzer Systemgathers monitoring data from the execution environment viaMonitoring and Management Agents.

This process can be described as architecture-specific ser-vice composition adaptation that is performed in order toachieve the required value of QoS or QoE guided by theadaptation policy. The adaptation loop addresses service selec-tion, binding protocol and interaction policy choices. Thus, theadaptability process mainly concerns integration mechanisms.

B. Implementation Details

Monitoring ESB allows management actions to be per-formed. The presented concepts cover selected issues related

to improving communication over ESB by separating trafficinto several flows, which can then be independently handled.This leads to increased scalability and is required by manyaspects of infrastructural functionality, including monitoring,data collection, management information distribution and se-curity considerations.

The proposed mechanisms are compliant with existing inte-gration technologies. Interceptor mechanisms enable dynamiccontrol of service or component invocation, along with sensorsand effectors necessary to close the adaptation loop.

The proposed adaptation mechanism provides elementsnecessary to close the control loop for ESB. It is used forcompositional adaptation in systems which modify servicecomposition while retaining their overall functionality. ESBis suitable for implementation of such adaptation, since onecan modify message flows between components in accordancewith high-level goals.

Sensors

An adaptive system should react in accordance with variousgoals, requiring several types of information from ESB. Inmost cases, this information will be disjunctive, so one wouldexpect to deploy specialized types of sensors rather thangeneric ones. Interceptor design patterns fulfill these require-ments, allowing interceptors to be deployed or undeployed atruntime.

A message is created in a service, is passed through thespecialized Service Engine and is sent to the NormalizedMessage Router (NMR), which reroutes it to a particulardestination through the same components. Common usage ofthis concept includes:• QoS Measuring – the functionality of monitoring inter-

ceptors is not limited to creating copies of messagessent through them, but may include more complex tasks,providing quantitative information related to service in-vocation. In the QoS interceptor, a message sent to aservice is stored in the internal memory of the interceptor.When a response is generated, the previous message iscorrelated and response time is evaluated;

• Tagging/Filtering – interceptors are commonly used formessage tagging and filtering.

Effectors

Adaptive software has to modify itself to the changes in theexecution environment. This adaptation requires performingactions (via effectors) that modify the execution characteristicsof a system. For any sort of system, a set of operations has tobe defined, along with places where these modifications shouldbe introduced. It has been found that modifying messageroutes can affect the adaptation of complex services deployedin ESB.

Rerouting messages to other instances is justified onlywhen these instances share the same interface and provideidentical functionality. Current implementations of ESB thatare compliant with the JBI specification share some commonattributes used in the course of message processing. Eachinvocation of a complex service is described by its CID

10

Table IINMR ROUTING TABLE

Priority VESB CID Intentional

Service Name

EID Decision

1 n/a n/a n/a + Service Name

2 n/a + + n/a Service Name

3 + n/a + n/a Service Name

4 n/a n/a + n/a Service Name

5 n/a + n/a n/a Service Name

6 + n/a n/a n/a Service Name

7 n/a n/a n/a n/a Service Name

(Correlation ID) and is constant for one invocation, even whenpassed among services. A particular message sent betweenservices is described by an EID (Exchange ID). Generallyspeaking, the invocation of a complex service is described bya CID and consists of several message exchanges describedby an EID. Extending the Normalized Message Router witha routing algorithm capable to modify message routing wouldyield an adaptive ESB.

Once the message reaches the NMR, the routing algorithmrelies on matching the message to routing rules in the routingtable. If the message matches a routing rule, that rule is firedand the Service Name from the routing rule substitutes theintended destination Service Name. Routing rules are splitinto groups – Virtual ESB (VESB) with different priorities,analyzed in a particular order. In every message, parameterssuch as VESB tag, Correlation ID, intended Service Nameand Exchange ID are matched to routing rules. If the messagematches several rules, one of them is selected on a round-robinbasis to provide load balancing.

Depending on the priority value, different parameters arematched. The presented matching criteria are summarized inTable II. The lower the priority value the more importantthe routing rule. Some attributes are omitted when processingrules, though each routing rule returns a Service Name as aresult. The decision element which closes the adaptation loopalready presented in Fig. 8 gathers information about ESBfrom sensors and uses effectors to dynamically modify therouting table at runtime.

C. Case Study

The purpose of this scenario is to demonstrate how thesystem responds to disturbances in the execution environment.

Let us assume that one would like to create a GeoWeatherservice providing weather information for a given location.Location data will be provided as a zip code, GPS location, IPaddress of a computer, or country name. Another assumptionis that accuracy can be limited to cities.

Widely available weather services do not provide weatherinformation for GPS coordinates. Instead, they return weatherinformation for a given readable address – thus all possibleinput formats have to be converted to addresses and thenvalidated against the weather information service.

In order to better present system responses, a fragment ofthe service is analyzed, i.e. it is assumed that requests onlycontain geographical locations. The ESB contains several otherservices that can be used interchangeably. The model of theanalyzed service and its projection onto instances found in the

START STOPS1

S2

Location

Weather

Global

START STOP

LocationA

LocationB

WeatherA

WeatherB

WeatherC

Projection

S6

Weather

USA

WeatherU

Figure 9. Projection of an Abstract Composite Service into a CompositeService

ESB is depicted in Fig. 9. There are six possible combinationsof service instances that might be executed.

Without an adaptation policy, user requests are handledby services called locationB and weatherB. In normal cir-cumstances the agreed-upon response time is in the rangeof 400-450 ms. Unfortunately, sometimes these instances areoverloaded or unloaded, resulting in uneven response timesof the whole complex service. Areas marked in Fig. 10 showwhen disturbances are observed. In the 60-120 s period thelocationB service execution time increases from about 200 msto 500 ms, inducing an overall execution time of 700 ms whichis 300 ms more that it should be. In the 180-240 s period, theweatherB service responds about 100 ms faster than normal,resulting in the shortest overall execution time. During thefirst disturbance phase, the client did not receive a responsein the required time, whereas during the second phase theclient obtained better-than-agreed upon service quality. With

Figure 10. Evaluation of ESB use case scenario

an adaption policy active, the system counteracts disturbancesin the execution environment and switches to a different setof service instances whenever it is necessary to maintain theagreed-upon level of QoE.

VII. ADAPTIVE COMPONENTS

Adaptive Components are used in the Adaptive S3 modelto provide adaptability for the Service Components layer. The

11

main goal of Adaptive Components is to provide a backgroundfor creating atomic services used by the other layers.

In SOA systems, atomic services are mainly comprised ofcomponents. The need to ensure implementation and com-munication protocol independence forces the selection of anindependent integration environment. The Service ComponentArchitecture (SCA) specification [36] provides such a solution.It supports several component implementations (such as Java,C++, BPEL and Spring) as well as various communication pro-tocols (Web Services, RMI and JMS). Moreover, it is highlyextensible, as evidenced by different SCA implementations[37] which introduce additional technologies not covered bythe original blueprint.

However it should be noted that the SCA specificationlacks of adaptability mechanisms, which play a crucial rolein ensuring conformance between the provided services andchanging user requirements (i.e. Quality of Service).

The SCA specification involves the concept of a compositewhich consists of a set of components connected by wires.A wire consists of a service representing the functionalityexposed by one component, a reference representing thefunctionality required by another component (delegate object)and a binding protocol which represents the communicationprotocol between the reference and the service. Several com-ponents in an SCA composite may expose services for externalcommunication. These services are further exposed e.g. viaESB.

Services created using SCA composites should be able toadapt to changing customer requirements and service providercapabilities (such as different CPU speeds resulting frominfrastructure changes etc.) Nonfunctional customer require-ments are recognized as QoS metrics and may be providedby the QoS layer of the S3 model. On the other hand, themeasured service QoE, represents actual capabilities of aservice. In an ideal case, QoE metrics should be as close toQoS requirements as possible.

An SCA composite may be perceived as a directed graphwith nodes representing components and edges representingwires (directed from references to services), hereafter calleda Composition Instance (CI). A CI is connected with aspecific QoE description derived from a composite. A setof Composition Instances, which meet the same functionalrequirements and differ only with respect to nonfunctionalones (QoS) is called a Composition. Compositions may alsobe represented as a directed graph, created by joining all CIswhich provide a given element of functionality. The rulesfor joining CIs are as follows: if CI1 and CI2 use the samecomponent as a specific node, these components can be joined;otherwise both components need to be added to the graph.Such a solution reduces the amount of resources requiredby all CIs (by exploiting shared nodes) and enables moreefficient CI processing. A sample Composition with a selectedComposition Instance is depicted in Fig. 11.

A. Architecture

The architecture of the Adaptive SCA is depicted in Fig. 12,and it is a realization of the previously described AS3 Element.

SCA Composite

v0, r01

Component E, v5

s51

Component G, v7

s71

Component F, v6

s61

Component B, v2

s21

r21

Component D, v4

s41

r41

Component A, v1

r11s11

Component C, v3

s31 r31

r32

e0111

e1121

e1131

e1141

e4171

e3271

e3161

e2151

Figure 11. Sample Composition with a selected Composition Instance

The Adaptive SCA service is a service created using SCAtechnology with the proposed enhancement, which could beintegrated by the Adaptive ESB Element.

Monitored data Facts out To other AM Decisions Actions

Service Component Architecture

...

Adaptive Manager

Policy

repository

Policy

Engine

Exposition

Mapping

Engine

Exposition

Agent

Component

Discovery

Monitoring

Monitoring

Agent

Management

Policy

Manager

Instrumentation

ServiceReferenceSCA

ContainerComponent

Facts

Generator

Instance

Manager

Binding

Manager

Binding

Figure 12. Adaptive SCA Architecture

Instrumentation is used to enhance the SCA Container tomanage components, their services and references, and bindingprotocols used for remote communication. The monitoringlayer includes the Monitoring Agent, which gathers QoE met-rics for the service. The exposition layer is mainly composedof the Fact Generator (used to create specific facts furtherused by the Policy Engine), and the Mapping Engine, whichis responsible for applying mappings between the Compositionand Composition Instance into a particular set of components,discovered by the Component Discovery. Policy, Instance, andBinding Managers perform low-level management tasks, suchas applying the selection of components taking part in theComposition Instance.

B. Implementation Details

Adaptive SCA comes as a set of extensions for the Ser-vice Component Architecture [36] (in particular, the ApacheTuscany SCA [37] implementation). These extensions enhancethe SCA component model, turning it into an Adaptive SCAcomponent. Low-level extensions provide interceptors injectedinto SCA references to enable sensor invocations and applyselection of proper services and binding protocols (effectors),as depicted in Fig. 13.

For better understanding of this process, the figure shouldbe compared with the service model (cf. Fig. 11). A referenceis connected with several component services in the Com-position, but only one should be selected within the current

12

Figure 13. Adaptive SCA Component with Interceptors and ReferenceSelection Process

Composition Instance. This selection is performed by Instanceand Binding Effectors.

The functionality of sensors and effectors is exposed by theMonitoring and Management Interface (MMI), which is usedon the upper level of the AS3 Element.

The Policy Engine is used to process adaptation policiesprovided with the service description (e.g. by the service cus-tomer). Such policies describe QoS requirements using a high-level abstract language and they are further mapped to specificrules used to select proper CIs. CI descriptions (maintainedby the Adaptive SCA Element) are used to perform selectiondecisions using component reference effectors exposed byMMI (cf. Fig. 13).

C. Case Study

Our case study presents a possible adaptation of a typicalservice created using Adaptive SCA. The service providesbanknote recognition functionality. The Composition whichrealises this functionality is depicted in Fig. 14.

NeuralNetwork

Image

Recognizer

EdgeDetector

ImageMagick

ImageConverter

NetPBM

ImageConverter

FileLoader

ImageLoader

EdgeRecognizer

Banknote

Recognizer

Figure 14. Case Study Composition

The main component, BanknoteRecognizer, implements theoverall functionality and contains two references. The firstreference is used to provide the functionality of loading animage from a remote location and converting it to a specificfile format (using specialized libraries, such as ImageMagickor NetPBM), while the second one is used to scan two imagesfor similarities.

There are four Composition Instances (CIs) defined inthe Composition, which differ only in their nonfunctionalparameters. The CIs are as follows:

CI 1: Banknote Recognizer, Image Loader, File Loader,NetPBM Image Converter, NeuralNetwork ImageRecognizer;

CI 2: Banknote Recognizer, Image Loader, File Loader,NetPBM Image Converter, Edge Recognizer, EdgeDetector;

CI 3: Banknote Recognizer, Image Loader, File Loader,ImageMagick Image Converter, NeuralNetwork Im-age Recognizer;

CI 4: Banknote Recognizer, Image Loader, File Loader,ImageMagick Image Converter, Edge Recognizer,Edge Detector.

with the quality metrics presented in Table III:

Table IIIQUALITY OF SERVICE FOR CASE STUDY CIS

CI name invocationtime [s]

cost[eurocents]

memoryusage [MB]

CI 1 5 2 2000CI 2 8 5 1000CI 3 2 9 1500CI 4 5 4 1400

The presented experiment shows a typical situation, whenthe capabilities of the service provider change temporarily,e.g. due to a brief system overload (which may result fromincreased service demand, exposure of new services, etc.).

The adaptation policies used in the case study are definedas follows:• keep average invocation time between 4 and 6 seconds;• keep average cost per invocation between 3 and 6 euro-

cents;• maximum allowed invocation time is 11 seconds;• keep average memory usage between 1300 MB and

1800 MB;• if invocation time and cost requirements are fulfilled, try

to find a CI with lower cost.These policies are transformed to low-level rules by the

Policy Engine, following which the adaptation is performed.During service execution the system discovers that CI 4 maybe used (thus the provided QoE meets requirements describedby the policies). However, after 55 seconds of service execu-tion, the invocation time of CI 4 increases to 10 seconds, whichis not acceptable. This causes selection of the other CIs, whichin turn results in proper average QoE. After 87 seconds, theinvocation time of CI 4 reverts to its initial value (5 seconds),hence this CI is again selected. The observed QoE achievedwith this adaptability process is depicted in Fig. 15.

VIII. RELATED WORK

The presented work concerning VEI is very much relatedto research on Grid resource management. The paper [38]presents how to develop collaborative Grids into stable, flexi-ble and dynamic resource management environments by meansof a Collaborative Awareness Management (CAM) model.

13

Figure 15. QoE in the case study experiment

CAM optimises resource collaboration, promotes cooperationand responds to specific circumstances.

Management of the underlying network infrastructure sup-porting Grid communications is not performed by the samemanagement systems which manage the Grid itself. In the pre-sented scenario, integrated management of VEI and networkcould simplify the overall maintenance processes. Work [39]proposes a hierarchical policy-based architecture whose goalis to allow such integration where Grid policies are translatedto network policies according to rules defined by networkadministrators. It also describes a prototype implementationof such an architecture.

As it can be observed that most of these efforts addressthe specific issue of virtualizing computing resources andconcentrate on problems resulting from integration with ex-isting environments at the management level. There is anobservable lack of complex solutions addressing differentresource virtualization mechanics.

Some projects attempt to extend adaptability mechanismsin ESB, but these solutions are focused on selecting the mostappropriate service instances without evaluating how it mayinfluence overall composition. Chang et al. propose a dynamiccomposition handler (DCH) [16] for ESB. Business processesare defined using BPEL and may include several activities.Some of them may have more than one service componentwhich can perform a given activity. DCH determines the mostappropriate service component and invokes it according to therequirements and circumstances of various service consumers.Bai et al. propose Dynamic Routing in the Enterprise ServiceBus (DRESR) [40] framework to enable dynamic messagerouting. The authors define an Abstract Routing Table as anexecution sequence of services in terms of abstract servicespecifications. Prior to execution of an abstract service, theframework analyses existing service providers and chooses onethat meets nonfunctional requirements such as response time.The services are evaluated based on current testing resultsas well as historical data. Chen et al. present an AdaptableService Bus (ASB) [41] that enables, to some extent, dynamiccomposition of services. In order to modify the behavior ofthe application at runtime, developers can adjust the parametervalues maintained in external storage.

In [15][6], the authors present results of their work in the

DiVA [42] project, which focuses on dynamic variability incomplex, adaptive systems. In several aspects, this work isrelated to the concepts of Adaptive Components. The aim ofthe prepared dynamically adaptive systems is to provide thefunctionality described with a specified model, according tospecified QoS and current context (e.g. user location). The au-thors propose several metamodels for architecture, context andreasoning description. Although adaptation to context changesis precisely described, the methods of adapting to changingQoS requirements and capabilities are only mentioned.

Vukovic, in [14], presents service composition methodsfor a context-aware environment, especially a mobile one.The author investigates planning-based service composition[13][43]. The framework, called GoalMorph, mainly focuseson resilience to failures arising both at composition andexecution time.

S-Cube (Software Services and Systems Network [44])is a project funded by the European Community’s SeventhFramework Programme. One of its activities (WP-JRA-1.2)focuses on “Adaptation and Monitoring Principles, Techniquesand Methodologies for Service-based Applications [12].” Ac-cording to its description, it should propose solutions fordifferent levels of adaptation, in particular for: optimization,recovery, QoS-based adaptation, evolution, mediation. In con-trast to the presented work it uses adaptation mechanisms forcomposing services into business processes and recomposesthem according to adaptation strategies. Unfortunately, thisproject is scheduled for 2007-2013 and currently there are nodetailed results on the investigation of adaptation mechanisms.

IX. CONCLUSIONS AND FUTURE WORK

The paper presents the concept of the Adaptive S3 Model.Individual layers of this model are currently in the process ofdevelopment and subject to intensive research which requiresa lot of effort. The major contribution of this paper is theproposition of how the adaptation loop construction – the AS3element pattern – could be applied in a uniform way across theS3 layers to reduce the complexity of SOA applications QoEand QoS governance. The essential part of this study showspractical usage of the AS3 pattern across different layers.Such an approach, supported by proper selection of availablesoftware tools for code instrumentation, monitoring, and policyprocessing, leads to an efficient and scalable solution. This hasbeen illustrated by the implementation of adaptive OperationalSystems, Integration and Service Components layers.

Uniform implementations of the AS3 elements over dif-ferent layers facilitate their interoperability and provide op-portunities for multilayer adaptation of SOA systems. Thischallenge has not been explored in this paper but the presentedsystems are fully prepared for such experiments and weintend to pursue them in the course of our future work. Theintegrated adaptation of SOA applications and their executionenvironments should lead to full control over service QoS andQoE. Realization of this vision requires careful analysis ofnew adaptation strategies, metrics and models.

The proposed study relies on the adaptive system concept.The complexity of management actions means that auto-nomic systems, being the most mature and advanced form

14

of adaptation, are an appropriate solution in this regard. Morecomplex adaptation algorithms can take into account additionalknowledge gained during system operation, while other partsof the proposed system can be applied without any changes.

The paper focuses on the Adaptive S3 model concept, whilesoftware tools for AS3 elements for particular layers are notpresented. A collection of these tools, called AS3 Studio[45], is now under development at the Computer ScienceDepartment, AGH University of Science and Technology. AS3Studio supports implementation and deployment of adaptationloop components via a user-friendly GUI. It also facilitatesconvenient definition of policy rules and retrieval of monitor-ing data. It is constructed as a set of plug-ins for the Eclipseframework.

ACKNOWLEDGMENTS

The research presented in this paper was partially supportedby the European Union in the scope of the European RegionalDevelopment Fund program no. POIG.01.03.01-00-008/08.

REFERENCES

[1] P. Bachara, K. Blachnicki, and K. Zielinski, “Framework for applicationmanagement with dynamic aspects j-ears case study,” Information andSoftware Technology, vol. 52, no. 1, pp. 67–78, 2010.

[2] N. Bartlett, OSGi In Practice, 2009.[3] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neuge-

bauer, I. Pratt, and A. Warfield, “Xen and the Art of Virtualization,” inSOSP ’03: Proceedings of the nineteenth ACM symposium on Operatingsystems principles. New York, NY, USA: ACM, 2003, pp. 164–177.

[4] E. L. Haletky, VMware ESX Server in the Enterprise: Planning andSecuring Virtualization Servers. Prentice Hall, 2008.

[5] M. Lageman, Solaris Containers What They Are and Howto Use Them, Sun Microsystems, 2005. [Online]. Available:http://www.sun.com/blueprints/0505/819-2679.pdf

[6] F. Fleurey, V. Dehlen, N. Bencomo, B. Morin, and J.-M. Jezequel,“Modeling and Validating Dynamic Adaptation,” pp. 97–108, 2009.

[7] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,”Computer, vol. 36, no. 1, pp. 41–50, 2003.

[8] A. G. Ganek and T. A. Corbi, The dawning of the autonomic computingera, IBM Corporation, 2003.

[9] A. Janik and K. Zielinski, “Adaptability mechanisms for autonomicsystem implementation with aaop,” Softw., Pract. Exper., vol. 40, no. 3,pp. 209–223, 2010.

[10] L.-J. Zhang, N. Zhou, Y.-M. Chee, A. Jalaldeen, K. Ponnalagu, R. R.Sindhgatta, A. Arsanjani, and F. Bernardini, “Soma-me: a platform forthe model-driven design of soa solutions,” IBM Syst. J., vol. 47, no. 3,pp. 397–413, 2008.

[11] A. Arsanjani, L.-J. Zhang, M. Ellis, A. Allam, and K. Channabasavaiah,“S3: A service-oriented reference architecture,” IT Professional, vol. 9,pp. 10–17, 2007.

[12] C. Cappiello, K. Kritikos, A. Metzger, M. Parkin, B. Pernici, P. Plebani,and M. Treiber, “A Quality Model for Service Monitoring and Adap-tation,” in Workshop on Monitoring, Adaptation and Beyond (MONA+)at the ServiceWave 2008 Conference. Springer, 13 December 2008.

[13] D. W. Evren, D. Wu, E. Sirin, J. Hendler, D. Nau, and B. Parsia,“Automatic Web Services Composition Using SHOP2,” in In Workshopon Planning for Web Services, 2003.

[14] M. Vukovic, “Context Aware Service Composition,” Ph.D. dissertation,University of Cambridge, April 2006.

[15] B. Morin, O. Barais, J.-M. Jezequel, F. Fleurey, and A. Solberg, “Mod-els@Run.time to Support Dynamic Adaptation,” Computer, vol. 42, pp.44–51, 2009.

[16] S. H. Chang, H. J. La, J. S. Bae, W. Y. Jeon, and S. D. Kim, “Designof a dynamic composition handler for esb-based services,” in ICEBE’07: Proceedings of the IEEE International Conference on e-BusinessEngineering. Washington, DC, USA: IEEE Computer Society, 2007,pp. 287–294.

[17] C. I.Y., N. G.K., and L. C.Y., “A runtime-adaptable service bus designfor telecom operations support systems,” IBM Syst. J., vol. 47, no. 3,pp. 445–456, 2008.

[18] K.-J. Lin, M. Panahi, Y. Zhang, J. Zhang, and S.-H. Chang, “Buildingaccountability middleware to support dependable soa,” IEEE InternetComputing, vol. 13, pp. 16–25, 2009.

[19] J. O. Kephart and D. M. Chess, “The Vision of Autonomic Computing,”Computer, vol. 36, no. 1, pp. 41–50, January 2003.

[20] “Esper – Event Stream and Complex Event Processing for Java,” ,http://www.espertech.com/, accessed on December 2009.

[21] P. Browne, JBoss Drools Business Rules. Packt Publishing Ltd., 2009.[22] E. Friedman-Hill, Jess in Action : Java Rule-Based Systems (In Action

series). Manning Publications, December 2002.[23] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng,

“Composing adaptive software,” Computer, vol. 37, no. 7, pp. 56–64,2004.

[24] J. Strassner and D. Raymer, “Implementing next generation servicesusing policy-based management and autonomic computing principles,”in NOMS, J. L. Hellerstein and B. Stiller, Eds. IEEE, 2006.

[25] Java Management Extensions (JMX) Specification, Version 1.4,JSR 160, Sun Microsystems, Santa Clara, CA, USA, 2006, jmx-1 4-mrel3-spec.pdf. [Online]. Available: http://jcp.org/en/jsr/detail?id=160

[26] Service Oriented Infrastructure Reference Framework, DraftTechnical Standard, The Open Group, SOA Working Group,2008. [Online]. Available: https://www.opengroup.org/projects/soa-soi/uploads/40/19218/soi-V1-5-P1.pdf

[27] R. W. Doran, “Amdahl multiple-domain architecture,” Computer,vol. 21, pp. 20–28, 1988.

[28] M. Rosenblum, “The reincarnation of virtual machines,” Queue, vol. 2,no. 5, pp. 34–40, 2004.

[29] S. J. Vaughan-Nichols, “New approach to virtualization is a lightweight,”Computer, vol. 39, pp. 12–14, 2006.

[30] J. Kosinska, J. Kosinski, and K. Zielinski, “Virtual grid resource man-agement system with virtualization technology,” in KU KDM ’09: Pro-ceedings of the Second Conference of the High Performance Computers’Users, 2009.

[31] K. Balos, M. Jarzab, D. Wieczorek, and K. Zielinski, “Open interfacefor autonomic management of virtualized resources in complex systemsconstruction methodology,” ser. 5, vol. 24. Future Generation ComputerSystems, 2008, pp. 390–401.

[32] J. Kay and P. Lauder, “A fair share scheduler,” Commun. ACM, vol. 31,no. 1, pp. 44–55, 1988.

[33] H. J.L., D. Y., P. S., and T. D.M, Feedback Control of ComputingSystems. Wiley-IEEE Press, 2004.

[34] M. Jarzab and K. Zielinski, “Framework for consolidated workloadadaptive management,” in Software engineering in progress - II IFIPCentral and East European Conference on Software Engineering Tech-niques, ser. IFIP, vol. 3994. NAKOM, 2006, pp. 17–29.

[35] J. Adamczyk, R. Chojnacki, M. Jarzab, and K. Zielinski, “Rule enginebased lightweight framework for adaptive and autonomic computing,”in Computational Science ICCS 2008, ser. Lecture Notes in ComputerScience, vol. 5101. Springer Berlin / Heidelberg, 2008, pp. 355–364.

[36] SCA Service Component Architecture. Assembly Model Specification,version 1.00, OASIS, May 2007.

[37] “Apache Tuscany Home Page,” http://tuscany.apache.org/.[38] P. Herrero, J. L. Bosque, M. Salvadores, and M. S. Perez, “A rule

based resources management for collaborative grid environments,” Int.J. Internet Protoc. Technol., vol. 3, no. 1, pp. 35–45, 2008.

[39] R. Neisse, E. D. V. Pereira, L. Z. Granville, M. J. B. Almeida, andL. M. R. Tarouco, “An Hierarchical Policy-Based Architecture forIntegrated Management of Grids and Networks,” IEEE InternationalWorkshop on Policies for Distributed Systems and Networks, vol. 0,p. 103, 2004.

[40] X. Bai, J. Xie, B. Chen, and S. Xiao, “Dresr: Dynamic routing inenterprise service bus,” E-Business Engineering, IEEE InternationalConference on, vol. 0, pp. 528–531, 2007.

[41] I.-Y. Chen, G.-K. Ni, and C.-Y. Lin, “A runtime-adaptable service busdesign for telecom operations support systems,” IBM Syst. J., vol. 47,no. 3, pp. 445–456, 2008.

[42] “DiVA Home Page,” http://www.ict-diva.eu/, accessed on January 2010.[43] D. Nau, M. Ghallab, and P. Traverso, Automated Planning: Theory &

Practice. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc.,2004.

[44] “S-Cube, the Software Services and Systems Network Project HomePage,” http://www.s-cube-network.eu/, accessed on December 2009.

[45] “IT-SOA Project,” http://www.soa.edu.pl/.

15

AUTHORS

Krzysztof Zielinski is a full professorand head of the Institute of ComputerScience at AGH-UST. His interests focuson networking, mobile and wireless sys-tems, distributed computing, and service-oriented distributed systems engineering.He is an author of over 200 papers in thisfield.

He has been Project/Task Leader innumerous EU-funded projects, e.g.: PRO-

ACCESS, 6WINIT, Ambient Networks. He served as an expertwith the Ministry of Science and Education. Now he is leadingSOA oriented research performed by IT-SOA Consortium inPoland. In this area his research interests concern: AdaptiveSOA Solution Stack, Services Composition, Service DeliveryPlatforms and Methodology. His a member of IEEE, ACM andthe Polish Academy of Science, Computer Science Chapter.

Tomasz Szydło is a PhD candidate andresearch assistant at the Department ofComputer Science at AGH-UST. His in-terests focus on Service-Oriented Archi-tectures as well as mobile systems. Hehas participated in several EU researchprojects including CrossGrid and Ambi-ent Networks. Recently he is working onthe SOA project conducted by severaluniversities in Poland. His interest in this

project is concentrated on Adaptive ESB. He is an author often research papers.

He has cooperated with Machine Learning and InferenceLaboratory at George Masson University working on theconversion of rules into decision trees. He was also an intern atIBM Hursley, UK where he worked on integration of MQTTprotocol with Service Oriented Device Architectures. He isinvolved in the CISCO Regional Academy at AGH-UST asan instructor.

Robert Szymacha is a PhD candidateand research assistant at the Departmentof Computer Science at AGH-Universityof Science and Technology in Krakow,Poland. His interests focus on networking,distributed systems, context-aware sys-tems and SOA applications. He is anauthor of 9 papers in these areas.

He has been working in several largeprojects, like 6FP EU: Ambient Net-

works, SGI Project: Parallel Isosufraces Visualization andReconstruction, Sun Microsystems: Spontaneous Containersimplementation in Java Multitasking Virtual Machine. Cur-rently he works in the SOA research project performed bythe IT-SOA Consortium in Poland. He works on AdaptiveComponent Integration and QoS-aware services.

Jacek Kosinski is a PhD research assis-tant at the Department of Computer Sci-ence, AGH University of Science Tech-nology Krakow since 2000. His main in-terests focus on computer networks, oper-ating systems and virtualization. He is anauthor of several papers in these areas.He is a Cisco CCNP instructor. He hasparticipated in national and international

research projects, mainly EU-founded. Currently he works inSOA research project performed by IT-SOA Consortium inPoland and in a project releated with Polish national gridinitiative - PL-Grid. He works on usage of virtualizationtechniques in areas related with resources management.

Joanna Kosinska is a research assistantat the Department of Computer Science,AGH University of Science and Technol-ogy Krakow since 2001. Her main inter-ests focus on service oriented architectureand distributed environments based onJava. She has participated in several na-tional and international research projects,mainly EU-funded. Currently she worksin the SOA research project performed

by the IT-SOA Consortium in Poland. She works on usageof virtualization techniques in areas related with resourcesmanagement.

Marcin Jarzab received his MSc inComputer Science, at the University ofScience and Technology (AGH-UST) inKrakow, Poland, in 2002. He worked as asoftware consultant at Consol* Solutionsand Software in 2000-2002, participatingin many projects for Telco companies. Hewas an intern at Sun Labs in the latterhalf of 2003, investigating the applicationof the Multi-tasking Java Virtual Machine

to the J2EE environment. His research interests include thetuning and performance evaluation of distributed systems,design patterns, frameworks, and architectures of autonomiccomputing environments.