Dynamic Configuration Abstraction

Transcription

1 LANCASTER UNIVERSITY Computing Department Dynamic Configuration Abstraction Ian Warren and Ian Sommerville Cooperative Systems Engineering Group Technical Report : CSEG/5/1995 CSEG, Computing Department, Lancaster University, LANCASTER, LA1 4YR, UK. Phone: ; Fax: ; cseg-info@comp.lancs.ac.uk Dynamic Configuration Abstraction Ian Warren and Ian Sommerville Computing Dept., Lancaster University, LANCASTER LA1 4YR, UK. iw,is@comp.lancs.ac.uk Abstract. Dynamic configuration is the ability to modify the structure of an application as a concurrent activity to the application providing service. Society has

2 placed great reliance on complex computer systems; this tr looks set to continue with expectations for non-stop and adaptive applications. Research to date has produced a pool of mechanisms and theory regarding dynamic configuration. Our research appears as a natural and timely progression. We feel it is appropriate to provide abstraction support, so propose the use of an abstract model to manage reconfiguration. Central to our work is an application model which is used to manage reconfiguration automatically whilst preserving application consistency. Reconfiguration is expressed by version descriptions, which initiate a state transition from one configuration state to another. In addition, the model provides a base from which developers can analyse reconfigurable applications. 1 Introduction Today's society places considerable trust in computer systems. Many applications are subject to real-time constraints, are geographically distributed, must reason in the absence of complete information and are safety critical in nature. Such characteristics yield applications which are inherently complex. This complexity will be further increased by the requirements placed on nextgeneration systems. Continuous service and adaptability are two interesting requirements of tomorrow s systems. We define non-stop applications as a class of system where a break in service might result in a catastrophe. The term catastrophe is used to embrace a human fatality, an economic loss, or environmental damage. Adaptive systems are defined as a class of system which operate in dynamic environments. Dynamic configuration is the ability to modify the structure of an application whilst the application continues to operate. We view dynamic reconfiguration as a strong candidate with which to realise non-stop and adaptive applications. Much recent research has adopted the Configuration paradigm [1] for structuring reconfigurable applications. Non-stop applications must be maintained dynamically through evolutionary change. We define evolutionary change as the accommodation of requirements changes, bug fixes and environment changes. Evolutionary change is initiated by developers or administrators in response to evolving system requirements. Adaptive systems may themselves invoke structural change through reactive change, which is defined as reconfiguration in response to application or system events. Application events are application specific, but an example of a system event might be a processor failure. Research to date has produced a pool of mechanisms for effecting dynamic configuration and theory with which to reason about reconfiguration [2]. Mechanisms have emerged which, for example, maintain application consistency during reconfiguration [2-6], facilitate timely change [6] and allow reactive change to be robust to evolutionary change [7, 8]. However, dynamic configuration research is still relatively immature [9]. We propose a framework which provides abstraction support for dynamic configuration. The rationale behind our model is to raise the level of abstraction at which engineers are able to consider reconfiguration. The heart of the model is a repository which represents a model of an application. Our model provides an abstract interface to the repository which provides support for reconfiguration control and analysis. Control provides for automated and valid reconfiguration which will leave the application in a consistent state. Analysis enables engineers to ensure that an application meets its reconfigurability requirements, and to reason about proposed configuration changes. Support of this nature is lacking from research to date. 2 Background The intention of this section is to provide the reader with an appreciation of the issues in dynamic configuration management. Table 1 summarises these issues. We are constrained by space, so are unable to elaborate in detail on relevant work.

