1

CASA – A Contract-based Adaptive Software Architecture Framework*

Arun Mukhija and Martin Glinz

Technical Report 2003

Institut für InformatikUniversity of Zurich

Winterthurerstrasse 190CH-8057, Zurich, Switzerland{mukhija | glinz}@ifi.unizh.ch

Abstract

Traditionally, applications are developed with an implicit reliance on the stability oftheir execution environment and available resources, while little or no support isprovided for the runtime adaptation of application behavior in case of any instabilityencountered. But such an approach proves futile for more dynamic environments,such as those encountered in self-organized mobile networks, wherein any form ofreliance on runtime computing environment of an application would be highlyoptimistic.

The Contract-based Adaptive Software Architecture (CASA) framework, described inthis paper, addresses the need to equip an application with the ability to dynamicallyadapt itself in response to changes in its execution environment. This implies that anapplication is able to best meet its functional and/or non-functional commitmentseven when its runtime computing environment changes. The framework builds on theidea of specifying resource requirements and adaptation behavior of applications inapplication contracts. The Contract Specification Language (CSL), developed as partof the framework to express application contracts and other informational entitiesrequired to support it, is also described in this paper.

1. Introduction

Software applications for dynamic distributed computing environments are faced withtwo challenges: limited resources and unreliable availability of resources. The formerchallenge is primarily due to the limited communication resources available whenusing wireless networks; moreover the ever-reducing size of mobile nodes restrictsthe amount of local resources that can be integrated into them. The latter challenge ofunreliable resource availability is due to uncertain variations in load and unanticipatedresource failures. It is especially profound in the case of self-organized mobilenetworks, popularly known as mobile ad-hoc networks, as these networks offer a veryflexible way of operation, wherein nodes are free to join or leave a network

* The work presented in this paper was supported (in part) by the National Competence Center inResearch on Mobile Information and Communication Systems (NCCR-MICS), a center supported bythe Swiss National Science Foundation under grant number 5005-67322.

2

community or travel within thenetwork, without any prior intimation. Such flexibility,obviously, comes at the cost of highly dynamic topology of the network and thusincreased undependability on the available resources. Moreover, applications do notknow in advance, with which, and with how many other applications they need tocontend with for the allocation of local as well as network resources, which furthercontributes to the unreliability of resources available to an application throughout itsexecution life.

Conventional approaches of software development do not account for the instabilityof resources: the applications are developed with, more or less, fixed resourcerequirements. Such an approach works reasonably well for computing environmentswhere dependability on the available resources is quite high. But for more dynamicenvironments, where fluctuations in resource availability are very frequent, thisapproach fails. Hard-coding some degree of adaptability into the applications is atedious and rather limited solution of the problem. Recent attempts to enhancemiddleware for providing adaptability services are also limited in scope and lackflexibility (see Section 2 on related work).

Developing applications for such dynamic environments requires a fundamental shiftin the approach towards development. Unlike the traditional approaches, the newapproach for software development should ideally make no prior assumptions aboutthe resources that will be available to an application, while at the same time theapplication should be prepared for all possible resource availability scenarios. This, ineffect, implies that applications should be made dynamically adaptable in response tochanges in their execution environment. This problem needs to be handled in twoparts. Firstly, an application should be able to detect changes in its runtime computingenvironment and the resources available to it. And secondly, the application should beable to adapt its behavior in response to such changes, so that it can continue tooperate in the new environment, probably at a different level of performance and/orfunctionality. That is, in case of a drop in the desired availability of a particular scarceresource, an application may need to switch to a reduced level of performance and/orchange its functionality, while the adaptation may require an increase in usage ofsome other resources. Later, whenever availability of the concerned resource isrestored, the application should be able to switch back to its previous state ofworking. This will ensure optimal performance of the application under all resourceavailability scenarios, as well as the efficient utilization of available resources.

Even with such an approach, it will sometimes be necessary to suspend an applicationin case of a significant drop in the availability of a critical resource. But in generalapplications will be able to carry on with their execution for a much wider range ofresource availability scenarios. Needless to say that such adaptive applications wouldoutlive those that have strict resource requirements and are not adaptable.

As an example, let two remote applications be collaborating for an emergencycoordination project that requires the monitoring application to send latest images ofmaps of an affected area to be analyzed and used by the back-end support application.Now, in case of a drop in bandwidth available on the path between two applications,the monitoring application will need to switch to another configuration that sendsmaps with reduced details or sends them less frequently; and accordingly the back-end application will need to switch to a configuration that is able to work with the

3

maps with reduced details or with stale maps. Or alternatively, the monitoringapplication may simply switch to a configuration that sends the data computed formthe maps, at the expense of more CPU cycles, instead of directly sending the maps.While the former is an example of reduced performance due to drop in availableresources, the latter is an example of increase in usage of another resource (CPU inthis case) without sacrificing the performance of the application as such.

The CASA (Contract-based Adaptive Software Architecture) framework, presented inthis paper, provides an integrated framework for the development of adaptiveapplications, while the CASA run-time system takes care to provide ‘resourceawareness’ and ‘dynamic adaptability’ to the applications in a transparent manner.Different application domains may have different service parameters of interest. Forexample, multimedia applications may be interested in service parameters such aslatency and jitter, while some other applications may be interested in serviceparameters at a higher level of abstraction such as timely response and dependability,and still others may be interested directly in resource requirements such as memoryspace and processor cycles. CASA provides an integrated approach to include all kindof service parameters across different application domains within the sameframework.

