1

Autonomic Computing Systems: Issues and Challenges

Mohammad Reza Nami, Koen Bertels, Stamatis Vassiliadis
Computer Engineering Laboratory
Faculty of Electrical Engineering, Mathematics, and Computer Science
Technical University of Delft
The Netherlands
{nami,koen,stamatis}@ce.et.tudelft.nl
Abstract Nowadays, IT organizations have encountered growing
challenges in the management and maintenance of large scale heterogeneous distributed computing systems because these systems attempt
to be active and available at all hours. Moreover, current programming languages, methods, and management tools are inadequate to handle complexity, scale, dynamism, heterogeneity, and uncertainty as the
most important challenges in such systems. Therefore, researchers investigate new ideas to address the problems created by IT complexity. One
such idea is Autonomic Computing (AC). Autonomic Computing Systems (ACSs) are systems that manage themselves. This paper provides a
thorough survey of autonomic computing systems, presenting their definitions, their characteristics and effects on quality factors, their architecture, issues, and challenges.
Keywords: Agent, Multi-agent Systems (MASs), Autonomic Computing Systems, Self-managing Systems.

I. Introduction
Data and programs in centralized applications are kept
at one site and this creates a bottleneck in performance
and availability of information in remote desktop computers. Distributed systems have emerged to remove this
flaw. Advances in communication technology, especially
the Internet and increasing desktops power, have helped
distributed computing systems. Distributed Computing
Systems (DCSs) [31] consist of different computers connected to each other and located at geographically remote
sites. Several flavours emerged such as Peer-to-Peer (P2P)
Computing [21], agents [36], and grid computing [24]. The
complexity of these systems has revolutionized their management. Today, IT organizations have encountered growing challenges in the management and maintenance of large
scale heterogeneous distributed computing systems because
these systems have to be active and available at all hours.
Therefore, it is difficult for administrators to manage such
systems and handle changes occured at all hours and IT operators may also make mistakes in their work. IT managers
look for ways to improve the Return On Investment (ROI)
by reducing Total Cost of Ownership (TCO), increasing
Quality of Services (QoSs), and decreasing the cost of managing IT. It seems that existing management methods and
tools are inadequate to handle the complexity, heterogenity, uncertainty, dynamism, and scale of today s and future
information systems. Furthermore, such systems will become too complex and large-scale for skilled persons who
install, optimize, protect, and maintain them. Research by
the university of California shows that almost half of the
total budget is spent to prevent and recover systems from
crashes [26]. Another study [19] shows that 25 to 50 percent of IT resources are spent on problem determination
and according to IBM studies, in the 1990s, approximately

80 percent of the cost of major computer systems revolved

around harware and software acquisitions [13]. Daniel J.
Clancy, chief of the Computational Sciences Division at
NASA Ames Research Center, believes that with increasing complexity, 40 percent of his groups software work is
devoted to test the exponentially growing system behavior [6]. As a consequence, we need systems which address
these problems, work independently of humans, and manage themselves according to a set of goals. One new idea
to cope with the complexity is Autonomic Computing [10].
The vision of Autonomic Computing [16] is to improve
the management of complex IT systems by introducing selfmanagement systems [12] for configuration, protection, optimization, and healing purposes. Multiple interacting Autonomic Elements (AEs) form the building blocks of ACSs.
Major characteristics of an ACS are self-Configuration,
self-Healing, self-Optimization, and self-Protection, called
self-CHOP [14] [8] [13]. These systems monitor data sensed
by sensors, analyse them, and adjust their operations according to policies, thus reducing complexity. Some benefits of autonomic computing include reduction of costs and
errors, improvement of services, and reduction of complexity. Sun, Microsoft, and IBM have introduced products
that support certain aspects of autonomic computing development. IBM as one of the pioneers in autonomic computing, has software development tools for building their
autonomic softwares. Some vendors have been outlined in
[20] in terms of their developed software type.
This paper is organized as follows. Section 2 describes
what ACSs are including a survey of their definitions, their
characteristics, and their effects on quality factors. In section 3, building blocks of an ACS are introduced. Software
architectures for autonomic computing are also presented.
Section 4 discusses some issues and challenges in this field
such as robustness and relationships among AEs. Section
5 presents an overview of related work about role of ACSs
and research carried out in this field. Finally, conclusions
and further works are presented.
II. Autonomic Computing (AC): Overview
This section presents an overview of Autonomic Computing Systems (ACSs) and initial concepts about their
definitions and their characteristics are discussed.
A. AC Definitions and Characteristics
The autonomic computing initiative is inspired by the
human body s autonomic nervous system [9]. The human

538

body has good mechanisms for repairing physical damages.

It is able to effectively monitor, control, and regulate the
human body without external intervention. An autonomic
system provides these facilities for a large-scale complex
heterogeneous system. An ACS is a system that manages
itself. This definition shows that AC is emerging as an approach to the design, developement, and management of
large-scale distributed computing systems. According to
Paul Horn s definition [13], an ACS is a self-management
system with eight elements. Self-configuration means that
an ACS must dynamically configure and reconfigure itself under changing conditions. Self-healing means that
an ACS must detect failed components and eliminate or
replace it with another component without disrupting the
system. On the other hand, it must predict problems and
prevent failures. Self-optimization is the capability of maximizing resource allocation and utilization for satisfying
user requests. Resource utilization and work load management are two significant issues in self-optimization. An
ACS must identify and detect attacks and cover all aspects
of system security at different levels such as the platform,
operating system, applications, etc. It must also predict
problems based on sensor reports and attempt to avoid
them. It is called self-protection. An ACS needs to know
itself. It must be aware of its components, current status,
and available resources. It must also know which resources
can be borrowed or lent by it and which resources can be
shared. It is self-awareness or self-knowledge property. An
ACS must be also aware of the execution environment to
react to environmental changes such as new policies. It is
called context-awareness or environment-awareness. Openness means that an ACS must operate in a heterogeneous
environment and must be portable across multiple platforms. Finally, an ACS can anticipate its optimal required
resources while hiding its complexity from the end user
view and attempts to satisfy user requests. We consider
self-configuration, self-healing, self-optimization, and selfprotection as major characteristics and the rest as minor
characteristics.
[35] defines decentralized autonomic computing systems
as systems that are constructed as a group of locally interacting autonomous entities that cooperate in order to
adaptively maintain the desired system-wide self-* properties without any external or internal control. For these
systems, implications and interpretation of decentralization
on self-* properties can be grand challenges.
B. Relationships between Characteristics and Quality Factors
As mentioned before, the aim of Autonomic Computing (AC) is to improve the system abilities. The design
and implementation of ACSs that dynamically support selfmanaging operations such as finding an autonomic element,
optimization, and configuration, can affect various measurements of the system quality and become a solution
to satisfy requirements in different aspects such as performance and security. Table 1 specifies the relationships
between autonomic computing properties and quality factors.

Characteristics
Self-configuration
Self-healing
Self-optimization
Self-protection
Self-awareness
Openness
Context-awareness
Anticipatory

Metrics
Maintainability, Usability, Functionality, and Portabil
Reliability and Maintainability
Efficiency, Maintainability, and Functionality
Reliability and Functionality
Functionality
Portability
Functionality
Efficiency and Maintainability

TABLE I
Relationships Between Autonomic Computig Properties and
Quality factors

III. Autonomic Computing Architecture

In this section, we express how ACSs can be built. We
describe the necessary elements and set of tools that provide the basic structure for an ACS. Software architectures
for AC are also explained.
A. Autonomic Element Architecture
AEs are the basic building blocks of autonomic systems and their interactions produce self-managing behavior. There is a generic architecture for AEs that is showed
in figure 1. The IBM autonomic blueprint [9] considers
that each AE has two parts Managed Elements (ME) and
Autonomic Manager (AM). In fact, ACSs are established
from ME whose behaviors are controlled by AMs. A ME is
a component from a system. It can be hardware, application software, or an entire system. Each ME must include
sensors and effectors [8]. Sensors sense and retrieve information about the current state of the ME, then compare
it with expectations that are held in knowledge base by
the AE. The required action is executed by effectors. An
AM uses manageability interface to monitor and control
the ME. Each AM has four parts: monitor, analyze, plan,
and execute. Monitor part provides mechanisms to collect
information from a ME, monitor it (data sensed by sensor), and manage it. Monitored data is analyzed. It helps
the AM to predict future status. The plan part assigns
tasks and resources based on the policies [1]. Policies can
be a set of administrator comments. They are stored as
knowledge to guide the AM. The AMs can change resource
allocation to optimize performance according to policies.
Finally, the execute part controls the execution of a plan
and dispatches recommended actions into the ME. These
four parts with sensors and effectors provide a control loop
to create self-managing. AEs communicate with each other
and react to environmental changes according to predefined
policies for developing a self-managing system. Negotiation
[16] and trust [4] are two grand challenge in relationships
between them. Negotiation should establish contracts for
relationships between AEs and trust among AEs is important becuase they must provision their internal resources
after reaching an agreement.
A.1 Some views about Autonomic Element
In [37], the authors assume that each management unit
(AM) is comprised of six components: (1) Transmit Ser-

539

Fig. 2. An agent in architecture of tightly-coupled autonomic systems

Fig. 1. A generic AE architecture

struct a reference autonomic manager.

B. Software Architectures for Autonomic Computing

vice Component (TSC) for exchanging messages with other

AMs, (2) Heartbeat Monitoring Component (HMC) for
testing validity, integrity, and avaiability of AM with send
ing out heartbeats and listening remote heartbeats, (3)
Resource Discovery Component (RDC) for generating and
finding the best set of candidate resources for the request,
(4) Service Management Component (SMC) for keeping
service lists provided by the AE while checking the validity of these services periodically, (5) Hardware Utilization
Monitoing Component (HUMC) for monitoring the hardware state and examining hardware utilization such as CPU
speed, and (6) Decision-Making Component (DMC) for independently making decisions according to rules and policies. In this view of an AE, relationships between AEs
is saimilar to what mentioned before, but details of the
relationships are performed and examined by these components. For example, if an AE wants to send message
to another agent, it should send a request for communication to TSC. These components can communicate with
together. For example, if SMC finds that a service is not
valid, it reports invalidity to DMC for analysis and if it
is necessary, the DMC can send reports about it to other
AEs via TSC. If HMC does not listen any heartbeat from
an agent, the HMC reports it to RDC to find a substitute
for that agent.
In [7], a research project in Intel s Research Lab is described that focuses on exploring the nature and value of
providing platform support for AC. Architectural components (AEs) of the platform consist of four layers: (1) Sensors and effectors, (2) Unified Sensor-Effector Abstraction
layer to abstract and uniform received information and
present them to higher layers, (3) Data Monitoring and
Fusion layer to preprocess data and provide functions such
as alert notification, and (4) Policy creation and execution
(authoring tool) after evaluation of the sensed data by the
autonomic manager. The authors choices Linux as their
operating system and present initial phase of this project
with providing a software abstraction interface to connect
sensor information with an authoring tool for autonomic
and policy-based management. Their future work is to con-

The activities in software field are categorized into four

groups: monitoring components, analysing monitored data
related to the components, creating a plan for adaptation
and repair, and executing the plan. McCann et al [20] have
identified two categories of the approaches to ACSs: tightly
coupled and decoupled autonomic systems. The former is
built by using intelligent agents. Autonomic computing
and software agent technology are viewed as new technologies to solve these bottlenecks and enhance the design, implementation, and the management of complex distributed
systems [3]. In decomposed autonomic systems, an infrastructure handles the autonomic behavior of the system.
B.1 Tightly-coupled Autonomic Systems
Tightly-coupled autonomic systems are built by using
intelligent agents (AEs). The agents have autonomous behavior and make decisions according to predefined policies.
Each change in behavior of an agent can create instabilities in the entire system, because that agent can affect
other agents. Other problem is to define individual goals
of agents to achieve the system goals. In this architecture, agents should determine their desirable behavior own
themselves to reach the system goals. Internal monitoring
and external monitoring are also discussed in this software
architecture. In fact, without centralized monitoring system, each agent should monitor itself (internal monitor )
and also other agents (external monitor ). R. Sterritt and
D. Bustard [30] have proposed a heartbeat or pulse monitor
for monitoring the state of AEs in an autonomous component domain. The heartbeat of each AE (agent) is sent to
an autonomic signal channel that other AEs listen or send
on it. As this channel connects AEs located from different networked phisical systems, external monitoring may
emerge a lot of traffic on the channel (Figure 2).
B.2 Loosely-coupled Autonomic Systems
In this approach, individual components of the system
are not autonomic but an autonomic infrastructure that
is separated from the running system handles the autonomic behavior of the system. The autonomic infrastruc-

540

Fig. 3. Architecture of loosely-coupled autonomic systems

ture runs on another machine, therby, we called this approach as loosely-coupled. This approach is also an architecture model-based because the autonomic infrastructure
uses an architecture model of the running system for desiging the system. Components and their connections are
evaluated with a list of properties and constraints in the autonomic infrastructure. The running system is monitored,
its data is collected and mapped to the architecture model.
The architecture model may be updated based on current
status of the running system. Then, the architecture model
is analysed and if the system needs adaptation or repair,
appropriate plan is executed. The use of knowledge of past
successful plans improves decision about adaptation. The
plan descibes which components must be removed or which
components must be inserted. An advantage of the complete separation of autonomic behavior and the running
system is that software adaptation can be plugged into a
pre-existing system [32]. Since this approach is centralized,
problems related to centralized systems such as failure in
the central architecture manager affect performance of the
system. Therefore, fault management must be considered
in the infrastructure and individual components. Figure
3 (based on the figure from [20]) shows a diagram of a
loosely-coupled autonomic system.
IV. Challenges and Issues
Since autonomic computing is a new concept in largescale heterogeneous systems, there are different challenges
and issues. Some of them are explained in the following:
A. Applying Agent-Oriented Paradigm
As discussed in [16] and [13], agent-based technology,
grid computing, and software engineering methodologies
are research areas that can help researchers to achieve the
aims of AC. An outstanding property of software agent
is autonomy. An agent not only reacts to environmental changes but also acts autonomously. Software agents
can be viewed as autonomic elements and this means that
agent-oriented architecture can help for the implementation of self-management. For example, Rudder [17] is a decentralized scalable agent-based composition infrastructure
that addresses the development of autonomic grid applications, focusing on the dynamic selection and composition
of autonomic elements and negotiation between them to
execute self-managing behaviors. Rudder consists of three
types of context-aware software agents including Component Agents (CAs), System Agents (SAs), and Composi-

tion Agents (CSAs). CAs dynamically and locally configure and manage autonomic components. SAs are embedded within resources such as CPU to monitor, schedule, and optimize their utilization with dynamically workload balancing. CSAs define rules based on application
requirements to choose an enacted workflow plan and insert rules into the tuple-space as reactive rules. They dynamically search and select the appropriate registered autonomic components and resources according to goals and
requirements of the application. These agents interact with
each other and scalable tuple-space provides the coordination for their interactions. Self-management is provided
with software agents, tuple-space, and composition rules.
B. Component-Based approach for Developing Autonomic
Computing Systems
Hot swapping [2] is a component-based technique to develop self-management systems by either replacing codes
(components) with same functionality or inserting a new
code (component) between two existing component. The
stages include terminating a component that should be replaced, suspending components and connections related on
this component, adding a new component that is determined according to a repair plan, establishing the relationships between new components and suspended components and connections, reconfiguring the system. Although
adaptation is established into the system, but the system
needs extra time to load a new component and link it to
the system, thereby, overhead increases. Another research
themes has been introduced to address self-management at
the level of middlewares and frameworks such as dynamic
composition [25] and smart components. Smart components are used to adapt to environmental changes and support self-management. Composition formalisms help to automate generation of global configuration by considering
certain constraints and/or optimization criteria [29].
C. Issues in Relationships among AEs
Relationships among AEs have a key role in implementing self-management. These relationships have a life cycle
consisting of specification, location, negotiation, provision,
operation, and termination stages. Each stage has its own
challenges [16]. Challenges in specification include lack of
the establishment of the syntax and semantics of standard
services for AEs, because AEs should interact together and
use from their services. Moreover, an AE must dynamically locate input services that it needs and other AEs
that need its output services must dynamically locate this
element with looking it up. Therefore, AE reliability can
be a research area. AEs also need protocols and strategies
to establish rules of negotiation and to manage the flow of
messages among the negotiators. One of these challenges
is to develop and analyze negotiation algorithms and protocols, then determine which negotiation algorithm can be
effective. After negotiation and reaching to an agreement,
how both agreed AEs provision their resources in an important issue. An AE can provide agreed service itself or
other elements can help it in providing part of agreed service. This is a research area. Automated provision can

541

also be a research area for this stage. After agreement, the

AMs of both AEs control the operation. If the agreement
is violated, different solutions can be introduced. This can
be a research area. Finally, after both AEs agree to terminate the negotiated agreement, the procedure should be
clarified.

of trust can be introduced into a system by assigning an

instantaneous trust index to each execution of an AM and
an overall trust index that reflects the level of trust of an
administrator in that AM [4].

V. Related Work

D. Learning and Optimization Theory

One of questions in ACSs is how can we transfer the management system knowledge from human experts to ACSs?
In more sophisticated autonomic systems, individual elements will be agents that continually adapt to their environment that consists largely of other agents [16]. These
agents must learn to solve problems based on their past experiences. Therefore, the use of Artificial Intelligence (AI)
and machine learning techniques can help them in how a
problem to be solved on different systems by several human experts and the knowledge acquisition from the human experts. Designing a robust learning procedure that
is automatically performed on a new system can be a research area. Optimization can be also a challenge because
in such systems, agents adapting in a dynamic environment
are changing their behavior to reach optimization. The optimization is examined at AE level.
E. Robustness
Robustness has been used in various sciences and systems such as ecology, engineering, and social systems. We
can interpret it as stability, reliability, survivability, and
fault-tolerance, although it does not mean all of these. Robustness is the ability of a system to maintain its functions
in an active state, and persist when changes occur in internal structure of the system or external environment. Robustness may be defined stability. Although both stability
and robustness focus on persistence, robustness is broader
than stability [15]. It is possible that components of a system are not themselves robust, but interconnections among
them make robustness at the system level. A robust system
can perform multiple functionalities for resistance, without
change in the structure. With the design of instructions
that permit systems to preserve their identity even when
they are disrupted, the robustness in systems can be increased. Robustness is one of grand scientific challenges in
the development of ACSs.
F. Trust
Trust among AEs can be one of important issues in the
relationships between them and affects ACS functionality.
It means that one AE expects other AEs to reliably perform
their tasks to provide their agreed services to achieve the
goal. Trust Parameters (TPs) can be defined as the basis
of trust management such as customer response time as an
optimization TP. We can categorize TPs in configuration,
healing, protection, and optimization. Trust requirements
include identifying and selecting TPs, aggregating them,
assigning trust values to AMs into each AE, and managing
trust in communcation of AEs. In an AE, trust can be
built according to result of examining the history of past
performance information recorded in the AE. The concept

On March 8, 2001, Paul Horn presented a link between

pervasiveness and self-regulation in body s autonomic nervous system and introduced ACSs to the National Academy
of Engineering at Harvard University. With choosing the
term autonomic, researchers attempted to make autonomic
capabilities in computer systems with the aim of decreasing
the cost of developing and managing them. [18] presents
a standard and quantitative definition of AC according to
quality mertics frameworks described in IEEE Std 10611998. It also represents a quality metrics framework for
AC that contains three layers, openness and anticipatory
at first layer, self-awareness, context-awareness, and selfmanagement as subsets of anticipatory at second layer, and
self-CHOP as subsets of self-management at third layer.
S. White et al in [34], and R. Sterritt and D. Bustard in
[30] have described some general architecture for ACSs and
their necessary elements called Autonomic Elements (AEs).
One of problems in implementation of ACSs is how parts
of applications are connected, how they interoperate, and
how components developed by different technologies are
simply integrated. Middleware, as systems software that
locates between applications and low-level hardware and
software infrastructure, is served as a solution for above
problems. Common Object Request Broker Architecture
(CORBA) [23] and Enterprise JavaBeans [22] are common
middlewares. Although the CORBA Component Model
as a common model specifies components for distributed
software systems, but some limitations mentioned in [33],
make it inappropriate for use in autonomic environments.
Middleware has been emphasized for three reasons: (1)
Encapsulation of capabilities for the management of computing resources instead of distributed operating systems,
(2) Implementation of more functions that are usable in
a specific application domain such as telecommunication,
and (3) Ability to monitor, analyse, and control the state
and behavior at runtime itself. Third property is related
to autonomic computing middlewares that perform reasoning and decision making themselves. Some work on autonomic middleware can be found at [27] [28]. J. A. McCann
and M. C. Huebscher in [20] have proposed some metrics
to evaluate ACSs such as adaptability. Some performance
factors such as security and performance have been discussed by others [5] [11]. The most important challenges
in engineering and science such as robustness and relationships among AEs have been discussed in [16]. Different
projects and products have been developed both by the
industry and the academia. M. Salehie and L. Tahvildari
have outlined some of these products in [29]. Finally, the
last information about autonomic computing can be found
in http://www-03.ibm.com/autonomic/.

542

VI. Conclusion
Current programming languages, methods, and management tools are not adequate to handle the complexity, scale, dynamism, heterogeneity, and uncertainty. Autonomic Computing has gained world attention in recent
years for the reason of developing applications with selfmanaging behavior. Automatic computing is a grand challenge that requires advances in several fields such as software architecture, learning and reasoning, modelling behavior, policies, multi-agent systems, and knowledge base
design. In this paper, a survey of autonomic computing systems, their importance, their architectures, and some challenges was presented. The lifecycle of relationships between
AEs, learning, and robustness express some challenges in
ACSs. Issues about applying agent-oriented paradigm and
component-based development and management was also
described.
References
[1]

[2]
[3]

[4]

[5]
[6]
[7]

[8]
[9]
[10]

[11]
[12]
[13]

[14]

[15]
[16]

R. J. Anthony. A Policy-Definition Language and Prototype

Implementation Library for Policy-based Autonomic Systems.
In IEEE International Conference on Autonomic Computing
(ICAC 06), pages 265276, June 2006.
J. Appavoo and et al. Enabling autonomic behavior in systems software with hot swapping. In IBM Systems Journal,
volume 42, pages 6076, January 2003.
W. Chainbi. Why Applying Agent Technology to Autonomic
Computing? In Self-Organization and Autonomic Informatics
(I), edited by Hans Czap, Rainer Unland, Cherif Branki, Huaglory Tianfield, volume 135, pages 17, 2005.
H. Chan, A. Segal, B. Arnold, and I. Whalley. How Can We
Trust an Autonomic System to Make the Best Decision? In Second International Conference on Autonomic Computing (ICAC
05), pages 351352, June 2005.
D. M. Chess, C. Palmer, and S. R. White. Security in an autonomic computing environment. In IBM System Journal, volume 42, pages 107118, January 2003.
D. J. Clancy. NASA Challenges in Autonomic Computing. In
Almaden Institute, IBM Almaden Research Center, San Jose,
CA, April 2002.
L. M. Durham, M. Milenkovic, and P. Cayton. Platform Support
for Autonomic Computing: a Research Vehicle. In IEEE International Conference on Autonomic Computing (ICAC 06),
pages 293294, June 2006.
A. G. Ganek and T. A. Corbi. The dawning of the autonomic
computing era. In IBM System Journal, volume 42, pages 518,
January 2003.
IBM Group. An architectural blueprint for autonomic computing. In http://www-03.ibm.com/autonomic/pdfs/AC, June 2005.
S. Hariri and et al. The Autonomic Computing Paradigm.
In Cluster Computing: The Journal of Networks, Software
Tools, and Applications, Springer Science+Business Media
B.V. (Kluwer Academic Publishers), volume 9, pages 517, 2006.
S. Hariri and M. Parashar. Autonomic Computing: An overview.
In Springer-Verlag Berlin Heidelberg, pages 247259, July 2005.
M. G. Hinchey and R. Sterritt. Self-managing software. In Computer, Published by IEEE Computer Society, volume 39, pages
107109, February 2006.
P. Horn.
Autonomic Computing:
IBM s perspective on the State of Information Technology.
In www1.ibm.com/industries/government/doc/content/bin/auto.pdf,
October 2001.
M. Jarrett and R. Seviora. Constructing an Autonomic Computing Infrastructure Using Cougaar. In Proceedings of the Third
IEEE International Workshop on Engineering of Autonomic
and Autonomous Systems (EASe 2006), pages 119128, March
2006.
E. Jen. Stable or Robust? Whats the Difference?
In
http://www.santafe.edu/ erica/stable.pdf, 2002.
J. O. Kephart and D. M. Chess. The vision of autonomic computing. In IEEE Computer, volume 36, pages 4150, January
2003.

[17] Z. Li and M. Parashar. Rudder: A Rule-Based Multi-Agent

Infrastructure for Supporting Autonomic Grid Applications.
In First International Conference on Autonomic Computing
(ICAC04), New York, NY, pages 278279, May 2004.
[18] P. Lin, A. MacArthur, and J. Leaney. Defining Autonomic computing: A software engineering perspective. In Australian Software Engineering Conference (ASWEC05), 2005.
[19] M. Loughran and K. Gibbons. IBM and Cisco Unveil Innovative
Approach Toward a Self-Healing Infrastructure. In http://www03.ibm.com/autonomic/, October 2003.
[20] J. A. McCann and M. C. Huebscher. Evaluation issues in autonomic computing. In Proceedings of Grid and Cooperative
Computing workshop(GCC), volume 15, pages 597608, October 2004.
[21] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja,
J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-Peer Computing. In Proceedings of the Second International Conference
on Peer-to-Peer Computing, pages 151, July 2002.
[22] Shin Nakajima and Tetsuo Tamai. Behavioural Analysis of the
Enterprise JavaBeans Component Architecture. In Lecture Notes
in Computer Science, volume 2057, pages 163182, 2001.
[23] Object Management Group (OMG). Common Object Broker Resource Architecture (CORBA).
In Available at:
http://www.corba.org.
[24] M. Parashar, Z. Li, H. Liu, V. Matossian, and C. Schmidt. AutoMate: Enabling Autonomic Grid Applications: Requirements,
Models and Infrastructures. In Self-Star Properties in Complex Information Systems, Lecture Notes in Computer Science,
Springer Verlag, volume 3460, 2005.
[25] E. Patouni and N. Alonistioti. A Framework for the Deployment
of Self-Managing and Self-Configuring Components in Autonomic Environments. In International Symposium on a World of
Wireless, Mobile and Multimedia Networks (WoWMoM 2006),
pages 480484, June 2006.
[26] D. Patterson and et al. Recovery Oriented Computing (ROC):
Motivation, Definition, Techniques, and Case studies.
In
roc.cs.berkeley.edu/papers/, 2002.
[27] G. Rimassa, D. Greenwood, and M. E. Kernland. The Living
Systems Technology Suite: An Autonomous Middleware for Autonomic Computing. In International Conference on Autonomic
and Autonomous Systems (ICAS06), Silicon Valley, USA), July
2006.
[28] A. Sajjad and et al. AutoMAGI-an Autonomic middleware for
enabling Mobile Access to Grid Infrastructure. In Proceedings of
Joint International Conference on Autonomic and Autonomous
Systems and International Conference on Networking and Services (ICAS/ICNS), pages 7378, October 2005.
[29] M. Salehie and L. Tahvildari. Autonomic Computing: emerging
trends and open problems. In ACM SIGSOFT Software Engineering Notes, volume 30, pages 17, July 2005.
[30] R. Sterritt and D. Bustard. Towards an autonomic computing environment. In 14th International Workshop on Database
and Expert Systems Applications (DEXA 03), pages 694698,
September 2003.
[31] A. Umar. Distributed computing: A practical synthesis. In
Prentice-Hall, pages 422:293312:349356, 1993.
[32] G. Valetto and G. Kaiser. A case study in software adaptation.
In ACM Workshop on Self-Healing Systems (WOSS 02), pages
7378, November 2002.
[33] N. Wang, D. C. Schmidt, and C. ORyan. Overview of the corba
component model. In Component-Based Software Engineering,
Editors G. Heineman and B. Councill, Addison-Wesley, 2000.
[34] S. White and et al. An architectural approach to autonomic computing. In Proceedings the International Conference on Autonomic Computing (ICAC04), NewYork, USA, pages 29, May
2004.
[35] T. De Wolf and T. Holvoet. Evaluation and comparison of decentralised autonomic computing systems. In Department of Computer Science, K.U.Leuven, Report CW 437, Leuven, Belgium,
March 2006.
[36] M. Wooldridge and N. R. Jennings. Agent Theories, Architectures, and Languages: A Survey. In ECAI Workshop on Agent
Theories, Architectures, and Languages, volume 890, pages 1
39, August 1994.
[37] Y. Zhang, J. Sun, and H. Ma. Self-management model based on
multiagent and worm techniques. In Canadian Conference on
Electrical and Computer Engineering, volume 1, pages 397400,
May 2004.

543