Dynamic Maintenance and Evolution of Critical Components-Based Software Using Multi Agent Systems

Component-based development has become a commonly used technique for building complex software systems by composing a set of existing components. In general adapting an application means stopping the application and restarting it after the adaptation. This approach is not suitable for a large classes of software systems in which continuous availability is a critical requirement, hence the need of adapting dynamically the application at runtime. This paper presents an architecture based approach for dynamic adaptation in critical components based software using multi agent system.To achieve this, we use an agent based system to perform the adaptation. The agent system is guided by an architectural description. The adaptation mechanism is implemented within the connectors using the flexibility offered by the Java script language techniques. The script language Groovy is used. The evaluation is made by comparing the execution time before and after the adaptation mechanism. The paper is structured as follows: section 2 presents related works to dynamic adaptation. Section 3 describes the proposed solution to achieve a dynamic update of components-based software applications. The implementation details and some measurements relative to our solution are given in section 4. Section 5 concludes and presents some perspectives.


Introduction
A components-based development [Szyperski, C., 1998] aims to the development of large software by assembling existing components.The continuous evolution of user's needs and the fast changing in the execution environments make the software adaptation a primordial task.In components-based development paradigm [Aksit, M. and Choukair, Z., 2003], an adaptation can address: Architectural changes, geographical changes, Interface modification, or implementation adaptation.The architectural changes consist of adding or removing components or modifying connections among them.The geographical changes correspond to the migration of components from one site to another.The interface modification consists of changing the interface of a component to make it more compliant to the caller's expectations, while the implementation adaptation affects the internal implementation of components without changing its interfaces.
Traditionally, an application is stopped to be adapted.This approach is not suitable for critical systems that have a high level of availability like banks, Internet or telecommunication services.In these systems the adaptation must take place at runtime and the application should not be entirely stopped.Unfortunately, such adaptation is not trivial; there are several conditions and constraints to be satisfied, and this leads to many problems to overcome.Some important issues to be, in order, made to the dynamic update are [Aksit, M. and Choukair, Z., 2003]:  Maintaining application consistency: Components states must not be affected by changes the application architecture. Preserving components bindings: Bindings have to be preserved by redirecting the calls to new components and managing transient states. Initializing new components: New components must be initialized with adequate internal state according to the former component. Preserving communication channels by avoiding message loss, duplication or excessive delays.
In this paper, we describe our approach to achieve dynamic adaptation of components-based software applications.The idea is to introduce between two components a connector (unit of interaction) [Kell, S., 2007] that intercept and redirect inter components communications.The adaptation is made through a so called adaptation system by acting on connectors.The adaptation system is part from the application, and it consists of agents system, whose role is to perform and supervise the adaptation operations.The agents system is guided by a knowledge base, with: i) the architectural description of the running application, ii) a set of reference rules defining the adaptation policy, iii) a set of coherence rules ensuring the validity and the coherence of adaptation process.The evaluation is made by comparing the execution time of the initial application (prior to the adaptation) with the execution time after the adaptation mechanism.
We have tested the adaptation mechanism influence on the application response time and the adaptation time.According to the results, we noticed that the influence on the response time is stable and that overhead time is about 16 %.The adaptation time average is greater than three (03) seconds.Of course, this figure is very large compared to the response time of one request which is approximately 14ms.However, this is only true while the adaptation process is taking place.A second experimentation aims to evaluate the ability of the system to preserve the communication channels during adaptation.The obtained results show that the rate of altered messages, during an adaptation, is null.According to the previous results, we can state that the proposed approach is well suited for applications, with a low adaptation rate, and in which loss of performance is preferred than the loss of data.