Applications residing on autonomous nodes of a self-organized mobile networknegotiate a service agreement with their peers. The agreed upon application-domain-specific service requirements of an application are mapped to the correspondingresource-level requirements. The underlying CASA run-time system strives to satisfyresource requirements of the application by proper resource allocation andmanagement techniques. In case of significant changes in the resource availability,due to load variations or resource failures, the components of the concernedapplication are dynamically reconfigured by the CASA run-time system to suit thechanged execution environment. Dynamic reconfiguration of components is carriedout in a seamless manner that is without taking down the system. The adaptationpolicy of an application is specified in the so-called application contract. Theapplication contract is expressed in the Contract Specification Language (CSL),developed as part of the CASA framework.

The approach offered by CASA is flexible, as the level of adaptability can be tailoredto the application’s requirements. The level of adaptability depends on the amount ofalternative configuration provided for an application. Moreover it is extensible, as thelevel of adaptability as well as the policies of adaptation can be extended anytime, byintegrating more alternative configurations and updating the application contractaccordingly, to make it more sensitive to environmental changes.

The rest of the paper is organized as follows. Section 2 gives an overview of therelated work. Section 3 describes the constituent entities of the CASA framework.Section 4 does the job of linking these entities together to explain the working ofCASA. Section 5 gives details of contract specification. Finally Section 6 concludesthe paper and indicates future direction of our work.

4

2. Related Work

QoS Control at Middleware / System Level

Real-Time CORBA [OMG02a], and its implementation in TAO [OSK+00, PSC03],provides a mechanism to respect relative priority of components for the purpose ofresource allocation, in an attempt to provide end-to-end predictability for the real-timefixed-priority CORBA applications. But its efforts are limited to fair distribution ofavailable resources depending on relative priorities of contenders, while it provides nomeans for an application to explicitly specify or negotiate its resource requirementswith the underlying system or to adapt its behavior in case its requirements can not bemet.

Work on Quality Objects (QuO) [ZBS97, LSZB98] extends CORBA to provide QoSfor CORBA object invocations. And AQuA [CRS+98], integrated with QuO, attemptsto provide dependability to applications. QuO offers a framework wherein at any timean application belongs to a certain QoS region – each region representing a possiblestate of QoS – and appropriate methods are called in case of transitions between QoSregions. Although it mentions a broad range of application-specific QoS parameters, itdoes not offer an integrated framework for handling all QoS parameters of interest, ina unified way. Moreover it requires several system condition objects to monitorindividual application-specific system conditions, such objects may prove to be costlyin a resource constrained self-organized mobile network environment.

The approach advocated by the 2KQ system [NWX00] talks about functionaladaptation in response to QoS changes, and it shares the same goals as our CASAframework. However, it provides a centralized control over adaptation policies for thecomplete distributed system, whereas in CASA the applications at every discrete nodecan individually adapt, as per their own adaptation policies. Since self-organizedmobile networks consist of autonomous nodes that form ad-hoc networks,independence in deciding an application’s own adaptation policies is significant.

Reflective Middleware [CEM01, CMZE01] presents a flexible approach wherein anapplication is able to modify middleware behavior at run time depending on thecurrent context. But the adaptation here is limited to modifying behavioral policy ofmiddleware, and it does not involve adaptation of application itself.

Odyssey architecture [Nob00, NSN+97] provides a framework for type-specificadaptation of data being communicated between remote applications, in response toexecution environment changes. However the adaptation is restricted to adapting dataformat being communicated, and not the functionality or other performancecharacteristics of the application.

Reconfigurable Context Sensitive Middleware (RCSM) [YK01] presents asoftware-hardware hybrid approach that enables invocation of methods when theircorresponding context conditions are satisfied. Such an approach enablescontext-sensitive computing and information exchange without direct userinvolvement, but it does not take the changing context into account.

5

Work on Adaptive Resource Allocation (ARA) [RSYJ97], (along with its interrelatedwork on the Real-time Adaptive Resource Management system (RT-ARM)[HJH+97]), presents another middleware based approach that strives to satisfy QoSrequirements of an application and mentions application adaptation in response tochanges in external environment. However, it does not provide any means for run-time service negotiations among applications.

Some other approaches restricted to provide efficient resource managementtechniques, in order to satisfy QoS requirements, include the Globus Architecture forReservation and Allocation (GARA) [FRS00] and the Darwin project [CFK+98].

Dynamic Reconfiguration

[AWPV01, AWVN01] presents a mechanism to extend CORBA to enable runtimereconfiguration of objects to support evolution of applications with high availabilityrequirements. Similar approaches have also been proposed by [BISZ98] and [RI99].Such techniques can be suitably modified for the self-organized mobile networkenvironment and can provide a basis for the dynamic component replacement part ofour architecture.

Resource Control

