Autonomic Computing Systems - Issues and Challenges

8/21/2019 Autonomic Computing Systems - Issues and Challenges

http://slidepdf.com/reader/full/autonomic-computing-systems-issues-and-challenges 1/6

1

Autonomic Computing Systems: Issues and Challenges

Mohammad Reza Nami, Koen Bertels, Stamatis VassiliadisComputer 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 growingchallenges in the management and maintenance of large scale hetero-geneous distributed computing systems because these systems attemptto be active and available at all hours. Moreover, current program-ming languages, methods, and management tools are inadequate to han-

dle complexity, scale, dynamism, heterogeneity, and uncertainty as themost important challenges in such systems. Therefore, researchers inves-tigate new ideas to address the problems created by IT complexity. Onesuch idea is Autonomic Computing (AC). Autonomic Computing Sys-tems (ACSs) are systems that manage themselves. This paper provides athorough survey of autonomic computing systems, presenting their defi-nitions, their characteristics and effects on quality factors, their architec-ture, issues, and challenges.

Keywords: Agent, Multi-agent Systems (MASs), Autonomic Com-puting Systems, Self-managing Systems.

I. Introduction

Data and programs in centralized applications are keptat one site and this creates a bottleneck in performance

and availability of information in remote desktop comput-ers. Distributed systems have emerged to remove thisflaw. Advances in communication technology, especiallythe Internet and increasing desktops power, have helpeddistributed computing systems. Distributed ComputingSystems (DCSs) [31] consist of different computers con-nected to each other and located at geographically remotesites. Several flavours emerged such as Peer-to-Peer (P2P)Computing [21], agents [36], and grid computing [24]. Thecomplexity of these systems has revolutionized their man-agement. Today, IT organizations have encountered grow-ing challenges in the management and maintenance of largescale heterogeneous distributed computing systems because

these systems have to be active and available at all hours.Therefore, it is difficult for administrators to manage suchsystems and handle changes occured at all hours and IT op-erators may also make mistakes in their work. IT managerslook for ways to improve the Return On Investment (ROI)by reducing Total Cost of Ownership (TCO), increasingQuality of Services (QoSs), and decreasing the cost of man-aging IT. It seems that existing management methods andtools are inadequate to handle the complexity, heterogen-ity, uncertainty, dynamism, and scale of today ’s and futureinformation systems. Furthermore, such systems will be-come too complex and large-scale for skilled persons who

install, optimize, protect, and maintain them. Research bythe university of California shows that almost half of thetotal budget is spent to prevent and recover systems fromcrashes [26]. Another study [19] shows that 25 to 50 per-cent of IT resources are spent on problem determinationand according to IBM studies, in the 1990s, approximately

80 percent of the cost of major computer systems revolvedaround harware and software acquisitions [13]. Daniel J.Clancy, chief of the Computational Sciences Division atNASA Ames Research Center, believes that with increas-

ing complexity, 40 percent of his group’s software work isdevoted to test the exponentially growing system behav-ior [6]. As a consequence, we need systems which addressthese problems, work independently of humans, and man-age themselves according to a set of goals. One new ideato cope with the complexity is Autonomic Computing [10].

The vision of Autonomic Computing [16] is to improvethe management of complex IT systems by introducing self-management systems [12] for configuration, protection, op-timization, and healing purposes. Multiple interacting Au-tonomic Elements (AEs) form the building blocks of ACSs.Major characteristics of an ACS are self-Configuration,self-Healing, self-Optimization, and self-Protection , calledself-CHOP [14] [8] [13]. These systems monitor data sensedby sensors, analyse them, and adjust their operations ac-cording to policies, thus reducing complexity. Some bene-fits of autonomic computing include reduction of costs anderrors, improvement of services, and reduction of complex-ity. Sun, Microsoft, and IBM have introduced productsthat support certain aspects of autonomic computing de-velopment. IBM as one of the pioneers in autonomic com-puting, has software development tools for building theirautonomic 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, theircharacteristics, and their effects on quality factors. In sec-tion 3, building blocks of an ACS are introduced. Softwarearchitectures for autonomic computing are also presented.Section 4 discusses some issues and challenges in this fieldsuch as robustness and relationships among AEs. Section5 presents an overview of related work about role of ACSsand research carried out in this field. Finally, conclusionsand further works are presented.

