Describing and Deploying Self-Adaptive Applications - CiteSeerX

Anais do XXVI Congresso da SBC LAACS 2006 l 1st Latin American Autonomic Computing Symposium

14 a 20 de julho de 2006 Campo Grande, MS

Describing and Deploying Self-Adaptive Applications Alexandre Sztajnberg2, Orlando Loques1 1

2

Instituto de Computação, Universidade Federal Fluminense (UFF), DICC/IME/UERJ e PEL/FEN/, Universidade do Estado do Rio de Janeiro (UERJ), [email protected], [email protected]

Abstract. This paper discusses the use of architectural contracts to specify the execution context and resource requirements for applications running on enviroments which have constantly changing resources. These contracts also guide configuration adaptations on the application’s architecture, which are supported by a middleware infrastructure. The overall approach, called CRRIO, is used to present the design of a videoconference application, with focus on diverse dynamic activities regarding the Terminal-Reflector interaction, and how the use of contracts can facilitate deploying them. An ongoing work on formal verification of the contracts is also presented.

1. Introduction The operation of many autonomic or ubiquitous applications depend on context-aware non-functional requirements, which have to be enforced in addition to their basic functional requirements. In our terms, context-aware requirements express concerns related to resources (e.g., processing, memory and communication), features (e.g., fault tolerance and security) or other services (e.g., location services, game providers, streamers, codecs) that complement the support infrastructure for a given application. Considering that the same basic application architecture can run in dynamic contexts, and that the non-functional requirements have some degree of flexibility, it is interesting to continuously adapt the architecture for each particular context. In order to support such adaptive procedures, it is worth to define a set of configuration options, one of which can be initially deployed, and others which can be deployed in different contextual situations that may happen during the application lifetime. As a further feature, it should be provided an abstraction that allows describing a set of different configuration options, which satisfy the requirements of the application, with different degrees of quality. Once a configuration is selected, it can be used to guide adaptations in the supporting infrastructure to guarantee the required non-functional properties. We center our investigation on the CR-RIO framework [Loques 2004] that includes concepts and mechanisms that facilitate the specification, deployment and management of self-adaptive context-aware applications. CR-RIO includes an ADL (architecture description language), called Cbabel, with features to describe contracts that are used to describe application architectures and configuration options, which can be deployed when changes occur in the supporting environment. Contract descriptions are mapped to a middleware infrastructure that monitors the environment and effectively performs reconfigurations. Based on this approach we developed a series of experiments, with a self-adaptive version of a videoconference application, focusing on how the CR-RIO framework can facilitate the design and deployment of applications running on constantly changing environmments.

24

The rest of the paper has the following structure. Section 2 presents the basic elements of the framework that supports our approach, and in Section 3 we discuss some related work. Section 4 is dedicated to the presentation of the videoconference example, which provides a basis for discussing the self-adaptive aspects of our work. We also present the ongoing work on formal aspects of our approach in Section 5. Section 6 contains some concluding remarks.

2. CR-RIO The CR-RIO framework is centered on an architectural model and uses an ADL and contract description language to express applications non-functional requirements [Loques 2004]. Based on these elements a supporting infrastructure is provided to: (i) parse the contract specifications and store them as meta-level data associated to the application, (ii) provide reflective and adaptive mechanisms, which allows adapting the application’s configuration (including its elements of support), in order to cope with the contract demands, and (iii) provide a set of mechanisms to interpret, impose, monitor and manage these contracts. The highlight of the approach is the immediate association between the application’s architectural components and the non-functional requirements described in a contract. This allows the designer to describe, with the required granularity, in which part of the application’s component configuration a given contract has to be imposed. In addition, adaptations that have to be performed to maintain a service quality level described in a contract, are also made explicit over the application’s architecture. 2.1 Contracts A contract describes at design time non-functional aspects of the application, specifying how supporting resources should be used in running time, and the acceptable variations on the availability of theses resources. The semantics defined by a contract is imposed in running time by a middleware infrastructure composed by a standard set of components (Section 2.3). A typical contract has the following elements: a) Categories, which describe, in an abstract level, properties of resources, services, or specific non-functional aspects, typically associated to the context where the applications run. For instance, processing, memory or communication resources can have an associated Category. Operational aspects, such as fault-tolerance, cryptography, and less tangible aspects such as price (“cheap”, “expensive”), quality (“god”, “avg”, “low”), physical position (inside, outside), can also be described. Categories are associated to the entities that will implement, manage, monitor, or give access to properties of resources or services available in the supporting infrastructure. It is worth noticing that non-functional aspects also cover concerns traditionally named as QoS (quality of service) requirements, usually associated to communication level entities. b) Profiles, which quantify or value the properties of a given Category. The quantification constrains each property according to its description, functioning as an instance of acceptable values for a given Category. Components or parts of the application’s architecture can define profiles constraining their required operating context with a desired granularity. c) A set of Services, where each Service defines a set of constraints related to

