Mathematical and Computer Modelling 52 (2010) 2097–2117

Contents lists available at ScienceDirect

Mathematical and Computer Modelling

journal homepage: www.elsevier.com/locate/mcm

Bio-inspired self-organization for supporting dynamic reconfiguration of

modular agents
Kiwon Yeom ∗
Department of HCI and Robotics, University of Science and Technology, Daejon, Republic of Korea
Intelligence & Interaction Research Center, Korea Institute of Science & Technology, 39-1 Hawolgok 2-dong Seongbuk-gu, 136-791 Seoul, Republic of Korea

article info abstract

Article history: This paper presents an approach to develop and manage a self-organizing, distributed
Received 23 September 2009 computing system in dynamically changing environments. In the proposed approach, a
Received in revised form 25 December 2009 target application is characterized by a collection of distributed, autonomous, and diverse
Accepted 31 January 2010
mobile agents, designed to mimic the adaptive behavior of biological systems. Each
mobile agent is implemented as dynamic modular components, which can automatically
Keywords:
migrate and reconfigure while the application is being executed. Assemblage of modular
Self-organization
Federation of agents
components can be altered according to the local migration schemes of agents, which
Modular agents include deployment behavior based on biological processes. This paper presents an
adaptive architecture, which can reorganize and reconfigure agents based on several
different biological concepts and mechanisms. We describe several key features of the
modular components, the design methodologies and implementation of the modular, self-
organizing framework, and demonstrate how the framework satisfies a set of functional
requirements derived from specific agent behavior. We also present some simulation
results to examine the scalability and efficiency of the framework.
© 2010 Elsevier Ltd. All rights reserved.

1. Introduction

A key observation of current and upcoming distributed applications is that autonomous adaptation to dynamically
changing environments is a emerging issue. It is easy to imagine that many people will connect to and disconnect from
running applications via global networks as a part of their daily lives. In other words, future networked applications may be
inherently susceptible to issues of complexity and scale. Additionally, such applications will be confronted with continuous
requests from users or their environments for various reasons.
In nature, biological systems, such as cells, ants, or bees have developed adaptation mechanisms to live and survive in
changing environments. They have developed the ability to enlarge in scale without any centralized control because they
can behave autonomously, influenced by only local conditions and individual interactions with other nearby entities [1].
The social network of bee hives, for example, is that of a distributed system, with each member producing effects that
pervade the hive. The queen bee acts as an egg production specialist rather than a controller that organizes the colony. Each
member of the hive acts as a member of a social group. Within each social group, or network, collections of individuals will
develop associations and communication systems [2]. The behavior of individual insects is directly affected by the behaviors
of and communications with other individual insects. For instance, a bee could enter a hive exhibiting one social role and
leave with an entirely different role. These individual behaviors are called phenotypes and contain a set of measurable traits.
Phenotypes that can be observed at a group level, such as the division of labor, are called emergent properties.

∗ Corresponding address: Intelligence & Interaction Research Center, Korea Institute of Science & Technology, 39-1 Hawolgok 2-dong, Seongbuk-gu,
136-791 Seoul, Republic of Korea.
E-mail address: pragman@gmail.com.

0895-7177/$ – see front matter © 2010 Elsevier Ltd. All rights reserved.
doi:10.1016/j.mcm.2010.06.018
2098 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

As social groups coalesce, individuals take on certain tasks while ignoring others. Some particular members of an
association will perform a certain task, making other members of the social group less likely to perform that task. Individuals
assume particular tasks based on their tolerance threshold for neglecting such tasks. For example, some bees will set out
to gather pollen at the first sign of reduced pollen levels in the hive. Other bees will join the gathering task only when the
pollen levels of the hive drop below a certain level. This behavior can be found in individuals in all social networks [3,4].
A Ubiquitous, or Pervasive, computing environment is becoming even more common [5]. In the near future, the
ubiquitous computing calls for the deployment of a wide variety of smart devices throughout our working and living
spaces [6]. Furthermore, many devices will be mobile. They are expected to dynamically discover other devices at a given
location and continue to function even if they are disconnected. The overall goal is to provide users with universal and
immediate access to information and to transparently support them in their tasks [7].
The ubiquitous computing space can thus be envisioned as a combination of mobile and stationary devices that draw on
powerful services embedded in the network to achieve users’ tasks [8]. The result will be a giant, ad hoc distributed system,
with tens of thousands of people, devices, and services coming and going. Therefore, networked applications will need to
become more scalable, autonomous, and adaptive. They will need to be resilient to dynamic changes inside the network such
as changing network traffic and fluctuations in available resources relative to the number of users. They are also expected
to extend the duration of service of applications and reduce maintenance costs [9].
An application can be run on a group of one or more computers to gratify its own requisites, which may be beyond the
capabilities of an individual computer. Such a group has to be reconfigurable during runtime because user devices may vary
depending on what needs to be done, and very often they may connect to and disconnect from the network sporadically.
It is difficult to adapt to changes in user requests or changes in execution environments during runtime such as the
spontaneous addition and removal of components and changing network topology. These factors will be more critical in
both ubiquitous computing environments and large scale distributed systems such as grid computing environments [10,11].
Since computational resources such as processors, storage, and input and output devices are heterogeneous and limited, an
individual system can only support its own applications [12]. Consequently, future networked applications will be expected
to be scalable, autonomous, and adaptive in order to respond to dynamic network environments [13,14].
In the process of realizing future network applications with the aforementioned characteristics, we found that various
biological systems have already developed the mechanisms necessary to achieve the key requirements of future network
applications such as autonomy, scalability, adaptability, and simplicity [13,15]. The proposed architecture is motivated by
the observation of such desirable properties, thereby drawing inspiration from biological systems. The objective of our
long-term research is to develop autonomous adaptive agents for large scale, network-based or Internet-based, ubiquitous,
distributed computing environments. In order to accomplish this goal, we have come up with a novel architecture called
the ‘bio-inspired reconfigurable and adaptive agent framework’, which is attributable to several biological concepts and
mechanisms [15–17].
In this paper, the author describes a self-organizing system framework that allows for highly distributed and dynamic
network applications using autonomous adaptive agents. This paper introduces several key features of the autonomous
adaptive agents in our architecture and depicts functional requirements for our agent-based framework. This paper presents
how the agents can combine and reorganize a collection of components, which may execute on heterogeneous computing
environments, and modify their associated contexts (e.g. locations, tasks, etc.) in accordance with user requirements. We
describe the design and implementation of the framework, showing how the proposed framework satisfies the expected
requirements of future networked applications. In order to explore the scalability and efficiency of the framework, we
present some results from our initial empirical computations.
This paper begins with a brief description of the related work in Section 2. Then we describe the issues that we consider
are necessary for the framework in Section 3, followed by a description of the design goals for the framework in Section 4.
We then describe its design and a prototype implementation in Sections 5 and 6, respectively. In Section 7, we discuss our
simulation results and we conclude with a summary of our work and several future issues in Section 8.

2. Related works

