An Autonomous Engine for Services
Configuration and Deployment
Félix Cuadrado, Member, IEEE, Juan C. Dueñas, Member, IEEE Computer Society,
Rodrigo García-Carmona, Member, IEEE
Abstract—The runtime management of the infrastructure providing service-based systems is a complex task, up to the point where manual operation struggles to be cost effective. As the functionality is provided by a set of dynamically composed distributed services, in order to achieve a management objective múltiple operations have to be applied over the distributed elements of the managed infrastructure. Moreover, the manager must cope with the highly heterogeneous characteristics and management interfaces of the runtime resources. With this in mind, this article proposes to support the configuration and deployment of services with an automated closed control loop. The automation is enabled by the definition of a generic information model, which captures all the information relevant to the management of the services with the same abstractions, describing the runtime elements, service dependencies and business objectives. On top of that, a technique based on satisfiability is described, which automatically diagnoses the state of the managed environment and obtains the required changes for correcting it (e.g. installation, service binding, update or configuration).The results from a set of case studies extracted from the banking domain are provided to valídate the feasibility of this proposal.
Index Terms—Autonomic Systems, Model-Based Management, Satisfiability, Service Configuration.
1 INTRODUCTION
T
HE Service-Oriented p a r a d i g m aims atrevolutioniz-ing h o w software is developed, assembled a n d p u t into production. Vendor independence, dynamic composition, runtime adaptation a n d Internet-wide Communications are key elements for the success of this paradigm. Services are in essence distributed applications w h o s e functionality is described by well-deñned interfac-es, r u n n i n g on logical containers over networked com-puters.
N o w a d a y s services seem to be the preferred w a y to implement d o m a i n specific processes in industry, as ser-vices can be composed a n d connected across organiza-tional boundaries. Thus, business level requirements on company processes, such as those related to reliability, security or performance m u s t be supported by the servic-es taking part in the procservic-essservic-es. However, this doservic-es not change the fact that services are provided by software components that r u n over service execution platforms (including containers, computers a n d network elements). Therefore, those requirements imposed on services are translated to their execution infrastructure.
This context presents múltiple challenges to ensure services a n d service environments fit to the business re-quirements they have been designed for. M a n a g e m e n t operations are specially affected by those factors as ser-vices implementations, as well as their infrastructure, frequently change. The challenges for a u t o m a t i n g the change operations to enterprise services include m a n a g -ing the complexity a n d heterogeneity of the execution
The authors are with the Departamento de Ingeniería de Sistemas Tele-máticos, Escuela Técnica Superior de Ingenieros de Telecomunicación, Universidad Politécnica de Madrid, Madrid, Spain. E-mail: {fcuadrado, jcduenas, rodrigoj@dit.upm.es.
environments, reasoning about all elements r u n n i n g over the distributed platform, taking care of the existing de-pendencies, relationships a n d constraints between all of them and ensuring that the m a n a g e d environment com-plies w i t h the defined business objectives.
Heterogeneity, distribution a n d awareness of outer elements greatly complicate the tasks of deployment a n d runtime operation. These factors are taken into account by operation tools following the traditional m a n a g e m e n t p a r a d i g m a h u m a n operator w o r k i n g w i t h a m a n a g e -m e n t consolé. However, reasoning activities such as adaptation a n d decisión m a k i n g on the information pro-vided by the services platform are seldom automated, resulting in a true bottleneck for the operation of services.
In this article w e present our results on improving the automation capabilities of the m a n a g e m e n t infrastructure for heterogeneous, distributed services infrastructure. The m a i n contribution of this w o r k is the characterization of the correctness of a distributed system as a quantifiable formula (including functional aspects, logical d e p e n d e n -cies, restrictions over the h a r d w a r e platform, a n d busi-ness objectives of the whole environment). Building on top of that, w e have designed a satisfiability-based resolu-tion engine that is able to automatically reason about that information in order to determine the required m a n a g e -m e n t operations. As a n additional contribution w e present a set of models that can be obtained by instru-mentation agents a n d contain all the required information about the runtime platform a n d the available services, serving as input of the previous elements.
w e use in our solution a n d outlines some key m a n a g e -m e n t definitions built over the-m, such as environ-ment changes, as well as desired, stable a n d correct configura-tions. The next one details the algorithms for reasoning u p o n them autonomously, obtaining if possible a solution for reaching a desirable a n d stable configuration; this solution m u s t also fit other restrictions a n d constraints imposed by the services platform infrastructure. In Sec-tion 5 the proposal is validated through a set of case stu-dies derived from the banking domain. Finally, the last section reflects on the explained aspects, focusing on the impact a n d potential extensions to this work.
2 BACKGROUND INFORMATION
In this section w e will analyze the underlying challenges for a u t o m a t i n g the service m a n a g e m e n t tasks a n d eva-lúate the existing approaches a n d alternatives for ad-dressing them.
2.1 Automated Services Management
The Service-Oriented Architecture (SOA) p a r a d i g m [1][2] is fundamentally changing the w a y systems are created a n d operated, as it pavés the w a y for reuse a n d collabora-tion in a dynamic, distributed context [3]. However, in order to truly seize its potential, all the software engineer-ing disciplines m u s t provide solutions to the n e w chal-lenges which have emerged, ranging from service design to their dynamic runtime adapta tion [4].
In this article w e will focus on the intermediate a n d latter stages of the service lifecycle: the deployment (or p r o -visioning) of the services a n d their runtime management, including reconfiguration for corrective maintenance. The complexity of these activities lies in the need to s u p p o r t the runtime a n d generic characteristics of SOA while at the same time coping w i t h the complexity a n d hetero-geneity of the supporting infrastructure. In this context, it is fundamental to provide m e t h o d s a n d techniques that improve the automation capabilities of the m a n a g e m e n t systems, as m a n u a l operations are no longer cost-effective a n d greatly impact the agility of service-based applica-tions.
A u t o m a t e d m a n a g e m e n t has been associated recently w i t h the autonomic computing paradigm. This approach aims to lessen the b u r d e n on system administrators by enabling a completely a u t o m a t e d m a n a g e m e n t of the infrastructure [5]. The potential advantages that can be obtained by this p a r a d i g m are usually expressed in the form of four distinct self-management capabilities.
Self-Configuration consists in the automatic installation a n d
configuration of the components of a n autonomic system, w i t h o u t needing h u m a n intervention. A Self-Healing sys-tem diagnoses itself continuously, detecting functional failures, a n d reconfiguring itself in order to correct them.
Self-Optimization is achieved whenever the system
moni-tors its resources w i t h respect to defined requirements a n d policies, continuously configuring them in order to improve its service-level quality. Finally, Self-Protection capabilities enable the system to proactively identify intruders a n d defend from their attacks. Any system s u p
-porting one of those self-capabilities is said to present a u t o n o m o u s behavior. The importance of those aspects for service m a n a g e m e n t is highlighted in [6].
The behavior of a completely a u t o m a t e d (autonomous) m a n a g e m e n t system is often represented w i t h the concept of a closed control loop. The m a n a g e r monitors the m a -naged system through a sensor channel, analyzes its state (including all the relevant information) a n d automatically obtains a n d executes the required changes through a n actúator channel [7].
As regards the autonomic s u p p o r t of both deployment a n d reconfiguration of services, there is no single initia-tive that directly addresses these topics. Several contributions have been proposed to automate network m a n a g e -m e n t through the use of policies a n d ontologies, w i t h PMAC [8] a n d FÓCALE [9] being the prime representa-tives. However, these initiatives do not address the ser-vice m a n a g e m e n t aspects. Nonetheless, at application and service level some contributions can be found w h i c h bring self-management capabilities to specific elements of the services domain, such as a single application server [10] or a h o m e service gateway [11]. However, in those cases the distribution aspects of a service-based system are not supported. Finally, there are several interesting w o r k s which propose autonomic architectures to support runtime services m a n a g e m e n t [12] [13]. However, these alternatives are tied to a specific m i d d l e w a r e technology, the CORBA distributed object model, which complicates their adoption for a generic service infrastructure m a n -agement system.
elements. Those abstractions greatly simplify the imple-mentation of a u t o m a t e d solutions, but they m u s t be com-plemented in order to fully capture the required informa-tion a n d restricinforma-tions for a n effective service m a n a g e m e n t .
2.2 Applications of Satisfiability
In order to cióse the control loop the m a n a g e r m u s t be able to automatically process all the m a n a g e m e n t infor-mation a n d find the required correction operations w h i c h will be applied. Recently Satisfiability (SAT) has gained traction as a technique for efficiently finding solutions to problems w i t h very large search spaces. Some problems expressed in SAT include automatic test pattern genera-tion, r e d u n d a n c y identification a n d eliminagenera-tion, FPGA (Field Programmable Gate Array) routing, or m o d e l cor-rectness checking [21]. Over the following p a r a g r a p h s w e will provide some basic information about this technique a n d highlight its use on some specific problems closely related to the context of this article.
The SAT problem consists of finding a n assignment to the variables of a Boolean function that evaluates it to true [22]. In addition to the base SAT problems, there are sev-eral variants such as MaxSAT, consisting of finding the m á x i m u m n u m b e r of positive literals of the formula, or Pseudo Boolean SAT, w h i c h supports inequality clauses w i t h linear expressions over Boolean variables, as well as the definition of a n optimization function which will be maximized. In spite of the NP-complete complexity of the problem family, current generation solvers are able to find a suitable solution for a large subset of them in a very short period of time.
M o d e r n solvers are generally based on the DPLL (Da-vis-Putman-Logemann-Loveland) algorithm [23], w h i c h provided a sound a n d complete w a y of obtaining the solution to the problem of satisfiability. This base algo-rithm has been heavily optimized in the recent years, by adopting strategies such as conflict analysis techniques (which try to obtain the reason for a n assignment con-flict), conflict-driven learning (adding clauses to avoid the same conflict in the future) or the incorporation of heuris-tics to detect conflicts before they occur a n d optimizing the w a y the search space is explored [24], which has greatly extended the domains w h e r e this technique can be applied.
There is one specific field of application of SAT which has led to its consideration for the proposed algorithm: the support for dependency resolution in installation processes, first a d o p t e d by the OPIUM prototype [25]. The SAT applicability to this field has been demonstrated since 2008, w i t h a refinement of this technique being a d o p t e d for p o w e r i n g Eclipse's p2 u p d a t e m a n a g e r oper-ations (install, u p d a t e a n d uninstall) [26]. The main inno-vation of this example is the use of a Pseudo Boolean SAT solver, which allows to express linear inequalities in addi-tion to SAT first order constraints, a n d also supports the definition of a n optimization function to obtain m o r e satisfactory results. As it is described in [27] this is a n increasing trend, w i t h both the dependency m a n a g e m e n t of the M a v e n 3.0 reléase, a n d the openSuse 11.0 Linux distribution being addressed by this technique.
SAT solvers are also applied for automatically obtain-ing valid configurations of network e q u i p m e n t such as routers a n d bridges [28]. By modeling the relevant charac-teristics of every manageable element a n d defining their restrictions using propositional logic, these engines can automatically find correct configurations for each ele-ment, or diagnose the correctness of a preset configura-tion. A n alternative approach for the same problem is addressed in [29], w h e r e instead of modeling the problem as a SAT, the solution is based on the tool Alloy. This tool provides a solver that, given a m o d e l definition w i t h first order logic constraints, obtains a n instance of the model matching the restrictions. While Alloy internally uses a SAT solver, the tool abstracts users from the conversión to a SAT problem a n d SAT results interpretation steps. The SelfSoC [29] approach provides another example of the use of Alloy, addressing the problem of dynamic component assembly similar to the previously presented d e p -loyment solutions.
Before e n d i n g this overview w e will mention another interesting application of SAT, in this case for generating test cases of a complex system configuration [31]. This w o r k highlights h o w this technique can be applied to find efficiently solutions to a search space w h e r e múltiple constraints over the correct solution are defined.
As a conclusión, none of the analyzed initiatives ad-dresses the problem of a u t o m a t i n g the m a n a g e m e n t of a service infrastructure, although SAT has been successful-ly applied to affine problems (dependency m a n a g e m e n t a n d constraints-based configura tion search).
3 A MODEL FOR SERVICES DEPLOYMENT AND
CONFIGURATION
As it has been previously described, a n autonomic service m a n a g e r m u s t be based on a m e t a m o d e l that captures all the relevant m a n a g e m e n t information of a heterogeneous infrastructure in a generic w a y . These abstractions are vital, as m a n a g e m e n t decisions a n d actions will be based exclusively on the modeled concepts a n d relationships. This section describes the main model definitions, the relevant information a n d the inferred environment stabil-ity a n d correctness definitions, which will completely characterize the task to be solved by the a u t o m a t e d sys-tem.
3.1 Model Foundations
The proposed information m o d e l is generic a n d object-oriented, building over the base concept of Resource. This base definition characterizes a manageable element (de-scribed w i t h a set of Properties) w i t h a ñame, a n optional
versión a n d a type. The type concept is fundamental as it
classifies a n initially u n k n o w n set of resources. This al-lows u s to define expressive constraints in a generic w a y which can be automatically processed. These concepts constitute the c o m m o n ground for most of the analyzed standards, including D&C, SDD a n d MUWS (as it is de-scribed in [32]), making the proposed solution compatible w i t h them.
Resource
ñame: string type: rType visib: visibKind
0..*
properties
Property
ñame: string valué: string <h
TV
o:expc :edResources
DeploymentUnit
versión: string
dependencies
Depende ncy
ñame: string type: rType
versionRange: String [0..1] id: int
v boundProperties
visibKind local = 0 host= 1 context = 2 envlronment= 3
ContextAwareProperty
expression: string
constraintKind
none = 0 not= 1 exclusive = 2
Constraint
ñame: string [0..1] type: rType klnd: ConstraintKind
propertyConstraintKind
MÍNIMUM = 0 MÁXIMUM = 1 ATTRIBUTE = 2 SELECTION = 3 CONSUMPTION = 4
propConstralnts
BoundProperty
providerName: string dependantName: string
PropertyConstraint
ñame: string
kind: PropertyConstraintKind argument: string
Fig. 1 The Logical Information Model
model of the services configuration and deployment in-formation, detailing its inferred stability conditions for an automated diagnosis. This is an evolution of our previous w o r k on modeling to characterize virtualized environ-ments [33] a n d support installation processes [34], enabl-ing an autonomic m a n a g e m e n t of the services infrastruc-ture.
Resource type attributes belong to the rType class,
which provides increased expressiveness over individual classifications. A n rType object contains a hierarchy of types, w i t h progressively more specific categories. For serialization purposes, rType instances are represented similarly to Java packages. This way, a n e t w o r k card of type "hw.net.interface.ethernet" belongs simultaneously to the types {"hw", "hw.net", "hw.net.interface", "hw.net.interface.ethernet"}.
The presented abstractions can be divided in two com-plementary groups, d e p e n d i n g if they define logical or runtime information. Both are built over the same re-source abstractions a n d are tightly integrated: The logical model describes the services a n d artifacts which m u s t be considered over the deployment a n d configuration activi-ties, while the runtime information characterizes all the m a n a g e d elements from the runtime environment, in-cluding the instantiation of the logical elements.
3.2 Logical Information Model
The logical information model characterizes the services a n d deployable artifacts that provide them. This model provides a deployment a n d configuration perspective of the artifacts obtained from the service development process. The presented abstractions keep the require-ments of the applications a n d services that have been taken into account over the analysis, design, implementa-tion a n d testing phases. Fig. 1 shows the m a i n elements of this model. The root element of the model is the
Deploy-ment Unit, a subclass of Resource representing each
indi-visible artifact which provides functionality w h e n provi-sioned to the environment (typical units are WAR a n d
Property
ñame: string valué: string
State
STARTED
STOPPED
3
globalProperties Environment
—z~, • ñame: string
properties globaJResources 0..
Resource
ñame: string type: rType visib: visibKind
Binding
id: int 0..
bindingsX
ref
nodeResources Node
exportedResources
contaitierResources
RuntimeUnit
versión: string
state: State units
Container
supptdTypes: rTypeO versión: string
Fig. 2 The Runtime Information Model
EAR JEE deployable files, OSGi JAR Bundles a n d pack-aged SQL scripts). In addition to the ñame a n d versión, the unit's type identifies the kind of packaging (i.e. the format of the file).
A Deployment Unit aggregates functionality, such as services, libraries, w e b interfaces a n d business logic components, which will be available w h e n the unit is d e p -loyed to the runtime environment. These elements are modeled as Resources. The typing mechanism allows a rich characterization of different elements with the same c o m m o n concepts, and a visibility attribute controlling w h a t elements from the environment can access them. Finally, the infernal configuration of the Deployment Unit is reflected as a set of Properties (e.g., the connection pa-rameters for accessing an external datábase).
3.3 Runtime Information Model
The runtime information model defines the resources which constitute the m a n a g e d environment a n d their relationships, ranging from h a r d w a r e assets (such as h a r d disks, RAM m e m o r y or network devices) to software elements (such as available ports from a machine, operat-ing system and application server services, or a directory service). Fig. 2 depicts its main elements, which describe a hierarchical Resource structure. This presents a clear m a n -agement view of the infrastructure a n d running services, w i t h specific elements representing the key concepts of the system (nodes, containers, units).
The root element is the Environment, which represents the runtime environment itself. The Environment is com-posed by Nodes, global Resources (such as a DNS naming service, or third-party remotely available Web Services) a n d global configuration Properties.
Nodes model Resources with computing capabilities
(like PCs or servers). A Node comprises all the h a r d w a r e a n d low-level software layers of the device (such as the operating system). The specific components, libraries, communication channels a n d devices are abstracted as
nodeResources. O n top of that substrate, a Node hosts any
n u m b e r of Containers.
A Container is the base execution platform for the a p
Containers have a ñame (unique over the environment), a type classifying it (examples include "contain-er.database.jdbc.oracle" or " container.]ee.websphere") a n d a versión. These elements provide platform services to the
hosted units, which are expressed as a set of Resources (typical application server resources w o u l d be Datasource connections, JMS queues, or remote system connectors).
Because of its key role in service configuration m a n -agement, the hosted runtime instances of the Deployment
Units are explicitly represented in the model. The
instan-tiation of a Deployment Unit in a Container from the envi-r o n m e n t cenvi-reates a Runtime Unit. The suppoenvi-rtedTypes attribute of the Container restricts which types of units can be deployed over it.
A Deployment Unit shares w i t h all its Runtime Unit in-stances the identity information (ñame, versión a n d type), as well as the initial configuration Properties a n d exported
Resources. This allows keeping the traceability between
the t w o models. Runtime Units also have a state, indicating its lifecycle stage.
3.4 Unit Configuration Restrictions
Up to this point, w e have explained the m a i n entities of the model, the contained information a n d its relation-ships. These constructs provide u s w i t h all the observed information for m a n a g i n g the system. However, these concepts are not sufficient for enabling a n autonomic m a n a g e m e n t . It is also necessary to define the configura-tion restricconfigura-tions of each m a n a g e d element. Following w i t h the logical a n d runtime partition of model concepts the restrictions will be defined at the Deployment Units a n d will be validated at each one of the runtime instances. For illustrating these concepts, a n exemplary Deployment Unit instance, s h o w n in Fig. 3, will be used over this section to provide specific examples of the restrictions imposed by model instances.
Deployment Units are not i n d e p e n d e n t entities; w h e n
-ever they are instantiated at the environment they colla-borate w i t h other resources to provide the final services. Therefore, those interactions m u s t be explicitly reflected as part of the model, allowing its automatic check. We have identified t w o types of relationships d e p e n d i n g o n the type of elements. The relationships between units (such as service provider / consumer) are defined as
Dependencies. O n the other hand, some artifacts require
additional capabilities from the execution environment
Resources for a correct operation (such as a TCP port).
DS Credit: Constraint
type:
s w . j d b c . d a t a s o u r c e kind: none
Product Data A c c e s s : Deployment Unit
v e r s i ó n : 1.3.1 t y p e : unit.ear
p r o d u c t data dao: Resource v e r s i ó n : 1.3.1 t y p e : sw.service.dao v i s i b : local
type: hw.memory.ram kind: none
user data: Dependency
id:0
v e r s i o n R a n g e : [1.3.0, 1.4.0) type: sw.service.bean
p r o d u c t data w s : Resource
v e r s i ó n : 1.3.1 t y p e : sw.service.ws v i s i b : e n v i r o n m e n t
availableT Propertv Constraint kind: CONSUMPTION argument: 256M
service-url: Context A w a r e Propertv
e x p r e s s i o n : http://${ip}:${http.port}/Product
Fig. 3 Sample Deployment Unit instance
Those conditions are expressed w i t h Constraints. Fig. 1 shows h o w the model allows Deployment Units to express these restrictions.
A unit can define any n u m b e r of Dependencies, with each one d e m a n d i n g the access to a runtime Resource provided by another unit. The Resources that can satisfy the dependency are identified by defining a filter consist-ing of ñame, type a n d optionally versionRange. For a re-source to match the filter, both ñ a m e s m u s t be equal, the resource versión m u s t be contained in the presented range, while the filter type m u s t be a subset of the re-source type. For the example depicted at Fig. 3, the satis-fying resource m u s t be n a m e d user_data, contain the type
sw.service.bean a n d have a versión valué between 1.3.0
(inclusive) a n d 1.4.0. In addition to this, the Runtime Unit definition contains in the Bindings attribute the informa-tion about h o w Dependencies are satisfied at the runtime environment. This w a y , each logical Dependency m u s t result in a runtime Binding, containing a reference to the satisfying unit. In addition to the filter restriction, the b o u n d Resource m u s t be accessible (as restricted by the
Resource visibility attribute) to the d e p e n d a n t Resource in
order for the Binding to be valid. The addition of Bindings to the runtime information model builds a dependency overlay structure over the runtime containment hie-rarchy. This environment-wide dependency layer reflects real restrictions which m u s t be considered in order to safely apply any changes over already existing Runtime
Units, as well as tracing the impact derived from any
change to the runtime elements. Therefore, the expressivi-ty of the runtime model is considerably improved by this addition.
Constraints are declared in the Deployment Unit
defini-tion w i t h a similar mechanism. Each Constraint element will d e m a n d the presence of a specific Resource at the unit's execution environment (composed by its r u n t i m e hosts: the Container, Node a n d Environment). Similar to the previous restriction, valid Resources are identified by a filter composed by a type a n d optionally a ñame. The ex-ample shows t w o Constraints representing different re-strictions. The Constraint depicted at the top-left córner represents a basic definition; it d e m a n d s the existence of a
Resource n a m e d DS_Credit, of type sw.jdbc.datasource. This Constraint models a JDBC Datasource Connection, which
is provided by standard Java Enterprise Edition Applica-tion servers (modeled as Containers), a n d can be confi-gurad through a m a n a g e m e n t operation.
However, the model for Constraints provides addition-al expressivity. First, the kind attribute supports t w o va-riants to the default (of kind none) restrictions. Exclusive
Constraints d e m a n d n o other Runtime Unit accesses
simul-taneously the same Resource (representing scenarios such as the reserva tion of a TCP machine port). Not Constraints declare a n incompatibility w i t h the identified Resource, which cannot be part of the unit execution environment
Constraints are based in the restrictions defined in the
D&C model. The kind attribute defines w h a t type of check m u s t be applied ( m i n i m u m a m o u n t - at least the speci-fied valué, m á x i m u m amount, selection from a list of valid valúes, a n d consumption of numeric resource), a n d the argument attribute provides the valúes to be compared with. They represent restrictions such as h a r d disk capaci-ty usage, or m i n i m u m processor speed. The RAM
Con-straint from Fig. 3 shows another example of the numeric
consumption kind. The definition contains a Property
Constraint d e m a n d i n g the consumption of 256M of the
property n a m e d avaüable of a Resource of type
hw.memory.ram. As in the other example, the satisfying Resource m u s t belong to the execution environment of the
unit. This Constraint w o u l d be typically satisfied by a
Node Resource representing the RAM m e m o r y state.
These restrictions allow declaring w h a t m u s t be avaü-able at the runtime environment in order for the Runtime
Unit to w o r k correctly. In addition to that, the defined
model provides abstractions that further s u p p o r t auto-m a t e d service auto-m a n a g e auto-m e n t . This is achieved by linking the infernal configuration of a Runtime Unit to the envi-r o n m e n t state. D e p e n d i n g on the envi-runtime elements which provide the configuration valúes, two types of restrictions can be established to Property valúes. Bound Properties link
Property valúes between the Runtime Units connected w i t h
a runtime Binding. A Bound Property m a n d a t e s that the valué of the Property from the d e p e n d a n t unit n a m e d
dependantName m u s t be equal to the valué of the Property
n a m e d providerName from the Resource of the b o u n d unit. This allows automatic support of scenarios such the au-tomatic configuration of a connection URL to access a Web Service provided by another Runtime Unit.
The second type of restrictions is expressed through a
Property subclass n a m e d Context-Aware Property. This
specialized subclass specifies the expression attribute that defined h o w the Property valué can be obtained by com-posing valúes from Properties of their execution environ-m e n t (e.g. retrieving the teenviron-mporal folder froenviron-m an applica-tion server). The example unit shows h o w this mechan-ism can be used for infernal configuration enforcement. In this case the valué of the Context-Aware Property service-url will be obtained by substituting in the provided ex-pression the two variables (ip a n d http-porf). Their valúes are obtained from the execution context Resources.
3.5 Environment Stability Definition
The definitions of Constraint, Property Constraint,
Depen-dency, Bound Property a n d Context Aware Property
com-prise every restriction that can be expressed at the logical definition over the configuration of a Runtime Unit. They specify w h e r e the unit can be deployed, w h a t other units can be dynamically b o u n d to it a n d w h e t h e r the valúes of its properties ha ve correct valúes.
W e have defined the concept of stability for reflecting these configuration requirements. An existing Runtime
Unit is stable if it is correctly configured at the
environ-m e n t (assuenviron-ming for environ-m a n a g e environ-m e n t purposes that it w o r k s properly). Runtime Unit stability is defined the following way: A Runtime Unit is stable if it is instantiated at a
com-patible Container a n d every configuration restriction de-fined at its corresponding Deployment Unit model is met by the current runtime environment configuration.
The stability concept is extensible to the remaining resources of the Environment (Containers a n d Nodes). H o w -ever, as the model does not define any restriction about their configuration, they are always stable. Finally, w e can define stability for the complete Environment configuration by combining the stability checks of each of its m e m -bers. Consequently, an Environment configuration C / w i l l be stable if every Runtime Unit u ,11 GCfis stable, as s h o w n in (1).
n
StabilityiCf) = /\stability(Ui) (1)
i=i
The stability formula is fundamental for m a n a g e m e n t automation, as it dictates whether the system is adequate-ly configured or not. Consequentadequate-ly, this function m u s t be obtainable a n d evaluable just from a runtime environ-m e n t environ-model a n d a set of logical Deployenviron-ment Unit defini-tions. The formula is composed by múltiple restrictions, w i t h each of them needing to be matched for a global stable verdict. Each individual restriction is originated by one of the existing Runtime Units, so the formula can be built by combining the restrictions from each existing unit.
The stability restrictions related to a Runtime Unit are obtained in the following w a y . All Units impose the host compatibility restriction (mandating that the Container w h e r e the unit is executing supports the unit's type). Every remaining restriction is specified in the Deployment
Unit model from which the Runtime Unit has been
instan-tiated. Specifically, each Constraint, Property Constraint,
Dependency, Bound Property a n d Context Aware Property,
can be directly translated to a function that will be eva-luated to true or false w h e n its variables are substituted w i t h the runtime valúes.
In order to illustrate h o w the environment stability function can be obtained a n d evaluated w e will use the example Environment presented at Fig. 4. It is composed by a Node, a Container a n d two Runtime Units. For space reasons, n o d e resource Properties are represented as attributes. This Environment will be stable if both Client Data Access (CDA) a n d Product Data Access (PDA)
Run-time Units are stable. First, each unit imposes a restriction
about its compatibility with the host Container (identified w i t h the function HostOf).
unit.ear e HostOf (PDA).supportedTypes (2)
unit.war e HostOf\CDA).supportedTypes (?)
The remaining stability restrictions from each unit are obtained from its corresponding Deployment Unit model. W e will focus on PDA, w h o s e logical definition w a s pre-sented in Fig. 3. Its m o d e l includes five elements that restrict the unit configuration, resulting in the following five blocks of stability constraints.
1. Stability restriction from Constraint C l (DS Credit).
^Resource r1,r1 e ExecutionContext(PDA) I
r, ñame = DS Credit A (4)
service-url: Property
valué: http://138.4.12.200:8081/Product
p r o d u c t d a t a w s r Resource versión: 1.3.1 type: sw.service.ws visib: environment
product_data_dao~ Resource versión: 1.3.1 type: sw.service.dao visib: local
M^
client data: Resource versión: 1.3.4 type: sw.service.bean visib: local
Product Data Access: Runtime Unit
versión: 1.3.1 type: unit.ear visib: local state: STARTED
•
idO: Bindinq ref
Client Data Access: Runtime Unit
versión: 1.3.4 type: unit.war visib: local state: STARTED
Gf_N1: Container
type: container.jee.gf versión: 2.1 supptdTypes: ear, war http.port:8081
DS Credit: Resource
type: sw.jdbc.datasource pool-size: 5
3ZZN
env: Environment
lancard: Resource
type: hw.net.lan.iface visib: context ip: 138.4.12.200 speed: 100M
RAM mem: Resource
type: hw.mem.ram.ddr visib: context available: 8G speed: 800M
Fig. 4 Sample Runtime Environment Configuration
2. Stability restriction from Constraint C l (DS Credit).
3Resource r2,r2 eExecutionContext{PDA) | /§\
r2.type c: hw.memory.ram
3. Stability restrictions from Property Constraint PC of C2, of kind consumption. Property Constraint restric-tions inherit the scope from the parent Constraint restrictions (in this case C2).
(6)
SProperty p,pe r2.properties | p.name = available
The second restriction is determined by the con-sumption kind. As these restrictions are competi-tive, the group of Runtime Units {w,},/ e [l,«] con-s u m i n g Property p of Recon-source ri, m u con-s t be obtained. The set {c } contains the a m o u n t (argument attribute) consumed by each resource (256 for PDA).
y V j <p.valué (7)
Stability restrictions from Dependency DO, w i t h Runtime Unit BU being the one referenced by the
Binding idO of PDA:
BResource r,,r, e \BU\[jBU.exportedResources | r^.versione [l.3.0,1.4.0)A
r3type c swservicebean
(8)
Dependencies also impose a visibility stability check. In this case, as the Resource r¡ of BU is visi-ble locally, the following restriction is defined (mandating the same Container for both Units).
HostOF(BU) = HostOF(PDA) (9)
Stability restriction for Context Aware Property ser-vice-url: The valué of the service-url Property from PDA m u s t be equal to the expression attribute, w i t h
the two defined variables substituted by the cor-rect valúes. This way, ${ip} m u s t be substituted by the valué of a Property n a m e d ip of a Resource in the PDA execution context (in case there are m ú l -tiple matching properties, the nearest in the con-tainment hierarchy will be the one w h o s e valué is taken). The ${http.port} variable m u s t be substi-tuted the same way. Additionally, the Context
Aware Property imposes a n implicit restriction: the
execution context of the unit m u s t contain re-sources w i t h properties n a m e d " i p " a n d
"http.port", so that the valué can be successfully
obtained.
The obtained stability restrictions can be evaluated by assigning to the variables the actual runtime environment valúes. From w h a t w e can discern, the environment de-picted at Fig.4 is stable, as it addresses every k n o w n sta-bility restriction.
Although only a specific example has been described, the same m e t h o d can be applied to obtain the stability formula of any combination of a runtime environment m o d e l a n d a set of definitions of the corresponding
Dep-loyment Units. The formula will be composed by a n u m b e r
of stability clauses derived from the logical definitions, a n d it will be evaluated by substituting the valúes of the existing runtime resources.
To s u m u p , the described information model defines a rich set of restrictions for software applications a n d ser-vices that can be clearly evaluated against the runtime state through the stability formula. This is achieved by defining a c o m m o n set of abstractions (the Resource con-cept from WSDM a n d specially D&C, a n d the Deployment
/Runtime Unit concept) for both logical a n d runtime
modeling, which h a d not been simultaneously covered by the analyzed specifications.
The logical model characterizes logical units a n d ser-vices, extending D&C a n d SDD restrictions in order to provide a complete set of abstractions. The main a d d i -tions are Resource-based Dependencies a n d configurable
Properties, w h o s e correct valúes are extracted from either
the Runtime Unit Bindings or its execution context.
The runtime model extends D&C in order to improve its representation of r u n n i n g applications and services. In addition to Runtime Units, the Container concept explicitly characterizes the direct execution platform of runtime software a n d services, while Bindings enable runtime traceability of logical Dependencies. Logical definitions are instantiated into runtime elements, a n d their restrictions can be validated through the existing resources.
3.6 Environment Correctness Definition
In the previous sections w e have presented a m o d e l which provides a complete view of the m a n a g e d envi-ronment, as well as a set of abstractions for diagnosing its
stability. This concept is very important for a u t o m a t i n g
m a n a g e m e n t activities, as it allows diagnosing the run-time environment w i t h a check against the modeled in-formation.
deter-mine w h e t h e r the environment elements have a stable configuration, w e m u s t also be able to k n o w if the system is fulfilling the desired business objectives. In other w o r d s , w e m u s t k n o w if the environment is doing what it
must and not doing what it must not do.
We h a v e m a d e this requirement possible by incorporating a third branch of concepts to the presented model: the Objectives. These elements represent conditions w h i c h m u s t be met by the existing environment in order to p r o v i d e the desired functionality.
Objectives refer to Resources in order to preserve
consistency a m o n g the information models. Two types of
Objectives h a v e been introduced: EXISTS(r) d e m a n d s the
presence of a Resource in the environment, while its opposite condition, NOTEXISTS(r), forbids its existence. This w a y , the functional requirements of the r u n t i m e infrastructure are expressed t h r o u g h Resources (e.g. w h a t services m u s t be running).
Once these elements have been introduced, Desirability of a n environment configuration Cf, w i t h a n associated set of defined Objectives O, can be defined analogously to the previous concept of environment Stability (10).
\o\
Desirability(Cf) / \ 0 i , 0 i
e 0
(10)Finally, it is possible to formalize the requirements for any environment configuration to be correct as a combi-nation of these t w o factors. W e define the Correctness of a configuration as the state in w h i c h that configuration is at the same time desirable a n d stable (11).
Correctness (Cf} = StabíIíty(Cf) A DesírabíIíty{Cf) ( H )
As the combination of logical resources, r u n t i m e re-sources a n d objectives encapsulates all the information relevant to the m a n a g e m e n t of any specific environment, w e will use the term Management Domain to refer to the information collectively. A Domain D is a triplet com-posed by the current configuration of the environment C/o, a Logical Resource Base (LRB) containing the defined
Deployment Units a n d the defined Objectives O.
D = (Cf0,LRB,O) (12)
As w e have explained over these sections, the correct-ness formula of any Domain is obtained just from these three models. It is composed by a set of restrictions that m u s t be fulfilled, w h i c h can be individually evalúated.
3.7 Runtime Changes
The previous section has presented the concept of
Do-main. From a m a n a g e m e n t view, the Domain is a m u t a b l e
entity, as all its elements (logical definitions, objectives a n d r u n t i m e resources) can suffer modifications w i t h the passing of time, potentially affecting the Correctness.
D e p e n d i n g on the n a t u r e of the initiating agent, do-m a i n changes can be classified as external changes (in-itiated by external entities) or intemal changes (applied by the m a n a g e m e n t system). The scope of both types of changes is also different: infernal changes can only m o d i -fy the current configuration, w h e r e a s external changes can affect every element of the Domain. Examples include the definition of a new business objective or the reléase of a n u p d a t e d versión of a component (that will appear at the LRB).
In this context it becomes clear that for m a n a g e m e n t p u r p o s e s it is vital to provide a comprehensive identifica-tion of the infernal changes, as they define the scope of potential actions that can be applied by the m a n a g e m e n t system. Table 1 provides a short overview of the ten d e p -loyment a n d configuration primitives (infernal changes) w h i c h w e h a v e deemed necessary for a service m a n a g e -m e n t syste-m. For each operation w e detail the code ña-me, the required a r g u m e n t s a n d the changes it causes to the configuration w h e n applied (including valué changes a n d the existence or not of the elements). The m a n a g e m e n t system can only affect the topology of the Environment at Runtime Unit level. It is possible to remove existing units (UNINSTALLUNIT), a n d instantiate n e w Runtime Units defined at the LRB (INSTALLUNIT, UPDATEUNIT). The configuration of the existing units can also be m a n a g e d , w i t h control over their lifecycle (STARTUNIT, STOPU-NIT), as well as Property configuration (CONFUNIT-PROP) a n d Bindings (CONFBINDING). Containers can also be partially m a n a g e d , in the form of Container Re-source configuration changes (ADDCONTRES, RMVCONTRES, CONFCONTRES), allowing to address Unit Constraints. N o d e m a n a g e m e n t is out of the scope.
The autonomic m a n a g e m e n t control loop w e intend to implement can be clearly defined using the presented concepts: After a n external change h a p p e n s to the Domain a n d is detected by the m a n a g e m e n t system, it is diag-nosed, in order to evalúate if the Correctness has been broken. In that case, all the information will be analyzed in order to obtain a set of infernal changes to the r u n t i m e configuration w h i c h will restore it to a correct state.
TABLE 1
INTERNAL CHANGES DEFINITION
Ñame
INSTALLUNIT UNINSTALLUNIT UPDATEUNIT ADDCONTRES RMVCONTRES CONFIGRES STARTUNIT STOPUNIT CONFUNITPROP CONFBINDING
Arguments
Container cont, DepUnitdu Container cont, RuntimeUnit ru
Container cont, RuntimeUnit ro, DepUnitdun Container cont, ConfCRes ere, String ñame Container cont, Resource re
Container cont, Resource re, Props props RuntimeUnit ru
RuntimeUnit ru
RuntimeUnit ru, Property[] props RuntimeUnit ru,rb, intbindld
PostCondition
3RuntímeUnít ru, ru G cont. units A ru ínstanceof du ru £ cont. units
3RuntimeUnit rn,rn G cont.units Arn Ínstanceof dun Aro £ cont.units
3Resource cr,cr G cont. resources A cr Ínstanceof ere A cr. ñame = ñame re £ cont. resources
props £ rc.properties ru. state = STARTED ru. state = STOPPED
props £ ru.propertíes
4 A TECNIQUE FOR AUTOMATED SERVICE CHANGE IDENTIFICATION
The previous section provided a complete definition of the service m a n a g e m e n t problem. All the relevant m a n -agement information h a s been defined based o n a com-m o n com-model, a n d a function to evalúate the correctness of the d o m a i n h a s been derived from the m o d e l abstrac-tions. Finally, the operations available to the m a n a g e m e n t system to change the environment have been identified. After those concepts have been defined w e will propose in this section a technique for automatically finding a correct solution by exploring the changes that can be applied to the environment.
Clearly brute-force approaches are n o t feasible in this context, as previous theoretical analysis have proved the NP-complete algorithmic complexity of the problem of finding a correct configuration for a distributed system [35]. O n the other hand, w e have already presented h o w SAT solvers have been successfully applied to problems of a similar nature, such as software packages d e p e n d e n -cy management, as well as exploring a configuration space w i t h múltiple defined constraints. Because of those factors, w e have opted to express the problem of finding a reachable correct configuration as a satisfiability formula. A m o n g the available variants, w e have selected a P s e u d o Boolean SAT solver (PB SAT) as the base of our solution.
The m a i n alternative to the selected approach w a s the previously described Alloy tool. Alloy offers a higher level abstraction over base SAT solvers, directly support-ing the generation of m o d e l instances satisfysupport-ing a set of first order constraints (equivalent to base SAT clauses) expressed over the model abstractions. However, for the purposes of o u r work, the use of a Pseudo Boolean SAT provides two important advantages: Linear clauses allow enforcing constraints such as valué consumption. Second,
a n d more importantly, the availability of a n optimization function provides m u c h greater influence over the p r o -posed solution. For o u r context, minimizing the n u m b e r of required changes w a s a fundamental factor for the applicability of the solution. As there w e r e reports of industrial adoption of PB SAT Solvers for considerable large problem sizes w i t h good results, w e opted to ex-plore that approach for our specific problem.
This way, the m a n a g e m e n t problem is converted to the following SAT terms. Defined SAT variables represent every potential decisión about the final environment con-figuration, w i t h all of them being reachable by applying infernal changes. Therefore, the true or false valúes of the proposed solution determine the final runtime configura-tion. The proposed solution m u s t represent a coherent environment configuration, both stable a n d desirable. This will be enforced by defining SAT clauses over the variables. Finally, the Pseudo-Boolean optimization func-tion will allow further control over the final result.
Fig. 5 shows a high-level representation of the com-plete change identification process, w h i c h receives the information models as input a n d returns the required set of changes for restoring the correctness of the environ-ment. The technique can be divided in four steps: literals definition, clauses definition, SAT invocation a n d results interpretation. Stability a n d desirability restrictions will be evaluated over different steps of the process (depend-ing o n its kind), in order to ensure that the proposed solu-tion is correct.
The literals definition step takes as input the information from the logical deployment units a n d the current state of the environment, obtaining from them a set of SAT liter-als that represent all the potentially reachable configura-tions. After all the literals have been defined, the clauses
definition step defines all the required clauses to ensure
that the potential results from SAT execution will yield a
DOMAIN KNOWLEDGE
( Logical Resource
/--* Base
0 0 ^
Initial Configuration
LITERALS DEFINITION
CLAUSES
DEFINITION SAT RESULTS
RESULTS INTERPRETATION
("container ) ( Contalñei
K
Objectives
J
J
'Jí CLit \
-"ígh
stc
stc
Sbc
SbC
SbC t >
-OptimF
> ObC
•) ObC
1
co
-AuLlt"^-r^
- ^ INSTALLUNIT
• - - ^ CONFBINDING
- — ^ ADDCONTRES
• ^ UNINSTALLUNIT
stable a n d desirable solution. In order to do so, the literals a n d objectives are analyzed. Once the SAT solver has been completely configured, it will be invoked, obtaining a proposed final state of the environment. Finally, the
results interpretation step will evalúate each clause valué
against the current environment state in order to obtain the required set of changes to be invoked by the m a n -agement system.
Over the following subsections w e will provide a d d i -tional details over each one of the steps, presenting the techniques that, starting from the Domain information, genérate the required input for the SAT solver (literals, clauses a n d optimization Function), invoke the engine, a n d interpret the results as the set of required changes.
4.1 Literals Definition
The first step of the presented algorithm consists of defin-ing SAT literals that capture every potential decisión about the final environment state (e.g. w h a t resources will be part of it a n d h o w will they be configured). The scope of these decisions is limited by the available m a n a g e m e n t operations (the ten primitives presented in the previous table). In order to identify these decisions, the available logical units a n d the current environment model m u s t be analyzed. The defined deployment units determine w h a t services can be instantiated over the environment, w h e -reas several elements from the runtime also influence the potential actions. The runtime containers determine w h e r e can units be deployed over the environment, and provide a set of resources which can satisfy the defined constraints. Additionally, the configuration contains exist-ing units a n d services which can be potentially removed. O n the other hand, defined objectives are not relevant at this stage, as they don't influence w h a t configurations can be reached, only evalúate their desirability.
After evaluating these concerns, the following types of SAT literals have been defined to capture the problem:
Runtime Unit Literals, RULit, represent the decisión of a
runtime unit belonging or not to the final configuration (it might originate from the instantiation of a logical unit over a resource or it might exist initially). Binding Literals,
BLit, represent the decisión of configuring a specific
bind-ing of a Runtime Unit to another in order to satisfy the logical dependency. W e use the term group of literals to identify all the BLits which belong to the same decisión about a runtime Binding. Finally, the Container Resource
Literals, CLit, represent the decisión of creating or not a
Resource at a runtime container in order to satisfy a r u n -time resource constraint.
Literals are obtained through a two-step algorithm. First, the RULits are obtained. In order to do so, the Dep-loyment Units from the LRB are iterated over the Con-tainers existing at the runtime configuration. This carte-sian product contains every Runtime Unit that can poten-tially appear at the environment by the actions of the m a n a g e m e n t system. However, m a n y of these Units w o u l d actually never be stable, as they w o u l d be d e p -loyed over incompatible Containers, or have Constraints that cannot be satisfied. In order to avoid that, several stability restrictions are applied at this stage. The
algo-rithm checks the basic part of the Constraints (the ñ a m e a n d type filter) of the Deployment Units against the ex-ecution context that w o u l d correspond to the Runtime Unit (the Container a n d its Resources, the N o d e a n d its Resources). Additionally, the algorithm checks the host compatibility restriction (ensuring that Container's s u p -portedTypes include the unit's type), as well as the impli-cit restrictions derived from Context A w a r e Properties. This way, RULits that w o u l d represent unstable decisions are not defined, a n d CLit decisions are defined for those situations w h e n the creation of a specific Resource at the Container can address unit stability.
The second step of the algorithm generates the BLit lit-erals that contain the potential decisions about the Bind-ings established between the Runtime Units configura-tions. In order to do so, the RULits representing units w i t h Dependencies are iterated against the complete set of RULits, obtaining every possibility. Similarly to the previous stage, stability restrictions are applied over the literals generation loop in order to discard unfeasible options. In particular, Dependency's b o u n d resource compatibility (expressed by the ñame, versión, a n d type filter, as well as the existence of the Properties requested by children Bound Property elements), a n d visibility of the potential b o u n d resource are verified before defining the corresponding BLit. Additionally, RULits representing units w i t h a dependency which cannot be solved will be removed from the SAT problem (as a true assignment for them w o u l d always result in an unstable solution).
The presented steps capture every potential decisión about the final configuration topology (Units, Bindings, a n d Container Resources) which can result on a correct solution. Several stability restrictions are checked as part of the loops, imposing a slight overhead in the specific step. Nonetheless, applying them at this point not only reduces SAT problem size but also simplifies later stages of the process that itérate over previous results.
4.2 Clauses Definition
After identifying the types of SAT variables and the m e -chanism for its definition w e will describe the clauses
identification step. From this point o n w a r d s , w e will focus
on w h a t restrictions need to be expressed to the valúes of the SAT literals in order to ensure that the proposed solu-tion is correct. Restricsolu-tions are expressed through stan-d a r stan-d SAT clauses anstan-d pseustan-do-Boolean linear clauses (linear inequality with Boolean literals) [22]. Three cate-gories of clauses will be introduced. Structural clauses enforce that the solution is coherent w i t h the unit-resource structure (that is, the consistence of the valúes of related RULit a n d BLit variables). Stability clauses m á n d a t e this condition to be met by the proposed solution. Finally,
Objective clauses transíate the defined objectives ensuring
that the proposed solution is desirable.
Structural clauses link the valúes of a RULit a n d its
as-sociated BLit elements, as only one BLit from each g r o u p can be simultaneously true, a n d their valué is also depen-dant on the existence or not of the Runtime Unit. These requirements will be expressed the following w a y . Let
originat-ing Deployment Unit declares n¿ Dependencies, w i t h n¿.>0 Each Binding Aibj,jE[l,n,] of the Runtime Unit represented by Ai can be potentially b o u n d to m different units
identi-fied by the set of literals {Bk }, Bk E RULit,kE[l,m\. This
way, the decisión about the configuration of Binding Aib¡ is represented by the following set of literals: [AibjBk],
AibjBkEBLü, kE[l,m]. For each Binding Ai>¡, of each RULit Ai the structure will be preserved by a d d i n g clauses (13)
a n d (14) to the SAT.
m m
Al^\/AlbjBk (13) ^ \ f c , f lk< l (14)
»c=i »c=i
Stabüüy restrictions ensure that t h e decisions about
Runtime Unit placement (RULits) and Binding configura-tion (BLits) a t the final configuraconfigura-tion respect the Depen-dency a n d Constraint restrictions. Property valué restric-tions from Context-Aware a n d Bound Properties need not to be expressed in the SAT problem, as instead of restrict-ing valid decisions they are directly derived from them. Therefore, they will be enforced at a later stage.
Dependency restrictions are expressed by a d d i n g the clause (15) for each defined BLit element. This translates the SAT-ification of the simple dependency concept de-scribed in [25] to the current distributed problem through the use of bindings. As regards constraints addressable by the creation of n e w resources, a similar approach is fol-lowed for the basic restriction. Let {CR¿}/ CR¡E CLit iE[l,n] the set of defined Container Resource Literals a n d CU¡ E
RULit the literal representing a unit w h o s e Constraint will
be satisfied by the creation of the resource represented by
CRi. Defining clause (16) for each CLit ensures the final
configuration will créate all the necessary Container Re-sources.
AtbjBk^Bk (15) CUl^CRl (16)
The presented definitions cover only the simple cases of Dependency a n d Constraint definitions. Additional clauses are defined to capture additional stability restrictions such a s exclusive access, incompatibilities or r e -source consumption that involve múltiple units with conflicting requirements. As an example w e describe h o w to capture the consumption requirement w h o s e function w a s presented at Section 3. Let a group of defined RULits {C¿},G E RULit z'E[l,n] representing units that consume the same resource (e.g. RAM m e m o r y from a node, a s the unit depicted in Fig. 3). Each element consumes a n a m o u n t a EN , as their Deployment Unit model contains a Constraint to a Resource of type "hardware.memory.rom", with a Property Constraint of kind CONSUMPTION a n d valué a (e.g. 256 for the unit presented in Fig. 3). If the valué of the Resource property, representing total capaci-ty is cap EN, the consumption restriction over the resource can be captured by a d d i n g a linear clause (17).
n
c¡ * C¡ < cap (17)
i=i
Objective restrictions. Finally, desirability will be
en-sured by codifying the defined m a n a g e m e n t objectives into clauses. Both types of objectives refer to one resource which m u s t either exist or not exist at the final state of the
runtime environment. The set of RULits providing the identified resource is called {ORi], ORi E RULit, iE[l,n]. In the case of the EXISTS objective, a t least one of the p r o -viders m u s t appear at the solution, which is expressed by clause (18). O n the other hand, NOTEXISTS objectives forbid the presence of that element. Therefore, no provid-er will appear at the solution, as is reflected in (19).
n
\J'ORi (18) ORl=false,ie[l,n] (19)
i=i
The definitions presented u p to this point ensure that every proposed solution will be correct. However, a s it has been mentioned, this is insufficient for most scena-rios. The solution should not only be correct but also en-force established m a n a g e m e n t policies. These aspects can be expressed using additional P s e u d o Boolean SAT re-strictions a n d / o r optimization functions. This allows the customization of aspects such as the n u m b e r of desired instances of each resource, the preference i n physically concentrating or distributing the services or minimizing the changes to the initial configuration as m u c h as possi-ble.
As an example of those customizations, w e describe an optimization function that captures the objective of re-m o v i n g u n n e e d e d units a n d re-minire-mizing the n u re-m b e r of changes to the runtime resources composition. This way, "purposeless" resources will be removed from the r u n -time configuration and, w h e n e v e r possible, the proposed solution will respect the current state of the configuration while addressing at the same time the desirability and stability. In order to express this, the set of defined RULits m u s t be partitioned into m groups, each of them com-posed by the literals instantiating the same Deployment Unit. These groups are: {A¿,}, AijERULit, AÍ¡ instanceof
Dep-loyment Unit DU¡, iE[l,n], jE[l,m\.
For each group, if n>2 and one of the literals A¡¡ represents an existing Runtime Unit, there is a potential SAT solution which does not include the already existing element. For those cases, a term GRP¡ that expresses the preference for respecting the existing unit will be a d d e d to the optimization function, as is presented in (20).
m
MINIMIZE(Y GRPj) (20)
i = i
The GRPj terms are defined as follows. For each g r o u p
{Ai¡} of cardinality n, a linear expression will be defined
from those literals w i t h two different weights for the
va-riables, as is s h o w n in (21). The existing unit AXi will ha ve
a weight VKíEN, the rest having W2EN, with Wi > Wi. The exact weights can be adjusted in order to prioritize a m o n g additional optimization criteria. This way, w h e n the SAT minimizes the expression, the preferred option (in case it is correct) will be the nonexistence of every runtime unit from the group. If the unit is necessary for correctness, keeping the existing unit will be a better solution than any other alternative, as the weight contribution will be lower.
n-í
GRPj = Wí * AXJ +YJW2*Alj,AXJeC0,n>2 (21)
4.3 Results Interpretation
After all the literals a n d clauses have been identified the SAT solver will be invoked, finding a solution (if possi-ble) which consists of a proposed true or false assignment for each variable. The solution defines a correct environ-m e n t state which can be obtained by applying infernal changes (from the primitives presented in Table 1). The final step of the service change identification process will interpret the SAT results a n d obtain the changes which will be applied. As the valué of each SAT literal represents a decisión about one element of the final envi-r o n m e n t state (eitheenvi-r a Containeenvi-r Resouenvi-rce, a Runtime Unit, or the configuration of a unit Binding), the required changes to apply each decisión can be evaluated indivi-dually. Over this process the remaining stability restric-tions (related to Bound a n d Context-Aware Properties) are verified, ensuring the correctness of the final state. W e will show h o w each type of literals is interpreted into changes to the runtime configuration by comparing them w i t h the initial d o m a i n state.
CLit literals contain the decisions about the creation of additional resources on top of the existing Containers in order to satisfy unit constraints. Therefore, true valúes will be interpreted as ADDCOT\TTRES(cont, ere, ñame) changes.
RULit literals determine w h a t units a n d services will appear at the final configuration. In this case both positive a n d negative assignments need to be checked, w i t h its interpretation d e p e n d i n g also on the initial environment state. True RULits d e m a n d the unit to appear, so if it w a s not initially deployed, it will be provisioned by the execu-tion of INSTALLUNIT(c,du) a n d STARTUNIT(c,ru) changes. In case the literal is evaluated as false, a n d the runtime unit w a s present at the initial configuration, it will have to be safely removed from the environment, by applying STOPUNIT(c,ru) followed by
UNINSTU-NIT(c,ru). Finally, at this stage the stability restrictions
from Context A w a r e Properties will be enforced. The required valúes for those Properties will be obtained from the final runtime state a n d will be reflected w i t h a
CON-FUNITPROP (cont,ru,props) change.
The last set of literals (BLits) represent the decisions over the satisfaction of unit dependencies by establishing bindings a m o n g the runtime elements. For each positive valué, a CONFBINDING (ru,bindld,rub) change will be applied. Finally, the infernal unit configuration restric-tions specified by Bound Properties will be computed, taking into account the decided Bindings a n d the source valúes. The required configuration for those properties will be specified t h r o u g h a CONFUNITPROP
(cont,ru,props) change.
The list of changes contains every operation required for reaching the desired state, but it cannot be arbitrarily executed, as there are partial ordering restrictions be-tween the obtained changes. These dependencies are caused by two factors: Runtime Units have a n execution lifecycle, defined taking as reference the c o m m o n g r o u n d of the m a i n enterprise component specifications, such as JEE (Java Enterprise Edition)'s EJBs (Enterprise Java Beans) or OSGi bundles. It includes provisioning,
activa-tion, stop, configuration a n d uninstallation. The changes that can be applied to a unit are restricted by its lifecycle state, d e m a n d i n g the definition of reía ti ve restrictions (i.e. the unit cannot be started before it has been installed, or the unit configuration m u s t be completed before its acti-va tion). As the m o d e l aims at supporting heterogeneous components a n d services, hot reconfiguration is not al-lowed (applied while the component is active) [36]. Con-sequently, the lifecycle m a n d a t e s configuration operations to be applied only w h e n a unit is stopped. A d d i -tionally, before starting a unit all its stability requirements (i.e. dependencies a n d constraints) m u s t have been ad-dressed. Therefore, before starting a runtime unit its in-fernal configuration, b o u n d units a n d accessed container resources m u s t have been left at a stable state.
These restrictions can be expressed in the following rules, that w h e n applied provide a partial ordering of the change activities.
For activities affecting the same runtime unit: • INSTALLUNIT m u s t be applied first. • UNINSTALLUNIT m u s t be applied last.
• STOPUNIT m u s t be applied before every C O N -FUNITPROP a n d CONFBINDING activity
• CONFUNITPROP changes which modify Bound Properties m u s t be applied after the CONFBIND-ING changes.
• CONFUNITPROP a n d CONFBINDING m u s t be applied before STARTUNIT
Regarding activation of unstable units:
• ADDCONTRES a n d CONFIGRES m u s t be applied before applying the constrained unit STARTUNIT a n d any CONFUNITPROP changes derived from Context-Aware Properties
• STARTUNIT activities cannot be applied before every b o u n d unit has already been started
The partial order restrictions are obtained over the change generation process by applying these rules. The complete list of changes combined w i t h their execution dependencies constitutes the change plan for the envi-ronment, which can be interpreted to reach the desired state.
5 VALIDATION
The previous sections have detailed the technical founda-tions of our a u t o m a t e d m a n a g e m e n t engine. Over this section w e present a set of validation experiments applied to a n industrial case study from the banking domain.