There have been several techniques proposed for the run time monitoring and controlof applications to ensure that applications do not access more resources than they areentitled to. For example, the technique proposed in Software-Based Fault Isolation[WLAG93] is based on object code modifications to control memory access behaviorof applications. While it does not take into account the temporal behavior ofapplications. Similarly [GWTB96] proposes a mechanism to impose restricted accessto resources by intercepting application's interaction with the underlying system anddeciding whether or not to permit this interaction. And [DFWB97] advocates for aninterpreter based access control for the resources. But such techniques impose a highperformance cost on the system, as they need to intercept every call made by theapplication. Moreover all the above approaches have been developed keeping in mindthe security concerns caused by malicious or untrusted applications, and thus theseapproaches do not impose any quantitative restrictions on resources, such as CPU,that do not require explicit application request. More recently, User-LevelSandboxing [CIK02] has attempted to extend such mechanisms to impose quantitativerestrictions on resources such as CPU and network usage in addition to the memory.However it does not provide a means for the application to state its resourcerequirements, rather the system is responsible to provide a fair sharing of resourcesamong applications. Such techniques can nevertheless be extended and refined for ourpurpose to provide realistic restrictions on the resource consumption by applications.

Specification Language

There has been a significant amount of work done on specification of componentcontracts. Such as the Interface Definition Language (IDL) for CORBA [OMG02b]

6

enables specification of interface to the methods implemented by a component. TheDesign by Contract approach, originated by [Mey92], stresses on the need to specifypre and post conditions as well as invariants maintained for each method. Thisapproach is used in the Eiffel language and is extended for Java language by the toolslike iContract [Kra98] and jContractor [KHB99]. [OHR00] proposes a framework topresent metadata about a software component for the software engineering tasks suchas analysis and testing, but it is confined to specifying functional specifications of acomponent only. The QoS Modeling Language (QML) [FK98] is used to capture QoSproperties to be provided by a component, at the design stage. [Hus00] stresses on theneed to formally specify components, and advocates the use of Object ConstraintLanguage (OCL) [OMG01], a part of UML, for this purpose. But QML and OCL areessentially the modeling languages and their use as machine processable specificationlanguages is very restricted.

All the above specification techniques basically assist in the task of composing anapplication from components, wherein the information about component interface andbehavior would suffice. In fact, the term ‘contract’ has so far been envisioned assomething that exists between components and that facilitates composition of aquality application. While for our purpose we need an application level contract todescribe the appropriate component configuration of the application corresponding toeach possible resource availability scenario. Such information would facilitate thesmooth running of the application, even in a varying execution environment. None ofthe above specification techniques address this issue.

Advances in eXtensible Markup Language (XML) [WWWC00, BDD+01] make it apromising technique to express data in a structured and platform independent format.In particular with its associated hierarchical tree structure, XML can expresssemantically richer data in a simple and extensible manner. Due to its abovecharacteristics, we have used XML as the syntactic envelope for our ContractSpecification Language (CSL).

3. CASA (Contract-based Adaptive Software Architecture)Framework

The overall framework of CASA is as illustrated in Figure 1. Adaptive applicationsreside on distributed autonomous nodes that form ad-hoc networks. At run-time, whenthe peer applications decide to interact, they negotiate a service agreement amongstthem. The underlying CASA run-time system utilizes proper resource allocation andmanagement techniques in order to satisfy service commitments of individualapplications. In case of unanticipated changes in resources availability or due tovoluntary changes in applications requirements, the CASA run-time system carriesout dynamic reconfiguration of application components, according to the adaptationpolicy specified in the application contracts.

The details of each of the constituent entities of the CASA framework are describedin the following sub-sections. (We use the term “entity” to refer to components ofCASA framework, in order to avoid confusion with the term “component” used forapplication components).

7

Figure 1: CASA Framework

3.1. Applications

The internal structure of an application is as shown in Figure 2. CASA supportscomponent-oriented development of applications. To support adaptation, alternativecomponent configurations of an application need to be provided by the applicationdeveloper, such that each one is best suited for particular resource conditions.Providing such alternative configurations for an application forms the backbone ofour adaptive software architecture. A component configuration here implies the set ofcomponents constituting the application. Alternative component configurations maydiffer in just a few of their constituent components, while many other componentsremaining same across the configurations. The differing components in alternativeconfigurations will most likely belong to the same type, although it may not always bethe case. Belonging to the same type implies that components conform to the samefunctional interface, but differ in their implementations – that is, in their resourcerequirements and probably functional and/or performance characteristics – thusmaking them mutually replaceable as far as their external interface is concerned.Many of the constituent components of an application may be standard componentsand be reused in integration of various diverse applications in the same or otherdomains. Thus the effort spent in developing different implementations of the samecomponent, each suited for a different execution environment, will be compensatedby the amount of reuse of the component.

As shown in the internal structure of an application in Figure 2, there is an activecomponent configuration while there may be several passive componentconfigurations. As is evident from their names, the active configuration is the one that

8

is currently being executed, while passive configurations are the ones that are not partof the current execution. This is just a logical representation, as in practice themajority of the components will be same across active and passive configurations; soit will be only a few components that will be passive, and not a completeconfiguration. The other two significant constituents of an application, namely theapplication contract and the service negotiator are described in the following sub-sections.

Figure 2: Internal Structure of Application

3.1.1. The Application Contract

