Context Driven Compositional Adaptation of Mobile Agents

Kutila Gunasekera1, Arkady Zaslavsky1, Seng Wai Loke2, Shonali Krishnaswamy1 1Faculty of Information Technology, Monash University, Australia

2Department of Computer Science & Computer Engineering, La Trobe University, Australia {kutila.gunasekera, arkady.zaslavsky, shonali.krishnaswamy}@infotech.monash.edu.au,

S.Loke@latrobe.edu.au

Abstract

Agent technology is increasingly seen as an

attractive approach to develop applications for pervasive environments. However, it is a challenge to develop agent systems for such complex and dynamic environments. We propose a novel approach to develop software for pervasive environments by using context-aware adaptive agents. Our agents have the ability to exchange their capabilities with peers, are self-adaptive and enable software reuse through a component-based infrastructure. The solution also enables reduced network traffic and has the potential to allow agents to execute on heterogeneous agent platforms. We also describe the first implementation of the solution and discuss experiments carried out with it and possible further enhancements. 1. Introduction

The rise of pervasive computing means that computer systems execute in dynamic open environments as opposed to the well-behaved and controlled environments of yesteryear. Developing the complex software needed to control such systems is becoming increasingly difficult. Autonomic computing [1] and self-adaptive software [2, 3] are two approaches suggested to overcome this impending crisis. Both of these approaches see agent technology as an attractive technique to develop complex distributed systems for open environments. Software agents, and in particular mobile agents, are seen by many as a key solution to issues in pervasive computing [4-6].

A pervasive application has to deal not only with user input but many other inputs from sensors and other traditional sources like databases and remote messages. It may have to adapt its behaviour based on time, location, device power level, incoming messages,

user preferences and so on. In other words, pervasive applications have to be context-aware.

We propose a novel approach to develop software for pervasive environments by using adaptive agents. Our agents are autonomous entities which execute on heterogeneous platforms, acquire new capabilities at runtime, and adapt based on contextual input. Their ability to dynamically change behaviours by acquiring capabilities from peer agents makes them more versatile compared to conventional agents.

In the next section we analyse selected previous work in the field which paves the way for our research. Section 3 describes our solution. In section 4 and 5, we describe the first implementation of the solution and tests carried out on it respectively. Section 6 further discusses future directions of the solution and we conclude in section 7. 2. Background

Agent systems have been around for some time, but, similar to the case with non-agent software, it is extremely difficult to design and program an agent system to cater for all possible situations it may encounter in an open environment [7]. Hence, many existing agent systems are static and able to deal with only a limited set of expected situations and need to be reprogrammed when faced with unexpected situations. Therefore it is important to be able to model and build agent systems that can learn and adapt to environmental changes. Marín and Mehandjiev [7] describe several recent research efforts to build adaptive agent systems. Based on descriptions in literature [8-11] we note that an adaptive agent is aware of its structure and ability to change at runtime, makes use of this self-awareness to change its internals at runtime (i.e. agent structure, knowledge/data contents) and is able to improve its performance over time (or maintain its usefulness in a changing environment) as a result of adaptation. Next, we briefly

201

describe several efforts to develop agent systems with compositional adaptation of agents.

GAMA (Generic Adaptive Mobile Agent architecture) [11, 12] describes a framework for building component-based adaptive mobile agents for pervasive environments. A GAMA [11] agent is composed of multiple components and is capable of adapting itself to suit new environments. GAMA [11] agents are self-adaptive and adaptation is triggered based on contextual information about the agent’s platform. Adaptation is a process which takes as input a core agent, a set of environment dependent components and a description of the current environment and produces as output the core agent linked with a selected set of components that suit the environment. GAMA agents however have two serious limitations. Adaptation can only happen after migration to a new location and agents are limited to using only the contents of the component repository of its current location.