Related works
Several works dealt with dynamic adaptation problems, hence the emergence of several approaches.
In the model driven approach, the dynamic adaptation is based on a components model that designed to support this kind of adaptation.DCUP (Dynamic Component Updating) [Plasil, F. et al., 1997] is an example of this approach.In DCUP the component is divided into two parts: permanent part and replaceable part.Adapting a component means replacing its replaceable part by a new version at run-time.
In the reflexive approach, an application has an abstract level (meta-level) that reify the real system.The adaptation is made first on the meta-level, after that, the changes are reflected on the executed applications thanks to the causal connection between the meta-level and the real system.DYVA [Ketfi, A., 2004]: is an example of reflexive framework for dynamic reconfiguration of components-based applications.The framework is decomposed in two main parts: The base-level represents the concrete application that provides the expected functionalities and its execution environment and the reconfiguration machine that contains i) the different operational modules responsible for achieving the reconfiguration, ii) the meta-level which represents the materialization of the concrete application.
In the architectural approach, it uses explicit description of the executed application through specific languages: the ADLs [Medidovic, N. and Taylor, R.N., 2000] (Architecture Description Languages).An ADL describes an application in term of components, connectors and connection among them.The adaptation in this approach is verified and validated in the architectural level before to be applied on the application.This approach is used by [Qun Yang et al., 2006]; the adaptation takes advantage of both meta-architecture and the mobile agents.It uses an architectural model to guarantee the safety of the reconfiguration, while using mobile agents to automate the adaptation process in a flexible way.
In the flexible middleware approach, the adaptation is delegated to the execution platform.In such system the dynamic adaptation is looked like a non functional properties offered by the middleware, like security and transactions management.The adaptation in [Brinkschulte, U., Schneider, E. and Picioroag, F., 2005] is based on the real time middleware OSA+ [Brinkschulte, U. et al., 2002].The objective is to be able to reconfigure services during run-time, with a predictable and predefined blackout time (the time where the system does not react due to the reconfiguration).
The aspect oriented approach, which adaptation is based on the aspect oriented programming techniques [Kiczales, G. et al., 1997]; in particular the dynamic aspect involves plugging and unplugging aspects without stopping, and restarting a running system.DAOP [Pinto, M. Et al., 2003] (Dynamic Aspect-Oriented Platform) is an example of such system.DAOP provides a composition mechanism that plugs aspects into components dynamically at runtime.The composition between components and aspects is established during runtime interaction and is governed by a set of plug-compatibility rules in order to guarantee their correct interoperation.
Authors in [Oreizy, P. et al., 1998] describe Arch Studio, a tool that implements an architecture-based approach to runtime software evolution.The approach is based on an explicit architectural model, which is deployed with the system and used as a basis for change.The connectors in the system are first class elements that have an important role to support run-time changes.An imperative language is used for modifying architectures.The tool supports adding, removing and replacing components and connectors, and changing the architectural topology.
On the same axis [John, C., et al., 2004] presents an architecture-centric approach to self-adaptive software applied to systems constructed using independent components interconnected through first-class connectors, both explicitly modelled using architectural descriptions.The architectural models are used as the basis for the decomposition.The architectural models representation is make using xADL 2.0 language [Dashofy, E.M., et al., 2001]; a highly extensible, XML-based ADL.An extension of this language is also used to define the structure of observations, responses, and adaptation policies.
In [Qun Yang et al., 2006], the adaptation takes advantage of both meta-architecture and the mobile agents.It uses an architectural model to guarantee the safety of the reconfiguration, while uses mobile agents to automate the adaptation process in a flexible way.
[ Huang, G., et al., 2006] presents an approach to recover software architecture from component based systems at runtime and changing the runtime systems via manipulating the recovered software architecture.As soon as software architecture is recovered, the runtime system can be observed, reasoned and adapted through its architecture views.The approach supports the adding, deletion and replacement of the components and connectors.
As a conclusion each one of the cited approaches has its advantages and drawbacks.Our approach is based on a Multi Agent System (MAS) which is justified by the facts that: -The adaptation of s distributed application needs distributed tools; this is the case of MAS, -MAS is mature with stable and efficient platforms, and characteristics like communication, scalability, mobility, and so on…

Proposed System
The architecture of the proposed system [Belabed, A. and Chouarfia. A., 2008] consists of two main parts: the Knowledge Base and the Multi Agent System: MAS (Figure 1):

Knowledge Base: KB
The KB consists of two parts: the adaptation policy and the architecture description.The formalism used in this base is based on the logic of predicates; we used Prolog.The choice of this formalism is justified by:  The important role played by the architecture description in the adaptation mechanisms; as it involves a large number of inferences made on the architecture description to guide the adaptation.Such mechanism is provided in Prolog. Prolog¦ can be easily used as descriptive language.A predicate which presents a fact is similar to an ¦XML tag¦, for example: < tag > value < tag >, can be written in P¦PPProlog as¦ tag (value).More Moreover, ¦Prolog¦ is used in several projects to describe more complex structures such as ontology [Samuel, K., et al., 2006]; this motivated us to use it as an architecture description language. The existing tools facilitate the use and the integration of Prolog formalism with other languages (such as java/Prolog interface), hence eliminating the reprogramming of the necessary inferences mechanisms needed in our approach.

