Transcript A Cooperative Approach to Support Software Deployment using the

A Cooperative Approach to Support Software
Deployment using the Software Dock
Dennis Heimbigner
Richard S. Hall
Alexander L. Wolf
Software Engineering Research Laboratory
University of Colorado
Introduction
What is Software Deployment?
The delivery, assembly and maintenance of a particular version of
a software system at a site.
In simple words it is the process that covers post-development
activities like configuration, release, installation, updating, adapting,
reconfiguration and un-installation.
Traditional Software Deployment
Methods

The foot and hand model: Run around on foot and install
software by hand.
- Only viable for small client base.
- Expensive for the companies.

The self-service model: The end users install the software
themselves.
- Scales well.
- Low costs for the company.
- Becomes difficult as the complexity of installation and
configuration increases.
Requirements of solutions for
software deployment










Incremental updates
Versioning
Automatic installation and configuration
Centralized Inventory
Decentralized Control
Security
Scalability
Support for heterogeneous environments
Live Updates
Licensing
Software Deployment Life Cycle
The Software Deployment Life Cycle is an evolving collection of
processes. These processes can either be performed on the
software producer side or the customer side.
Producer-side processes

Release

Retire
Customer-side processes

Install

Activate

Deactivate

Reconfigure

Update

Adapt

Remove
Software Dock (Overview)






It addresses most of the requirements cited earlier.
It is a system of loosely coupled, cooperating, distributed
components.
It provides support for the producers by providing the release
dock which acts as a central repository. In the release dock a
standard semantic schema is used to specify deployment
requirements of the software systems.
At the customer end a field dock component provides an interface
to the customer’s resources and deployed systems.
Agents in the Software Dock travel from the release dock to the
field dock in order to perform specific deployment tasks through
the interface.
A wide area event systems connects release docks to field docks
for asynchronous, bidirectional activity.
Software Dock Architecture
Software Dock Architecture (Cont’d)
Key Components




Release Dock
Field Dock
Agents
Wide Area System
Software Dock Architecture (Cont’d)
Key Components

Release Dock
- It is a server at the producer side which acts as a release repository
providing a web-based release mechanism.
- Each software release is described by a standard deployment schema.
- It provides programmatic interface for the agents to access its services
and content.
- It generates events when changes occur to the software releases
managed by it.



Field Dock
Agents
Wide-Area Event Service
Software Dock Architecture (Cont’d)
Key Components


Release Dock
Field Dock
- It is a server residing at the customer side which provides an interface to
the customer, providing information about the resources and
configuration of the system.
- It provides customer side information, which is critical in any deployment
process, in the form of a standardized and hierarchical registry.
- Any changes in the registry generates an event that the agents receive to
perform subsequent tasks.


Agents
Wide Area System
Software Dock Architecture (Cont’d)
Key Components



Release Dock
Field Dock
Agents
- They do all the software deployment work.
- There are different agents to perform software deployment processes like
installation, update, adapt, reconfigure, and remove.
- Each of these agents does its assigned task based upon the system
information that it is provided through the interface at the field dock.
Wide Area System
Software Dock Architecture (Cont’d)
Key Components




Release Dock
Field Dock
Agents
Wide Area System
- It provides a means of connectivity between producers and customers
for push style capability.
- Agents subscribe for events from the release docks using the wide-area
event system.
- Direct communication over the Internet and communication through
events in the wide-area event system combined provide an opportunity to
the producer and the customer to cooperate for deployment support.
Software Dock : Design Issues

Deployable Software Description (DSD) format
- It was developed to facilitate the creation of generic deployment
process definitions.
- It provides a standard schema to describe a software system
family.
- DSD family description is divided into multiple sections like
identification, imported and system properties, property
composition, assertions, dependencies, artifacts, interfaces,
notifications, services, and activities.
- Some of these sections can be directly associated with the five
classes of semantic information that have to be provided by any
software system model, namely Configuration, Assertions,
Dependencies, Artifacts and Activities.
Software Dock : Design Issues

