J. Callahan and J. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, pages 626--635, 1991.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of RESTCLK. These examples illustrate 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 ....

....practice cost very little in terms of additional delays incurred in communication, when compared to any other agent mediated communication system. Thus there is little or no overhead to using RESTCLK. 168 2. Development of tools, languages and environments for dynamic reconfiguration programming [38, 5, 1, 26, 27, 23, 30, 45, 14], and 3. New paradigm that allows a priori unplanned for dynamic reconfigurations. RESTCLK is the only work in this category. Works in the first category above brought the problem of dynamic reconfiguration into prominence and also proposed viable solutions to the problem which were widely ....

J. Callahan and J. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, pages 626--635, 1991.

....a component s interactive and functional concerns to be separated, it does so at the cost of making interaction a second class concern: the only interaction mechanism between components that he supports is sharing a Linda tuplespace. Closer in spirit to this work is that of Callahan and Purtilo [2]. Like Flexible Packaging, their system Nimble also allows a component to be accessed through different interaction mechanisms, restricted to members of a family: procedure call, cross language procedure call, and remote procedure call. This restriction allows them both to develop their equivalent ....

John R. Callahan and James M.Purtilo."A packaging system for heterogeneous execution environments." University of Maryland Technical Report cs-tr2542, 1990.

....for transmission of structured data over a network, with a possibly different data representation at the destination. Their method employs user written procedures to encode and decode the data into transmissible representations. They also describe a method for transmission of shared structures. [5] describes a system that automatically generates stub programs to interconnect processing modules that are in different languages or processors; this work is complementary to the techniques presented in this paper. The Common Object Request Broker Architecture (CORBA) 6] includes an Interface ....

J. Callahan and J. Purtilo, "A Packaging System for Heterogeneous Execution Environments," IEEE Trans. Software Engineering, vol. 17, no. 6, pp. 626-635, June 1991. 28

....use. While each addresses specific concerns and is a product of the era in which it was first designed, there is considerable commonality among the features they offer. Figure 2 (extended from [Bishop 1994] shows the range for some current languages [Magee 1994a] Barbacci 1993] Dobbing 1993] [Callahan 1991], Shaw 1995] Allen 1994] 3 Darwin Durra PCL Polylith UniCon WRIGHT process term process component = task or channel partition = RCI designated library unit module language dependent language dependent process language C plus library template classes Ada83 plus generic package Ada83 ....

....this: lock; transfer.in (X) X : X 1; transfer.out (X) unlock; 6. Related work The original MILs relied on procedure call for interaction, or as Garlan calls it: Definiton Use. Configuration languages conceived in the later eighties such as PCL [Dobbings 1993] Durra [Barbacci 1993] and Polylith [Callahan 1991] do not have connectors, but some do include a more general form of connection, such as the software bus [Purtilo 1994] The original form of Darwin that was based on Pascal [Magee 1993] provided only one kind of port, but in principal the new version based on C classes should enable a greater ....

J R Callahan and J M Purtilo, A packaging system for heterogeneous execution environments, IEEE Trans. Soft. Eng. 17 (6) pp 626-- 635 June 1991

....becoming known as configuration languages 1 . One of the first configuration languages was CONIC which grew out of engineering problem management in the early 1980s [20] At this stage there are more than 10 in existence, but we shall be considering four here: Darwin [17, 21] Durra [6] Polylith [9, 23] and PCL [1, 11] Several of the others are covered in individual papers collected in [18] B. Background to the systems Darwin is part of the Regis environment developed at Imperial College London. Regis s ancestors include the well used CONIC (begun 1981) which was followed by SONIC, TONIC ....

.... environment Polygen operates as a Prolog engine, and given the command 13 polygen m producer consumer will create a set of Prolog rules which can be matched against the stored set for the environment, and will a) confirm that a mapping is possible and b) generate the executables for it [9]. In Darwin, users may specify detailed mapping files, but this is no longer necessary. For interest s sake, we consider the previous version of Darwin running under Rex. Fig. 5 shows how we would distribute this very simple system onto two processors [17] There are two transputer T800 ....

J R Callahan and J M Purtilo, "A packaging system for heterogeneous execution environments", IEEE Trans. Soft. Eng. 17 (6) pp 626-- 635 June 1991

....its interactions with the control automaton. The transport automaton defines how to use for example the transmission or error control and the timers handling. The choice of a compiler is also described by [ WP93] The authors take the same approach, using two specification languages POLYGEN MIL[ CP91] for the interface definition and PROTEUS [ MNP 91] for the control specifications. But they do not have an interest in the communication aspects as transport and time specifications. And their aim is more oriented to modularity and reusability at the application level than at the ....