Dynamic Agents [13] aims to provide agents with dynamic behaviour modifiability for “highly dynamic and distributed applications”. Individual dynamic agents [13] are general purpose carriers of programs designated as either actions or open servers. An agent can dynamically load new programs (actions or open servers) when it is presented with a task that requires capabilities beyond what it has at present. A somewhat similar system, Dynamically Configurable Software (DynamiCS) [14] allows dynamic inclusion of negotiating capabilities into mobile agents. DynamiCS [14] agents are containers for plug-in software components. A basic DynamiCS agent contains mobility and persistence features while all application specific functionality is represented as plug-in components that can be dynamically loaded and unloaded from agents. DynamiCS [14] agents can only adapt to change their negotiation capabilities. A Dynamic agent [13] in need of a new component queries the resource-broker and downloads the component from a URL. Components, therefore, are downloaded allowing no room for optimized exchange of components.

The component-based approach to developing adaptive agents is an important commonality in many of the adaptive agent systems analysed [9, 11, 13-15]. We believe the majority choice of a component-based approach for adaptive agents is the logical path to take. It is also in line with the general preference towards component-based software development.

Adaptive software agents are still limited by the scope of adaptation available to them. Usually it is limited to one of either migration, reconfiguration of parameters, or sometimes addition/removal of internal software components from a pre-defined component

repository. We believe adaptation through component change is the most powerful since it allows an agent to completely change its behaviour while maintaining identity. However, to be truly useful in unpredictable environments, agents should have more flexibility in adaptation. For example, the dependence on one or a small set of “capability” providers can be a limitation, especially in pervasive environments where the agent may migrate beyond the reach of such services. We also see the necessity to have a broader view of adaptation. Migration, for example, is often not seen as a viable option for adaptation because agents are too heavy and available migration mechanisms too inefficient. Even in systems where agent mobility is available, it is sometimes not considered as a form of adaptation. We believe that by including agent migration as a form of adaptation, we increase the options available for an agent to react and thereby make better responses possible.

3. VERSAG: Versatile Self-adaptive Agents

We propose the development of VERsatile Self-adaptive AGents (VERSAG) which are context-aware, lightweight, component-based and can load software components at runtime to acquire new behaviours. The salient features of the proposed solution are: • The ability of agents to acquire new behaviours

from peer agents without depending on one or a group of designated component providers and

• An agent’s ability to adapt based on contextual input.

Self-adaptiveness, as identified before, is important in pervasive environments in order to manage the growing complexity of applications. Supporting multiple forms of adaptation and being able to choose the best form allows for more efficient agents. We also take the approach of Dynamic Agents [13] where agents are carriers of software components; thereby making agents reusable and easily extensible. From a programming point of view, VERSAG agents are homogeneous as all agents are instantiated from the same class and the differences arise from the carried components which are simply data to the runtime environment.

We term the components that are carried and exchanged by agents as “capabilities”. Since the term has been used with different meanings in literature, we give our definition for the purpose of this research. A capability is formally defined as a tuple <id, F, credentials, Env> where, id is a unique identifier, F represents the set of functions that the capability contains, credentials represent meta-data such as

202

origin, version, security certificates and optimizations available in the capability and Env represents a set of environments that the capability can execute in. More informally, a capability is a software component which can be attached to and detached from a software agent to provide the agent with particular application-specific behaviour. The program logic (and data) required to exhibit this behaviour are contained in the capability, usually in the form of compiled code. Several examples of behaviours an agent may acquire through a capability are: the ability to act as a buyer or seller in an auction; the ability to mine data from a database; the ability to buy movie tickets from the internet and even acquiring a BDI like agent model. Action programs and open servers in Dynamic agents [13], and GAMA components [11] are concepts similar to capabilities. From a programming perspective, a capability could be represented as a collection of classes carried about with an agent to be loaded when needed.

VERSAG agents do not contain any application specific behaviours when they are created. An agent is given an itinerary which specifies the activities it has to carry out and the locations where these activities are to be carried out. It is up to the agent to decide when and from where the necessary capabilities are acquired. An agent which does the same task at multiple locations may opt to load the capabilities needed once and carry them throughout rather than loading and discarding them at each location. In a situation where network bandwidth is limited, it may be prudent to find capabilities from ‘nearby’ peer agents rather than carrying them around. An agent also has the ability to pass on its capabilities to other agents when requested, making all VERSAG agents potential capability providers.