3 Separation of application function from configuration. Declarative (re)configuration expression. Preservation of application consistency. Reactive change expression robust to evolution. Reconfiguration efficiency. Table 1 Prevailing issues The Configuration paradigm [1] is an approach to software development which separates the functional description of individual component behaviours from the system viewed as a set of processes and their interconnections. Such a separation of concerns is essential for reducing complexity. Reconfiguration can be reasoned about purely in terms of application structure without regard for component implementation detail. Components are functional entities which encapsulate state. They are interconnected by bindings, which queue messages for effecting data and control exchanges. Inter-component communication is not direct, but through a well defined interface. An interface is typically composed of ports which form an indirect coupling between connected components. Outports provide for sing messages, while inports allow a component to receive messages. Components thus, do not make external references. The Configuration paradigm naturally leads to the use of two languages: a configuration language for specifying system structures, and a programming language for coding individual components (C++ for example). Configuration languages support a small set of commands to effect component instanciation, removal, binding, and execution termination and resumption. Although declarative, such command sets offer only primitive support. They are abstract in as far as they suppress the implementation detail of each command. Currently, we view configuration commands as analogous to low level machine instructions. The presence of a dynamic configuration capability should not compromise application integrity. If reconfiguration is managed indepently of the application, the application may proceed towards an inconsistent state with the possibility of causing a catastrophe. Maintaining application consistency introduces two further issues; namely synchronising reconfiguration with the application, and management of persistent state. The former requires the specification of a state which must be reached and maintained, prior to and during reconfiguration. The latter requires that any significant state held in components and bindings must survive reconfiguration. ACTIVE CHANGE MANAGEMENT Application contribution yields complex application components and a subversion of the Configuration paradigm. Restrictive definition of quiescence yields unnecessary disturbance. Assured reachability of quiescent states, but only if application components behave correctly with respect to the reconfiguration protocol. PASSIVE CHANGE MANAGEMENT Application components do not contribute to reconfiguration, and so are usable with or without the presence of a reconfiguration manager. Reconfiguration states are expressed in terms of asynchronous port interactions. This fine grained approach can optimise minimal disturbance. Reachability of reconfiguration states is not assured, neither is the correctness of reconfiguration state expressions. Table 2 ACM and PCM characteristics We are aware of two approaches to synchronising reconfiguration with the application: active change management (ACM) [6] and passive change management (PCM) [3]. These are summarised in Table 2. ACM requires explicit contribution to the reconfiguration process from application components. Correctness of ACM is thus depent on the conformance of application

4 components to the semantics of the change protocol. PCM is fundamentally different; it is based on expressing reconfiguration states in terms of the externally observable behaviours of components. ACM is based on transaction completeness. In this paper, we adopt the following definition of a transaction; a service which, when requested, involves computation from exactly one component. According to Kramer [6], a component is in a passive state if: it can service incoming transactions, but it is not currently awaiting a response from a transaction it initiated, and it will not initiate a new transaction. Kramer suggests that passivity is not a strong enough property of a component to be reconfigured; rather, a component must be in a quiescent state. A component, X, is quiescent if it is passive, and all components which may initiate a transaction of X are also passive. Quiescence thus implies that there are no outstanding transactions involving X. Work involving persistent state capture [4] appears to work well with a synchronisation model based on transaction completeness. Herlihy's work exts an abstract data type (ADT) with two further operations, capture and restore. Capture extracts the state encapsulated within an abstract data type. Restore initialises a compatible ADT with the state extracted by capture. Such state access and modification operations are typically restricted to use by the dynamic configuration manager [10]. Persistent state management however, introduces several non-trivial problems [2, 5] such as identification of critical state and transformation of state from one component to another where the data structures employed by the two components are not identical. Further, initialisation of components which are dynamically introduced may require access to state of a number of existing components. Persistent state management is fundamental to application consistency preservation and is an issue which must be further addressed. For applications where adaptive behaviour and continuous service are expected, reactive change expressions must be expressed in a way that is robust to evolution. When an application has been subjected to evolutionary change, the resulting structure might not comply with assumptions made by reactive change expressions. For example, a component may be referred to in a reactive expression which has been removed from the system by a preceding evolutionary change. This type of problem is experienced when configuration languages use explicit naming to refer to components. Endler [7] has addressed this problem with an object selection mechanism for use in reactive change expressions. This mechanism selects components according to their properties rather than by explicit naming. Finally, dynamic configuration management should be efficient. Efficiency can be decomposed into three distinct parts. First, the time between reconfiguration request and execution should be minimal. Second, the time taken to perform the requested reconfiguration should also be minimal. Third, application disturbance with respect to the number of components affected by reconfiguration should be minimal. The first two issues are crucial for reactive change, but in the absence of real-time constraint expression, are difficult to reason about. Application disturbance can be minimised by designing loosely coupled component configurations. 3 Dynamic Configuration Management: Abstraction Support We are now in a position to present our argument for dynamic configuration abstraction. The limitations of current work can be illustrated with a simple example. Consider a configuration of two components, a nurse and bed monitor as illustrated in figure 1(b). An evolutionary change involving changing the implementation of the nurse component is required. The change might be necessary to effect a bug fix. change upgrade_nurse (old_nurse : nurse; monitor : bed_monitor) select old_nurse : # ( {request}) = # ( {data}) stop old_nurse unlink old_nurse.request, monitor.request unlink old_nurse.data, monitor.data unlink old_nurse.alarm, monitor.alarm create new_nurse : enhanced_nurse relink new_nurse.request, monitor.request relink new_nurse.data, monitor.data relink new_nurse.alarm, monitor.alarm start new_nurse remove old_nurse (a)

