J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, 11 (4), 1985.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Another approach is called forced validity [9] Upon the detection of constraint violation, the faulty data value is reset to a valid value. Dynamic Reconfiguration Distributed real time systems require the possibility for onthe fly configuration and maintenance without a system shut down [10]. This allows the accommodation of the system to evolutionary changes, which is especially important for networks with a long expected lifetime. Desired Interface Properties This section elaborates on desired properties of interfaces for smart transducer networks. Temporal Composability In a ....

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, 1985.

....3 Module Replacement with Serfs This section outlines five sufficient factors for supporting dynamic module replacement, and describes how Serfs satisfy these prerequisites. Previous research has explored other factors pertaining to the safety and semantic correctness of module replacement [9, 8]. A mature reconfiguration strategy should address these additional factors such as protection, security, and substitution consistency. Ultimately, however, all approaches must supply a sufficient infrastructure for effecting the module replacement itself. Our concern is to supply such a ....

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE TSE, SE-11(4):424--436.

....and structural dynamic reconfigurations [8] Functional reconfiguration involves new code being added to an application, while structural reconfiguration is topological in nature. Again, Lira supports both. Several researchers, including Almeida et al. 1] Bidan et al. 4] Kramer and Magee [18], and Wermelinger [25] have tried to address the problem of maintaining consistency during and after a reconfiguration. Usually, the consistency properties of the system are expressed through logical constraints that should be respected, either a posteriori or a priori. If the constraints are ....

J. Kramer and J. Magee. Dynamic Configuration for Distributed Systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, April 1985.

....for the validity of a static analysis. In non critical real time system software, dynamic debugging and testing may be preferred due to lower cost and complexity. Distributed real time systems require the possibility for on the fly configuration and maintenance without a system shut down [Kra85]. This allows the accommodation of evolutionary changes of the system, which is especially important for networks with a long expected lifetime. Configuration is aided by electronic data sheets that contain all relevant information of a transducer [Lee00] This information is located on the chip ....

J. Kramer and J. Mageee. Dynamic Configuration for Distributed Systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, 1985.