Agents need to find capabilities that are able to fulfill the tasks allocated to them. Therefore it is necessary to describe a capability in a way that allows agents to search for and reason about them (i.e. match tasks to capabilities and compare between alternatives). Agents also need to be certain that capabilities acquired are safe, indicating a need to have them certified as secure. Computationally heavy tasks could have capabilities optimized for different hardware platforms. For example, a data mining agent could operate more efficiently with a mining algorithm implementation that is optimized for its current platform. Capabilities could similarly describe themselves as memory/CPU efficient so that an agent migrating to a resource constrained device may load them. They may also contain source code to be compiled for the target platform before use. Capability specifications (similar to blueprints in [9]) could allow agents to migrate between different programming platforms (e.g. Java and .NET) with the agent being

assembled on the target platform using compatible components.

Capability exchange among peer agents gives VERSAG several advantages over systems where runtime component loading depends on a designated provider. Two designated provider examples are downloading components from a remote URL and loading from a repository at a particular location. The agent then has to either know where the provider is a priori or should request this information from an intermediary broker. Designated providers need to have high-performance and be highly available to satisfactorily serve requests from a large number of agents. And the failure of a provider or broker could cripple the system. Consider an environment where a group of agents form an ad-hoc network and are out of reach of a designated component provider. An agent in this network, which needs to acquire a component, is unable to do so even if another agent in the network has the component simply because the provider is unavailable. The ability of agents to request and acquire components from peer agents becomes highly valuable in such situations. Also, acquiring capabilities from a nearby peer instead of a distant provider reduces network traffic by allowing local exchanges instead of global ones. For example, we visualize an agent in need of dealing in a particular type of auction moving to the location of the auction and acquiring the necessary capabilities from agents already in that auction. With all agents being providers, the need for a single high-performing provider is eliminated and an individual agent need not be as robust in its provider role since it is no longer the sole provider.

This section described the proposed solution towards versatile adaptive agents and its advantages over current systems. 4. Design and Implementation

We now take a detailed look at the design and implementation of a prototype of the VERSAG system. We perceive an agent as having a set of tasks, but whether the agent has an individual goal or shares a common goal with a team of agents is not of concern for this discussion. However, we assume that agents are cooperative in that they always provide their capabilities to requestors. An agent’s tasks are specified in an itinerary [16, 17], which provides an agent with a “migration path”: a list of locations to visit and sub-tasks to carry out at each location. To carry out these sub-tasks, an agent requires different skills, which are represented as capabilities. Figure 1 shows the structure of a VERSAG agent. It is now

203

built on top of the JADE agent platform which also has support for running on resource-limited devices.

Fig. 1. The structure of a VERSAG agent is shown here. An agent is a thin layer built on top of a JADE agent and can be ported to different agent platforms such as Voyager [18].

The agent is driven by an itinerary and the itinerary management module contains the methods for parsing and executing an itinerary. Given below is a sample itinerary record indicating the agent’s tasks when at location loc1. loc1=fetch c023#exec c023 versag.MySQLMiner mine#move loc2

The tasks are separate by a ‘#’ (hash) character. The first task is to fetch (fetch) the capability c023. Then it is to execute (exec) the capability and finally move to location loc2.

The capability management module’s tasks are to locate and fetch capabilities, execute them when requested by the itinerary management module and also to serve capability requests from peers. The module also allows an agent to query what capabilities are currently available with it so as to decide whether a capability needs to be acquired. Shown below is a modified code excerpt of the methods made available by the capability management module.

public class CapabilityManager { public void fetch(String capabilityId, ...) { ... } public void unload(String capabilityId) { ... } public Object execute(String capabilityId, ...) { ... } public synchronized void startProvider() { ... } public boolean isAvailable(String capabilityId) { ... } ... }

Capability discovery in the prototype is done

through the JADE Directory Facilitator agent (DF) [19]. Agents register themselves as capability providers with the DF. When a capability is required,

the agent gets the list of available providers from the DF and sends requests to these agents until a successful response is received.

The capability repository is where capabilities are stored in an agent and represents what Laddaga [20] terms as a “reuse asset base” required by self-adaptive software. A capability is represented as a Java object with an identifier and bytecode for a collection of classes. An agent loads these classes with a custom class loader and executes them using the Java Reflection API [21]. Importantly, the capabilities are reusable components as they are independent of the agent toolkit and can be reused across heterogeneous agent platforms and even on non-agent environments. 5. Evaluation

In this section we describe the experiments performed to compare the performance of a VERSAG agent against a conventional agent and identify relative advantages and drawbacks.

Fig. 2. The test environment setup consists of a JADE platform with four locations (i.e. JADE containers). The “main container” is where the JADE Agent Management Service (AMS) and Directory Facilitator (DF) reside. This is named loc1 and is located on computer A. The other three locations named loc2, loc3 and loc4, are all on computer B. The two computers are connected over a LAN.

Figure 2 shows the test environment setup. The communication cost (in terms of network traffic) between locations on the same computer is assumed to be negligible while there is a cost involved in data transfer over the network link (i.e. it represents a low bandwidth communication link in a pervasive setting). We are not concerned with the specifications of the machines or network as our main target is to measure the volume of data transferred over the network. Readings taken are of the number of bytes transferred over the network link and the time taken to load and execute a capability in each case.

204

The tests consist of an agent travelling from loc1 to loc4 via loc2 and loc3. The agent has to sort a text file using an “insertion sort” capability at loc2 and a “shell sort” capability at loc3. In the first three test cases, a VERSAG agent carries out the tasks. In the fourth test, a conventional agent which has the two sorting algorithms coded into it is used. As a pre-condition for test case 1 and 2, an agent with the required capabilities and playing the role of a provider should reside at loc1.

Fig. 3. Test case 3 and 4

In test case 1, a capability-exchanging agent is started and loads the itinerary at loc1. It loads the required capabilities while at loc1 and then migrates to loc2. At loc2 the first sorting capability is executed and then unloaded. The agent then moves to loc3 where the other sorting capability is executed and unloaded from the agent’s repository. Finally the agent moves to loc4. In test case 2, the working agent loads the required capability at the location where it has to be executed and unloads it before moving on to the next location. In test case 3 the capability provider agent resides at loc4 and itinerary of the working agent is the same as test case 2. In test case 4, a conventional agent starts at loc1 and moves through loc2 and loc3 carrying out its sorting and finishes at loc4. Figure 3 illustrates test cases 3 and 4.

When a JADE agent migrates, the classes that represent the agent are pulled from the agent’s home location if they are not available at the destination [22].

In our tests, the agents’ home is always loc1 and we restart the agent platform after each test to ensure that classes are not available at the non-home locations due to a similar agent having previously passed through. Therefore each migration in our test cases requires the destination agency to retrieve the agent’s code from the home, the exception being loc4 in test case 3 where the code is already available because the provider agent is at loc4. This rule does not apply to capability code as they are carried around as data and explicitly exchanged by the agents.

Table 1. Test Results

Data transferred (kb) Execution Time (ms) Test

Case Total A to B B to A Cap1 Cap2 1 360.5 277.3 83.2 309 79 2 389.8 294.9 95.0 312 75 3 134.8 94.6 40.2 316 78 4 319.0 242.5 76.5 318 78

We take readings of the total amount of data

exchanged between the two computers in the four test cases. This includes the serialized agent and its classes transferred, the messages exchanged between agents and the capabilities exchanged. We also measure the time taken by an agent to execute a capability. The results of our tests (averaged over a number of test runs) are shown in table 1.

Fig. 4. Traffic Generated over network link. More data is transferred from A to B which is the direction in which agents migrate and code transfers occur. The traffic in reverse direction is generated due to messages passed.