5 old_nurse alarm request data new_nurse (b) monitor alarm request data monitor alarm request data (c) alarm request data Figure 1 Nurse enhancement reconfiguration Assuming the configuration shown in figure 1(b), a change program must be written to effect the required evolutionary change, resulting in the configuration of figure 1(c). The change program is shown in figure 1(a). We have used Etzkorn's configuration language. The choice of configuration language is arbitrary for our purposes, but we have selected Etzkorn's language to illustrate the passive change approach to synchronising reconfiguration with the application. The change program, update_nurse scopes the change to the two components old_nurse and monitor. The select statement expresses the predicate which must evaluate true prior to performing reconfiguration. In this scenario, the components involved in reconfiguration are deemed to be consistent when the number of port interactions on port request of old_nurse equals the number of port interactions of port data of old_nurse. Upon reaching this state, the sequence of configuration commands are executed sequentially. The configuration language offers no support for management of persistent state encapsulated within components. This is generally typical of other work reviewed. From the above example, it is apparent that there is much scope for error. Change administrators are confronted with an interface comprising the primitive command set supported by the configuration language. The responsibility for ensuring the correctness, in terms of consistency and completeness of the change program lies with the change administrator. Trivial errors can easily be introduced with non-trivial consequences. For example, in the above change program, if a link instruction were used instead of a relink instruction, the messages in the original binding would be lost 1. As a consequence, the application would enter an inconsistent state. The use of the PCM approach to synchronisation of reconfiguration with the application requires a reconfiguration predicate to be expressed imperatively. The imperative nature of reconfiguration expressions demands that individuals responsible for reconfiguration have a sound understanding of the application being reconfigured. There is a real risk of expressing a reconfiguration state that is not reachable, which is of particular concern for reactive change. For ACM, the responsibility for correct reconfiguration is shared between application components and the change program. Assuming each application component behaves as expected with respect to the change management protocol semantics, the individual administering reconfiguration must identify which components to make passive, and which to make quiescent. Conic [6, 13] supports a passive configuration command which is used to achieve passivity, and ultimately quiescence. Although trivial, the example indicates the error prone nature of a low level dynamic configuration protocol. Of greater significance, are a number of problems which are raised when developing sizeable applications. The Configuration paradigm generally yields loosely coupled applications. However, developers can subvert this property with the undesirable consequence of increasing the degree of inter component coupling. If a component involved in reconfiguration is highly coupled with respect to its neighbouring components, many components might be susped prior to reconfiguration. This would result in unnecessary application disturbance. Excessive disturbance could cause an application to fail its requirement for continuous service. 1 Assume that the semantics of link create a new binding. In contrast the semantics of relink are such that a new binding is not created; rather, an existing binding which may contain unprocessed messages is relinked between the two named components.

6 The current lack of tools for analysis and automated reconfiguration control is undesirable for reconfigurable systems development. These problems have generated a set of requirements for our work on dynamic configuration abstraction as shown in Table 3. SUPPORT Analysis Control (RE)CONFIGURATION REQUIREMENTS For any reconfigurable application, it should be possible to show reachability of all reconfiguration states. Rationale: A non-reachable reconfiguration state will preclude reconfiguration. Reactive change is typically required in realtime. An unreachable reconfiguration state will cause an application to fail its real-time and perhaps functional requirements. Inter component coupling. A metric for measuring the cohesion between components is desirable. Rationale: Loosely coupled systems generally experience little disturbance during reconfiguration. Excessive disturbance may cause an application to fail its requirement for continuous service. For any proposed change, support should be provided to examine the effects of change. Rationale: Without support for change impact assessment, the danger of transforming an application which as expected into an application which behaves unpredictably is likely to become a reality. Automated reconfiguration. Dynamic configuration should be managed without user intervention where possible. Rationale: The risk of introducing error into the process of reconfiguration is high when manual techniques are employed. Proposed change should be expressed abstractly. Rationale: It is desirable to express change at a higher level of abstraction. The probability of introducing error would then be reduced because of the automation potential. 3.1 The model Table 3 Requirements for dynamic configuration abstraction Our model has been developed to manage dynamic configuration abstractly. Initial configuration and subsequent reconfiguration of a particular application are expressed abstractly in the form of version descriptions. A version description is defined as a set of attribute values, which when applied to an application specification, generates a unique system instance. Reconfiguration of an application is initiated by submitting a version description of the proposed system. Figure 2 shows that reconfiguration causes a state transition from one configuration state to another. A version description may be invalid for one of two reasons. The first is that the version description has not identified a unique system instance. All static variability (section 3.2) must be removed from a system description in order to remove any ambiguity in system construction. The second reason is that the version description has described a system which violates the structural constraints specified by the system model. Invalid version descriptions are rejected, as the proposed system would result in an invalid state transition. Our model for reconfiguration expression is novel; rather than expressing change explicitly as changes to the current configuration of an executing application, change is expressed by describing a new system version. The processes of determining version description validity and ensuring application consistency preservation during the state transition is the responsibility of the configuration manager, not the individual administering the change.