In this section, we describe several biologically inspired approaches to distributed and multi-agent systems. Our platform
is similar to existing mobile agent platforms, such as Aglets, Voyager, JumpingBeans, and Grasshopper [18–20,4], in the
sense that it implements a weak migration mechanism for agents. In contrast, the proposed framework emphasizes the
decentralized combination and reorganization of agents on distributed network environments based on biological concepts.
Most existing agent platforms presuppose the existence of a host controller or of centralized agents. For instance, Hive
deals with decentralized agents [18], but its current implementation is based on a central host and deployment of the remote
message by Java RMI. In contrast, the proposed framework allows agents to organize a virtual network among agents using
their functionalities and relationships. They also carry out distributed discoveries through interactions with each other,
which results in social networking.
There are several platforms which provide social networking functionality such as OceanStore, Pole, and Co-Field [20,4,
21]. The discovery mechanism for them is based on structured peer-to-peer communication with a distributed hash function
on the whole overlay network. Such discovery mechanisms are very expensive, and it is hard to maintain their structure in
dynamic network environments, where individuals frequently join and leave.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2099

Fig. 1. Group migration in distributed systems.

Alternatively, instead of depending on any distributed hash function, our framework is designed on a loosely coupled
virtual network of agents in order to adapt to dynamically changing environments. It also provides a flexible discovery
scheme that allows agents to detect and specify the corresponding cytokine/chemokine (pheromone), which affects the
behavior of other agents of the same type (e.g. attracting them sexually).
In a few attempts, the architecture for real distributed systems have been presented. For example, the Anthill project
established a bio-inspired middleware for peer-to-peer systems, which consists of an aggregation of interconnected
dens [22]. Autonomous agents, called ants, can move around the network to satisfy user requests. The main difference
between Anthill, including its applications, and our proposed framework is that agents are independent objects that can
accomplish their tasks and are flexible components that can be combined with and segregated from each other through the
proposed framework. The Co-Field project suggested the concept of a general coordinator for the movements of agents and
organization of a group of agents, which consist of mobile devices and mobile robots. However, it is only available within
limited simulation environments.
In our framework, there are two key ideas. The first is to implement components as mobile agents that can travel between
computers, regardless of being homogeneous or heterogenous, under their own migration schemes. That is, each component
can autonomously migrate to another computer or duplicate and send its copies of itself to others. The second is to facilitate
the dynamic association of one or more components over distributed systems. The framework supports low-level operating
and networking details (e.g. marshalling and unmarshalling, I/O and concurrency) for agent’s migration and communication.
This architecture also provide agents with seamless runtime services without any system interruption.

3. Biologically inspired approach

The goal of this framework is to provide a general scheme that enables applications on a distributed network environment
to be deployed, migrated, and reconfigured dynamically in order to accomplish some tasks successfully.

3.1. General concept of mobile agent based applications

The proposed framework presupposes that each application is composed of one or more components as shown in
Fig. 1. Each component has a mobile single-cellular structure (modular agent or motile cell), since it is self-comprised and
self-roving. A collection of components is akin to pseudo-deformation in biology because such a combination can modify
the structure of a group of components. These collections have the ability to move around within a distributed system
and partially relocate their constituent components in accordance with changes in the system, network status, and user
requirements (see Fig. 2).
The framework provides interaction measures for the migration of components. It controls the migration of components
to other computers to accomplish particular requirements or tasks. For instance, when the framework detects any changes
in a user’s positions, it provides necessary migration information to the relevant agents such as the address of destination
computers (which uses the locational information services we presented in [13]). Components then transmigrate to the
destination. If the computing environments have also changed (e.g. from a desktop to a laptop or PDA), a suitable component
which can support user preference is also migrated to the new environments.

3.2. Afflatus motivated from observation of biological mechanism

Applications should be able to run on any computer in order to satisfy their requirements and tasks. However, it is difficult
to deploy components to appropriate computing devices on any distributed computing environment where computing
devices are dynamically combined and separated [23].
The requirements for accomplishing user requests may vary and the resulting complexity of applications may increase
considerably. For example, mobile users may want to receive consistent service from the current environment. That is,
regardless of the user’s location or other environmental variables, the user wants constant interaction with the computing
environment. Consequently, applications should be able to travel from computer to computer to adequately serve users [24].
Therefore, the proposed framework should enable a group of components to partially or completely (i.e. a complete
2100 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Fig. 2. Migration and organization of network-enabled components.

application) migrate to suitable computing devices according to changes in the user’s conditions and associated context
(e.g. user’s location, designated tasks, the overhead of components).

3.2.1. Aggregation of mobile components as cell-filopodia

The filopodia (also called microspikes) are slender cytoplasmic projections, which extend from the leading edge of
migrating cells [25]. They contain actin filaments, cross-linked and form focal adhesions with the substratum, linking it
to the destination cell surface [26]. A cell migrates along a surface by extending filopodia at the leading edge. The filopodia
attach to the substratum further down the migratory pathway, then contraction of stress fibres retracts the rear of the cell
to move the cell forwards [27,28].
The framework should be used to develop an unicellular application as a set of agent-based components for components
or applications, which are able to migrate to other computing devices and reorganize components while the application
is running [29]. The movement of one component may affect other components. For example, two components, which
have different latencies in communication and velocities in movement and reorganization, are requested to simultaneously
combine by a nearby computing device. One is for the control of the keyboard and another is to display content on the screen.
Since each component has its own unique properties and control strategy, synchronizing a collection of components tends
to be impossible over a distributed network environment. Therefore, components cannot efficiently coordinate with each
other.
In our framework, agents collect and aggregate components around specified components like the aggregation of
Dictyostelium discoideum (see Fig. 3(a) [30]). In contrast, the second scheme makes replication of components to maintain
itself at the source, like inter-cellular exchange (see Fig. 3(b) [31]).
Therefore, the framework ought to enable each component to explicitly specify its own restraints for migration and
reorganization. For instance, imagine a component, called the master component, whose migration behavior is dependent
on another component, called the servant component. If the master component, which is needed for normal activity of the
servant component, moves to another location, then the servant component has to determine whether it remains stationary
or moves according to the location change of the master component (see Fig. 2). Such inter-constraints can be defined
as migration schemes for the components. These inter-constraints also specify the physical structures of the agents for
interaction with each other and outline specific migration mechanisms of mobile cells, such as membrane and cytoplasmic
streaming and gel-to-sol transitions [32].

3.2.2. Migration of components as cell-lamellipodia

The lamellipodium (plural lamellipodia) is a cytoskeletal actin projection on the mobile edge of a cell. Lamellipodia
are found primarily in very mobile cells, allowing them to crawl at speeds of 10–20 m/min over epithelial surfaces. A
lamellipodium separated from the main part of a cell (by scratching across the cell with a pipette tip) can continue to crawl
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2101

Fig. 3. (a) D.discoideum aggregation of the cells [30]. (b) Inter-cellular exchange in young living lymphocyte cells [31].

freely. They are believed to be the actual motor which pulls the cell forward during the process of cell migration. When
they pull one another, their stretched cortex extends to arbitrary regions. This continues until a lamellipodium creates a
dominant direction (pathway) to move, then it migrates in that direction [25].
The phenomenon of lamellipodia can be regarded as speculative migration, which is used as a basis for the migration of
mobile agent-based components. A component has to migrate to one of the most suitable computing devices under their
own control and constraints to satisfy their requirements and tasks. However, it is not always possible to decide exactly
which destination is the most suitable. For this reason, the proposed framework allows a component to simultaneously
distribute its clones to multiple computing devices. The framework then selects the most suitable clone while the others
naturally vanish. This mechanism corresponds to the expansion process of lamellipodia for migration in mobile cells.
2102 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Fig. 4. Architecture of the proposed framework.