J. Callahan and J.M Purtilo. A Packaging System for Heterogeneous Execution Environments. IEEE Transactions in Software Engineering, 17(6):626-- 635, June 1991.

....partial evaluation to produce configurations 21 described by makefiles and scripts; it also employs abstract interpretation to answer queries about product feasibility. A knowledge based tool designed for multiparadigm configuration management is Polygen, a tool used in the Polilyth environment [29]. Polilyth allows the integration of distributed and heterogeneous software components. Polygen is a knowledge based tool written in Prolog used to generate the software interfaces needed to integrate and transform (for instance, to compile and link) the description of a software configuration ....

.... 56, 71, 82, 98, 99, 104, 115, 120, 133, 148, 170, 176, 177, 179, 188, 197] Design [8, 4, 38, 44, 63, 106, 109, 118, 147, 160, 162, 202] Editing and Compiling [10, 18, 48, 36, 78, 158, 136, 150, 194] Debugging and testing [21, 42, 46, 59, 67, 74, 76, 81, 92, 123, 154, 181] Maintenance and Reuse [23, 25, 26, 29, 30, 31, 66, 79, 110, 117, 193, 201, 7, 60, 93, 135, 142, 159, 174, 200] Figure 4: A classification of the projects and tools cited in this paper IF start working context THEN CALL(working context,R,W,X,Doc Type,Doc Name, New Status,Item) REMOVE(document(Doc Type,Doc Name, INSERT(document(Doc Type, Doc Name, New Status) REMOVE(start working context) IF ....

J. Callahan and J. Purtilo. A Packaging System for Heterogeneous Execution Environments. IEEE Transactions on Software Engineering, 17(6):626--635, June 1991.

....that all modules are available during system construction, and that module interfaces describe the other modules with which they interact. Newer work has begun to soften these restrictions. In the Darwin language, modules can be dynamically instantiated and bound at runtime [MDK93] Polygen [CP91] augments a module interconnection language with an inference engine that deduces from a user defined set of rules how (or whether) a system can be integrated from set of modules. These modules can be implemented in multiple programming languages, and the machinery needed to connect them can be ....

John R. Callahan and James M. Purtilo. "A Packaging System for Heterogeneous Execution Environments." IEEE Trans. on Software Engineering, 17(6): 626-635, June 1991.

....is used to provide some dynamic aspects. Unlike Schooner, however, such systems provide only limited support for heterogeneity and are not designed for integrating existing tools such as AVS with remote parallel computations. A similar system is described in [26] The Polylith [27] Polygen [28] and Surgeon [29] family of systems also supports heterogeneous interconnectivity of the type implemented by Schooner. Polylith provides a software bus that can be viewed abstractly as a backplane into which different software modules are plugged. It handles communication between ....

J. Callahan and J. Purtilo, `A packaging system for heterogeneous execution environments', IEEE Transactions on Software Engineering, 17(6), 626--635 (1991).

....components, and for controlling the computation during execution. Data transfer is based on the remote procedure call (RPC) paradigm and is done in such a way that heterogeneity is handled transparently to the user. Thus, in contrast with traditional configuration management 3 systems (e.g. [Callahan91, Purtilo94, Magee94]) Schooner is a communication subsystem with facilities for supporting the configuration requirements of scientific applications rather than a general high level tool for distributed programming. The most important aspects of Schooner from the point of view of supporting configuration and ....

....instantiation, where the creation of a component instance is avoided until actually needed. Schooner s approach differs in providing support for multiple languages and programming models, and in providing dynamic configuration abilities oriented towards scientific applications. The Polygen system [Callahan91] supports configuration through the use of a module interconnections language (MIL) Specification files for each module are created that are similar to the UTS specification files in Schooner. To configure an application, Polygen also uses a composite specification file that describes the ....

J.R. Callahan and J.M. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering 17, 6 (June 1991), 626-635.

....to avoid recompilation. However, DSEE was 131 primarily a CASE tool and did not take part in the execution phase of program development. The module language of OMOS is somewhat similar to architecture description languages, such as Rapide [44] the POLYLITH Module Interconnection Language (MIL) [12, 66], and OMG s Interface Definition Language (IDL) 60] These languages all share the characteristic that they support the flexible specification of high level components and interconnections. Our approach offers the important advantage that OO like program adaptation and reuse techniques ....

....scale well to arbitrarily large types, e.g. large structs; and (iii) we want to do not only type checking, but also useful adaptation during link time; hence we must utilize sophisticated linker technology. There is a plethora of literature related to stub generation[6, 5, 75] The Polygen system [12] is representative of automatic stub generation for programming in a heterogeneous environment. Polygen packages heterogeneous modules by utilizing a programmer defined specification of their interfaces and execution environments specified in a common module language. The packaging process ....

Callahan, J. R., and Purtilo, J. M. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering 17, 6 (June 1991), 626--635.

....that allow to dissociate the fault tolerance mechanism from its interconnections with the application, significantly assist to deal with failures. Such environments permit the programmer to declare in module interfaces the bindings between application operations and fault tolerance mechanisms [1], or to specify alternative execution paths in the case of failure [2] However, the programmer is still concerned with the use of specific fault tolerance mechanisms, while from the application standpoint it is sufficient to specify the behavior that the execution environment should exhibit when ....

J. R. Callahan and J. M. Purtilo. A Packaging System for Heterogeneous Execution Environments. IEEE Transactions on Software Engineering, 17(6), 1991.

....a large program became too great, our research field quickly shifted to building systems of smaller components instead. This was enabled by the use of module interconnection languages and by technology for integrating those components [3] 5] 12] 28] 35] 41] In particular, software packaging [4] that is, reasoning about compatibility of software modules in order to determine valid means for integrating and interconnecting them has been successful in simplifying system design and implementation, with all the benefits widely known about modular programs. To date, however, this ....

J. Callahan, J. Purtilo. "A Packaging System for Heterogeneous Execution Environments," IEEE Transactions on Software Engineering, vol. 17, pp. 626-635, June 1991.

....in the expression of component (or object) interconnection. Using Corba, the application programmer has to code calls to server objects within the implementation of client objects while this may be achieved automatically from the configuration description in a configuration based system (e.g. see [6]) The main advantage of the Oma comes from the fact that it is a standard for distributed computing. In particular, one may expect the implementation of various object services and common facilities, hence promoting software reuse. It follows that the design of a configuration based system ....

J. R. Callahan and J. M. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, 17(6):626--635, 1991.

....to mask some details of processor heterogeneity and distribution, in the case where the underlying application runs in several dissimilar environments. From this vantage point, our work resembles other efforts in software systems to promote program interoperability, such as software packaging [CP91] middleware (see for example Bernstein [Be93] and distributed object management systems [NWM93] We report here on our use of computational proxies in the domain of computational chemistry, and then try to abstract lessons that can be applied in other domains, as well as indicating where more ....

J. R. Callahan and J. M. Purtilo. A Packaging System for Heterogeneous Execution Environments. IEEE Trans. on Software Engineering 17(6), June 1991.

....to check consistency before delegating the actual linking to ld. However, the crucial advantage with our approach is that we per form type checking as a controlled and programmable link time activity. There is a plethora of literature related to stub generation[4, 12, 3, 20] The Polygen system [7] is representative of automatic stub generation for programming in a heterogeneous environment. Polygen packages heterogeneous modules by utilizing a programmer defined specification of their interfaces and execution environments specified in a common module language. The packaging process ....

John R. Callahan and James M. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, 17(6):626--635, June 1991.

....objects, taking advantage of caching to avoid recompilation. DSEE was primarily a CASE tool and did not take part in the execution phase of program development. Several architecture description languages have been proposed, such as Rapide [12] the POLYLITH Module Interconnection Language (MIL) [5, 18], and OMG s Interface Definition Language (IDL) 9] These languages all share the characteristic that they support the flexible specification of high level components and interconnections. Our approach offers the important advantage that OO like program adaptation and reuse techniques ....

John R. Callahan and James M. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, 17(6):626--635, June 1991.

....code is frequent when datastructures do not match fully, when the application demands filtering of information, and in general when modules written in a different context are being reused. 1.1. 2 The Vision To support more general notions of composition, interface formalisms have to be provided [Callahan:91] These interfaces need machine processable specifications, to help in the composition task. The use of formal interfaces is especially critical for reconfiguration and redistribution of software modules [Purtilo:92] Often multiple processors will be involved. The actual composition of modules ....

....applications. The composition task can be greatly aided by having tools as libraries with formal specifications, and graphical tools for the selection and insertion of modules [Hunt:90] To create a library of such modules we can initially wrap existing programs to serve within this architecture [Callahan:91] The wrapper will have to provide an interface specification for linkage as well as provided the estimates for module scheduling. Human interface code in old programs, needed to make them user friendly can be omitted, greatly reducing their complexity. We foresee that the input output code will ....

J. Callahan and J. Purtilo: "A Packaging System for Heterogeneous Execution Environments"; IEEE Transactions on Software Engineering, Vol. 17, 1991, pp.626-- 635.

....is translated under this system, each RPC statement is translated into a set of fine grained message passing primitives, and the source is translated to introduce the particular techniques specified at the configuration level. This builds upon the MIL (Module Interconnection Language) approach [5, 21] for distributed programming, where the original MIL specification is intended for structural presentation of interfaces between interacting processes. We append performance related specifications onto each interface specification in a MIL. As the performance factors are isolated from the module ....

....and their compositions is derived from the Polylith module interconnection language, and the distributed run time environment chosen is likewise the software bus behind Polylith. Basic tools for preparing applications to run in this environment are already available within the Polygen system [5], although they are to be tailored to attain our source translation (rather than stub generation) principle. Therefore the principle thrust of our effort has been to add a source translator (gen trans) to the suite of Polygen tools. The source translator operates differently depends on whether a ....

John Callahan and James Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, Vol. 17(6):626--635, June 1991.

....is translated under this system, each RPC statement is translated into a set of fine grained message passing primitives, and the source is translated to introduce the particular techniques specified at the configuration level. This builds upon the MIL (Module Interconnection Language) approach [5, 21] for distributed programming, where the original MIL specification is intended for structural presentation of interfaces between interacting processes. We append performance related specifications onto each interface specification in a MIL. As the performance factors are isolated from the module ....

....and their compositions is derived from the Polylith module interconnection language, and the distributed run time environment chosen is likewise the software bus behind Polylith. Basic tools for preparing applications to run in this environment are already available within the Polygen system [5], although they are to be tailored to attain our source translation (rather than stub generation) principle. Therefore the principle thrust of our effort has been to add a source translator (gen trans) to the suite of Polygen tools. The source translator operates differently depends on whether a ....

John Callahan and James Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, Vol. 17(6):626--635, June 1991.

....for them to be bound via an interface. We are now able to demonstrate these benefits via our experimental system called PTM. Our approach has been to formulate a multicast execution environment in terms of software bus organization [8] and then take advantage of existing packager technology [3] (based upon the software bus) to show how large software configurations can be automatically prepared for execution on the new bus without requiring manual adaptation of the code. The multicast bus implementation by itself gives no more functionality than other (and perhaps more mature) ....

....obtain executables reliably the problem is identifying the program units and generating the appropriate command. This is a tedious task that no programmer is interested in performing manually. The packaging work described in this paper is based on the software packaging technology of Polygen[3]. In Polygen, a primitive module specification is an abstract description of a software module describing the interfaces of a module and other attributes (the location of the source code for example) of that module. The initial configuration of an application is given in an composite specification ....

J. Callahan, J. Purtilo. A Packaging System for Heterogeneous Execution Environments. IEEE Transactions on Software Engineering, (June 1991), 626-635.

....In the following section, we present a source transformation framework under constraints (1) 4) for optimizing RPC based distributed programs, with preserving the control dependences as well. 4 TRANSFORMATION FRAMEWORK When an RPC is implemented through traditional stub generation based methods [6, 8, 13], a stub performs following three functions. 1. Communication: RPC arguments are transmitted to the remote callee via communication network, and the result is back to the caller. 2. Synchronization: The caller is suspended until the result is ready to receive. 3. Data conversion: A data type in ....

J. Callahan and J. M. Purtilo. A packaging system for heterogeneous execution environments. IEEE Transactions on Software Engineering, Vol. 17(6):626--635, June 1991.

....of how to build the system on any given platform. 1 Supported by the Advanced Research Projects Agency Grant MDA 972 91 J 1022, the National Aeronautics and Space Administration Grant NAG 5 2129, and the National Library of Medicine Grant N01 LM 3 3525. 1 Introduction Software packaging [1] is an attempt to present a unified solution to the problems of building software applications from reusable software components. Software packaging hides the difficult problems of putting the pieces together that often prevent reuse, make configuration management difficult, and prevent ....

J. Callahan and J. Purtilo, A packaging system for heterogeneous execution environments, IEEE Transactions on Software Engineering, June 1991, Volume 17, Number 6, pp. 626-635.

No context found.

J. Callahan, J. Purtilo, "A Packaging System for Heterogeneous Execution Environments," IEEE Transactions on Software Engineering, vol. 17, pp. 626-635, 1991.

No context found.

John R. Callahan and James M. Purtilo. "A Packaging System for Heterogeneous Execution Environments." IEEE Trans. on Software Engineering, 17(6): 626-635, June 1991.

First 50 documents

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