Informática 35 (2011) 29-37 29 Component Reconfiguration in Presence of Mismatch Carlos Canal and Antonio Cansado Department of Computer Science, University of Málaga, Spain E-mail: canal@lcc.uma.es Keywords: component substitution, dynamic reconfiguration, software adaptation Received: February 20, 2010 This paper discusses how to reconfigure systems in which components present mismatch in both their signature and behavioural interfaces. We are interested in performing component substitution without stopping the system, though we assume components are not designed with reconfiguration capabilities in mind. We also consider that components may need to be adapted before interacting with the system. In this work we identify the basic requirements for achieving runtime component substitution, and define several different interchangeability notions that are adequate to component substitution under behavioural adaptation. Our approach is illustrated with a case-study of a client/server system where the server needs to be substituted by a new one. Classic equivalence and compatibility notions fail to find a new server because the only one available implements a different interface. We show how our interchangeability notions could be used in order to let the system keep on working. Povzetek: Opisanoje preoblikovanje sistemov, ko se zgodi neskladje. 1 Introduction Software reuse is of great interest because it reduces costs and speeds up development time. Indeed, a vast number of software components are already available through the Internet, and many research and development efforts are being invested in devising techniques for combining them safely and efficiently. In particular, Software Adaptation promotes the use of adaptors in order to compensate mismatch among component interfaces. In fact, this is the only known way to adapt off-the-shelf components since designers usually only have access to their public interfaces. Without adaptation, components could not be put together or their execution could lead to deadlocking scenarios [2, 9]. Still, one of the most challenging issues in Software Adaptation is that systems need to adapt to environmental changes, server upgrades or failures, or even the availability of a new component more suitable to be used in the system. Indeed, the need for finding a new component to be integrated in the system may be either reactive or proactive. The reactive case is caused by the system itself. For instance as a consequence of connection loss or failure of one its components, thus creating a hole in the system that must be filled for its correct functioning. The proactive case would be caused by the availability of a new component that is suspected to be a good candidate for being integrated in the system, replacing some of its current components. In both cases, we have first to detect the need for reconfiguration by using runtime monitoring techniques both on the system and on its environment. Then, the interface of the candidate components —and its compatibility with the rest of the system— must be evaluated, attending not only to its signature interface (names of services, operations, messages, etc.), but also to its behavioural interface (the order in which the elements in the signature interface are expected to be used) and the QoS features provided/expected by the component and the system. When dealing with this kind of dynamic reconfiguration [14], component substitution must be applied without stopping the complete system, and trying to affect minimally its performance, in particular the functioning of those of its parts that are not directly involved in the reconfiguration. That means that components must collaborate to support reconfiguration capabilities. In fact, it is important to determine when the system can be reconfigured and which kind of properties the system holds after reconfiguration. Few works have studied the interplay of behavioural adaptation and reconfiguration so far. In most approaches to reconfiguration, substituting a component by another one requires the new component to implement the same functionality as the former one. This means that substitution is usually limited to instances (or subtypes) of a given component. However, it is possible that a component cannot substitute another one, but an adapted version can. This paper identifies some basic requirements for runtime component substitution and we describe the operations required to achieve this reconfiguration. We also define several different interchangeability notions that are well fitted for component substitution under behavioural adaptation. The paper is structured as follows: Firstly, Section 2 provides some background on behavioural interfaces and adaptation. Then, Section 3 introduces a client/server system that is used as running example through all this document. Section 4 presents our reconfiguration model, for describing systems as a collection of static ar- 30 Informatica 35 (2011 ) 29-37 C. Canal et al. chitectural views (configurations), and reconfiguration operations for moving from one configuration to another one; it also shows how reconfiguration states can be defined at certain points of system execution, and how new components must be initialised for arriving to these states. Next, Section 5 defines different notions of substitutability that we believe are adequate for component replacement under behavioural adaptation. Then, Section 6 outlines the platform that we plan to implement for validating our results. Finally, Section 7 presents related works on reconfiguration and behavioural adaptation, and Section 8 concludes the paper. This paper builds on our previous work in the field. It is an extension of our position paper [10], developing the ideas presented there, adding many explanations and more detailed examples. In presents also our model for dynamic reconfiguration, and the notions of substitutability discussed in [10] are formally defined here. 2 Background We assume that component interfaces are equipped both with a signature (set of required and provided operations), and a protocol. For the protocol, we model the behaviour of a component as a Labelled Transition System (LTS). The LTS transitions encode the actions that a component can perform in a given state. For reasons of space we omit the signature interface when it can be easily inferred from the corresponding protocol. Definition 1. [LTS]. A Labelled Transition System (LTS) is a tuple (S,so,L,—>) where S is the set of states, so G S is the initial state, L is the set of labels or alphabet, —> is the set of transitions : —»Ç S xLx S. We write s —» s' for (s, a, s') e-h Communication between components are represented using actions relative to the emission and reception of messages corresponding to operation calls, or internal actions performed by a component. Therefore, in our model, a label is either the internal action t or a tuple (M, D) where M is the message name and D stands for the communication direction (/ for emission, and ? for reception). LTSs are adequate as far as user-friendliness and development of formal algorithms are concerned. However, higher-level behavioural languages such as process algebras can be used to define behavioural interfaces in a more concise way. We can use for that purpose the part of the CCS notation restricted to sequential processes, which can be translated into LTS models: P ::= 0|a?P|a!P|T.P|Pl + P2\P/L\A, where 0 denotes a do-nothing process; alP a process which receives a and then behaves as P;alP a process which sends a and then behaves as P; t.P a process which performs an internal action t and then becomes P; PI +P2 a process which may act either as PI or P2; P/L is the process P after hiding the names in L, preventing any communication on those names; and A denotes the call to a process defined by an agent definition equation A = P. Additionally, we will use the parallel operator 11 for representing the composition of components —represented by CCS processes— allowing the synchronisation of their input and output actions. In this paper we will use LTSs or CCS expressions indistinctly for representing components and adaptors. Both could be easily obtained for standard notations such as WS-BPEL or WWF. 2.1 Specification of adaptation contracts Adaptors can be automatically generated based on an abstract description of how mismatch can be solved. This is given by an adaptation contract In this paper, the adaptation contract between components is specified using vectors [8]. Each action appearing in a vector is executed by one of the components, and the overall result corresponds to a loose synchronisation between all of them. A vector may involve any number of components and does not require interactions to occur on the same names of actions. For distinguishing between actions with the same name occurring on different components, we prefix actions with component names. For example, (C\.on\,C2.activatel) is a vector denoting that the action on! performed by component CI corresponds to action activate? performed by component C2. This does not mean that both actions have to take place simultaneously, nor one action just after the other; for the transmission of Cl's action onl to C2 as activate?, the adaptor will take into account the behaviour of these components as specified in their LTS, accommodating the reception and sending of actions to the points in which the components are able to perform them (Fig. 1). ? ® ...Ji ' (SK ® Figure 1: Components CI and C2 connected through an adaptor. 2.2 Adaptor generation Thus, previously to the reconfiguration of the system by the integration of a new component, we will likely need to adapt the component for solving the problems of compatibility detected in the component discovery phase. This will be accomplished by generating an adaptor, that will play the role of wrapper or component in-the-middle, filtering the interactions between the component and the system and ensuring both a correct functioning of the system (verifying for instance the absence of deadlocks or other user defined properties) and the safety of the composition (i.e., that the component is behaving as stated on its interface). In previous works we have developed a methodology COMPONENT RECONFIGURATION IN PRESENCE OF. Informatica 35 (2011 ) 29-37 35 for behavioural adaptation (see [9], where our approach for generating adaptors is presented). Following this methodology, both contract specification and adaptor generation are tool supported [8]. 3 Running example This section presents the running example used throughout the paper. It consists of a client/server system in which the server may be substituted by an alternative server component. This may be necessary in case of server failure, or simply for a change in the client's context or network connection that made unreachable the original server. Suppose that the client wants to buy books and magazines as shown in its behavioural interface in Fig. 2(a). The server A can sell only one book per transaction (see Fig. 2(c)); on the other hand, the server B can sell a bounded number of books and magazines (see Fig. 3(b)). In both cases, sales are represented by a pair of actions (one order and its acknowledgement), and with these two actions we abstract all the details of payment and shipment. Initially, the client is connected to the server A; we shall call this configuration ca- The client and the server agree on an adaptation contract stf^c^. (see Fig. 2(b)), which establishes action correspondences between the client and the server A. Obviously, under configuration ca the client can buy at most one book in each transaction but it is not allowed to buy magazines because this is not supported by the server A. The latter is implicitly defined in the adaptation contract (Fig. 2(b)) since there is no vector allowing the client to perform the action buyMagazinel. Finally, the server A does not send the acknowledgement ackl expected by the client; this must be worked out by the adaptor, too (see V4 in Fig. 2(b)). In an alternative configuration cb the client is connected to the server B whose protocol is depicted in Fig. 3(b). Similarly, the client and the server agree on an adaptation contract s^^cfi (see Fig. 3(a)). Under configuration cb, the client can buy a bounded number of books and magazines. In Fig. 3(a), we see that vector vs allows the client to buy magazines. Moreover, the server B sends a different acknowledgement for each product (see V4 and w, in Fig. 3(a)). Following the methodology for behavioural adaptation presented in [9], adaptors can be automatically generated for configurations ca and cb (see adaptors Ac a and Ac.u in Fig. 4). These adaptors ensure by construction that the interaction between the client and servers A or B will take place without deadlock and fulfilling the correspondences of actions described in the corresponding adaptation contracts [9], 4 Reconfiguration model This section presents the model that enables both reconfiguration and behavioural adaptation. We define a reconfigu- (a) LTS of ClientC vi = {C .login\,A.user!) V2 = [C .passwd\:A.passwd!) V3 = [C .buyBook\:A.buy!) v4 = (C.ackl,A.e) V5 = [C .logout\, A.disconnect!) (b) Adaptation Contract .e/^c,A Figure 2: Configuration caví = (C .login\,B. connect!) V2 = [C .passwd\:B.pwd!) V3 = [C : buyBook\:B : buyBook!) v4 = {C.ack!,B.bookOk\) V5 = {C.buyMagazinel,B.buyMagazine!) V6 = [C .ack! :B .magazineOk\) V7 = {C .logout\,B.disconnect!) (a) Adaptation Contract j/^c.b (b) LTS of Server b Figure 3: Configuration cb- ration contract to determine how the system may evolve in terms of structural changes. First, a system architecture consists of a finite number of components. Each configuration is a subset of these components connected together by means of adaptation contracts. Definition 2. [Configuration]. A configuration c = (P, ¿/të, S*) is a static structural representation (c) LTS of Server A 32 Informatica 35 (2011 ) 29-37 C. Canal et al. Figure 4: Adaptors of a system's architecture. P is an indexed set of components. is an adaptation contract of components in P. S* is a set of reconfiguration states defined upon P; these are the states in which reconfiguration is allowed. Changing a configuration by another is what we call a reconfiguration. A reconfiguration is specified in a reconfiguration contract which separates reconfiguration concerns from the business logic of the system. This way, each configuration can be thought of as a static view of the system, while its dynamic view is specified by a reconfiguration contract. Definition 3. [Reconfiguration Contract]. A reconfiguration contract = (C, Co, —is defined as: C is a set of static configurations, Co G C is the initial configuration. ->«CCx Rop xC is a set of reconfiguration operations, with reconfiguration operation Rop Ç S* x S*j, Sj G Ci,Sj G Cj ■ cij G C. From the definition above, reconfiguration can only take place at predefined states, for guaranteeing system consistency. One certain state of the source configuration (sf) defines when an architecture can be reconfigured. On the other hand, one state of the target configuration (sp says what is the starting state in the target configuration to resume the execution. Notice also that the target configuration may require a new adaptation contract (allowing replacing a component by another one that implements a different behavioural interface). Example. In our running example, there are two configurations: cA = {{C,A},^c,A,SkA),md cb = ({C,B},£/^c,b,S*b). The reconfiguration contract 3% = (C, is given by: C = {cA,cB}, and {cA cB}, with r= (4,4). Hence, r specifies pairs of reconfiguration states on which reconfiguration can be performed. Since both servers have different behavioural interfaces, it is not straight-forward to determine how reconfiguration can take place after a transaction between the client and the server has started. In the simplest scenario, we may consider that reconfiguration from ca to en and back is only allowed at the initial states of the client and the server. This is specified as a unique reconfiguration state s® G 5*, / G {A. />'} for each configuration, (where = {C..V()./1..Vo} and s# = {C.so,B.so}), and a pair of reconfiguration operations rA,B . rB,A . , , n n, . ca —> cb and cB —> ca, with rA,B = 14'41 and rb,a = (4 .Y({} (subindexes in states always refer to state numbers as depicted in Figs. 2 and 3). In the next section, we will study how other pairs of reconfiguration states —apart from the initial states here— can be obtained. 4.1 Reconfiguration at runtime In the previous section we have presented our reconfiguration model considering that reconfiguration could be only performed at the initial state of the system (i.e. at static time). Now we will generalise our working scenario allowing reconfiguration to occur when the interactions have already started and the components are in intermediate states (i.e. at dynamic time). Interactions already performed with the component being substituted cannot be merely ignored; they must be either reproduced up to an equivalent state with the new component, transparently to the rest of the system, or rolled back and compensated when the reproduction of the state is not possible. Both fault-tolerance algorithms, exception handling and roll-back techniques must be developed to this effect, and compensation procedures must be defined when the initiated interactions cannot be correctly finished. Example. In our running example, if the login phase has already been performed with the system in configuration ca, and then we need to move to configuration cb, the server B should be initialised such that the client does not need to re-log in the system. Suppose that the client C has performed a trace {loginl,passwdl}: Then, the initialisation trace for the server B would be {connect?, pwdl}. Once the server B is initialised as indicated, the system can be reconfigured in order to use the new component. The substitution of the server A by the server B does not affect the client C in the sense it does not need to re-log in the system. In fact, COMPONENT RECONFIGURATION IN PRESENCE OF. Informatica 35 (2011 ) 29-37 35 the client continues working on transparently, though it is warned that the adaptation contract has changed. This way, we have implicitly defined two new reconfiguration states: s\ = {C.si.A.si} for configuration ca and s\ = (C..V2. U.S2) for cb, and one reconfiguration operation ca cb, with r2 = {s\, 4}• In the next section, we will present several notions of substitutability that will help us defining additional reconfiguration states and operations for our system. 5 Notions of substitutability One of the key elements in allowing safe reconfiguration is to determine whether a certain component can be easily replaced by another one. A relation of equivalence —such as bisimulation in CCS— cannot be used for these purposes. Indeed, since there is mismatch among the interfaces of the components, a test based on bisimulation would immediately reject servers A and B as equivalent (A ■-/ />'). Even if we accommodated name mismatch between both servers by using the adaptation contracts c„.\ and s^^cfi for building name substitutions a a, <7s according to the correspondence of names described in those contracts, the renamed components A