3.2.3. Self-organizing architecture

Our framework should be used to allow network protocols to manage the migration of mobile agents within a distributed
network environment and as a middleware for self-organizing adaptive systems in distributed computing systems (see
Fig. 2). We can easily imagine that there may be many different approaches for component management in a distributed
system because most applications have their own specific management strategy. Therefore, the framework should be
independent of any component deployment and organization approaches and of any biologically inspired processes [33].
The proposed framework can be employed as a general middleware architecture, which enables components to be
exchanged between computers and allows applications to be implemented utilizing such components. That is, each
component can have its own control and constraints for specifying spatial relationships between its location and other
components’ locations at neighboring computing devices. As a result, instead of any global policy, a collection of components
should be managed through the association of the components’ schemes.

4. Design principles of the framework

The framework presented in this paper was implemented in JDK version 1.4.2. It consists of two parts, mobile agents
and agent hosts. The first defines partitioned applications like a client in a server/client architecture. The second, which
corresponds to a server in a server/client architecture, is a middleware and enables components to travel from computer to
computer.

4.1. Component-based modular architecture

In the proposed framework, each agent consists of a head, a body and activities (see Fig. 4). The head carries descriptive
information regarding an agent (e.g. identifier). The body implements the agent’s functional services.
For instance, one agent may include software code for control of devices, while another agent may implement reservation
services for a hotel, train and airplane in its body. Activities implement non-functional biological behavior that are inherent
to all agents (e.g. reproduction and migration).
Each agent lives on a specific framework to execute its functional service implemented in its body. Our framework runs
on each network node. Through a set of runtime services provided by a local framework, each agent continuously senses
the current surrounding conditions in the network (e.g. network traffic) and performs accordingly. For clarification, Fig. 5
has been redrawn as follows (refer to CCA forum [34]).
Firstly, as shown in Fig. 5, the agent must be bound to the framework for any services or any actions because of security
issues. Secondly, a single component agent may be able to provide a service by itself. Thirdly, the framework should provide
a binding service for component binding in distributed environments. Therefore, the framework has to provide a structure
(i.e. container, Fig. 5(a)) that executes a life activity and combines other components (see Fig. 5(b)). These features are mainly
handled by the agent manager. The framework is implemented in Java, and each framework runs on a Java Virtual Machine
(JVM) (Fig. 4). Each agent is implemented as a Java object and runs on the proposed framework.
The framework, as shown in Fig. 4, is composed of six architectural components. First, Framework Indicator is an object
that represents the framework running on a computing device and runs on a per-framework basis, which means that
multiple framework instances can be executed at the same time. It maintains a table which lists all of the services in the
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2103

a b

Fig. 5. (a) Inner structure of agent. A component based agent has two interfaces to connect with other agents and one channel which is used to communicate
with its host. (b) Framework for components binding. A component has to be inside a container to execute its functionality.

Fig. 6. Internal message process design of agent.

service provider and all of the agents in the agent manager on a local framework along with their names and references. It
is initialized when a framework starts up.
Agent Attribute is an entry point for an agent to access underlying framework instances. If an agent requests a service to
the framework, the framework examines if the requested service is available. If it is, the agent attribute returns a reference to
the service. Each agent attribute performs this lookup for the services through the local framework indicator. Each agent has
its own attributes. An agent attribute is automatically generated and associated with an agent which has the life-cycle service
(one of the services, see Section 3.2.1) when the agent is created, replicated, and reproduced, or completes a migration.
Service Provider provides a set of runtime services that agents use to accomplish their activities. Each service consists of
one or more activities involving agents. The activities which our framework currently supports are migration, replication,
reproduction, agent discovery, resource sensing, and energy transaction.
Agent Manager maintains a table that contains references to all the agents running on a local platform. It also plays a
role to dispatch incoming messages to these agents. The message is delivered by a message transmitter which abstracts
low-level networking and operating details, for example, network I/O, concurrency, messaging, and network connection
management, etc. It follows the message transmission and object adapter of ORB [35] for the object activation and call, and
the table maintenance and message dispatching. It also keeps track of the network traffic load by computing the number of
dispatched messages and received packets.
Message Transporter is to allow different types of information to be sent between networked devices. The main purpose
of a message handling system is to provide a means for transferring messages from one messaging host to another. This
message transfer may occur on the same host, between hosts in the same organization, or between distant hosts in different
networks, etc.
Class Loader is a customized class loader that extends the default class loader of the Java Virtual Machine (JVM). It is used
to dynamically load/unload the object of a agent’s class into a JVM when it is newly produced, destroyed, or migrated.

4.2. Interfaces of agent based on component design

For the proposed framework, we define two interfaces for agent communication (see Fig. 6).
The send() and receive() methods are used to communicate with each other. The message format for agent communication
follows that of the FIPA [36]. More details are described in [36,37]. The agent communication process is as follows: the agent
sends a message through the interface of send(), it receives a message from another agent. These two message exchange
processes occur asynchronously. That is, during message transmission an agent can accept a message from other agents
simultaneously. The reason why we chose an asynchronous communication manner instead of a synchronous approach
is because it allows for better scalability and more stability in terms of service availability. Specifically, it reduces system
response time, throughput, and system and network load relevant to the agent. The framework allows for continuous service
without any system halt since message transmission does not need to wait for any response.
2104 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Fig. 7. Three main constituents of agent.

The send() operation inserts a received message in the agent’s message queue (Fig. 6). The agent then brings the message
into an individual thread to process it. If there is no available message in the message queue, the thread waits for a new
message. Since all the messages in a queue are included in the agent class object, when an agent migrates to another platform
with unprocessed messages they are also transmitted and processed at the destination [38].
Each agent maintains another thread to carry out its non-functional activities, as mentioned at the beginning of this
section. We assigned different threads for functional and non-functional purposes since these activities operate at different
durations. In other words, from a functional aspect, a thread should be executed the moment a message arrives in the queue;
however, the thread relating to non-functional activities is executed depending on application requirements.

4.3. Constituents of agent