The application contract of an application is divided into so-called operating zones(the format of the application contract is described in Section 4). The operating zonesof an application contract are distinguished by the service level provided and/orexpected by the application in a given zone. Switching between the operating zones ofan application contract implies significant differences in the level of service providedand/or expected by the corresponding application. Each zone, in turn, contains a listof valid alternative component configurations for that zone, and their correspondingresource requirements1. As described in Section 4, component configurations arespecified by the list of names of their constituent components. Alternative componentconfigurations within a zone offer and expect, more or less, the same level of service(as they belong to the same operating zone) but differ in their resource requirements.Due to the above restriction, there might be just one configuration in a given zone. Incase there is more than one configuration, the first configuration listed in a zone istreated as the most preferred configuration for that zone, while others are substitutessubject to resource availability conditions. Application contracts are expressed in theContract Specification Language (CSL).

1 The resource requirements corresponding to a component configuration can be computed by various analyticaland experimental techniques available for this purpose.

9

In contrast to the application contract, the component-level contracts help theapplication developer in composing alternative component configurations of anapplication, and in generating the application contract. The component-level contractsspecify the functionality offered by a component implementation as well as its non-functional performance characteristics. In addition, they contain information such asdependencies of components on some other components, pre and post conditions ofmethods etc. This information enables application developers in composing the rightmix of component configurations of an application. The component-level contractsare static and used off-line, whereas the application contract contains adaptationinformation that is used by the CASA run-time system to carry out dynamicadaptation. There has been a significant amount of work done in industry andacademia on developing such component-level contracts (as discussed in the relatedwork Section), and any of the techniques can be used for this purpose.

3.1.2. The Service Negotiator (SN)

Each application contains a Service Negotiator (SN) component that is responsible fornegotiating the service level (also referred to as quality of service or QoS in theliterature) to be offered to and/or expected from its peer applications, on behalf of itshost application2. A self-organized mobile network is essentially a peer-to-peernetwork, wherein the applications offer services to other peer applications and at thesame time use services provided by the other applications, and thus they do not playstrict roles of clients or servers. The SNs of the peer applications use a service-agreement protocol to arrive at a mutually acceptable service agreement.

A mapping module within the SN maps the service parameters that it has negotiatedwith its peers to the appropriate service zone. The mapping rules have to be suppliedby the application developer, although for the standard components used, there maybe automated tools to generate customized mapping rules for applications. Theselected operating zone, obviously, corresponds to the component configurations thatare able to satisfy the service commitments of the application.

3.2. The Contract-based Adaptation System (CAS)

The Contract-based Adaptation System (CAS), which is part of the CASA run-timesystem, is a standard application-independent entity that is responsible for carryingout dynamic adaptation on behalf of its associated application. The CAS submitsresource requests of its associated application – as specified in the applicationcontract corresponding to the selected operating zone – to the underlying ContractEnforcement System (CES). In case there is a mismatch between resources requestedby an application and those that can be made available to it, the CAS carries outdynamic adaptation of the application by replacing the current componentconfiguration with the one that has resource requirements compatible with theavailable resources.

2 For applications that do not require a service negotiation phase and whose contracts comprise of singleoperating zones, the SN may be omitted.

10

While carrying out dynamic adaptation, the CAS takes into account the need for statetransfer between components of the same type. Moreover the adaptation is carried outwithout taking down the system and the integrity of existing transactions ismaintained.

3.3. The Contract Enforcement System (CES)

The Contract Enforcement System (CES) is also a part of the CASA run-time systembut, unlike the CAS, the CES is a central entity responsible for satisfying resourcerequirements of all applications running on its host node. The CES is updated aboutthe current resource status by the Resource Manager (RM), and is responsible formaking resource allocation decisions in order to satisfy resource requirements ofrequesting applications. In making resource allocation decisions, the CES needs totake into account the relative priorities of the various requesting applications,particularly when there are not enough resources to satisfy the requirements of all theapplications. For local resources, resource allocation is straightforward, but fordistributed resources, the CES needs to work in coordination with the CESs of otherparticipating nodes along the application execution path, using a resource-coordination protocol.

In case - initially or at anytime during the execution life of an application - there is amismatch between resources requested by the CAS and those that can be allocated toit, the CES triggers the CAS about the resource requirement-availability mismatch,also specifying the values of resources that can be allocated to it. The mismatch mayoccur because of scarcity or abundance of resources. Resources might become scarcedue to increased load (increase in demand for the limited resources by contendingapplications) or resource failures (some resources becoming unavailable), with theresult that the currently available resources are not sufficient enough to meet thedemands of all requesting applications. Resources might become abundant because ofreduced load (some applications releasing their resources) or restoration of someresources that failed earlier, with the result that more resources can be allocated to anapplication than specified in the resource request. A resource request submitted by theCAS specifies the range of desired values for each resource, as well as options totrigger the CAS about any possible degradation below the desired value and/orimprovement above the desired value for each resource (format discussed in Section4). The ranges of acceptable values for the individual resources, specified in theresource request, impart the CES flexibility to operate within the given ranges. TheCES dynamically adjusts resource allocations within specified resource ranges, basedon the current actual resource usage patterns of applications. In effect, the CESprovides a first level of absorption mechanism in the event of degradation in theresource availability, by reallocating existing resources among applications so thathigh priority applications can carry on with their execution without much interruption,and only the low priority applications need to be adapted.