25

architecture level entities which are acceptable by the application. This is accomplished by associating one or more profiles to components or to interaction channels (used to connect components) of an application’s architecture. In this way, the desired or acceptable level of quality associated to a service is differentiated from the others by the properties (and their values) declared in the profiles. A Service can be deployed only if all of its associated profiles are valid. The set of references to individual components (modules and connectors) are considered as default profiles: so all references must be valid to maintain the Service active. In that way, each Service defines a possible operational configuration for the application. d) A Negotiation clause that describes a policy, defined by a transition system (state machine), which establishes a particular order to deploy the services. According to a described policy, when a service with higher preference can be no more maintained, the contract management entity will try to deploy a service with lower preference. The return to a service of higher preference can be also described, allowing a service with better quality or higher priority to be deployed if its associated profiles become valid. 2.2 Category Description This section describes the categories to be used in the videoconference application (Section 4). Each category contains the properties of interest, and the characteristics of these properties (Figure 1). The LocalResc category represents the resources from the local system that will be allocated / monitored in order to support the quality expected by the user. The Transport category defines the transport and communication characteristics, such as bandwidth, delay and jitter. Category LocalResc { utilization: decreasing numeric %; clockFreq: increasing numeric MHz; memReq: increasing numeric Mbytes;} Category VMedia { codec: enum (H261, H263, MJPEG); quality: enum (LOW, MEDIUM, HIGH); size: enum (CIF, QCIF); frameRate: increasing numeric fps;}

Category Transport { bandwidth: increasing numeric Mbps; delay: decreasing numeric ms; jitter: decreasing numeric;} Category AMedia { codec: enum (G711, G723, GSM, DVI); sampleLenght: enum (8, 16); // bits sampleRate: increasing numeric Hz; channels: enum (MONO, STEREO);}

Figure 1. Categories for the videoconference application

Likewise, the categories related to audio and video resources contain the properties than can be selected in typical implementations. When instantiating a videoconference terminal, for instance, the audio and video profiles can select specific values for the audio (e.g., codec:G711; sampleRate:8000) and video properties (say, codec:H261; frameRate:20). These values will be used by associated Resource Agents to allocate the necessary resources and by the Configurator to create the component instances with the adequate parameters (please, see next subsection). 2.3 Support Infrastructure Architectures described in our ADL are mapped to an object model [Corradi 2005]. This model is reflected on a meta-level repository, which maintains the configuration information of the architecture that can be queried and updated during the application’s lifetime. This repository also includes the representation of the contracts and maintains information regarding resources (devices, services, applications, etc.) that are of interest of the application. Based on the contracts, which use the information contained in the

26

repository, a supporting infrastructure is used to manage the architectural configurations. This infrastructure is composed by a standard set of components: Contract Manager (CM). The CM interprets the contracts, already mapped to the metalevel repository and extracts from them the information regarding the services, respective profiles and the service negotiation state machine. During the service deployment process the CM commands the Contractors to verify if the constraints defined in the service profiles can be satisfied. If the CM is notified, by any Contractor, with the information that a profile cannot be (or can be no more) satisfied, the current service is invalidated and a new one should be selected. The CM can also initiate a new negotiation procedure when the resources to deploy a more preferable service become (again) available. Contractor. Manages and mediates the monitoring process of the properties of the basic elements (mechanisms, resources or low-level services associated to Categories) specified in the profiles. A Contractor interacts with the Resource Agents (RA) obtaining and evaluating the measured values of the properties. Violations and validations of the profiles are notified to the CM. Resource Agent (RA). Categories are associated to RAs, which encapsulate the access to the supporting basic elements, providing interfaces to manage and monitor values of the associated properties. The acquired values are transferred to the Contractor when significant changes are detected. Configurator. Element responsible for mapping architectural descriptions into actions that configure the architecture. It can initiate an application (if it is not running yet) and execute commands received from de CM regarding services management. The Configurator provides a configuration API, which allows instantiating, linking, stopping and substituting components during the application’s operation. These operations are reflected into a persistent meta-level repository, which maintains the application’s context and can be queried through an architectural reflection API.

3. Related Work The design of pervasive and self-adaptive applications comprises a broad range of elements and techniques. In [Sztajnberg 2005] we compare several proposals regarding these concerns. Here we comment additional related works. Rainbow [Garlan 2004] adopts similar elements to those described in our proposal. It uses application invariants coordinated with adaptation strategies, which are, respectively, equivalent to profiles and services of our contracts. Adaptations in Rainbow, in contrast to our approach, which associates them explicitly to architectural level entities, are embedded in procedures that implement the configuration actions. This approach can hide structural details making formal verification more difficult. Huang presents an approach for service self-configuration based on recipes related to the application’s architecture [Huang 2004]; however, the recipes only consider communication level aspects (delay and throughput). An attractive point in the approach is the use of utility functions which identify the adequate set of resources to make the initial configuration of the application. Our approach generalizes this proposal considering utility functions as being part of the Resource Agent responsibilities making it possible to dynamically select or invalidate a specific resource, among a set

27

of similar ones, and, as a result, driving dynamic adaptations. The task-based adaptation approach [Polodian 2006] is similar to ours. The key ideas: (a) explicit representation of user tasks; (b) decoupling task and preference specification from the lower level mechanisms and (c) algorithms to select in real time near-optimal resource allocations and reallocations for a given task, have counterparts in CR-RIO. Our approach however is centered in an ADL and contracts, which are mapped to an object representation and are adequate to formal verification (Section 5). In our proposal the switching between distinct configurations of an application is triggered by changes in the execution environment, which are associated to resource variations or external events. This can lead to instability, if the managing system cannot consistently identify that the monitored values effectively represent real changing trends. [Bha99] presents a deep investigation on this issue, providing guidelines to smooth out transient or spike values, aiming to trigger service switching in a consistent manner. As an interim solution, we used in our experiments a simple moving average filtering mechanism to avoid false triggering situations.

4. Videoconference Application The considered videoconference application contains the usual elements: (i) a directory/session service, which performs the session registration and control, such as the ITU-T H.323 standard Gatekeeper; (ii) a audio and video flow redistribution element, equivalent to the H.323’s MCU (without the transcoding function), or to reflectors from systems such as the VRVS or CuSeeMe; and (iii) user’s client-terminals that perform the capture, display and transmission of the audio and video media. The basic scenario for the videoconference application comprises an arbitrary number of users distributed over a network such as the Internet, with an overlay network used to provide multipoint communication through point-to-point connections. The overlay network architecture is formed by reflectors, interconnected by communication connectors, which relay the audio and video flows. 4.1 Basic Architecture The basic videoconference application architecture is described in CBabel as in Figure 2(a) and depicted in Figure 2(b). The overlay network (a module in CBabel terms) is described stating each reflector’s instantiation (lines 3-5) and the connection between reflectors (lines 6-7), which establishes the topology for the flow relay. The terminal references are then specified (line 9) and also their link to the overlay network (line 10). All the elements are described in scope of the module teleconf, which will be used as a reference to the application’s context. 01 module teleconf { 02 module ovNet { 03 instantiate refl as refUFF at ic.uff.br; 04 instantiate refl as refUERJ at rio.uerj.br; 05 instantiate refl as refLMPD at lmpd.uerj.br; 06 link refUFF to refUERJ by comSock; 07 link refUERJ to refLMPD by comSock; 08 } 09 instantiate Terminal as c1, c2, c3, c4; 10 link c1, c2, c3, c4 to ovNet; } (a)

c1

c2 refUFF

refUERJ refLMPD

c3

c4 (b)

Figure 2. Videoconference application (a) architecture and (b) topology

28

4.2 Contracts for the Overlay Network The contract for a single overlay network requires only one service viaInternet (Figure 3), which specifies the minimum resources (CPU and memory) required to run the reflectors (in this case, the refLProf profile, lines 2-4); and the minimum resources required by the communication channels interconnecting them, defined according to the transport requirements to provide the service (profile refCProf, lines 5-6). 01 02 03 04 05 06 07

service { instantiate refl as refUFF at caueira.uff.br with refLProf; instantiate refl as refUERJ at rio.uerj.br with refLProf; instantiate refl as refLMPD at LMPD.uerj.br with refLProf; link refUFF to refUERJ by comSock with refCProf; link refUERJ to refLMPD by comSock with refCProf; } viaInternet;

Figure 3. viaInternet service for the overlay network

The foreseen demand for local resources by each reflector is defined in the refLProf, Figure 4. In this profile the admitted values for some properties of the LocalResc category are defined. When the refUFF reflector (Figure 3, line 2) is to be instantiated, for example, these characteristics are previously verified. The desired characteristics for the communication channels that interconnect each pair of reflectors are defined in the refCProf profile. The delay and bandwidth requirements are configured proportionally to the maximum number of users and simultaneous sessions, and the type of the audio and video coding to be used. profile { LocalResc.utilization: 50; LocalResc.clockFreq: 2800; LocalResc.memReq: 512; } refLProf;

profile{ Transport.delay: 50; Transport.bandwith: 16000; } refCProf;

Figure 4. LocalResc and Transport profiles for the reflectors

The viaInternet service was tested in two contract-based approaches: one to introduce fault-tolerance (by duplication) and the other to provide link-level self-repair characteristics on the overlay network. Alternative overlay network. In our experiments we worked with two sets of reflectors: one of them used links from the commodity Internet and the other Giga bit dedicated channels, connecting the UFF, the UERJ and the LAMPADA Project. In the contract described in Figure 5, in addition to the viaInternet service (described in Figure 3), we have the viaGIGA service (details not presented), which is also associated to profiles, indicating its non-functional requirements. The idea is that “overlay providers” offer differentiated access services, and the user, using a contract and consistent profiles, can specify a policy for choosing one of those services. For instance, the viaInternet service should be preferably used – given that the non-functional requirements are being met. In the negative case, the viaGIGA service, with better resources, but more expensive, is negotiated and is made the current service. If neither service can be deployed the videoconference session cannot be established. This policy is defined in the negotiation clause in the contract (lines 18-20). The overlay network selected in the contract becomes part of the context, which is used to make management decisions. To allow the composition with other contracts

29

of the videoconference application (for instance, the contracts for the terminals, see Section 4.3), the @teleconf variable (line 2) is updated with the reference of the selected network (lines 3 and 11); establishing a path to access it’s information, e.g., the identity of its component reflectors. 01 contract { 02 context @teleconf; 03 service {... @teleconf = _viaInternet} viaInternet; 11 service {... @teleconf = _viaGIGA} viaGIGA; 18 negotiation { 19 not viaInternet -> viaGIGA; 20 not viaGIGA -> out-of-service; } 21 } cAlt1Ovl;

Figure 5. Contract providing fault tolerance

Alternative link. In the case of saturation or fail of a link connecting two reflectors, the interconnection could be reconfigured using an alternative link (maintained in cold or hot standby). This aspect can be handled in a specific contract, which describes the possible configuration of the link between two reflectors associated to the overlay network provided by the viaInternet service. By using different communication connectors, independent routes are used in each service. If the preferred service is not available (that is, the preferred link), the architecture is reconfigured to use the alternative service (that is, the alternative link). If the preferred service becomes available it is established again. If neither service can be deployed this part of the architecture becomes unavailable, fact also be reflected in the whole overlay network. 4.3 Contracts for a Client Terminal Once the overlay network is deployed and available, client terminals can use this service to participate on a session. The access of the terminals is handled in another vision of the architecture. Each user terminal connects independently of the other terminals to a reflector in the overlay network. Each terminal is associated to a contract that is specified to cover the many involved requirements: (i) media quality, which depends on the chosen audio and video codecs; (ii) communication characteristics, to be observed in the link between the terminal and the associated reflector; and (iii) videoconference session management. For brevity sake, we omit the details of this last profile, considering that the directory service performs an admission control, which limits the number of clients per session. We also assume, in this example, that the local resources are always sufficient to run the selected mutimedia components. Besides defining the quality requirements the user can have a pro-active role regarding by enhancing the contracts as follows: (a) Initially the selection of the reflector to which the terminal will be linked can be done by policies defined in the profiles. Some strategies can be used considering properties of interest such as: network delay, available bandwidth, monetary cost, etc., or a combination of these properties. In a more sophisticated option, the selection can be performed by a utility-function (referenced in the contract) provided by the designer (as proposed in [Huang 2004]). In that way, calculations over a set of properties (e.g., clockFreq and utilization from the LocalResc category, delay and bandwidth from the Transport category) would guide the choice of the best reflector; (b) After the initial selection, during operation, the link connecting the client to the

30

reflector begins to present a higher delay than the tolerated, or the bandwidth becomes lower than the necessary. Foreseeing this case, the contract can include: (i) a service with lower quality, which consumes fewer resources (using H.261 instead of the MJPEG; for instance), making possible the interaction continuity; (ii) active monitoring of the available reflector/communication channel and dynamically change to a better one, avoiding bottlenecks. In this line, the instantiation of a terminal, the link between the terminalreflector, and the dynamic selection of the most appropriate reflector are ruled by the contract described in Figure 6. The contract has two specified services: 01 02 03 04 05 06 07 08 09 10 11 12 13 14

contract { service { instantiate Terminal with hqTermVProf, hqTermAProf; link Terminal to @ref by commCon with hqTermCProf; @ref=select*(hqRef, refl@teleconf); } sHQTerm; service { instantiate Terminal with lqTermVProf, lqTermAProf; link Terminal to @ref by commCon with lqTermCProf; @ref=select*(hqRef, refl@teleconf); } sLQTerm; negotiation { sHQTerm sLQTerm || out-of-service; } } } }