An agent consists of three main parts: Head, Body, and Activities (Fig. 7). The head carries descriptive information
regarding the agent (e.g. agent ID and a description of the type of service it provides). The body implements a service
that the agent provides and contains materials relevant to the service (e.g. data, application code, user profiles). For
instance, one agent may implement control software for a device in its body while another agent may implement a hotel
reservation service. Activities implement non-service-related actions that are innate to all agents. Examples of activities
include migration, reproduction, and energy exchange.
(1) Agent Head: The current design of the framework defines the head information and metadata that all agents have
to maintain. The getHead() operation of an agent is used to obtain head information and metadata of an agent (see Fig. 6).
The essential information for an agent head is (1) the agent’s GUID (globally unique ID), (2) the agent’s reference and the
metadata, (3) the available service, and (4) the energy ratio. A GUID is a special type of identifier used in software applications
to provide a reference number for some entity, which is unique in any context. In our framework, we design the GUID using
32 bits of hexadecimal digits, such as {3F2504E0-4F89-11D3-9A0C-0305E82C3301}, which is generated by the platform
where the agent originates.
An agent’s GUID is unique and does not change throughout the lifetime of an agent. An agent’s reference is the entry point
for communication, which is required for message transmission and acquisition. It includes the encapsulated IP address and
port number of the framework where the agent currently resides. When an agent migrates, the IP address and port number
are renewed to those of the framework which it migrates to. The description of a service is the name of the service that an
agent provides. Energy ratio, which an agent maintains, varies according to the service it provides and its non-functional
activities. For instance, if an agent is created with 100 energy units, when it calls a service that requests 20 energy units
the overall energy level is changed to 80 units. Another example is when an agent, which has only 30 units, is frequently
requested by other agents, its energy unit is automatically increased according to the energy management policy.
(2) Agent Body: The body is the part that defines the service which the user wants to implement. It follows the component
object model (COM) guideline. Therefore, the service that an agent provides is dependent on user or system requirements
(e.g. data, component/application code, user preference or user profiles, etc.). Implementation of the body is left to the
developer and the user of the framework.
(3) Agent Activities: Agents autonomously behave, modeled after simple biological mechanisms. Some examples of the
agent activities are described next.

• Resource and environment sensing: Agents are acutely aware of their surrounding environment. For example,
agents recognize which other agents exist in the environment and what services are available. Agents also sense specific
cytokines/chemokines, which other agents leave on remote frameworks, and resources which include CPU processing
power or memory space on remote frameworks.
• Discovery and relationship management: Agents can establish relationships with other agents and seek agents
with certain attributes by forwarding queries to agents that they have relationships with.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2105

• Cytokine/chemokine diffusion: Agents can leave a cytokine/chemokine (or a trace) behind on a framework when
they migrate to another framework. This action indicates their presence to other agents. A cytokine/chemokine contains
the agent’s GUID and a reference to the framework that the agent migrated to. Cytokine/chemokines are emitted with
certain strengths and may decay over time. Cytokine/chemokines may have a variety of uses, which include improving
the performance of discovery.
• Communication: Agents may communicate with other agents for the purposes of, for instance, requesting a service,
forwarding a discovery query, or exchanging energy.
• ATP exchange and store: Agents can receive ATP1 from other agents or framework and store energy. They can also
consume energy. For example, agents may expend a certain amount of energy units for a service that they request to
other agents. In addition, when an agent utilizes resources on a framework (e.g. CPU and memory), it may pay energy
units to that framework.
• Migration: Agents can migrate from one framework to another.
• Life-cycle management: Agents can manage their life-cycles. Agents may make a copy of themselves (replication)
with possible mutations with regard to the replication scheme. Two parent agents can create a child agent (reproduction)
with possible crossover and mutation with regards to the reproduction scheme. Agents may also die (death) from a lack
of energy. If the energy expenditure of an agent is not balanced in regards to the energy units it receives by providing
services to other agents, it will not be able to pay for the resources it needs and will consequently die from the lack of
energy. Agents with wasteful behavioral schemes (e.g. replicating or migrating too often) will have a higher chance of
dying from energy deficiency.
The framework implements the activities described above. Each activity is composed of one or more runtime components
and services provided by the framework. When an activity is invoked, corresponding runtime components and services are
also designated.

4.4. Behavioral principles of modular components

It is almost impossible to automatically divide existing standalone applications into multiple sub-modules or smaller
independent applications. Therefore, the implementation of this framework is based on the construction methodology of a
component object model (COM) based application. That is, an application is loosely composed of other components, which
may execute on different computing devices. Each component is an assembly of Java Bean objects in standard file format,
which not only migrates from computer to computer but can also duplicate itself and create a different child component
through the combination of two parent components. When components arrive at their destination or are duplicated, each
component can continue working without any loss of their previous work such as the contents of instance variables and
methods in the component’s program at the source computing devices.
A component includes its own GUID and an identifier of the association that it may belong to. It can explicitly specify
the computational capability on its destination hosts by filling the CC/PP (composite capability/preference profiles) form,
which is described by the World Wide Web Consortium [35]. If a component is on a computing device that cannot satisfy
its requirements or tasks, the component is removed from the computing device. In order to remove an agent, the life-
cycle management service provides a destruction operation. The destruction operation frees the resources (e.g. memory
and threads) that a dying agent utilizes, removes components from the energy table in the energy management services,
and unregisters the dying agents from the container of the framework. Of course, the component can leave the host device
without destruction or any energy loss.
The current implementation supports several migration strategies for the mobile components. Although it will be
discussed in the following section, we will present two basic migration strategies here.
• When a component that is connected to other components moves to another destination, the connected components
may also migrate to the destination or to a nearby suitable host (Follow Scheme, Fig. 8(a)).
• When a component that is connected to other components moves to another destination, the connected components
may replicate or reproduce themselves at their current location and then send the copies to the destination or a nearby
host (Replication Scheme, Fig. 8(b)).
Fig. 9 shows an example of the group migration of three components. When component B has a ‘follow scheme’ for
component A, and component C has a ‘replication scheme’ for component A, then if component A moves, component B
moves to component A’s destination host because the host satisfies component B’s requirements. Component C, however,
remains at its source and a copy of component C moves to component A’s destination. Each component may change its
activity schemes while running [38]. Some components within an association may be mobile or stationary according to
their surrounding environments or requirements. That is, they can change their scheme according to changes in their
environments or requirements. This is abstracted from the reversible ‘sol to gel to sol transition’ behavior where the motile
cells change their status with increasing temperature.

1 Adenosine 5’-triphosphate (ATP) is a multi-functional nucleotide that is most important as a ‘‘molecular currency’’ of intracellular energy transfer. It
is produced as an energy source during the processes of photosynthesis and consumed by a multitude of cellular processes including motility and cell
division. ATP is also incorporated into the processes of DNA replication and transcription. In signal transduction pathways, ATP is used to produce the
second messenger molecule.
2106 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Fig. 8. (a) Migration with Follow scheme. (b) Migration with Replicate scheme.

Such schemes may be similar to the dynamic layout of distributed applications in [39]. However, our schemes aim at
allowing a component to describe its own migration and association strategy because, in principle, our framework defines
the components as autonomous entities, which migrate from a computing device to other computing devices under their
own control.
Notably, our approach is free of any conflict because each component is allowed to follow its own behavior scheme as
well as exchange its scheme. Each component can have references to other components in the association that it belongs to.
The reference allows components to interact with other components even when the former and latter components reside
at different computers or move to other computers.

4.5. Migration schemes

While components are executing, they can maintain their own migration scheme by invoking the setScheme method,
which was explained in the previous section. The first argument (CompProfile cref) is a reference to another component.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2107

Fig. 9. Examples of component group migration with follow replication schemes.

The second argument is an instance of the MigScheme class. When a component migrates from its source to its destination,
the component selects and conducts one of the following actions:

• MigScheme(Scheme.Follow). The component migrates to the destination computing device.

• MigScheme(Scheme.Replicate). The component duplicates itself and its clone migrates to the same destination.
• MigScheme(Scheme.Reproduce). The component duplicates itself and its clone migrates to the destination.
• MigScheme(Scheme.Change). The component does not copy itself; it migrates and combines with other components
at its source.
2108 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Follow Follow

