A Flexible and Secure Deployment Framework for Distributed Applications

Dearle, Alan; Kirby, Graham N. C.; McCarthy, Andrew J.; Carballo, Juan Carlos Diaz y

doi:10.1007/978-3-540-24848-4_15

Cited by 7 publications

(7 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In [28] we describe an architecture, called Cingal, which permitted code to be safely deployed on thirdparty machines. The system could deploy selfcontained assemblies which contained closures of code and data and were called bundles.…”

Section: Distributed Deploymentmentioning

confidence: 99%

Software Deployment, Past, Present and Future

Dearie

2007

Future of Software Engineering (FOSE '07)

Self Cite

View full text Add to dashboard Cite

What is Software deployment?Software deployment may be defined to be the processes between the acquisition and execution of software. This process is performed by a software deployer who is the agent that acquires software, prepares it for execution, and possibly executes the software [1]. Thus deployment is a post-production activity that is performed for or by the customer of a piece of software. It is at this point in time that all customer centric customization and configuration takes place. Software deployment may be considered to be a process consisting of a number of inter-related activities including the release of software at the end of the development cycle; the configuration of the software, the installation of software into the execution environment, and the activation of the software [2]. It also includes post installation activities including the monitoring, deactivation, updating, reconfiguration, adaptation, redeploying and undeploying of the software. We briefly expand on each of these activities in Section 1.2 below. Concepts/TerminologyIn this section we introduce common terminology and concepts which apply to many software deployment systems.Most deployment systems incorporate the concept of a component which is defined in the UML2 specification [3] to be a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. In [4] a component is defined to be a unit of composition with contractually specified interfaces and explicit context dependencies only. A component defines its behavior in terms of provided and required interfaces. In this context, an assembly is a set of interconnected components. An assembly can itself be viewed as a component made up of subcomponents and offering and requiring interfaces. This concept has been developed to its logical conclusion in the Fractal Component Model [5]. The required interfaces of the components in an assembly may be satisfied either by other components in the assembly or be required from the environment in which the assembly is deployed. The term resource is commonly used to refer to any artefact (both hardware, software and system artefacts) which a component requires in order to function. An application is simply a collection of components which performs some function. In order to deploy a component it must be instantiated, supplied with instances of components on which it depends and configured. A version of a component refers to time ordered revisions of a component or application and to platform-specific and/or functional variants [1].Some systems provide the notion of a component package containing metadata and assemblies. The package may contain multiple implementations of components to satisfy the needs of different hardware and software environments. Thus when a package is deployed, the deployment system may need to choose the components that are most suitable for the environment. To do this appropriate and adequate

show abstract

Section: Distributed Deploymentmentioning

confidence: 99%

Software Deployment, Past, Present and Future

Dearie

2007

Future of Software Engineering (FOSE '07)

Self Cite

View full text Add to dashboard Cite

show abstract

“…For instance, the Cingal model is a component model very similar to the OSGi one, and provides digital signature using the same principle of digital signature of the bundles [2]. A similar mechanism has been defined to support the deployment of Web Services [4].…”

Section: Secure Deploymentmentioning

confidence: 99%

Supporting the Secure Deployment of OSGi Bundles

Parrend

Frénot

2007

2007 IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks

View full text Add to dashboard Cite

show abstract

“…Once these bundles have been fired on the appropriate hosts, the application is fully deployed in its initial configuration. This process is described in detail in [14]. The autonomic aspect of this approach is that the deployed application is instrumented with probes to monitor its execution.…”

Section: Figure 2 Refined Autonomic Cyclementioning

confidence: 99%

“…From a DDD, the ADME generates a collection of scripts which perform installation, instantiation and wiring of the components. Once the scripts have executed on the appropriate hosts, the application is fully deployed in its initial configuration [2].…”

mentioning

confidence: 99%

A framework for constraint-based deployment and autonomic management of distributed applications (extended abstract)

Dearle

Kirby

McCarthy

International Conference on Autonomic Computing, 2004. Proceedings.

View full text Add to dashboard Cite

We propose a framework for the deployment We believe that the initial deployment of an application and its subsequent evolution in the face of host failures and other perturbations are separate but closely related problems. Both are too complex in large applications to be handled by a human operator. We propose that both should be controlled automatically, driven by a high-level configuration goal specified by the administrator at the outset. We thus address specifically the first and third of Kephart & Chess' issues [1]: self-configuration and self-healing.Our general approach is shown below. The application administrator specifies a deployment goal in terms of resources available and constraints over their deployment. We propose a new domain-specific constraint language called Deladas (DEclarative LAnguage for Describing Autonomic Systems) for this purpose. The resources include software components and physical hosts on which these components may be installed and executed. Constraints operate over aspects such as the mapping of components to hosts and the interconnection topology between components.The autonomic cycle is controlled by an engine, which we call the Autonomic Deployment and Management Engine (ADME), that attempts to satisfy a goal, specified by the administrator in the constraint language. The engine includes a parser and constraint solver. The result of the attempted goal satisfaction is a set of zero or more solutions. Each solution is in the form of a configuration, expressed as a Deployment Description Document (DDD), which describes a particular mapping of components to hosts and interconnection topology that satisfies the constraints.If a configuration can be found, it is enacted by the engine to produce a running deployment of the application. From a DDD, the ADME generates a collection of scripts which perform installation, instantiation and wiring of the components. Once the scripts have executed on the appropriate hosts, the application is fully deployed in its initial configuration [2].

show abstract

A Flexible and Secure Deployment Framework for Distributed Applications

Cited by 7 publications

References 8 publications

Software Deployment, Past, Present and Future

Software Deployment, Past, Present and Future

Supporting the Secure Deployment of OSGi Bundles

A framework for constraint-based deployment and autonomic management of distributed applications (extended abstract)

Contact Info

Product

Resources

About