II. Autonomic Computing (AC): Overview

This section presents an overview of Autonomic Com-

puting Systems (ACSs) and initial concepts about theirdefinitions and their characteristics are discussed.

A. AC Definitions and Characteristics

The autonomic computing initiative is inspired by thehuman body ’s autonomic nervous system [9]. The human

538



2

body has good mechanisms for repairing physical damages.It is able to effectively monitor, control, and regulate thehuman body without external intervention. An autonomic

system provides these facilities for a large-scale complexheterogeneous system. An ACS is a system that managesitself. This definition shows that AC is emerging as an ap-proach to the design, developement, and management of large-scale distributed computing systems. According toPaul Horn ’s definition [13], an ACS is a self-managementsystem with eight elements. Self-configuration means thatan ACS must dynamically configure and reconfigure it-self under changing conditions. Self-healing means thatan ACS must detect failed components and eliminate orreplace it with another component without disrupting thesystem. On the other hand, it must predict problems andprevent failures. Self-optimization is the capability of max-

imizing resource allocation and utilization for satisfyinguser requests. Resource utilization and work load man-agement are two significant issues in self-optimization. AnACS must identify and detect attacks and cover all aspectsof system security at different levels such as the platform,operating system, applications, etc. It must also predictproblems based on sensor reports and attempt to avoidthem. It is called self-protection . An ACS needs to knowitself. It must be aware of its components, current status,and available resources. It must also know which resourcescan be borrowed or lent by it and which resources can beshared. It is self-awareness or self-knowledge property. An

ACS must be also aware of the execution environment toreact to environmental changes such as new policies. It iscalled context-awareness or environment-awareness . Open-ness means that an ACS must operate in a heterogeneousenvironment and must be portable across multiple plat-forms. Finally, an ACS can anticipate its optimal requiredresources while hiding its complexity from the end userview and attempts to satisfy user requests. We considerself-configuration, self-healing, self-optimization, and self-protection as major characteristics and the rest as minorcharacteristics.

[35] defines decentralized autonomic computing systemsas systems that are constructed as a group of locally in-

teracting autonomous entities that cooperate in order toadaptively maintain the desired system-wide self-* prop-erties without any external or internal control. For thesesystems, implications and interpretation of decentralizationon self-* properties can be grand challenges.

B. Relationships between Characteristics and Quality Fac-tors

As mentioned before, the aim of Autonomic Comput-ing (AC) is to improve the system abilities. The designand implementation of ACSs that dynamically support self-managing operations such as finding an autonomic element,

optimization, and configuration, can affect various mea-surements of the system quality and become a solutionto satisfy requirements in different aspects such as per-formance and security. Table 1 specifies the relationshipsbetween autonomic computing properties and quality fac-tors.

Characteristics MetricsSelf-configuration Maintainability, Usability, Functionality, and PortabilSelf-healing Reliability and MaintainabilitySelf-optimization Efficiency, Maintainability, and FunctionalitySelf-protection Reliability and FunctionalitySelf-awareness FunctionalityOpenness PortabilityContext-awareness FunctionalityAnticipatory 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 pro-vide the basic structure for an ACS. Software architecturesfor AC are also explained.

A. Autonomic Element Architecture

AEs are the basic building blocks of autonomic sys-tems and their interactions produce self-managing behav-ior. There is a generic architecture for AEs that is showedin figure 1. The IBM autonomic ’blueprint’ [9] considersthat each AE has two parts Managed Elements (ME) andAutonomic Manager (AM). In fact, ACSs are establishedfrom ME whose behaviors are controlled by AMs. A ME is

a component from a system. It can be hardware, applica-tion software, or an entire system. Each ME must includesensors and effectors [8]. Sensors sense and retrieve infor-mation about the current state of the ME, then compareit with expectations that are held in knowledge base bythe AE. The required action is executed by effectors. AnAM uses manageability interface to monitor and controlthe ME. Each AM has four parts: monitor, analyze, plan,and execute . Monitor part provides mechanisms to collectinformation from a ME, monitor it (data sensed by sen-sor), and manage it. Monitored data is analyzed. It helpsthe AM to predict future status. The plan part assignstasks and resources based on the policies [1]. Policies can