Replicate Replicate

Reproduce Reproduce

Change Change

Stay Stay

Distribute Distribute

Fig. 10. Examples of basic migration schemes.

• MigScheme(Scheme.Stay). The component stays and waits at the current host.

• MigScheme(Scheme.Distribute). The component duplicates itself and dispatches its copies to several hosts.
Each component may have at most one scheme and Fig. 10 outlines six basic schemes where two components (B and C)
have schemes for a specific component (A).
These schemes are related to phenomena observable in biological processes. For example, Scheme.Follow enables a
component to follow the master component. When multiple components have a scheme for a master component, they
can gather around the master component. Scheme.Replicate enables servant components to keep track of the movement
of a master component. These schemes naturally correspond to the phenomenon of inter-cellular exchange of the cell.
Scheme.Reproduce allows a component to stay in its current host and then dispatch its clone to the destination of a moving
master component, which is inspired from the phenomenon of motile cell location change.
In our framework, all components have their own energy units. Life-spans are specified when a component is created,
replicated, reproduced, and migrated. For instance, when a master component leaves a clone behind after moving, if the
clone has a very short TTL value then the clone component plays a role of cytokine/chemokine to attract other components
to follow the relocated component. After a certain amount of time, the clone component is automatically removed from the
system.
The framework is open to new migration scheme strategies as long as they maintain the MigScheme class architecture.
Therefore, we can easily define new schemes, including bio-inspired ones.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2109

Fig. 11. Basic structure for runtime service. Dotted line shows an example of agent migration and dash–dotted line shows the example of the component
copy operation as a result of agent communication.

5. Design of agent host and networking

The host, which executes actions relating to each component or a collection of components (an application) on a platform,
provides a runtime service for executing and migrating components to other computing devices.
Fig. 11 outlines the basic structure of a runtime system which is modified from ORB architecture (refer to [35] for basic
CORBA architecture). Each host establishes at most one TCP/IP connection to each of its neighboring hosts and exchanges
control messages, components, and inter-component communications with the other hosts through the connection. Since
the host is constructed on the Java Virtual Machine, it can disregard differences between the platform architecture of the
source and destination hosts, such as the operating system and hardware specifications.

5.1. Kernel of reflection

Core Kernel of Reflection manages the ‘Core Runtime Service (CRS)’, which is responsible for reacting to any changes in
the environments. The Java standard environment only allows for bytecode transformation at load time. At runtime, it is
only possible to dynamically generate new classes from scratch, not modify existing ones. Furthermore, the possibilities of
class reloading are strongly limited since new members cannot be added to classes. However, the proposed framework uses
‘load-time bytecode transformation’ technology in order to be applicable to binary components and in settings where all
classes are not known until they are actually loaded (e.g. open distributed systems).
To make classes dynamic on runtime, we use a methodology for load-time structural reflection introduced by [40]. As
mentioned in Section 4.1, the framework implements a customized class loader from Java. CRS relies on this class loader.
When requested by the virtual machine, the loader forwards the request to a class pool in charge of locating class definitions.
When a class is located and about to be loaded, the class pool can notify a translator which can then modify the class. To this
end, the translator can obtain reification of classes as CtClass objects. CtClass offers the same introspection capabilities
as those of the standard reflection API of Java plus intercession capabilities (e.g. adding/modifying a member, changing the
superclass, altering method bodies).

5.2. Runtime service for components

Component Runtime Service Component Runtime Service handles all the components inside the framework and maintains
the life-cycle state of each component. That is, when the life-cycle state of a component changes (e.g. when agents are created
or migrate to another host) the runtime service changes the energy units of the component. This is because the components
may have limited life-cycles and they can earn/expend energy units by various activities such as the acquiring/releasing of
resources, migration, replication, reproduction, etc.
The framework offers an RDF based CC/PP profile, which is a description of device capabilities and user preferences.
This is often referred to as a device’s delivery context and can be used to guide the adaptation of content presented to that
device (see Fig. 12). For example, a description contains information regarding the properties of a computing device such as
the vendor and model class (PC, PDA, or phone), screen size, number of colors, CPU, memory, input devices, and secondary
storage.
Each host informs the components that exist inside of the host or neighboring hosts about its CC/PP profile. Then each
of the components may autonomously select and migrate to one of the most suitable destinations. In addition, since each
component can count coexisting components with similar types or functionality at the same host, it can leave the host with
high component density.
2110 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Fig. 12. Example of CC/PP profile fragment referencing externally defined defaults [41].

5.3. Component migration management service

Component Migration Manager manages component migration from one host to another host based on the mobile agent’s
networking mechanism. When a component is transported over a network, the host, which is sending a component, converts
the component’s object/data code into a byte-stream and then transfers these with state information to the destination
(marshalling). Another host, which receives the marshalled byte-stream code, uses a reverse process to restore the byte-
stream back to its original object/data (unmarshalling). The purpose of this networking process is to transfer an object
between hosts.
Our framework uses Java’s object serialization mechanism for marshalling/unmarshalling the components. There are two
critical elements for communicating with remote objects, stubs and skeletons (generic codes). A stub for a remote object
acts as a client’s local representative or proxy for the remote object. The caller invokes a method on the local stub, which is
responsible for carrying out the method call on the remote object. A stub for a remote object implements the same set of
remote interfaces that a remote object implements. When a stub’s method is invoked, it does the following:
1. initiates a connection with the remote JVM containing the remote object,
2. marshals (writes and transmits) the parameters to the remote JVM,
3. waits for the result of the method invocation,
4. unmarshals (reads) the return value or exception returned, and
5. returns the value to the caller.
The stub hides the serialization of parameters and the network-level communication in order to present a simple
invocation mechanism to the caller. Therefore, the framework does not capture stack frames of threads.
In the remote JVM, each remote object may have a corresponding skeleton (in the Java 2 platform it is substituted by
generic code). The skeleton is responsible for dispatching the call to the actual remote object implementation. When a
skeleton receives an incoming method invocation it does the following:
1. unmarshals (reads) the parameters for the remote method,
2. invokes the method on the actual remote object implementation, and
3. marshals (writes and transmits) the result (return value or exception) to the caller.
Each host has a small database to keep the component states. When a component migrates to a different host, the source
host forwards messages to the component. If the components move to other hosts, it forwards messages to these relocated
components, and the destination host updates the databases of other hosts by multicasting control messages.

6. Prototype implementation

In this section, we introduce the base class, migration schemes of components, and coordination strategy.

6.1. Base class implementation

In this framework, each component is implemented as a collection of Java objects that are defined as subclasses of the
BioComponent
A component executes the movetoDestination(URL url) method to move to the destination host specified by a url. This
action is managed by the source host in the runtime service. The setTimetoLive() specifies the life-cycle, called Time-To-Live
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2111

(TTL), of the component. The life span decrements the TTL value in accordance with time and energy unit expenditure. If the
TTL value becomes zero, the component is automatically removed from the host. The setGID() method binds the component
to the identifier of the association it belongs to.