Figure 6. Providing dynamic adaptation for the Terminal

sHQTerm: the preferential service, which allows the use of high-quality audio and video. The instantiation of the Terminal module (line 3) is constrained by profiles adequately dimensioned and the link of the Terminal to the reflector (line 4) is also constrained by a profile to ensure adequate bandwidth and delay characteristics. sLQTerm: lower quality service, to be used in the last case. It is equivalent to the sHQTerm service, with less restrictive profiles (lines 8-9), which contain property values good enough to give support to this lower quality service. profile { VMedia.codec: MJPEG; VMedia.resolution: CIF; profile { AMedia.codec: G711; AMedia.sampleLenght: 16; profile{ Transport.delay: 80; profile { VMedia.codec: H261; VMedia.resolution: QCIF; profile { AMedia.codec: DVI; AMedia.sampleLenght: 8; profile{ Transport.delay: 80;

VMedia.frameRate: 24; VMedia.quality: HIGH;

} hqTermVProf;

AMedia.channels: MONO; Media.sampleRate: 32000;

} hqTermAProf;

(a)

Transport.bandwith: 1600; } hqTermCProf; VMedia.frameRate: 14; VMedia.quality: MEDIUM;

} lqTermVProf;

AMedia.channels: MONO AMedia.sampleRate: 800;

} lqTermAProf

Transport.bandwith: 128;

} lqTermCProf;