be a set of administrator comments. They are stored asknowledge to guide the AM. The AMs can change resourceallocation to optimize performance according to policies.Finally, the execute part controls the execution of a planand dispatches recommended actions into the ME. Thesefour parts with sensors and effectors provide a control loopto create self-managing. AEs communicate with each otherand react to environmental changes according to predefinedpolicies for developing a self-managing system. Negotiation[16] and trust [4] are two grand challenge in relationshipsbetween them. Negotiation should establish contracts forrelationships between AEs and trust among AEs is impor-

tant becuase they must provision their internal resourcesafter 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



3

Fig. 1. A generic AE architecture

vice Component (TSC) for exchanging messages with otherAMs, (2) Heartbeat Monitoring Component (HMC) fortesting validity, integrity, and avaiability of AM with sending out heartbeats and listening remote heartbeats, (3)Resource Discovery Component (RDC) for generating andfinding the best set of candidate resources for the request,(4) Service Management Component (SMC) for keepingservice lists provided by the AE while checking the valid-ity of these services periodically, (5) Hardware Utilization

Monitoing Component (HUMC) for monitoring the hard-ware state and examining hardware utilization such as CPUspeed, and (6) Decision-Making Component (DMC) for in-dependently making decisions according to rules and poli-cies. In this view of an AE, relationships between AEsis saimilar to what mentioned before, but details of therelationships are performed and examined by these com-ponents. For example, if an AE wants to send messageto another agent, it should send a request for communi-cation to TSC. These components can communicate withtogether. For example, if SMC finds that a service is notvalid, it reports invalidity to DMC for analysis and if itis necessary, the DMC can send reports about it to other

AEs via TSC. If HMC does not listen any heartbeat froman agent, the HMC reports it to RDC to find a substitutefor that agent.

In [7], a research project in Intel ’s Research Lab is de-scribed that focuses on exploring the nature and value of providing platform support for AC. Architectural compo-nents (AEs) of the platform consist of four layers: (1) Sen-sors and effectors, (2) Unified Sensor-Effector Abstractionlayer to abstract and uniform received information andpresent them to higher layers, (3) Data Monitoring andFusion layer to preprocess data and provide functions suchas alert notification, and (4) Policy creation and execution

(authoring tool) after evaluation of the sensed data by theautonomic manager. The authors choices Linux as theiroperating system and present initial phase of this projectwith providing a software abstraction interface to connectsensor information with an authoring tool for autonomicand policy-based management. Their future work is to con-

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

struct a reference autonomic manager.

B. Software Architectures for Autonomic Computing

The activities in software field are categorized into fourgroups: monitoring components, analysing monitored datarelated to the components, creating a plan for adaptationand repair, and executing the plan. McCann et al [20] haveidentified two categories of the approaches to ACSs: tightlycoupled and decoupled autonomic systems. The former isbuilt by using intelligent agents. Autonomic computingand software agent technology are viewed as new technolo-gies to solve these bottlenecks and enhance the design, im-

plementation, and the management of complex distributedsystems [3]. In decomposed autonomic systems, an infras-tructure handles the autonomic behavior of the system.

B.1 Tightly-coupled Autonomic Systems

Tightly-coupled autonomic systems are built by usingintelligent agents (AEs). The agents have autonomous be-havior and make decisions according to predefined policies.Each change in behavior of an agent can create instabil-ities in the entire system, because that agent can affectother agents. Other problem is to define individual goalsof agents to achieve the system goals. In this architec-ture, agents should determine their desirable behavior own

themselves to reach the system goals. Internal monitoring and external monitoring are also discussed in this softwarearchitecture. In fact, without centralized monitoring sys-tem, each agent should monitor itself (internal monitor )and also other agents (external monitor ). R. Sterritt andD. Bustard [30] have proposed a heartbeat or pulse monitorfor monitoring the state of AEs in an autonomous compo-nent domain. The heartbeat of each AE (agent) is sent toan autonomic signal channel that other AEs listen or sendon it. As this channel connects AEs located from differ-ent networked phisical systems, external monitoring mayemerge a lot of traffic on the channel (Figure 2).