7 VD' current VD' proposed describes describes configuration' current state transition configuration' proposed Figure 2 Configuration state transition A repository used to model reconfigurable applications lies at the heart of the model. An abstract interface is provided which comprises a set of tools which interact with the repository. The tools generally facilitate reconfiguration control and analysis. Evolutionary change is initiated through use of the user interface tools. Reconfiguration is managed by the application interface tools. The Configuration paradigm naturally supports a constructive approach to system building [1]. Currently, we assume that for any component specified in the application specification, there exists an implementation of the component coded in C The repository The application model captures two views of an application. The first is an application specification, which describes structural variability, component behaviours, constraints governing legal configurations, reactive change expressions and identifies components with persistent state. There are two types of variability: static and dynamic. The second view is an application image which serves as a run-time database. The image records the dynamic properties of an executing application, for example, transaction status's, and the processor on which each component resides. The configuration manager interacts with the application image to maintain consistency between the image and the executing application. Static variability captures the variability inherent in a family of related applications. For example, a family of applications might be functionally equivalent, but structural variability is necessary to support several platforms. A version description is applied to the family which generates a particular system. All static variability must be removed by applying a version description to the family prior to system building. Dynamic variability captures the set of all possible configuration states which an executing application may assume. At any given time, the application configuration must correspond to a particular state in the set. Evolutionary change may am the set of configuration states, but reactive change is constrained to selecting a particular configuration from the set. We have described the application model using a new object-oriented configuration language, PCL [11, 12]. The primary role of PCL is to model evolving system architectures. Although designed as a tool to assist with static configuration management activities, we have found it appropriate for implementing our model and are continuing its evolution in the context of dynamic configuration.

8 composition structure classifications family entity relationship participation applied-to generates attribute value set version description system version Figure 3 PCL entity structure The unit of configuration in PCL is the family entity, which represents one or more versions of a logical component or system. A family entity may be related to other family entities through inheritance, composition, and relationship participation. Figure 3 illustrates that a family entity has various kinds of associated information (shown in rectangles) such as a composition structure. An entity may be classified in a number of dimensions; classifications are used to identify legal entity domain and range arguments in relationships. Attributes are used for documenting entities, and for version selection. The parts section is used to specify the composition of an entity in terms of other entities. Further, a family entity may have one or more version descriptors which uniquely define a single version of that family by specifying its. We do not have the space to present complete PCL descriptions in this paper, but in figure 4, we show some general declarations which are used in our example of section 4. These declarations provide some building blocks for modelling reconfigurable applications. We have modelled the elements of the Configuration paradigm; namely ports, components, and their bindings. The port declaration is an abstract family entity 2 from which application ports are derived. port entities are classified according to the direction of data flow and whether they are synchronous or asynchronous. The classification hierarchy of figure 4(a) shows how ports may be classified in the ABSTRACTION dimension. Ports are responsible for managing one instance of a particular data type, captured by the data attribute. port_class in_port out_port async_in_port sync_in_port sync_out_port async_out_port (a) Port classification hierarchy 2 Abstract family entities are semantically analogous to abstract base classes in C++. These entities cannot be instanciated, but can be inherited by concrete (or other abstract) entities.

9 family port is classification REALISATION => abstract ABSTRACTION => port_class data : data_type default signal relation component_binding is domain component range component cardinality 1:N relation init_sync_trans is domain sync_out_port range sync_in_port cardinality 1:1 relation serv_sync_trans domain sync_in_port range sync_out_port cardinality 1:N family application_component is classification REALISATION => abstract ABSTRACTION => component persistent_state : boolean default false image : run_time_state parts IN_PORTS : class in_port OUT_PORTS : class out_port (b) PCL declarations Figure 4 Building blocks for reconfiguration modelling A further abstract family entity, application_component is provided from which application components are derived. application_component declares two common to all components: a boolean attribute, persistent_state to indicate whether persistent state is held in a component, and image which stores the dynamic run-time data maintained by the dynamic configuration manager. In addition to the common, placeholders are provided for ports. The IN_PORTS and OUT_PORTS placeholders are used to specify the behaviour of a component in terms of transactions. Family entities associated with IN_PORTS are constrained to entities classified as in_port; such ports facilitate servicing an in-coming transaction. Similarly, family entities associated with the OUT_PORTS slot are constrained to entities classified as out_port. PCL is object-oriented so polymorphism can be exploited. The IN_PORT and OUT_PORT slots of component application_component constrain family entities associated with the slots to classifications in_port and out_port respectively. Any family entity classified as a sub-class of in_port, sync_in_port for example, may therefore appear as an IN_PORT slot value. We have constrained the inheritance semantics of family entities classified as component to strict subtyping: a component X is a subtype of Y if it provides at least the behaviour of Y [16]. During reconfiguration, a component instance of X can be used in place of Y. In the case of reconfiguration involving replacement of one component for another, replacement is only valid if the replacement component is a subtype of the component to be replaced. Inheritance is thus exploited to build a hierarchy of family entities which eases the task of determining compatibility between the components involved in a replacement reconfiguration. Inter-component binding expression is managed at two levels: component and port. The relation component_binding expresses a required binding between one component instance and one or more instances of another component. Once a component binding has been specified, it is necessary to define the legal binding of the two components in terms of their ports. A number of relations have been defined to specify port bindings with respect to the notion of a transaction. Figure 4(b) shows two such relations, init_sync_trans and serv_sync_trans. init_sync_trans is used to express a synchronous transaction, initiated by a component s domain argument port, and serviced by a component s range argument port. The cardinality of init_sync_trans is restricted to a 1:1 mapping because it is not pragmatic to initiate a synchronous transaction to more than one recipient; problems arise with matching requests with replies. Relation serv_sync_trans is used to express a synchronous transaction, which is serviced by a component s domain argument port, and initiated by a component s range argument port. Similar relations exist for asynchronous transactions. 4 Example: Patient Monitoring System

10 The purpose of this section is to clarify our work. We use a variation on the patient monitoring system (PMS); an example which is both illustrative of our abstraction work, and which has been used in the past [7, 13]. The PMS is characterised by a ward which is composed of a number of nurse and bed monitor instances. Each nurse is responsible for managing a maximum of three bed monitors. The maximum number of nurses and bed monitors in the ward are constrained respectively to five and fifteen. For each bed monitor, the responsible nurse periodically requests patient data (blood pressure, pulse and temperature for example). A bed monitor raises an alarm to its responsible nurse if patient readings are abnormal. The configuration changes when: a nurse wishes to leave the ward. A nurse is only permitted to leave if all monitors the nurse is responsible for can be managed by other nurses; a data logger instance is introduced which similarly to nurse instances, requests patient readings from bed monitors. This information is used to build a history database. An enhanced nurse is then introduced which communicates with the data logger to query the history of a particular patient. All nurse instances should be upgraded. 4.1 Application modelling The PMS application is initially modelled by three main components: nurse, monitor and ward. According to the inheritance semantics of PCL, each of these components is a strict subtype of the abstract family entity, application_component. Evolutionary change subsequently requires the introduction of the data_logger and new_nurse components. Figure 5 shows the fundamental PCL declarations. A diagrammatic representation of the configuration evolution is presented in figure 6. nurse declares that it is a state repository; persistent state might for example record when monitors were last serviced. The transactions of nurse, modelled in the port placeholders are enumerated; if, for example, a nurse is responsible for two monitors, it has two alarm ports, one for each monitor. The constraint that a nurse may not be responsible for any more than 3 monitors is captured by monitors, a variability control attribute of nurse. new_nurse exts the behaviour of its super-family, nurse by adding the capability to initiate a patient history transaction. history_out is assumed to be classified as a sync_out_port port. family inherits port is classification REALISATION => concrete ABSTRACTION => sync_in_port data = patient_data family data_out inherits is classifications ABSTRACTION => sync_out_port family quit inherits invoke_reaction is classification REALISATION => concrete action = removal family nurse inherits application_component is classification REALISATION => concrete persistent_state = true monitors : integer range 0..3 parts IN_PORTS => alarm_in [monitors] OUT_PORTS => data_out [monitors], quit family generic_monitor inherits application_component is classification REALISATION => concrete parts IN_PORTS => OUT_PORTS => family monitor inherits generic_monitor is relationships CB1 : component_binding => (nurse) PB1 : serv_sync_trans =>, (nurse.data_out) PB2 : init_async_trans =>, (nurse.alarm_in) family ward inherits application_component is classification REALISATION => concrete nurses : integer range 0..5 monitors : integer range parts NURSES => nurse [nurses]

