T. Bloom and M. Day. Reconfiguration and module replacement in Argus: Theory and Practice, IEE Software Engineering Journal, vol 8, no 2, March 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... common mechanisms for updating in di#erent languages, whether functional, object oriented, or imperative There are quite a number of DSU implementations (e.g. 2, 13, 16, 9, 19, 15, 6, 14] among others) and many informal or incomplete ideas as to when a dynamic update should be considered safe [12, 3, 4, 16, 13]. However, we believe a formal, mathematical approach, with clear operational semantics, should be developed to set a firm foundation for both users and implementors of DSU technology. Unfortunately, little semantic work has been carried out to date. The most substantial work is by Gupta [11, 12] ....

....easy to determine (e.g. if the types of functions change) but in others it is not straightforward. Furthermore, a valid update must be known before it can be deconstructed, but no guidance is provided in finding such an update. Bloom et al. develop a similar, but more complicated, model for Argus [3, 4]. A number of researchers have observed that dynamic updates can become invalid if they are applied at an inopportune time. Assuming that an update can become available at any time, rather than perform the update at that moment, 14 the update can be delayed until certain conditions are ....

T. Bloom and M. Day. Reconfiguration and module replacement in Argus: theory and practice. Software Engineering Journal, 8(2):102--108, March 1993.

....for pervasive dependability. The major questions that we are addressing in this context are how one performs (1) self configuration, 2) self tuning, and (3) selfdiagnosis (see Section 3) There has been a large body of work addressing the issue of reconfiguration of component based systems [2, 3, 12, 14, 17, 18, 22]. However, with the possible exceptions of [12, 18] which provide (non trivial) automatic reconfiguration of pipelined applications, all of these approaches require an amount of user (or system administrator) involvement that is inappropriate for pervasive dependable systems. When addressing this ....

T. Bloom and M. Day. Reconfiguration and module replacement in argus: theory and practice. Software Engineering Journal, 8(2):102--108, 1993.

....oriented systems for pervasive dependability. The major questions that we are addressing in this context are how one performs (1) selfconfiguration, 2) self tuning, and (3) self diagnosis. There has been a large body of work addressing the issue of reconfiguration of component based systems [2, 3, 10, 12, 15, 16, 20]. However, with the possible exceptions of [10, 16] which provide (non trivial) automatic reconfiguration of pipelined applications, all of these approaches require an amount of user (or system administrator) involvement that is inappropriate for pervasive dependable systems. When addressing this ....

T. Bloom and M. Day. Reconfiguration and module replacement in argus: theory and practice. Software Engineering Journal, 8(2):102--108, 1993.

....of dynamic reconfiguration known as dynamic module replacement that enables the implementation of a component to be hot swapped at runtime. Existing solutions have various shortcomings that limit their scope of applicability and deployment. For example, the approaches taken by CONIC [12] ARGUS [2], and POLYLITH [8] are coupled to particular research languages that generally lack support for mainstream software development. Other solutions have targeted development languages, but at a cost: HADAS [1] for Java) requires integrated tool support at runtime; dynamic Java classes [13] ....

....reflection to provide an easy approach to dynamic module replacement. 4 Implementing Mutual Exclusion using the Serf approach Previous treatments of dynamic module replacement have focused almost exclusively on containers for encapsulating data structures(such as queues, stacks, and maps) [2]. Unfortunately, this peculiar emphasis on data containers has underestimated and perhaps mis characterized the full power of module replacement. The first contribution of this Due to lack of space, we have presented only the key aspects of our implementation of the resource manager ....

T. Bloom and M. Day. Reconfiguration and module replacement in argus: Theory and practice. IEE Software Engineering Journal, 8(2):102--108, mar 1993.

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

....approaches that work with a driven safe state fall into two major categories [10] those in which during reconfiguration interactions are aborted and that rely on entities to recover from abortions, and those which avoid interactions to be aborted. Mechanisms based on interaction abortion (e.g. [ 1 ]) require the application developer to provide rollback mechanisms to recover from abortions without proceeding to errors. Therefore, the range of applications to which these mechanisms can be used is quite limited. We have studied mechanisms that do not abort interactions. These mechanisms are ....

T. Bloom, M. Day, Reconfiguration and module replacement in Argus: Theory and Practice, IEE Software Engineering Journal, vol 8, no 2, March 1993.

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

T. Bloom and M. Day. Reconfiguration and module replacement in Argus: Theory and Practice, IEE Software Engineering Journal, vol 8, no 2, March 1993.

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

....approaches that work with a driven safe state fall into two major categories [10] those in which during reconfiguration interactions are aborted and that rely on entities to recover from abortions, and those which avoid interactions to be aborted. Mechanisms based on interaction abortion (e.g. [1]) require the application developer to provide rollback mechanisms to recover from abortions without proceeding to errors. Therefore, the range of applications to which these mechanisms can be used is quite limited. We have studied mechanisms that do not abort interactions. These mechanisms are ....