B.2 Loosely-coupled Autonomic Systems

In this approach, individual components of the systemare not autonomic but an autonomic infrastructure thatis separated from the running system handles the auto-nomic behavior of the system. The autonomic infrastruc-

540



4

Fig. 3. Architecture of loosely-coupled autonomic systems

ture runs on another machine, therby, we called this ap-proach as loosely-coupled. This approach is also an archi-tecture model-based because the autonomic infrastructureuses an architecture model of the running system for de-

siging the system. Components and their connections areevaluated with a list of properties and constraints in the au-tonomic infrastructure. The running system is monitored,its data is collected and mapped to the architecture model.The architecture model may be updated based on currentstatus of the running system. Then, the architecture modelis analysed and if the system needs adaptation or repair,appropriate plan is executed. The use of knowledge of pastsuccessful plans improves decision about adaptation. Theplan descibes which components must be removed or whichcomponents must be inserted. An advantage of the com-plete separation of autonomic behavior and the runningsystem 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 inthe central architecture manager affect performance of thesystem. Therefore, fault management must be consideredin the infrastructure and individual components. Figure3 (based on the figure from [20]) shows a diagram of aloosely-coupled autonomic system.

IV. Challenges and Issues

Since autonomic computing is a new concept in large-scale heterogeneous systems, there are different challengesand 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 methodologiesare research areas that can help researchers to achieve theaims of AC. An outstanding property of software agentis autonomy . An agent not only reacts to environmen-tal changes but also acts autonomously. Software agentscan be viewed as autonomic elements and this means thatagent-oriented architecture can help for the implementa-tion of self-management. For example, Rudder [17] is a de-centralized scalable agent-based composition infrastructure

that addresses the development of autonomic grid applica-tions, focusing on the dynamic selection and compositionof autonomic elements and negotiation between them toexecute self-managing behaviors. Rudder consists of threetypes of context-aware software agents including Compo-nent Agents (CAs), System Agents (SAs), and Composi-

tion Agents (CSAs). CAs dynamically and locally con-figure and manage autonomic components. SAs are em-bedded within resources such as CPU to monitor, sched-

ule, and optimize their utilization with dynamically work-load balancing. CSAs define rules based on applicationrequirements to choose an enacted workflow plan and in-sert rules into the tuple-space as reactive rules. They dy-namically search and select the appropriate registered au-tonomic components and resources according to goals andrequirements of the application. These agents interact witheach other and scalable tuple-space provides the coordina-tion for their interactions. Self-management is providedwith 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 de-velop self-management systems by either replacing codes(components) with same functionality or inserting a newcode (component) between two existing component. Thestages include terminating a component that should be re-placed, suspending components and connections related onthis component, adding a new component that is deter-mined according to a repair plan, establishing the rela-tionships between new components and suspended compo-nents and connections, reconfiguring the system. Althoughadaptation is established into the system, but the systemneeds extra time to load a new component and link it to

the system, thereby, overhead increases. Another researchthemes has been introduced to address self-management atthe level of middlewares and frameworks such as dynamiccomposition [25] and smart components. Smart compo-nents are used to adapt to environmental changes and sup-port self-management. Composition formalisms help to au-tomate generation of global configuration by consideringcertain constraints and/or optimization criteria [29].

C. Issues in Relationships among AEs

Relationships among AEs have a key role in implement-ing self-management. These relationships have a life cycleconsisting of specification, location, negotiation, provision,

operation, and termination stages. Each stage has its ownchallenges [16]. Challenges in specification include lack of the establishment of the syntax and semantics of standardservices for AEs, because AEs should interact together anduse from their services. Moreover, an AE must dynam-ically locate input services that it needs and other AEsthat need its output services must dynamically locate thiselement with looking it up. Therefore, AE reliability canbe a research area. AEs also need protocols and strategiesto establish rules of negotiation and to manage the flow of messages among the negotiators. One of these challengesis to develop and analyze negotiation algorithms and pro-