(b)

Figure 7. Profiles for (a) sHQTerm and (b) sLQTerm

Each service contains the description of media requirements, associated to the Terminal module, described in the profiles *termVProf and *termAProf (line 3 for the sHQTerm service and line 8 for the sLQTerm service). The communication constraints are described in the *termCProf profiles. These profiles (Figure 7) are valuations of the properties of the Transport, VMedia and AMedia categories, previously defined. The

31

values for each property where selected consistently regarding the service to with they are associated. For instance, in the hqTermVProf profile it is defined that the MJPEG is the codec to be used, CIF is the desired resolution, and the minimum tolerated frame rate tolerated is 24 fps. In that way, the deployment of the sHQTerm service will be only possible if these characteristics can be imposed. When deploying the contract, the CM must select a specific reflector to which the terminal will actually connect. This is acomplished during the negotiation process of the s*Term services. In the description of the link connecting the terminal to the refletor (Figure 6, lines 4-5 for sHQTerm and lines 9-10 for sLQTerm) the @ref context variable, will contain the reference to the reflector to be effectively used. This reference is resolved when the select* primitive is executed, which is parameterized by the selection function to be used (chosen among the ones described in the Refl category, Figure 8(a)) and a reference to the context/domain to be considered in the selection (in this case, the set of refl connectors of the @teleconf context). In this example, the utility function (optim – listed in the hqRef profile, Figure 8(b)) is applied to the monitored property values of each reflector that belongs to the @telefonf, and the results are classified to determine which reflector is the most adequate. The reference to the selected reflector can then be used in the configuration operations. Also, the select* primitive periodically checks if the currently selected refletor is still the best choice. If this is not the case, @ref is turned null and, thus, the service is invalidated (leading to a new negotiation run). category { selPol: enum (random, lowCost, optim); } Refl;