class BioComponent extends MobileEnv implements Serializable {

void movetoDestination(URL url) throws
NoSuchHostException {...}
setScheme(CompProfile cref, MigScheme mScheme,
Boolean coexist) {...}
setTimetoLive(int life-cycle) {...}
void setGID(GID gid) {...}
GID getGroupIdentifier() {...}
void setCompProfile(CompProfile cpf) {...}
CompProfile getCompProfile(CompRef ref) {...}
Boolean isSuitableHost(HostProfile hfs) {...}
void linstenAdapter() {...}
....
}
<Sample partial codes for main class>

6.2. Coordination of components

The component references are critical for tracking moving components and invoking their methods. This framework
provides the APIs for invoking the methods of components on local or remote computers.
Our programming interface for invoking methods is similar to CORBA’s dynamic invocation interface. It does not have to
statically define any stub or skeleton interfaces through a precompiler approach because our target is a dynamic computing
system (see the example invoking procedure):

\\ from local host

BioComponent bc1 = new BioComponent();
...
bc1.setScheme(ComProfile bc1_cref, bc1_mScheme, Boolean coexist);
bc1.setGID(F01AC42F);
...
Message msg = new Message("print");
msg.setArg("Say Hello")
bc1.envelop(msg);
bc1.movetoDestination(10x, 11x, 21x, 4x);
...
\\ moved destination host
BioComponent bc2 = new BioComponent();
bc2.GID = bc1.getGroupIdentifier();
bc2.cpf = bc1.getCompProfile(bc1_cref);
...
bc2.cpf.invoke(bc1.msg);
<Sample partial codes for invoking procedure>

This example describes the invoking procedure as a component moves from one host to another. The component receives
a reference at the current, which is given when the host is originally created. The reference is compared with the GID of the
host at the new location. Then other components can invoke the methods of the newly attracted component. In addition,
based on ORB’s publish/subscribe concept, our framework allows users to implement the generic remote publish/subscribe
mechanism that enables subscribers to express their requirements or tasks for an event. As a result, components may easily
recognize whether or not they can accomplish their requirements at the current host.
Each component can specify a requirement on its destination host by invoking the setCompProfile() method, which
provides the requirements of a component. The destination host may then recognize which task is requested by an incoming
component by executing the getCompProfile() method. The isSuitableHost() is a method that specifies whether or not a
particular host can satisfy the requirements of the component. Each component may possess a listenAdapter method,
which is a customized listener interface that catches events relating to any changes, issued by a host’s runtime service,
to surrounding environments.
2112 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Table 1
The protocol for message exchange.
Field Value set

Message header
DeliveryMode The same as that specified on the request
Expiration Derived from the request. Decide whether to degrade for processing time.
Priority Copied from the request
CorrelationID Copied from the request MessageID
Destination Copied from the ReplyTo property in the request
Message properties
RequestURI Copied from the requestURI property in the request message
BindingVersion Copied from the bindingVersion property
ContentType Inferred from the Envelope and presence of attachments
Message body
Body Serialized message according to the media type

6.3. Communication between agent manager

This section is non-normative and is intended to give an example of how the agent manager communicate with each
other. To communicate with another agent manager, a sender of source host has to set the values of corresponding host
header fields and a receiver has to validates the values set for the respective message header properties. This specification
assumes that the receiver.
class MSTransporter extends Message {
public void MessageTransport(Context ctx,
MessageProducer producer,
Message BioMessage,
String deliveryModeStr,
String replyToName, int priority,
long timeToLive
)
int deliveryMode = deliveryModeStr.equals("PERSISTENT");
Message.setMSDeliveryMode(deliveryMode );
Destination replyDestination = ctx.lookup(replyToName);
Message.setMSReplyTo(replyDestination);
Message.setMSPriority(priority);
producer.setTimeToLive(timeToLive);
producer.send(BioMessage);
}
<Sample partial codes for communication with message procedure>

The protocol for message exchange consists of 3 Conformation Value, Header, Properties, and Body. The header consists
of 5 fields and the Properties has 3 fields. The body has only one field to envelope serialized message. Table 1 is a brief
summary for Message protocol.

7. Experimental results

This section describes some of the initial measurement results regarding the footprint, efficiency, and scalability of the
proposed framework.

7.1. Environment configuration

In the empirical evaluation of the framework presented in this section, various measurements were obtained involving
varying numbers of agents (1 to 1000 agents) and frameworks (1 to 6 platforms). Three Windows PCs were used in the
empirical evaluation, each running the Java 2 standard edition JVM (version 1.4.2 from Sun Microsystems). These three PCs
were divided into three groups with two multithreads in each group, according to their CPU speed and memory size, as
shown in Table 2. These PCs were connected through 100 Mb/s Ethernet.
In order to measure elapsed time during agent execution in these experiments, we added several time measurement and
data gathering methods using native functions integrated in the components. In all events, when a component is created, the
time is recorded. The two key methods are readCountofCall() and writeIttoCounter(). The first function returns the number
of calls per second by other components, hosts, etc. The second function writes the current counter value.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2113

Table 2
Configuration of PCs used in simulation.
Group CPU (GHz) Memory (MB)

A Intel Pentium 4 2.0 512

B Intel Pentium 4 2.5 512
C Intel Pentium 4 3.2 1024

Table 3
Average bootstrap overhead and memory footprint.
Framework component Overhead (ms) Footprint (kB)

Message transport 11.98 3.32

Agent manager 130.02 4.44
Class loader 6.72 1.58
Framework indicator 34.11 6.29
Resource sensing 32.28 22.01
Energy management 49.01 4.73
Migration 12.43 2.98
Cytokine/chemokine emission 15.79 3.53
Discovery 32.43 9.48

In every experiment, to measure time duration we warmed up the JVM(s) before the experiment by executing
measurement code for a sufficient amount of time. Since Java byte code is generally optimized at runtime, the first several
experiments were discarded. Before each measurement, our framework and measurement code were optimized through
the JVM warm-up process. Then CPU, memory, and other utilizations were measured.

7.2. Simulation results

7.2.1. Overhead of bootstrap and footprint

Table 3 shows the average bootstrap overhead and memory footprint of whole framework instances. The bootstrap
overhead measures the time for the framework to initialize each framework instance, and the bootstrap memory footprint
measures the amount of memory space each framework instance consumes when it is initialized.
The measurement results demonstrate that the bootstrap overhead and memory footprint of each framework instance is
very small. The footprint of the agent management service is relatively large because the service creates a thread pool, which
consists of ten threads. The thread pool is used to improve the service response time for component requests. In lieu of a
thread pool, if 2 components arrive at a host, one of the components must wait till the other component service is over. This
situation may cause considerable latency in service and cause the system to stall. However, our framework is able to avoid
such issues through the introduction of thread pooling. Incoming components are allocated to the most inactive thread. This
ensures that all services will be served within a certain amount of time.

7.2.2. Overhead of sensing cytokine/chemokine

The total overhead of cytokine sensing is determined by the amount of time it takes for the cytokine sensing service
to find the migrating agent’s cytokine (by accessing a cytokine list maintained by the cytokine emission service), contact
a representative of the platform that the cytokine specifies (i.e. the platform that the agent migrated to), and locate the
migrated agent on the remote platform.
Fig. 13 shows how the overhead changes when an agent senses cytokines emitted on remote platforms, multiple hops
away. It also illustrates that the overhead of the cytokine sensing service is small and that it efficiently performs cytokine
sensing. Fig. 13 demonstrates that the overhead increases linearly as the hop count to remote platforms increases, which
indicates that the cytokine sensing service is scalable.