DSD Examples
Property {
Name = “Online Help”
Type = “Boolean”
Description = “Include online help.”
…}
Assertion {
Condition = “($OS$ == ‘Solaris’) ||
($OS$ == ‘Win95’)”
Description = “Test for supported
operating system.”
…}
Artifacts {
Artifact {
Guard = “($OS$ == ‘Solaris’)”
SourceName = “help.html”
Source = “/proj/doc”
DestinationName = “help.html”
Destination = “doc”
Mutable = false
Signature=“3b8902d3410ec832”
Type = “Documentation”
…}
Artifact {
Guard = “($OS$ == ‘Win95’)”
SourceName = “help.hlp”
Source = “/proj/doc”
DestinationName = “help.hlp”
Destination = “doc”
Mutable = false
Signature = “9283cd2378102f1a3b12ee”
Type = “Documentation”
…}
}
Software Dock : Design Issues

Software Dock Processes
- Agents define all the software deployment processes. They are the active
components of the Software Dock.
- Software Dock framework facilitates the creation of generic agents, to
perform standard deployment processes, as well as the creation of
specific agents to perform software deployment tasks specific to
particular customer systems.
- All Agents use information provided by the DSD and a generic
deployment process algorithm to perform their tasks.
- Generic Deployment Process Definition
- Specific Deployment Process Definitions
Software Dock : Design Issues
Generic Deployment Process definition:
- This algorithm is based on the idea that a deployment process
-
transforms an existing software system configuration to a new
one based on a set of property values.
Transformation is done by differential processing over the
applicable schema elements of the DSD specification.
Applicable schema elements are determined by the guard
conditions in the DSD.
Software Dock : Design Issues
Specific Deployment Process Definitions:
The Software deployment processes generally follow the algorithm
explained earlier yet they are different from each other in small but
important ways. Working of each deployment process is described
below:
-
-
Install Process
- It is different from the other processes, in that, it is not associated with an existing
software release configuration. It’s a pull oriented process requested by the user.
- The install agent gets information from the field dock regarding which configuration
of the software release to install.
- The agent performs the necessary activities, like resolving dependencies, testing
assertions and retrieving artifacts, once it determines which release to install.
Update Process
Reconfigure Process
Adapt Process
Remove Process
Software Dock : Design Issues
Specific Deployment Process Definitions:
-
Install Process
Update Process
- The update agent deploys a new, previously unavailable configuration of a deployed
software release.
- It changes the current DSD specification to the new specification, undoes the
schema elements of the previous configuration and applies the schema elements of
the new one by differential processing of applicable schema elements.
- The update process is not always associated with a change in the configuration. It
might be performed for a content change or to provide a more specific DSD
specification.
-
Reconfigure Process
Adapt Process
Remove Process
Software Dock : Design Issues
Specific Deployment Process Definitions:
-
-
Install Process
Update Process
Reconfigure Process
- A reconfigure agent changes the existing configuration of a deployed software
release much like an update agent. However it does not ask for a new DSD from the
server.
- It finds the new configuration from the field dock like an install agent and makes
changes to the existing DSD according to the new configuration using differential
processing like an update agent.
- There is a one-to-one relationship between a reconfigure agent and a specific
software release.
Adapt Process
Remove Process
Software Dock : Design Issues
Specific Deployment Process Definitions:
-
-
Install Process
Update Process
Reconfigure Process
Adapt Process
- The primary function of the Adapt Agent is to maintain consistency of the deployed
software release with respect to the customer.
- It compares the schema elements of the existing DSD, applicable to the existing
configuration with the configuration of the customer system and determines if they
are still valid or not.
- If it finds any discrepancy in the DSD specification and the configuration of the
system it simply processes the schema elements in its own DSD to correct the
problem.
Remove Process
Software Dock : Design Issues
Specific Deployment Process Definitions:
-
Install Process
Update Process
Reconfigure Process
Adapt Process
Remove Process
- The remove agent removes a particular software release from the customer’s
system.
- The agent must take care of all dependencies and constraints before it removes the
software release associated with it.
- This process might cause generation of a number of remove requests to other
agents incase of removal of a dependent software release.
- A remove agent takes information from its DSD and removes the components
specified in it according to the applicable schema elements.
Software Dock : Design Issues