(a)

profile { Refl.selPol: optim; } hqRef;

(b)

Figure 8. (a) Refl category; (b) hqRef and lqRef profile

The negotiation clause in Figure 6, lines 12-14, contains a single rule representing a basic priority-policy state machine. The sHQTerm service, on the left, has the higher priority and is always the first to be negotiated. In the case it is not possible to deploy or maintain a service (i.e., if a profile is not valid or if the @ref is invalidated), the CM will always start to negotiate from the sHQTerm service (given that it is possible to get a better reflector when the select* function is again executed), and if this doesn’t work the sLQTerm service, with lower quality, is negotiated. While the sLQTerm service is effective, if the conditions to deploy the sHQTerm service are met, the sHQTerm will be deployed again, always trying to reach the service with higher priority, i.e., the best available service. If the deployment of sHQTerm or sLQTerm is not possible the out-of-service (not described here) service is reached and the application may be terminated. Observation. Other scenarios where a real resource is selected from a potentially dynamic set o of similar elements were explored in our research. For example, in a scenario where a set of WiFi Access Points (WAPs) is available in a building, a mobile user should be always connected to one of the WAPs. In certain circumstances two or more WAPs can be available, but one of them would be the best choice according to an utility function, say, combining available bandwidth and packet loss ratio. In this case, the current service should be continuously evaluated in order to verify if the currently selected WAP is still the one that presents the best profile, compared to the other ones in the set. A contract similar to that in Figure 6 was used to meet this requirement.

32

5. Formal Semantics for Contracts In [Braga 2006] a formal semantics for CBabel architecture and contract descriptions is presented using Rewriting Logic as the foundation. Rewriting Logic is a logic and semantic framework to which several models of computation, logics and specification languages have been mapped to [Oliet 2001], due to its unified view of computation and logic. Maude is a high-performance implementation of Rewriting Logic [Clavel 2003]. Together with its meta-programming facilities, the Maude system provides a rich tool set for the development of formal tools. Moreover, Maude has a built-in linear temporal logic model-checking capability. Using Maud we employed different approaches to verify architecture and contract descriptions in CBabel: (i) architecture components, topology and coordination requirements are naturally mapped into the Maude’s “soup” [Clavel 2003] of elements and (ii) contracts are directly mapped into transition systems (state machines), which are nicely represented with Rewriting Logic. In our framework, CBabel modules, connectors and the described topology are understood as rewrite theories, messages and equations, or more specifically, as objectoriented modules in our mapping to Maude. Using Maude’s rewriting logic semantics and meta-level features we developed the CBabel Tool, which automates the process of parsing and loading modules into the Maude system, and allows CBabel descriptions to be executed and verified as rewrite theories [Rademaker 2005]. For instance it is possible to verify deadlocks and race-conditions or model-check the architecture against temporal logic assertives. The next searches are performed to verify overflow and race conditions on a producer-consumer architecture using CBabel Tool. search [1] in VER-PCB : initial =>* C < buff : BUFFER | AS,MAXITEMS : N':Int, items : N > such that N > N':Int = true . No solution. states: 255 rewrites: 4731 in 130ms cpu (130ms real) (36392 rewrites/second) reduce in VER-PCB : modelCheck(initial, []~ raceCond) . rewrites: 4481 in 130ms cpu (130ms real) (34469 rewrites/second) result Bool: true