7.2.3. Overhead of typical activities

Table 4 shows the average overhead of typical activities such as the installation and execution of a component on the
framework. The total overhead to instantiate a component and conduct a set of activities was 2633.39 ms. The total overhead
to replicate a component through the life-cycle management was 2720.59 ms. In both cases, an initialized agent contacts
the local resource and environment sensing service to establish relationships with other located components on the same
framework instance. These two overhead results are reasonable since 10 000 components are simultaneously instantiated
and invoked on 6 PCs. Therefore, each activity of each component only takes a few milliseconds at most.

7.2.4. Roundtrip time of message

Fig. 14 shows the roundtrip time of a message between two components running on different frameworks. In this
measurement, a single component is deployed on a platform and a disparate set of components (from 101 to 104 receiver
2114 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

0.8

0.6

cdf
0.4

0.2

0
0 2 4 6 8 10
Number of hops

Fig. 13. Overhead of environment sensing (cytokine sensing) using cytokine emission services. The major overhead occurs when agent accesses cytokine
list which is maintained by agent host. In general, overhead increases linearly as the distance to remote hosts increases.

Table 4
Average overhead to install and initialize a component.
Activity Overhead (ms)

Class loading 17.26

Creation by manually 107.38
Instantiation
Replication by life-cycle management 394.58
Initialization 172.24
Discovers 100 agents via discovery service 677.59
Establishes initial relationship 1458.92

Deploy a new agent 2333.39

Total
Deploy a replicated agent 2720.59

101

100
Time (sec)

10–1

10–2

10–3 0
10 101 102 103 104 105
The number of agents

Fig. 14. Roundtrip time of message between two components on different frameworks. In general, roundtrip time increases as the number of agents
increases because the experiment was set for an agent to communicate with all agents within a network. However, the maximum time required is within
4 ∼ 6 s.

agents) is deployed on another platform. The sender randomly chooses one of the receivers and sends a component
initialization message to the chosen receiver. Then the receiver sends back an acknowledge message to the sender.
Fig. 15 shows that the roundtrip time is comparable with well-known Java-based distributed object platforms (CORBA
ORB and Java IDL), indicating that the networking interface for message transport is implemented efficiently. Fig. 15 also
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2115

107

106

bytes/sec
105

104

103 1
10 102 103 104
The overall throughput

Fig. 15. Comparing to other platform technologies.

40000
2nd biRNA agent
1st biRNA agent
30000

20000

10000

0
1 51 101 151 201 251 301 351 401 451 501 551 601 651 701 751 801 851 901 951 10011

Fig. 16. Change in throughput by life-cycle management.

shows that the roundtrip time remains relatively constant as the number of receiver agents grows up to 10 000, which
indicates scalability.
Fig. 16 shows the throughput of the proposed framework per component. We measured how many interactions were
exchanged, per second, between two agents. As Fig. 16 shows, two components running on different platforms can
send approximately 30 000 messages to each other per second. Note that the overall throughput dramatically decreases
after peaking at the 214 min mark. This decrease is due to the life-cycle management service. All components have a
level of energy units that may increase or decrease due to the frequency of calls from other components and hosts. So
once a framework instance is initiated, only the components which are optimized or fitted to the environment survive.
Consequently, this behavior can increase the consistency of the system and prepare it for service. This throughput result
shows that our framework is consistent and competitive with existing distributed object platforms. We also believe message
transport and the container structure are fairly efficient.

7.2.5. Overhead of social networking

Table 5 shows the overhead of each phase in the discovery and relationship process during component communication.
In this measurement, two components were deployed on different platforms. One of the components was specified as a
seeker component and established a relationship with the other component, called an answerer. The answerer maintains
the mandatory activities, which were described in Section 4.2.

7.2.6. Overhead of migration

Table 6 shows the overhead for an agent to migrate from one platform to another using the migration service. The
migration overhead includes the transmission time over the network and the processing time at both the origin and
destination platforms. As the size of mobile code grows, the overhead increases linearly, instead of exponentially, indicating
that the migration service is scalable.
Through observation, we noticed that the dominant factors which increase the migration overhead in our framework
is the process of serialization and deserialization of a component and their data size (see Table 6). In this experiment,
2116 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117

Table 5
Discovery overhead.
Phase in a discovery process Overhead (ms)

Relationship establishment b.w. 2 agents 2.36

Query initialization 0.73
Query forwarding 10.49
Guide matching 4.85
Complex matching 10.02
Query hit backtracking 16.84

Table 6
Migration overhead.
Size Data size (byte) Execution time (seconds) Migration time (seconds)
Level 1 4 8 1 4 8 1 4 8

1 024 49 316 49 732 50 321 0.534 0.548 0.567 0.018 0.018 0.018
2 048 98 168 99 024 99 675 1.725 1.757 1.778 0.041 0.041 0.047
4 096 193 872 197 788 198 376 4.799 4.821 4.997 0.096 0.103 0.104
8 192 391 480 394 916 399 684 11.021 11.534 11.891 0.179 0.192 0.198
16 384 783 696 787 292 788 120 24.185 24.478 24.729 0.327 0.386 0.394

160 100

90
140
80
120
70

CPU Utilization (%)

Number of Users

100
60

80 50

40
60
30
40
20
20
10

0 0
0:00
0:11
0:22
0:33
0:44
0:55
1:06
1:17
1:28
1:39
1:50
2:01
2:12
2:23
2:34

Elapsed Time (h:mm)

Fig. 17. CPU utilization.

we prepared two different PCs and deployed two frameworks respectively. Then multiple components, which were
implemented as internet users with different service levels, were dispatched on the first platform and subsequently moved
to the other. Each component implements a simple data read function that processes the GET request message, defined by
HTTP 1.0. A host implements the response to any component request with the same data size. When a component arrives at
another host, it reads the message in their message queue, saves the response data from the host, and returns to the origin
host. Each component maintains five different files whose sizes are 1 MB, 2 MB, 4 MB, 8 MB, and 16 MB.

7.2.7. CPU utilization

Fig. 17 shows CPU utilization of the web server and the proposed framework. The potential for high bandwidth has little
value in practice if communication overheads leave no CPU power to process the data. CPU utilization is just as important
as bandwidth since bandwidth will drop if application processing overwhelms the CPU.
All the optimizations we explore are fundamentally directed at reducing overhead. They indirectly increase bandwidth by
delaying utilization of the host CPUs. Running the proposed framework on a virtual machine has some overhead, especially
in regards to memory management, due to the nature of the application. The framework shows considerable stability in
minimizing this overhead. Fig. 17 also presents the relationship between CPU utilization and the number of concurrent users.
As seen above, the proposed framework normally runs with CPU utilization at 85%. Given these results, we can confirm that
the framework is stable and scalable enough with regards to the number of agents/users.
 K. Yeom / Mathematical and Computer Modelling 52 (2010) 2097–2117 2117

8. Conclusions and future work