Adaptation Policy
The adaptation policy is a set of rules that guide the adaptation trigger according to the values of particular environment variables.The rules are in the following form:

If <event> Then <action>
An event can be a significant change in one of the environment variable like memory usage, network bandwidth saturation, and so on.The following example shows the form of a rule which specifies the trigger of an adaptation if the memory exceeds a given value (val).Replace (compo1,compo2).

Event ('Context', Value):-Value > val,
The predicate Event has two parameters: the first specifies the type of context concerned by the event; and the second the value of the event.The action "Replace (compo1, compo2)" will be triggered only if the condition "Value > val" is verified.
If a new significant event occurred while a component is running, the adaptation is postponed until the execution of the component terminates.We did not investigate yet the interrupt of a running component, and then make the adaptation and resuming the component adaptation.

Architecture Description
The description contains:  The detailed specification of each component in the component's database in terms of provided and required interfaces along with their operations. The architecture description of the running application (components/connectors and interactions). The inference rules used to extract the correspondence and compatibility between components. The set of rules used to ensure the adaptation coherence and finally validate it.Connector ('name', 'id') Interact ('component_id1, 'component_id', 'operation_id1', 'operation_id2', 'connector_id') This relation will provide all the couples (connector, operation) in connection with the component_id1.Such relation is used to localize all the connectors which call component_id1 in order to block their messages towards it during an adaptation task.

e-Coherence rules
Like inference rules, the knowledge database is enhanced by two sets of coherence rules.The first set is used to ensure the knowledge database coherence, while the second is used to ensure the application coherence before to validation of the adaptation task.Knowledge database coherence rules: Example: 'Two components don't have the same component_id' is expressed as (15) Incoherence is detected if the execution of this predicate ends succeeded.The rule (1) is used to make the link between the component_name and its component_id.Application coherence rules: Example: "Detection of cycle in the call of operations" is expressed as The connect predicate defines a connexion between two operations X and Y (X calls Y).This relation is established if the rule (13) exists and it includes the operations X and Y.The rule (17) specifies that the relation is verified even if the call is not direct.A cycle is detected if an operation calls itself.

Multi Agent System MAS
 As already stated, the use of MAS is justified by the facts that it is a distributed tool in a mature phase along with stable and efficient platform.MAS (Figure 2) contains two agents: an adaptation agent A-A and an environment agents E-A.

Adaptation Agent A-A
Its role is to:  Take decisions about the adaptation triggering, according to the notifications provided by the E-A.The A-A uses the adaptation policy rules to accomplish this task. Perform the adaptation according to the actions deduced from the adaptation policy rules.The adaptation operations are guided by the architecture description base. Modify the architecture description according to the changes made on the application level.The A-A makes the above operations through three managers: the rules manager, the adaptation manager and the architecture manager.
The rules manager is responsible for the manipulation of the adaptation policy rules.If a decision to adapt is taken, the rules manager informs the adaptation manager to do so.This operation is guided by the architecture manager which makes the necessary inferences from the architecture description base.Subsequently, after each adaptation the architecture manager reflects the changes upon the architecture description in order to ensure a matching between the running application and its description.

3.2.2: Environment Agent E-A:
Its role is to control the execution environment and to notify the A-A, in case of any significant changes in the environment variables [Belabed, A. and Chouarfia. A., 2008].