Besides being able to verify static architecture and coordination requirements, we are investigating verification techniques that can help us verifying non-functional contracts and answer “what happens if” questions (in the case of the videoconference example, “if the bandwidth between refUFF and refUERJ follows bellow 1 Mbps and the current services is viaInternet”). This will allow the designers to reason about the strategies employed in the contracts prior to coding the actual artifacts or deploying the application. As a first step, CBabel contracts semantics is being formalized in the form of transition systems, supported by a modular structural operational semantics definition formalism, MSDF. MSDF makes it possible to simulate and evaluate the contracts with the Maude MSOS tool [Chalub 2005], which is also based in Rewriting Logic and Maude, given that the semantic of both is exactly a transition system. Table 1. Mapping contracts to transition systems CBabel Services Negotiation rules Profiles RAs monitoring

MSDF based transition system. States of the transition system. Transitions of the transition system, and assigned priority Transition guards. Input of the transition system.

Table 1 presents the mapping between CBabel contract elements and MSDF.

33

Figure 9 represents the negotiation clause of the fault tolerant overlay service contract (Figure 5) as a transition system (or state machine). The labels in the circles represent the current service. The labels on the transitions represent the condition to fire a transition. For instance, considering the rule, not viaInternet -> viaGIGA, (line 19), the state machine is interpreted as the current service, viaInternet, being invalidated and the viaGIGA being next negotiated and deployed. Once the viaGIGA is established and cannot be maintained the transition to the out-of-service state is fired. not viaInternet

viaInternet

not viaGiga

viaGiga

out-ofservice

Figure 9. Negotiation clause (Figure 6) as a state machine

We are currently using MSDF to map and verify several example contracts, including some simplified scenarios based on the contracts presented in Section 4. The following assertive exemplifies a simple search on the overlay contract (which considered local resource profiles). (search < (system (timeStamp: 1 clockFreq: 700 utilization: 30 delay: 15 bandwidth: 180) hvideo) ::: 'System , {null} > =>+ < (system D:Data no-service) ::: 'System , {null} > .)

CBabel architecture semantics is quite stable and we are working on graphical tools to facilitate the use of CBabel Tool. The foundation of the contract semantics is also stable, but still has to incorporate some enhancements we found useful in the current stage of our investigation; for instance, the invalidation of a service when a reference is invalidated. As other ongoing activities, we are refining the kind of questions our tools can answer and designing an automatic resource data acquisition mechanism.

6. Conclusion Using the concepts and mechanisms included in the CR-RIO framework the nonfunctional requirements of a context-aware application are expressed by contracts, associated to the description of its architecture. Guided by the contracts these requirements can be imposed through adaptations on the application’s configuration or on its supporting infrastructure. The basic mechanisms for contract interpretation and management are recurrent, constituting a design pattern [Lisbôa 2004]. Based on this design pattern, the support for contracts can be implemented as a class-framework [Corradi 2005], in which hot-spots allow some classes to be specialized to cope with the specific requirements of each application. Using this class-framework several casestudy applications were implemented to help evaluating the overall approach. More details on these experiments can be obtained in [Freitas 2005, Cardoso 2006]. In order to promote the use of the described approach, it is expected that in the future an explicit separation between the policies and mechanisms is adopted in the design of the low-level artifacts, commonly used to support context-sensitive nonfunctional requirements. More specifically, these artifacts should provide (standard) APIs to manage and monitor their internal mechanisms. In this direction, we are refining our Resource Agent model, aiming to provide a way to include seamlessly low-

34