This paper presented a middleware system comprised of dynamic collections of components on a distributed system.
Since the middleware enabled each component to migrate over a distributed system under its own scheme, the collection
was mobile and able to transform in a self-organizing manner. With biologically inspired principles and mechanisms,
network applications created based on the proposed architecture satisfy the key requirements of future network
applications such as autonomy, scalability, and adaptability. For example, it permits components to follow other moving
components and deploy their clones at different computers, similar to what happens in the locomotion of motile cells.
We designed and implemented a prototype middleware system and demonstrated its effectiveness in several applications.
Empirical evaluation shows that the platform is efficient, scalable, and reusable. In addition, it significantly simplifies the
development of network applications. There are still further issues that need to be resolved. The final goal of this middleware
is to provide a general test bed for various bio-inspired approaches for adaptive distributed systems. Although the current
implementation focuses on the deployment of components, we plan to extend the framework so that it can be used to
modify the behavior of each component during execution. Also, since the current performance is not satisfactory, further
measurements and optimizations are required. In addition, the current migration scheme for partitioned applications may
still be naive. We have studied some higher-level routings for mobile agents in previous papers and are interested in applying
routing approaches to partitioned applications. We plan to develop a monitoring and testing system for components by using
an approach where we test context-aware applications on mobile computers.

References

[1] T.D. Seeley, When is self-organization used in biological systems? Biological Bulletin 202 (9) (2002) 314–318.
[2] N. Minar, M. Gray, O. Roup, R. Krikorian, P. Maes, Hive: distributed agents for networking things, in: ASA/MA’99.
[3] R. Schoonderwoerd, O. Holland, J. Bruten, Ant-like agents for load balancing in telecommunications networks, in: Conference on Autonomous Agents,
vol. 9.
[4] G.D. Caro, M. Dorigo, Antnet—distributed stigmergetic control for communications networks, Journal of Artificial Intelligence Research, 9.
[5] M. Weiser, The computer for the twenty-first century, Scientific American 265 (3) (1991) 94–104.
[6] M. Esler, J. Hightower, T. Anderson, G. Borriello, The future of computing, Scientific American 281 (2) (1999) 52–55.
[7] R. Grimm, J. Davis, E. Lemar, A. Macbeth, et al., Programming for pervasive computing environments, in: Proceedings of ACM Symposium on Operating
Systems Principles.
[8] M.L. Dertouzos, Next century challenges: data-centric networking for invisible computing, in: Proceedings of the 5th ACM/IEEE International
Conference on Mobile Computing and Networking, 1999, pp. 256–262.
[9] Y. Fan, S. Gauch, Autonomous adaptive agents for information gathering, in: Proceedings of AAAI 96, 1996.
[10] M. Roman, H. Ho, R.H. Campbell, Application mobility in active spaces.
[11] B.L. Brumitt, B. Meyers, J. Krumm, A. Kern, S. Shafer, Easyliving—technologies for intelligent environments, in: Proceedings of International Symposium
on Handheld and Ubiquitous Computing, 2000.
[12] I. Satoh, Building reusable mobile agents for network management, IEEE Transactions on Systems, Man and Cybernetics 33 (3).
[13] K.-W. Yeom, et al., A context-aware system in ubiquitous environment—a research guide assistant, in: Proceedings of IEEE International Conference
on CIS/ROI, 2000.
[14] K. Yeom, J. Park, Bio-inspired self-organization architecture for distributed components, in: Proceedings of International Conference on Ultra Modern
Communications, 2009.
[15] O. Babaoglu, H. Meling, A. Montresor, Load-balancing through a swarm of autonomous agents, in: Proceedings of International Workshop on Agents
and Peer-to-Peer Computing, 2002.
[16] J. Suzuki, T. Nakano, K. Fujii, N. Ikeda, T. Suda, Reconfiguration of network applications and middleware systems in the bio-networking architecture,
in: Proceedings of IEEE LARTES, 2002.
[17] M. Wang, T. Suda, The bio-networking architecture: a biologically inspired approach to the design of scalable, adaptive, and survivable/available
network applications, in: Proceedings of the 1st IEEE SAINT Conference, 2001.
[18] N. Minar, M. Gray, O. Roup, R. Krikorian, P. Maes, Hive—distributed agents for networking things, in: International Symposium on Agent Systems and
Applications/International Symposium on Mobile Agents, 1999, pp. 569–571.
[19] N. Minar, R. Burkhart, C. Langton, M. Askenazi, The swarm simulation system, a toolkit for building multi-agent simulations, Technical Report of
Swarm Development Group.
[20] M. Mamei, L. Leonardi, F. Zambonelli, Co-fields—a unifying approach to swarm intelligence, Lecture Notes in Computer Science 2577 (2003).
[21] P. Bellavista, A. Corradi, C. Stefanelli, Mobile agent middleware to support mobile computing, IEEE Computer 32 (3) (2001).
[22] B. Overeinder, E. Osthumus, F. Brazier, Integrating peer-to-peer networking and computing in agentspace framework, in: IEEE International
Conference on Peer-to-Peer Computing, 2002.
[23] J. Kubiatowicz, et al., Oceanstore: an architecture for global-scale persistent storage.
[24] I. Stoica, R. Morris, D. Karger, M.F. Kaashoek, H. Bala-krishnan, Chord: a scalable peer-to-peer lookup service for internet applications.
[25] B. Alberts, D. Bray, A. Johnson, J. Lewis, Essential Cell Biology, 2nd ed., Garland Science, 2003.
[26] K. Abul, H. Andrew, Cellular and Molecular Immunology, 5th ed., Saunders, 2002.
[27] Lodish Berk, K. Matsudaira, et al., Molecular Cell Biology, fifth ed., Garland Science, 2004.
[28] W. Woo, P. Martin, Structures in focus-filopodia, The International Journal of Biochemistry & Cell Biology 34 (7) (2002) 726–730.
[29] A. Montresor, O. Babaoglu, Biology-inspired approaches to peer-to-peer computing in bison, in: International Conference on Intelligent System Design
and Applications, 2003.
[30] MetaMicrobe, D.discoideum. URL: http://www.metamicrobe.com/dicty.
[31] D.M. Davis, Nature reviews immunology 7. URL: http://www.nature.com/nri/journal/v7/n3/full/nri2020.html.
[32] G.M. Cooper, R.E. Hausman, The Cell: A Molecular Approach, ASM Press, 2003.
[33] C. Szyperski (Ed.), Component Software, Addison-Wesley, 1998.
[34] CCA, The common component architecture forum. URL: http://www.cca-forum.org/.
[35] OMG, The corba specification version 3.0, 2006. URL: http://www.w3.org/Mobile/CCPP/.
[36] FIPA, Fipa the foundation for intelligent physical agents. URL: http://www.fipa.org.
[37] P. Maes, Modeling autonomous adaptive agents, Artificial Life.
[38] A. Fuggetta, G.P. Picco, G. Vigna, Understanding code mobility, IEEE Transactions on Software Engineering 24 (5) (1998).
[39] O. Holder, I. Ben-Shaul, H. Gazi, System support for dynamic layout of distributed applications, in: International Conference on Distributed Computing
Systems, 1999.
[40] S. Chiba, Load-time structural reflection in java, in: Lecture Notes in Computer Science, vol. 1850, 2000.
[41] O.M.G. (OMG), Corba specification in java, 2003. URL: http://www.corba.org.