Adaptation Principle
The idea behind the approach is to associate a connector to each component, which implements its required interfaces.The inter components calls are done through these connectors.
The adaptation mechanism acts directly on connectors to achieve the adaptation (Figure 3).Each connector implements the necessary mechanisms (calls and redirection) that allow the adaptation agent to perform the update.
Using Figure 3, we explain the structure of connectors in our approach.In the following example, we assume that the C1 component interacts with the C2 component through a connector in a synchronous communication mode.
The C1 component requires interface I1, the specification of which is: The body of Operation Op1 of the connector is implemented with a script that makes the call to Operation Op2 of C2 component, with the necessary parameters and return types casting.The replacement of the C2 component is made by changing the executed script in the body of connector's operation (Op1 in the example).
The system is designed to support the adding, removing, replacement and migration (change of the deployment server) of components.The A-A operates according to an adaptation scheme, this is a set of basic algorithms specific to each operation (ex: adding or removing operation).
Before any operation, the components directly implied in the adaptation operation must be in a passive state, this is possible thanks to the connectors that can queue calls to a component C during adaptation.
A dynamic connection between two components C1 and C2 is to put in interaction these two components through two operations, usually called methods, M1 and M2.M1 is the required method for C1 and M2 is the provided method by C2.The connection is done by the A-A while indicating to the connector associated with C1 the name of C2 component and the method to be called M2.A mapping phase between the two methods is necessary before establishing the connection.The correspondence concerns the call parameters, their order and the return type of each method.The mapping is done manually by the administrator of the application using the architecture description.The administrator must provide the methods of calculation (script code) for conversion between the types of the call parameters and the return type of each method.The methods are then transmitted to the connector responsible for the connection between the two components.To make conversions, in an automatic way, after a connection, the administrator must also manage the semantic correspondence between the methods to be connected to avoid erroneous semantic uses.
The dynamic disconnection of a component consists of putting it in a passive state.After the corresponding phase, the adaptation agent performs the replacement according to the following adaptation order: 1. Referring to the architecture description, the adaptation agent localises all connectors in relation (in provided interfaces) with the component to be replaced (« con 1.3 » and « con 2.3 » in the example).
2. The adaptation agent puts C3 in passive state by giving instructions to each localised connector to block all incoming messages towards it.
3. The adaptation agent deploys the new component.
4. The adaptation agent sends the necessary information to each connector to make the redirection of the calls towards the new component.
5. The adaptation agent connects the new component on the provided interfaces with the C4 component, this operation implies the deployment of the connector associated to the NewC3 component.
6.The adaptation agent makes a state transfer between the two components if this implies.
7. After a time t corresponding to the maximum of the response times of the component to be replaced, the adaptation agent deactivates this last one then activates the new component by releasing the blocked messages and announces the end of the adaptation process.This mechanism is used to make sure that the C3 component has finished all its current treatments before its suppression.

Component Migration
The migration consists of moving a component from an application server S to another server NewS.The new server must provide an execution environment for the moved component, i.e. it must have all the resources which the component needs.The migration of a C component towards a NewS is made by the A-A according to the following script: Listing 3: Component migration code

Adaptation Coherence
The adaptation coherence is ensured at the architectural level.Before establishing an adaptation at the executing level, a prior adaptation is made on the architectural level.The coherence checking is done through a set of rules incorporated in the architecture description base.Any incoherent adaptation incoherent at this level is cancelled.
The following section describes the solutions used in our approach to ensure a coherent and safe adaptation.
1. Preserving communication channels: the communication channels are preserved through a mechanism implemented in each connector.This mechanism suspends the incoming messages during the adaptation process.The end of adaptation resumes all the suspended messages, and the application continues its execution without loss of messages.-make a state transfer between C and its copy; 2. Coherence of the interactions: the coherence of the interactions between components is ensured through a manual a mapping phase between the components ports of the components to connect.This phase is performed using information provided for each port in the architecture description base.This information allows us to take into account the semantics of use of each port and component, hence avoiding any conflict when calling operations.
3. Conflicts between adaptations: to avoid any conflict between adaptations, we do allow only one adaptation at a time, i.e. there are no concurrent or simultaneous adaptations.This leads to a total crash of the application.In case of many adaptations, we "serialize" the adaptation processes and we serve them in first in first out order.However, if we notice a conflict between adaptations, within the queue, we perform only the last one.
4. The state transfer: we do not introduce a specific solution in our approach; we adopt the solution proposed by [Ketfi, A., 2004].This solution is specific to the components written in java.Each component before, its deployment, is instrumented using a byte code manipulation tool such as Javassist [Chiba, S. and Nishizawa, M., 2003] or BECEL [Dahm, M., 1999].In this phase we inspect the component implementation then select the attributes which constitute the state of component, we add then the operations getStat () and setState() in the component implementation.This mechanism increases the complexity of the operation of adaptation, for example, in component replacement it is also necessary to make a correspondence between the two components to see whether it is possible to make a state transfer.
If the mapping fails, the replacement will then be impossible.

