Dennis Heimbigner, Alexander Wolf
Richard Hall, and Andre van der Hoek
Department of Computer Science
University of Colorado, Boulder, CO 80309 USA
{dennis,alw,rickhall,andre}@cs.colorado.edu
November 21, 1997
Deployment of software systems that are constructed through composition of pre-existing components adds a new layer of complexity over the deployment of more monolithic systems. This is because the component pieces comprising a system can and will evolve independently of the whole system. On one hand, these changes can threaten the integrity and operation of the whole system. On the other hand, component evolution can also provide new and and valuable capabilities to the systems that incorporate them.
We envision that future deployment of software systems will increasingly be accomplished using the Internet, and that the components comprising a software system will be obtained from a variety of possibly independent software providers through the Internet.
Network delivery of software components has a number of advantages over other media; advantages such as timeliness and constant evolution. Networks provide a more timely method for a software producer to make software available to its consumers. As soon as a new software system version or update becomes available, customers can be given access to it. The constant evolution of the content available through network distribution makes it possible to add value to software systems in a way that is not possible using other media. For example, by leveraging the timeliness of network distribution and the connectivity that it provides, it is possible for software systems and software producers to perform some management responsibilities like updating or adapting the software system.
Release: The release activity connects development to deployment. It encompasses all the activities needed to prepare and advertise a system so that it can be obtained and assembled correctly at a consumer site. Advertising includes the dissemination of sufficient information to interested parties and providing some form of access to the software system so that follow-on activities can be performed.
Installation: The installation activity covers the initial deployment of a software system onto a consumer site. It is usually the most complex of the deployment activities because it must find and assemble all the resources necessary to use a system. The installation process uses the information created by the release process. Given a released package, the installation process combines the knowledge encoded in the package with the information at a target site in order to determine how to properly configure the software system to the specific target site. Component-based software complicates this activity since the installation may need to obtain appropriate components from several Internet sites and install each one at the target site before the installation of the whole system can be completed.
Activation: Activation is the activity of starting up the components of a system that must execute in order for the system to be usable. For a complex compositional system, there will be components that must run continuously in order for the system to be usable. Examples of the latter might be various object servers and database systems needed by the system.
De-activation: De-activation, the inverse of activation, is responsible for shutting down any executing components of an installed system. De-activation may be required in order to perform other deployment activities such as update (see Section 3).
Update: The update process involves modifying a software system that has been previously installed on a consumer site. The update may be the result of the release of a new version of the software to fix a bug or add new functionality. It might also be the result of the release of a new version of a separately developed component that has been used in the composition of an already installed system. Typically the deployment life cycle includes a repeated sequence in which a system is (optionally) de-activated, an updated version of the system is installed, and then the system is reactivated.
Adapt: The adapt process involves modifying a software system that has been previously installed on a consumer site. Adapt differs from update in that updates are instigated by remote events whereas adaptations are instigated by local events. For example, if the configuration at the consumer site changes in a way that affects the deployed software system it may be necessary for the deployed software system to take some sort of corrective action.
De-installation: A software system may eventually become unneeded at a given consumer site and the system will need to be de-installed. De-installation is not necessarily a trivial process. Special attention has to be paid to shared resources such as data files and components in order to prevent dangling references to the required resource. De-installation is therefore not the process of undoing everything that was done in installation, rather it is the examination of the current state of the system and its dependencies and constraints and the removal of the specific software system artifacts that will not violate these dependencies and constraints.
De-release: Ultimately a system or component is marked as obsolete and support by the producer is withdrawn. De-release is distinct from de-installation in the sense that it makes the software no longer available for installation at consumer sites, but it does not necessarily remove it from the consumer sites that are using it. Consumers of the software system may continue to use the system without knowing that it has been marked as obsolete, but the de-release process has an obligation to notify current users that support for the software has been withdrawn.
Each release site and each field site has associated with it what we call a dock, which is an environment for hosting agents and for maintaining information about that site. A dock provides an interface through which agents can query and manipulate the information. In general, there can be many field and release docks representing the interests of the many possible participants in the deployment process.
Most of the functionality of field and release docks is embodied in the set of agents that they host at any given time. Agents register for specific events and then perform specific tasks once these events have been received. The actions performed by agents can cause other events to be generated, thus stimulating the system with additional event-action responses.
We intend the Software Dock to be strongly policy driven. For example, one policy might be to require all attempts to update a component to be screened and scheduled by a site administrator so that existing software systems are not disrupted. To support a wide variety of possible policies, the basic agents provided with the Dock are policy-neutral. The basic agents are combined with product specific declarative information (e.g., constraints and dependencies) both from the product site and from the target site to produce effective agents embodying specific policies.
To illustrate our use of agents in the Software Dock, consider a scenario involving the automated update of a server object in a component-based system. In order for a running server to be properly updated, a carefully orchestrated set of activities must be performed. First, the clients must be deactivated. Then the server must be deactivated. The server can then be updated. After this, the server must be reactivated. Finally, the clients must be reactivated. Each activity can be handled by an agent associated with the specific activity (e.g., deactivation) for the specific component system (e.g., the client) at a particular site (e.g., a Windows~95 platform). In effect, agents in the Software Dock abstract the dependencies and constraints imposed by the cross product of activity, component, and environment.
In a related experiment, the Dock has been used in a Lockheed-Martin demonstration of their EVOLVER helpdesk system. The Dock was used to complete the cycle from problem report to updating fielded software.
Additionally, we have been tracking standardization efforts that are relevant to the deployment problem.