#! /bin/more ################################################################################ # # General package information. # Copyright (c) 2002-2006 Oak Ridge National Laboratory. # # For more information see the following files in the source distribution top- # level directory or package data directory (usually /usr/local/share/package): # # - README for general package information. # - INSTALL for package install information. # - COPYING for package license information and copying conditions. # - AUTHORS for package authors information. # - ChangeLog for package changes information. # ################################################################################ GENERAL PACKAGE INFORMATION =========================== 1. Introduction 2. Harness Architecture 3. RMIX Architecture 4. Harness-RMIX Plug-in 5. References 6. Package Content 7. Package Install Options 8. Install Versioning System 9. Binaries for Debugging 10. Development Information 1. Introduction =============== The heterogeneous adaptable reconfigurable networked systems (Harness [1-6]) research project is an ongoing collaborative effort among Oak Ridge National Laboratory, the University of Tennessee, Knoxville, and Emory University. It focuses on the design and development of a pluggable lightweight heterogeneous Distributed Virtual Machine (DVM) environment, where clusters of PCs, workstations, and "big iron" supercomputers can be aggregated to form one giant DVM (in the spirit of its widely-used predecessor, "Parallel Virtual Machine" (PVM)). As part of the Harness project, a variety of experiments and system prototypes were developed to explore lightweight pluggable frameworks, adaptive reconfigurable runtime environments, assembly of scientific applications from software modules, parallel plug-in paradigms, highly available DVMs, fault-tolerant message passing, fine-grain security mechanisms and heterogeneous reconfigurable communication frameworks. Currently, there are three different Harness system prototypes, each concentrating on different research issues. The teams at Oak Ridge National Laboratory and at the University of Tennessee provide different C variants, while the team at Emory University maintains a Java-based alternative. 2. Harness Architecture ======================= Conceptually, the Harness software architecture consists of two major parts: a runtime environment (RTE) and a set of plug-in software modules. The multi-threaded user-space RTE manages the set of dynamically loadable plugins. While the RTE provides only basic functions, plug-ins may provide a wide variety of services needed in fault-tolerant parallel and distributed scientific computing, such as messaging, scientific algorithms and resource management. Multiple RTEs can be aggregated into a Distributed Virtual Machine. With this software distribution, we present a native (C-based), flexible, adaptable, multi-protocol RMI communication framework plug-in for the C-based ORNL Harness RTE that complements the Java-based RMIX variant [7-11] previously developed by our partner team at Emory University as part of the Harness research effort. 3. RMIX Architecture ==================== RMIX is a dynamic, heterogeneous, reconfigurable communication framework that allows software components to communicate using various RMI protocols, such as Java RMI and SOAP, by facilitating dynamically loadable provider plug-ins to supply different protocol stacks. While the RMIX base library contains functions that are common to all protocol stacks, like advanced RMI semantics, networking and thread management, RMIX provider plug-ins only contain certain protocol stack specific functions for connection management, message formats and data encoding. Since it is up to the provider plug-ins to reuse base library functions, implementations may range from lightweight to heavyweight. Moreover, client- and server-side object stubs are lightweight and protocol independent as they only perform an adaptation to the RMIX system. RMI semantics have been expanded within RMIX to support the Remote Procedure Call (RPC) paradigm and its protocols, such as ONC RPC, providing communication for a wide range of software components. Furthermore, in addition to standard synchronous RMI/RPC mechanisms, RMIX also offers advanced invocation semantics, such as asynchronous and one-way. 4. Harness-RMIX Plug-in ======================= The C-based RMIX variant is integrated into the C-based lightweight Harness RTE [6] in form of a plug-in to provide RMI capabilities to the RTE and to other plug-ins. This effort also complements research performed earlier by our partner team at Emory University, where the Java-based RMIX solution has been integrated into the Java-based Harness run time environment H2O [11]. The RMIX base library and stubs for the Harness RTE are wrapped into a Harness plug-in, while stubs for other plug-ins are also implemented as plug-ins. Since the Harness RTE supports plug-in dependencies, a plug-in requiring RMIX auto- matically loads its stub plug-in(s) and subsequently the RMIX plug-in. 5. References ============= 1. Geist, G.A., Kohl, J.A., Scott, S.L., Papadopoulos, P.M.: HARNESS: Adaptable virtual machine environment for heterogeneous clusters. Parallel Processing Letters 9 (1999) 253-273 2. Sunderam, V., Kurzyniec, D.: Lightweight self-organizing frameworks for metacomputing. Proceedings of HPDC (2002) 113-124 3. Emory University, Atlanta, GA, USA: Harness project at http://www.mathcs.emory.edu/harness 4. Oak Ridge National Laboratory, TN, USA: Harness project at http://www.csm.ornl.gov/harness 5. University of Tennessee, Knoxville, TN, USA: Harness project at http://icl.cs.utk.edu/harness 6. Engelmann, C., Geist, G.A.: A lightweight kernel for the Harness metacomputing framework. Proceedings of IPDPS - HCW (2005) 120 7. Kurzyniec, D., Wrzosek, T., Sunderam, V.S., Slominski, A.: RMIX: A multiprotocol RMI framework for Java. Proceedings of IPDPS (2003) 140 8. Kurzyniec, D., Wrzosek, T., Sunderam, V.S.: Heterogeneous access to servicebased distributed computing: The RMIX approach. Proceedings of IPDPS - HCW (2003) 100 9. Kurzyniec, D., Sunderam, V.S.: Semantic aspects of asynchronous rmi: The RMIX approach. Proceedings of IPDPS - JavaPDCW (2004) 157 10. Wrzosek, T., Kurzyniec, D., Sunderam, V.S.: Performance and client heterogeneity in service-based metacomputing. Proceedings of IPDPS - HCW (2004) 113 11. Kurzyniec, D., Drzewiecki, D., Sunderam, V.S.: Towards self-organizing distributed computing frameworks: The H2O approach. Parallel Processing Letters 13 (2003) 273-290 6. Package Content ================== This package contains: rmix-base - RMIX multi-protocol remote method invocation sub-package rmix-rpcx - RMIX-RPC protocol provider sub-package harness-base - Harness run time environment sub-package harness-example - Harness example plug-in sub-package harness-rmix - Harness-RMIX integration sub-package Please read the individual sub-package descriptions for more details. 7. Package Install Options ========================== This source distribution does provide the following additional `configure` and/or `autogen.sh` options: --disable-rmix skip rmix sub-packages --disable-harness skip harness sub-packages --disable-rmix-base skip rmix-base sub-package --disable-rmix-rpcx skip rmix-rpcx sub-package --disable-harness-base skip harness-base sub-package --disable-harness-example skip harness-example sub-package --disable-harness-rmix skip harness-rmix sub-package Try `configure --help` or `autogen.sh --help` for standard options. 8. Install Versioning System ============================ In order to support simultaneous installations of different versions of the same package and/or in order to provide version tracking, files and folders may be installed in a way to differentiate between their versions and revisions. These versions and revisions are the ones of the installed files and folders and not of their packages. For example, a shared library provides a set of functions in form of an API documented in a header file. A single number is used to describe this API version and a single number is used to describe the revision of this specific API version. The version number is increased if the API changes, i.e. a function is added, removed or its signature or meaning modified. The revision number is set to 0 if the version number was increased. The revision number is increased if the implementation of the API is improved, but its meaning not changed, e.g. for bug fixes and performance improvements. A shared library may also support past API versions if functions where only added, but not removed or its signature or meaning modified. So that there is always a continuous range of version numbers specified by two numbers, the first version supported and the number of followup versions supported (age). Together with the revision the triplet .. is formed, which is used to differentiate and order files and folders by appending it to or inserting it into the file or folder name, e.g. libfoo.0.0.0.so. The triplet is maintained for every library or program and its corresponding files, like header and configuration files, together, so that the library /usr/lib/libfoo.0.0.0.so corresponds to the folder /usr/include/foo.0.0.0 where all of its header files are installed. A program /usr/bin/foo.0.0.0 would have its configuration files installed in the folder /etc/foo.0.0.0. In order to simplify access to the different installed versions the script `autolink.sh` creates, corrects and removes symbolic links to the normal names pointing to the highest version and revision (e.g. foo -> foo.0.0.0) and to extended names that include only the interface version and point to highest revision (e.g. foo.0 -> foo.0.0.0). The script `autolink.sh` is invoked on package installation and removal for every file and folder by the corresponding Makefile. To use the versioned files and folders, just link or include the files and folders with the extended names, i.e. "cc bar.c -lfoo.0" or "#include ". You will always link/include the right version with the highest revision. 9. Binaries for Debugging ========================= In order to provide more extensive debugging support additional variants of binaries (libraries and programs) with built-in extended error logging and/or memory tracing may be installed. These variants are installed with the extension .debug. If the installed file has a system extension, like .a, .debug is inserted before it, e.g. libfoo.debug.a. If the installed file uses the Install Versioning System, .debug is inserted after the version triplet and before any system extension, e.g. libfoo.0.0.0.debug.a. The script `autolink.sh` is used to maintain links, such as libfoo.0.debug.a. 10. Development Information =========================== See INSTALL in the source distribution top-level directory or package data directory (usually /usr/local/share/harness-example) about install information for development purposes. See COPYING in the source distribution top-level directory or package data directory for license information about modifying this package, i.e. adding, removing and/or changing any files. In order to take part in the development process for this package, unpack the source distribution and install it into the unpacked source distribution directory to make sure that this installation is for development purpose only. Submit bug fixes or enhancements to the bugreport e-mail address supplied in configure.ac in the source distribution top-level directory. Also look at the "Introduction" section in INSTALL for instuctions on using `configure` and `autogen.sh`. If you change any file that is processed by `configure`, be sure to run `autogen.sh`. Be also sure not to change any file that is created by `configure`. Change the template (`configure` input) file instead. See the "Package Install Options" section in this file for any additional `configure` and/or `autogen.sh` options. This source distribution provides the following make targets after running `configure` or `autogen.sh` in the source distribution top-level directory: `make` or `make all`: Compiles and links all binaries of this package. Do not run any created executable and do not link any created library (unless cross-linked inside the package), since the package is compiled and not installed. `make install`: Installs all files of this package marked to be installed. Run any installed executable or script and link any installed library in their installation path. Installed header files may be included by other software packages. Some package information files (README, INSTALL, etc.) are installed as well. `make clean`: Removes any files created by `make` or `make all`, but does not remove any files installed by `make install`. `make uninstall`: Removes any files installed by `make install`, but does not remove any files created by `make` or `make all`. `make reinstall`: Performes `make uninstall` and `make install` `make maintainer-clean`: Removes any files created by `make` or `make all` and files created by `configure`, but does not remove any files installed by `make install`. `make release`: Creates all files needed for a release of this software package. This includes: tar/bz2 archives and source rpm. Do NOT use `make dist` provided through `automake`. `make releases`: Recursively executes `make release` for software packages that bundle other software packages, so that the bundle release and all individual releases are created. `make backup`: Creates a recursive archive of the source distribution top-level directory with a timestamp and puts it into the directory above the source distribution top-level directory. ################################################################################ # # End of file. # ################################################################################