3.4. The Resource Manager (RM)

The Resource Manager (RM) monitors the value and availability of resources andkeeps the CES updated about the current resource status, and the actual resource

11

usage of applications. Monitoring the changes directly at the resource level shortensthe turnaround time from the change in resource conditions to adapting theapplication, as compared to when measuring the actual level of service beingavailable at the receiver end, before taking an adaptation decision. However, to avoida pre-mature reaction to temporary fluctuations in the availability of a resource, theRM may suitably delay updating the CES. Resources include memory, processoroccupancy, communication budget etc. The RM carries out reservation of resources asgoverned by the resource allocation decisions of the CES. It further ensures thatapplications operate within their allocated resource limits, so that resources allocatedto an application are protected.

4. Working of CASA

The Service Negotiators (SNs) of peer applications negotiate a service agreementusing a service-agreement protocol (see Figure 3a). The mapping modules, present ineach of the SNs, then map the agreed upon service parameters to the appropriateoperating zones for each application.

Figure 3a: Service Negotiators of peer applications arrive at a service agreementusing a service-agreement protocol

The SN of each participating application then sends the information about thenegotiated operating zone to the Contract-based Adaptation System (CAS) associatedwith the application (see Figure 3b).

Figure 3b: Service Negotiator informs CAS about the valid zone number

12

Based on the given operating zone, the CAS looks up the first componentconfiguration specified in the application contract under that zone, and forwards theresource requirements corresponding to this configuration as a resource request to theContract Enforcement System (CES) (see Figure 3c).

Figure 3c: CAS submits resource request to CES

Based on the resource request submitted by the CAS and the resource status updatedby the RM, the CES makes resource allocation decisions (see Figure 3d). For thedistributed resources, the CES coordinates with the CESs of other participating nodesusing a resource-coordination protocol. In case the resource request can be satisfiedthe CES notifies the resource approval to the CAS and instructs the RM to reserve therequired resources. But in case (initially or at anytime during the execution life of anapplication) there is a mismatch between the resource request and resourceavailability, CES triggers CAS about the resource requirement-availability mismatch(see Figure 3e).

Figure 3d: CES allocates resources

Figure 3e: CES notifies resource response to CAS

13

If the resources requested by the CAS are allocated (indicated by resource approval),it activates the corresponding component configuration. Else if the CAS is triggeredby the CES about a resource requirement-availability mismatch, CAS looks for analternative configuration that has resource requirements compatible with the availableresources, within the current zone in the application contract. If the CAS finds one, itsimply activates the new configuration while passivating the old one, and renews itsresource request to the CES. In case the CAS cannot find an alternative configurationwithin the current zone, it searches for one in other zones. If the CAS finds a suitableconfiguration in another zone that has resource requirements matching the resourceavailability, it sends information to the SN about the zone number of the newconfiguration, to which it intends to switch (see Figure 3f).

Figure 3f: CAS informs Service Negotiator about the intended zone number

The SN, in turn, sends information to its peer applications about the new level ofservice that it can offer (obviously, the mapping module first reverse maps theoperating zone to service parameters). Once the new service level is approved, SNgives the signal to the CAS to go ahead with switching to the new configuration3.Since the new configuration may differ from the old one in just a few components(maybe just one component), the CAS activates only those components that are newand passivates the components that are not required in the new configuration, andrenews its resource request to the CES. In case the new component being activated isof the same type as the old one being passivated (which will be the case many times),a state transfer from the old component to the new one might be required. The CASArun-time system takes care of it. Since components of the same type conform to thesame interface, and we envision that adaptation shall mostly involve replacingcomponents of the same type, the remote application code utilizing services of oldcomponents will not be affected by the adaptation. Although, the peer applicationsmay need to adapt based on the changes in service level being offered, this scenario isdiscussed later in this Section. Note that while switching between configurationswithin the same zone, there is no need to inform the SN or the peer applications. Thisis because alternative configurations within the same zone offer almost the same levelof service.

If the peer applications do not approve the new service level being offered, theapplication will need to be suspended or may be terminated. In such a case, the SN

3 For certain applications, it may not be required to inform peer applications explicitly about achange in the service level being offered. Particularly when the change in service level is self-explanatory and the peer applications are not expected to object to such a change, for example a changein the data format that can be readily identified and handled by the receiver application. For suchapplications, SN can simply confirm the CAS to go ahead with the change, without initiating theprocess of informing peer applications and seeking their approval.

14

instantiates any finalizing work that needs to be carried out before suspension ortermination (as the case may be), and then signal the CAS in that respect to free upresources. Similarly, if the CAS is unable to find any appropriate componentconfiguration in response to the mismatch trigger, which means none of theconfigurations specified in the application contract matches the existing resourceconditions, it informs so to the SN. In such a case, the application will also need to besuspended or terminated, and SN will inform its peer applications accordingly,instantiate finalizing work and signal the CAS to passivate current configuration andfree up resources. In case the application is suspended (and not terminated), the CASmay try to revive it in frequent intervals, by submitting resource requests to the CESwith the same values as were used during the last successful execution of theapplication. In case the requested resources get available, another round of informingthe SN and peer applications will take place before the application is revived.