-
-
Security
Agents operate in the Java Virtual Machine sandbox thus limiting
their ability to access the customer’s system. This is useful if any
hostile agent docks at the field dock.
Field docks are the only interface available to the agents and the
field docks use a capability approach which grants access to
restricted operations only to certain agents based on the agent’s
inherent capability.
Though the current security mechanisms are not good enough,
support is given to extend the framework so as to allow agents to
become trusted which can facilitate more secure transactions.
Related Work
Technology
Strengths
Weaknesses
Configuration Management
Modeling
•
Precise & easy to understand
modeling language
•
Open Software Description
(OSD)
•
Describes software systems for
push technologies
• Provides identification information
and pointers to archives of artifacts
•
Application Management
Specification (AMS)
•
It describes constraints,
dependencies, identification and
support
•
Common Operating
Environment (DII COE)
•
Segments describe artifacts,
constraints
• Scripts provide deployment support
•
RedHat Package Manager (RPM)
•
Provides a variety of deployment
features
• Scripts provide information about
the software system to be deployed
•
InstallShield & NetDeploy
•
Make good use of the connectivity of
Do not address software
deployment
• Do not create standard schemas for
any specific task
Immature (???Have to take the
authors’ word)
• Too simplistic to perform automated
software deployment
Not designed to automate
deployment process
• Does not support modification of
internal system properties
Configuration cannot be
manipulated
• There is no release side support
Limited forms of configuration
selection are supported
• No support for multi-site deployment
or management
•
No support for automated deploying
Current Status






A prototype implemented in Java exists
Voyager is used as an IPC mechanism and mobile
agent enabling technology
An evolving definition of the DSD exists
A schema editor is provided to create and edit DSD
descriptions
A docking station is used to request updates, adapts,
reconfigures and removes
Generic agents are provided for various deployment
processes
Future Work






Inclusion of an Administrator Role and “remote”
agents to support it
An InterDock will be created to support
Administrators
The DSD will be extended and expanded
Administration policy support will be enhanced
Arbitrary dependency specification will be researched
Better support for specialized deployment activities
will be looked into
Conclusion




Software Deployment transcends just installation.
For better software deployment, the vast connectivity
of the internet or any other network should be taken
advantage of.
Knowledge of user systems is necessary to provide
better support for a software system. This is provided
by field docks.
There is a need for a standardized means of
specifying software systems for deployment
processes which is provided by DSD.
Strengths of the paper





It gives a good idea about the requirements for better
software deployment.
Provides a seemingly good solution for each of the
requirements.
It addresses each of the deployment process in
depth.
It highlights some important concepts of the software
deployment life cycle.
It explains the working of the software dock project in
easy to understand terms
Weaknesses of the paper




It is too optimistic about the success of the Software
Dock.
It conveniently skirts important design issues like
security, that play an important role in software
deployment.
It fails to address scalability and concurrency issues.
It focuses too much on Deployable Software
Description format and fails to mention more specific
actions of each of the key components of the
architecture.
Relevance to Embedded Systems
 Resource Constraints
The software dock works in a JVM sandbox hence memory requirements
and CPU time is assumed to be minimal.
 Run-time deployment and down time
Seeing the change of configuration techniques used in the Software Dock it
is safe to assume that it does not support run-time deployment.
 Security
Software Dock provides minimal security and even with “trusted” agents
there is no stringent provision for authentication.
 Real-time constraints
As the Software Dock depends on a wide area event service there is ample
chance of the deployment processes not adhering to real-time constraints
due to network problems, lesser bandwidth and locality of the embedded
system in case its mobile.