tocols, then determine which negotiation algorithm can beeffective. After negotiation and reaching to an agreement,how both agreed AEs provision their resources in an im-portant issue. An AE can provide agreed service itself orother elements can help it in providing part of agreed ser-vice. This is a research area. Automated provision can

541



5

also be a research area for this stage. After agreement, theAMs of both AEs control the operation. If the agreementis violated, different solutions can be introduced. This can

be a research area. Finally, after both AEs agree to ter-minate the negotiated agreement, the procedure should beclarified.

D. Learning and Optimization Theory

One of questions in ACSs is how can we transfer the man-agement system knowledge from human experts to ACSs?In more sophisticated autonomic systems, individual ele-ments will be agents that continually adapt to their envi-ronment that consists largely of other agents [16]. Theseagents must learn to solve problems based on their past ex-periences. 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 hu-man experts and the knowledge acquisition from the hu-man experts. Designing a robust learning procedure thatis automatically performed on a new system can be a re-search area. Optimization can be also a challenge becausein such systems, agents adapting in a dynamic environmentare changing their behavior to reach optimization. The op-timization is examined at AE level.

E. Robustness

Robustness has been used in various sciences and sys-tems such as ecology, engineering, and social systems. We

can interpret it as stability, reliability, survivability, andfault-tolerance, although it does not mean all of these. Ro-bustness is the ability of a system to maintain its functionsin an active state, and persist when changes occur in inter-nal structure of the system or external environment. Ro-bustness may be defined stability. Although both stabilityand robustness focus on persistence, robustness is broaderthan stability [15]. It is possible that components of a sys-tem are not themselves robust, but interconnections amongthem make robustness at the system level. A robust systemcan perform multiple functionalities for resistance, withoutchange in the structure. With the design of instructionsthat permit systems to preserve their identity even when

they are disrupted, the robustness in systems can be in-creased. Robustness is one of grand scientific challenges inthe development of ACSs.

F. Trust

Trust among AEs can be one of important issues in therelationships between them and affects ACS functionality.It means that one AE expects other AEs to reliably performtheir tasks to provide their agreed services to achieve thegoal. Trust Parameters (TPs) can be defined as the basisof trust management such as customer response time as anoptimization TP. We can categorize TPs in configuration,

healing, protection, and optimization. Trust requirementsinclude identifying and selecting TPs, aggregating them,assigning trust values to AMs into each AE, and managingtrust in communcation of AEs. In an AE, trust can bebuilt according to result of examining the history of pastperformance information recorded in the AE. The concept

of trust can be introduced into a system by assigning aninstantaneous trust index to each execution of an AM andan overall trust index that reflects the level of trust of an

administrator in that AM [4].

V. Related Work

On March 8, 2001, Paul Horn presented a link betweenpervasiveness and self-regulation in body ’s autonomic ner-vous system and introduced ACSs to the National Academyof Engineering at Harvard University. With choosing theterm autonomic , researchers attempted to make autonomiccapabilities in computer systems with the aim of decreasingthe cost of developing and managing them. [18] presentsa standard and quantitative definition of AC according toquality mertics frameworks described in IEEE Std 1061-1998. It also represents a quality metrics framework forAC that contains three layers, openness and anticipatoryat first layer, self-awareness, context-awareness, and self-management as subsets of anticipatory at second layer, andself-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 andtheir necessary elements called Autonomic Elements (AEs).One of problems in implementation of ACSs is how partsof applications are connected, how they interoperate, and

how components developed by different technologies aresimply integrated. Middleware, as systems software thatlocates between applications and low-level hardware andsoftware infrastructure, is served as a solution for aboveproblems. Common Object Request Broker Architecture(CORBA) [23] and Enterprise JavaBeans [22] are commonmiddlewares. Although the CORBA Component Modelas a common model specifies components for distributedsoftware 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 com-puting resources instead of distributed operating systems,