level system sensors, monitors and actuators in our framework. We are also refining our contract language to include user defined utility functions able to express complex context-sensitive dependencies. Associated to this, we are investigating select-like primitives regarding to their semantics and implementation issues. In the present article we presented some preliminary results of this ongoing activity. In an optimistic vision, the application’s non-functional requirements will be expressed through contracts, from which these requirements would be automatically imposed. In that way, autonomic systems that could enforce internally the adaptations required to meet the contractual specifications would be built. Currently there are no suitable standards and systematic solutions that allow reaching the required automation level. We hope that the approach here described can contribute to build reliable autonomic systems with lower developing and maintenance costs. Acknowledgments. The authors acknowledge the support of RNP/CPqD/Finep (GIGA Project). Alexandre Sztajnberg thanks Faperj (PAEP 04/2005 E-26/171.130/2005).

References Bhatti, S. N. and Knight, G., “Enabling QoS adaptation decisions for Internet applications”, Computer Networks, Vol. 31, No. 7, pp. 669-692, March, 1999. Braga, C. Chalub, F., “QoSTool”, in Loques, O., et al, “CARAVELA: Contracts for applications running on high speed networks”, 4th Report, GIGA Project, RNP, RNP/CPqD/Finep, January, 2006. (in Portuguese) Cardoso, L., Sztajnberg, A. e Loques, O., “Provendo aplicações com requisitos não-funcionais dinâmicos através de contratos”, to be published in the SBRC 2006, Curitiba, 2006. Chalub, F., “An Implementation of Modular Structural Operational Semantics in Maude”, MSc. Dissertation, IC, UFF, 2005. (in Portuguese) Corradi, A. S., “A framework to support non-functional requirements for high-level services”, MSc. Dissertation, IC, UFF, 2005. (in Portuguese) Freitas, G., Cardoso, L., Santos, A., Loques, O., “Otimizando a Utilização de Servidores através de Contratos Arquiteturais”, WTR 2005, Fortaleza, May 2005. (in Portuguese) Garlan, D., Cheng, S., Huang, A., et al., “Rainbow: architecture-based self adaptation with reusable infrastructure”, IEEE Computer, Vol. 37, No. 10, October, 2004. Huang, A.-C., “Building self-configuring services using service-specific knowledge”, PhD Thesis, Carnegie Mellon Univ., Pittsburgh, PA, December, 2004. Lisbôa, J. C. and Loques. O., “An architectural pattern to manage Quality of Service in distributed systems”, 4th SugarLoafPLoP, Porto das Dunas, Brazil, 2004. (in Portuguese) Loques, O., Sztajnberg, A., Cerqueira, R. C. and Ansaloni, S., “A contract-based approach to describe and deploy non-functional adaptations in software architectures”. JBCS, Vol. 10, No. 1, pp. 5-18, July, 2004. Sztajnberg, A., Corradi, A. M., Santos, A. L., Barros, F. A., Cardoso, L. X. T. and Loques, O., “Specification and support of non-functional requirements for high-level services”, 23rd SBRC Mini-courses, p. 223-279, Fortaleza, CE, 2005. (in Portuguese) Mart´ý-Oliet, N. and Meseguer, J., “Rewriting Logic as a Logical and Semantic Framework”, in Handbook of Philosophical Logic, Vol. 61, Academic Publishers, second edition, 2001. Clavel, M., Durán, F., Eker, S., Mart´ý-Oliet, N., Lincoln, P., Meseguer, J., Talcott, C., “Maude 2”, SRI International and UIUC, http://maude.cs.uiuc.edu, 2003. Rademaker, A., Braga, C.; Sztajnberg, A.; “A Rewriting Semantics for a Software Architecture Description Lang.”, Proc. SBMF 2004, ENTCS, Elsevier, V.130, pp. 345-377, May, 2005. Vahe Poladian, João P. Sousa, David Garlan, Bradley Schmerl, Mary Shaw, “Task-based Adaptation for Ubiquitous Computing”, IEEE Transactions on Systems, Man, and Cybernetics, Special Issue on Engineering Autonomic Systems, Vol. 36, No. 3, May 2006.

35