We present our approach for deploying and managing distributed component-based applications. A Desired State Description (DSD), written in a high-level declarative language, specifies requirements for a distributed application. Our infrastructure accepts a DSD as input, and from it automatically configures and deploys the distributed application. Subsequent violations of the original requirements are detected and, where possible, automatically rectified by reconfiguration and redeployment of the necessary application components. A constraint solving tool is used to plan deployments that meet the application requirements.
@cite_0: Introduction SmartFrog was conceived to overcome the myriad issues related to incorrect configuration of complex, distributed systems. Applications such as multi-tier web-service systems are composed of multiple software components, typically running across multiple nodes. Several elements must be in place for the system to be considered correctly configured: first, each component of the system (e.g. database, application server) must be configured correctly with the required software settings. Secondly, each system component must be correctly bound to the other system components – e.g., the application server must be connected to the correct database. Thirdly, system components must be started in an appropriate sequence, such as starting the database before the application server. In addition, there are often setup tasks that must precede the startup of the main system, and cleanup tasks that must occur after the system is shut down. Incorrect configuration in one or more of these aspects is a very frequent source of system malfunction [1]. In general, such configuration aspects are found in multiple formats, in multiple places. Changes to configurations are made one-by-one, in many places in the system, without regard for how configuration parameters are interdependent. Configuration changes are made in an ad-hoc fashion, by multiple people at multiple times (e.g., setting factory defaults, making installation-time changes, making operation-time changes), and there is little traceability or repeatability. So, the problem is firstly how to express all of the configuration information in a consistent fashion, which recognizes the relationships between configuration parameters, avoids duplication, allows for correctness-checking, and allows the system configuration to be changed at different stages in its evolution. Secondly, how to take this more powerful expression of the system configuration and use it to automatically, repeatably and flexibly ignite the complete system. SmartFrog addresses these problems by offering a powerful and consistent way to capture system configurations, an automatic deployment infrastructure which can repeatably realize the systems described and a component model to manage the deployed applications though their lifecycle.
@cite_16: This article addresses the utilization of the component-based approach for building and executing a distributed application that can offer services over a set of heterogeneous and possibly volatile devices. We propose to rely on a hierarchical component model and present a method for distributing a component that makes the set of its interfaces available everywhere. The runtime system associated with this model allows disconnections of devices to be reflected on the architecture of the component by disabling some of its interfaces while allowing it to perform in a degraded mode.
The SmartFrog framework @cite_0 is similar to this work in its motivation, to address the problems of describing, deploying and managing complex, distributed assemblies of software components. SmartFrog consists of a declarative language for describing component collections and component configuration parameters, and a runtime environment which activates and manages the components to deliver and maintain running systems. In SmartFrog each component transitions through life-cycle states in lock-step with all other components in the deployment. The SmartFrog life-cycle service model is similar to @cite_16 which also utilizes constraint-based deployment. However, they advocate propagative deployment and maintain global constraints through the use of a consensus algorithm.