Implementation and Evaluation
A preliminary implementation of the system is done for the EJB (Enterprise Java Bean: Sun Micro Systems) component model.For implementing the interception and redirection mechanisms in the connectors, we have used the reflexives properties of Java language and the Java scripting programming technique [Bosanac, D., 2007].This technique consists of executing a script code in a java class.The script origin can be a file or other application.This technique enables the adaptation agent to change the connectors' code dynamically.The script language used in the implementation is Groovy [Bordeie, X., 2007].
To evaluate the proposed system, the test application runs on a PC with Pentium IV 1.7MHz, 256M SDRAM.It consists of a component client sending a string and component server receiving and printing it on the screen before returning it back to the client.
The evaluation test is made by comparing two versions of the same application; one implements the adaptation mechanism on its connectors, the other one without this mechanism.
First, we have tested the adaptation mechanism influence on the application response time.The objective was to calculate the response time increase in the version which implements the adaptation mechanism in relation with the number of requests sent by the client.The Table 1 shows the response times before and after the adaptation mechanism.
According to the results, we notice that the influence of the adaptation mechanism is at least stable; it induces a response time increase of about 16%.This increase is acceptable because the use of an interpreted language in connector code and will be less if a compiled version.We cannot say that is acceptable or not, as it depends on the nature of the application and whether we prefer dynamic adaptability more than performance or not.Thus, there is always a trade off between the dynamic adaptability and performance.
The second evaluation is to measure the adaptation executing time, which is also the inactivity time, since the communication channels are blocked during adaptation.The adaptation time is calculated as follow:
T rspt-wa : response time including adaptation.
T rspt-na : response time without adaptation.
According to the results shown in Table 2, we observe that the adaptation time average is greater than 3 seconds.This time is very large compared to the response time of only one request which is approximately 14 ms (response time/a number of requests).This value presents an unacceptable inactivity rate, especially if we manipulate a highly critical or real time application.
The last experimentation, Table 3, aims to evaluate the ability of the system to preserve the communication channels during adaptation.For this reason, we have implemented on the client component a mechanism that counts the number of the positive acknowledges received from the server component.We repeat the previous experience, in which we make adaptation during request execution.
The obtained results show that the rate of altered messages during an adaptation is almost null, thanks to the call blocking/unblocking mechanism implemented on the connectors.
According to the previous results, we can say that the proposed approach is well adapted for the applications with less frequent adaptation rate and in which we prefer performance losses to data losses.

Conclusion
In this paper we have presented an architecture based approach for dynamic adaptation in component-based software.The major advantage of the proposed system is the separation of the adaptation mechanism from the executed application.This makes the system independent from particular component models and platforms.The implementation for a specific component model (Enterprise Java Bean, CCM (Corba Component Model: OMG) or Dot Net: Microsoft) is made with the least effort in connectors' level and without changing the main adaptation concepts.The main advantage is the preserving of the communication channels because of a reliable adaptation.
However the evaluation of the proposed solution has revealed some limits, for example the long adaptation time makes our solution adapted only for special kinds of applications.Others limits like the non support of simultaneous adaptations, leads us to plan the following prospects:  The improvement of the adaptation system in terms of performances;  To extend the MAS by introducing for example several adaptation agents and ensuring their collaboration to achieve more than one adaptation at the same time.In the long term, we plan to continue our experiments with others components models like CCM and Dot Net, and study the possibilities to extend our adaptation solution to be supported by other kinds of applications like web services.Also, we plan to enumerate and specify the kind or the type of systems or applications where our approach is well suitable and appropriate.

/
Figure4shows the replacement of the component C3 by the component NewC3.In the example, the C3 component is in relation with the two components C1 and C2 through the provided interfaces and in relation with C4 through the required interface.
Migrate (component C, server NewS) { -deploy a copy of C on the NewS; -locate all connectors referring C; -make C in passive state (no incoming calls); -send the address of the NewS to the localised connectors to locate the migrated component; -If C is with state Then { -Waits a t time >= max (response time of C); Figure 1.Proposed architecture

Figure
Figure 2. Multi agent system

Table 1 .
Increase rate time

Table 2 .
Adaptation time

Table 3 .
Altered messages rate