Figure 4 is a graphical representation of the amount of data transferred over our ‘expensive’ network link. Test cases 1 and 2 generate similar amounts of traffic with test case 2 being slightly higher due to the overheads of searching for and requesting capabilities. In test case 4, the capabilities are anyway included in the agent; however the overheads of capability exchange are non-existent. Therefore we see a slight reduction in the total data transferred. Test case 3

205

shows a significant reduction in the number of bytes transferred when the capabilities are already available on computer B. This is further explained in table 2.

Table 2. Composition of traffic over network link. Ao represents agent object size, Ac agent class size, C1c Capability 1 class size and C2c capability 2 class size.

Test Case

Distribution of Traffic over Network Link

1 agent{Ao, Ac} + data{C1c , C2c} + {overheads}

2

agent{Ao, Ac} + capabilities{C1c , C2c, exchange overhead} + {overheads}

3 agent{Ao , Ac} + {overheads} 4 agent{A′o, A′c , C1c , C2c } + {overheads} Test results show that VERSAG agents significantly

reduce network load by reusing code available in nearby locations. Understandably, there is an overhead due to the capability exchanging mechanism. The execution times for tasks are similar when loaded as capabilities and when coded into the agents, indicating negligible overhead due to the added application level class loading and execution.

In the prototype, agents adapt by acquiring and discarding capabilities as per itinerary commands. A separate context-aware adaptation module that decides on forms of adaptation is needed. Also, at present it is the itinerary management module that controls the agent’s behaviour which is restrictive as an agent needs to monitor and evaluate its functioning and goals through its “own process control” as mentioned in [23]. Such a kernel process would be in charge of the agent’s processing and would decide with help of other components how the agent behaves. The current itinerary syntax is simple and we plan to add support for a more powerful itinerary language such as that defined by Loke, Zaslavsky et al. [17]. 6. Discussion

In this section we further discuss parts of the proposed solution and its implementation in relation to other works and what aspects remain to be investigated.

Automated exchange of software resources is useful in many application areas such as autonomic computing, grid computing and service-oriented systems. If the agents in our solution are competing entities rather than a team of agents with a common goal, capability exchange becomes a marketplace activity and a capability becomes a marketable commodity. A provider agent then has to be compensated for serving a peer’s request, a capability

is assigned a value and the exchange process would involve contracts about how the recipient can use the capability. Challenges and requirements of such a marketplace are described in [24]. How a capability is described decides how successfully it can be searched, matched, exchanged and used. These aspects need further investigation as the current implementation takes a simple approach to representing, searching, describing and exchanging capabilities.

Mobile agents are one form of code mobility [25], and capability carrying agents form another layer capable of moving code on top of an agent. This seemingly redundant layer allows us to make agents adaptable and provide code mobility at a different level of abstraction: we are attempting to implement a finer-grained form of code mobility. There is however another aspect on which we can improve: code migration strategies. Braun et al. [26] identified that most agent toolkits implement simple push-all or pull-as-required migration strategies which can be inefficient. In push-all when a component (agent or capability) migrates, all classes belonging to it are pushed to the destination even though some may not be used. In the pull-strategy, classes are pulled (from the home agency or a remote location) as required (e.g. JADE). They propose an optimized agent mobility model, which allows optimized migration of code. Their proposals include adaptive transmission of code allowing runtime migration strategy selection and code caching. Such optimized migration strategies can be implemented for capability transmission in VERSAG agents, providing systems using standard agent toolkits with optimized migration strategies. An improved capability fetching protocol and use of compression for capability migration would lead to improvements.

Context-awareness, as mentioned before, is seen as an integral enabling technology for pervasive computing. CALMA [27] is a framework for developing context-aware lightweight BDI mobile agents. The CALMA architecture includes a special “resource monitor” component to monitor environmental conditions. In [28] Munoz et al. describe a system which acquires context-awareness through dedicated agents. However, in VERSAG, context-awareness is an attribute each agent should possess and we need to further investigate approaches taken by context-aware systems for pervasive environments (including the above) to identify how context should be represented and used in VERSAG. 7. Conclusions and Future Work

In this paper, we have proposed a novel approach to develop software systems for pervasive

206

environments. Our solution consists of context-driven mobile agents that can dynamically adapt by exchanging software components (termed as capabilities) with peer agents. By enabling agents to exchange components among each other, we eliminate the need for a dedicated component server and enable local exchanges between agents. Both these features are desirable in pervasive environments where low bandwidth and small islands of agents are possible. Our agents also have a potentially large number of capability sources to select from instead of being limited to a single provider. Software capabilities enable reuse between different agent platforms and even with non-agent systems. Agents adapt based on contextual input and are therefore able to adapt to any sort of environmental change.

The proposed compositional agent architecture does not limit agents to a particular model such as the BDI model, since these models can also be represented as capabilities. Further, with equivalent capabilities available in different programming environments, agents could also migrate from one environment to a different one.

The current prototypical implementation of VERSAG agents was explained in detail. We successfully demonstrated the capability exchanging of agents through our implementation. The experimental results showed that a significant reduction in network traffic can be achieved by localized capability exchange among peer agents. We also identified the possibility of further network traffic optimizations through the use of efficient code migration mechanisms.

Security and privacy are important issues in mobile agent research and with VERSAG’s use of capabilities, these issues are well recognized. However security and privacy issues are outside the scope of the current research and therefore we have not discussed them in this paper.

Our future work includes research into approaches for capability representation, description, discovery and exchange, for which the use of ontologies is one option. Inclusion of optimized migration strategies, data compression and context-awareness also needs to be looked at. The limitations of the prototype identified previously remain to be remedied in future versions. 8. References [1] J. Kephart and D. Chess, "The Vision of Autonomic

Computing," Computer, vol. 36, p. 10, 2003. [2] R. Laddaga, "Self-adaptive software, DARPA, BAA-

98-12, Proposer Information Pamphlet," 1997. [3] P. Robertson, R. Laddaga, and H. Shrobe,

"Introduction: The First International Workshop on

Self-Adaptive Software," in Self-Adaptive Software: First International Workshop, IWSAS 2000, Oxford, UK, April 2000. Revised Papers. vol. 1936, P. Robertson, R. Laddaga, and H. Shrobe, Eds. Berlin/Heidelberg: Springer, 2000, pp. 1-10.

[4] M. Satyanarayan, "Pervasive computing: vision and challenges," IEEE Personal Communications, vol. 8, pp. 10-17, 2001.

[5] R. S. Cardoso and F. Kon, "Mobile Agents: A Key for Effective Pervasive Computing," in ACM OOPSLA 2002 Workshop on Pervasive Computing, Seattle, 2002.

[6] A. Zaslavsky, " Mobile agents: can they assist with context awareness?," in IEEE International Conference on Mobile Data Management, 2004, pp. 304- 305.

[7] C. A. Marín and N. Mehandjiev, "A Classification Framework of Adaptation in Multi-Agent Systems," in Cooperative Information Agents X. vol. 4149, M. Klusch, M. Rovatsos, and T. R. Pay, Eds. Berlin, Heidelberg: Springer, 2006, pp. 198-212.

[8] P. Maes, "Modeling Adaptive Autonomous agents," Artificial Life, vol. 1, pp. 135-162, 1994.

[9] S. v. Splunter, N. J. E. Wijngaards, and F. M. T. Brazier, "Structuring Agents for Adaptation," in Adaptive Agents and Multi-Agent Systems. vol. 2636, E. Alonso, D. Kudenko, and D. Kazakov, Eds. Berlin: Springer, 2003, pp. 174-186.

[10] Z. Guessoum, " Adaptive agents and multiagent systems," IEEE Distributed Systems Online, vol. 5, 2004.

[11] N. Amara-Hachmi and A. E. Fallah-Seghrouchni, "Towards a Generic Architecture for Self-Adaptive Mobile Agents," in European Workshop on Adaptive Agents and Multi-Agent Systems, 2005.

