a cooperative approach to support software deployment using the software dock n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
A Cooperative Approach to Support Software Deployment using the Software Dock PowerPoint Presentation
Download Presentation
A Cooperative Approach to Support Software Deployment using the Software Dock

Loading in 2 Seconds...

play fullscreen
1 / 29

A Cooperative Approach to Support Software Deployment using the Software Dock - PowerPoint PPT Presentation


  • 402 Views
  • Uploaded on

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?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Cooperative Approach to Support Software Deployment using the Software Dock' - paul


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a cooperative approach to support software deployment using the software dock

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
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
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
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
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
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 cont d
Software Dock Architecture (Cont’d)

Key Components

  • Release Dock
  • Field Dock
  • Agents
  • Wide Area System
software dock architecture cont d1
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 d2
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 d3
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 d4
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
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 issues1
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 design issues2
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 issues3
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 issues4
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 issues5
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 issues6
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 issues7
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 issues8
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 issues9
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.
current status
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
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
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
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
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
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.