![General-Purpose Autonomic Computing
Radu Calinescu
Abstract The success of mainstream computing is largely due to the widespread
availability of general-purpose architectures and of generic approaches that can
be used to solve real-world problems cost-effectively and across a broad range
of application domains. In this chapter, we propose that a similar generic frame-
work is used to make the development of autonomic solutions cost effective, and to
establish autonomic computing as a major approach to managing the complexity of
today’s large-scale systems and systems of systems. To demonstrate the feasibility
of general-purpose autonomic computing, we introduce a generic autonomic com-
puting framework comprising a policy-based autonomic architecture and a novel
four-step method for the effective development of self-managing systems. A pro-
totype implementation of the reconfigurable policy engine at the core of our archi-
tecture is then used to develop autonomic solutions for case studies from several
application domains. Looking into the future, we describe a methodology for the
engineering of self-managing systems that extends and generalises our autonomic
computing framework further.
1 Introduction
The last decade has brought revolutionary transformations to the way in which
information and communication technologies (ICT) are used to conduct business
and research and to provide services in all sectors of the society [26]. The ability
to accomplish more, faster and on a broader scale through expert use of ever more
complex ICT systems is at the core of today’s scientific discoveries, newly emerged
services and everyday life. Autonomic computing represents an effective approach
to managing the spiralling complexity of these systems by delegating their configu-
ration, optimisation, repair and protection to the systems themselves [15, 21].
R. Calinescu (B)
Computing Laboratory, University of Oxford, Oxford, England, UK
e-mail: Radu.Calinescu@comlab.ox.ac.uk
M.K. Denko et al. (eds.), Autonomic Computing and Networking,
DOI 10.1007/978-0-387-89828-5 1, C
Springer Science+Business Media, LLC 2009
3](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-19-320.jpg)
![4 R. Calinescu
The research efforts of the past few years have generated a wealth of knowl-
edge on what autonomic systems should look like [9, 13, 21, 31, 34] and what
best practices to follow in building them [4, 16, 41, 43]. This progress is to a great
extent a by-product of the effort that went into the development of successful auto-
nomic solutions addressing specific management tasks in real-world applications
[8, 25, 27, 40, 42]. While these developments demonstrate the feasibility of the auto-
nomic computing approach to complexity management, the current use of bespoke
and domain-specific architectures, and of dedicated models and policies limits sig-
nificantly the cost-effectiveness and reusability of today’s autonomic solutions.
These limitations resemble the problems encountered in the early days of main-
stream computing, and overcome successfully through the use of general-purpose
architectures and generic approaches for the development of real-world applica-
tions across multiple application domains. We therefore propose that an equally
generic framework is used to make the development of self-managing systems cost-
effective, and to drive standardisation, component reuse and user adoption in the
realm of autonomic computing. Given that policy-based autonomic computing rep-
resents the most advanced approach to developing self-managing systems of practi-
cal utility, we describe below the criteria that a policy-based autonomic computing
framework needs to satisfy in order to qualify as “general purpose”:
C1 Support for the whole range of software, hardware and data compo-
nents encountered in real-world ICT systems. To enable the development of
effective autonomic systems for real-world applications, the framework should
support the organisation of heterogeneous collections of existing and future
ICT components into self-managing systems. Both components specifically
designed for inclusion into a self-managing system (i.e., autonomic-enabled
ICT resources) and components not originally intended for this purpose (i.e.,
legacy ICT resources) should be catered for.1
C2 Support for a broad spectrum of self-* functional areas and autonomic
computing policies. The framework should aid the development of self-
management capabilities spawning a rich spectrum of self-* functional areas,
e.g., self-configuration, self-healing, self-optimisation and self-protection
[21, 31, 34]. This must be achieved through supporting all types of autonomic
computing policies, including action, goal and utility-function policies [44, 45].
C3 Support for the cost-effective development of self-managing systems for
a large variety of application domains and use cases. The framework must
reduce the effort and costs incurred in the development of today’s autonomic
systems significantly through enabling the extensive reuse of components and
the sharing of autonomic computing models and policies. It should drive the
standardisation of interfaces, policies, models and components for autonomic
computing, and should allow and encourage the modular development of com-
plex self-managing systems and systems of systems. Last but not least, the
framework must provide a generic method for developing autonomic systems
from any combination of legacy and/or autonomic-enabled ICT resources.
1 The ICT components to be integrated into an autonomic system will be termed (ICT) resources.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-20-320.jpg)
![General-Purpose Autonomic Computing 5
To demonstrate the feasibility of general-purpose autonomic computing, we
introduce a novel policy-based autonomic computing framework comprising an
autonomic architecture designed around a reconfigurable policy engine, and a four-
step method for the effective development of self-managing systems. This frame-
work builds on recent advances in autonomic computing [9, 13, 17, 34], and extends
the author’s previous work in this area [4–7] in several new directions. Thus, we
describe for the first time how multiple instances of the same general-purpose
autonomic architecture can be organised into self-managing systems of systems
by means of a new type of autonomic policy termed a resource-definition policy.
Also, we present the first-ever integration of quantitative model checking techniques
[23, 24] into autonomic policy engines, and show how the use of this new capability
enables the specification of powerful utility-function policies. Finally, we present a
new four-step method for the development of self-managing systems starting from a
model of their ICT resources, and we illustrate its application to several case studies
that spawn different application domains and employ a wide range of policy types.
The remainder of the chapter is organised as follows. In Sect. 2, we contrast
our framework with other approaches to autonomic solution development. We then
describe the general-purpose autonomic architecture and the reconfigurable policy
engine at its core in Sects. 3 and 4, respectively. A prototype implementation of
the policy engine is presented in Sect. 5, followed by the description of our generic
method for the development of self-managing systems in Sect. 6, and by several
case studies that illustrate its use in a number of different real-world applications
in Sect. 7. Section 8 analysis the extent to which our candidate general-purpose
autonomic framework satisfies the criteria stated at the beginning of the chapter,
and suggests ways for extending our current results.
2 Related Work
The autonomic infrastructure proposed in [35] is retrofitting autonomic functional-
ity onto legacy systems by using sensors to collect resource data, gauges to inter-
pret these data and controllers to decide the “adaptations” to be enforced on the
managed systems through effectors. This infrastructure was successfully used to
monitor, analyse and control legacy systems in applications such as spam detection,
instant messaging quality-of-service management and load balancing for geograph-
ical information systems [19]. Our framework is building on the powerful approach
in [19, 35], and has the added capability to handle heterogeneous types of resources
unknown until runtime, and to support the development of autonomic systems of
systems through the use of resource-definition policies.
In [20], the authors define an autonomic architecture meta-model that extends
IBM’s autonomic computing blueprint [16], and use a model-driven process to
partly automate the generation of instances of this meta-model. Each instance is
a special-purpose organic computing system that can handle the use cases defined
by the model used for its generation. Our general-purpose autonomic architecture
eliminates the need for the 19-activity generation process described in [20] by using](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-21-320.jpg)
![6 R. Calinescu
a universal policy engine that can be dynamically redeployed to handle any use cases
encoded within its resource model and policy set.
Several research projects propose the use of model-driven architecture (MDA)
techniques to develop autonomic computing policies and self-managing systems
starting from high-level behavioural models of the system or of its components
[10, 36, 39]. Two of these approaches [10, 36] are targeted at bespoke systems whose
components already exhibit sophisticated autonomic behaviour, and thus cannot be
readily extended to handle generic legacy resources. In contrast, our framework
can accommodate any type of ICT resource whose characteristics can be mod-
elled as described in Sect. 6. The preliminary work described in [39] is closer to
our approach in that it advocates the importance of using MDA techniques in the
development of generic self-managing systems; however, the authors do not sub-
stantiate their proposal with any concrete solution, but rather qualify it as an open
challenge.
A number of other projects have investigated isolated aspects related to the devel-
opment of autonomic systems out of non-autonomic components. Some of these
projects addressed the standardisation of the policy information model, with the
Policy Core Information Model [30] representing the most prominent outcome of
this work. Recent efforts such as Oasis’ Web Services Distributed Management
(WSDM) project were directed at the standardisation of the interfaces through
which the manageability of a resource is made available to other applications
[32]. An integrated development environment for the implementation of WSDM-
compliant interfaces is currently available from IBM [17].
In [12], the authors take a view similar to ours by introducing a paradigm termed
model-driven autonomic computing, and explaining that the model-based validation
of self-management decisions represents a more reliable and flexible approach than
the use of pre-set policies. A powerful hierarchical model of NASA’s Autonomous
Nano-Technology Swarm missions is successfully used in [12] to achieve the self-
managing functionality that these missions depend on, and thus to illustrate the ben-
efits of the approach. Our work complements the results in [12] with a new model-
based approach to developing self-management functionality and a generic method
that uses existing tools and standards for the implementation of autonomic systems.
Finally, we build on recent advances in component-based programming, by using
an approach to ICT resource composition and dynamic configuration that resembles
the one supported by reflective component models such as Fractal [3]. In addi-
tional to the Fractal functionality, our framework automates the generation of
most component interfaces and the management of the targeted system.
3 General-Purpose Autonomic Architecture
Figure 1 depicts our general-purpose autonomic architecture, a preliminary version
of which was introduced in [5, 6]. The core component of the architecture is a
universal policy engine that organises a heterogeneous collection of legacy ICT
resources and autonomic-enabled resources into a self-managing system. To reduce](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-22-320.jpg)
![General-Purpose Autonomic Computing 7
Fig. 1 UML component diagram of the autonomic architecture. The architecture supports the
development of two types of autonomic systems-of-systems: a hierarchical topology that allows
an instance of the policy engine to manage other instances of the architecture (i.e., the managed
resources n+1 to n+m in the diagram); and a federation of collaborating instances of the archi-
tecture that use each others’ high-level sensors and effectors, as shown by the dashed lines in the
diagram
the effort required to develop autonomic solutions, the policy engine can handle
resources whose types are unknown during its implementation and deployment.
This unique capability is achieved through runtime configuration: a model of the
system to be managed is supplied to the policy engine for this purpose. As a result,
the engine can implement the high-level goals described by a set of user-specified
policies that make reference to the resources defined in the system model.
As recommended by IBM’s architectural blueprint for autonomic computing
[16], standardised adaptors are used to expose the manageability of all types of
legacy ICT resources in a uniform way, through sensor and effector interfaces. The
autonomic-enabled resources in the self-managing system are either typical ICT
resources designed to expose sensor and effector interfaces allowing their direct
inter-operation with the policy engine, or other instances of the architecture. The
latter option is possible because the policy engine exposes the entire system as an
atomic ICT resource through high-level sensors and high-level effectors. A detailed
description of the architecture and an overview of existing standards and technolo-
gies that can be used to implement it in practice are available in [5, 6].](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-23-320.jpg)
![General-Purpose Autonomic Computing 9
• The scheduler is used to support the scheduling operators appearing in policy
actions for the goal and utility-function policies handled by the policy engine.
• The resource discovery component is used to locate the resources to be managed
by the policy engine.
• The database driver is used to maintain policy engine data such as historical
resource property values in an external persistent storage.
• The machine learning modules use machine learning techniques [2] to derive
and/or refine a behavioural model of the managed resources based on sensor data
and inside policy engine information. This enables the engine to support goal
and utility-function policies for systems for which in-depth knowledge about
the behavioural characteristics of the managed resources cannot be supplied by
system administrator. The usefulness of a Modeler component for the implemen-
tation of utility-function policies is mentioned in [44], although the authors are
not specific about the learning algorithms that such a component might use.
• The probabilistic model checker enables the policy engine to take full advantage
of the behavioural model supplied by the system administrator or built by its
machine learning modules. This is done by using probabilistic model checking
to establish quantitative properties of the system [24] and thus to implement the
user-specified policies. As will be illustrated by a couple of the case studies
in Sect. 7, the integration of these quantitative verification techniques into the
policy engine enables system administrators to specify powerful goal and utility-
function policies that would have been extremely complicated or even impossible
to express otherwise. Another use envisaged for the model checker is to help
verify the policies implemented by the engine as suggested in [22].
5 Prototype Implementation
In this section we overview a prototype implementation of our autonomic architec-
ture that was originally introduced in [7], and we describe for the first time two of its
new features: the integration of a probabilistic model checker with the policy engine
and the implementation of resource-definition policies.
Two major choices influence the realisation of an instance of the architecture:
the technology used to represent the system model and the technology chosen for
the implementation of the policy engine components. We chose to represent system
models as plain XML documents that are instances of a pre-defined meta-model
encoded as an XML schema. This choice was motivated by the availability of
numerous off-the-shelf tools for the manipulation of XML documents and XML
schemas that are largely lacking for the other technologies we considered (e.g.,
[1, 29, 32]). In particular, by using existing XSLT engines and XML-based code
generators, we shortened the prototype development time and avoided the need to
implement bespoke components for this functionality.
As shown in Fig. 3, an ICT system is a named set of resources (resource in
the UML diagram), each comprising a unique identifier ID and a set of resource](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-25-320.jpg)
![10 R. Calinescu
Fig. 3 Meta-model of an ICT system
properties with their characteristics. A resource property is associated a unique ID,
and has a data type (i.e., propertyDataType). Several other property characteristics
are defined in the meta-model:
• mutability – the WS-RMD MutabilityType [33] specifies if the property is “con-
stant”, “mutable” or “appendable”;
• modifiability – tells if the property is “read-only”, “read–write”, “write-only” or
“derived” from other properties and the behavioural model of the system;
• subscribeability – specifies whether a client such as the policy engine can sub-
scribe to receive notifications when the value of this property changes;
• primaryKey – indicates whether the property is part of the property set used to
identify a resource instance among all resource instances of the same type.
Our prototype policy engine and the manageability adaptors enabling its interopera-
tion with legacy resources were implemented as web services in order to leverage the
platform independence, loose coupling and security features of this technology [46].
The runtime configuration of the engine required the extensive use of techniques
available only in an object-oriented environment, e.g., runtime generation of data
types and manageability adaptor proxies, reflection and generics. Based on these
requirements, J2EE and .NET were selected as candidate development platforms
for the prototype engine, with .NET being eventually preferred due to its better
handling of dynamic proxy generation and slightly easier-to-use implementation of
reflection. The components included in the prototype are shown in Fig. 2.
The free, open-source probabilistic model checker PRISM [14] developed by
the Quantitative Analysis and Verification Group at the University of Oxford was
chosen for integration with the original version of the policy engine described in
[7]. This choice was based on an extensive performance analysis of a range of model
checkers [18] that ranked PRISM as the best option for analysing large behavioural
models such as the ones encountered in autonomic computing systems. Further-
more, PRISM comes with a command-line interface that made possible its direct
integration into the existing version of the policy engine, and the runtime execution
of quantitative analysis experiments [23, 24] that self-managing systems can use to
realise powerful goal and utility-function policies as illustrated in Sects. 7.3 and 7.4.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-26-320.jpg)
![General-Purpose Autonomic Computing 11
Another novel feature of the policy engine that we describe for the first time is
its ability to handle resource-definition policies, i.e., policies of the form
RESDEF(newResourceId, propertyDef1, . . . , propertyDefm), (1)
where newResourceId is a string corresponding to the ID element of a resource
definition from the meta-model in Fig. 3 and
propertyDefi = (propertyIdi, expri, subscribeabilityi, primaryKeyi), 1≤ i≤ m
(2)
define the properties of the new resource type. The expri component in (2) tells the
policy engine how to calculate the value of the ith resource property as a function
of the resources in the policy scope, or is one of INTEGER, DOUBLE or STRING
to indicate that property i is a “read–write” property with one of these primitive
types. The other components of propertyDefi correspond to the property charac-
teristics from the system meta-model in Fig. 3 that cannot be inferred from expri.
To implement a resource-definition policy, the policy engine generates dynamically
the data type for the new resource and its manageability adaptor (i.e., a new web
service whose URL is built by replacing the suffix PolicyEngine.asmx from
the policy engine URL with newResourceIdManageabilityAdaptor.asmx).
This manageability adaptor exposes objects of the new data type that are created and
whose fields are set in accordance with the property definitions (2). The case study
presented in Sect. 7.5 illustrates the use of resource-definition policies.
6 A Generic Method for the Development of Autonomic Systems
Our method for the development of autonomic systems comprises four steps:
1. development of a model of the system to which autonomic capabilities are added;
2. generation of manageability adaptors for the legacy resources in the system;
3. reconfiguration of the policy engine by means of the system model from step 1;
4. development of autonomic computing policies that handle the required use cases.
To illustrate these steps, we will apply them to a system comprising a set of services
of different priorities, subjected to different workloads, and sharing the CPU capac-
ity of the same server. The aim of the case study is to develop an autonomic solution
for managing the allocation of CPU to services such that high-priority services are
treated preferentially, subject to each service getting a minimum amount of CPU.
Several policy types are typically used in autonomic systems [44, 45]: action
policies provide a low-level specification of how the system configuration should
be changed to match its state; goal policies specify precise constraints that should
be met by varying the system configuration and utility-function policies supply a
“measure of success” that the self-managing system should optimise by appropri-
ately varying its configuration. In our running example we will use a utility-function
policy, which is the most flexible of these policy types.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-27-320.jpg)
![12 R. Calinescu
To implement utility-function policies, the policy engine needs an understanding
of the behaviour of the system and its resources. Given a resource, we define its state
s as the vector whose elements are the read-only properties of the resource, and its
configuration c as the vector comprising its modifiable (i.e., read–write) properties.
Let S and C be the value domains for s and c, respectively.2
A behavioural model of
the resource is a function
behaviouralModel : S × C → S, (3)
such that for any current resource state s ∈ S and for any resource configuration
c ∈ C, behaviouralModel(s, c) represents the future state of the resource if its con-
figuration is set to c.
Our policy engine works both with an approximation of the behavioural model
that consists of a set of discrete values of the behaviouralModel in (3) and with
a continuous-time Markov chain (CTMC) [23] representation of (3). For our run-
ning example, we will use the former type of behavioural model; the use of CTMC
behavioural models is described in Sect. 7. As the current version of the policy
engine does not include the machine learning modules described in Sect. 4, it
acquires these behavioural models from the manageability adaptors for the managed
resources. With the future addition of machine learning modules (Fig. 2), the pol-
icy engine will gain the ability to use learning techniques to refine and, eventually,
to derive these behavioural models automatically based on its observation of the
managed resources.
Step 1: Model Development Let System be the set of all instances of the meta-
model in Fig. 3; the purpose of this step is to find a system model
M ∈ System (4)
that can be used to implement the desired autonomic solution. To achieve this goal,
we identify the system resources involved in the autonomic solution and their rel-
evant properties. Given the ability to reconfigure the policy engine at any time, it
makes sense to keep this model as simple as possible: additional resources and/or
resource properties can be specified in new versions of the model, and conveyed to
the policy engine as and when necessary. For instance, the single resource type for
our example system is service, and its properties are as follows: name, a unique
identifier used to distinguish between different services; priority, an integer
value; cpuAllocation, the percentage of the server CPU allocated to the service;
responseTime, the service response time, averaged over the past one-second
time interval; interArrivalTime, the request inter-arrival time, averaged over
the past one-second time interval and behaviouralModel, an approximation of
the service behaviour that provides information on how the service response time
varies with its CPU allocation and the request inter-arrival time.
2 Note that S and C are fully specified in the system model.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-28-320.jpg)
![14 R. Calinescu
Fig. 5 Generated XML schema (a) and manageability adaptor (b) for the sample system
generator such as Microsoft’s XML Schema Definition tool [28] is then used to
automatically generate the data type set associated with this schema:
dataTypeGen : XmlSchema → P DataType. (6)](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-30-320.jpg)
![16 R. Calinescu
system model from our running example, and the utility-function policy that will be
presented in step 4 were supplied to the engine.
Step 4: Policy Development In this step, autonomic computing policies are
designed that support the use cases of the envisaged autonomic solution. The scope,
priority, condition and action components of these policies make reference to the
resources and resource properties defined in the system model used to configure the
policy engine. Each of these policy components can be specified using a rich set of
operators and functions [6] that allow the definition of action, goal, utility-function
and, in the latest version of the engine, of resource-definition policies.
The policy set is applied to all resources whose locations are known to the policy
engine,3
and which are in the scope of the policies. Policy development is generally
a complex, error-prone and iterative process [4], and our framework improves the
effectiveness of this process significantly by (a) enabling and encouraging the reuse
of system models and policies and (b) simplifying the iterative development and
testing of policies for new types of resources and of policies that explore the use of
new properties of existing resources in novel ways.
For our autonomic solution, we defined a utility function that models the business
gain associated with running a set of service resources R with different levels of
service:
utility(R) =
r∈R
r.priority ∗ min(1000, max(0, 2000 − r.responseTime)).
Figure 7a depicts the utility function for a server running a “premium” service
with priority 100 and a “standard” service with priority 10. The policy action
implemented by the autonomic system (Fig. 6 and Table 1) was defined by means of
the MAXIMISE(R, utility, property, capacity, min, max, model) operator that uses
the information about the system behaviour encoded in model to set the value of the
specified resource property for all resources in R such as to: (a) maximise the value
of the utility function and (b) ensure that the value of property stays between min
and max, and that the sum of the property values across all resources in R does not
exceed the available capacity.
This policy provides the definition of the utility function, and the link between
the responseTime, interArrivalTime and cpuAllocation properties
of a service resource and the components of its behaviouralModel property.
Each time it evaluates the utility-function policy, the policy engine uses this infor-
mation to select the elements from the behavioural model that are in the proximity
of the current state of the system; the Euclidean metric is used for this calculation.
The new configuration for the system is then chosen as the one associated with the
selected element that maximises the value of the utility function. The experimental
results of applying this policy to our example system are presented in Sect. 7.1.
3 The policy engine employs a resource discovery service (Fig. 2) to obtain the URLs of the
resources to be managed.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-32-320.jpg)
![18 R. Calinescu
7 Case Studies
7.1 Utility-Driven Allocation of CPU Capacity
We start our presentation of case studies with the experimental results for the run-
ning example of an autonomic system from the previous section. Variants of this
system were used to validate autonomic computing frameworks in the past (e.g.,
[44]), hence this well-understood use case provides a good basis for a first assess-
ment of the framework. To evaluate our autonomic solution, the behavioural model
for a service was obtained from 100 runs of the server simulator in which the
average service response time was recorded for 920 equidistant points covering
the entire (interArrivalTime, cpuAllocation) value domain (Fig. 7b).
Figure 8 shows a typical experiment in which the utility-function policy in Table 1
was used to manage the allocation of CPU to our “premium” and “standard” ser-
vices, when their request inter-arrival times were varied to simulate different work-
loads. The policy evaluation period was set to 3 s for this experiment, so that the
system could self-adapt to the rapid variation in the workload of the two services.
This allowed us to measure the CPU overhead of the policy engine, which was under
1% with the engine service running on a 1.8 GHz Windows XP machine. In a real
scenario, such variations in the request inter-arrival time are likely to happen over
longer intervals of time, and the system would successfully self-optimise with far
less frequent policy evaluations.
7.2 Goal-Based Scheduling of CPU Capacity
In the absence of knowledge about the behaviour of the legacy ICT resources that
need to be organised into a self-managing system, goal policies can often be used in
conjunction with scheduling heuristics. In this section, we consider the same system
as in Sect. 7.1, but assume that a behavioural model describing the variation of the
service response time with its allocated CPU and request inter-arrival rate is not
available. Figure 9 depicts a concise representation of the system model and a goal
policy that can be used in this scenario. The action of this goal policy is specified by
means of an expression that uses the SCHEDULE(R, ordering, property, capacity,
min, max, optimal) operator that (a) sorts the resources in R in non-increasing order
of the comparable expressions in ordering; (b) in the sorted order, sets the specified
resource property to a value never smaller than min or larger than max, and as close
to optimal as possible; and (c) ensures that the overall sum of all property values
does not exceed the available capacity. Accordingly, the policy action in Fig. 9 will
set the cpuAllocation property of all services to a value between 15 and 100%, sub-
ject to the overall CPU allocation staying within the 100% available capacity. Opti-
mally, the cpuAllocation should be left unchanged if the 55 ≤ cpuUtilisation ≤ 85,](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-34-320.jpg)
![General-Purpose Autonomic Computing 19
Fig. 8 Experimental results for Sect. 7.1. The CPU allocations for the services are initially
decreased to match their light workload (5 ms request inter-arrival time during time interval a).
As the service workloads increase, so do the CPU allocations, until the CPU required to satisfy
the demand from the premium service leaves insufficient CPU capacity for the standard service to
make any contribution to the utility function (time interval d), hence it is allocated the minimum
amount of CPU specified in the policy (i.e., 15%). As soon as less CPU capacity is required to
satisfy the needs of the premium service (time interval e), the standard service is swiftly allocated
sufficient CPU to bring it back into a region of operation in which it contributes to the utility
function. Subsequently, the CPU allocations are varied to accommodate more gradual changes in
the workloads (time intervals f–g)
decrease by 5% if cpuUtilisation 55 and increase by 5% if cpuUtilisation 85.4
The experimental results for the resulting autonomic solution (available in [7])
resemble those corresponding to the use of a utility-function policy in Sect. 7.1,
but are less effective in two important circumstances:
4 The HYSTERESIS(val, lower, upper) operator used to achieve this behaviour (Fig. 9) returns
−1, 0 or 1 if val lower, lower ≤ val ≤ upper or upper val, respectively.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-35-320.jpg)
![20 R. Calinescu
Fig. 9 Policy engine parameters for the case study in Sect. 7.2. The policy engine is configured
to monitor the service cpuUtilisation (i.e., the amount of CPU utilised by the service,
expressed as a percentage of its CPU allocation) and to realise a goal policy requiring that the
cpuUtilisation is maintained between 55 and 80% of the allocated CPU
• several successive policy evaluations are required to handle significant changes
in the service workloads because the CPU capacity allocated to services can be
modified by only ±5% at a time;
• when insufficient CPU is available to ensure that a low-priority service runs in
an operation area that is useful for the business and the utility-function policy in
Sect. 7.1 would restrict the CPU allocated to the service to a minimum, the goal
policy gives it all available CPU, thus wasting CPU capacity unnecessarily.
7.3 Dynamic Power Management of Disk Drives
When formal methods are used in the development and/or verification of legacy
ICT resources, the behavioural models employed by these methods can often be
exploited by our framework to augment the legacy ICT resources with autonomic
capabilities. Starting from the CTMC model of a Fujitsu disk drive in [38] and its
encoding as a PRISM CTMC model [37], we built (Fig. 10) a system model of
the disk drive that can be used for the configuration of our policy engine. We then
used this system model to add self-optimisation capabilities to the disk drive so
that it dynamically adapted its probability of transitioning from the idle state to the
low-power sleep state to changes in (a) the request inter-arrival time and (b) the
user-specified utility function:
utility = w1 min
1, max
0,
11 − queueLength)
2
+ w2 max(0, 1.2 − power),
(8)](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-36-320.jpg)
![General-Purpose Autonomic Computing 21
Fig. 10 PRISM CTMC model of a three-state Fujitsu disk drive taken from [37], and used to
devise the system model for the configuration of the policy engine. The uninitialised PRISM
constants correspond to “read-only” and “read–write” properties of a disk drive resource (i.e.,
interArrivalTime and switchToSleepProbability, respectively). PRISM reward
structures (i.e., power and queueLength) correspond to “derived” disk drive properties
where the weights w1 and w2 are chosen depending on the circumstances in which
the disk drive is used (Fig. 11). Given this policy, the policy engine ran PRISM
experiments [24] to establish the optimal switchToSleepProbability for
the disk drive at regular, 10-s time intervals. For our simple CTMC model, each of
these experiments took subsecond time, yielding the results in Fig. 12.
7.4 Adaptive Control of Cluster Availability
The case study presented in this section involves the adaptive control of cluster
availability within a data centre. The aim of the autonomic solution is to control
the number of servers allocated to the N ≥ 1 clusters of a data centre in order to
maximise the utility function](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-37-320.jpg)
![22 R. Calinescu
Fig. 11 The utility function (8) (depicted here for w1 = w2 = 100) was used to achieve a user-
customisable trade-off between the disk drive responsiveness (which is provably proportional to its
average queueLength [38]) and its power consumption (i.e., power)
utility =
N
i=1
priorityi ·GOAL(availabilityi ≥ target availabilityi)−ε
N
i=1
serversi
(9)
subject to
N
i=1
serversi ≤ Total servers and requiredi ≤ serversi, (10)
where priorityi 0, availabilityi ∈ [0, 1], target availabilityi ∈ [0, 1], requiredi ≥
1 and serversi ≥ 1 represent the priority, (actual) availability, target availability,
number of required servers and number of (allocated) servers for cluster i, 1 ≤ i ≤
N, respectively. The GOAL operator yields 1 when its argument is true and 0
otherwise, Total servers ≥ 1 is the total number of servers in the data centre, and
0 ε 1 is a constant.5
The availability of cluster i, availabilityi, is the fraction
of a 1-year time period during which at least requiredi servers are usable (i.e., they
are operational and connected to an operational switch and backbone).
Like in the previous case study, we extracted the system model for the configu-
ration of our policy engine from an existing behavioural model of the targeted ICT
resource, namely from the CTMC model of a dependable cluster of workstations
introduced in [11]. This model takes into account the failure and repair rates of
all components from our targeted cluster architecture (Fig. 13a). Consequently, the
policy engine can use PRISM to calculate the cluster availabilities for the data-centre
configurations satisfying (10), and to decide the number of servers that each cluster
5 The second term of the utility function (9) ensures that when multiple configurations maximise
the first term, the configuration that uses the fewest servers is preferred.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-38-320.jpg)
![General-Purpose Autonomic Computing 23
Fig. 12 Discrete-event simulation results contrasting our autonomic approach to disk drive
dynamic power management (DPM) with two standard DPM methods [38]: the timeout method
that moves the disk drive into the sleep state after a period of idleness t and “awakens” it immedi-
ately after a request has arrived; and the N method that moves the disk drive into the sleep state as
soon as it becomes idle, and “awakens” it after N requests accumulate in its queue. The autonomic
DPM approach achieved a better utility than the two standard DPM methods for most of the time,
and similar utility to the better of the two for the rest of the time. This is due to the good trade-off
that the autonomic approach realised between power consumption and request queue length across
a wide workload range, while the other approaches are effective for specific workloads
should get so that the value of the utility function (9) is maximised. Given the com-
plexity of the CTMC behavioural model, we implemented a cluster manageability
adaptor that uses notifications to inform the policy engine about changes in the
number of required servers for the clusters. Hence, the policy engine recalculates
the server allocations only when there is a change in the state of the autonomic
system. In our simulations, this calculation took up to 30 s. This response time is
acceptable for the considered use case because, based on our previous experience
with policy-based data-centre management [4], half a minute represents a small](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-39-320.jpg)
![24 R. Calinescu
Fig. 13 Architecture of an n-server dependable cluster, taken from [11] (a), and simulation results
for a three-cluster data centre over a 4-week time period (b)
delay compared to the time required to provision a server when it is allocated to
a new cluster.6
The experimental results are shown in Fig. 13b.
7.5 Dynamic Web Content Generation
The last case study is extending the autonomic solution from the previous section
by incorporating the autonomic system for controlling cluster availability into an
autonomic system of systems (Fig. 14). The resource-definition policy action below
was supplied to policy engine instances within the autonomic data-centre systems:
RESDEF(businessValue, (id, CONCAT(cluster.id), false,true),
(max, SUM(cluster.priority),true, false), (actual, SUM(cluster.priority∗ (11)
GOAL(cluster.availability = cluster.targetAvailability)),true, false)).
6 Section 8 suggests techniques for working around the time taken by runtime model checking
when such delays are not acceptable.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-40-320.jpg)
![General-Purpose Autonomic Computing 27
C1 In terms of supported ICT resources, our case studies demonstrate that the
framework can handle the whole range of envisaged ICT resources.
C2 The framework has been used to develop autonomic solutions in several areas of
self-* functionality, and to support all types of autonomic computing policies.
To further confirm its generality, new applications are being currently investi-
gated that address additional areas of self-* functionality.
C3 The autonomic systems developed for the presented case studies cover a range
of application domains, including the development of a hierarchical system of
systems. This is a good first step towards establishing that the framework sat-
isfies this criterion. More work is required to assess the feasibility of using the
framework in other use cases, and in particular in the development of federations
of collaborating autonomic systems with no centralised management.
Based on past experience in using a domain-specific autonomic framework [4]
to develop systems similar to those in Sects. 7.1 and 7.2, we estimate that the use
of the generic framework to build these systems reduced the development effort
by roughly an order of magnitude, and we expect the same to hold true for other
applications.
Fig. 16 Proposed autonomic system development methodology. The autonomic architecture, pol-
icy engine and system meta-model described in this paper are used at the domain-independent
level, alongside a proposed ICT ontology and a proposed tool for designing the meta-model
instances used to configure the policy engine. Repositories of ICT resource definitions and auto-
nomic policies, and domain-specific ICT ontologies should be available at the level of an appli-
cation domain, while our generic method for autonomic system development is employed for the
cost-effective development of autonomic systems at the application-specific level](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-43-320.jpg)
![28 R. Calinescu
A key feature of our autonomic computing framework is its use of runtime prob-
abilistic model checking. As shown in Sect. 7.4, model checking large systems can
incur significant overheads, and the use of the subscription-notification mechanism
supported by the framework (instead of periodical policy evaluation) is one way
to accommodate this constraint. Other approaches to be investigated include the
use of caching and pre-evaluation techniques to bypass the model checking step
during policy evaluation, and the use of a hybrid approach in which a smaller model
checking experiment is carried out to produce a close-to-optimal configuration for
the autonomic system and a faster technique is then used to refine this configuration.
In addition to reusing components and techniques across a broad range of appli-
cations, our approach to autonomic system development allows and encourages the
reuse of system models and autonomic computing policies. To take reusability fur-
ther, these models and policies should draw their elements from domain-specific
repositories of resource definitions and autonomic computing policies, respectively.
Furthermore, to maximise the sharing of models, policies, manageability adaptors
and autonomic-enabled resources, these repositories need to be built around con-
trolled ICT ontologies, as required by the methodology for the cost-effective devel-
opment of autonomic systems that we are proposing in Fig. 16. This methodology
that we are working towards is in line with the excellent principles stated in [43]
and successfully applied in the context of autonomic networking by Strassner
et al. [42].
Acknowledgments The work presented in this chapter was partly supported by the UK Engineer-
ing and Physical Sciences Research Council grant EP/F001096/1. The author is grateful to Marta
Kwiatkowska, David Parker, Gethin Norman and Mark Kattenbelt for insightful discussions during
the integration of the PRISM probabilistic model checker with the autonomic policy engine.
References
1. J. Arwe et al. Service Modeling Language, version 1.0, March 2007. http://www.w3.org/
Submission/2007/SUBM-sml-20070321.
2. C. M. Bishop. Pattern Recognition and Machine Learning. Springer, 2007.
3. E. Bruneton et al. The Fractal component model and its support in Java. Softw. Pract.
Exper., 36:1257–1284, 2006.
4. R. Calinescu. Challenges and best practices in policy-based autonomic architectures. In Proc.
3rd IEEE Intl. Symp. Dependable, Autonomic and Secure Computing, pages 65–74, 2007.
5. R. Calinescu. Model-driven autonomic architecture. In Proc. 4th IEEE Intl. Conf. Autonomic
Computing, June 2007.
6. R. Calinescu. Towards a generic autonomic architecture for legacy resource management. In
K. Elleithy, editor, Innovations and Advanced Techniques in Systems, Computing Sciences and
Software Engineering, pages 410–415, Springer, 2008.
7. R. Calinescu. Implementation of a generic autonomic framework. In D. Greenwood et al.,
editor, Proc. 4th Intl. Conf. Autonomic and Autonomous Systems, pages 124–129, March 2008.
8. M. Devarakonda et al. Policy-based autonomic storage allocation. In Self-Managing Dis-
tributed Systems, volume 2867 of LNCS, pages 143–154. Springer, 2004.
9. S. Dobson et al. A survey of autonomic communications. ACM Transactions on Autonomous
and Adaptive Systems, 1(2):223–259, December 2006.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-44-320.jpg)
![Software Architecture-Based Self-Adaptation 33
In this chapter, we introduce the ideas behind architecture-based self-adapting
systems; briefly survey the research landscape; discuss the research and engineer-
ing challenges, particularly with respect to autonomic behavior for distributed, net-
worked systems; and describe the Rainbow approach and how it addresses these
challenges. We also give examples of its use in the context of autonomic networks,
focusing on adaptations to improve qualities such as fidelity, performance, security,
and cost of operation.
2 Overview of Autonomic and Self-Adaptive Systems
Overcoming the challenges of self-adaptation and allowing managed systems to
self-adapt with minimal human oversight requires closing the “loop of control.”
Software systems have traditionally been designed as open-loop systems: once a
system is designed for a certain function and deployed, its extra-functional quality
attributes typically remain relatively unchanged. In most cases, if something goes
wrong, humans must intervene, often by restarting the failed subsystem or taking
the entire system offline for repair. This results in high costs in system downtime,
personnel costs, and decreased revenue through system unavailability.
To address this problem, a number of researchers have proposed an alternative
approach that uses external software mechanisms to maintain a form of closed-loop
control over the target system (e.g., [26, 30, 39]). Such mechanisms allow a system
to self-adapt dynamically, with reduced human oversight. Minimally, closed-loop
control consists of mechanisms that monitor the system, reflect on observations for
problems, and control the system to maintain it within acceptable bounds of behav-
ior. This kind of system is known as a feedback control system in control theory [42].
Feedback control systems have typically been applied to control physical sys-
tems. For simple systems, the control model may be built-in to the design. For
example, a home thermostat that measures room temperature and checks it against
the set point, controlling a home heating and cooling system, will typically have a
simple built-in thermodynamic model. In more complex systems an explicit process
model is necessary for effective control [42]. For example, an air conditioning sys-
tem for a large building that monitors and controls multiple locations would require
an explicit model of the building partitions and temperatures to efficiently control
which cooling units to turn on and when.
For software systems, the external controller requires an explicit model of the
target system in order to reflect on observations and to configure and repair the
system [39]. Monitoring mechanisms extract and aggregate target system informa-
tion to update the model. An evaluation mechanism detects problems in the target
system as reflected in the model. The appearance of a problem triggers an adaptation
mechanism to use the model to determine a course of action. The mechanism then
propagates the necessary changes to the target system to fix the problem.
In principle, external mechanisms have a number of benefits over internal mecha-
nisms. External control separates the concerns of system functionality from those of](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-49-320.jpg)
![34 D. Garlan et al.
adaptation (or “exceptional”) behaviors. With the adaptation mechanism as a sep-
arate entity, engineers can more easily modify and extend it, and reason about its
adaptation logic. Furthermore, the separation of mechanisms allows the application
of this technique even to legacy systems with inaccessible source code, as long
as the target system provides, or can be instrumented to provide, hooks to extract
system information and to make changes. Finally, providing external control with
generic but customizable mechanisms (e.g., model management, problem detection,
strategy selection) facilitates reuse across systems, reducing the cost of developing
new self-adaptive systems.
2.1 The IBM Autonomic Framework
The IBM Autonomic Computing Initiative codified an external, feedback control
approach in its Autonomic Monitor-Analyze-Plan-Execute (MAPE) Model [28].
Figure 1 illustrates the MAPE loop, which distinguishes between the autonomic
manager (embodied in the large rounded rectangle) and the managed element,
which is either an entire system or a component within a larger system. The MAPE
loop highlights four essential aspects of self-adaptation:
1. Monitor: The monitoring phase is concerned with extracting information—
properties or states—out of the managed element. Mechanisms range from
source-code instrumentation to non-intrusive communication interception.
2. Analyze: is concerned with determining if something has gone awry in the sys-
tem, usually because a system property exhibits a value outside of expected
bounds, or has a degrading trend.
3. Plan: is concerned with determining a course of action to adapt the managed
element once a problem is detected.
4. Execute: is concerned with carrying out a chosen course of action and effecting
the changes in the system.
Fig. 1 The IBM Autonomic MAPE Reference Model](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-50-320.jpg)
![Software Architecture-Based Self-Adaptation 35
Shared between these four phases is the Knowledge component, which contains
models, data, and plans or scripts to enable separation of adaptation responsibilities
and coordination of adaptations. The Rainbow framework provides components that
fulfill each of these four phases and the knowledge to support self-adaptation.
3 Software Architecture and Architecture-Based Self-Adaptation
A key issue in using an external model is to determine the appropriate kind of mod-
els to use for software-based systems. Each type of model has certain advantages
in terms of the analyses and kinds of adaptation it supports. In principle, a model
should be abstract enough to allow straightforward detection of problems in the
target system, but should provide enough fidelity to determine remedial actions to
take to fix the problem. State machines, queuing theory, graph theory, differential
equations, and other mathematical models [40, 42] have all been used for model-
based, external adaptation of software systems.
We, among others, use a system’s software architecture as the external model for
dynamic adaptation [19, 39]. The architecture of a software system is an abstract
representation of the system as a composition of computational elements and their
interconnections [44]. Specifically, an architecture model represents the system as
a graph of interacting components.1
Nodes in the graph, termed components, rep-
resent the principal computational elements and data stores of the system: clients,
servers, databases, user interfaces, etc. Arcs, termed connectors, represent the path-
ways of interaction between the components. This is the core architectural represen-
tation scheme adopted by a number of architecture description languages (ADLs),
such as Acme [20] and xADL [13].
The use of software architecture as the basis for self-adaptation, termed
architecture-based self-adaptation, holds a number of potential promises. A rich
body of work on architecture trade-off analysis techniques used at system design
time facilitates runtime self-adaptation. As an abstract model, an architecture model
provides a global perspective on the system and exposes the important system-level
behaviors and properties. As a locus of high-level system design decisions, the
model makes system integrity constraints explicit, thereby helping to ensure the
validity of a change. For example, the architecture model can expose important
properties such as throughput and bandwidth, allowing the overall throughput
or performance of the system to be analyzed. Furthermore, the model might be
associated with explicit constraints on the architecture that, for example, forbid
cycles. This knowledge can be used at runtime to reason about the effect of a
change on the system’s throughput or structure. See [18] for a discussion of this
concept for performance evaluation.
1 We are primarily interested in the component–connector view [11] because it characterizes the
abstract state and behavior of the system at runtime to enable reasoning about problems and courses
of adaptation.](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-51-320.jpg)
![36 D. Garlan et al.
Crucial for architecture-based self-adaptation is the choice of the architectural
style used to represent the target system. A style (e.g., pipe-filter) provides the
vocabulary to describe the architecture of a system in terms of a set of component
types (e.g., filter) and connector types (e.g., pipe), along with the rules for composi-
tion (e.g., no cycles) [1]. A style might also prescribe the properties associated with
particular element types (e.g., throughput on a pipe). Usually associated with a style
is a set of analytical methods to reason about properties of systems in that style. For
example, systems in the MetaH style supports real-time schedulability analysis [16].
For self-adaptation, given some quality objectives, each style may guide the
choice of system properties to monitor, help identify strategic points for system
observation, and suggest possible adaptations. To illustrate this, consider a signal-
processing system with an architecture in the pipe-filter style. This style constrains
the system to a data-flow computation pattern, points to throughput as a system
property, identifies the filter as a strategic point for measuring throughput, and sug-
gests throughput analysis for reasoning about overall system throughput. The pipe-
filter style may suggest adaptations that swap in variants of filters to adjust through-
put, create redundant paths to improve reliability, or add encryption to enhance
security. In contrast, consider a different system in the client–server style. This
style highlights request-response latency as a key property, identifies the client as a
strategic point for measuring latency and the server for load, and suggests the use of
queuing theory to reason about service time and latency. The style may suggest an
adaptation that switches clients to less loaded servers to reduce latency.
4 Related Work
To date, several dynamic software architectures and architecture-based adaptation
frameworks have been proposed and developed [7, 24, 39], including an effort to
characterize the style requirements of self-healing systems [35]. Below, we examine
a representative set of approaches, categorizing each by its primary focus, then high-
lighting its main features. Broadly speaking, related approaches focus on formalism
and modeling, or mechanisms of adaptation. A third category addresses distribution
and decentralization of control.
4.1 Distributed, Decentralized Adaptation
Work on self-organizing systems in [23] proposes an approach where self-managing
units coordinate toward a common model, an architectural structure defined using
the architectural formalism of Darwin [33]. Each self-organizing component is
responsible for managing its own adaptation with respect to the overall system. To
do this, each component maintains a copy of the architecture model of the entire
system. While this approach provides the advantage of distributed control and elim-
inates a single point of failure, requiring each component to maintain a global model](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-52-320.jpg)
![Software Architecture-Based Self-Adaptation 37
and keep the model consistent, which imposes significant performance overhead.
Furthermore, the approach prescribes a fixed distributed algorithm for global config-
uration. We overcome the performance overhead and coordination issue by allowing
tailorable global reorganization without imposing a high-performance overhead, but
we trade off distributed, localized control of adaptation decision.
4.2 Formal, Dynamic Architectures
A number of approaches focus on modeling and formalizing dynamic systems,
rather than mechanisms to enable self-adaption. Our approach builds on formal
architectural modeling, using the model within a framework of reusable infras-
tructures to enable self-adaptation in a target system. Wermelinger and colleagues
developed a high-level language, based on CommUnity, to describe architectures,
as well as changes over an architectural configuration, such as adding, removing, or
substituting components or interconnections [49].
The K-Component model addresses the integrity and safety of dynamic software
evolution, modeled as graph transformations of meta-models on architecture [15]. It
uses reflective programs called adaptation contracts to build adaptive applications,
coordinated via a configuration manager (similar to Le Métayer’s approach [31]).
Darwin is an ADL for specifying the architecture of a distributed system, with an
operational semantics that captures dynamic structures as the elaboration of com-
ponents and their bindings in a configuration [33]. Organization of components and
connectors may change during execution. The evolving structures of Darwin are
modeled using Milner’s -calculus, allowing the correctness of its program elab-
oration to be analyzed. Together with its -calculus semantics, Darwin serves as
a general-purpose configuration language for specifying distributed systems. Arch-
Ware [37] and PiLar [12] are examples of ADLs that use architectural reflection to
model layers of active architectures, allowing separate concerns to be addressed at
different layers. These approaches rely on sophisticated reflective technologies to
support the active architectures and enable dynamic co-evolution.
These approaches assume that system implementations are generated from the
architecture descriptions. In contrast, our approach relies on external mechanisms
decoupled from the target system and can therefore be used to add adaptation to
existing systems.
4.3 Style-Specific Approaches with Fixed Quality Attributes
A number of architecture-based approaches provide mechanisms to enable self-
adaptation (or system reconfiguration) that focus on particular quality attributes
of systems, such as performance [6, 27, 32], survivability [50], or that focus on
particular architectural styles, for example, [26, 38].](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-53-320.jpg)
![38 D. Garlan et al.
Most closely related to our own work is that of the UCI Research group headed by
Taylor [14], and the research of Sztajnberg [47]. As a natural extension of [38], Tay-
lor’s group developed an architecture-based runtime architecture evolution frame-
work, which dynamically evolves systems using a monitoring and execution loop
controlled by a planning loop. This framework supports self-adaptation for C2-style
systems, and evolution of the architecture model uses architectural differencing and
merging techniques similar to those used for source code version control. Sztajnberg
and Loques developed the CR-RIO framework, which uses a style-neutral ADL
(CBabel), architectural contracts to specify execution context, application profiles
to describe resource requirements, and middleware to perform architectural recon-
figurations based on the specified contracts. CR-RIO demonstrates a formal ver-
ification capability but does not appear to support automation of multi-objective
adaptations, for example by composing multiple contracts, nor does it address engi-
neering aspects. Our approach can be applied to different classes of systems and can
address multiple quality objectives.
Current approaches present a number of limitations and unresolved issues, which
are addressed by Rainbow. In particular, where traditional adaptive techniques—for
example, the ones based on exception-handling mechanisms and network time-
outs—rely only on localized knowledge of system states, we use an architecture-
based approach to leverage a more global perspective. While existing approaches
do not address the quantity of adaptation and system-level details that engineers
grapple with in order to build self-adaptation for their systems, we design a language
that encapsulates core self-adaptation concepts and hoists them as first-class build-
ing blocks for system engineers to build self-adaptation capabilities. Finally, almost
no existing approach provides a systematic, integrated approach to self-adaptation
that combines an end-to-end system perspective, style-based adaptation, automation
of routine human expertise, and incremental support to developing self-adaptation
capabilities; we address this by providing a framework with reusable infrastructures
and customizable elements.
5 The Rainbow Approach
Related work provides some of the building blocks for our own research. Software
architecture research provides the language, models, and analysis mechanisms to
represent and reason about a system’s runtime properties; related work in self-
healing systems and architecture-based approaches demonstrate the effectiveness
of using software architecture for particular classes of systems and fixed quality
attributes. What is missing is an approach to self-adaptation that (a) is generally
applicable to different classes of systems and quality objectives, (b) allows adapta-
tion to be represented as explicit operational entities and chooses the best one in a
principled and analyzable way, and (c) provides an integrated approach that saves
engineers time and effort in writing and changing adaptation.
Our approach satisfies the above requirements by (1) providing a framework,
called Rainbow, that provides general, supporting mechanisms for self-adaptation,](https://image.slidesharecdn.com/28349623-250522124519-11876610/85/Autonomic-Computing-And-Networking-2009th-Edition-Mieso-Denko-54-320.jpg)
Autonomic Computing And Networking 2009th Edition Mieso Denko
- 1. Autonomic Computing And Networking 2009th Edition Mieso Denko download https://ebookbell.com/product/autonomic-computing-and- networking-2009th-edition-mieso-denko-56699246 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Advanced Autonomic Networking And Communication Whitestein Series In Software Agent Technologies And Autonomic Computing 1st Edition Monique Calisti https://ebookbell.com/product/advanced-autonomic-networking-and- communication-whitestein-series-in-software-agent-technologies-and- autonomic-computing-1st-edition-monique-calisti-2176724 Autonomic Computing And Communications Systems Third International Icst Conference Autonomics 2009 Limassol Cyprus September 911 2009 Revised Selected Papers 1st Edition Athanasius V Vasilakos https://ebookbell.com/product/autonomic-computing-and-communications- systems-third-international-icst-conference-autonomics-2009-limassol- cyprus-september-911-2009-revised-selected-papers-1st-edition- athanasius-v-vasilakos-4201856 Law Human Agency And Autonomic Computing The Philosophy Of Law Meets The Philosophy Of Technology 1st Edition Mireille Hildebrandt Editor https://ebookbell.com/product/law-human-agency-and-autonomic- computing-the-philosophy-of-law-meets-the-philosophy-of- technology-1st-edition-mireille-hildebrandt-editor-36289768 Defense Industry Applications Of Autonomous Agents And Multiagent Systems Whitestein Series In Software Agent Technologies And Autonomic Computing 1st Edition Michal Pechoucek https://ebookbell.com/product/defense-industry-applications-of- autonomous-agents-and-multiagent-systems-whitestein-series-in- software-agent-technologies-and-autonomic-computing-1st-edition- michal-pechoucek-2166106
- 3. Cascom Intelligent Service Coordination In The Semantic Web Whitestein Series In Software Agent Technologies And Autonomic Computing 1st Edition Michael Schumacher https://ebookbell.com/product/cascom-intelligent-service-coordination- in-the-semantic-web-whitestein-series-in-software-agent-technologies- and-autonomic-computing-1st-edition-michael-schumacher-2166110 Bidding Strategies In Agentbased Continuous Double Auctions Whitestein Series In Software Agent Technologies And Autonomic Computing 1st Edition Huiye Ma https://ebookbell.com/product/bidding-strategies-in-agentbased- continuous-double-auctions-whitestein-series-in-software-agent- technologies-and-autonomic-computing-1st-edition-huiye-ma-2166586 The Agent Modeling Language Aml A Comprehensive Approach To Modeling Multiagent Systems Whitestein Series In Software Agent Technologies And Autonomic Computing 1st Edition Radovan Cervenka https://ebookbell.com/product/the-agent-modeling-language-aml-a- comprehensive-approach-to-modeling-multiagent-systems-whitestein- series-in-software-agent-technologies-and-autonomic-computing-1st- edition-radovan-cervenka-2426264 Autonomic Computing Principles Design And Implementation 1st Edition Philippe Lalanda https://ebookbell.com/product/autonomic-computing-principles-design- and-implementation-1st-edition-philippe-lalanda-4242138 Autonomic Computing Concepts Infrastructure And Applications Hariri https://ebookbell.com/product/autonomic-computing-concepts- infrastructure-and-applications-hariri-22052558
- 5. Mieso K. Denko LaurenceTianruoYang Yan Zhang Editors Autonomic Computing and Networking
- 6. Autonomic Computing and Networking
- 7. Mieso K. Denko · Laurence Tianruo Yang · Yan Zhang Editors Autonomic Computing and Networking 123
- 8. Editors Mieso K. Denko Department of Computing and Information Science University of Guelph Reynolds Building Guelph, ON N1G 2W1 Canada denko@cis.uoguelph.ca Yan Zhang Simula Research Laboratory Norway yanzhang@ieee.org Laurence Tianruo Yang Department of Computer Science Francis Xavier University Antigonish, NS B2G 2W5 Canada ltyang@gmail.com ISBN 978-0-387-89827-8 e-ISBN 978-0-387-89828-5 DOI 10.1007/978-0-387-89828-5 Library of Congress Control Number: 2008940265 c Springer Science+Business Media, LLC 2009 All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed on acid-free paper springer.com
- 9. Preface Autonomic computing and networking are emerging paradigms that allow for the creation of self-managing and self-controlling environments by employing distributed algorithms and context-awareness to dynamically control networking functions without human interventions. Autonomic networking is characterized by recovery from failures and malfunctions and agility to changing networking envi- ronments and self-optimization. The self-control and management features can help overcome the growing complexity and heterogeneity of existing communication net- works and systems. The realization of fully autonomic heterogeneous networking requires fundamental research challenges in all aspects of computing, networking, communications, and other related fields. This book, with chapters contributed by prominent researchers from academia and industry, will serve as a technical guide and reference material for engineers, scientists, practitioners, and researchers by providing them with state-of-the-art research findings and future opportunities and trends. These contributions include state-of-the-art architectures, protocols, technologies, and applications in pervasive computing and wireless networking. In particular, the book covers existing and emerging communications and computing models, design architectures, mobile and wireless applications, technologies, and research issues in autonomic computing systems and communications. The book has 18 chapters organized into two sections: autonomic computing and autonomic networking. Each section contains nine chapters addressing existing and emerging architectures, protocols, and applications. Part I Autonomic Computing This section consists of Chapters 1–9 and covers various topics on autonomic com- puting systems and applications. Chapter 1 by Radu discusses a generic autonomic computing framework for the development of self-managing systems. A prototype implementation of the reconfigurable policy engine is used to develop autonomic solutions in case studies from several application domains. Chapter 2 by Garlan et al. presents a system called Rainbow that uses software architecture models and styles to support self-adaptation. The framework provides v
- 10. vi Preface general and reusable infrastructures with well-defined customization points, allow- ing engineers to systematically customize Rainbow for particular systems. Chap- ter 3 by Mpitziopoulos et al. discusses mobile agent-based middleware solutions for autonomic data fusion tasks. Chapter 4 by Hagimont et al. presents a component- based autonomic management system for legacy software. It describes the design and implementation of such a system and evaluates different uses. Chapter 5 by Brock and Goscinski proposes a dynamic web services description language for sup- porting autonomic computing. The framework allows the attributes of web services to be visible, thus allowing the autonomic system to better cater to the installation and use of new components. Chapter 6 by Oliveri et al. discusses a bio-inspired cognitive radio for dynamic spectrum access. Autonomic bio-inspired approaches Part II: Autonomic Networking This section consists of Chapters 10–18 with a focus on autonomic networking and communications. Chapter 10 by Boutaba et al. discusses autonomic networks with focus on knowl- edge management and self-stabilization. In-depth discussions of basic concepts, research challenges, and their importance for the success of autonomic networks are presented. Chapter 11 by Yu et al. discusses autonomic wireless sensor net- works. The chapter has an in-depth discussion of existing research activities in this area. Chapter 12 by Wada et al. discusses a model-driven development environment for biologically inspired autonomic network applications. The chapter proposes and evaluates a new development environment, called iNetLab, which can improve the productivity of designing, maintaining, and tuning operational policies in autonomic network applications. Chapter 13 by Cascado et al. discusses network reconfigura- tion in high-performance interconnection networks. Chapter 14 by Zulkernine et al. discusses autonomic management of networked web service-based processes. The authors discuss web services management from service providers’ and service con- sumers’ perspectives. Chapter 15 by Zseby et al. discusses self-protection in autonomic and related net- works. Chapter 16 by Cong-Vinh discusses the formal aspects of self-∗ in autonomic networked computing systems. Chapter 17 by Alouf et al. discusses autonomic information diffusion in intermittently connected networks. The chapter proposes a framework for designing autonomic information diffusion mechanisms using tech- niques and tools drawn from evolutionary computing research. Finally, Chapter 18 and spectral access are also discussed. Chapter 7 by Boucadair discusses the intro- duction of autonomous behaviors to IP multimedia subsystem (IMS)-based architec- tures. Solutions covered aim at enhancing the robustness and the availability of cur- rent IMS-based architectures owing to the activation of autonomic-like techniques. Chapter 8 by Bixio et al. discusses the cognition-based distributed spectrum sensing for autonomic wireless systems. Finally, in Chapter 9, Kwok presents an autonomic peer-to-peer systems with a focus on incentive and security issues.
- 11. Preface vii by He et al. presents dynamic and fair spectrum access mechanism for autonomous communications. This book has the following salient features: • Provides a comprehensive reference on autonomic computing and networking. • Presents state-of-the-art techniques in autonomic computing and networking. • Contains illustrative figures enabling easy reading. • Discusses emerging trends and open research problems in autonomic computing and networking. We owe our deepest gratitude to all the authors for their valuable contribution to this book and their great efforts. All of them are extremely professional and cooper- ative. We wish to express our thanks to Springer especially Katelyn Stanne, Caitlin Womersley, and Jason Ward for their support and guidance during the preparation of this book. A special thank also goes to our families and friends for their constant encouragement, patience, and understanding throughout this project. The book serves as a comprehensive and essential reference on autonomic com- puting and networking and is intended as a textbook for senior undergraduate and graduate-level courses. It can also be used as a supplementary textbook for under- graduate courses. The book is a useful resource for the students and researchers to learn autonomic computing and networking. In addition, it will be valuable to pro- fessionals from both the academia and industry and generally serves instant appeal to the people who would like to contribute to autonomic computing and networking technologies. We welcome and appreciate your feedback and hope you enjoy reading the book. Mieso K. Denko Ontario, Canada Laurence T. Yang Nova Scotia, Canada Yan Zhang Oslo, Norway
- 12. Contents Part I Autonomic Computing General-Purpose Autonomic Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Radu Calinescu Software Architecture-Based Self-Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . 31 David Garlan, Bradley Schmerl, and Shang-Wen Cheng Mobile Agent Middleware for Autonomic Data Fusion in Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Aristides Mpitziopoulos, Damianos Gavalas, Charalampos Konstantopoulos, and Grammati Pantziou Component-Based Autonomic Management for Legacy Software . . . . . . . . 83 Daniel Hagimont, Patricia Stolf, Laurent Broto, and Noel De Palma Dynamic WSDL for Supporting Autonomic Computing . . . . . . . . . . . . . . . . 105 Michael Brock and Andrzej Goscinski Bio-inspired Cognitive Radio for Dynamic Spectrum Access. . . . . . . . . . . . . 131 Giacomo Oliveri, Marina Ottonello, and Carlo S. Regazzoni Introducing Autonomous Behaviors into IMS-Based Architectures . . . . . . . 155 Mohamed Boucadair Embodied Cognition-Based Distributed Spectrum Sensing for Autonomic Wireless Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Luca Bixio, Andrea F. Cattoni, Carlo S. Regazzoni, and Pramod K. Varshney Autonomic Peer-to-Peer Systems: Incentive and Security Issues. . . . . . . . . . 205 Yu-Kwong Kwok ix
- 13. x Contents Part II Autonomic Networking Toward Autonomic Networks: Knowledge Management and Self-Stabilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Raouf Boutaba, Jin Xiao, and Qi Zhang Autonomic Networking in Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . 261 Mengjie Yu, Hala Mokhtar, and Madjid Merabti iNetLab: A Model-Driven Development and Performance Engineering Environment for Autonomic Network Applications . . . . . . . . . . . . . . . . . . . . . 285 Hiroshi Wada, Chonho Lee, Junichi Suzuki, and Tetsuo Otani Network Reconfiguration in High-Performance Interconnection Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 R. Casado, A. Bermúdez, A. Robles-Gómez, O. Lysne, T. Skeie, Å.G. Solheim, and T. Sødring Autonomic Management of Networked Web Services-Based Processes . . . . 333 Farhana H. Zulkernine, Wendy Powley, and Patrick Martin Concepts for Self-Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Tanja Zseby, Heiko Pfeffer, and Stephan Steglich Formal Aspects of Self-∗ in Autonomic Networked Computing Systems . . . 381 Phan Cong-Vinh Autonomic Information Diffusion in Intermittently Connected Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Sara Alouf, Iacopo Carreras, Álvaro Fialho, Daniele Miorandi, and Giovanni Neglia Dynamic and Fair Spectrum Access for Autonomous Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Jianhua He, Jie Xiang, Yan Zhang, and Zuoyin Tang Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
- 14. Contributors Sara Alouf INRIA, Sophia Antipolis, France, sara.alouf@sophia.inria.fr A. Bermúdez Universidad de Castilla-La Mancha, I3A Campus Universitario s/n, 02071 Albacete, Spain, abermu@dsi.uclm.es Luca Bixio Department of Biophysical and Electronic Engineering, University of Genova, Via Opera Pia 11a, 16145 Genova, Italy, luca.bixio@dibe.unige.it Mohamed Boucadair France Télécom RD, 42 Rue des coutures, 14066 Caen Cedex, France, mohamed.boucadair@orange-ftgroup.com Raouf Boutaba David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON, Canada, rboutaba@cs.uwaterloo.ca Michael Brock Deakin University, Pigdons Road, Waurn Ponds, Geelong, Victoria 3217, Australia, mrab@deakin.edu.au Laurent Broto UPS, Toulouse, France, broto@irit.fr Radu Calinescu Computing Laboratory, University of Oxford, Oxford, England UK, Radu.Calinescu@comlab.ox.ac.uk Iacopo Carreras CREATE-NET, Trento, Italy, iacopo.carreras@create-net.org R. Casado Universidad de Castilla-La Mancha, I3A Campus Universitario s/n, 02071 Albacete, Spain, rcasado@dsi.uclm.es Andrea F. Cattoni Department of Biophysical and Electronic Engineering, University of Genova, Via Opera Pia 11a, 16145 Genova, Italy, cattoni@dibe.unige.it Shang-Wen Cheng Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA 15213, USA, zensoul@cs.cmu.edu Phan Cong-Vinh London South Bank University, Borough Road, London SE1 0AA, United Kingdom, phanvc@ieee.org Noel De Palma INPG, Grenoble, France, depalma@inrialpes.fr xi
- 15. xii Contributors Álvaro Roberto Silvestre Fialho INRIA, Sophia Antipolis, France, Now at Microsoft Research-INRIA Joint Centre, Orsay, France, alvaro.fialho@inria.fr David Garlan Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA 15213, USA, garlan@cs.cmu.edu Damianos Gavalas Dept of Cultural Technology and Communication, University of the Aegean Address of Institute, Lesvos, Greece, dgavalas@aegean.gr Andrzej Goscinski Deakin University, Pigdons Road, Waurn Ponds, Geelong Victoria 3217, Australia, ang@deakin.edu.au Daniel Hagimont INPT, Toulouse, France, hagimont@enseeiht.fr Jianhua He Institute of Advanced Telecommunications, Swansea University, Swansea SA2 8PP, UK, j.he@swansea.ac.uk Charalampos Konstantopoulos Research Academic Computer Technology Institute, Patras, Greece, konstant@cti.gr Yu-Kwong Kwok Department of Electrical and Computer Engineering, Colorado State University, Fort Collins, CO 80526-1373, USA, Ricky.Kwok@colostate.edu Chonho Lee University of Massachusetts, Boston, MA, USA chonho@cs.umb.edu O. Lysne University of Oslo, Simula Research Laboratory, P.O. Box 134, N-1325 Lysaker, Norway, olavly@simula.no Patrick Martin School of Computing, Queen’s University, Kingston, ON K7L 3N6, Canada, martin@cs.queensu.ca Madjid Merabti School of Computing and Mathematical Science, Liverpool John Moores University, Byrom Street, Liverpool, UK, M.Merabti@ljmu.ac.uk Daniele Miorandi CREATE-NET, Trento, Italy, daniele.miorandi@create-net.org Hala Mokhtar School of Computing and Mathematical Science, Liverpool John Moores University, Byrom Street, Liverpool, UK, H.M.Mokhtar@ljmu.ac.uk Aristides Mpitziopoulos Dept of Cultural Technology and Communication, University of the Aegean Address of Institute, Lesvos, Greece, crmaris@aegean.gr Giovanni Neglia INRIA, Sophia Antipolis, France University of Palermo, P alermo, Italy, giovanni.neglia@ieee.org Giacomo Oliveri Department of Biophysical and Electronic Engineering, University of Genova, Via Opera Pia 11a, 16145 Genova, Italy, giacomo.oliveri@dibe.unige.it Tetsuo Otani Central Research Institute of Electric Power Industry ohtani@criepi.denken.or.jp
- 16. Contributors xiii Marina Ottonello Department of Biophysical and Electronic Engineering, University of Genova, Via Opera Pia 11a, 16145 Genova, Italy, marina@dibe.unige.it Grammati Pantziou Department of Informatics, Technological Educational Institution of Athens, Athens, Greece, pantziou@teiath.gr Heiko Pfeffer Fraunhofer Institute Fokus, Berlin, Germany heiko.pfeffer@fokus.fraunhofer.de Wendy Powley School of Computing, Queen’s University, Kingston, ON K7L 3N6, Canada, wendy@cs.queensu.ca Carlo S. Regazzoni Department of Biophysical and Electronic Engineering, University of Genova, Via Opera Pia 11a, 16145 Genova, Italy, carlo@dibe.unige.it A. Robles-Gómez Universidad de Castilla-La Mancha, I3A Campus Universitario s/n, 02071 Albacete, Spain, arobles@dsi.uclm.es Bradley Schmerl Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA 15213, USA, schmerl@cs.cmu.edu T. Skeie University of Oslo, Simula Research Laboratory, P.O. Box 134, N-1325 Lysaker, Norway, tskeie@simula.no T. Sødring University of Oslo, Simula Research Laboratory, P.O. Box 134, N-1325 Lysaker, Norway, tsodring@simula.no A.G. Solheim University of Oslo, Simula Research Laboratory, P.O. Box 134, N-1325 Lysaker, Norway, aashig@simula.no Stephan Steglich Fraunhofer Institute Fokus, Berlin, Germany stephan.steglich@fokus.fraunhofer.de Patricia Stolf IUFM, Toulouse, France, stolf@irit.fr Junichi Suzuki University of Massachusetts, Boston, MA jxsg@cs.umb.edu Zuoyin Tang Pramod K. Varshney Department of Electrical Engineering and Computer Science, Syracuse University, NY, USA, varshney@syr.edu Hiroshi Wada University of Massachusetts, Boston, MA, USA, fshu@cs.umb.edu Jie Xiang Simula Research Laboratory, Martin Linges vei 17, IT Fornebu, P.O.Box 134, No-1325 Lysaker, Norway, jxiang@simula.no Jin Xiao David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON, Canada, j2xiao@cs.uwaterloo.ca Mengjie Yu School of Computing and Mathematical Science, Liverpool John Moores University, Byrom Street, Liverpool UK, M.Yu@2001.ljmu.ac.uk
- 17. xiv Contributors Qi Zhang David R. Cheriton School of Computer Science, University of Waterloo, Waterloo, ON, Canada, q8zhangg@cs.uwaterloo.ca Tanja Zseby Fraunhofer Institute Fokus, Berlin, Germany tanja.zseby@fokus.fraunhofer.de Farhana H. Zulkernine School of Computing, Queen’s University, Kingston, ON K7L 3N6, Canada, farhana@cs.queensu.ca Yan Zhang Simula Research Laboratory, Norway, yanzhang@iee.org Zuoyin Tang Department of Electronic and Electrical Engineering, University of Strathclyde, Glasgow G1 1XW, UK, Zuoyin.Tang@strath.ac.uk
- 19. General-Purpose Autonomic Computing Radu Calinescu Abstract The success of mainstream computing is largely due to the widespread availability of general-purpose architectures and of generic approaches that can be used to solve real-world problems cost-effectively and across a broad range of application domains. In this chapter, we propose that a similar generic frame- work is used to make the development of autonomic solutions cost effective, and to establish autonomic computing as a major approach to managing the complexity of today’s large-scale systems and systems of systems. To demonstrate the feasibility of general-purpose autonomic computing, we introduce a generic autonomic com- puting framework comprising a policy-based autonomic architecture and a novel four-step method for the effective development of self-managing systems. A pro- totype implementation of the reconfigurable policy engine at the core of our archi- tecture is then used to develop autonomic solutions for case studies from several application domains. Looking into the future, we describe a methodology for the engineering of self-managing systems that extends and generalises our autonomic computing framework further. 1 Introduction The last decade has brought revolutionary transformations to the way in which information and communication technologies (ICT) are used to conduct business and research and to provide services in all sectors of the society [26]. The ability to accomplish more, faster and on a broader scale through expert use of ever more complex ICT systems is at the core of today’s scientific discoveries, newly emerged services and everyday life. Autonomic computing represents an effective approach to managing the spiralling complexity of these systems by delegating their configu- ration, optimisation, repair and protection to the systems themselves [15, 21]. R. Calinescu (B) Computing Laboratory, University of Oxford, Oxford, England, UK e-mail: Radu.Calinescu@comlab.ox.ac.uk M.K. Denko et al. (eds.), Autonomic Computing and Networking, DOI 10.1007/978-0-387-89828-5 1, C Springer Science+Business Media, LLC 2009 3
- 20. 4 R. Calinescu The research efforts of the past few years have generated a wealth of knowl- edge on what autonomic systems should look like [9, 13, 21, 31, 34] and what best practices to follow in building them [4, 16, 41, 43]. This progress is to a great extent a by-product of the effort that went into the development of successful auto- nomic solutions addressing specific management tasks in real-world applications [8, 25, 27, 40, 42]. While these developments demonstrate the feasibility of the auto- nomic computing approach to complexity management, the current use of bespoke and domain-specific architectures, and of dedicated models and policies limits sig- nificantly the cost-effectiveness and reusability of today’s autonomic solutions. These limitations resemble the problems encountered in the early days of main- stream computing, and overcome successfully through the use of general-purpose architectures and generic approaches for the development of real-world applica- tions across multiple application domains. We therefore propose that an equally generic framework is used to make the development of self-managing systems cost- effective, and to drive standardisation, component reuse and user adoption in the realm of autonomic computing. Given that policy-based autonomic computing rep- resents the most advanced approach to developing self-managing systems of practi- cal utility, we describe below the criteria that a policy-based autonomic computing framework needs to satisfy in order to qualify as “general purpose”: C1 Support for the whole range of software, hardware and data compo- nents encountered in real-world ICT systems. To enable the development of effective autonomic systems for real-world applications, the framework should support the organisation of heterogeneous collections of existing and future ICT components into self-managing systems. Both components specifically designed for inclusion into a self-managing system (i.e., autonomic-enabled ICT resources) and components not originally intended for this purpose (i.e., legacy ICT resources) should be catered for.1 C2 Support for a broad spectrum of self-* functional areas and autonomic computing policies. The framework should aid the development of self- management capabilities spawning a rich spectrum of self-* functional areas, e.g., self-configuration, self-healing, self-optimisation and self-protection [21, 31, 34]. This must be achieved through supporting all types of autonomic computing policies, including action, goal and utility-function policies [44, 45]. C3 Support for the cost-effective development of self-managing systems for a large variety of application domains and use cases. The framework must reduce the effort and costs incurred in the development of today’s autonomic systems significantly through enabling the extensive reuse of components and the sharing of autonomic computing models and policies. It should drive the standardisation of interfaces, policies, models and components for autonomic computing, and should allow and encourage the modular development of com- plex self-managing systems and systems of systems. Last but not least, the framework must provide a generic method for developing autonomic systems from any combination of legacy and/or autonomic-enabled ICT resources. 1 The ICT components to be integrated into an autonomic system will be termed (ICT) resources.
- 21. General-Purpose Autonomic Computing 5 To demonstrate the feasibility of general-purpose autonomic computing, we introduce a novel policy-based autonomic computing framework comprising an autonomic architecture designed around a reconfigurable policy engine, and a four- step method for the effective development of self-managing systems. This frame- work builds on recent advances in autonomic computing [9, 13, 17, 34], and extends the author’s previous work in this area [4–7] in several new directions. Thus, we describe for the first time how multiple instances of the same general-purpose autonomic architecture can be organised into self-managing systems of systems by means of a new type of autonomic policy termed a resource-definition policy. Also, we present the first-ever integration of quantitative model checking techniques [23, 24] into autonomic policy engines, and show how the use of this new capability enables the specification of powerful utility-function policies. Finally, we present a new four-step method for the development of self-managing systems starting from a model of their ICT resources, and we illustrate its application to several case studies that spawn different application domains and employ a wide range of policy types. The remainder of the chapter is organised as follows. In Sect. 2, we contrast our framework with other approaches to autonomic solution development. We then describe the general-purpose autonomic architecture and the reconfigurable policy engine at its core in Sects. 3 and 4, respectively. A prototype implementation of the policy engine is presented in Sect. 5, followed by the description of our generic method for the development of self-managing systems in Sect. 6, and by several case studies that illustrate its use in a number of different real-world applications in Sect. 7. Section 8 analysis the extent to which our candidate general-purpose autonomic framework satisfies the criteria stated at the beginning of the chapter, and suggests ways for extending our current results. 2 Related Work The autonomic infrastructure proposed in [35] is retrofitting autonomic functional- ity onto legacy systems by using sensors to collect resource data, gauges to inter- pret these data and controllers to decide the “adaptations” to be enforced on the managed systems through effectors. This infrastructure was successfully used to monitor, analyse and control legacy systems in applications such as spam detection, instant messaging quality-of-service management and load balancing for geograph- ical information systems [19]. Our framework is building on the powerful approach in [19, 35], and has the added capability to handle heterogeneous types of resources unknown until runtime, and to support the development of autonomic systems of systems through the use of resource-definition policies. In [20], the authors define an autonomic architecture meta-model that extends IBM’s autonomic computing blueprint [16], and use a model-driven process to partly automate the generation of instances of this meta-model. Each instance is a special-purpose organic computing system that can handle the use cases defined by the model used for its generation. Our general-purpose autonomic architecture eliminates the need for the 19-activity generation process described in [20] by using
- 22. 6 R. Calinescu a universal policy engine that can be dynamically redeployed to handle any use cases encoded within its resource model and policy set. Several research projects propose the use of model-driven architecture (MDA) techniques to develop autonomic computing policies and self-managing systems starting from high-level behavioural models of the system or of its components [10, 36, 39]. Two of these approaches [10, 36] are targeted at bespoke systems whose components already exhibit sophisticated autonomic behaviour, and thus cannot be readily extended to handle generic legacy resources. In contrast, our framework can accommodate any type of ICT resource whose characteristics can be mod- elled as described in Sect. 6. The preliminary work described in [39] is closer to our approach in that it advocates the importance of using MDA techniques in the development of generic self-managing systems; however, the authors do not sub- stantiate their proposal with any concrete solution, but rather qualify it as an open challenge. A number of other projects have investigated isolated aspects related to the devel- opment of autonomic systems out of non-autonomic components. Some of these projects addressed the standardisation of the policy information model, with the Policy Core Information Model [30] representing the most prominent outcome of this work. Recent efforts such as Oasis’ Web Services Distributed Management (WSDM) project were directed at the standardisation of the interfaces through which the manageability of a resource is made available to other applications [32]. An integrated development environment for the implementation of WSDM- compliant interfaces is currently available from IBM [17]. In [12], the authors take a view similar to ours by introducing a paradigm termed model-driven autonomic computing, and explaining that the model-based validation of self-management decisions represents a more reliable and flexible approach than the use of pre-set policies. A powerful hierarchical model of NASA’s Autonomous Nano-Technology Swarm missions is successfully used in [12] to achieve the self- managing functionality that these missions depend on, and thus to illustrate the ben- efits of the approach. Our work complements the results in [12] with a new model- based approach to developing self-management functionality and a generic method that uses existing tools and standards for the implementation of autonomic systems. Finally, we build on recent advances in component-based programming, by using an approach to ICT resource composition and dynamic configuration that resembles the one supported by reflective component models such as Fractal [3]. In addi- tional to the Fractal functionality, our framework automates the generation of most component interfaces and the management of the targeted system. 3 General-Purpose Autonomic Architecture Figure 1 depicts our general-purpose autonomic architecture, a preliminary version of which was introduced in [5, 6]. The core component of the architecture is a universal policy engine that organises a heterogeneous collection of legacy ICT resources and autonomic-enabled resources into a self-managing system. To reduce
- 23. General-Purpose Autonomic Computing 7 Fig. 1 UML component diagram of the autonomic architecture. The architecture supports the development of two types of autonomic systems-of-systems: a hierarchical topology that allows an instance of the policy engine to manage other instances of the architecture (i.e., the managed resources n+1 to n+m in the diagram); and a federation of collaborating instances of the archi- tecture that use each others’ high-level sensors and effectors, as shown by the dashed lines in the diagram the effort required to develop autonomic solutions, the policy engine can handle resources whose types are unknown during its implementation and deployment. This unique capability is achieved through runtime configuration: a model of the system to be managed is supplied to the policy engine for this purpose. As a result, the engine can implement the high-level goals described by a set of user-specified policies that make reference to the resources defined in the system model. As recommended by IBM’s architectural blueprint for autonomic computing [16], standardised adaptors are used to expose the manageability of all types of legacy ICT resources in a uniform way, through sensor and effector interfaces. The autonomic-enabled resources in the self-managing system are either typical ICT resources designed to expose sensor and effector interfaces allowing their direct inter-operation with the policy engine, or other instances of the architecture. The latter option is possible because the policy engine exposes the entire system as an atomic ICT resource through high-level sensors and high-level effectors. A detailed description of the architecture and an overview of existing standards and technolo- gies that can be used to implement it in practice are available in [5, 6].
- 24. 8 R. Calinescu 4 Reconfigurable Policy Engine The internal architecture of our policy engine (Fig. 2) is influenced by the types of policies it implements and by its ability to handle resources whose characteristics are supplied to the engine at runtime. A “coordinator” module is employing the following components to implement the closed control loop of an autonomic system: • The runtime code generator produces the necessary interfaces when the policy engine is configured to manage new types of resources or supplied with new resource-definition policies. When a new system model is used to configure the policy engine, manageability adaptor proxies are generated that allow the engine to interoperate with the manageability adaptors for the resource types specified in the system model. Likewise, when resource-definition policies are set up that specify new ways in which the policy engine should expose the ICT resources it manages, high-level manageability adaptors are generated. • The manageability adaptor proxies are thin interfaces allowing the policy engine to communicate with the autonomic-enabled resources and the manageability adaptors for the legacy resources in the system. • The high-level manageability adaptors expose the system state and configura- tion in a format that allows its integration within other instances of the architec- ture. The way in which these interfaces are dynamically specified by means of resource-definition policies is described later in the chapter. Fig. 2 Architecture of the reconfigurable policy engine. The shaded components are implemented by the prototype described in Sect. 5. A standards-based database driver will be added in a future version of the prototype. The machine learning modules represent the focus of ongoing research efforts by the autonomic computing community, and will be included in a reference implementation of the engine when the results of this research start to crystallise
- 25. General-Purpose Autonomic Computing 9 • The scheduler is used to support the scheduling operators appearing in policy actions for the goal and utility-function policies handled by the policy engine. • The resource discovery component is used to locate the resources to be managed by the policy engine. • The database driver is used to maintain policy engine data such as historical resource property values in an external persistent storage. • The machine learning modules use machine learning techniques [2] to derive and/or refine a behavioural model of the managed resources based on sensor data and inside policy engine information. This enables the engine to support goal and utility-function policies for systems for which in-depth knowledge about the behavioural characteristics of the managed resources cannot be supplied by system administrator. The usefulness of a Modeler component for the implemen- tation of utility-function policies is mentioned in [44], although the authors are not specific about the learning algorithms that such a component might use. • The probabilistic model checker enables the policy engine to take full advantage of the behavioural model supplied by the system administrator or built by its machine learning modules. This is done by using probabilistic model checking to establish quantitative properties of the system [24] and thus to implement the user-specified policies. As will be illustrated by a couple of the case studies in Sect. 7, the integration of these quantitative verification techniques into the policy engine enables system administrators to specify powerful goal and utility- function policies that would have been extremely complicated or even impossible to express otherwise. Another use envisaged for the model checker is to help verify the policies implemented by the engine as suggested in [22]. 5 Prototype Implementation In this section we overview a prototype implementation of our autonomic architec- ture that was originally introduced in [7], and we describe for the first time two of its new features: the integration of a probabilistic model checker with the policy engine and the implementation of resource-definition policies. Two major choices influence the realisation of an instance of the architecture: the technology used to represent the system model and the technology chosen for the implementation of the policy engine components. We chose to represent system models as plain XML documents that are instances of a pre-defined meta-model encoded as an XML schema. This choice was motivated by the availability of numerous off-the-shelf tools for the manipulation of XML documents and XML schemas that are largely lacking for the other technologies we considered (e.g., [1, 29, 32]). In particular, by using existing XSLT engines and XML-based code generators, we shortened the prototype development time and avoided the need to implement bespoke components for this functionality. As shown in Fig. 3, an ICT system is a named set of resources (resource in the UML diagram), each comprising a unique identifier ID and a set of resource
- 26. 10 R. Calinescu Fig. 3 Meta-model of an ICT system properties with their characteristics. A resource property is associated a unique ID, and has a data type (i.e., propertyDataType). Several other property characteristics are defined in the meta-model: • mutability – the WS-RMD MutabilityType [33] specifies if the property is “con- stant”, “mutable” or “appendable”; • modifiability – tells if the property is “read-only”, “read–write”, “write-only” or “derived” from other properties and the behavioural model of the system; • subscribeability – specifies whether a client such as the policy engine can sub- scribe to receive notifications when the value of this property changes; • primaryKey – indicates whether the property is part of the property set used to identify a resource instance among all resource instances of the same type. Our prototype policy engine and the manageability adaptors enabling its interopera- tion with legacy resources were implemented as web services in order to leverage the platform independence, loose coupling and security features of this technology [46]. The runtime configuration of the engine required the extensive use of techniques available only in an object-oriented environment, e.g., runtime generation of data types and manageability adaptor proxies, reflection and generics. Based on these requirements, J2EE and .NET were selected as candidate development platforms for the prototype engine, with .NET being eventually preferred due to its better handling of dynamic proxy generation and slightly easier-to-use implementation of reflection. The components included in the prototype are shown in Fig. 2. The free, open-source probabilistic model checker PRISM [14] developed by the Quantitative Analysis and Verification Group at the University of Oxford was chosen for integration with the original version of the policy engine described in [7]. This choice was based on an extensive performance analysis of a range of model checkers [18] that ranked PRISM as the best option for analysing large behavioural models such as the ones encountered in autonomic computing systems. Further- more, PRISM comes with a command-line interface that made possible its direct integration into the existing version of the policy engine, and the runtime execution of quantitative analysis experiments [23, 24] that self-managing systems can use to realise powerful goal and utility-function policies as illustrated in Sects. 7.3 and 7.4.
- 27. General-Purpose Autonomic Computing 11 Another novel feature of the policy engine that we describe for the first time is its ability to handle resource-definition policies, i.e., policies of the form RESDEF(newResourceId, propertyDef1, . . . , propertyDefm), (1) where newResourceId is a string corresponding to the ID element of a resource definition from the meta-model in Fig. 3 and propertyDefi = (propertyIdi, expri, subscribeabilityi, primaryKeyi), 1≤ i≤ m (2) define the properties of the new resource type. The expri component in (2) tells the policy engine how to calculate the value of the ith resource property as a function of the resources in the policy scope, or is one of INTEGER, DOUBLE or STRING to indicate that property i is a “read–write” property with one of these primitive types. The other components of propertyDefi correspond to the property charac- teristics from the system meta-model in Fig. 3 that cannot be inferred from expri. To implement a resource-definition policy, the policy engine generates dynamically the data type for the new resource and its manageability adaptor (i.e., a new web service whose URL is built by replacing the suffix PolicyEngine.asmx from the policy engine URL with newResourceIdManageabilityAdaptor.asmx). This manageability adaptor exposes objects of the new data type that are created and whose fields are set in accordance with the property definitions (2). The case study presented in Sect. 7.5 illustrates the use of resource-definition policies. 6 A Generic Method for the Development of Autonomic Systems Our method for the development of autonomic systems comprises four steps: 1. development of a model of the system to which autonomic capabilities are added; 2. generation of manageability adaptors for the legacy resources in the system; 3. reconfiguration of the policy engine by means of the system model from step 1; 4. development of autonomic computing policies that handle the required use cases. To illustrate these steps, we will apply them to a system comprising a set of services of different priorities, subjected to different workloads, and sharing the CPU capac- ity of the same server. The aim of the case study is to develop an autonomic solution for managing the allocation of CPU to services such that high-priority services are treated preferentially, subject to each service getting a minimum amount of CPU. Several policy types are typically used in autonomic systems [44, 45]: action policies provide a low-level specification of how the system configuration should be changed to match its state; goal policies specify precise constraints that should be met by varying the system configuration and utility-function policies supply a “measure of success” that the self-managing system should optimise by appropri- ately varying its configuration. In our running example we will use a utility-function policy, which is the most flexible of these policy types.
- 28. 12 R. Calinescu To implement utility-function policies, the policy engine needs an understanding of the behaviour of the system and its resources. Given a resource, we define its state s as the vector whose elements are the read-only properties of the resource, and its configuration c as the vector comprising its modifiable (i.e., read–write) properties. Let S and C be the value domains for s and c, respectively.2 A behavioural model of the resource is a function behaviouralModel : S × C → S, (3) such that for any current resource state s ∈ S and for any resource configuration c ∈ C, behaviouralModel(s, c) represents the future state of the resource if its con- figuration is set to c. Our policy engine works both with an approximation of the behavioural model that consists of a set of discrete values of the behaviouralModel in (3) and with a continuous-time Markov chain (CTMC) [23] representation of (3). For our run- ning example, we will use the former type of behavioural model; the use of CTMC behavioural models is described in Sect. 7. As the current version of the policy engine does not include the machine learning modules described in Sect. 4, it acquires these behavioural models from the manageability adaptors for the managed resources. With the future addition of machine learning modules (Fig. 2), the pol- icy engine will gain the ability to use learning techniques to refine and, eventually, to derive these behavioural models automatically based on its observation of the managed resources. Step 1: Model Development Let System be the set of all instances of the meta- model in Fig. 3; the purpose of this step is to find a system model M ∈ System (4) that can be used to implement the desired autonomic solution. To achieve this goal, we identify the system resources involved in the autonomic solution and their rel- evant properties. Given the ability to reconfigure the policy engine at any time, it makes sense to keep this model as simple as possible: additional resources and/or resource properties can be specified in new versions of the model, and conveyed to the policy engine as and when necessary. For instance, the single resource type for our example system is service, and its properties are as follows: name, a unique identifier used to distinguish between different services; priority, an integer value; cpuAllocation, the percentage of the server CPU allocated to the service; responseTime, the service response time, averaged over the past one-second time interval; interArrivalTime, the request inter-arrival time, averaged over the past one-second time interval and behaviouralModel, an approximation of the service behaviour that provides information on how the service response time varies with its CPU allocation and the request inter-arrival time. 2 Note that S and C are fully specified in the system model.
- 29. General-Purpose Autonomic Computing 13 Each resource property is then analysed in order to identify its value domain, mutability, modifiability and all of the other characteristics specified by the meta- model in Fig. 3. This information is encoded as an instance of the system meta- model, ready to be used in the subsequent steps of the method. By analysing these resource properties for our running example and representing the analysis results as an instance of the system meta-model, we produced with the system model in Fig. 4. Step 2: Manageability Adaptor Generation Given a system model M, this step generates manageability adaptors for each type of legacy resource. Off-the-shelf tools can be used to automate most of this generation. First, an XSLT transformation schemaGen : System → XmlSchema (5) is applied to the system model in order to obtain an XML schema for the resource types in the system. The XML schema generated when this transformation is applied to our sample system model is depicted as UML in Fig. 5a. A standard data type system xmlns=“...” nameserver/name !-- Services running within a server -- resource IDservice/ID property IDname/ID propertyDataType xs:simpleType name=“serviceName” xs:restriction base=“xs:string”/ /xs:simpleType /propertyDataType mutabilityconstant/mutability modifiabilityread-only/modifiability subscribeabilityfalse/subscribeability primaryKeytrue/primaryKey /property property IDpriority/ID . . . /property property IDcpuAllocation/ID propertyDataType xs:simpleType name=“serviceCpuAllocation” xs:restriction base=“xs:int” xs:minInclusive value=“0”/ xs:maxInclusive value=“100”/ /xs:restriction /xs:simpleType /propertyDataType mutabilitymutable/mutability modifiabilityread-write/modifiability subscribeabilityfalse/subscribeability primaryKeyfalse/primaryKey /property property IDresponseTime/ID . . . /property property IDinterArrivalTime/ID . . . /property property IDbehaviouralModel/ID propertyDataType xs:complexType name=“serviceBehaviouralModel” xs:sequence xs:element name=“modelElement” type=“serviceModelElement” maxOccurs=“unbounded”/ /xs:sequence /xs:complexType xs:complexType name=“serviceModelElement” xs:sequence xs:element name=“responseTime” type=“serviceResponseTime”/ xs:element name=“interArrivalTime” type=“serviceInterArrivalTime”/ xs:element name=“cpuAllocation” type=“serviceCpuAllocation”/ /xs:sequence /xs:complexType /propertyDataType mutabilityconstant/mutability modifiabilityread-only/modifiability subscribeabilityfalse/subscribeability primaryKeyfalse/primaryKey /property /resource /system Fig. 4 System model for the running example
- 30. 14 R. Calinescu Fig. 5 Generated XML schema (a) and manageability adaptor (b) for the sample system generator such as Microsoft’s XML Schema Definition tool [28] is then used to automatically generate the data type set associated with this schema: dataTypeGen : XmlSchema → P DataType. (6)
- 31. General-Purpose Autonomic Computing 15 Finally, a simple transformation was implemented to automate the generation of manageability adaptor stubs for the legacy resources in the system: adaptorGen : XmlSchema → P ManageabilityAdaptor. (7) As shown in Fig. 5b, which depicts the data type (i.e., service) and the manage- ability adaptor (i.e., ServiceManageabilityAdaptor) for the system in our run- ning example, all manageability adaptors are subclassing the generic abstract web service ManagedResourceT. The bulk of the sensor and effector functionality associated with a manageability adaptor is implemented in this base abstract class, and only a small number of simple, resource-specific methods that are declared abstract in ManagedResourceT need to be implemented manually in each man- ageability adaptor. Note that the policy engine is itself implemented as a subclass of ManagedResourceT, so that an instance of the architecture can be readily included as a managed resource into a larger autonomic system as described in Sect. 3. To complete this step, the manageability adaptor produced by the generator in (7) and depicted in Fig. 5b was manually extended, and then connected to a server discrete-event simulator running a high-priority “premium” service and a low-priority “standard” service. These services handled simulated requests with normally distributed CPU utilisation and exponentially distributed inter-arrival time. Step 3: Engine Configuration This step consists in supplying the system model to the instance of the policy engine used in the autonomic solution. As stated before, the policy engine was realised as a web service, so we implemented a web interface for its simple configuration. Figure 6 shows a snapshot of this interface after the Fig. 6 Policy engine configuration
- 32. 16 R. Calinescu system model from our running example, and the utility-function policy that will be presented in step 4 were supplied to the engine. Step 4: Policy Development In this step, autonomic computing policies are designed that support the use cases of the envisaged autonomic solution. The scope, priority, condition and action components of these policies make reference to the resources and resource properties defined in the system model used to configure the policy engine. Each of these policy components can be specified using a rich set of operators and functions [6] that allow the definition of action, goal, utility-function and, in the latest version of the engine, of resource-definition policies. The policy set is applied to all resources whose locations are known to the policy engine,3 and which are in the scope of the policies. Policy development is generally a complex, error-prone and iterative process [4], and our framework improves the effectiveness of this process significantly by (a) enabling and encouraging the reuse of system models and policies and (b) simplifying the iterative development and testing of policies for new types of resources and of policies that explore the use of new properties of existing resources in novel ways. For our autonomic solution, we defined a utility function that models the business gain associated with running a set of service resources R with different levels of service: utility(R) = r∈R r.priority ∗ min(1000, max(0, 2000 − r.responseTime)). Figure 7a depicts the utility function for a server running a “premium” service with priority 100 and a “standard” service with priority 10. The policy action implemented by the autonomic system (Fig. 6 and Table 1) was defined by means of the MAXIMISE(R, utility, property, capacity, min, max, model) operator that uses the information about the system behaviour encoded in model to set the value of the specified resource property for all resources in R such as to: (a) maximise the value of the utility function and (b) ensure that the value of property stays between min and max, and that the sum of the property values across all resources in R does not exceed the available capacity. This policy provides the definition of the utility function, and the link between the responseTime, interArrivalTime and cpuAllocation properties of a service resource and the components of its behaviouralModel property. Each time it evaluates the utility-function policy, the policy engine uses this infor- mation to select the elements from the behavioural model that are in the proximity of the current state of the system; the Euclidean metric is used for this calculation. The new configuration for the system is then chosen as the one associated with the selected element that maximises the value of the utility function. The experimental results of applying this policy to our example system are presented in Sect. 7.1. 3 The policy engine employs a resource discovery service (Fig. 2) to obtain the URLs of the resources to be managed.
- 33. General-Purpose Autonomic Computing 17 Fig. 7 Utility function (a) and service behavioural model (b) for the running example Table 1 The arguments of the MAXIMISE(R, utility, property, capacity, min, max, model) policy action for the running example of an autonomic system R service utility SUM(service.priority ∗ MIN(1000, MAX(0, 2000 − service.responseTime))) property service.cpuAllocation capacity 100 min 15 max 100 model service.responseTime(service.interArrivalTime, service.cpuAllocation) = service.behaviouralModel.responseTime(service.behaviouralModel. interArrivalTime, service.behaviouralModel.cpuAllocation)
- 34. 18 R. Calinescu 7 Case Studies 7.1 Utility-Driven Allocation of CPU Capacity We start our presentation of case studies with the experimental results for the run- ning example of an autonomic system from the previous section. Variants of this system were used to validate autonomic computing frameworks in the past (e.g., [44]), hence this well-understood use case provides a good basis for a first assess- ment of the framework. To evaluate our autonomic solution, the behavioural model for a service was obtained from 100 runs of the server simulator in which the average service response time was recorded for 920 equidistant points covering the entire (interArrivalTime, cpuAllocation) value domain (Fig. 7b). Figure 8 shows a typical experiment in which the utility-function policy in Table 1 was used to manage the allocation of CPU to our “premium” and “standard” ser- vices, when their request inter-arrival times were varied to simulate different work- loads. The policy evaluation period was set to 3 s for this experiment, so that the system could self-adapt to the rapid variation in the workload of the two services. This allowed us to measure the CPU overhead of the policy engine, which was under 1% with the engine service running on a 1.8 GHz Windows XP machine. In a real scenario, such variations in the request inter-arrival time are likely to happen over longer intervals of time, and the system would successfully self-optimise with far less frequent policy evaluations. 7.2 Goal-Based Scheduling of CPU Capacity In the absence of knowledge about the behaviour of the legacy ICT resources that need to be organised into a self-managing system, goal policies can often be used in conjunction with scheduling heuristics. In this section, we consider the same system as in Sect. 7.1, but assume that a behavioural model describing the variation of the service response time with its allocated CPU and request inter-arrival rate is not available. Figure 9 depicts a concise representation of the system model and a goal policy that can be used in this scenario. The action of this goal policy is specified by means of an expression that uses the SCHEDULE(R, ordering, property, capacity, min, max, optimal) operator that (a) sorts the resources in R in non-increasing order of the comparable expressions in ordering; (b) in the sorted order, sets the specified resource property to a value never smaller than min or larger than max, and as close to optimal as possible; and (c) ensures that the overall sum of all property values does not exceed the available capacity. Accordingly, the policy action in Fig. 9 will set the cpuAllocation property of all services to a value between 15 and 100%, sub- ject to the overall CPU allocation staying within the 100% available capacity. Opti- mally, the cpuAllocation should be left unchanged if the 55 ≤ cpuUtilisation ≤ 85,
- 35. General-Purpose Autonomic Computing 19 Fig. 8 Experimental results for Sect. 7.1. The CPU allocations for the services are initially decreased to match their light workload (5 ms request inter-arrival time during time interval a). As the service workloads increase, so do the CPU allocations, until the CPU required to satisfy the demand from the premium service leaves insufficient CPU capacity for the standard service to make any contribution to the utility function (time interval d), hence it is allocated the minimum amount of CPU specified in the policy (i.e., 15%). As soon as less CPU capacity is required to satisfy the needs of the premium service (time interval e), the standard service is swiftly allocated sufficient CPU to bring it back into a region of operation in which it contributes to the utility function. Subsequently, the CPU allocations are varied to accommodate more gradual changes in the workloads (time intervals f–g) decrease by 5% if cpuUtilisation 55 and increase by 5% if cpuUtilisation 85.4 The experimental results for the resulting autonomic solution (available in [7]) resemble those corresponding to the use of a utility-function policy in Sect. 7.1, but are less effective in two important circumstances: 4 The HYSTERESIS(val, lower, upper) operator used to achieve this behaviour (Fig. 9) returns −1, 0 or 1 if val lower, lower ≤ val ≤ upper or upper val, respectively.
- 36. 20 R. Calinescu Fig. 9 Policy engine parameters for the case study in Sect. 7.2. The policy engine is configured to monitor the service cpuUtilisation (i.e., the amount of CPU utilised by the service, expressed as a percentage of its CPU allocation) and to realise a goal policy requiring that the cpuUtilisation is maintained between 55 and 80% of the allocated CPU • several successive policy evaluations are required to handle significant changes in the service workloads because the CPU capacity allocated to services can be modified by only ±5% at a time; • when insufficient CPU is available to ensure that a low-priority service runs in an operation area that is useful for the business and the utility-function policy in Sect. 7.1 would restrict the CPU allocated to the service to a minimum, the goal policy gives it all available CPU, thus wasting CPU capacity unnecessarily. 7.3 Dynamic Power Management of Disk Drives When formal methods are used in the development and/or verification of legacy ICT resources, the behavioural models employed by these methods can often be exploited by our framework to augment the legacy ICT resources with autonomic capabilities. Starting from the CTMC model of a Fujitsu disk drive in [38] and its encoding as a PRISM CTMC model [37], we built (Fig. 10) a system model of the disk drive that can be used for the configuration of our policy engine. We then used this system model to add self-optimisation capabilities to the disk drive so that it dynamically adapted its probability of transitioning from the idle state to the low-power sleep state to changes in (a) the request inter-arrival time and (b) the user-specified utility function: utility = w1 min 1, max 0, 11 − queueLength) 2 + w2 max(0, 1.2 − power), (8)
- 37. General-Purpose Autonomic Computing 21 Fig. 10 PRISM CTMC model of a three-state Fujitsu disk drive taken from [37], and used to devise the system model for the configuration of the policy engine. The uninitialised PRISM constants correspond to “read-only” and “read–write” properties of a disk drive resource (i.e., interArrivalTime and switchToSleepProbability, respectively). PRISM reward structures (i.e., power and queueLength) correspond to “derived” disk drive properties where the weights w1 and w2 are chosen depending on the circumstances in which the disk drive is used (Fig. 11). Given this policy, the policy engine ran PRISM experiments [24] to establish the optimal switchToSleepProbability for the disk drive at regular, 10-s time intervals. For our simple CTMC model, each of these experiments took subsecond time, yielding the results in Fig. 12. 7.4 Adaptive Control of Cluster Availability The case study presented in this section involves the adaptive control of cluster availability within a data centre. The aim of the autonomic solution is to control the number of servers allocated to the N ≥ 1 clusters of a data centre in order to maximise the utility function
- 38. 22 R. Calinescu Fig. 11 The utility function (8) (depicted here for w1 = w2 = 100) was used to achieve a user- customisable trade-off between the disk drive responsiveness (which is provably proportional to its average queueLength [38]) and its power consumption (i.e., power) utility = N i=1 priorityi ·GOAL(availabilityi ≥ target availabilityi)−ε N i=1 serversi (9) subject to N i=1 serversi ≤ Total servers and requiredi ≤ serversi, (10) where priorityi 0, availabilityi ∈ [0, 1], target availabilityi ∈ [0, 1], requiredi ≥ 1 and serversi ≥ 1 represent the priority, (actual) availability, target availability, number of required servers and number of (allocated) servers for cluster i, 1 ≤ i ≤ N, respectively. The GOAL operator yields 1 when its argument is true and 0 otherwise, Total servers ≥ 1 is the total number of servers in the data centre, and 0 ε 1 is a constant.5 The availability of cluster i, availabilityi, is the fraction of a 1-year time period during which at least requiredi servers are usable (i.e., they are operational and connected to an operational switch and backbone). Like in the previous case study, we extracted the system model for the configu- ration of our policy engine from an existing behavioural model of the targeted ICT resource, namely from the CTMC model of a dependable cluster of workstations introduced in [11]. This model takes into account the failure and repair rates of all components from our targeted cluster architecture (Fig. 13a). Consequently, the policy engine can use PRISM to calculate the cluster availabilities for the data-centre configurations satisfying (10), and to decide the number of servers that each cluster 5 The second term of the utility function (9) ensures that when multiple configurations maximise the first term, the configuration that uses the fewest servers is preferred.
- 39. General-Purpose Autonomic Computing 23 Fig. 12 Discrete-event simulation results contrasting our autonomic approach to disk drive dynamic power management (DPM) with two standard DPM methods [38]: the timeout method that moves the disk drive into the sleep state after a period of idleness t and “awakens” it immedi- ately after a request has arrived; and the N method that moves the disk drive into the sleep state as soon as it becomes idle, and “awakens” it after N requests accumulate in its queue. The autonomic DPM approach achieved a better utility than the two standard DPM methods for most of the time, and similar utility to the better of the two for the rest of the time. This is due to the good trade-off that the autonomic approach realised between power consumption and request queue length across a wide workload range, while the other approaches are effective for specific workloads should get so that the value of the utility function (9) is maximised. Given the com- plexity of the CTMC behavioural model, we implemented a cluster manageability adaptor that uses notifications to inform the policy engine about changes in the number of required servers for the clusters. Hence, the policy engine recalculates the server allocations only when there is a change in the state of the autonomic system. In our simulations, this calculation took up to 30 s. This response time is acceptable for the considered use case because, based on our previous experience with policy-based data-centre management [4], half a minute represents a small
- 40. 24 R. Calinescu Fig. 13 Architecture of an n-server dependable cluster, taken from [11] (a), and simulation results for a three-cluster data centre over a 4-week time period (b) delay compared to the time required to provision a server when it is allocated to a new cluster.6 The experimental results are shown in Fig. 13b. 7.5 Dynamic Web Content Generation The last case study is extending the autonomic solution from the previous section by incorporating the autonomic system for controlling cluster availability into an autonomic system of systems (Fig. 14). The resource-definition policy action below was supplied to policy engine instances within the autonomic data-centre systems: RESDEF(businessValue, (id, CONCAT(cluster.id), false,true), (max, SUM(cluster.priority),true, false), (actual, SUM(cluster.priority∗ (11) GOAL(cluster.availability = cluster.targetAvailability)),true, false)). 6 Section 8 suggests techniques for working around the time taken by runtime model checking when such delays are not acceptable.
- 41. General-Purpose Autonomic Computing 25 Fig. 14 Autonomic system of systems comprising several instances of the data-centre system from Sect. 7.4, and an autonomic-enabled web page implementing a business dashboard. The data-centre systems were each configured to expose their actual and ideal utility by means of a resource- definition policy, and the top-level policy engine implements an action policy that updates the properties of the autonomic-enabled web page with a summary of these utilities As described in Sect. 5, this resulted in each of these policy engines dynamically creating a new ICT resource named businessValue and comprising three “read- only” properties: id – the concatenated identifiers of its clusters; max – its ideal utility, i.e., the maximum possible value of the first term in (9); and actual – the actual value of this term. A model of this synthesised ICT resource and of an autonomic-enabled web page was then used to configure the top-level policy engine in Fig. 14, and an action policy was used to ensure that this policy engine updates the web page periodically with a summary based on the businessValue of each autonomic data-centre system it knows about (Fig. 15). 8 Summary and Future Work The success of mainstream computing is largely due to the availability of a system development methodology that enables and encourages standardisation, component reuse and user adoption. Building on recent advances in autonomic computing and on our previous work on policy-based autonomic systems, we proposed a general- purpose framework that brings similar benefits to the realm of autonomic com- puting. We introduced a set of criteria for assessing the generality of autonomic computing frameworks, and a new method for the development of self-managing systems starting from a model of their ICT resources. Also, we presented the inte- gration of a probabilistic model checker into an autonomic computing policy engine, and we described how a new policy type termed a resource-definition policy can be used to build autonomic systems of systems.
- 42. 26 R. Calinescu Fig. 15 An autonomic-enabled web page exposes effectors that the top-level policy engine uses to supply it with summary information about the maximum utility and actual utility of a set of auto- nomic data-centre systems (a single data-centre system was used in the experiment shown here). The web page presents the dynamically acquired information using a graphical representation that is generated at runtime using Matlab. Thus, the information about potential loss of business value is conveyed in a concise format that can be used directly by a data-centre manager To validate our framework, we employed it to build autonomic solutions spawn- ing a range of application domains and using a variety of autonomic computing policies. Table 2 uses these case studies to analyse the extent to which the proposed framework satisfies the generality criteria C1–C3 introduced in Sect. 1: Table 2 Summary of the case studies presented in the paper Sect. 7.1 Self-monitoring Self-optimisation CPU capacity allocation C1 ICT resources S o f t w a r e H a r d w a r e D a t a L e g a c y A u t o n o m i c - e n a b l e d M a i n s e l f - * A c t i o n G o a l U t i l i t y - f u n c t i o n R e s o u r c e - d e f i n i t i o n f u n c t i o n a l a r e a s C2 self-* areas policies C3 application domain CPU capacity allocation Dynamic power management Cluster availability control Dynamic gen. of web content Self-monitoring Self-optimisation Self-monitoring Self-adaptation Self-configuration Self-protection Self-monitoring Self-generation Sect. 7.2 Sect. 7.3 Sect. 7.4 Sect. 7.5
- 43. General-Purpose Autonomic Computing 27 C1 In terms of supported ICT resources, our case studies demonstrate that the framework can handle the whole range of envisaged ICT resources. C2 The framework has been used to develop autonomic solutions in several areas of self-* functionality, and to support all types of autonomic computing policies. To further confirm its generality, new applications are being currently investi- gated that address additional areas of self-* functionality. C3 The autonomic systems developed for the presented case studies cover a range of application domains, including the development of a hierarchical system of systems. This is a good first step towards establishing that the framework sat- isfies this criterion. More work is required to assess the feasibility of using the framework in other use cases, and in particular in the development of federations of collaborating autonomic systems with no centralised management. Based on past experience in using a domain-specific autonomic framework [4] to develop systems similar to those in Sects. 7.1 and 7.2, we estimate that the use of the generic framework to build these systems reduced the development effort by roughly an order of magnitude, and we expect the same to hold true for other applications. Fig. 16 Proposed autonomic system development methodology. The autonomic architecture, pol- icy engine and system meta-model described in this paper are used at the domain-independent level, alongside a proposed ICT ontology and a proposed tool for designing the meta-model instances used to configure the policy engine. Repositories of ICT resource definitions and auto- nomic policies, and domain-specific ICT ontologies should be available at the level of an appli- cation domain, while our generic method for autonomic system development is employed for the cost-effective development of autonomic systems at the application-specific level
- 44. 28 R. Calinescu A key feature of our autonomic computing framework is its use of runtime prob- abilistic model checking. As shown in Sect. 7.4, model checking large systems can incur significant overheads, and the use of the subscription-notification mechanism supported by the framework (instead of periodical policy evaluation) is one way to accommodate this constraint. Other approaches to be investigated include the use of caching and pre-evaluation techniques to bypass the model checking step during policy evaluation, and the use of a hybrid approach in which a smaller model checking experiment is carried out to produce a close-to-optimal configuration for the autonomic system and a faster technique is then used to refine this configuration. In addition to reusing components and techniques across a broad range of appli- cations, our approach to autonomic system development allows and encourages the reuse of system models and autonomic computing policies. To take reusability fur- ther, these models and policies should draw their elements from domain-specific repositories of resource definitions and autonomic computing policies, respectively. Furthermore, to maximise the sharing of models, policies, manageability adaptors and autonomic-enabled resources, these repositories need to be built around con- trolled ICT ontologies, as required by the methodology for the cost-effective devel- opment of autonomic systems that we are proposing in Fig. 16. This methodology that we are working towards is in line with the excellent principles stated in [43] and successfully applied in the context of autonomic networking by Strassner et al. [42]. Acknowledgments The work presented in this chapter was partly supported by the UK Engineer- ing and Physical Sciences Research Council grant EP/F001096/1. The author is grateful to Marta Kwiatkowska, David Parker, Gethin Norman and Mark Kattenbelt for insightful discussions during the integration of the PRISM probabilistic model checker with the autonomic policy engine. References 1. J. Arwe et al. Service Modeling Language, version 1.0, March 2007. http://www.w3.org/ Submission/2007/SUBM-sml-20070321. 2. C. M. Bishop. Pattern Recognition and Machine Learning. Springer, 2007. 3. E. Bruneton et al. The Fractal component model and its support in Java. Softw. Pract. Exper., 36:1257–1284, 2006. 4. R. Calinescu. Challenges and best practices in policy-based autonomic architectures. In Proc. 3rd IEEE Intl. Symp. Dependable, Autonomic and Secure Computing, pages 65–74, 2007. 5. R. Calinescu. Model-driven autonomic architecture. In Proc. 4th IEEE Intl. Conf. Autonomic Computing, June 2007. 6. R. Calinescu. Towards a generic autonomic architecture for legacy resource management. In K. Elleithy, editor, Innovations and Advanced Techniques in Systems, Computing Sciences and Software Engineering, pages 410–415, Springer, 2008. 7. R. Calinescu. Implementation of a generic autonomic framework. In D. Greenwood et al., editor, Proc. 4th Intl. Conf. Autonomic and Autonomous Systems, pages 124–129, March 2008. 8. M. Devarakonda et al. Policy-based autonomic storage allocation. In Self-Managing Dis- tributed Systems, volume 2867 of LNCS, pages 143–154. Springer, 2004. 9. S. Dobson et al. A survey of autonomic communications. ACM Transactions on Autonomous and Adaptive Systems, 1(2):223–259, December 2006.
- 45. General-Purpose Autonomic Computing 29 10. D. Gracanin et al. Towards a model-driven architecture for autonomic systems. In Proc. 11th IEEE Intl. Conf. Engineering of Computer-Based Systems, pages 500–505, 2004. 11. B. Haverkort et al. On the use of model checking techniques for dependability evaluation. In Proc. 19th IEEE Symp. Reliable Distributed Systems, pages 228–237, October 2000. 12. M. Hinchey et al. Modeling for NASA autonomous nano-technology swarm missions and model-driven autonomic computing. In Proc. 21st Intl. Conf. Advanced Networking and Applications, pages 250–257, 2007. 13. M.G. Hinchey and R. Sterritt. Self-managing software. Computer, 39(2):107–109, Feb. 2006. 14. A. Hinton et al. PRISM: A tool for automatic verification of probabilistic systems. In H. Hermanns and J. Palsberg, editors, Proc. 12th Intl. Conf. Tools and Algorithms for the Construction and Analysis of Systems, volume 3920 of LNCS, pages 441–444. Springer, 2006. 15. IBM Corporation. Autonomic computing: IBM’s perspective on the state of information tech- nology, October 2001. 16. IBM Corporation. An architectural blueprint for autonomic computing, 2004. http://www- 03.ibm.com/autonomic/pdfs/ACBP2 2004-10-04.pdf. 17. IBM Corporation. Autonomic integrated development environment, April 2006. http://www.alphaworks.ibm.com/ tech/aide. 18. D.N. Jansen et al. How fast and fat is your probabilistic model checker? An experimental comparison. In K. Yorav, editor, Hardware and Software: Verification and Testing, volume 4489 of LNCS, pages 69–85. Springer, 2008. 19. G. Kaiser et al. Kinesthetics extreme: An external infrastructure for monitoring distributed legacy systems. In Proc. of the 5th Annual Intl. Active Middleware Workshop, June 2003. 20. H. Kasinger and B. Bauer. Towards a model-driven software engineering methodology for organic computing systems. In Proc. 4th Intl. Conf. Comput. Intel., pages 141–146, 2005. 21. J.O. Kephart and D.M. Chess. The vision of autonomic computing. IEEE Computer Journal, 36(1):41–50, January 2003. 22. S. Kikuchi et al. Policy verification and validation framework based on model checking approach. In Proc. 4th IEEE Intl. Conf. Autonomic Computing, June 2007. 23. M. Kwiatkowska. Quantitative verification: Models, techniques and tools. In Proc. 6th Joint Meeting of the European Software Engineering Conf. and the ACM SIGSOFT Symp. Founda- tions of Software Engineering, pages 449–458. ACM Press, September 2007. 24. M. Kwiatkowska et al. Stochastic model checking. In M. Bernardo and J. Hillston, editors, Formal Methods for the Design of Computer, Communication and Software Systems: Perfor- mance Evaluation (SFM’07), volume 4486 of LNCS, pages 220–270. Springer, 2007. 25. C. Lefurgy et al. Server-level power control. In Proc. 4th IEEE Intl. Conf. Autonomic Com- puting, June 2007. 26. T. Lenard and D. Britton. The Digital Economy Factbook. The Progress and Freedom Foun- dation, 2006. 27. Wen-Syan Li et al. Load balancing for multi-tiered database systems through autonomic placement of materialized views. In Proc. 22nd IEEE Intl. Conf. Data Engineering, April 2006. 28. Microsoft Corporation. Xml schema definition tool (xsd.exe), 2007. http:// msdn2.microsoft.com/en-us/library/x6c1kb0s(VS.80).aspx. 29. Microsoft Corporation. System Definition Model overview, April 2004. http://download.microsoft.com/download/b/3/8/b38239c7-2766-4632-9b13- 33cf08fad522/sdmwp.doc. 30. B. Moore. Policy Core Information Model (PCIM) extensions, January 2003. IETF RFC 3460, http://www.ietf.org/rfc/rfc3460.txt. 31. R. Murch. Autonomic Computing. IBM Press, 2004. 32. B. Murray et al. Web Services Distributed Management: MUWS primer, February 2006. OASIS WSDM Committee Draft, http://www.oasis-open.org/committees/download.php/ 17000/wsdm-1.0-muws-primer-cd-01.doc. 33. OASIS. Web Services Resource Metadata 1.0, November 2006.
- 46. 30 R. Calinescu 34. M. Parashar and S. Hariri. Autonomic Computing: Concepts, Infrastructure Applications. CRC Press, 2006. 35. J. Parekh et al. Retrofitting autonomic capabilities onto legacy systems. Cluster Computing, 9(2):141–159, April 2006. 36. J. Pena et al. A model-driven architecture approach for modeling, specifying and deploying policies in autonomous and autonomic systems. In Proc. 2nd IEEE Intl. Symp. Dependable, Autonomic and Secure Computing, pages 19–30, 2006. 37. PRISM Case Studies: Dynamic Power Management. http://www.prismmodelchecker.org/ casestudies/power.php. 38. Q. Qiu et al. Stochastic modeling of a power-managed system: construction and optimization. In Proc. Intl. Symp. Low Power Electronics and Design, pages 194–199. ACM Press, 1999. 39. M. Rohr et al. Model-driven development of self-managing software systems. In Proc. 9th Intl. Conf. Model-Driven Engineering Languages and Systems. Springer, 2006. 40. R. Sterritt et al. Sustainable and autonomic space exploration missions. In Proc. 2nd IEEE Intl. Conf. Space Mission Challenges for Information Technology, pages 59–66, 2006. 41. R. Sterritt and M.G. Hinchey. Biologically-inspired concepts for self-management of com- plexity. In Proc. 11th IEEE Intl. Conf. Engineering of Complex Computer Systems, pages 163–168, 2006. 42. J. Strassner et al. Providing seamless mobility using the FOCALE autonomic architecture. In Proc. 7th Intl. Conf. Next Generation Teletraffic and Wired/Wireless Advanced Networking, volume 4712 of LNCS, pages 330–341, 2007. 43. J. Strassner et al. Ontologies in the engineering of management and autonomic systems: A reality check. Journal of Network and Systems Management, 15(1):5–11, 2007. 44. W.E. Walsh et al. Utility functions in autonomic systems. In Proc. 1st Intl. Conf. Autonomic Computing, pages 70–77, 2004. 45. S.R. White et al. An architectural approach to autonomic computing. In Proc. 1st IEEE Intl. Conf. Autonomic Computing, IEEE Computer Society, pages 2–9, 2004. 46. O. Zimmermann et al. Perspectives on Web Services: Applying SOAP, WSDL and UDDI to Real-World Projects. Springer, 2005.
- 47. Software Architecture-Based Self-Adaptation David Garlan, Bradley Schmerl, and Shang-Wen Cheng Abstract Increasingly, systems must have the ability to self-adapt to meet changes in their execution environment. Unfortunately, existing solutions require human oversight, or are limited in the kinds of systems and the set of quality-of-service concerns they address. Our approach, embodied in a system called Rainbow, uses software architecture models and architectural styles to overcome existing limi- tations. It provides an engineering approach and a framework of mechanisms to monitor a target system and its environment, reflect observations into a system’s architecture model, detect opportunities for improvement, select a course of action, and effect changes in a closed loop. The framework provides general and reusable infrastructures with well-defined customization points, allowing engineers to sys- tematically customize Rainbow to particular systems and concerns. 1 Introduction Imagine a world where a software engineer could take an existing software sys- tem and specify an objective, conditions for change, and strategies for adaptation to make that system self-adaptive where it was not before. Furthermore, imagine that this could be done in a few weeks of effort and be sensitive to maintaining business goals and other properties of interest. For example, an engineer might take an existing client–server system and make it self-adaptive with respect to a specific performance concern such as high latency. He might specify an objective to maintain request-response latency below some threshold, a condition to change the system if the latency rises above the threshold, and a few strategies to adapt the system to fix the high-latency situation. Another engineer might make a coalition-of-services system self-adaptive to network performance fluctuations, while limiting cost of operating the infrastructure. Still another engineer might make a cluster of servers self-adaptive to certain security attacks. D. Garlan (B) Carnegie Mellon University, 5000 Forbes Ave, Pittsburgh, PA 15213, USA e-mail: garlan@cs.cmu.edu M.K. Denko et al. (eds.), Autonomic Computing and Networking, DOI 10.1007/978-0-387-89828-5 2, C Springer Science+Business Media, LLC 2009 31
- 48. 32 D. Garlan et al. Today, when increasingly systems have the requirement to self-adapt with mini- mal human oversight, it is becoming necessary to meet this vision. Systems must cope with variable resources, system errors, and changing user priorities, while maintaining, as best they can, the goals and properties envisioned by the engineers and expected from the users. Software engineers lack the tools and techniques to engineer a system with self-adaptation. Engineers and researchers alike have responded to and met this self-adaptation need in somewhat limited forms through programming language features such as exceptions and in algorithms such as fault-tolerant protocols. But these mechanisms are often specific to the application, tightly bound to the code, and usually provide only localized treatment of system errors. As a result, self-adaptation for today’s systems are costly to build, often taking many man-months to retrofit systems. In contrast, the vision outlined above requires an approach that makes it pos- sible for engineers to easily define adaptation policies that are global in nature, and that take into consideration business goals and quality attributes. In particular, we require that engineers be able to augment existing systems to be self-adaptive without rewriting them from scratch, that self-adaptation policies and strategies can be reused across similar systems, that multiple sources of adaptation expertise can be synergistically combined, and that all of this can be done in ways that support maintainability, evolution, and analysis. In this chapter, we describe an approach to achieving these goals using architecture-based self-adaptation techniques. In particular, our approach abstracts observed behavior of an executing system into properties of an architectural model, where they can be reasoned about using a variety of existing architectural analysis techniques. The results of these analyses can then be used to reason about changes that should be made to a system to improve or correct the system’s achievement of the quality attributes. Our approach is embodied in a system called Rainbow, which focuses on two challenges to achieve cost-effective self-adaptation: (1) an approach and mecha- nism that reduces engineering effort and (2) representation of adaptation knowl- edge. Rainbow provides an engineering approach and a framework of mechanisms to monitor a system and its executing environment, reflect observations into an architectural model of the system, determine any problem states, select a course of action, and effect changes. By leveraging the notion of architectural style to exploit commonality of systems, the framework provides a general and reusable infrastructure with well-defined customization points to cater to a wide range of systems. The framework also provides a set of abstractions that allow engineers to focus on adaptation concerns, facilitating an adaptation engineering workflow for the systematic customization of Rainbow. To emulate the mundane and rou- tine adaptation tasks performed by system administrators, Rainbow provides a lan- guage, called Stitch, to represent the adaptation techniques using first-class adapta- tion concepts. It offers modularity with respect to quality dimension and domain expertise, strategies with condition and effect, a mechanism to tailor to particu- lar styles, and the use of utility theory to compute the best adaptation path under uncertainty.
- 49. Software Architecture-Based Self-Adaptation 33 In this chapter, we introduce the ideas behind architecture-based self-adapting systems; briefly survey the research landscape; discuss the research and engineer- ing challenges, particularly with respect to autonomic behavior for distributed, net- worked systems; and describe the Rainbow approach and how it addresses these challenges. We also give examples of its use in the context of autonomic networks, focusing on adaptations to improve qualities such as fidelity, performance, security, and cost of operation. 2 Overview of Autonomic and Self-Adaptive Systems Overcoming the challenges of self-adaptation and allowing managed systems to self-adapt with minimal human oversight requires closing the “loop of control.” Software systems have traditionally been designed as open-loop systems: once a system is designed for a certain function and deployed, its extra-functional quality attributes typically remain relatively unchanged. In most cases, if something goes wrong, humans must intervene, often by restarting the failed subsystem or taking the entire system offline for repair. This results in high costs in system downtime, personnel costs, and decreased revenue through system unavailability. To address this problem, a number of researchers have proposed an alternative approach that uses external software mechanisms to maintain a form of closed-loop control over the target system (e.g., [26, 30, 39]). Such mechanisms allow a system to self-adapt dynamically, with reduced human oversight. Minimally, closed-loop control consists of mechanisms that monitor the system, reflect on observations for problems, and control the system to maintain it within acceptable bounds of behav- ior. This kind of system is known as a feedback control system in control theory [42]. Feedback control systems have typically been applied to control physical sys- tems. For simple systems, the control model may be built-in to the design. For example, a home thermostat that measures room temperature and checks it against the set point, controlling a home heating and cooling system, will typically have a simple built-in thermodynamic model. In more complex systems an explicit process model is necessary for effective control [42]. For example, an air conditioning sys- tem for a large building that monitors and controls multiple locations would require an explicit model of the building partitions and temperatures to efficiently control which cooling units to turn on and when. For software systems, the external controller requires an explicit model of the target system in order to reflect on observations and to configure and repair the system [39]. Monitoring mechanisms extract and aggregate target system informa- tion to update the model. An evaluation mechanism detects problems in the target system as reflected in the model. The appearance of a problem triggers an adaptation mechanism to use the model to determine a course of action. The mechanism then propagates the necessary changes to the target system to fix the problem. In principle, external mechanisms have a number of benefits over internal mecha- nisms. External control separates the concerns of system functionality from those of
- 50. 34 D. Garlan et al. adaptation (or “exceptional”) behaviors. With the adaptation mechanism as a sep- arate entity, engineers can more easily modify and extend it, and reason about its adaptation logic. Furthermore, the separation of mechanisms allows the application of this technique even to legacy systems with inaccessible source code, as long as the target system provides, or can be instrumented to provide, hooks to extract system information and to make changes. Finally, providing external control with generic but customizable mechanisms (e.g., model management, problem detection, strategy selection) facilitates reuse across systems, reducing the cost of developing new self-adaptive systems. 2.1 The IBM Autonomic Framework The IBM Autonomic Computing Initiative codified an external, feedback control approach in its Autonomic Monitor-Analyze-Plan-Execute (MAPE) Model [28]. Figure 1 illustrates the MAPE loop, which distinguishes between the autonomic manager (embodied in the large rounded rectangle) and the managed element, which is either an entire system or a component within a larger system. The MAPE loop highlights four essential aspects of self-adaptation: 1. Monitor: The monitoring phase is concerned with extracting information— properties or states—out of the managed element. Mechanisms range from source-code instrumentation to non-intrusive communication interception. 2. Analyze: is concerned with determining if something has gone awry in the sys- tem, usually because a system property exhibits a value outside of expected bounds, or has a degrading trend. 3. Plan: is concerned with determining a course of action to adapt the managed element once a problem is detected. 4. Execute: is concerned with carrying out a chosen course of action and effecting the changes in the system. Fig. 1 The IBM Autonomic MAPE Reference Model
- 51. Software Architecture-Based Self-Adaptation 35 Shared between these four phases is the Knowledge component, which contains models, data, and plans or scripts to enable separation of adaptation responsibilities and coordination of adaptations. The Rainbow framework provides components that fulfill each of these four phases and the knowledge to support self-adaptation. 3 Software Architecture and Architecture-Based Self-Adaptation A key issue in using an external model is to determine the appropriate kind of mod- els to use for software-based systems. Each type of model has certain advantages in terms of the analyses and kinds of adaptation it supports. In principle, a model should be abstract enough to allow straightforward detection of problems in the target system, but should provide enough fidelity to determine remedial actions to take to fix the problem. State machines, queuing theory, graph theory, differential equations, and other mathematical models [40, 42] have all been used for model- based, external adaptation of software systems. We, among others, use a system’s software architecture as the external model for dynamic adaptation [19, 39]. The architecture of a software system is an abstract representation of the system as a composition of computational elements and their interconnections [44]. Specifically, an architecture model represents the system as a graph of interacting components.1 Nodes in the graph, termed components, rep- resent the principal computational elements and data stores of the system: clients, servers, databases, user interfaces, etc. Arcs, termed connectors, represent the path- ways of interaction between the components. This is the core architectural represen- tation scheme adopted by a number of architecture description languages (ADLs), such as Acme [20] and xADL [13]. The use of software architecture as the basis for self-adaptation, termed architecture-based self-adaptation, holds a number of potential promises. A rich body of work on architecture trade-off analysis techniques used at system design time facilitates runtime self-adaptation. As an abstract model, an architecture model provides a global perspective on the system and exposes the important system-level behaviors and properties. As a locus of high-level system design decisions, the model makes system integrity constraints explicit, thereby helping to ensure the validity of a change. For example, the architecture model can expose important properties such as throughput and bandwidth, allowing the overall throughput or performance of the system to be analyzed. Furthermore, the model might be associated with explicit constraints on the architecture that, for example, forbid cycles. This knowledge can be used at runtime to reason about the effect of a change on the system’s throughput or structure. See [18] for a discussion of this concept for performance evaluation. 1 We are primarily interested in the component–connector view [11] because it characterizes the abstract state and behavior of the system at runtime to enable reasoning about problems and courses of adaptation.
- 52. 36 D. Garlan et al. Crucial for architecture-based self-adaptation is the choice of the architectural style used to represent the target system. A style (e.g., pipe-filter) provides the vocabulary to describe the architecture of a system in terms of a set of component types (e.g., filter) and connector types (e.g., pipe), along with the rules for composi- tion (e.g., no cycles) [1]. A style might also prescribe the properties associated with particular element types (e.g., throughput on a pipe). Usually associated with a style is a set of analytical methods to reason about properties of systems in that style. For example, systems in the MetaH style supports real-time schedulability analysis [16]. For self-adaptation, given some quality objectives, each style may guide the choice of system properties to monitor, help identify strategic points for system observation, and suggest possible adaptations. To illustrate this, consider a signal- processing system with an architecture in the pipe-filter style. This style constrains the system to a data-flow computation pattern, points to throughput as a system property, identifies the filter as a strategic point for measuring throughput, and sug- gests throughput analysis for reasoning about overall system throughput. The pipe- filter style may suggest adaptations that swap in variants of filters to adjust through- put, create redundant paths to improve reliability, or add encryption to enhance security. In contrast, consider a different system in the client–server style. This style highlights request-response latency as a key property, identifies the client as a strategic point for measuring latency and the server for load, and suggests the use of queuing theory to reason about service time and latency. The style may suggest an adaptation that switches clients to less loaded servers to reduce latency. 4 Related Work To date, several dynamic software architectures and architecture-based adaptation frameworks have been proposed and developed [7, 24, 39], including an effort to characterize the style requirements of self-healing systems [35]. Below, we examine a representative set of approaches, categorizing each by its primary focus, then high- lighting its main features. Broadly speaking, related approaches focus on formalism and modeling, or mechanisms of adaptation. A third category addresses distribution and decentralization of control. 4.1 Distributed, Decentralized Adaptation Work on self-organizing systems in [23] proposes an approach where self-managing units coordinate toward a common model, an architectural structure defined using the architectural formalism of Darwin [33]. Each self-organizing component is responsible for managing its own adaptation with respect to the overall system. To do this, each component maintains a copy of the architecture model of the entire system. While this approach provides the advantage of distributed control and elim- inates a single point of failure, requiring each component to maintain a global model
- 53. Software Architecture-Based Self-Adaptation 37 and keep the model consistent, which imposes significant performance overhead. Furthermore, the approach prescribes a fixed distributed algorithm for global config- uration. We overcome the performance overhead and coordination issue by allowing tailorable global reorganization without imposing a high-performance overhead, but we trade off distributed, localized control of adaptation decision. 4.2 Formal, Dynamic Architectures A number of approaches focus on modeling and formalizing dynamic systems, rather than mechanisms to enable self-adaption. Our approach builds on formal architectural modeling, using the model within a framework of reusable infras- tructures to enable self-adaptation in a target system. Wermelinger and colleagues developed a high-level language, based on CommUnity, to describe architectures, as well as changes over an architectural configuration, such as adding, removing, or substituting components or interconnections [49]. The K-Component model addresses the integrity and safety of dynamic software evolution, modeled as graph transformations of meta-models on architecture [15]. It uses reflective programs called adaptation contracts to build adaptive applications, coordinated via a configuration manager (similar to Le Métayer’s approach [31]). Darwin is an ADL for specifying the architecture of a distributed system, with an operational semantics that captures dynamic structures as the elaboration of com- ponents and their bindings in a configuration [33]. Organization of components and connectors may change during execution. The evolving structures of Darwin are modeled using Milner’s -calculus, allowing the correctness of its program elab- oration to be analyzed. Together with its -calculus semantics, Darwin serves as a general-purpose configuration language for specifying distributed systems. Arch- Ware [37] and PiLar [12] are examples of ADLs that use architectural reflection to model layers of active architectures, allowing separate concerns to be addressed at different layers. These approaches rely on sophisticated reflective technologies to support the active architectures and enable dynamic co-evolution. These approaches assume that system implementations are generated from the architecture descriptions. In contrast, our approach relies on external mechanisms decoupled from the target system and can therefore be used to add adaptation to existing systems. 4.3 Style-Specific Approaches with Fixed Quality Attributes A number of architecture-based approaches provide mechanisms to enable self- adaptation (or system reconfiguration) that focus on particular quality attributes of systems, such as performance [6, 27, 32], survivability [50], or that focus on particular architectural styles, for example, [26, 38].
- 54. 38 D. Garlan et al. Most closely related to our own work is that of the UCI Research group headed by Taylor [14], and the research of Sztajnberg [47]. As a natural extension of [38], Tay- lor’s group developed an architecture-based runtime architecture evolution frame- work, which dynamically evolves systems using a monitoring and execution loop controlled by a planning loop. This framework supports self-adaptation for C2-style systems, and evolution of the architecture model uses architectural differencing and merging techniques similar to those used for source code version control. Sztajnberg and Loques developed the CR-RIO framework, which uses a style-neutral ADL (CBabel), architectural contracts to specify execution context, application profiles to describe resource requirements, and middleware to perform architectural recon- figurations based on the specified contracts. CR-RIO demonstrates a formal ver- ification capability but does not appear to support automation of multi-objective adaptations, for example by composing multiple contracts, nor does it address engi- neering aspects. Our approach can be applied to different classes of systems and can address multiple quality objectives. Current approaches present a number of limitations and unresolved issues, which are addressed by Rainbow. In particular, where traditional adaptive techniques—for example, the ones based on exception-handling mechanisms and network time- outs—rely only on localized knowledge of system states, we use an architecture- based approach to leverage a more global perspective. While existing approaches do not address the quantity of adaptation and system-level details that engineers grapple with in order to build self-adaptation for their systems, we design a language that encapsulates core self-adaptation concepts and hoists them as first-class build- ing blocks for system engineers to build self-adaptation capabilities. Finally, almost no existing approach provides a systematic, integrated approach to self-adaptation that combines an end-to-end system perspective, style-based adaptation, automation of routine human expertise, and incremental support to developing self-adaptation capabilities; we address this by providing a framework with reusable infrastructures and customizable elements. 5 The Rainbow Approach Related work provides some of the building blocks for our own research. Software architecture research provides the language, models, and analysis mechanisms to represent and reason about a system’s runtime properties; related work in self- healing systems and architecture-based approaches demonstrate the effectiveness of using software architecture for particular classes of systems and fixed quality attributes. What is missing is an approach to self-adaptation that (a) is generally applicable to different classes of systems and quality objectives, (b) allows adapta- tion to be represented as explicit operational entities and chooses the best one in a principled and analyzable way, and (c) provides an integrated approach that saves engineers time and effort in writing and changing adaptation. Our approach satisfies the above requirements by (1) providing a framework, called Rainbow, that provides general, supporting mechanisms for self-adaptation,
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. pronounced against the devil, which puts him into an irrecoverable state by a mortal bruising of his head.” But, I say, he is not only punished, but the organ, whereby he blew in his temptation, is put into a worse condition than it was before. Thus God hated the sponge, whereby the devil deformed his beautiful image: thus God, to manifest his detestation of sin, ordered the beast, whereby any man was slain, to be slain as well as the malefactor (Lev. xx. 15). The gold and silver that had been abused to idolatry, and were the ornaments of images, though good in themselves, and incapable of a criminal nature, were not to be brought into their houses, but detested and abhorred by them, because they were cursed, and an abomination to the Lord. See with what loathing expressions this law is enjoined to them (Deut. vii. 25, 26). So contrary is the holy nature of God to every sin, that it curseth everything that is instrumental in it. (3.) How detestable is everything to him that is in the sinner’s possession! The very earth, which God had made Adam the proprietor of, was cursed for his sake (Gen. iii. 17, 18). It lost its beauty, and lies languishing to this day; and, notwithstanding the redemption by Christ, hath not recovered its health, nor is it like to do, till the completing the fruits of it upon the children of God (Rom. viii. 20‒22). The whole lower creation was made subject to vanity, and put into pangs, upon the sin of man, by the righteousness of God detesting his offence. How often hath his implacable aversion from sin been shown, not only in his judgments upon the offender’s person, but by wrapping up, in the same judgment, those which stood in a near relation to them! Achan, with his children and cattle, are overwhelmed with stones, and burned together (Josh. vii. 24, 25). In the destruction of Sodom, not only the grown malefactors, but the young spawn, the infants, at present incapable of the same wickedness, and their cattle, were burned up by the same fire from heaven; and the place where their habitations stood, is, at this day, partly a heap of ashes, and partly an infectious lake, that chokes any fish that swims into it from Jordan, and stifles, as is related, by its vapor, any bird that attempts to fly over it. O, how
- 57. detestable is sin to God, that causes him to turn a pleasant land, as the “garden of the Lord” (as it is styled Gen. xiii. 10), into a lake of sulphur; to make it, both in his word and works, as a lasting monument of his abhorrence of evil! (4.) What design hath God in all these acts of severity and vindictive justice, but to set off the lustre of his holiness? He testifies himself concerned for those laws, which he hath set as hedges and limits to the lusts of men; and, therefore, when he breathes forth his fiery indignation against a people, he is said to get himself honor: as when he intended the Red Sea should swallow up the Egyptian army (Exod. xiv. 17, 18), which Moses, in his triumphant song, echoes back again (Exod. xv. 1): “Thou hast triumphed gloriously;” gloriously in his holiness, which is the glory of his nature, as Moses himself interprets it in the text. When men will not own the holiness of God, in a way of duty, God will vindicate it in a way of justice and punishment. In the destruction of Aaron’s sons, that were will‑worshippers, and would take strange fire, “sanctified” and “glorified” are coupled (Lev. x. 3): he glorified himself in that act, in vindicating his holiness before all the people, declaring that he will not endure sin and disobedience. He doth therefore, in this life, more severely punish the sins of his people, when they presume upon any act of disobedience, for a testimony that the nearness and dearness of any person to him shall not make him unconcerned in his holiness, or be a plea for impurity. The end of all his judgments is to witness to the world his abominating of sin. To punish and witness against men, are one and the same thing (Micah i. 2): “The Lord shall witness against you;” and it is the witness of God’s holiness (Hos. v. 5): “And the pride of Israel doth testify to his face:” one renders it the excellency of Israel, and understands it of God: the word גאון, which is here in our translation, “pride,” is rendered “excellency” (Amos viii. 7): “The Lord God hath sworn by his excellency;” which is interpreted “holiness” (Amos iv. 2): “The Lord God hath sworn by his holiness.” What is the issue or end of this swearing by “holiness,” and of his “excellency” testifying against them? In all those places you will find them to be sweeping
- 58. judgments: in one, Israel and Ephraim shall “fall in their iniquity;” in another, he will “take them away with hooks,” and “their posterity with fish‑hooks;” and in another, he would “never forget any of their works.” He that punisheth wickedness in those he before used with the greatest tenderness, furnisheth the world with an undeniable evidence of the detestableness of it to him. Were not judgments sometimes poured out upon the world, it would be believed that God were rather an approver than an enemy to sin. To conclude, since God hath made a stricter law to guide men, annexed promises above the merit of obedience to allure them, and threatenings dreadful enough to affright men from disobedience, he cannot be the cause of sin, nor a lover of it. How can he be the author of that which he so severely forbids; or love that which he delights to punish; or be fondly indulgent to any evil, when he hates the ignorant instruments in the offences of his reasonable creatures? Thirdly. The holiness of God appears in our restoration. It is in the glass of the gospel we behold the “glory of the Lord” (2 Cor. iii. 18); that is, the glory of the Lord, into whose image we are changed; but we are changed into nothing, as the image of God, but into holiness: we bore not upon us by creation, nor by regeneration, the image of any other perfection: we cannot be changed into his omnipotence, omniscience, c., but into the image of his righteousness. This is the pleasing and glorious sight the gospel mirror darts in our eyes. The whole scene of redemption is nothing else but a discovery of judgment and righteousness (Isa. i. 27): “Zion shall be redeemed with judgment, and her converts with righteousness.” 1. This holiness of God appears in the manner of our restoration, viz. by the death of Christ. Not all the vials of judgments, that have, or shall be poured out upon the wicked world, nor the flaming furnace of a sinner’s conscience, nor the irreversible sentence pronounced against the rebellious devils, nor the groans of the damned creatures, give such a demonstration of God’s hatred of sin, as the wrath of God let loose upon his Son. Never did Divine
- 59. holiness appear more beautiful and lovely, than at the time our Saviour’s countenance was most marred in the midst of his dying groans. This himself acknowledges in that prophetical psalm (xxii. 1, 2), when God had turned his smiling face from him, and thrust his sharp knife into his heart, which forced that terrible cry from him, “My God, my God, why hast thou forsaken me?” He adores this perfection of holiness (ver. 3), “But thou art holy;” thy holiness is the spring of all this sharp agony, and for this thou inhabitest, and shalt forever inhabit, the praises of all thy Israel. Holiness drew the veil between God’s countenance and our Saviour’s soul. Justice indeed gave the stroke, but holiness ordered it. In this his purity did sparkle, and his irreversible justice manifested that all those that commit sin are worthy of death; this was the perfect index of his “righteousness” (Rom. iii. 25), that is, of his holiness and truth; then it was that God that is holy, was “sanctified in righteousness” (Isa. v. 16). It appears the more, if you consider, (1.) The dignity of the Redeemer’s person. One that had been from eternity; had laid the foundations of the world; had been the object of the Divine delight: he that was God blessed forever, become a curse; he who was blessed by angels, and by whom God blessed the world, must be seized with horror; the Son of eternity must bleed to death! When did ever sin appear so irreconcileable to God? Where did God ever break out so furiously in his detestation of iniquity? The Father would have the most excellent person, one next in order to himself, and equal to him in all the glorious perfections of his nature (Phil. ii. 6), die on a disgraceful cross, and be exposed to the flames of Divine wrath, rather than sin should live, and his holiness remain forever disparaged by the violations of his law. (2.) The near relation he stood in to the Father. He was his “own Son that he delivered up” (Rom. viii. 32); his essential image, as dearly beloved by him as himself; yet he would abate nothing of his hatred of those sins imputed to one so dear to him, and who never had done anything contrary to his will. The strong cries uttered by him could not cause him to cut off the least fringe of this royal
- 60. garment, nor part with a thread the robe of his holiness was woven with. The torrent of wrath is opened upon him, and the Father’s heart beats not in the least notice of tenderness to sin, in the midst of his Son’s agonies. God seems to lay aside the bowels of a father, and put on the garb of an irreconcileable enemy,907 upon which account, probably, our Saviour in the midst of his passion gives him the title of God; not of Father, the title he usually before addressed to him with, (Matt. xxvii. 46), “My God, my God;” not, My Father, my Father; “why hast thou forsaken me?” He seems to hang upon the cross like a disinherited son, while he appeared in the garb and rank of a sinner. Then was his head loaded with curses, when he stood under that sentence of “Cursed is every one that hangs upon a tree” (Gal. iii. 13), and looked as one forlorn and rejected by the Divine purity and tenderness. God dealt not with him as if he had been one in so near a relation to him. He left him not to the will only of the instruments of his death; he would have the chiefest blow himself of bruising of him (Isa. liii. 10): “It pleased the Lord to bruise him:” the Lord, because the power of creatures could not strike a blow strong enough to satisfy and secure the rights of infinite holiness. It was therefore a cup tempered and put into his hands by his Father; a cup given him to drink. In other judgments he lets out his wrath against his creatures; in this he lets out his wrath, as it were, against himself, against his Son, one as dear to him as himself. As in his making creatures, his power over nothing to bring it into being appeared; but in pardoning sin he hath power over himself; so in punishing creatures, his holiness appears in his wrath against creatures, against sinners by inherency; but by punishing sin in his Son, his holiness sharpens his wrath against him who was his equal, and only a reputed sinner; as if his affection to his own holiness surmounted his affection to his Son: for he chose to suspend the breakings out of his affections to his Son, and see him plunged in a sharp and ignominious misery, without giving him any visible token of his love, rather than see his holiness lie groaning under the injuries of a transgressing world.
- 61. (3.) The value he puts upon his holiness appears further, in the advancement of this redeeming person, after his death. Our Saviour was advanced, not barely for his dying, but for the respect he had in his death to this attribute of God (Heb. i. 9): “Thou hast loved righteousness, and hated iniquity: therefore God, even thy God, hath anointed thee with the oil of gladness,” c. By righteousness is meant this perfection, because of the opposition of it to iniquity. Some think “therefore” to be the final cause; as if this were the sense, “Thou art anointed with the oil of gladness, that thou mightest love righteousness and hate iniquity.” But the Holy Ghost seeming to speak in this chapter not only of the Godhead of Christ but of his exaltation; the doctrine whereof he had begun in ver. 3, and prosecutes in the following verses, I would rather understand “therefore,” for “this cause, or reason, hath God anointed thee;” not “to this end.” Christ indeed had an unction of grace, whereby he was fitted for his mediatory work; he had also an unction of glory, whereby he was rewarded for it. In the first regard, it was a qualifying him for his office; in the second regard, it was a solemn inaugurating him in his royal authority. And the reason of his being settled upon a “throne for ever and ever,” is, “because he loved righteousness.” He suffered himself to be pierced to death, that sin, the enemy of God’s purity, might be destroyed, and the honor of the law, the image of God’s holiness, might be repaired and fulfilled in the fallen creature. He restored the credit of Divine holiness in the world, in manifesting, by his death, God an irreconcileable enemy to all sin; in abolishing the empire of sin, so hateful to God, and restoring the rectitude of nature, and new framing the image of God in his chosen ones. And God so valued this vindication of his holiness, that he confers upon him, in his human nature, an eternal royalty and empire over angels and men. Holiness was the great attribute respected by Christ in his dying, and manifested in his death; and for his love to this, God would bestow an honor upon his person, in that nature wherein he did vindicate the honor of so dear a perfection. In the death of Christ, he showed his resolution to preserve its rights; in the exaltation of Christ, he evinced his mighty
- 62. pleasure for the vindication of it; in both, the infinite value he had for it, as dear to him as his life and glory. (4.) It may be farther considered, that in this way of redemption, his holiness in the hatred of sin seems to be valued above any other attribute. He proclaims the value of it above the person of his Son; since the Divine nature of the Redeemer is disguised, obscured, and vailed, in order to the restoring the honor of it. And Christ seems to value it above his own person, since he submitted himself to the reproaches of men, to clear this perfection of the Divine nature, and make it illustrious in the eyes of the world. You heard before, at the beginning of the handling this argument, it was the beauty of the Deity, the lustre of his nature, the link of all his attributes, his very life; he values it equal with himself, since he swears by it, as well as by his life; and none of his attributes would have a due decorum without it; it is the glory of power, mercy, justice, and wisdom, that they are all holy; so that though God had an infinite tenderness and compassion to the fallen creature, yet it should not extend itself in his relief to the prejudice of the rights of his purity: he would have this triumph in the tenderness of his mercy, as well as the severities of his justice. His mercy had not appeared in its true colors, nor attained a regular end, without vengeance on sin. It would have been a compassion that would, in sparing the sinner, have encouraged the sin, and affronted holiness in the issues of it: had he dispersed his compassions about the world, without the regard to his hatred of sin, his mercy had been too cheap, and his holiness had been contemned; his mercy would not have triumphed in his own nature, whilst his holiness had suffered; he had exercised a mercy with the impairing his own glory; but now, in this way of redemption, the rights of both are secured, both have their due lustre: the odiousness of sin is equally discovered with the greatest of his compassions; an infinite abhorrence of sin, and an infinite love to the world, march hand in hand together. Never was so much of the irreconcileableness of sin to him set forth, as in the moment he was opening his bowels in the reconciliation of the sinner. Sin is made the chiefest mark of his
- 63. displeasure, while the poor creature is made the highest object of Divine pity. There could have been no motion of mercy, with the least injury to purity and holiness. In this way mercy and truth, mercy to the misery of the creature, and truth to the purity of the law, “have met together;” the righteousness of God, and the peace of the sinner, “have kissed each other” (Ps. lxxxv. 10). 2. The holiness of God in his hatred of sin appears in our justification, and the conditions he requires of all that would enjoy the benefit of redemption. His wisdom hath so tempered all the conditions of it, that the honor of his holiness is as much preserved, as the sweetness of his mercy is experimented by us; all the conditions are records of his exact purity, as well as of his condescending grace. Our justification is not by the imperfect works of creatures, but by an exact and infinite righteousness, as great as that of the Deity which had been offended: it being the righteousness of a Divine person, upon which account it is called the righteousness of God; not only in regard of God’s appointing it, and God’s accepting it, but as it is a righteousness of that person that was God, and is God. Faith is the condition God requires to justification; but not a dead, but an active faith, such a “faith as purifies the heart” (James ii. 20; Acts xv. 9). He calls for repentance, which is a moral retracting our offences, and an approbation of contemned righteousness and a violated law; an endeavor to gain what is lost, and to pluck out the heart of that sin we have committed. He requires mortification, which is called crucifying; whereby a man would strike as full and deadly a blow at his lusts, as was struck at Christ upon the cross, and make them as certainly die, as the Redeemer did. Our own righteousness must be condemned by us, as impure and imperfect: we must disown everything that is our own, as to righteousness, in reverence to the holiness of God, and the valuation of the righteousness of Christ. He hath resolved not to bestow the inheritance of glory without the root of grace. None are partakers of the Divine blessedness that are not partakers of the Divine nature: there must be a renewing of his image before there be a vision of his face (Heb. xii. 14). He will not have men
- 64. brought only into a relative state of happiness by justification, without a real state of grace by sanctification; and so resolved he is in it, that there is no admittance into heaven of a starting, but a persevering holiness (Rom. ii. 7), “a patient continuance in well‑doing:” patient, under the sharpness of affliction, and continuing, under the pleasures of prosperity. Hence it is that the gospel, the restoring doctrine, hath not only the motives of rewards to allure to good, and the danger of punishments to scare us from evil, as the law had; but they are set forth in a higher strain, in a way of stronger engagement; the rewards are heavenly, and the punishments eternal: and more powerful motives besides, from the choicer expressions of God’s love in the death of his Son. The whole design of it is to reinstate us in a resemblance to this Divine perfection; whereby he shows what an affection he hath to this excellency of his nature, and what a detestation he hath of evil, which is contrary to it. 3. It appears in the actual regeneration of the redeemed souls, and a carrying it on to a full perfection. As election is the effect of God’s sovereignty, our pardon the fruit of his mercy, our knowledge a stream from his wisdom, our strength an impression of his power; so our purity is a beam from his holiness. The whole work of sanctification, and the preservation of it, our Saviour begs for his disciples of his Father, under this title (John xvii. 11, 17): “Holy Father, keep them through thy own name,” and “sanctify them through thy truth;” as the proper source whence holiness was to flow to the creature: as the sun is the proper fountain whence light is derived, both to the stars above, and the bodies here below. Whence He is not only called Holy, but the Holy One of Israel (Isa. xliii. 15), “I am the Lord your Holy One, the Creator of Israel:” displaying his holiness in them, by a new creation of them as his Israel. As the rectitude of the creature at the first creation was the effect of his holiness, so the purity of the creature, by a new creation, is a draught of the same perfection. He is called the Holy One of Israel more in Isaiah, that evangelical prophet, in erecting Zion, and forming a people for himself, than in the whole Scripture
- 65. besides. As he sent Jesus Christ to satisfy his justice for the expiation of the guilt of sin, so he sends the Holy Ghost for the cleansing of the filth of sin, and overmastering the power of it: Himself is the fountain, the Son is the pattern, and the Holy Ghost the immediate imprinter of this stamp of holiness upon the creature. God hath such a value for this attribute, that he designs the glory of this in the renewing the creature, more than the happiness of the creature; though the one doth necessarily follow upon the other, yet the one is the principal design, and the other the consequent of the former: whence our salvation is more frequently set forth, in Scripture, by a redemption from sin, and sanctification of the soul, than by a possession of heaven.908 Indeed, as God could not create a rational creature, without interesting this attribute in a special manner, so he cannot restore the fallen creature without it. As in creating a rational creature, there must be holiness to adorn it, as well as wisdom to form the design, and power to effect it; so in the restoration of the creature, as he could not make a reasonable creature unholy, so he cannot restore a fallen creature, and put him in a meet posture to take pleasure in him, without communicating to him a resemblance of himself. As God cannot be blessed in himself without this perfection of purity, so neither can a creature be blessed without it. As God would be unlovely to himself without this attribute, so would the creature be unlovely to God, without a stamp and mark of it upon his nature. So much is this perfection one with God, valued by him, and interested in all his works and ways! III. The third thing I am to do, is to lay down some proposition in the defence of God’s holiness in all his acts, about, or concerning sin. It was a prudent and pious advice of Camero, not to be too busy and rash in inquiries and conclusions about the reason of God’s providence in the matter of sin. The Scripture hath put a bar in the way of such curiosity, by telling us, that the ways of God’s wisdom and righteousness in his judgments are “unsearchable” (Rom. xi. 33): much more the ways of God’s holiness, as he stands in relation to sin, as a Governor of the world; we cannot consider those things without danger of slipping: our eyes are too weak to look
- 66. upon the sun without being dazzled: too much curiosity met with a just check in our first parent. To be desirous to know the reason of all God’s proceedings in the matter of sin, is to second the ambition of Adam, to be as wise as God, and know the reason of his actings equally with himself. It is more easy, as the same author saith, to give an account of God’s providence since the revolt of man, and the poison that hath universally seized upon human nature, than to make guesses at the manner of the fall of the first man. The Scripture hath given us but a short account of the manner of it, to discourage too curious inquiries into it. It is certain that God made man upright; and when man sinned in paradise, God was active in sustaining the substantial nature and act of the sinner while he was sinning, though not in supporting the sinfulness of the act: he was permissive in suffering it: he was negative in withholding that grace which might certainly have prevented his crime, and consequently his ruin; though he withheld nothing that was sufficient for his resistance of that temptation wherewith he was assaulted. And since the fall of man, God, as a wise governor, is directive of the events of the transgression, and draws the choicest good out of the blackest evil, and limits the sins of men, that they creep not so far as the evil nature of men would urge them to; and as a righteous Judge, he takes away the talent from idle servants, and the light from wicked ones, whereby they stumble and fall into crimes, by the inclinations and proneness of their own corrupt natures, leaves them to the bias of their own vicious habits, denies that grace which they have forfeited, and have no right to challenge, and turns their sinful actions into punishments, both to the committers of them and others. Prop. I. God’s holiness is not chargeable with any blemish for his creating man in a mutable state. It is true, angels and men were created with a changeable nature; as though there was a rich and glorious stamp upon them by the hand of God, yet their natures were not incapable of a base and vile stamp from some other principle: as the silver which bears upon it the image of a great prince, is capable of being melted down, and imprinted with no
- 67. better an image than that of some vile and monstrous beast. Though God made man upright, yet he was capable of seeking “many inventions” (Eccl. vii. 29); yet the hand of God was not defiled by forming man with such a nature. It was suitable to the wisdom of God to give the rational creature, whom he had furnished with a power of acting righteously, the liberty of choice, and not fix him in an unchangeable state without a trial of him in his natural; that if he did obey, his obedience might be the more valuable; and if he did freely offend, his offence might be more inexcusable. 1. No creature can be capable of immutability by nature. Mutability is so essential to a creature, that a creature cannot be supposed without it; you must suppose it a Creator, not a creature, if you allow it to be of an immutable nature. Immutability is the property of the Supreme Being. God “only hath immortality” (1 Tim. vi. 16); immortality, as opposed not only to a natural, but to a sinful death; the word only appropriates every sort of immortality to God, and excludes every creature, whether angel or man, from a partnership with God in this by nature. Every creature, therefore, is capable of a death in sin. “None is good but God,” and none is naturally free from change but God, which excludes every creature from the same prerogative; and certainly, if one angel sinned, all might have sinned, because there was the same root of mutability in one as well as another. It is as possible for a creature to be a Creator, as for a creature to have naturally an incommunicable property of the Creator. All things, whether angels or men, are made of nothing, and therefore, capable of defection;909 because a creature being made of nothing, cannot be good, per essentiam, or essentially good, but by participation from another. Again, every rational creature, being made of nothing, hath a superior which created him and governs him, and is capable of a precept; and, consequently, capable of disobedience as well as obedience to the precept, to transgress it, as well as obey it. God cannot sin, because he can have no superior to impose a precept on him. A rational creature, with a liberty of will and power of choice, cannot be made by nature of such a mould and temper, but he must be as well
- 68. capable of choosing wrong, as of choosing right; and, therefore, the standing angels, and glorified saints, though they are immutable, it is not by nature that they are so, but by grace, and the good pleasure of God; for though they are in heaven, they have still in their nature a remote power of sinning, but it shall never be brought into act, because God will always incline their wills to love him, and never concur with their wills to any evil act. Since, therefore, mutability is essential to a creature as a creature, this changeableness cannot properly be charged upon God as the author of it; for it was not the term of God’s creating act, but did necessarily result from the nature of the creature, as unchangeableness doth result from the essence of God. The brittleness of a glass is no blame to the art of him that blew up the glass into such a fashion; that imperfection of brittleness is not from the workman, but the matter; so, though unchangeableness be an imperfection, yet it is so necessary a one, that no creature can be naturally without it; besides, though angels and men were mutable by creation, and capable to exercise their wills, yet they were not necessitated to evil, and this mutability did not infer a necessity that they should fall, because some angels, which had the same root of changeableness in their natures with those that fell, did not fall, which they would have done, if capableness of changing, and necessity of changing, were one and the same thing. 2. Though God made the creature mutable, yet he made him not evil. There could be nothing of evil in him that God created after his own image, and pronounced “good” (Gen. i. 27, 31). Man had an ability to stand, as well as a capacity to fall: he was created with a principal of acting freely, whereby he was capable of loving God as his chief good, and moving to him as his last end; there was a beam of light in man’s understanding to know the rule he was to conform to, a harmony between his reason and his affections, an original righteousness: so that it seemed more easy for him to determine his will to continue in obedience to the precept, than to swerve from it; to adhere to God as his chief good, than to listen to the charms of Satan. God created him with those advantages, that he might with
- 69. more facility have kept his eyes fixed upon the Divine beauty, than turn his back upon it, and with greater ease have kept the precept God gave him, than have broken it. The very first thought darted, or impression made, by God, upon the angelical or human nature, was the knowledge of himself as their Author, and could be no more than such whereby both angels and men might be excited to a love of that adorable Being, that had framed them so gloriously out of nothing; and if they turned their wills and affections to another object it was not by the direction of God, but contrary to the impression God had made upon them, or the first thought he flashed into them. They turned themselves to the admiring their own excellency, or affecting an advantage distinct from that which they were to look for only from God (1 Tim. iii. 6). Pride was the cause of the condemnation of the devil. Though the wills of angels and men were created mutable, and so were imperfect, yet they were not created evil. Though they might sin, yet they might not sin, and, therefore, were not evil in their own nature. What reflection, then, could this mutability of their nature be upon God? So far is it from any, that he is fully cleared, by storing up in the nature of man sufficient provision against his departure from him. God was so far from creating him evil, that he fortified him with a knowledge in his understanding, and a strength in his nature to withstand any invasion. The knowledge was exercised by Eve, in the very moment of the serpent’s assaulting her (Gen. iii. 3); Eve said to the serpent, “God hath said, ye shall not eat of it:” and had her thoughts been intent upon this, “God hath said,” and not diverted to the motions of the sensitive appetite and liquorish palate, it had been sufficient to put by all the passes the devil did, or could have made at her. So that you see, though God made the creature mutable, yet he made him not evil. This clears the holiness of God. 3. Therefore it follows, That though God created man changeable, yet he was not the cause of his change by his fall. Though man was created defectible, yet he was not determined by God influencing his will by any positive act to that change and apostasy. God placed him in a free posture, set life and happiness
- 70. before him on the one hand, misery and death on the other; as he did not draw him into the arms of perpetual blessedness, so he did not drive him into the gulf of his misery.910 He did not incline him to evil. It was repugnant to the goodness of God to corrupt the righteousness of those faculties he had so lately beautified him with. It was not likely he should deface the beauty of that work he had composed with so much wisdom and skill. Would he, by any act of his own, make that bad, which, but a little before, he had acquiesced in as good? Angels and men were left to their liberty and conduct of their natural faculties; and if God inspired them with any motions, they could not but be motions to good, and suited to that righteous nature he had endued them with. But it is most probable that God did not, in a supernatural way, act inwardly upon the mind of man, but left him wholly to that power, which he had, in creation, furnished him with. The Scripture frees God fully from any blame in this, and lays it wholly upon Satan, as the tempter, and upon man, as the determiner of his own will (Gen. iii. 6); Eve “took of the fruit, and did eat;” and Adam took from her of the fruit, “and did eat.” And Solomon (Eccles. vii. 29) distinguisheth God’s work in the creation of man “upright,” from man’s work in seeking out those ruining inventions. God created man in a righteous state, and man cast himself into a forlorn state. As he was a mutable creature, he was from God; as he was a changed and corrupted creature, it was from the devil seducing, and his own pliableness in admitting. As silver, and gold, and other metals, were created by God in such a form and figure, yet capable of receiving other forms by the industrious art of man; when the image of a man is put upon a piece of metal, God is not said to create that image, though he created the substance with such a property, that it was capable of receiving it; this capacity is from the nature of the metal by God’s creation of it, but the carving the figure of this or that man is not the act of God, but the act of man. As images, in Scripture, are called the work of men’s hands, in regard of the imagery, though the matter, wood or stone, upon which the image was carved, was a work of God’s creative power. When an artificer frames an excellent instrument, and a musician
- 71. exactly tunes it, and it comes out of their hands without a blemish, but capable to be untuned by some rude hand, or receive a crack by a sudden fall, if it meet with a disaster, is either the workman or musician to be blamed? The ruin of a house, caused by the wastefulness or carelessness of the tenant, is not to be imputed to the workman that built it strong, and left it in a good posture. Prop. II. God’s holiness is not blemished by enjoining man a law, which he knew he would not observe. 1. The law was not above his strength. Had the law been impossible to be observed, no crime could have been imputed to the subject, the fault had lain wholly upon the Governor; the non‑observance of it had been from a want of strength, and not from a want of will. Had God commanded Adam to fly up to the sun, when he had not given him wings, Adam might have a will to obey it, but his power would be too short to perform it. But the law set him for a rule, had nothing of impossibility in it; it was easy to be observed; the command was rather below, than above his strength; and the sanction of it was more apt to restrain and scare him from the breach of it, than encourage any daring attempts against it; he had as much power, or rather more, to conform to it, than to warp from it; and greater arguments and interest to be observant of it, than to violate it; his all was secured by the one, and his ruin ascertained by the other. The commands of God are not grievous (1 John v. 3); from the first to the last command, there is nothing impossible, nothing hard to the original and created nature of man, which were all summed up in a love to God, which was the pleasure and delight of man, as well as his duty, if he had not, by inconsiderateness, neglected the dictates and resolves of his own understanding. The law was suited to the strength of man, and fitted for the improvement and perfection of his nature; in which respect, the apostle calls it “good,” as it refers to man, as well as “holy,” as it refers to God (Rom. vii. 12). Now, since God created man a creature capable to be governed by a law, and as a rational creature endued with understanding and will, not to be governed, according to his
- 72. nature, without a law; was it congruous to the wisdom of God to respect only the future state of man, which, from the depth of his infinite knowledge, he did infallibly foresee would be miserable, by the wilful defection of man from the rule? Had it been agreeable to the wisdom of God, to respect only this future state, and not the present state of the creature; and therefore leave him lawless, because he knew he would violate the law? Should God forbear to act like a wise governor, because he saw that man would cease to act like an obedient subject? Shall a righteous magistrate forbear to make just and good laws, because he foresees, either from the dispositions of his subjects, their ill‑humor, or some circumstances which will intervene, that multitudes of them will incline to break those laws, and fall under the penalty of them? No blame can be upon that magistrate who minds the rule of righteousness, and the necessary duty of his government, since he is not the cause of those turbulent affections of men, which he wisely foresees will rise up against his just edicts. 2. Though the law now be above the strength of man, yet is not the holiness of God blemished by keeping it up. It is true, God hath been graciously pleased to mitigate the severity and rigor of the law, by the entrance of the gospel; yet where men refuse the terms of the gospel, they continue themselves under the condemnation of the law, and are justly guilty of the breach of it, though they have no strength to observe it. The law, as I said before, was not above man’s strength, when he was possessed of original righteousness, though it be above man’s strength, since he was stripped of original righteousness. The command was dated before man had contracted his impotency, when he had a power to keep it as well as to break it. Had it been enjoined to man only after the fall, and not before, he might have had a better pretence to excuse himself, because of the impossibility of it; yet he would not have had sufficient excuse, since the impossibility did not result from the nature of the law, but from the corrupted nature of the creature. It was “weak through the flesh” (Rom. viii. 3), but it was promulged when man had a strength proportioned to the commands of it. And now, since man hath
- 73. unhappily made himself incapable of obeying it, must God’s holiness in his law be blemished for enjoining it? Must he abrogate those commands, and prohibit what before he enjoined, for the satisfaction of the corrupted creature? Would not this be his “ceasing to be holy,” that his creature might be unblameably unrighteous? Must God strip himself of his holiness, because man will not discharge his iniquity? He cannot be the cause of sin, by keeping up the law, who would be the cause of all the unrighteousness of men, by removing the authority of it. Some things in the law that are intrinsically good in their own nature, are indispensable, and it is repugnant to the nature of God not to command them. If he were not the guardian of his indispensable law, he would be the cause and countenancer of the creatures’ iniquity. So little reason have men to charge God with being the cause of their sin, by not repealing his law to gratify their impotence, that he would be unholy if he did. God must not lose his purity, because man hath lost his, and cast away the right of his sovereignty, because man hath cast away his power of obedience. 3. God’s foreknowledge that his law would not be observed, lays no blame upon him. Though the foreknowledge of God be infallible, yet it doth not necessitate the creature in acting. It was certain from eternity, that Adam would fall, that men would do such and such actions, that Judas would betray our Saviour; God foreknew all those things from eternity; but, it is as certain that this foreknowledge did not necessitate the will of Adam, or any other branch of his posterity, in the doing those actions that were so foreseen by God; they voluntarily run into such courses, not by any impulsion. God’s knowledge was not suspended between certainty and uncertainty; he certainly foreknew that his law would be broken by Adam; he foreknew it in his own decree of not hindering him, by giving Adam the efficacious grace which would infallibly have prevented it; yet Adam did freely break this law, and never imagined that the foreknowledge of God did necessitate him to it; he could find no cause of his own sin, but the liberty of his own will; he charges the occasion of his sin upon the woman, and consequently upon God in
- 74. giving the woman to him (Gen. iii. 12). He could not be so ignorant of the nature of God, as to imagine him without a foresight of future things: since his knowledge of what was to be known of God by creation, was greater than any man’s since, in all probability. But, however, if he were not acquainted with the notion of God’s foreknowledge, he could not be ignorant of his own act; there could not have been any necessity upon him, any kind of constraint of him in his action, that could have been unknown to him; and he would not have omitted a plea of so strong a nature, when he was upon his trial for life or death; especially when he urgeth so weak an argument, to impute his crime to God, as the gift of the woman; as if that which was designed him for a help, were intended for his ruin. If God’s prescience takes away the liberty of the creature, there is no such thing as a free action in the world (for there is nothing done but is foreknown by God, else we render God of a limited understanding), nor ever was, no, not by God himself, ad extra; for whatsoever he hath done in creation, whatsoever he hath done since the creation, was foreknown by him: he resolved to do it, and, therefore, foreknew that he would do it. Did God do it, therefore, necessarily, as necessity is opposed to liberty? As he freely decrees what he will do, so he effects what he freely decreed. Foreknowledge is so far from intrenching upon the liberty of the will, that predetermination, which in the notion of it speaks something more, doth not dissolve it; God did not only foreknow, but determine the suffering of Christ (Acts iv. 27, 28). It was necessary, therefore, that Christ should suffer, that God might not be mistaken in his foreknowledge, or come short of his determinate decree; but did this take away the liberty of Christ in suffering? (Eph. v. 2): “Who offered himself up to God;” that is, by a voluntary act, as well as designed to do it by a determinate counsel. It did infallibly secure the event, but did not annihilate the liberty of the action, either in Christ’s willingness to suffer, or the crime of the Jews that made him suffer. God’s prescience is God’s provision of things arising from their proper causes; as a gardener foresees in his plants the leaves and the flowers that will arise from them in the spring, because he knows the strength and nature of their several roots which lie under
- 75. ground; but his foresight of these things is not the cause of the rise and appearance of those flowers. If any of us see a ship moving towards such a rock or quicksand, and know it to be governed by a negligent pilot, we shall certainly foresee that the ship will be torn in pieces by the rock, or swallowed up by the sands; but is this foresight of ours from the causes, any cause of the effect; or can we from hence be said to be the authors of the miscarriage of the ship, and the loss of the passengers and goods? The fall of Adam was foreseen by God to come to pass by the consent of his free will, in the choice of the proposed temptation. God foreknew Adam would sin, and if Adam would not have sinned, God would have foreknown that he would not sin. Adam might easily have detected the serpent’s fraud, and made a better election; God foresaw that he would not do it; God’s foreknowledge did not make Adam guilty or innocent: whether God had foreknown it or no, he was guilty by a free choice, and a willing neglect of his own duty. Adam knew that God foreknew that he might eat of the fruit, and fall and die, because God had forbidden him; the foreknowledge that he would do it, was no more a cause of his action, than the foreknowledge that he might do it. Judas certainly knew that his Master foreknew that he would betray him, for Christ had acquainted him with it (John xiii. 21, 26); yet he never charged this foreknowledge of Christ with any guilt of his treachery. Prop. III. The holiness of God is not blemished by decreeing the eternal rejection of some men. Reprobation, in its first notion, is an act of preterition, or passing by. A man is not made wicked by the act of God; but it supposeth him wicked; and so it is nothing else but God’s leaving a man in that guilt and filth wherein he beholds him. In its second notion, it is an ordination, not to a crime, but to a punishment (Jude 4): “an ordaining to condemnation.” And though it be an eternal act of God, yet, in order of nature, it follows upon the foresight of the transgression of man, and supposeth the crime. God considers Adam’s revolt, and views the whole mass of his corrupted posterity, and chooses some to reduce to himself by his grace, and leaves others to lie sinking in their ruins. Since all mankind fell by
- 76. the fall of Adam, and have corruption conveyed to them successively by that root, whereof they are branches; all men might justly be left wallowing in that miserable condition to which they are reduced by the apostasy of their common head; and God might have passed by the whole race of man, as well as he did the fallen angels, without any hope of redemption. He was no more bound to restore man, than to restore devils, nor bound to repair the nature of any one son of Adam; and had he dealt with men as he dealt with the devils, they had had, all of them, as little just ground to complain of God; for all men deserved to be left to themselves, for all were concluded under sin; but God calls out some to make monuments of his grace, which is an act of the sovereign mercy of that dominion, whereby “he hath mercy on whom he will have mercy” (Rom. ix. 18); others he passes by, and leaves them remaining in that corruption of nature wherein they were born. If men have a power to dispose of their own goods, without any unrighteousness, why should not God dispose of his own grace, and bestow it upon whom he pleases; since it is a debt to none, but a free gift to any that enjoy it? God is not the cause of sin in this, because his operation about this is negative; it is not an action, but a denial of action, and therefore cannot be the cause of the evil actions of men.911 God acts nothing, but withholds his power; he doth not enlighten their minds, nor incline their wills so powerfully, as to expel their darkness, and root out those evil habits which possess them by nature. God could, if he would, savingly enlighten the minds of all men in the world, and quicken their hearts with a new life by an invincible grace; but in not doing it, there is no positive act of God, but a cessation of action. We may with as much reason say, that God is the cause of all the sinful actions that are committed by the corporation of devils, since their first rebellion, because he leaves them to themselves, and bestows not a new grace upon them,—as say, God is the cause of the sins of those that he overlooks and leaves in that state of guilt wherein he found them. God did not pass by any without the consideration of sin; so that this act of God is not repugnant to his holiness, but conformable to his justice.
- 77. Prop. IV. The holiness of God is not blemished by his secret will to suffer sin to enter into the world. God never willed sin by his preceptive will. It was never founded upon, or produced by any word of his, as the creation was. He never said, Let there be sin under the heaven, as he said, “Let there be water under the heaven.” Nor doth he will it by infusing any habit of it, or stirring up inclinations to it; no, “God tempts no man” (James i. 13). Nor doth he will it by his approving will; it is detestable to him, nor ever can he be otherwise; he cannot approve it either before commission or after. 1. The will of God is in some sort concurrent with sin. He doth not properly will it, but he wills not to hinder it, to which, by his omnipotence, he could put a bar. If he did positively will it, it might be wrought by himself, and so could not be evil. If he did in no sort will it, it would not be committed by his creature; sin entered into the world, either God willing the permission of it, or not willing the permission of it. The latter cannot be said; for then the creature is more powerful than God, and can do that which God will not permit. God can, if he be pleased, banish all sin in a moment out of the world: he could have prevented the revolt of angels, and the fall of man; they did not sin whether he would or no: he might, by his grace, have stepped in the first moment, and made a special impression upon them of the happiness they already possessed, and the misery they would incur by any wicked attempt. He could as well have prevented the sin of the fallen angels, and confirmed them in grace, as of those that continued in their happy state: he might have appeared to man, informed him of the issue of his design, and made secret impressions upon his heart, since he was acquainted with every avenue to his will. God could have kept all sin out of the world, as well as all creatures from breathing in it; he was as well able to bar sin forever out of the world, as to let creatures lie in the womb of nothing, wherein they were first wrapped. To say God doth will sin as he doth other things, is to deny his holiness; to say it entered without anything of his will, is to deny his omnipotence. If he did necessitate Adam to fall, what shall we think of his purity? If Adam did fall without any concern of God’s will in it, what shall we
- 78. say of his sovereignty? The one taints his holiness, and the other clips his power. If it came without anything of his will in it, and he did not foresee it, where is his omniscience? If it entered whether he would or no, where is his omnipotence (Rom. ix. 19)? “Who hath resisted his will?” There cannot be a lustful act in Abimelech, if God will withhold his power (Gen. xx. 6); “I withheld thee:” nor a cursing word in Balaam’s mouth, unless God give power to speak it (Numb. xxii. 38): “Have I now any power at all to say anything? The word that God puts in my mouth, that shall I speak.” As no action could be sinful, if God had not forbidden it; so no sin could be committed, if God did not will to give way to it. 2. God doth not will directly, and by an efficacious will. He doth not directly will it, because he hath prohibited it by his law, which is a discovery of his will: so that if he should directly will sin, and directly prohibit it, he would will good and evil in the same manner, and there would be contradictions in God’s will: to will sin absolutely, is to work it (Ps. cxv. 3): “God hath done whatsoever he pleased.” God cannot absolutely will it, because he cannot work it. God wills good by a positive decree, because he hath decreed to effect it.912 He wills evil by a private decree, because he hath decreed not to give that grace which would certainly prevent it. God doth not will sin simply, for that were to approve it, but he wills it, in order to that good his wisdom will bring forth from it.913 He wills not sin for itself, but for the event. To will sin as sin, or as purely evil, is not in the capacity of a creature, neither of man nor devil. The will of a rational creature cannot will anything but under the appearance of good, of some good in the sin itself, or some good in the issue of it. Much more is this far from God, who, being infinitely good, cannot will evil as evil; and being infinitely knowing, cannot will that for good which is evil.914 Infinite wisdom can be under no error or mistake: to will sin as sin, would be an unanswerable blemish on God; but to will to suffer it in order to good, is the glory of his wisdom; it could never have peeped up its head, unless there had been some decree of God concerning it. And there had been no decree of God concerning it,
- 79. had he not intended to bring good and glory out of it. If God did directly will the discovery of his grace and mercy to the world, he did in some sort will sin, as that without which there could not have been any appearance of mercy in the world; for an innocent creature is not the object of mercy, but a miserable creature: and no rational creature but must be sinful before it be miserable. 3. God wills the permission of sin. He doth not positively will sin, but he positively wills to permit it. And though he doth not approve of sin, yet he approves of that act of his will, whereby he permits it. For since that sin could not enter into the world without some concern of God’s will about it, that act of his will that gave way to it, could not be displeasing to him: God could never be displeased with his own act: “He is not as man, that he should repent” (1 Sam. xv. 29). What God cannot repent of, he cannot but approve of: it is contrary to the blessedness of God to disapprove of, and be displeased with any act of his own will. If he hated any act of his own will, he would hate himself, he would be under a torture: every one that hates his own acts, is under some disturbance and torment for them. That which is permitted by him, is in itself, and in regard of the evil of it, hateful to him: but as the prospect of that good which he aims at in the permission of it is pleasing to him, so that act of his will, whereby he permits it, is ushered in by an approving act of his understanding. Either God approved of the permission, or not; if he did not approve his own act of permission, he could not have decreed an act of permission. It is inconceivable that God should decree such an act which he detested, and positively will that which he hated. Though God hated sin, as being against his holiness, yet he did not hate the permission of sin, as being subservient by the immensity of his wisdom to his own glory. He could never be displeased with that which was the result of his eternal counsel, as this decree of permitting sin was, as well as any other decree, resolved upon in his own breast. For as God acts nothing in time, but what he decreed from eternity, so he permits nothing in time but what he decreed from eternity to permit. To speak properly,
- 80. therefore, God doth not will sin, but he wills the permission of it, and this will to permit is active and positive in God. 4. This act of permission is not a mere and naked permission, but such an one as is attended with a certainty of the event. The decrees of God to make use of the sin of man for the glory of his grace in the mission and passion of his Son, hung upon this entrance of sin. Would it consist with the wisdom of God to decree such great and stupendous things, the event whereof should depend upon an uncertain foundation which he might be mistaken in? God would have sat in counsel from eternity to no purpose, if he had only permitted those things to be done, without any knowledge of the event of this permission. God would not have made such provision for redemption to no purpose, or an uncertain purpose, which would have been, if man had not fallen; or if it had been an uncertainty with God whether he would fall or no. Though the will of God about sin was permissive, yet the will of God about that glory he would promote by the defect of the creature, was positive; and, therefore, he would not suffer so many positive acts of his will to hang upon an uncertain event; and, therefore, he did wisely and righteously order all things to the accomplishment of his great and gracious purposes. 5. This act of permission doth not taint the holiness of God. That there is such an act as permission, is clear in Scripture (Acts xiv. 16): “Who in times past suffered all nations to walk in their own ways.” But that it doth not blemish the holiness of God, will appear, 1st. From the nature of this permission. 1. It is not a moral permission, a giving liberty of toleration by any law to commit sin with impunity; when, what one law did forbid, another law doth leave indifferent to be done or not, as a man sees good in himself. As when there is a law made among men, that no man shall go out of such a city or country without license; to go out without license is a crime by the law; but when that law is repealed by another, that gives liberty for men to go and come at their
- 81. pleasure, it doth not make their going or coming necessary, but leaves those which were before bound, to do as they see good in themselves. Such a permission makes a fact lawful, though not necessary; a man is not obliged to do it, but he is left to his own discretion to do as he pleases, without being chargeable with a crime for doing it. Such a permission there was granted by God to Adam of eating of the fruits of the garden, to choose any of them for food, except the tree of “knowledge of good and evil.” It was a precept to him, not to “eat of the fruit of the tree of knowledge of good and evil;” but the other was a permission, whereby it was lawful for him to feed upon any other that was most agreeable to his appetite: but there is not such a permission in the case of sin; this had been an indulgence of it, which had freed man from any crime, and, consequently, from punishment; because, by such a permission by law, he would have had authority to sin if he pleased. God did not remove the law, which he had before placed as a bar against evil, nor ceased that moral impediment of his threatening: such a permission as this, to make sin lawful or indifferent, had been a blot upon God’s holiness. 2. But this permission of God, in the case of sin, is no more than the not hindering a sinful action, which he could have prevented. It is not so much an action of God, as a suspension of his influence, which might have hindered an evil act, and a forbearing to restrain the faculties of man from sin; it is, properly, the not exerting that efficacy which might change the counsels that are taken, and prevent the action intended; as when one man sees another ready to fall, and can preserve him from falling by reaching out his hand, he permits him to fall, that is, he hinders him not from falling. So God describes his act about Abimelech (Gen. xx. 6); “I withheld thee from sinning against me, therefore suffered I thee not to touch her.” If Abimelech had sinned, he had sinned by God’s permission; that is, by God’s not hindering, or not restraining him by making any impressions upon him. So that permission is only a withholding that help and grace, which, if bestowed, would have been an effectual remedy to prevent a crime; and it is rather a suspension, or
- 82. cessation, than properly a permission, and sin may be said to be committed, not without God’s permission, rather than by his permission. Thus, in the fall of man, God did not hold the reins strict upon Satan, to restrain him from laying the bait, nor restrain Adam from swallowing the bait: he kept to himself that efficacious grace which he might have darted out upon man to prevent his fall. God left Satan to his malice of tempting, and Adam to his liberty of resisting, and his own strength, to use that sufficient grace he had furnished him with, whereby he might have resisted and overcome the temptation. As he did not drive man to it, so he did not secretly restrain him from it. So, in the Jews crucifying our Saviour, God did not imprint upon their minds, by his Spirit, a consideration of the greatness of the crime, and the horror of his justice due to it; and, being without those impediments, they run furiously, of their own accord, to the commission of that evil; as, when a man lets a wolf or dog out upon his prey, he takes off the chain which held them, and they presently act according to their natures.915 In the fall of angels and men, God’s act was leaving them to their own strength; in sins after the fall, it is God’s giving them up to their own corruption; the first is a pure suspension of grace; the other hath the nature of a punishment (Ps. lxxxi. 12): “So I gave them up to their own hearts’ lusts.” The first object of this permissive will of God was to leave angels and men to their liberty, and the use of their free will, which was natural to them,916 not adding that supernatural grace which was necessary, not that they should not at all sin, but that they should infallibly not sin: they had a strength sufficient to avoid sin, but not sufficient infallibly to avoid sin; a grace sufficient to preserve them, but not sufficient to confirm them. 3. Now this permission is not the cause of sin, nor doth blemish the holiness of God. It doth not intrench upon the freedom of men, but supposeth it, establisheth it, and leaves man to it. God acted nothing, but only ceased to act; and therefore could not be the efficient cause of man’s sin. As God is not the author of good, but by willing and effecting it, so he is not the author of evil, but by willing
- 83. and effecting it: but he doth not positively will evil, nor effect it by any efficacy of his own. Permission is no action, nor the cause of that action which is permitted; but the will of that person who is permitted to do such an action is the cause.917 God can no more be said to be the cause of sin, by suffering a creature to act as it will, than he can be said to be the cause of the not being of any creature, by denying it being, and letting it remain nothing; it is not from God that it is nothing, it is nothing in itself. Though God be said to be the cause of creation, yet he is never by any said to be the cause of that nothing which was before creation. This permission of God is not the cause of sin, but the cause of not hindering sin. Man and angels had a physical power of sinning from God, as they were created with freewill, and supported in their natural strength; but the moral power to sin was not from God; he counselled them not to it, laid no obligation upon them to use their natural power for such an end; he only left them to their freedom, and not hindered them in their acting what he was resolved to permit. 2d. The holiness of God is not tainted by this, because he was under no obligation to hinder their commission of sin. Ceasing to act, whereby to prevent a crime or mischief, brings not a person permitting it under guilt, unless where he is under an obligation to prevent it; but God, in regard of his absolute dominion, cannot be charged with any such obligation. One man, that doth not hinder the murder of another, when it is in his power, is guilty of the murder in part; but, it is to be considered, that he is under a tie by nature, as being of the same kind, and being the other’s brother, by a communion of blood, also under an obligation of the law of charity, enacted by the common Sovereign of the world: but what tie was there upon God, since the infinite transcendancy of his nature, and his sovereign dominion, frees him from any such obligation (Job ix. 12)? “If he takes away, who shall say, What dost thou?” God might have prevented the fall of men and angels; he might have confirmed them all in a state of perpetual innocency; but where is the obligation? He had made the creature a debtor to himself, but he owed nothing to the creature. Before God can be charged with any
- 84. guilt in this case, it must be proved, not only that he could, but that he was bound to hinder it. No person can be justly charged with another’s fault, merely for not preventing it, unless he be bound to prevent it; else, not only the first sin of angels and man would be imputed to God, as the Author, but all the sins of men. He could not be obliged by any law, because he had no superior to impose any law upon him; and it will be hard to prove that he was obliged, from his own nature, to prevent the entrance of sin, which he would use as an occasion to declare his own holiness, so transcendent a perfection of his nature, more than ever it could have been manifested by a total exclusion of it, viz. in the death of Christ. He is no more bound, in his own nature, to preserve, by supernatural grace, his creature from falling, after he had framed him with a sufficient strength to stand, than he was obliged, in his own nature, to bring his creature into being when it was nothing. He is not bound to create a rational creature, much less bound to create him with supernatural gifts; though, since God would make a rational creature, he could not but make him with a natural uprightness and rectitude. God did as much for angels and men as became a wise governor: he had published his law, backed it with severe penalties, and the creature wanted not a natural strength to observe and obey it. Had not man power to obey all the precepts of the law, as well as one? How was God bound to give him more grace, since what he had already was enough to shield him, and keep up his resistance against all the power of hell? It had been enough to have pointed his will against the temptation, and he had kept off the force of it. Was there any promise past to Adam of any further grace which he could plead as a tie upon God? No such voluntary limit upon God’s supreme dominion appears upon record. Was anything due to man which he had not? anything promised him which was not performed? What action of debt, then, can the creature bring against God? Indeed, when man began to neglect the light of his own reason, and became inconsiderate of the precept, God might have enlightened his understanding by a special flash, a supernatural beam, and imprinted upon him a particular consideration of the necessity of his obedience, the misery he was approaching to by his sin, the folly of
- 85. any apprehension of an equality in knowledge; he might have convinced him of the falsity of the serpent’s arguments, and uncased to him the venom that lay under those baits. But how doth it appear that God was bound to those additional acts when he had already lighted up in him a “spirit, which was the candle of the Lord” (Prov. xx. 27), whereby he was able to discern all, if he had attended to it. It was enough that God did not necessitate man to sin, did not counsel him to it; that he had given him sufficient warning in the threatening, and sufficient strength in his faculties, to fortify him against temptation. He gave him what was due to him as a creature of his own framing; he withdrew no help from him, that was due to him as a creature, and what was not due he was not bound to impart. Man did not beg preserving grace of God, and God was not bound to offer it, when he was not petitioned for it especially: yet if he had begged it, God having before furnished him sufficiently, might, by the right of his sovereign dominion, have denied it without any impeachment of his holiness and righteousness. Though he would not in such a case have dealt so bountifully with his creature as he might have done, yet he could not have been impleaded, as dealing unrighteously with his creature. The single word that God had already uttered, when he gave him his precept, was enough to oppose against all the devil’s wiles, which tended to invalidate that word: the understanding of man could not imagine that the word of God was vainly spoken; and the very suggestion of the devil, as if the Creator should envy his creature, would have appeared ridiculous, if he had attended to the voice of his own reason. God had done enough for him, and was obliged to do no more, and dealt not unrighteously in leaving him to act according to the principles of his nature. To conclude, if God’s permission of sin were enough to charge it upon God, or if God had been obliged to give Adam supernatural grace, Adam, that had so capacious a brain, could not be without that plea in his mouth, “Lord thou mightest have prevented it; the commission of it by me could not have been without thy permission of it:” or, “Thou hast been wanting to me, as the author of my nature.” No such plea is brought by Adam into the court, when God tried and cast him; no such pleas can have any
- 86. strength in them. Adam had reason enough to know, that there was sufficient reason to overrule such a plea. Since the permission of sin casts no dirt upon the holiness of God, as I think hath been cleared, we may under this head consider two things more. 1. That God’s permission of sin is not so much as his restraint or limitation of it. Since the entrance of the first sin into the world by Adam, God is more a hinderer than a permitter of it. If he hath permitted that which he could have prevented, he prevents a world more, that he might, if he pleased, permit: the hedges about sin are larger than the outlets; they are but a few streams that glide about the world, in comparison of that mighty torrent he dams up both in men and devils. He that understands what a lake of Sodom is in every man’s nature, since the universal infection of human nature, as the apostle describes it (Rom. iii. 9, 10, c.), must acknowledge, that if God should cast the reins upon the necks of sinful men, they would run into thousands of abominable crimes, more than they do: the impression of all natural laws would be rased out, the world would be a public stew, and a more bloody slaughter house; human society would sink into a chaos; no starlight of commendable morality would be seen in it; the world would be no longer an earth, but an hell, and have lain deeper in wickedness than it doth. If God did not limit sin, as he doth the sea, and put bars to the waves of the heart, as well as those of the waters, and say of them, “Hitherto you shall go, and no further;” man hath such a furious ocean in him, as would overflow the banks; and where it makes a breach in one place, it would in a thousand, if God should suffer it to act according to its impetuous current. As the devil hath lust enough to destroy all mankind, if God did not bridle him; deal with every man as he did with Job, ruin their comforts, and deform their bodies with scabs; infect religion with a thousand more errors; fling disorders into commonwealths, and make them as a fiery furnace, full of nothing but flame; if he were not chained by that powerful arm, that might let him loose to fulfil his malicious fury; what rapines, murders,
- 87. thefts, would be committed, if he did not stint him! Abimelech would not only lust after Sarah, but deflour her; Laban not only pursue Jacob, but rifle him; Saul not only hate David, but murder him; David not only threaten Nabal, but root him up, and his family, did not God girdle in the wrath of man:918 a greater remainder of wrath is pent in, than flames out, which yet swells for an outlet. God may be concluded more holy in preventing men’s sins, than the author of sin in permitting some; since, were it not for his restraints by the pull‑back of conscience, and infused motions and outward impediments, the world would swarm more with this cursed brood. 2. His permission of sin is in order to his own glory, and a greater good. It is no reflection upon the Divine goodness to leave man to his own conduct, whereby such a deformity as sin sets foot in the world; since he makes his wisdom illustrious in bringing good out of evil, and a good greater than that evil he suffered to spring up.919 God did not permit sin, as sin, or permit it barely for itself. As sin is not lovely in its own nature, so neither is the permission of sin intrinsically good or amiable for itself, but for those ends aimed at in the permission of it. God permitted sin, but approved not of the object of that permission, sin; because that, considered in its own nature, is solely evil: nor can we think that God could approve of the act of permission, considered only in itself as an act; but as it respected that event which his wisdom would order by it. We cannot suppose that God should permit sin, but for some great and glorious end: for it is the manifestation of his own glorious perfections he intends in all the acts of his will (Prov. xvi. 4), “The Lord hath made all things for himself”—פעל hath wrought all things; which is not only his act of creation, but ordination: “for himself,” that is, for the discovery of the excellency of his nature, and the communication of himself to his creature. Sin indeed, in its own nature, hath no tendency to a good end; the womb of it teems with nothing but monsters; it is a spurn at God’s sovereignty, and a slight of his goodness: it both deforms and torments the person that acts it; it is black and abominable, and hath not a mite of goodness in the
- 88. nature of it. If it ends in any good, it is only from that Infinite transcendency of skill, that can bring good out of evil, as well as light out of darkness. Therefore God did not permit it as sin, but as it was an occasion for the manifestation of his own glory. Though the goodness of God would have appeared in the preservation of the world, as well as it did in the creation of it, yet his mercy could not have appeared without the entrance of sin, because the object of mercy is a miserable creature; but man could not be miserable as long as he remained innocent. The reign of sin opened a door for the reign and triumph of grace (Rom. v. 21), “As sin hath reigned unto death, so might grace reign through righteousness to eternal life;” without it, the bowels of mercy had never sounded, and the ravishing music of Divine grace could never have been heard by the creature. Mercy, which renders God so amiable, could never else have beamed out to the world. Angels and men upon this occasion beheld the stirrings of Divine grace, and the tenderness of Divine nature, and the glory of the Divine persons in their several functions about the redemption of man, which had else been a spring shut up, and a fountain sealed; the song of glory to God, and good will to men in a way of redemption had never been sung by them. It appears in his dealing with Adam, that he permitted his fall, not only to show his justice in punishing, but principally his mercy in rescuing; since he proclaims to him first the promise of a Redeemer to “bruise the serpent’s head,” before he settled the punishment he should smart under in the world (Gen. iii. 15‒17). And what fairer prospect could the creature have of the holiness of God, and his hatred of sin, than in the edge of that sword of justice, which punished it in the sinner; but glittered more in the punishment of a Surety so near allied to him? Had not man been criminal, he could not have been punishable, nor any been punishable for him: and the pulse of Divine holiness could not have beaten so quick, and been so visible, without an exercise of his vindicative justice. He left man’s mutable nature, to fall under righteousness, that thereby he might commend the righteousness of his own nature (Rom. iii. 7). Adam’s sin in its nature tended to the ruin of the world, and God takes an occasion from it for the glory of his grace in the redemption of the
- 89. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com