....install, remove, and retire (e.g. Castanet, InstallSheild [7] netDeploy [12] and RPM [1] but none that covers all the activities. Research prototypes have made strides at addressing dynamic reconfiguration, but are generally conceived within restricted or specially structured architectures [2, 8, 9, 11]. In this paper we present our attempt at improving support for the activities of reconfigure, adapt, and update. Although the context and drivers for these three activities di#er substantially, they clearly share many of the same technical challenges with respect to the correct and timely ....

J. Kramer and J. Magee. Dynamic Configuration for Distributed Systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, April 1985.

....percent generator failures. tolerance to users in the Eternal system, middle ware that operates in a CORBA environment, below a CORBA ORB but on top of their Totem group communication syst em[21] CONIC, a language and distributed support system, was developed to support dynamic configuration [17]. Darwin is a configuration language that separates program structure from algorithmic behavior [20] Darwin utilizes a component or object based approach to system structure in which components encapsulate behavior behind a well defined interface. Darwin is a declarative binding language that ....

Kramer, J. and J. Magee. "Dynamic Configuration for Distributed Systems," IEEE Transactions on Software Engineering, Vol. SE-11 No. 4, April 1985, pp. 424-436.

....on most issues, concepts, and terminology. The notable exception is some consensus on the structural properties of architectures, which lead to the development of the architecture interchange language ACME [GMW97] 1. 3 Issues There are several issues involved in reconfiguration, as discussed in [KM85, KM90, Ore96, Wer98c, MG99] We let aside technological issues (like the necessary support from the operating system and the component programming language) and classify and summarise the remaining ones as follows. time Architectures may change 1. before compilation, 2. before execution, or ....

....understandable, and analysable. In particular, the changes should be verifiable against the constraints. They also should be modular to allow compositional specifications. management The reconfiguration process may be managed in an explicit and centralized manner by a configuration manager [KM85] also called architecture evolution manager [OT98] coordinator [Met98] or configuror [ADG98] or management is implicit and distributed among the components. The latter case has been called self organising architectures [MK96b] The configuration manager translates the AML specification into ....

[Article contains additional citation context not shown here]

Jeff Kramer and Jeff Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, 11(14):424--435, April 1985.

....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 ....

....relations exist for asynchronous transactions. 4 Example: Patient Monitoring System 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 ....

Kramer, J. and Magee, J. Dynamic Configuration for Distributed Systems. IEEE Transactions on Software Engineering. 11(4):424-435. 1985.

....further incremental loading steps are controlled by the entity server and performed by the load server. 5. 2 Configurations For instantaneous loading as well as for incremental loading of a distributed application several data bases are interpreted, which contain cotfiguratiot specifi catiotas [8]. They can be obtained by the compilation of a corresponding cotfig uratiot descriptiot written in the PSACS system configuration language AIDA [19] The entity server and the name usher input their part of the specification upon startup. AIDA provides language constructs to produce logical and ....

J. Kramer, J. Magee "Dynamic Configuration for Distributed Systems", IEEE Transactions of Software Engineering, Vol. SE-11, No. 4, April, 1985

....these systems provide. They have high availability, adaptability and maintainability requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at ran time [8] as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the ....

.... requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at ran time [8], as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the moment they are envisioned as programmed and ....

[Article contains additional citation context not shown here]

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering 11 (4), pp. 424-436, April 1985.

....system is determined by its downtime due to various types of maintenance. In practice, a reconfiguration implies that the system needs to be taken offline and restarted after installation of new software components. The downtime due to maintenance can be avoided by using dynamic reconfiguration [1, 3, 4, 5, 7, 9, 10 , 11 , 13 , 20 , 25], i.e. the system can be maintained or upgraded without being taken off line. The aim of dynamic reconfiguration is to allow a system to evolve at run time [9] as opposed to designtime, while introducing little (or ideally no) impact on the system s execution. In this way, the system does not ....

....components. The downtime due to maintenance can be avoided by using dynamic reconfiguration [1, 3, 4, 5, 7, 9, 10 , 11 , 13 , 20 , 25] i.e. the system can be maintained or upgraded without being taken off line. The aim of dynamic reconfiguration is to allow a system to evolve at run time [9], as opposed to designtime, while introducing little (or ideally no) impact on the system s execution. In this way, the system does not have to be taken off line to accommodate changes. We distinguish two types of changes, related to the moment they are envisioned [11] programmed changes are ....

[Article contains additional citation context not shown here]

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering 11(4), pp. 424-436, April 1985.

....been argued that introduction of the computing system is itself a stimulus for change [29] 3 their design and implementation. Building flexible software systems, in the sense that required change management needs have been already provided for, has been an important issue in software engineering [24, 25]. Principal proposals that identified collaboration requirements and developed mechanisms to program needed collaborations came from systems such as, Conic, Podus, Polylith and PCL [25, 41, 19, 44] All proposed solutions assumed that to achieve management flexibility in a system one must ....

....the use of observation and control for transparent dynamic reconfiguration of application systems in various situations. We also use these examples to compare RESTCLK solutions for dynamic reconfiguration with solutions proposed in other systems like polylith [19, 38, 21, 22, 20, 5] and conic [25, 27, 26, 24]. These two are the only other significant systems that we are aware of, which propose novel communication systems organization that facilitate dynamic system reconfigurations of the kinds discussed here. The examples discussed in this chapter will illustrate clearly the benefits gained by using ....

[Article contains additional citation context not shown here]

J. Kramer and J. Magee. Dynamic Configuration for Distributed Systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, 1985. 176

....for the validity of a static analysis. In non critical real time system software dynamic debugging and testing may be preferred due to lower cost and complexity. Distributed real time systems require the possibility for on the fly configuration and maintenance without a system shut down [8]. This allows the accommodation of evolutionary changes of the system, which is especially important for networks with a long expected lifetime. Configuration is aided by electronic data sheets that contain all relevant information of a transducer [9] This information is located on the chip in ....

J. Kramer and J. Mageee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, SE-11(4):424--436, 1985.

....these systems provide. They have high availability, adaptability and maintainability requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at run time [8] as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the ....

.... requirements, and, in order to remain useful, they have to cope with advances in technology, modifications of their operating environment and ever changing human needs [10] The aim of dynamic reconfiguration [8, 9, 7, 1, 4, 11, 2, 10, 14, 18] is to allow a system to evolve at run time [8], as opposed to design time, while introducing little (or ideally no) impact on the system s execution. In this way, systems do not have to be taken off line, rebooted or restarted to accommodate changes. Changes can be classified with relation to the moment they are envisioned as programmed and ....

[Article contains additional citation context not shown here]

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering 11(4), pp. 424-436, April 1985.

....system. Table 2.1 summarizes our evaluation of past work on general purpose dynamic updating. The systems mechanisms we consider here are the following (presented roughly chronologically) dynamic linking (which exists for various languages) DYMOS [Lee83] Argus [Blo83, BD93] Conic [MKS89, MK85] PODUS [FS91, SF93] PolyLith [Hof93] Online Software Version Change (OSVC) GJ93, Gup94, GJB96] Erlang [AVWW96, Hau94] Dynamic ML [GKW97, WKG98] Dynamic C [HG98] Dynamic Java classes [MPG 00] DITools [SNC00] Guarded Software Updating (GSU) TTA 99, TTA 00] and DynInst ....