(2) Implementation of more functions that are usable ina specific application domain such as telecommunication,and (3) Ability to monitor, analyse, and control the stateand behavior at runtime itself. Third property is relatedto autonomic computing middlewares that perform reason-ing and decision making themselves. Some work on auto-nomic middleware can be found at [27] [28]. J. A. McCannand M. C. Huebscher in [20] have proposed some metricsto evaluate ACSs such as adaptability. Some performancefactors such as security and performance have been dis-cussed by others [5] [11]. The most important challengesin engineering and science such as robustness and relation-

ships among AEs have been discussed in [16]. Differentprojects and products have been developed both by theindustry and the academia. M. Salehie and L. Tahvildarihave outlined some of these products in [29]. Finally, thelast information about autonomic computing can be foundin http://www-03.ibm.com/autonomic/ .

542



6

VI. Conclusion

Current programming languages, methods, and man-agement tools are not adequate to handle the complex-

ity, scale, dynamism, heterogeneity, and uncertainty. Au-tonomic Computing has gained world attention in recentyears for the reason of developing applications with self-managing behavior. Automatic computing is a grand chal-lenge that requires advances in several fields such as soft-ware architecture, learning and reasoning, modelling be-havior, policies, multi-agent systems, and knowledge basedesign. In this paper, a survey of autonomic computing sys-tems, their importance, their architectures, and some chal-lenges was presented. The lifecycle of relationships betweenAEs, learning, and robustness express some challenges inACSs. Issues about applying agent-oriented paradigm and

component-based development and management was alsodescribed.

References

[1] R. J. Anthony. A Policy-Definition Language and PrototypeImplementation Library for Policy-based Autonomic Systems.In IEEE International Conference on Autonomic Computing (ICAC ’06), pages 265–276, June 2006.

[2] J. Appavoo and et al. Enabling autonomic behavior in sys-tems software with hot swapping. In IBM Systems Journal ,volume 42, pages 60–76, January 2003.

[3] W. Chainbi. Why Applying Agent Technology to AutonomicComputing? In Self-Organization and Autonomic Informatics(I), edited by Hans Czap, Rainer Unland, Cherif Branki, Hua-glory Tianfield , volume 135, pages 1–7, 2005.

[4] H. Chan, A. Segal, B. Arnold, and I. Whalley. How Can We

Trust an Autonomic System to Make the Best Decision? In Sec-ond International Conference on Autonomic Computing (ICAC ’05), pages 351–352, June 2005.

[5] D. M. Chess, C. Palmer, and S. R. White. Security in an au-tonomic computing environment. In IBM System Journal , vol-ume 42, pages 107–118, January 2003.

[6] D. J. Clancy. NASA Challenges in Autonomic Computing. InAlmaden Institute, IBM Almaden Research Center, San Jose,CA, April 2002.

[7] L. M. Durham, M. Milenkovic, and P. Cayton. Platform Supportfor Autonomic Computing: a Research Vehicle. In IEEE In-ternational Conference on Autonomic Computing (ICAC ’06),pages 293–294, June 2006.

[8] A. G. Ganek and T. A. Corbi. The dawning of the autonomiccomputing era. In IBM System Journal , volume 42, pages 5–18,January 2003.

[9] IBM Group. An architectural blueprint for autonomic comput-

ing. In http://www-03.ibm.com/autonomic/pdfs/AC , June 2005.[10] 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 5–17, 2006.

[11] S. Hariri and M. Parashar. Autonomic Computing: An overview.In Springer-Verlag Berlin Heidelberg , pages 247–259, July 2005.

[12] M. G. Hinchey and R. Sterritt. Self-managing software. In Com-puter, Published by IEEE Computer Society , volume 39, pages107–109, February 2006.

[13] P. Horn. Autonomic Computing: IBM ’s perspec-tive on the State of Information Technology. In www-1.ibm.com/industries/government/doc/content/bin/auto.pdf ,October 2001.

[14] M. Jarrett and R. Seviora. Constructing an Autonomic Comput-ing Infrastructure Using Cougaar. In Proceedings of the Third IEEE International Workshop on Engineering of Autonomic and Autonomous Systems (EASe 2006), pages 119–128, March2006.

[15] E. Jen. Stable or Robust? What’s the Difference? Inhttp://www.santafe.edu/ erica/stable.pdf , 2002.