T. Bloom, M. Day, Reconfiguration and module replacement in Argus: Theory and Practice, IEE Software Engineering Journal, vol 8, no 2, March 1993.

....in allowing parts of the application (and the run time itself) to be modified, for example using meta object protocols) However the challenge of this work has been to provide flexible mechanisms for allowing types to be changed at run time, while ensuring type safety. The Argus system [43, 5, 4] provided some support for updating a running system, using guardians, however versioning was largely of the nature provided by object oriented languages, and support mainly focused on properly terminating transactions. Evans and Dickman [22] describe an approach to managing multiple versions of ....

T. Bloom and M. Day. Reconfiguration and module replacement in Argus: Theory and practice. Software Engineering Journal, 8(2):102--108, 1993. 20

....concerning an updating 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 ....

....However, they show that if certain conditions are met as to when a change may take place and what state transforming functions S may be used, then validity can be proved formally; we describe these conditions below. Bloom et al. develop a similar, but more complicated, model for Argus [Blo83, BD93] Because no automated means of generally determining a valid update time is possible, previous researchers have developed techniques to identify program patterns that have valid update points. Perhaps the most advanced was developed by Gupta et. al ; it compares the old and new versions of C ....

[Article contains additional citation context not shown here]

Toby Bloom and Mark Day. Reconfiguration and module replacement in Argus: theory and practice. Software Engineering Journal, 8(2):102--108, March 1993.

.... these changes do not violate the integrity of the system, we adopt a general model of dynamic configuration that only permits change to occur when the affected portions of the system are quiescent [17] A number of other models of dynamic architectural (configuration) change have been proposed [1,3,5,28,31,35]. However, these models either restrict the kind of change handled to replacement or enhancement only (Agnew [1] or impose restrictions on the architectural style, such as components are connected by a broadcast bus in a particular hierarchical style (Oreizy [31] or using atomic transactions ....

.... these models either restrict the kind of change handled to replacement or enhancement only (Agnew [1] or impose restrictions on the architectural style, such as components are connected by a broadcast bus in a particular hierarchical style (Oreizy [31] or using atomic transactions (Bloom [5]) In our view, the change model in [17] remains the most general basic approach indicating the conditions necessary for change. Some extensions of this basic approach have been proposed so as to minimise the disturbance (MoazamiGoudarzi [28] Wermelinger [35] to the system. The role of ....

Bloom, T and Day, M, Reconfiguration and module replacement in Argus: theory and practices, IEE Software Engineering Journal, Special Issue on Configurable Distributed Systems, Vol. 8, No. 2, March 1993, 102-108.

....to be consistent when a module reaches a reconfiguration point. When a programmer introduces a reconfiguration point, he must define how module consistency can be preserved. As a consequence reconfiguration mechanisms are not transparent to programmers. Retrieving a consistent state Argus [8] follows another approach in which the operating system provides support to the addition, deletion and substitution of specific objects called Guardians. Reconfiguration can only occur when the state of guardians is stable and consistent. A consistent statecan be reached at any time by rolling ....

Bloom. T., Day M., "Reconfiguration and module replacement in Argus : theory and practice", Software Engineering Journal, March 1993, pp.102-108.

....supports some changes to the structure of an application as objects can migrate around the system, although to migrate a process would require substantial intervention by the software engineer. 8.3 Argus Argus [Lis88] is a language and system for building reliable distributed applications. In [BD93] the authors describe work done on supporting system reconfiguration in Argus. Argus programs are constructed from a collection of guardians. Guardians are abstract computational nodes that encapsulate a resource or data. A guardian s interface to other guardians is a collection of remotely ....

....a crash, some of a guardian s state is designated as stable and must remain consistent across node and media failure. Argus uses a nested transaction system [Mos85] to maintain consistency in the presence of distributed system failures. Two approaches to system reconfiguration are described in [BD93] however only their system supported replacement will be considered as it has the most in common with the approach taken in DRASTIC. System supported replacement in Argus allows any active guardian to be replaced by a different guardian. This replacement involves handlers having an additional ....

[Article contains additional citation context not shown here]

T. Bloom and M. Day. Reconfiguration and module replacement in Argus: Theory and practice. IEE Software Engineering Journal, 8(2):102--108, March 1993.

....unlink, link, and passivate, corresponding to the three types of module participation listed above. There are other distributed environments that support limited reconfiguration, namely replacement, and these also require the programmer to provide module participation. Durra [5] 6] and Argus [7] have facilities for incorporating fault tolerance into an application, and they use these facilities to help support dynamic reconfiguration. But even with these facilities, module participation must be written by the programmer in order to perform reconfiguration. In Durra, module participation ....

T. Bloom, M. Day, "Reconfiguration and Module Replacement in Argus: Theory and Practice, " IEE Software Engineering Journal, vol. 8, no. 2, pp. 102-108, March 1993.

No context found.

T. Bloom and M. Day. Reconfiguration and module replacement in Argus: Theory and Practice, IEE Software Engineering Journal, vol 8, no 2, March 1993.

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