11 MONITORS => monitor [monitors] (data_logger.history_in) family data_logger inherits application_component is classification REALISATION => concrete persistent_state = true parts IN_PORTS => history_in OUT_PORTS => data_out ['monitors] family new_nurse inherits nurse is parts OUT_PORTS => history_out relationships CB1 : component_binding => (data_logger) PB1 : init_sync_trans => history_out, Figure 5 PMS declarations in PCL family new_monitor inherits monitor is relationships CB2 : component_binding => (data_logger) PB3 : serv_sync_trans =>, (data_logger.data_out) family logged_ward inherits ward is parts DATA_LOG => data_logger [1] NURSES => new_nurse [nurses] MONITORS => new_monitor [monitors] The generic_monitor component represents a monitor and specifies its interface. A generic_monitor instance can initiate an asynchronous alarm transaction on port, and can service a data request transaction on port. generic_monitor is context indepent; it does not express any structural constraints and so is reusable in many different configurations. Inheritance allows a component to be derived from a context indepent component to establish the derived component in a particular configuration context. Family monitor inherits generic_monitor; monitor is a strict subtype of generic_monitor where a structural constraint has been added. The constraint, CB1, specifies that each instance of monitor must be bound to a nurse instance. The binding in terms of ports is specified by PB1 and PB2. Component data_logger is introduced during evolution of the PMS system. The family descriptions of nurse and monitor have to be revised to express the new structural constraints of the configuration. Each new_nurse and new_monitor instance must be bound to the data_logger. The implementation of component new_nurse must augment the implementation of nurse with port history_out, and the associated behaviour to request patient history information. The implementation of monitor however can be used for new_monitor, as the behaviour of new_monitor is identical to monitor; only its structural requirements have changed. Family ward is a composite component, which represents the PMS system. Two variability control are defined, nurses and monitors, which store the number of nurses and monitors in the system respectively. The NURSES slot stores an array, constrained in size to nurses of nurse instances. MONITORS similarly stores an array of monitor instances. Family logged_ward introduces exactly one instance of the data_logger component. 4.2 Reconfiguration expression Our model for (re)configuration is uniform: initial application configuration and subsequent reactive and evolutionary changes are managed through specifying version descriptions (figure 2). Expressing reconfiguration as a new system description is fundamentally different from other research which has expressed reconfiguration in terms of changes to the existing configuration. All static variability must be removed to specify a new system instance. The version description in figure 7, named initial_pms removes all static variability by providing values for all variability control of family ward. Figure 6(a) shows in diagrammatic form, the initial PMS configuration. In addition to static variability, the application specification captures the dynamic variability of an application. Recall that dynamic variability is the set of all possible configuration states of which an application may assume one at any particular time during execution. For evolutionary change, there are two cases to consider:

12 simple case. A version description is submitted which causes a configuration state transition according to the constraints modelled in the application specification. general case. Change may require the application specification to be evolved prior to specifying a version description to effect a state transition. Reactive change is constrained to the simple case of evolutionary change. Reactive change is thus restricted to selecting a particular configuration state from the set of states specified by dynamic variability. It is neither pragmatic, nor appropriate for a reactive change to evolve the application specification. Changes to the application specification require developers to reason about the effects of specification changes. We have found component addition, removal, replication, replacement and migration sufficient for reactive change. nurse[1] nurse[2] nurse[3] alarm_in[1] data_out[1] alarm_in[2] data_out[2] alarm_in[1] data_out[1] alarm_in[2] data_out[2] alarm_in[1] data_out[1] alarm_in[2] data_out[2] monitor[1] monitor[2] monitor[3] monitor[4] (a) Initial configuration: ward nurse[1] nurse[2] alarm_in[1] data_out[1] alarm_in[2] data_out[2] alarm_in[1] data_out[1] alarm_in[2] data_out[2] monitor[1] monitor[2] monitor[3] monitor[4] (b) Configuration after reactive change: ward new_nurse[1] new_nurse[2] data_logger history_out alarm_in[1] data_out[1] alarm_in[2] data_out[2] history_out alarm_in[1] data_out[1] alarm_in[2] data_out[2] history_in data_out[1] data_out[2] data_out[3] data_out[4] new_mon'r[1] new_mon'r[2] new_mon'r[3] new_mon'r[4] (c) Configuration after evolutionary change: logged_ward Transaction invocation: asynchronous synchronous Figure 6 PMS configuration evolution

13 The event of a nurse leaving the ward in the PMS application is modelled as a reactive change. Component nurse (and therefore new_nurse because it is a subtype of nurse) declare an invoke_reaction port, quit. invoke_reaction is a reconfiguration port ultimately derived from the abstract family entity port. Reconfiguration ports are implicitly bound to the dynamic configuration manager and declare new deping on the type of reactive change. An attribute common to all reconfiguration ports is action, which describes the type of structural change. The values of action are restricted to the structural changes identified above for reactive change. In the case of a nurse leaving the ward, the action attribute of port quit is assigned the value removal. version initial_pms of ward is nurses := 3 monitors := 4 nurse.monitors := (others => 2) relationships CB1 : component_binding => nurse[1], (monitor[2], monitor[2]) CB2 : component_binding => nurse[2], (monitor[3]) CB3 : component_binding => nurse[3], (monitor[4]) version ward_nurse[3]_quit inherits initial_pms of ward is nurses := 2 relationships CB2 : component_binding => nurse[2], (monitor[3], monitor[4]) CB3 : null Figure 7 Version descriptions version data_logged_ward inherits ward_nurse[3]_quit of ward_data_logger is relationships CB1 : component_binding => new_nurse[1], (monitor[1], monitor[2]) CB2 : component_binding => new_nurse[2], (monitor[3], monitor[4]) CB3 : component_binding => data_logger, (new_nurse[1], new_nurse[2], monitor[1], monitor[2], monitor[3], monitor[4]) Invocation of reactive change causes the dynamic configuration manager to generate a new version description using the version description generator tool. Reactive change expressions are robust to evolution as a consequence of the uniformity of all reconfiguration being managed by submission of version descriptions. The version description, ward_nurse[3]_quit in figure 7 is generated in response to nurse[3] requesting to leave, which results in the configuration shown in figure 6(b). Evolving the PMS application by introducing a data logger and an enhanced nurse which is able to communicate with the data logger is a case of general evolutionary change. The application specification must evolve by modelling the two new components and recording the new composition structure of ward. The version description for the new configuration, data_logged_ward simply inherits the version description, ward_nurse[3]_quit. Both version descriptions, initial_pms and data_logged_ward explicitly express component bindings. This can however be automated by the configuration manager. For reactive change, the version description generator tool has to be responsible for defining a correct component configuration; a configuration which satisfies the structural constraints. The constraints regarding the new system are embedded in the application specification. data_logged_ward must however be applied to the new ward component logged_ward. This abstract method of reconfiguration can be contrasted to the reconfiguration expression of figure 1: a low level change program. 4.3 Control Abstract reconfiguration expressions are amenable to automated processing. Version descriptions must be checked to ensure that all static variability has been removed, and any constraints expressed in the application specification are not violated. In the event of violation, the version description is invalid and rejected. Assuming a valid version description, it is the responsibility of the model to ensure that the transition from the current configuration to the proposed configuration is correct. Essentially, a comparison is made between the current and proposed version

14 descriptions to identify changes. For the set of identified changes, reconfiguration must be synchronised with the application and persistent state managed. From the PMS problem description, an invariant states that every monitor instance must be connected to a nurse instance. In the case of a nurse leaving the ward, the version description generated (ward_nurse[3]_quit) must be checked to determine that the number of nurse[3] s patients does not exceed the available capacity of the remaining nurses. In this case, all constraints are satisfied, and reconfiguration proceeds. The control element of our model is responsible for deriving an efficient reconfiguration strategy. For example, one change identified between the current and proposed configuration states, described by the ward_nurse[3]_quit and data_logged_ward version descriptions respectively is that all nurse instances should be replaced by new_nurse instances. There may be several nurse instances distributed throughout the application configuration. If the tasks of identifying each instance, defining a consistent application state for reconfiguration and managing the bindings of each instance were left to the individual administering change, there is a real risk of effecting transition to an invalid configuration state, and losing application consistency. In our model, these operations are executed automatically and invisibly to change administrators. Greater efficiency can be gained by exploiting parallelism. The model for synchronising reconfiguration with the application is a hybrid of ACM and PCM. For our model of synchronisation, we require that reconfiguration states can be reached in bounded time. Further we would like to keep application disturbance minimal, and remove the need for application contribution. We have selected to specify reconfiguration states in units of transactions (like ACM), because transactions are easy to reason about and are meaningful at the application level. To reduce application disturbance, we offer an alternative definition for quiescence. For non-composite components, a component is quiescent if it conforms to Kramer's definition of passivity. In essence, we have removed the restriction that a component cannot have any transactions awaiting processing (i.e. messages queued in its inports). For composite components, as a consequence of all member components being passive, the composite itself then complies with Kramer's definition of quiescence. For non-composite components, we have reduced disturbance by allowing ping transactions to be preserved as persistent state during reconfiguration. We feel this to be generally satisfactory. For example, consider the nurse enhancement scenario. By treating any ping transactions (alarm messages) as persistent state, the enhanced nurse can process them proceeding reconfiguration. Through the use of strict subtyping, we are assured that the messages held will be compatible with the enhanced nurse. Rather than placing the responsibility for reaching a quiescent state in application components, we have adapted PCM to work with our transaction-based synchronisation model. The synchronisation algorithm begins by identifying the set of components involved in reconfiguration. The set of components is susped before the states of all outports of the component set are accessed. Port usage data is recorded in the application image. All outports which are currently not in use are blocked. Execution is resumed until one of the components involved uses an outport. The part of the algorithm between port state access to execution resumption is repeated until all outports have been blocked. All components are then quiescent and held in this state for the duration of reconfiguration. When a component attempts to s a message on a blocked outport, the s primitive fails. Application components are aware of failure by querying a status flag. Transactions can then be postponed or aborted, deping on the application semantics. This is the only contribution required of application components, and is no more than good practise in a distributed environment. Finally, persistent state is managed by adopting Herlihy's ADT state capture and restoration model [4]. The nurse and data_logger components of the PMS application declare that they are state repositories. The implementations of such components are assumed to offer the capture and restore services for state extraction and initialisation. These operations are used to preserve state during reconfiguration (they are not available to other application components). However, we appreciate that managing persistent state is not as simple as we might have inferred. Reconfiguration involving component removal currently discards all persistent state (in the components to be removed and their associated bindings). Although satisfactory in the case of a nurse leaving the ward, there are scenarios involving component removal where discarding state is not acceptable, for instance when a components holds a lock to a shared resource. Further, we have assumed that persistent state encapsulated in a sub family entity is a subtype of the

15 persistent state encapsulated in its parent family entity. This is generally not a realistic assumption. In other scenarios, the rationale behind a component enhancement might be to use a superior data structure. This reinforces the need to explore management of persistent state further in future work. 5 Discussion and Conclusions The use of an application model to which version descriptions can be applied to manage reconfiguration while preserving application consistency characterises our research. We are aware of few research efforts aimed at providing abstraction support for dynamic configuration. Surgeon [14] however shares similar objectives to us, and achieves some abstraction support using packaging technology. Hofmeister defines packaging to be the automatic preparation of software. For every reconfigurable component in a Surgeon application, a catalyst is generated. At run-time, a catalyst is responsible for managing replication and replacement of the component to which it is associated. Change administrators are provided with an abstract interface comprising only replication and replacement commands. Administrators are thus shielded from the primitive command set of the underlying configuration language. However, Surgeon only generates catalyst skeletons; application developers are still responsible for coding the actual replicate and replace change programs. Further, in the interests of simplicity, Surgeon does not attempt to maintain application consistency. Recently, notations for expressing permitted configuration structures generically, according to properties or have been recognised as desirable. Not only is an alternative needed to explicit naming of components for facilitating reactive change expressions which are robust to evolution, but for concise configuration descriptions. Predicate logic, for example is an extremely powerful and expressive notation which has been adopted by Gerel [7] and RCMS [15]. We have used relationships and enumeration of component instances based on to govern configuration evolution. Although, less expressive than predicate logic, our model, unlike predicate logic requires no formal training to use. However, a problem we have found with our approach is managing component binding changes. For example, consider the PMS example of section 4. Expressing a constraint such as monitor instances should be distributed evenly to nurse instances (a form of load balancing) is difficult. The compatible integration of reactive and evolutionary change is exhibited by our model. Endler [7] and Young [8] have tackled this problem with logic based approaches. Our approach to this objective is uniform. Once reactive change has been invoked, it is managed by the generation and submission of a version description. PCL is an object-oriented configuration language. We feel it is advantageous to reap the benefits of object orientation at the Configuration level. Inheritance is well suited to configuration languages but we are not aware of any attempts to integrate object orientation with the Configuration paradigm. Our own experiences have shown that with strict subtyping inheritance semantics, reconfiguration involving component replacement is straight forward. In addition to using inheritance for subtyping, it has led to concise reusable descriptions. In Section 3, we introduced the notion of analysis support for reconfigurable applications. Reachability of reconfiguration states is assured as a product of our reconfiguration synchronisation mechanism. Further work has to be done on measuring the degree of inter component coupling and change impact assessment. For the latter, we int to consider phased reconfiguration, where change would cause excessive disturbance if executed atomically. Other analysis work will be aimed at examining application specification changes which contradict the current configuration state of an application. The reconfiguration control element of our model has largely been implemented, but further research is required regarding the role and management of persistent state. Ideally, we would like to preclude explicit application contribution when addressing this problem. The concept of a model through which to manage (re)configuration offers some interesting possibilities. For example, in addition to structural constraints, resource constraints could be modelled. It would then not be possible for example, to migrate a component to a processor which does not have access to devices required by the component. The model could also assist with application development. Rather than a constructive approach to application development from a library of component implementations, the application specification could be used to generate C++ class skeletons for components. Finally integrated documentation support for recording change rationale would allow developers to trace evolution.