An executing application may also need to change its operating zone voluntarily, forexample due to a change in user’s preference or due to some performanceconsiderations etc. In this case, SN first informs its peer applications about itsintended change to the new service level; and on approval, informs the CAS about thenew zone number to switch to. The rest of the cycle proceeds similar to the one whenan initial request is made. Similarly when an application is informed by its peerapplication about a change in the service level provided by the latter to the former, theformer may need to change its operating zone as well, to match the new serviceconditions4. This case emphasizes that ope rating zones are categorized not just bythe difference in service level provided by an application, but also by the difference inservice level that the application expects from its peers. Another factor to decidegranularity of operating zones is that how much difference in service level isconsidered minor and acceptable (grouped under same zone) beyond which the peerapplications need to be informed (grouped in different zones).

5. Contract Specification

Application contracts and other informational entities required to support the CASAframework are specified in the Contract Specification language (CSL). CSL is anXML-based specification language developed as part of the CASA framework. Thereason to use CSL is to specify application contracts and other informational entitiesin a standard and uniform manner that is independent of the applicationimplementation language or platform. This uniformity helps to achieve transparencyin dynamic adaptability of applications5.

4 Each application may also have a service monitor component to monitor actual level ofservice being delivered to it, and may need to change its operating zone or re-negotiate service level incase the observed level of service is different from the agreed one. Although, in general, suchmonitoring would not be required as the service provider application would inform if it changes theservice level delivered at its end, and the run-time CASA system would detect and inform any changein the resource conditions as well, that may result in a change in the service level.

5 The descriptions here list only the minimum attributes required for each informational entity.There will be more attributes (such as request_ID and application_ID etc.) in the actualimplementation.

15

First, we have to define ranges for all managed resources.

Resource Range Table: Below, we give an example for the format of resource rangetable.

<resource_range> <resource name=R1 unit=M1> <value from=V1 to=V2 range=1/> <value from=V2+1 to=V3 range=2/> . . </resource> <resource name=R2 unit=M2> . . </resource> . .</resource_range>

In the above example, R1 and R2 are resources with their units of measurement as M1and M2 respectively. The purpose of the resource range table is to appropriatelydistribute possible values of each resource into ranges and allocate range number foreach such range. The resource range table is needed for calculating Resource Tuples(see below).

Resource Tuple: The resource requirements of each component configuration arespecified in terms of a resource tuple. A resource tuple is a sequential representationof desired values of resources, where the desired values are expressed in terms ofrange numbers from the resource range table. The sequence of resources in theresource tuple is same as the sequence of listing of resources in the resource rangetable.

That means that for the sequence of resources R1, R2, R3,…,Rn specified in theresource range table, the tuple (N1)(N2)(N3)…(Nn) represents the resource tuple for acomponent configuration. Each (Ni) represents the desired value for the correspondingresource Ri. Each (Ni) might be specified in terms of a single range number (ni) or arange of such numbers (ni-nj), where ni and nj are range numbers from the resourcerange table. An empty parenthesis () in the tuple indicates that the correspondingresource is not required for the concerned component configuration. In addition,specifying an x just before the closing parenthesis, e.g. (nix), indicates that the CAS isnot interested to be triggered about any possible increase in the availability of theconcerned resource. Similarly an x just after the opening parenthesis, e.g. (xni),indicates that the CAS is not interested in any possible degradation in the availabilityof the concerned resource (although this option will be seldom used).

16

Application Contract: Below, we give an example for the format of the applicationcontract.

<app_contract app_name=A’> <zone number=1> <alt resource_tuple=(N1)(N2)…(Nn) comp_config=C1,C2,…,Ck/> . . </zone> <zone number=2> . . </zone> . .</app_contract>

As is clear from the format, an application contract is divided into zones, identified bytheir unique numbers. Each zone in turn consists of a list of alternative componentconfigurations and their corresponding resource requirements, specified in terms ofresource tuples. The first configuration in the list is the most preferred one for thatzone. Each component configuration (comp_config) is specified as a list of itsconstituents components separated by commas, for example,comp_config=C1,C2,C3,C4 where C1, C2, C3 and C4 are component names. For thecomponents that need state transfer when replacing a component of the same type, thetype of the component is specified in parenthesis after its name, for example,comp_config=C1,C2(x),C3(y),C4 where x and y are component types.

Resource Request: An example of format of Resource Request, as submitted by theCAS to the CES is as under -

<resource_request app_name=A’ resource_tuple=(N1)(N2)..(Nn)/>

As seen from above, CAS simply forwards the resource tuple corresponding tocurrently valid component configuration to CES as the resource request.

Resource Response: An example of format of Resource Response by the CES to theCAS of the concerned application is as under -

<resource_response app_name=A’ resource_tuple=(N1’)(N2’)..(Nn’)/>

As seen from above, format of resource response is similar to that of resource request,except that this time CES informs CAS of the resource tuple that can be madeavailable to it. If the resource tuple in resource response is same as (or is a sub-tupleof) requested resource tuple, it acts as a resource approval notification. Else, it acts asa resource requirement-availability mismatch trigger, with the resource tupleindicating new resource values that can be allocated to the concerned application.

17

Intended Zone: An example of format of Intended Zone, as informed by the CAS tothe SN is as under -

<intended_zone zone_number=n’/>

Zone number specifies the operating zone (n’ in the above example) that the CASintends to switch to.