[12] N. Amara-Hachmi, "An Ontology-based Model for Mobile Agents Adaptation in Pervasive Environments," in IEEE International Conference on Computer Systems and Applications, 2006, pp. 1106-1109.

[13] Q. Chen, P. Chundi, U. Dayal, and M. Hsu, "Dynamic Agents," International Journal of Cooperative Information Systems, vol. 8, pp. 195-223, 1999.

[14] M. T. Tu, F. Griffel, M. Merz, and W. Lamersdorf, "A Plug-in Architecture Providing Dynamic Negotiation Capabilities for Mobile Agents," in Proceedings of the Second International Workshop on Mobile Agents, Stuttgart, 1998, pp. 222 - 236.

[15] K. R. Dixon, T. Q. Pham, and P. K. Khosla, "Port-Based Adaptable Agent Architecture," in Self-Adaptive Software: First International Workshop, IWSAS 2000, Oxford, UK, April 2000. Revised Papers. vol. 1936, P. Robertson, H. Shrobe, and R. Laddaga, Eds. Oxford, UK: Springer-Verlag, 2000, pp. 181 - 198

[16] R. Price, S. Krishnaswamy, and N. Arora, "Current research in conceptual modelling of agent mobility: an ontology-based evaluation," International Journal of Metadata, Semantics and Ontologies, 2007.

[17] S. W. Loke, A. Zaslavsky, B. Yap, and J. R. Fonseka, "An Itinerary Scripting Language for Mobile Agents in Enterprise Applications," in Proceedings of the 2nd Asia-Pacific Conference on Intelligent Agent Technology (IAT 2001), Maebashi, Japan, 2001, pp. 124-128.

207

[18] "Voyager Edge: http://www.recursionsw.com/Products/voyager.html ". vol. 2007: Recursion Software, 2007.

[19] F. L. Bellifemine, G. Caire, and D. Greenwood, Developing Multi-agent Systems with JADE. Chichester: John Wiley and Sons, 2007.

[20] R. Laddaga, "Active Software," in Self-Adaptive Software: First International Workshop, IWSAS 2000, Oxford, UK, April 2000. Revised Papers. vol. 1936, P. Robertson, R. Laddaga, and H. Shrobe, Eds. Berlin / Heidelberg: Springer 2000, pp. 11-26.

[21] G. McCluskey, "Using Java Reflection http://java.sun.com/developer/technicalArticles/ALT/Reflection/index.html," 1998.

[22] P. Braun, I. Mueller, R. Kowalczyk, and S. Kern, "Attacking the Migration Bottleneck of Mobile Agents," Technical Report: SUTICT-TR2005.01, 2005.

[23] F. M. T. Brazier, C. M. Jonker, and J. Treur, "Principles of Component-Based Design of Intelligent Agents," Data Knowledge Engineering, vol. 41, pp. 1-27, 2002.

[24] T. Putnam and K. Liu, "Automated Exchange Of Software Resources, Components, Services, And Products," in 25th IASTED International Multi-Conference on Software Engineering, Innsbruck, Austria, 2007, pp. 249-254.

[25] G. P. Picco, "Mobile agents: an introduction," Microprocessors and Microsystems, vol. 25, pp. 65-74, 2001.

[26] P. Braun and W. Rossak, Mobile Agents Basic Concepts, Mobility Models, and the Tracy Toolkit: Morgan Kaufmann Publishers, 2004.

[27] S. H. Chuah, S. W. Loke, S. Krishnaswamy, and A. Sumartono, "CALMA: Context-Aware Lightweight Mobile BDI Agents for Ubiquitous Computing," in Workshop on Agents for Ubiquitous Computing, in conjunction with AAMAS 2004, New York, 2004.

[28] M. A. Munoz, M. Rodriguez, J. Favela, A. I. Martinez-Garcia, and V. M. Gonzalez, " Context-aware mobile communication in hospitals," IEEE Computer, vol. 36, pp. 38- 46, 2003.

208