[16] J. O. Kephart and D. M. Chess. The vision of autonomic com-puting. In IEEE Computer , volume 36, pages 41–50, January2003.

[17] Z. Li and M. Parashar. Rudder: A Rule-Based Multi-AgentInfrastructure for Supporting Autonomic Grid Applications.In First International Conference on Autonomic Computing (ICAC’04), New York, NY , pages 278–279, May 2004.

[18] P. Lin, A. MacArthur, and J. Leaney. Defining Autonomic com-puting: A software engineering perspective. In Australian Soft-ware Engineering Conference (ASWEC’05), 2005.

[19] M. Loughran and K. Gibbons. IBM and Cisco Unveil InnovativeApproach Toward a Self-Healing Infrastructure. In http://www-03.ibm.com/autonomic/ , October 2003.

[20] J. A. McCann and M. C. Huebscher. Evaluation issues in au-tonomic computing. In Proceedings of Grid and Cooperative Computing workshop(GCC), volume 15, pages 597–608, Octo-ber 2004.

[21] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja,J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-Peer Com-puting. In Proceedings of the Second International Conference on Peer-to-Peer Computing , pages 1–51, July 2002.

[22] Shin Nakajima and Tetsuo Tamai. Behavioural Analysis of theEnterprise JavaBeans Component Architecture. In Lecture Notesin Computer Science , volume 2057, pages 163–182, 2001.

[23] Object Management Group (OMG). Common Object Bro-ker Resource Architecture (CORBA). In Available at:http://www.corba.org .

[24] M. Parashar, Z. Li, H. Liu, V. Matossian, and C. Schmidt. Au-toMate: Enabling Autonomic Grid Applications: Requirements,Models and Infrastructures. In Self-Star Properties in Com-plex Information Systems, Lecture Notes in Computer Science,Springer Verlag , volume 3460, 2005.

[25] E. Patouni and N. Alonistioti. A Framework for the Deploymentof Self-Managing and Self-Configuring Components in Auto-nomic Environments. In International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2006),pages 480–484, June 2006.

[26] D. Patterson and et al. Recovery Oriented Computing (ROC):Motivation, Definition, Techniques, and Case studies. Inroc.cs.berkeley.edu/papers/ , 2002.

[27] G. Rimassa, D. Greenwood, and M. E. Kernland. The Living

Systems Technology Suite: An Autonomous Middleware for Au-tonomic Computing. In International Conference on Autonomic and Autonomous Systems (ICAS06), Silicon Valley, USA), July2006.

[28] A. Sajjad and et al. AutoMAGI-an Autonomic middleware forenabling Mobile Access to Grid Infrastructure. In Proceedings of Joint International Conference on Autonomic and AutonomousSystems and International Conference on Networking and Ser-vices (ICAS/ICNS), pages 73–78, October 2005.

[29] M. Salehie and L. Tahvildari. Autonomic Computing: emergingtrends and open problems. In ACM SIGSOFT Software Engi-neering Notes, volume 30, pages 1–7, July 2005.

[30] R. Sterritt and D. Bustard. Towards an autonomic comput-ing environment. In 14th International Workshop on Database and Expert Systems Applications (DEXA ’03), pages 694–698,September 2003.

[31] A. Umar. Distributed computing: A practical synthesis. In

Prentice-Hall , pages 4–22:293–312:349–356, 1993.[32] G. Valetto and G. Kaiser. A case study in software adaptation.In ACM Workshop on Self-Healing Systems (WOSS ’02), pages73–78, November 2002.

[33] N. Wang, D. C. Schmidt, and C. O’Ryan. Overview of the corbacomponent 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 com-puting. In Proceedings the International Conference on Auto-nomic Computing (ICAC’04), NewYork, USA, pages 2–9, May2004.

[35] T. De Wolf and T. Holvoet. Evaluation and comparison of decen-tralised autonomic computing systems. In Department of Com-puter Science, K.U.Leuven, Report CW 437, Leuven, Belgium ,March 2006.

[36] M. Wooldridge and N. R. Jennings. Agent Theories, Architec-tures, 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 397–400,May 2004.

543

Documents

Autonomic Computing Systems - Issues and Challenges