Valid Zone: An example of format of Valid Zone, as informed by the SN to CAS isas under -

<valid_zone zone_number=n/>

Zone number specifies the operating zone (n in the above example) that the CAS isdirected by the SN to switch to. If the valid zone is in response to the intended zone,and the zone number in valid zone is same as that in the intended zone, it acts as agreen signal for CAS to go ahead with switching to its intended componentconfiguration. Zone number equal to 0 implies suspension and zone number equal to–1 implies termination of application.

6. Concluding Discussion and Future Work

The CASA framework enables dynamic adaptation of applications in response tochanges in their execution environment. Dynamic adaptation is achieved throughruntime reconfiguration of components of an application, according to the adaptationpolicy specified in the application contract. Adaptive applications are able to bestmeet their functional and/or performance commitments even in dynamically changingenvironments, and thus have a longer execution life than their non-adaptablecounterparts.

A limitation of our approach is that it places a lot of responsibility on the applicationdeveloper in developing alternative component configurations for the application tosuit different resource conditions that can arise during the execution life of theapplication, and in generating the application contract accordingly. In doing so, anapplication developer may have to take difficult trade-off decisions in decidingbetween various alternatives. But it also provides enough flexibility to the applicationdeveloper to tailor the adaptation policy of an application specific to its needs.Moreover with standard COTS components widely used for realizing applications,automated tools to analyze alternative component configurations and to generateapplication contracts are envisioned, to make the application developer's job easier.Of-course, the actual effort spent on making an application adaptive, and the resultingamount of adaptation, would depend upon factors such as criticality and re-usabilityof the application.

The framework provides extensibility to extend the adaptation structure later bywidening the scope of reconfiguration, as the need arises. And it offers an integratedsupport to handle a wide range of service parameters across different applicationdomains. Moreover the application independent characteristic of the CASA run-time

18

system helps to achieve dynamic adaptability in a transparent manner. Thus itexpands the applicability of the framework to all kinds of applications that are facedwith the challenge of unreliable resource availability, and have alternative componentconfigurations to offer in the face of it.

CASA is still in its evolutionary phase. We are currently developing the details of thedistributed service-agreement protocol and the resource-coordination protocol. We arealso developing a priority model for various contending applications to help CESmake justified resource allocation decisions. The priority model will also includesome kind of charging mechanism whereby applications may be charged for reservingthe resources. In addition, we are working on the implementation of a prototype tostudy feasibility and performance issues related to the CASA framework.

References

[AWPV01] Almeida J.P.A., Wegdam M., Pires L.F. and Van Sinderen M. Anapproach to dynamic reconfiguration of distributed systems based on object-middleware. Proceedings of 19th Brazilian Symposium on Computer Networks (SBRC2001), May 2001.

[AWVN01] Almeida J.P.A., Wegdam M., Van Sinderen and Nieuwenhuis L.Transparent Dynamic Reconfiguration for CORBA. Proceedings of 3rd InternationalSymposium on Distributed Objects & Applications (DOA 2001), September 2001.

[BDD+01] Birbeck M., Diamond J., Duckett J., Gudmundsson O.G., Kobak P., LenzE., Livingstone S., Marcus D., Mohr S., Ozu N., Pinnock J., Visco K., Watt A.,Williams K. and Zaev Z. Professional XML 2nd Edition. Wrox Press Limited, 2001.

[BISZ98] Bidan C., Issarny V., Saridakis T. and Zarras A. A DynamicReconfiguration Service for CORBA. Proceedings of IEEE International Conferenceon Configurable Distributed Systems, May 1998.