....replaced. Perhaps the largest lesson of Argus is that fault tolerance mechanisms for ensuring consistent state (i.e. transactions and general purpose persistence) can be leveraged to provide a form of dynamic updating, but at the cost of a greater implementation burden. B.3. 3 Conic Conic [MKS89, MK85] is a distributed programming system that allows distributed components of an application to be reconfigured. Like Argus applications, Conic applications consist of a number of processes distributed throughout the network that communicate through a well defined entry points. A process s ....

Je# Magee and Je# Kramer. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, 11(4):424--436, April 1985.

....CONIC, a language and distributed support system, was developed to support dynamic configuration. The language enabled specification of system configuration as well as change specifications, then the support system provided configuration tools to build the system and manage the configuration [44]. More recently, they have modelled a distributed system in terms of processes and connections, each process abstracted down to a state machine and passing messages to other processes (nodes) using the connections. One relevant finding of this work is that components must migrate to a quiescent ....

Kramer, J. and J. Magee. "Dynamic Configuration for Distributed Systems," IEEE Transactions on Software Engineering, Vol. SE-11 No. 4, April 1985, pp. 424-436.

....it avoids the cost of saving and restoring state information, and the cost of clients discovering stale addresses and rebinding to new processes. 123 7 Related Work Research into the dynamic configuration of distributed programs and systems has grown from a seminal paper by Kramer and Magee [40], in which the authors describe a system called CONIC, which permits dynamic incremental modification of a running system. CONIC contains (1) a configuration language that programmers can use to describe the interconnection among a program s modules, 2) a Pascal based programming language for ....

Kramer, J., and Magee, J., "Dynamic Configuration for Distributed Systems," IEEE Transactions on Software Engineering, Volume SE-11, Number 4, April 1985.

No context found.

K. Kramer and J. Magee, `Dynamic configuration for distributed systems', IEEE Trans. Software Engineering, SE-11, (4), 424--436 ( 1985).

....The MP environment has been available and in use by students within the authors research section since September 1991 and has recently been made available for undergraduate teaching. While MP inherits from Conic the concept of a separate configuration language and context independent components[16], it significantly extends the facilities offered in Conic in a number of ways. The most important of these extensions are firstly the provision of generic components and secondly the ability to accommodate more dynamic structures through the ability of processes to pass remote references in ....

Kramer, J., and Magee, J.(1985). "Dynamic Configuration for Distributed Systems", IEEE Transactions on Software Engineering, SE-11 (4), 424-436.

No context found.

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, 11 (4), 1985.

No context found.

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering, 11(4), 1985.

No context found.

Kramer J and Magee J: `Dynamic configuration for distributed systems', IEEE Transactions on Software Engineering, SE-11, No 4, pp 425---436 (April 1985).

No context found.

J. Kramer, J. Magee, "Dynamic configuration for distributed systems," IEEE Trans. Software Eng., vol. 11, pp. 424-436, 1985.

No context found.

J. Kramer and J. Magee. Dynamic configuration for distributed systems. IEEE Transactions on Software Engineering 11(4), pp. 424-436, April 1985.

No context found.

J. Kramer and J. Magee, `Dynamic configuration for distributed systems', IEEE Trans. Software Eng., SE-11, (4), 424--436 (1985).

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC