Self-adaptive applications using ADL contracts Leonardo Cardoso1, Alexandre Sztajnberg2, Orlando Loques1 1Instituto
de Computação, Universidade Federal Fluminanse (UFF), Rua Passo da Pátria, 156, Niterói - Brazil {cardoso, loques}@ic.uff.br 2DICC/IME/UERJ e PEL/FEN/, Universidade do Estado do Rio de Janeiro (UERJ), Rua S. F Xavier, 524 – Maracanã, Rio de Janeiro - Brazil
[email protected]
Abstract. This paper presents a comprehensive approach to facilitate the specification, deployment and self-management of application architectures having context-sensitive nonfunctional requirements. The approach is centered on high-level contracts, associated to architectural descriptions, which are used to specify execution context requirements and to control configuration adaptations in the application supporting infrastructure. A videoconference application is used to present the proposal’s relevant features and to evaluate the approach through an implementation.
1 Introduction The operation and utility of many distributed application architectures depend on context sensitive non-functional requirements, which must be enforced in addition to their basic functional requirements. In our terms, context-sensitive non-functional 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 architecture. Thus, considering that the same basic functional architecture can be deployed in different 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. This idea is present in many areas of current concern, among them context-sensitive and autonomic computing. On the other hand, being the component technology mature, a lot of effort is being put on characterizing diverse non-functional aspects associated to typical architectural level components (clients, servers and interaction mechanisms). This characterization provides the foundations to design description (or specification) languages that provide abstractions to formalize the nonfunctional requirements of a given application architecture. Such special purpose languages allow, starting from the architectural level non-functional requirements, to describe contracts establishing the individual and mutual requirements of the entities composing a given application architecture. Probably, in a dynamic context, there will be different configuration options that comply with the demands of a given architectural level contract. Thus, in order to support a self-adaptive architecture, it is worth to define a set of configuration options, one of which can be initially deployed, and others that can be deployed in different contextual situations, which may happen during the application life time. Thus, as a further feature, the contract description language can include an abstraction that allows describing a set of different configuration options, which satisfy, with different quality degrees, the requirements of the application. (In our proposal, we use the word service to name each particular configuration option in a given contract, see section 3.) Once a configuration option is selected, it can be used to guide adaptations in the supporting infrastructure, in order to guarantee the non-functional properties for the application. Based on the concepts previously described, this paper presents the CR-RIO approach [12] that aims to facilitate the specification, deployment and management of self-adaptive context-sensitive
applications. Besides the introduction and the conclusion, the paper presents the elements of our approach (Section 2), a prototype videoconference application, which provides a basis for discussing some aspects of our approach (Section 3), and implementation details and some evaluation results (Section 4). We also present related work in Section 5.
2 The Cr-Rio Approach The CR-RIO approach is centered on an architectural model and uses a contract description language (CBabel) to express the application’s context sensitive non-functional requirements. Based on these elements a supporting infrastructure was developed 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. This exposition also facilitates the use of formal techniques to verify structural and consistency properties of contracts [4]. 2.1 Contracts In our approach, non-functional requirements, which impose constraints to non-specialized activities that the application may have, are described by contracts [2]. A contract describes at design time the non-functional aspects of the applications, specifying how supporting resources should be used in operation time, and the acceptable variations on the availability of theses resources. An application may depend on more than one contract; the semantics defined by each contract is imposed in operating time by a middleware composed by a standard set of components (Section 2.2). Similarly to described in [6], our contract concept 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 execute. For instance, processing, memory or communication resources can have an associated Category. Operational aspects, such as fault-tolerance and cryptography, and less tangible aspects such as price (“cheap”, “expensive”), quality (“god”, “avg”, “low”), physical position (inside, outside), can also be described in categories. Categories are associated to the entities that will implement, manage, monitor, or give access to properties of resources, services, or specific features, available in the supporting infrastructure. b) Profiles, which quantify and valuate 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, which are acceptable by the application, related to architecture level entities. 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. Each service defines a possible operating state for the application.
d) A negotiation clause that describes a policy, defined by a state machine, which establishes an arbitrary order to deploy the services. According to the 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 to be deployed if the associated profiles become valid. 2.2 Category Description This section describes the categories to be used in the videoconference application (Section 3). Each category contains the properties of interest, and the characteristics of these properties (Fig. 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 %; clockFrequency: increasing numeric MHz; memReq: increasing numeric Mbytes; } Category Transport { bandwidth: increasing numeric Mbps; delay: decreasing numeric ms; jitter: decreasing numeric; } Category VMedia { codec: enum (H261, H263, MJPEG); quality: enum (LOW, MEDIUM, HIGH); size: enum (CIF, QCIF); frameRate: increasing numeric fps; } Category AMedia { codec: enum (G711, G723, GSM, DVI); sampleLenght: enum (8, 16); // bits sampleRate: increasing numeric Hz; channels: enum (MONO, STEREO); } Fig. 1. Categories for the videoconference application
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 CBabel are mapped to an object model [5]. 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 life. This repository also includes the representation of the contracts and maintains information regarding resources (devices, services, applications, etc.) that are of interest of the applications. Based on the contracts, which use the information contained in the repository, a supporting infrastructure is used to manage the architectural configurations. This infrastructure is composed by a standard set of components (Fig. 2), described next:
Contract Manager (CM). The CM interprets the contracts, already mapped to the meta-level 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. Non-functional constraints Contract Manager
Contract
Resource-level requests Contractor
Constraints violation
Configurations
Resource Agent
Measured values
Configurator
Fig. 2. Component of the supporting infrastructure
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 Videoconference Application In this section we present a videoconference application to expose details of the proposed approach. The considered application contains the usual elements: (i) a directory/session service, which performs the session (room) registration and control, such as the H323 standard Gatekeeper [19]; (ii) a audio and video flow redistribution element, equivalent to the H323’s MCU (without the transcoding function), or to reflectors from systems such as the VRVS [1]; and (iii) user’s terminals that perform the capture, display and transmission of the audio and video medias. c2
c1
c2
c1 r1
Overlay Network
c3
c4
(a) Fig. 3. (a) Basic architecture; (b) Overlay network detailed
c3
r2
r3
c4
(b)
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 (Fig. 3(a)). The overlay network architecture is formed by reflectors (Fig. 3(b)), interconnected by communication connectors, which relay the audio and video flows. More details of this architecture are presented in sections 3.1 and 3.2. The teleconference application can have specific availability and reliability requirements. To cater for this case, we can add fault-tolerance to the overlay network and self-repair for its individual links. This is accomplished by a set of contracts and services, as described in section 3.3. Also, for clients, different forms of adaptation can be planned, such as: (i) for a static set of participating clients of a session, select a set of reflectors aiming to minimize the global communication delay; (ii) for a dynamic set of clients, when admitting a new client, the support can select, from the available reflector set, a given one that based on a policy optimizes performance parameters, e.g., delay and network throughput. Contracts for clients are presented in section 3.4. 3.1 Basic Architecture The basic videoconference application architecture is described in CBabel as in Fig. 4. 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) that establishes the topology for the flow relay. The terminal references are then specified (line 9) and also their link to the overlay network (link 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 reflector as refUFF at caueira.uff.br; 04 instantiate reflector as refUERJ at rio.uerj.br; 05 instantiate reflector 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; 11 } Fig 4. Videoconference application architecture
Once described, the application architecture can be actually deployed. But, besides the application functional aspects we are interested on non-functional aspects regarding operational requirements, such as the quality of the video and audio flows required by the user, and the overlay network capability to forward the flow of various sessions. In this context, those requirements should be specified, monitored and imposed by the supporting environment, as discussed previously. In our approach this is achieved by establishing contracts (including services) associated to different parts of the overall architecture. In this application architecture, specifically, the overlay network and the terminals used by the teleconference users. 3.2 Contract for a Single Overlay Network The contract for a single overlay network requires only one service viaInternet (Fig. 5), 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 reflector as refUFF at caueira.uff.br with refLProf; instantiate reflector as refUERJ at rio.uerj.br with refLProf; instantiate reflector 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;
Fig. 5. viaInternet service for the overlay network
The foreseen demand for local resources by each reflector is defined in the refLProf, Fig. 6. In this profile the admitted values for some properties of the LocalResc category are defined. When the refUFF reflector (Fig. 5, 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. It is worth noting that resource reservation is not always possible. In many systems it is only possible to perform an initial allocation of resources, which can be actually shared, or even relocated to applications with higher priority. Thus, during operation, the defined characteristics could be monitored and, in case of violation, an adaptive mechanism (associated to a service) can be started, e.g., to introduce a new reflector in the overlay network to balance the load. profile { LocalResc.utilization: 50; LocalResc.clockFrequency: 2800; LocalResc.memReq: 512; } refLProf;
profile{ Transport.delay: 50; Transport.bandwith: 16000; } refCProf;
Fig. 6. LocalResc and Transport profiles for the reflectors
3.3 Contracts for Fault-Tolerance and Self-Repair Now we present two contracts used to introduce fault-tolerance (by duplication) and 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 Fig. 7, in addition to the viaInternet service (described in Fig. 5), we have the viaGIGA service, 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, 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-21). 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; Fig. 7. Contract providing fault tolerance
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 of the videoconference application (for instance, the contracts for the terminals, see Section 3.4), 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. 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), Fig. 8(a). This aspect can be handled in a specific contract, which describes the possible configuration of the link between two reflectors, as presented in Fig. 8(b), associated to the overlay network provided by the viaInternet service. prim
R1
prim
R2 alt
R1
R2
(a)
alt
11 service { 12 link refUFF to refUERJ by comSock1 with refCProf; 13 } primeLink; 14 service { 15 link refUFF to refUERJ by comSock2 with refCProf; 16 } altLink; 17 negotiation { 18 not primeLink -> altLink; 19 altLink -> primeLink; 20 not altLink -> out-of-service; 21 } 22 } cAltOvl;
(b)
Fig. 8. Contract to self-repair overlay links
The contract in Fig. 8(b) describes two link services. By using different communication connectors (comSock1 and comSock2) independent routes are used in each service. The negotiation clause states that the preferred service is primeLink. If this service is not available, the architecture is reconfigured to use the altLink service (line 18). If the primeLink service becomes available again it is established again (line 19). If neither service can be deployed this part of the architecture becomes no-operating (line 20), fact that will also be reflected in the whole overlay network. 3.4 Contracts for a Terminal Once the overlay service is deployed and available, user terminals can connect to this network 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) local resources characteristics; (ii) media quality, which depend on the chosen audio and video codecs; (iii) communication characteristics, to be observed in the link between the Terminal module and the associated reflector; (iv) 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. Besides defining the quality requirements the user can have a pro-active role regarding the access to the videoconference session, 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 the properties of interest, described in the profiles of the service, 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 [9]). In that way, calculations over a set of properties (e.g., clockFrequency 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 Terminal to the 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 a service with lower quality, which consumes fewer resources (using H261 instead of the MJPEG; for instance), making it possible the interaction continuity. The instantiation of a terminal is ruled by the contract described in Fig. 9, where two services are specified: sHQTerm: the preferential service, which allows the use of high-quality audio and video. The instantiation of the Terminal module (line 2) and the link of the Terminal to the reflector (line 3) are constrained by profiles adequately dimensioned. sLQTerm: lower quality service, to be used in the last case. Its equivalent to the sHQTerm service with less restrictive profiles (lines 6-7), which contains property values just sufficient to give support to this lower quality service. 01 02 03 04 05 06 07 08 09 10 11
service { instantiate Terminal with hqTermLProf, hqTermVProf, hqTermAProf; link Terminal to @ref by commCon with hqTermCProf, @ref=select(hqRef, reflector@teleconf); } sHQTerm; service { instantiate Terminal with lqTermLProf, lqTermVProf, lqTermAProf; link Terminal to @ref by commCon with lqTermCProf; } sLQTerm; negotiation { not sHQTerm -> sLQTerm; not sLQTerm -> out-of-service; }
Fig. 9. Providing dynamic adaptation for the Terminal
Each service contains the description of the local resources and media requirements, regarding the instance of the Terminal module, described in the profiles *termLProf, *termVProf and *termAProf (line 2 for the sHQTerm service and line 6 for the sLQTerm service); the communication constraints are described in the *termCProf profile. These profiles are valuations of the properties of the LocalResc, Transport, VMedia and AMedia categories, previously defined. profile { LocalResc.utilization: 30; LocalResc.memReq: 512; LocalResc.clockFrequency: 1600; } hqTermLProf; profile { VMedia.codec: MJPEG; VMedia.frameRate: 24; VMedia.resolution: CIF; VMedia.quality: HIGH; } hqTermVProf; profile { AMedia.codec: G711; AMedia.channels: MONO; AMedia.sampleLenght: 16; Media.sampleRate: 32000; } hqTermAProf; profile{ Transport.delay: 80; Transport.bandwith: 1600; } hqTermCProf;
(a)
profile { VMedia.codec: H261; VMedia.resolution: QCIF; } lqTermVProf; profile { AMedia.codec: DVI; AMedia.sampleLenght: 8; } lqTermAProf profile{ Transport.delay: 80; } lqTermCProf;
VMedia.frameRate: 14; VMedia.quality: MEDIUM; AMedia.channels: MONO AMedia.sampleRate: 800;
(b)
Transport.bandwith: 128;
Fig. 10. Profiles for (a) sHQTerm and (b) sLQTerm
The profile used to specify the requirements to sHQTerm and sLQTerm are presented in Fig. 10(a) and (b), respectively. The 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. In the negotiation clause (Fig. 9) the sHQTerm service (line 10) is initially negotiated. In the case it is not possible to maintain this service (assuming that in this example it will be possible to deploy it initially), the CM will negotiate the sLQTerm service deployment (line 11), with lower quality. If none of the services can be deployed the application is terminated. category { selPol (random, lowCost, bestPerf, optim); } Refl; profile { Refl.selPol: optim; } hqRef;
(a) (b)
Fig. 11. (a) Refl category; (b) hqRef profile
In the contract deployment time the CM must select a specific reflector to which the Terminal module will actually connect. So, in the description of the link of the terminal, regarding the preferential service (Fig. 9, line 3) the @ref context variable, will contain the reference to the reflector to be effectively used in the link. This reference is resolved, when deploying the initial service, by executing the select primitive, which is parameterized by the selection function to be used (chosen among the ones described in the Refl category, Fig. 11(a)) and a reference to the context / domain to be considered in the selection (in this case, reflector of the @teleconf context). In this example, the utility function (optim – enumerated in the hqRef profile, Fig. 11(b)) is applied to the profile of each reflector, which makes part of the context, and the results are classified to determine which reflector is the most adequate. The reference to the specific selected instance is then used in the configuration operations.
4 Implementation & Evaluation The basic mechanisms for contract interpretation and management are recurrent, constituting a design pattern [11]. Based on this pattern, the specific support for contracts was implemented as a pre-composed set of objects (an object framework) [5], in which hot-spot objects allow some classes to be specialized to cope with the specific requirements of each application. Using this framework the videoconference application was implemented with the objective of evaluating the contract approach and performing experiments related to the switching of services. Specializations of the Contractor were implemented in order to handle the specific constraints of the services defined in the contracts of this application. In the same way, RAs where specialized to offer the access to the metrics associated to each contract. We developed three RAs:
•
Processing: performs the discovery and monitoring of local resources such as CPU and memory; implemented using the Ganglia tool [13];
•
Network: provides bandwidth and delay measurements regarding communication links; based on the Abing tool [15];
•
Real Time Protocol: in charge of monitoring the media flow properties. Developed using the commons library distributed with the VIC program [14]. In the current version, it monitors RTP packet loss.
The reflector’s implementation uses the code described in [8] as a base, which only performs the forwarding of UDP packets. The original version was enhanced with an API that allows the dynamic creation of sessions and the management of participants. In the experiment we configured some scenarios with pre-recorded audio and video flows. A set of machines (2.8 GHz P4, 512 MB RAM) distributed among UFF and UERJ were connected trough Internet links, which where “strangled” by a 10 Mbps HUB (to make possible the injection of background flows with no additional impact to the observed nodes). The same set was redundantly connected by dedicated optical Giga bit links, with access by 100/1000 Mbps switches. Delay (ms) 200,00
C
B
180,00
Loss (pkt/s) 3,00
160,00 140,00
2,00
120,00 100,00 80,00
Loss
60,00
A
40,00 20,00
1,00
Delay
0,00 1
8
15
22
29
36
43
50
57
64
71
78
85
92
0,00 99 106 113 120 127 134 141 148 155 162 169 176 Time (s)
Fig. 12. Measure (mobile avg.) for delay and RTP packet loss
Fig. 12 presents the results of one of the experiments regarding the contract associated to the communication between two reflectors, refUFF and refUERJ, primLink service on Fig. 8. An audio flow was transmitted form refUFF to refUERJ and a UDP flow injected as background. The measure of the delay was used to identify the necessity of adaptation. Also, the RTP packed loss was monitored in refUERJ to evaluate the quality of the audio flow under test. Point A shows the moment when the UDP flow was introduced. Point B indicates the instant when the RA in refUERJ monitors a value above the established in the profile (150ms, in this case), fact that is reported to the CM by the Contractor. Point C shows the moment when the alternative service (altLink) is deployed (between B and C, the state machine is evaluated, and a new service is selected and deployed). The RA continues to report packet losses, which are discarded by the Contractor until the alternative services has sufficient time to get in permanent regime; it can be verified that beyond this point the delay value returns to the desired level. To avoid instability provoked by temporary spike values monitored on the flow, which could cause false service transitions, it was used a mobile average filter. In the experiment we adopted a sample period of 3 sec, and the mobile average calculated over the 5 last samples. By another side, according to the tests performed in [5], the average time between receiving a profile violation notification and the establishment of the next service is approximately 2 ms. Additionally, the time to switch/add another component (that can be necessary to make an adaptation, e.g., chance the codec) using a Configurator integrated to the middleware [16] varies between 10.4 ms (best case: local execution / pre-loaded object) and 28.7 ms (worst case: remote execution / with object creation). These last measures demonstrate that the bottleneck, which bounds the total time for adaptation, is explicitly related to the interval required to identify in a consistent way a profile violation. [3] presents a more detailed investigation on this issue.
5 Related Work The approach described in this paper comprises a broad range of techniques [18]. Here we comment additional related works. The TAPAS project [10] proposes the use of a special language (SLAng) [17] to specify nonfunctional restrictions, which are associated to specific parts of an application infrastructure. Concepts similar to categories and profiles are adopted, but they are designed to e-busyness applications in the WWW context. Mainly, the proposal concentrates on the specification issues, only suggesting that the restrictions can be checked at execution time, and eventually used to guide adaptive actions. The Rainbow [7] proposal adopts similar elements to those described in our proposal. It uses application invariants coordinated with adaptation strategies, which are, respectively, equivalents 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 of contracts more difficult than in CR-RIO. In our project, we were able to develop a tool [4] that transforms contract descriptions in rules and equations in Maude (based on a modular structural operational semantics definition formalism), allowing to verify profile definition inconsistencies, service reachability and deadlocks. Huang presents an approach for service auto-configuration based on recipes related to the application’s architecture [9]; However, the recipes only consider communication level aspects (delay and throughput) and the association with the architectural level is only illustrated by means of a simulator. 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. Once initiated, local adaptations can be rapidly decided and performed to maintain the application running. Our approach generalizes this proposal including diverse non-functional aspects, as well as catering for the explicit description of the adaptations to be performed.
6 Conclusion We presented an approach that integrates diverse elements necessary to the design and implementation of applications with context-sensitive non-functional requirements. According to this approach non-functional specifications of the applications are expressed by contracts, associated to the description of their architecture. Guided by the contracts several requirements can be imposed through adaptations on the application’s configuration or on its supporting infrastructure. In this context, it should be noted that an application can be in fact managed by several contracts, each one of them associated to different elements (resources, applications or services) that are part of it, making it self-manageable. In this way, the goal of building autonomous systems, with capability to perform the required adaptations internally and automatically, in order to impose the contractual specifications could be achieved. In order to make practical the use of the proposed adaptation techniques, it is expected that in the future an explicit separation between the policies and mechanisms is adopted in the design and implementation of the artifacts commonly used to support context-sensitive non-functional requirements. Specifically, the resource agents should provide (standard) APIs to manage and monitor the resource associated mechanisms. This should facilitate the integration with the highlevel contract management entities, allowing more flexibility to impose the adequate adaptation policies to cope with the demands of current applications.
Acknowledgments. The authors acknowledge the support of RNP/CPqD/Finep (GIGA Project). Alexandre Sztajnberg thanks the support from Faperj (PAEP 04/2005 E-26/171.130/2005).
References 1. Adamczyk, D., Collados, D., Denis, G., Fernandes, J. et al., “VRVS 3 - Global platform for rich media conferencing and collaboration”, Third Annual Workshop on Advanced Collaborative Environments, Seattle, Washington, June, 2003. 2. Beugnard, A., Jézéquel, J.-M., Plouzeau, N. and Watkins, D., “Making components contract aware”, IEEE Computer, Vol. 32, N.7, pp. 38-45, July 1999. 3. [3] Bhatti, S. N. and Knight, G., “Enabling QoS adaptation decisions for Internet applications”, Computer Networks, Vol. 31, No. 7, pp. 669-692, March, 1999. 4. Braga, C. Chalub, F., “QoSTool”, in Loques, O., Sztajnberg, A., Abelém, A., Braga, C. and Stanton, M., “CARAVELA: Contracts for applications running on high speed networks”, 4th Report, GIGA Project, RNP, RNP/CPqD/Finep, January, 2006. (in Portuguese) 5. Corradi, A. S., “A framework to support non-functional requirements for high-level services”, MSc. Dissertation, Instituto de Computação, UFF, 2005. (in Portuguese) 6. Frolund, S. and Koistinen, J., “Quality-of-Service Specifications in Distributed Object Systems”, IEE Distributed Systems Engineering, No. 5, pp. 179-202, UK. 1998. 7. Garlan, D., Cheng, S., Huang, A., et al., “Rainbow: architecture-bases self adaptation with reusable infrastructure”, IEEE Computer, Vol. 37, No. 10, October, 2004. 8. O. Hodson, O., Varakliotis, S. and Hardman, V., “A software platform for multi-way audio distribution over the Internet”, Audio and music technology: the challenge of creative DSP, IEE Colloquium, London, November, 1998. 9. Huang, A.-C., “Building self-configuring services using service-specific knowledge”, PhD Thesis, Carnegie Mellon Univ., Pittsburgh, PA, December, 2004. 10. Lamanna, D. D., Skene, J. and Emmerich, W., "Specification language for service level agreements". D2 - TAPAS Project, http://www.newcastle.research.ec.org/tapas /deliverables/D2.pdf, 2004. 11. Lisbôa, J. C. and Loques. O., “An architectural pattern to manage Quality of Service in distributed systems”, The 4th SugarLoafPLoP Conference, Porto das Dunas, Brazil, 2004. (in Portuguese) 12. 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. 13. Matthew, M. L., Brent, C., and David, C., “The Ganglia distributed monitoring system: design, implementation, and experience”, Parallel Computing, Vol. 30, No. 7, July, 2004. 14. UCL Network and Multimedia Research Group, “Mbone conferencing applications”, http://wwwmice.cs.ucl.ac.uk/multimedia/software 15. Navratil, J. and Cottrell, R. L., “A practical approach to available bandwidth estimation”, Passive & Active Measurement Wks. pp.1-11, La Jolla, CA, April, 2003. 16. Santos, A. L. G., “Dynamic configuration support for component-based software architectures”, MSc. Dissertation (in preparation), Instituto de Computação, UFF, 2005. (in Portuguese) 17. Skene, J., Lamanna, D. D. and Emmerich, W., "Precise service level agreements", 26th Int. Conference on Software Engineering, Edinburgh, UK. pp. 179-188, 2004. 18. 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 Minicourses, p. 223-279, Fortaleza, CE, 2005. (in Portuguese) 19. Toga, J. and Ott, J., “ITU-T standardization activities for interactive multimedia communications on packet-based networks: H.323 and related recommendations”, Computer Networks, v. 31, n. 3, p. 205223, February, 1999.
