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

Dearle, Alan; Kirby, Graham N. C.; McCarthy, Andrew J.

doi:10.1109/icac.2004.1301386

Cited by 38 publications

(37 citation statements)

References 20 publications

(30 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The language we propose is purely declarative and descriptive and has a similar objective to the language described in [10]. It is not mandatory to give an explicit name or address of a target machine: the placement of components are mainly driven by constraints on the resources the target host(s) should satisfy.…”

Section: Deployment Specificationmentioning

confidence: 99%

“…The deployment considered in this work extends the Corba Component Model, which is a flat component model. In [10], the authors present the Deladas language that also allows constraints to be defined on hosts and components. A constraint solver is used to generate a valid configuration of the placements of components and reconfiguration of the placement is possible when a constraint becomes inconsistent.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Constraint-Based Deployment of Distributed Components in a Dynamic Network

Hoareau¹,

Mahéo²

2006

Architecture of Computing Systems - ARCS 2006

View full text Add to dashboard Cite

Abstract. Hierarchical software components offer interesting characteristics for the development of complex applications. However, supporting the deployment of such applications is difficult, especially on challenging distributed platforms. This paper addresses the distribution and the deployment of hierarchical components on heterogeneous dynamic networks. Such networks may include fixed and mobile resource-constrained devices and are characterized by the volatility of their hosts and connections, which may lead to their fragmentation. The distribution scheme and the associated mechanisms we propose allow a component to provide its services in an ubiquitous way and to operate in a degraded mode. The deployment of hierarchical components is described: we present an ADL extension for specifying a context-aware deployment and we detail a hierarchicallycontrolled deployment designed for dynamic networks. This deployment is performed in a propagative way and is driven by constraints put on the resources of the target hosts.

show abstract

Section: Deployment Specificationmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Constraint-Based Deployment of Distributed Components in a Dynamic Network

Hoareau¹,

Mahéo²

2006

Architecture of Computing Systems - ARCS 2006

View full text Add to dashboard Cite

show abstract

“…Both these problems may be addressed by specifying a high-level configuration goal which is used to drive the autonomic process. In order to describe how an application is intended to be structured, we have proposed the use of domain-specific constraint-based languages [35]. Using a constraint-language, it is possible to describe configuration goals in terms of resources including software components and physical hosts, relationships between hosts and components, and constraints over these.…”

Section: Adaptation and Autonomicsmentioning

confidence: 99%

Software Deployment, Past, Present and Future

Dearie

2007

Future of Software Engineering (FOSE '07)

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

“…Resource constraints are expressed through an Architecture Description Language (ADL) that is considered in a decisional algorithm. [4] rely also on a declarative language expressing the constraints and propose a deployment model and an autonomous management of distributed component oriented applications. Constraints as the placement of a component in a node or the components interconnection topology are first described, then resolved in order to find an optimal configuration.…”

Section: State Of the Art: Software Deployment Systemsmentioning

confidence: 99%

A Graph-Based Approach for Contextual Service Loading in Pervasive Environments

Hamida

Mouël

Frénot

et al. 2008

On the Move to Meaningful Internet Systems: OTM 2008

View full text Add to dashboard Cite

Abstract. The pervasive computing paradigm promises great abilities whenever and wherever a user goes. However, as people are shifting from the desktop to more resource-constrained devices, issues due to scarce resources may appear preventing from the use of the available services and applications. In this paper, we consider the adaptive deployment as a mainstream solution to suit service-oriented applications to different context constraints such as the users requirements, the hosts resources, the services properties and the surrounding environments. We put forward a graph-based deployment approach for service-based applications so as to make these applications adaptable to the runtime contextual constraints. We introduce the AxSeL architecture, A conteXtual Service Loader in which services and their dependencies are represented as a bidimensional graph. The dependency graph is then coloured through a process taking into account the devices, services and users constraints. This process aims to choose to load or not a service according to its execution context. A prototype based on Java and OSGi technologies is implemented in order to demonstrate and evaluate our approach.

show abstract

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

Cited by 38 publications

References 20 publications

Constraint-Based Deployment of Distributed Components in a Dynamic Network

Constraint-Based Deployment of Distributed Components in a Dynamic Network

Software Deployment, Past, Present and Future

A Graph-Based Approach for Contextual Service Loading in Pervasive Environments

Contact Info

Product

Resources

About