Dennis Heimbigner

A federated architecture for information management

An approach to the coordinated sharing and interchange of computerized information is described emphasizing partial, controlled sharing among autonomous databases. Office information systems provide a particularly appropriate context for this type of information sharing and exchange. A federated database architecture is described in which a collection of independent database systems are united into a loosely coupled federation in order to share and exchange information. A federation consists of components (of which there may be any number) and a single federal dictionary. The components represent individual users, applications, workstations, or other components in an office information system. The federal dictionary is a specialized component that maintains the topology of the federation and oversees the entry of new components. Each component in the federation controls its interactions with other components by means of an export schema and an import schema. The export schema specifies the information that a component will share with other components, while the import schema specifies the nonlocal information that a component wishes to manipulate. The federated architecture provides mechanisms for sharing data, for sharing transactions (via message types) for combining information from several components, and for coordinating activities among autonomous components (via negotiation). A prototype implementation of the federated database mechanism is currently operational on an experimental basis.

A cooperative approach to support software deployment using the software dock

Software deployment is an evolving collection of interrelated processes such as release, install, adapt, reconfigure, update, activate, deactivate, remove, and retire. The connectivity of large networks, such as the Internet, is affecting how software deployment is performed. It is necessary to introduce new software deployment technologies that leverage this connectivity. The Software Dock framework creates a distributed, agent based deployment framework to support the ongoing cooperation and negotiation among software producers themselves and among software producers and software consumers. This deployment framework is enabled by the use of a standardized deployment schema for describing software systems, called the Deployable Software Description (DSD) format. The Software Dock also employs agents to traverse between software producers and consumers in order to perform software deployment activities by interpreting the descriptions of software systems. The Software Dock infrastructure allows software producers to offer their customers high level deployment services that were previously not possible.

Language constructs for managing change in process-centered environments

Change is pervasive during software development, affecting objects, processes, and environments. In process centered environments, change management can be facilitated by software-process programming, which formalizes the representation of software products and processes using software-process programming languages (SPPLs). To fully realize this goal SPPLs should include constructs that specifically address the problems of change management. These problems include lack of representation of inter-object relationships, weak semantics for inter-object relationships, visibility of implementations, lack of formal representation of software processes, and reliance on programmers to manage change manually. APPL/A is a prototype SPPL that addresses these problems. APPL/A is an extension to Ada.. The principal extensions include abstract, persistent relations with programmable implementations, relation attributes that may be composite and derived, triggers that react to relation operations, optionally-enforceable predicates on relations, and five composite statements with transaction-like capabilities. APPL/A relations and triggers are especially important for the problems raised here. Relations enable inter-object relationships to be represented explicitly and derivation dependencies to be maintained automatically. Relation bodies can be programmed to implement alternative storage and computation strategies without affecting users of relation specifications. Triggers can react to changes in relations, automatically propagating data, invoking tools, and performing other change management tasks. Predicates and the transaction-like statements support change management in the face of evolving standards of consistency. Together, these features mitigate many of the problems that complicate change management in software processes and process-centered environments.

Deployment and dynamic reconfiguration planning for distributed software systems

The quality of software systems are determined in part by their optimal configurations. Optimal configurations are desired when the software is being deployed and during its lifetime. However, initial deployment and subsequent dynamic reconfiguration of a software system is difficult because of the interplay of many interdependent factors, including cost, time, application state, and system resources. As the size and complexity of software systems increases, procedures (manual or automated) that assume a static software architecture and environment are becoming untenable. We have developed a novel technique for carrying out the deployment and reconfiguration planning processes that leverages recent advances in the field of temporal planning. We describe a tool called Planit, which manages the deployment and reconfiguration of a software system utilizing a temporal planner. Given a model of the structure of a software system, the network upon which the system should be hosted, and a goal configuration, Planit will use the temporal planner to devise possible deployments of the system. Given information about changes in the state of the system, network and a revised goal, Planit will use the temporal planner to devise possible reconfigurations of the system. We present the results of a case study in which Planit is applied to a system consisting of various components that communicate across an application-level overlay network.

An architecture for post-development configuration management in a wide-area network

Few tools exist to address the post-development activities of configuring, releasing, installing, updating, reconfiguring, and even de-installing a software system. Certainly there is no unified approach for all of these activities, and none that can take full advantage of a wide-area network. The Software Dock represents an architecture for supporting post-development activities in such a setting. It is designed as a system of loosely-coupled, cooperating, distributed components that are bound together by a wide-area messaging and event system. In this paper we describe the Software Dock architecture and discuss the use of a prototype in deploying a complex system.

A generic, peer-to-peer repository for distributed configuration management

Distributed configuration management is intended to support the activities of projects that span multiple sites. NUCM (Network-Unified Configuration Management) is a testbed that we are developing to help us explore the issues of distributed configuration management. NUCM separates configuration management repositories (i.e. the stores for versions of artifacts) from configuration management policies (i.e. the procedures by which the versions are manipulated) by providing a generic model of a distributed repository and an associated programmatic interface. This paper describes the model and the interface, presents an initial repository distribution mechanism, and sketches how NUCM can be used to implement two rather different configuration management policies, namely check-in/check-out and change sets.

Software release management

Software release management begins with receipt of a release candidate comprising a software build for a particular target software release. It ends with the step of handing off that software build and associated meta-data to a manufacturing team. No changes to the software build itself are made during this process. Information about builds, targets software releases and stock keeping units (software products) are stored using a hierarchical representation. A sequence of ordered testing and approval steps is stored and may be dynamically re-configured. A release manager automatically manages the testing and approval steps according to the sequence. Web services are used to receive meta-data about the builds and release candidates.

The ProcessWall: a process state server approach to process programming

The ProcessWall is a process state server providing storage for process states plus operations for defining and manipulating the structure of those states. It separates the state of a software process from any program for constructing that state. Instead, client programs implement the processes for operating on the process state. This approach has a number of potential benefits such as support for process formalism interoperability, support for multiple process languages, low-cost retro-fitting of process into existing environments, and support for long-term execution of processes. The process server interface provides descriptive mechanisms for representing process state as well as product state. A classification of client programs is provided to show how the state server can be used in a variety of ways.

Software process modeling and execution within virtual environments

In the past, multiuser virtual environments have been developed as venues for entertainment and social interaction. Recent research focuses instead on their utility in carrying out work in the real world. This research has identified the importance of a mapping between the real and the virtual that permits the representation of real tasks in the virtual environment. We investigate the use of virtual environments—in particular, MUDs (Multi-User Dimensions)—in the domain of software process. In so doing, we define a mapping, or metaphor, that permits the representation of software processes within a MUD. The system resulting from this mapping, called Promo, permits the modeling and execution of software processes by geographically dispersed agents.

Reconfiguration in the Enterprise JavaBean Component Model

Reconfiguration is the process of applying planned changes to the communication, interconnection, componentization, or functionality of a deployed system. It is a powerful tool for achieving a variety of desirable properties of large-scale, distributed systems, including evolvability, adaptability, survivability, and continuous availability. Current approaches to reconfiguration are inadequate: some allow one to describe a systems range of configurations for a relatively broad class of system architectures, but do not provide a mechanism for actually carrying out a reconfiguration; others provide a mechanism for carrying out certain kinds of limited reconfigurations, but assume a specialized system architecture in order to do so. This paper describes our attempt at devising a reconfiguration mechanism for use with the popular and widely available Enterprise JavaBean (EJB) component container model. We describe extensions to the basic services provided by EJB to support the mechanism, a prototype implementation, and a case study of its application to a representative component-based distributed system.