[CEM01] Capra L., Emmerich W. and Mascolo C. Reflective Middleware Solutionsfor Context-Aware Applications. Proceedings of 3rd International Conference onMetalevel Architectures and Separation of Crosscutting Concerns (Reflection'01),September 2001.

[CFK+98] Chandra P., Fischer A., Kosak C., Eugene Ng T.S., Steenkiste P.,Takahashi E. and Zhang H.: Darwin: Customizable Resource Management for Value-Added Network Services. Proceedings of 6th International Conference on NetworkProtocols (ICNP’98), October 1998.

[CIK02] Chang F., Itzkovitz A. and Karamcheti V. User-level Resource-constrainedSandboxing. Proceedings of 4th USENIX Windows Systems Symposium, August 2002.

[CMZE01] Capra L., Mascolo C., Zachariadis S. and Emmerich W.: Towards aMobile Computing Middleware: a Synergy of Reflection and Mobile CodeTechniques. Proceedings of 8th IEEE Workshop on Future Trends of DistributedComputing Systems (FTDCS'01), October 2001.

19

[CRS+98] Cukier M., Ren J., Sabnis C., Henke D., Pistole J., Sanders W.H., BakkenD.E., Berman M.E., Karr D.A. and Schantz R.E.: AQuA: An Adaptive Architecturethat Provides Dependable Distributed Objects. Proceedings of 17th IEEE Symposiumon Reliable Distributed Systems (SRDS’98), October 1998.

[DFWB97] Dean D., Felten E.W., Wallach D.S. and Balfanz D. Java Security: WebBrowsers and Beyond. D. E. Denning and P. J. Denning (editors), Internet Beseiged:Countering Cyberspace Scofflaws, ACM Press, pages 241-269, October 1997.

[FK98] Frolund S. and Koistinen J. Quality of Service Specification in DistributedObject Systems Design. Proceedings of 4th USENIX Conference on Object-OrientedTechnologies and Systems (COOTS'98), April 1998.

[FRS00] Foster I., Roy A. and Sander V.: A Quality of Service Architecture thatCombines Resource Reservation and Application Adaptation. Proceedings of 8th

International Workshop on Quality of Service (IWQoS’2000), June 2000.

[GWTB96] Goldberg I., Wagner D., Thomas R. and Brewer E.A. A SecureEnvironment for Untrusted Helper Applications. Proceedings of 6th USENIX SecuritySymposium, July 1996.

[HJH+97] Huang J., Jha R., Heimerdinger W., Muhammad M., Lauzac S.Kannikeswaran B., Schwan K., Zhao W. and Bettati R. RT-ARM: A Real-TimeAdaptive Resource Management System for Distributed Mission-CriticalApplications. Proceedings of IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, December 1997.

[Hus00] Hussmann H. Towards Practical Support for Component-Based SoftwareDevelopment Using Formal Specification. Proceedings of Workshop on ModellingSoftware System Structures in a Fastly Moving Scenario, June 2000.

[KHB99] Karaorman M., Hölzle U. and Bruno J. jContractor: A Reflective JavaLibrary to Support Design by Contract. Proceedings of Meta-Level Architectures andReflection (Reflection'99), July 1999.

[Kra98] Kramer R. iContract – The Java Design by Contract Tool. Proceedings ofTechnology of Object-Oriented Languages and Systems (TOOLS'98), 1998.

[LSZB98] Loyall J.P., Schantz R.E., Zinky J.A. and Bakken D.E. Specifying andMeasuring Quality of Service in Distributed Object Systems. Proceedings of 1st

International Symposium on Object-Oriented Real-Time Distributed Computing(ISORC'98), April 1998.

[Mey92] Meyer B. Applying Design by Contract. IEEE Computer, Vol. 25, No. 10,pages 40-51, October 1992.

[Nob00] Noble B. System Support for Mobile, Adaptive Applications. IEEE PersonalCommunications, Vol. 7, No. 1, February 2000.

20

[NSN+97] Noble B.D., Satyanarayanan M., Narayanan D., Tilton J.E., Flinn J. andWalker K.R. Agile Application-Aware Adaptation for Mobility. Proceedings of 16th

ACM Symposium on Operating System Principles, October 1997.

[NWX00] Nahrstedt K., Wichadakul D. and Xu D.: Distributed QoS Compilation andRuntime Instantiation. Proceedings of IEEE/IFIP International Workshop on Qualityof Service (IWQoS’2000), June 2000.

[OHR00] Orso A., Harrold M.J. and Rosenblum D. Component Metadata forSoftware Engineering Tasks. Proceedings of 2nd International Workshop onEngineering Distributed Objects (EDO'2000), November 2000.

[OMG01] Object Management Group. Object Constraint Language Specification.Chapter 6, UML Specification, Version 1.4, September 2001.

[OMG02a] Object Management Group. Real-Time CORBA Specification, Version1.1, August 2002.

[OMG02b] Object Management Group. The Common Object request Broker:Architecture and Specification, Version 3.0, July 2002.

[OSK+00] O’Ryan C., Schmidt D.C., Kuhns F., Spivak M., Parsons J., Pyarali I. andLevine D.L. Evaluating Policies and Mechanisms for Supporting Embedded, Real-Time Applications with CORBA3.0. Proceedings of 6th IEEE Real-Time Technologyand Applications Symposium (RTAS'00), June 2000.

[PSC03] Pyarali I., Schmidt D.C. and Cytron R.K. Techniques for Enhancing Real-time CORBA Quality of Service. IEEE Proceedings Special Issue on Real TimeSystems, 2003.

[RI99] Rodriguez N. and Ierusalimschy R. Dynamic Reconfiguration of CORBA-based Applications. Proceedings of SOFSEM'99: 26th Conference on Current Trendsin Theory and Practices of Informatics, 1999.

[RSYJ97] Rosu D.I., Schwan K., Yalamanchili S. and Jha R. On Adaptive ResourceAllocation for Complex Real-Time Applications. Proceedings of IEEE Real-TimeSystems Symposium, December 1997.

[WLAG93] Wahbe R., Lucco S., Anderson T.E. and Graham S.L. Efficient Software-Based Fault Isolation. Proceedings of 14th ACM Symposium on Operating SystemsPrinciples, pages 203-216, December 1993.

[WWWC00] World Wide Web Consortium. Extensible Markup Language (XML) 1.0(Second Edition). W3C Recommendation, October 2000.

[YK01] Yau S.S. and Karim F. Reconfigurable Context-Sensitive Middleware forADS Applications in Mobile Ad Hoc Network Environments. Proceedings of 5th

IEEE International Symposium on Autonomous Decentralized Systems (ISADS'01),March 2001.

21

[ZBS97] Zinky J.A., Bakken D.E. and Schantz R.E. Architectural Support for Qualityof Service for CORBA Objects. Theory and Practice of Object Systems, Vol. 3, No. 1,April 1997.