3

By

Gohel Himanshu Ashokbhai

 3

Index

Introduction…………………………………………………………..4

What Is Software Agent?.......................................................................5

Defination Of Mobile Agent………………………………………..12

Mobile Agent Technology Concept………………………………….15

Structure Of Mobile Agent…………………………………………...20

Mobile Agent In Client-Server System………………………………24

Mobile Agent Artificial Intelligence Point Of View………………… 27

Benefit Of Mobile Agent…………………………………………… 29

Security Issue In Mobile Agent……………………………………… 40

Protecting The Agent Platform……………………………………….49

Protecting the Agent…………………………………………………...53

Mobile Agent Security………………………………………………....54

Why Mobile Agent use In Peer-to-Peer Process…………………….....60

Dynamic View System Architecture…………………………………...62

Conclusion………………………………………………………………74

Bibliography……………………………………………………………..75
 3

 INTRODUCTION

As the Internet constantly expands, the amount of available on-line

information expands correspondingly. The issue of how to efficiently find,
gather and retrieve this information has led to the research and development
of systems and too that attempt to provide a solution to this problem. These
systems and tools are based on the use of MAs’ technology. Mobile agents
are processes (e.g. executing programs) that can migrate from one machine
of a system to another machine (usually in the same system) in order to
satisfy requests made by their clients . Mainly, a mobile agent executes on a
machine that hopefully provides the resource or service that it needs to
perform its job. If the machine does not contain the needed resource/service,
or if the mobile agent requires a different resource/service on another
machine, the state information of the mobile agent is saved in pre-defined
manner, then transfer to a machine containing the necessary resource/service
is initiated, and the mobile agent resumes execution at the new machine.
Advantages of using MAs include low network bandwidth since they only
move when they need to continue execution even disconnected from the
network (typically for disconnected mode), ability to clone itself to perform
parallel execution, easy implementation, deployment, and reliability. The
rest of the paper is organised as follows.
 3

 What Is SoftWare Agent ?

Agents can be autonomous entities, deciding their next step without the
interference of a user ,or they can be controllable ,serving as a me diary
between the user and another agent, thereby having some amount of
Artificial Intelligence. An agent is simply another kind of software
abstraction, an abstraction in the same way that methods, functions, and
objects are software abstractions. An object is a high-level abstraction that
describes methods and attributes of a software component.. We may also say
that” Agents can exist in a structure as complex as the global Internet or
one as simple as a module of a common program.”

 Types Of SoftWare Agent

 CHARACTERTICS OF AGENTS

There are many possible conceptions of Agent . Characteristics . of Agents

Include:-
 3

• Proactive ness:-The agent has an agenda to pursue and will persist in trying
to achieve its aims.

• Autonomy:-It enables an agent to perform a job or step without direct

intervention of its user and it has full control over its actions and internal
state.

• Mobility:-It can passes the ability to move from place to place in a network
like Internet .It can move itself and execute afresh at a new location.

Sometimes an agent performs a task at one location ,saves the state ,migrates
to a new location and restores its execution state to continue where it left off

• Intelligence:- An agent displays intelligence by reasoning from the goal and

knowledge it has . It can learn from its environment and change its behavior
through experience and adapt itself.

 Application of Agent technology

• Information Retrieval Agents

Although the architecture diagram shown in Figure may appear at first
glance to be rather similar to that of the first class of system discussed in the
previous section, the inclusion of the arrow indicating a flow of
communication from the interface agent to the information resources reflects
a significant step up in sophistication. This is the first class of system that
exhibits a significant degree of proactively. The extra arrow on the reference
architecture indicates that the interface agent requests particular pieces of
information from the information sources, rather than passively filtering
information presented to it.
 3

Fig. A Reference Architecture for Information Retrieval Agents

This approach lends itself particularly nicely to being implemented using a

multi-agent system. Using this approach each separate information source
would be modeled by an agent and the interface agent would broadcast a
request for information. Upon receipt of such a request each information
agent would reply with a Message containing all the information they have
access too with relevance to the initial request. The interface agent, having
received all these separate pieces of information, is responsible fo
aggregating the information sensibly and presenting the information in a
unified and easy to access fashion. This approach brings with it a number of
benefits to compensate for the added complexity. Chiefly it allows us to deal
with distributed sources of information effectively, for example the World
Wide Web. It also brings benefits in terms of scalability in that the problems
associated with incorporating a new knowledge source are greatly reduced
as we simply need to design a new agent and slot it in. Systems of this
complexity are very thin on the ground. It is clearly of importance that the
information requested satisfies the users query or goals. Thus the request
sent by the interface agent must be based both on the information obtained
directly from the interface and also upon any user model the system has
managed to build up. This involves the provision of multimedia kiosks at
several sites around Ireland drawing social welfare and employment
information from a number of distributed knowledge sources. A number of
systems attempt to provide virtual newspapers which draw information from
a number of different sources based upon a user’s expressed interests. This
type of system differs from the traditional newspapers in that the user of the
system explicitly chooses what information should be present in their own
personal newspaper. This allows the newspapers to remain up to date
although typically at the expense of the in-depth analysis of the relevant
issues mentioned earlier. Newshound provides a somewhat different service
which is charged for. Here the users enter keywords which tell the system
what news items they are, possibly are and definitely are not interested in.
Again the system returns news articles drawn from a variety of online news
sources (mainly newswires).
 3

• E-Commerce
software agents are an integral part of the overall system and method of
approach. There are user agents acting on behalf of the consumer and
business agents representing the suppliers. Although currently beyond the
state of the art, it will not be long before users will be able to delegate to
their software agent the task of getting cinema tickets to see one of the latest
releases on Saturday night and then booking a meal in a nearby restaurant
afterwards. Given this objective and knowledge of its user’s preferences (eg
vegetarian, no spicyfood, comedies rather than action films, etc.), the proxy
will enter the appropriate electronic marketplace where it will encounter the
business agents (see figure 6)..

fig. The Electronic Marketplace

The proxy will first query the cinema agents to determine the most
appropriate film and the most convenient showing time. Having made this
decision, the proxy will then progress onto the restaurant agents to see which
one best fits with the user’s preferences and constraints. If no appropriate
restaurant can be found, the proxy will return to the cinema agent pool and
reassesses its choice of film or show time and then repeat the process.
Eventually, if successful, the proxy will report back to the user with the
cinema and restaurant booking information.— they are delegated a high-
level task which they have to complete on their own (autonomy), they need
to interact and negotiate with other service providing agents (social ability),
 3

if the preferred restaurant is fully booked the proxy should try another one
(responsiveness),and the proxy might voluntarily check with the railway
company agent to find out the time of the last train home from the station
nearest the restaurant (proactive ness).

• Business Adaptation

A potential evolution of business adoption of Agent technology is depicted

as below:-

fig7 business adaptation

A clear need is emerging across many industries however with increasing

outsourcing, fickle demand, and shortening product lifecycles: each of these
factors is increasing the volatility of markets and hence puts a high
premium on the flexibility of business systems. Particular areas in which
agent technology appears to be most appropriate include those which require
continuous adaptation, interpretation of large amounts of data, automated
assistance in decision making, multi-firm processes and improvements in
corporate learning.
 AGENT MODEL

This model defines the internal structure of the intelligent agent part of a
mobile agent.

• Life-cycle model

This model defines the different execution states of a mobile agent and the
events that cause the movement from one state to another. Thus, it is closely
 3

related to the computational model which describes how the execution

occurs. The first, and more powerful life cycle , starts with a ‘start’ state,
proceeds to a ‘running’ state where a persistent process is executed, and
hopefully enters a ‘death’ state where the process is terminated. When a
mobile agent is transported from one node to another, the process in the
running state is check-pointed e agent enters the ‘frozen’ state. Next, its
context is delivered to the destination node where the process is resumed and
re-enters the ‘running’ state at the point it left off. This kind of life cycle is
the most powerful and flexible life cycle as all other life cycle models can be
built on top of this.The task based starts in the ‘start’ state. Then depending
on a set of conditions is proceeds through a network of tasks. Each task
having its own state. However, when the agent moves to a new node the
context of the currently executing task is lost. Before bmoving the agent
must indicate the first task to be started when it re-materialises on the
destination node.

fig.Mobile Agent System

This model defines the different execution states of a mobile agent and the
events that cause the movement from one state to another. Thus, it is closely
related to the computational model which describes how the execution
occurs. The first, and more powerful life cycle , starts with a ‘start’ state,
 3

proceeds to a ‘running’ state where a persistent process is executed, and

hopefully enters a ‘death’ state where the process is terminated. When a
mobile agent is transported from one node toanother, the process in the
running state is check-pointed e agent enters the ‘frozen’ state. Next, its
context is delivered to the destination node where the process is resumed and
re-enters the ‘running’ state at the point it left off. This kind of life cycle is
the most powerful and flexible life cycle as all other life cycle models can be
built on top of thisThe task based starts in the ‘start’ state. Then depending
on a set of conditions is proceeds through a network of tasks. Each task
having its own state. However, when the agent moves to a new node the
context of the currently executing task is lost. Before bmoving the agent
must indicate the first task to be started when it re-materialises on the
destination node.

 Introduction And Possible Defination Of Mobile Agent:

The mobile agent (MA) paradigm is a further extension to distributed

computing paradigms. A mobile agent is a software program with mobility
which can be sent out from a computer into a network and roam among the
computer nodes in the network. It can be executed on those computers to
finish its task on behalf of its owner. The direction of a mobile agent can be
multi-way, from any computer to another within that network. The migration
of a mobile agent can occur multiple times before it comes back to its home
computer with the computation results. In addition, not only the application
logic of a mobile agent is transferred between computers, but the application
state can be transferred from one computer to another. The transferring of a
mobile agent state facilitates it in working autonomously to travel between
one or more remote computers. Figure 1 illustrates the distributed computing
 3

paradigms introduced above. The use of mobile code has a long history
dating back to the use of remote job entry systems in the 1960's. Today's
mobile agent incarnations can be characterized in a number of ways ranging
from simple distributed objects to highly organized software with embedded
intelligence , Mobile agent paradigm helps form a large-scale, loosely-
coupled distributed system. Because of its many salient merits, it ha
attracted tremendous attention in the last few years and become a promising
direction in distributed computing and processing, as well as high
performance network area.
 3

Although mobile agent technology has many notable advantages to be

applied to a wide range, it also brings significant new security threats
because the mobile code generated by one party will transfer to and execute
in an environment controlled by another party. Several security issues arise
in various areas for mobile agent computing, including authentication,
authorization (or access control), intrusion detection, etc. A mobile agent
system could be attacked by malicious agents, platforms and third parties.
Many of these threats have counterparts in conventional client-server
systems and have always existed in some form in the past. Mobile agents
simply offer a greater opportunity for abuse and misuse, which broadens the
scale of threats significantly. In addition, since mobile agents have some
unique characteristics such as the mobility of a mobile agent, security
problems become more complicated in mobile agent systems. Those security
 3

problems have become the bottleneck of the development and maintenance

of mobile agent technology, especially in security sensitive applications such
as electronic commerce. A lot of research has been dedicated to address the
security problems in a mobile agent system. This research differs in its aim,
emphasis, base, and technique. Some work are towards building the
foundations for the security of a mobile agent system; some propose security
mechanisms following different approaches; some focus on introducing
security mechanisms into the architectures of mobile code systems; and
others implement real applications with security features. However, there
has been limited research dedicated to provide an intuitive formal
framework for a secure mobile agent system, including formal modeling of
mobility, communication, and execution.
 MOBILE AGENT TECHNOLOGY CONCEPT
The mobile agent approach is a relatively new paradigm inthe distributed
systems environment. MAs have been developed as an extension to mobile
code approach (e.g. applet) and could replace the client-server model and
itsarchitectures in the near future. Many researchers in this field have
extended the mobile-code concept to “mobile object” in which an object
(code + data) are moved from one host to another. The mobile agent
approach extends this concept further by moving code, data and state
(thread) from one host to another as well. MAs run at one location, move
with their state to another host, and continue execution at that host. Mobile
code and mobile objects are normally moved by an external entity while
MAs are usually migrated autonomously. Before the mobile agent paradigm
appeared, many approaches have been proposed and developed for
communication between client and server such as, Message Passing (MP),
Remote Procedure Call (RPC) and Remote Evaluation (REV). In RPC, the
client sends data as parameters to a procedure that resides at the server. The
procedure will be executed on the server and the results will be sent back to
the client. The REV is a different architecture from RPC. Instead of calling a
remote procedure at the sever side, the procedure itself will be sent from the
client to the server to be executed and returns the result. Briefly, in RPC the
data is transmitted between the client and server in both directions. In REV,
code is sent from the client to the server, and the data is returned. In contrast,
a mobile agent is a program (encapsulating code, data, and state) sent by a
client to a server .However, in a client/server model, a server is a machine
that provides some service (or a set of services) and a client (most often
another machine) makes requests for those services through a
communication channel (e.g. wireless or wired).
 3

Communication between the client and the server is usually through

message passing. Thus, when a client needs a particular service, it usually
sends a request message to the server that contains the needed service as
shown in Fig 1. A limitation of the client-server model is that the client is
limited to the operations provided at the server. If the client needs a service
that a particular server does not provide, it must find a server that can
satisfy the request by sending out more messages to other servers. This
clearly is an inefficien use of network bandwidth. In addition, this kind of
communication may increase the networks traffic, waste network bandwidth
and causes delay of the reply due to server down time or crashes. Another
problem is in the use of the model for disconnected computing. Due to the
mobility factor of mobile devices (mobile phones, PDAs, Laptops), sporadic
disconnection is frequent in the wireless environment. Mobile agents
provide a solution for the dynamic environment of the mobile devices
because they do not rely on server operations . The mobile agent appears to
tackle significant problems whether in wired or wireless communication
such as disconnection operations, increased network traffic and others.
Moreover, mobile agents can play a major role in the wireless
communication after the failure of the Java RMI in increasing the
performance over slow wireless links . Once the mobile agent has migrated,
the connection between client and server will be disconnected. This saves
network bandwidth especially in a wireless environment. When a mobile
agent finishes its job at the server, it will then be ready to reconnect to its
 3

host or to migrate to another node to perform other duties within the network
as shown in Fig. 2. PDA (wireless mode) PC (Wired mode)
Fig. 1. Client-server paradigm

 MOBILE AGENT CHARACTERISTICS

A number of characteristics have been identified by MAs should be

autonomous, having the ability to act without direct external interferences.
In other words, they have some degree of control over their data and states.
MAs should be Interactive in communicating with the environment and
other agents. MAs should be adaptive. In other words, they have ability to
respond to other agents or their environment. Mobility is the core property in
a mobile agent concept whereby the agent has the ability to migrate or
transport itself from one node to another within the same environment or
from node to another node in a different environment autonomously. Proxy,
MAs may act on behalf of someone or for the benefit of some entities (e.g.
software systems). In order to act on behalf of others, mobile agents must
have at least a minimal degree of autonomy. Proactive, MA should be a
goal-oriented entity, and take an initiative in responding to an environment.
Intelligent, MAs may have certain degree of intelligence, base on
knowledge in order to act efficiency. Coordinative, MAs should be able to
 3

perform data transfer activities in sharing with other agents within the given
environment. Learning refers to a mobile agent’s ability in gaining
information about the current environment, which will help MAs to modify
its behaviour. Cooperative, MAs should be able to coordinate with other
agents to achieve a common purpose. Ragged, MAs should be able to deal
with errors when encountered and during their (errors) occurrence.
Researchers have also attempted to classify the types of the agent based on
the above attributes. In many cases, it is not necessary to have an agent with
all the above properties.This will be determined by the nature of the task
which the agent should achieve. For example, Microsoft’s software agent
does not necessarily need to be mobile and cooperative but it must be smart
and proactive. “This agent proposed to enhance the user interface of their
applications with interactive personalities in the form of animated
characters. These characters can move freely within the computer display,
speak aloud (and by displaying text onscreen), and even listen for spoken
voice commands” . However, as mentioned earlier several types of agent
exist such as collaborative agents, interface agents, mobile
agents,information agents, reactive agents, hybrid agents and smart agents.
These types of agent are built based on their purpose. For this work the
mobility factor must exist as the main feature alongside one or many of the
previous attributes depends on the need of that characteristic.

• MOBILE AGENT REQUIREMENTS

This section addresses software requirements. There are three main

requirements: the mobile agent programme (code) itself, mobile agent
platforms (execution environment) and mobile interfaces or mobile agent
creators. Currently, the traditional programming languages are facing real
challenges in implementing the new way of coding (e.g. mobility task) but
there are some conventional programming languages which have the
potential to be used for this purpose (e.g. Java Developers can build
powerful distributed applications by using Java due to its independence
platform feature. In addition, mobility tasks can be implemented in Java via
Serialisation Interface whereby a mobile agent can be serialised throughout a
communication channel and deserialised at the other end. However, when
developing and implementing the mobile agent code by using any capable
language (e.g. Java). MAs should be able to perform the following
operations in order to build a robust system: Creation, Cloning, Dispatching
or Migration, Retraction, Activation, Deactivation and finally Disposal .
Creation is the first period in the mobile agent life cycle. For example, when
 3

a system requests a service to be done by the mobile agent, the system must
create a mobile agent instance in the first place before any work can be done.
During, this creation stage the mobile agent will be equipped with the
desired parameters in order to achieve its goal. Cloning basically creates a
copy of the original mobile agent object. This operation is used when the
need for another agent (with the same features and properties to do the same
or other job in conjunction with the original one ) arises. The dispatching or
migrating is another main function in the mobile agent life cycle. This
function is responsible for moving the agent from one node to another within
the network environment by specifying the destination address (e.g. URL) to
the agent. There are two main types of migration: strong and weak. The
retraction function is done where the agent’s source node requires its agent
to be returned to the original host or node. Activation and deactivation are
operations done when the mobile agent is required to start or to stop only
within certain time of its lifetime. Finally, the dispose operation is done
where the agent life comes to the end. Fig. 3 explains the above mobile
agent operations as suggested by an Aglet system
 3

 The Structure of Mobile Agents

Mobile agents consist of three components: code, data, and execution state.
The code contains the logic of the agent, and all agents of the same type use
the same code.3 The code must be separated from the code of the agency so
that it can be transferred alone to another agency, and the code must be
identifiable and readable for an agency (e.g., in the form of a file from the
local file system or a byte stream from the network). Usually, as in other
programs, an agent’s code consists of more than one file (e.g., in the Java
programming language they could be many class files). The second
component of an agent is data. This term corresponds to the values of the
agent’s instance variables if we assume an agent to be an instance of a class
in object-oriented languages. The data is sometimes also called the object
state. It is important to note that not all data items an agent can access are
part of its object state. Some variables reference objects that are shared with
other agents or the agency software itself, for example, file handlers, threads,
the graphical user interface, or other resources and devices that cannot be
moved to other servers. Thus, we have to restrict the agent’s immediate data
to those data items the agent owns and that are movable. The third
component is the execution state. The difference between object and
execution state information is that the elements of the object state are
directly controlled by the agent itself, whereas execution state information is
usually controlled by the processor and the operating system. What this
means depends very much on the decision of the mobile agent toolkit
designer and the underlying execution environment (processor, operating
system, virtual machine), as we will see in Section 3.3, Design Issues of
Agent Migration. In some toolkits, an agent’s execution state is comprised
of the current value of the instruction pointer and the stack of the underlying
processor. In others it is not possible to determine the execution state of an
agent at all. In most Java-based toolkits, for example, the agent itself is
responsible for copying information about its current execution state on the
level of the programming language into the object state and restoring it after
successful migration.
• The Migration Framework

The typical behavior of a mobile agent is to migrate from one agency to

another. During the process of migration, the current agency (i.e., the one the
agent currently resides on) is called the sender agency and the other agency
(to which the agent wants to migrate) is called the receiver agency. During
 3

the migration process the sender and the receiver must communicate over
the network and exchange data about the agent that wants to migrate. Thus,
we can say that some kind of communication protocol is driven, and we call
this the migration protocol. Some systems simplify this task to an
asynchronous communication, comparable to sending an email, whereas
other systems develop rather complicated network protocols in addition to
TCP/IP. The whole migration process contains six steps, which are executed
in sequence, except for S3 and R1, which are executed in parallel (Fig. 3.1).
The first three steps (S1–S3) are executed on the sender agency: S1
Initialize the migration process and suspend the thread. The process of
migration typically starts with a special command, the migration command,
by which the agent announces its intention to migrate to another agency,
whose name is given as parameter of the migration command. The first task
for the agency is now to suspend the execution thread

of the agent and to guarantee that no other child thread is still alive. This
requirement is important for the next step, for which it is imperative that
data and state be frozen and unable to be modified later on.
 3

S2 Capture the agent’s data and execution state. The current state of all
variables (the data) of the agent is serialized; that is, their current values are
written to an external persistent representation, for example, a memory
block or a file. The agent’s state is also stored there so that the point of
suspension is known. The result of the serialization process is the serialized
agent, which is a flat byte stream that consists of the agent’s data and state
information.
S3 Transfer the agent. The serialized agent is transferred to the receiver
agency using a migration protocol. Whether any code is sent to the receiver
agency depends on different parameters and will be discussed later. The last
three steps (R1–R3) are executed on the receiver agency.
R1 Receive the agent. The serialized agent is received using the migration
protocol. The receiver agency checks whether the agent can be accepted
based on information about the agent’s owner and the sender agency. The
receiver agency may filter out agents that come from agencies that are
unknown or not trusted.
R2 Deserialize the agent. The serialized agent is deserialized; that is, the
variables and execution state are restored from the serialized agent. The
result of this step should be an exact copy of the agent that existed on
the sender agency just before reaching the migration command.
R3 Start agent execution in a new thread. The receiver agency resumes
agent execution by starting a new thread of control. When resuming
execution, the agent’s code is needed. In this general framework we make no
assumptions abouthowthe code is transferred to the receiver agency.One
possible technique is for the receiver agency to load the code from the
agent’s home agency or its code server.We will discuss those techniques. In
the next section we look at an implementation of a migration process. As an
example we chose our Tracy mobile agent toolkit, which is implemented in
the Java programming language.
 Why Are Mobile Agents a Good Idea?

Now we want to describe some major advantages of mobile agents and try
to explain why they will meet the demands of future distributed
systems.Although mobile agents provide a new and interesting approach to
distributed systems, there must be clear arguments in favor of mobile agents
before they are substituted for more traditional techniques. However,
although we believe that mobile agents are the most promising technology to
solve most of the problems of the networked future, it should be said that we
also believe that mobile agents will supplement many older techniques
rather than replace them. We present four major technical advantages in
 3

detail. It is this set of basic technical advantages that opens the chance for
improved and typical applications.

• Delegation of tasks.
Because mobile agents are simply a more specific type of software agent, a
user can employ a mobile agent as a representative to which the user may
delegate tasks. Instead of using computer system interactive tools that are
able to work only under direct control by a user, autonomous software
agents aim at taking care of entire tasks and working without permanent
contact and control. As a result, the user can devote time and attention to
other, more Iportant things. Thus, mobile software agents are a good means
to cope with the steady information overload we experience.
• Asynchronous processing.
Once mobile agents have been initialized a set up for a specific task, they
physically leave their owner’s computer system and from then on roam
freely through the Internet. Only for this first migration must a network
connection be established. This feature makes mobile agents suitable for
nomadic computing, meaning mobile users can start their agents from
mobile devices that offer only limited bandwidth and volatile network links.
Because the agent is less dependent on the network, it will be more stable
than client-server–based applications.
• Adaptable service interfa
Current techniques in distributed systems that offer application service
interfaces, usually as a collection of 2.5 Possible Application Domains
ofMobile Agents _ 27 functions, constitute only the least common
denominator of all possible clients. As a consequence, most of the interface
functions are more or less primitive, and clients will probably have to use a
workflow connecting these functions in order to execute a complex, user-
driven operation. If the communication overhead for exchanging messages
between client and server is high compared with the execution time of each
function, it would make sense to offer aggregated and more advanced
functions as combinations of the primitive ones. However, because it is
difficult to track down every possible scenario in advance or even during
runtime, these functions are usually not offered by the server’s multi-
purpose interface. Mobile agents can help in this situation by offering a
chance to design a client-driven interface that is optimized for the client
(user) but that is adaptable to different server interfaces. The key is to use a
mobile agent to translate the more complex and user-driven functions of the
client interface into the fitting primitive functions offered at the server node.
The mobile agent will simulate a constant and highly specialized interface
 3

for the client (user) while talking to each server in its own language, which
will allow servers to become simpler and more generalized.
• Code-shipping versus Data-shipping
This is the probably most cited advantage of mobile agents, and it stands in
close relationship to adaptable service interfaces. Service interfaces
frequently offer only primitive functions to access databases. A single call
can therefore result in a huge amount of data being sent back to the client
because of the lack of precision in the request. Instead of transferring data to
the client, where it will be processed, filtered, and probably cause a new
request (data-shipping), this code can be transferred to the location of the
data (code-shipping) by means of mobile agents. In the latter case, only the
relevant data (i.e., the results after processing and filtering) is sent back to
the client, which reduces network traffic and saves time if the code for
filtering is smaller than the data that must be processed. This advantage has
been scrutinized in the last 5 years by many different research groups for
different application domains, and it has generally been verified

 MOBILE AGENT SYSTEM IN, CLIENT SERVER AGENT SYSTEM

In particular, although full mobile-agent systems involve all the same

research issues (and more) as more restricted mobile-code systems, y. I will
be explain a brief overview and comparison of two system for distributed
computing: client-server, and mobile agents
• Client-Server System.
In the client-server paradigm, see Figure 3, a server advertises a set of
services that provide access to some resources (e.g., databases). The code
that implements these services is hosted locally by the server. We say that
the server holds the know-how. Finally, it is the server itself that executes
the service, and thus has the processor capability.
 3

fig 3.Client –Server System

If the client is interested in accessing some resource hosted by the server, it

will simply use one or more of the services provided by the server. Note that
the client needs some "intelligence" to decide which of the services it should
use. The server has it all, the know-how, resources, and processor. So far,
most distributed systems have been based on this paradigm.
• Mobile- Agent System
A key characteristic of the mobile agent paradigm, see Figure 4, is that any
host in the network is allowed a high degree of flexibility to possess any
mixture of know-how, resources, and processors. Its processing capabilities
can be combined with local resources. Know-how (in the form of mobile
agents) is not tied to a single host but available throughout the network.

fig4.Mobile Agent System

 Advantages of mobile agents over traditional client-server designs

• Reduction of Network Load:-

Mobile agents are also useful when it comes to reducing the flow of raw
data in the network. When very large volumes of data are stored at remote
hosts, these data should be processed in the locality of the data, rather that
transferred over the network. Mobile agents allow you to package a
conversation and dispatch it to a destination host where the interactions can
take place locally, see Figure 1.
 3

fig.4.Reduction of Network Load by using agents

• Support for disconnected operation and weak clients

Mobile agents improve the support for mobile computing, i.e., mobile
devices that are only intermittently connected. Mobile devices, such as
personal digital assistants (PDAs), web pads, and mobile phones, are not
general-purpose computing devices in the sense of personal computers, but
exhibit two key characteristics relevant in this discussion:

• Non-persistent and/or low-bandwidth connection to the network.

• Limited storage and processing capacity.

A user might choose to put together a query (a "task" for the agent), connect
to the network, launch the agent with the respective task, disconnect from
the network, and at a later time retrieve the agent along with the results it has
collected. This is beneficial not only when considering devices that are
occasionally disconnected but also when looking at devices, like cell phones,
that might be connected persistently, but only with a very low bandwidth.

• Robust remote interaction

RPC-based client-server computing was developed for LAN-based systems,

where strong assumptions regarding communication integrity and
server/infrastructure availability could be made. These assumptions are not
valid in their strong form when moving from LAN structures to wide area
networks (WAN), leading to reduced reliability of RPC-based client-server
applications. Although RPC itself could be enhanced to better cope with
 3

such new environments, it would take great efforts to adopt all existing
components to the improved protocol. Two properties of the mobile agent
paradigm offer advantages in this field:

• Messaging- As opposed to RPC, messaging is dependent on reliable

communications to a much lesser extent, because it does not require the
receiver to answer a message before the sender continues processing.
• Recovery- Mobile agents by nature have to deal with required servers or
services being unavailable. Therefore, mobile agents have to carry the ability
with them to deal with such situations, i.e., they have to "know" alternatives
or how to find them.
• How do MAs relate to other environments or infrastructures?
I certainly think there’s been a lot of work in OS process migration over the
last decade or two, so we could learn a lot from that work. But a lot of the
problems involved with MAs are very different. We tend to use interpreted
languages and try to support heterogeneous architectures, operating systems,
and even heterogeneous administrative domains, such as the Internet, while
the traditional process migration world tends to be much more homogenous.
We also tend to have different reasons to migrate. Process migration usually
supported load balancing, and MAs are generally moving for other purposes
— to become closer to some resource rather than just to balance
CPU load. MAs are good for higher-level things, but they’re too
heavyweight for low-level things such as an active network, which tends to
be at the packet level. As a result, the issues tend to differ also. Mobile
computing, on the other hand, is an area where I think MAs have a lot to
contribute. I think that PDAs, laptops, and other mobile devices will be a
field where MAs will be launched, leaving the mobile platform and roaming
through the wired network to accomplish the user’s task or representing
the users while they’re disconnected. I think there are many ways that
MA research can help that community.

 Mobile Agents The Artificial Intelligence Point of View

Let’s start with the notion of software agents. The word agent derives from
the Latin word for actor, meaning a person who acts on behalf of another.
In different languages the notion agent is used with different meanings. In
English-speaking countries, for example, the word agent is often used in
a more general context, whereas in German-speaking countries an agent
mostly works for the secret service. Usually, a real estate agent is employed
to aid in renting or buying a house, and a travel agent is visited to aid in
 3

planning a vacation. In physical science, an agent can be an active substance

that causes a reaction. Other sciences also use the term agent. For example,
in legal sciences an agent provocateur is a person hired to incite suspected
persons to commit some illegal action that will make them liable for
punishment.Nowadays, the term agent has (unfortunately) become a
buzzword to signal innovative system characteristics. For example, some
electronic mail clients are called mail agents, although they do nothing aside
from the usual task of delivering and collecting emails from your mailbox.
A software agent is a software entity that continuously performs tasks
given by a user within a particular restricted environment. The involved
software entity can be a computer program, a software component, or, in the
meaning of object-oriented programming languages, just a simple object.
However, true software agents must be seen as an extension of the more
general concept of objects or software components. Whereas software
objects are passive, agents are active.
The definition of what exactly constitutes a software agent has been
intensely debated in the research community for several years. Although this
debate continues, there is a common understanding that a software entity
must exhibit certain minimal features to qualify as an agent:
Autonomy Agents operate and behave according to a self-made plan that is
generated in accordance with the user-given task. Agents do not need every
step of this plan stipulated by their owner in advance, and they donot ask
their owner for confirmation of every step.
Social behavior Agents are able to communicate with other agents or
human beings by means of an agent communication language.
Communication can be restricted to pure exchange of information or can
include sophisticated protocols for negotiation, for example, when trading
the price for a good or joining an auction. A separate branch of research
deals with the problem of multiple agents working together on a single task
in so-called multi-agent systems. In this case, benevolent behavior is
necessary for a successful undertaking.
Reactivity Agents perceive their environment by some kind of sensors
andare able to react to identified events.

Proactivity Not only do agents react to stimuli from their environment, but
they are also able to take initiative and actively plan. B. Le Du explains
this with the following metaphor: “The difference between an automaton
and an agent is somewhat like the difference between a dog and a butler. If
you send your dog to buy a copy of the New York Times every morning, it
will come back with its mouth empty if the news stand happens to have run
 3

out of this specific newspaper one day. In contrast, the butler will probably
take the initiative and buy a copy of the The interested reader is referred to
some books that serve as comprehensive introductions to all fields of
intelligent software agent research and from which more information about
these topics can be gleaned and also more definitions for software agents
found. Software Agents, contains a collection of papers concerning the
areas of agentsupported user interfaces, agents for learning and intelligent
assistance, and a summary of agent communication, collaboration, and
mobility. We can now try to add mobility to our definitions of software
agents: Mobile software agents are computer programs that act as
representatives in the global network of computer systems. The agent knows
its owner, knows his or her preferences, and learns by communicating with
its owner. The user can delegate tasks to the agent, which is able to search
the network efficiently by moving to the service or information provider.
Mobile agents support nomadic users because the agent can work
asynchronously while the user is offline. Finally, the agent reports results of
its work to the user through different communication channels such as
electronic mails, Web sites, pagers, or mobile phones. In this definition,
many of the characteristics of software agents that we described earlier can
be found. A mobile agent acts on behalf of a user; it knows its user and gets
to know him or her better over time. It has social behavior because it is able
to communicate with the user, services, or even other agents. It works
proactively, because it can, for example, contact its owner by many means of
communication. The additional property of mobility can be seen as a very
straightforward extension, at least from a human point of view, as it goes
well with our natural understanding of how to search for information in a
distributed environment.

 There are at least seven main benefits, or good reasons, to start using
mobile agents:

A mobile agent is not bound to the system on which it begins execution. It

is free to travel among the hosts in the network. Created in one execution
environment, it can transport its state and code with it to another execution
environment in the network, where it resumes execution. The term state
typically means the attribute values of the agent that help it determine what
to do when it resumes execution at its destination. Code in an object-
oriented context means the class code necessary for an agent to execute.
 3

• They reduce the network load.

Distributed systems often rely on communication protocols involving
multiple interactions to accomplish a given task. The result is a lot of
network traffic. Mobile agents allow users to package a conversation and
dispatch it to a destination host where interactions take place locally. Mobile
agents are also useful when reducing the flow of raw data in the network.
When very large volumes of data are stored at remote hosts, that data should
be processed in its locality rather than transferred over the network. The
motto for agent-based data processing is simple: Move the computation to
the data rather than the data to the computation.
• They overcome network latency.
Critical real-time systems, such as robots in manufacturing processes, need
to respond in real time to changes in their environments.Controlling such
systems through a factory network of substantial size involves significant
latencies. For critical real-time systems, such latencies are not acceptable.
Mobile agents offer a solution, because they can be dispatched from a
central controller to act locally and execute the controllers directions
• They encapsulate protocols.
When data is exchanged in a distributed system, each host owns the
code that implements the protocols needed to properly code outgoing data
and interpret incoming data. However, as protocols evolve to accommodate
new requirements for efficiency or security, it is cumbersome if not
impossible to upgrade protocol code properly. As a result, protocols often
become a legacy problem. Mobile agents, on the other hand, can move to
remote hosts toestablish ÒchannelsÓ based on proprietary protocols.
• They execute asynchronously and autonomously.
Mobile devices often rely on expensive or fragile network connections.
Tasks requiring a continuously open connection between a mobile device
and a fixed network are probably not economically or technically feasible.To
solve this problem, tasks can be embedded into mobile agents, which can
then be dispatched into the network. After being dispatched, the agents
become independent of the process that created them and can operate
asynchronously and autonomously. The mobile device can reconnect at a
later time to collect the agent.
• They adapt dynamically.
Mobile agents can sense their execution environment and react
autonomously to changes. Multiple mobile agents have the unique ability of
distributing themselves among the hosts in the network to maintain the
optimal configuration for solving a particular problem.
 3

• They are naturally heterogeneous.

Network computing is fundamentally heterogeneous, often from both
hardware and software perspectives. Because mobile agents are generally
computer- and transportlayer- independent (dependent on only their
execution environments), they provide optimal conditions for seamless
system integration.
Seven Good Reasons for Mobile Agents

 Reliability Requirements in Mobile Agent Systems

• Requirements
Mobile agent fault tolerance requires at least mechanisms for making agents
persistent, for reactivating agents after a failure, for recovering the state of
the agent activity after a failure, and for reliably transporting agents between
agencies. Additionally, the execution of mobile agent-based applications
should be able to tolerate long-term failures of agencies. When a mobile
agent executing an application moves to an agency, it transfers the control
flow execution of that application to that agency. While executing at an
agency, an agent is completely subject to the execution rules and conditions
of that agency. If the agency where the agent is running fails, the execution
of that agent remains blocked while the agency is faulty. An agency may
remain faulty for a long time. Long unavailability periods have the obvious
undesirable effect of delaying the execution of an agent-based
application. Making the execution of an agent-based application tolerate
long-term failures of agencies is achieved by replicating agents. With
replication, an agent execution is seen as being performed in a sequence of
stages (see Figure 1). The first stage begins when the application execution
starts. A new stage then begins (and the previous terminates) when the
mobile agent execution reaches a movement operation, to continue at a new
agency. To provide agent fault-tolerance, copies of the agent are sent to
a non-empty set of agencies. Consider in Figure 1 that the agent application
has to perform actions sequentially at agencies agency_1_1, agency_2_1, ...,
agency_m_1, i.e., at the uppermost agencies at each stage represented in
the figure. As can be seen, at each stage copies of the agent are sent to the
desired agency and additionally to a set of n-1 other agencies. For example,
at stage 1, copies of the agent are sent to agencies agency_1_1,
agency_1_2, ..., agency_1_n. The n-1 additional agencies are used primarily
 3

for performing exception handling. The execution of the agent application at

these agencies, however, can also include accesses to services. When the
execution terminates at a stage, copies of the agent with the current state of
its execution are sent to the agencies of the next stage and the copies at the
current stage are destroyed. An agent application is performed then now by a
moving agent group, instead of by a single agent. A group of agents can,
during its execution, create other groups of agents, so that each agent group
can execute a part of the same global application asynchronously, movin
independently one in relation to the others. Each created agent group by its
turn can create other agent groups, resulting in a tree of mobile agent groups.
Fault tolerance must also be guaranteed for these cases. This implies, among
other aspects, the need for guaranteeing atomic creation of mobile age
groups and that there must exist mechanisms for coordinating sets of
independently migrating agent groups executing the same whole application.
Additionally, in order to use mobile agents in environments such as the
Internet, the developed fault tolerance mechanism must be as less restrictive
as possible in relation to its assumptions about the environment (for
example, in relation to time). In particular, network partitioning should be
supported by the mobile agent fault tolerance protocols.

Beyond fault tolerance, agent applications might require the execution of

agents to exhibit transactional behavior. For such applications, it is
necessary that accesses to a subset of the service available in a distributed
environment can be combined as an unit of work that executes correctly and
reliably in the presence of concurrency and failures.
 3

• Existing Approaches
Mobile agent fault tolerance and support for transactional behavior have
been considered in the context of some mobile agent projects. In
the authors consider agent replication as introduced in the previous section.
In, the author concentrates on the problem of protecting agents against being
subverted by malicious hosts. In the authors introduced the so-called rear
guards as agents left behind while an agent execution moves from agency to
agency that perform recovery if some failure causes the agent executing the
activity to vanish. The protocol used for managing rear guards is called the
NAP protocol. The NAP protocol is an efficient protocol based on reliable
broadcast. The NAP protocol, however, does not tolerate network
partitioning. In a specific protocol was described for mobile agent fault
tolerance that considers network partitioning. In this protocol, however, an
agent group cannot create new agent groups. This protocol is coupled with
the execution of a single atomic transaction by an agent at an agency. If a
new agent is activated to perform recovery of a failed agent, the state of the
execution backtracks to the point before the beginning of the execution of
the stage. an approach for mobile agent fault tolerance and a transaction
model (open nested) based on mobile agents are presented. The approach
supports the dynamic creation of agent groups by other agent groups,
recovery from long-term failures of agencies and network partitioning. This
approach, based on the use of transactions, fulfills the requirements defined
in the previous section. Another approach for agent fault tolerance is
presented in, but it does not tolerate long-term failures of agencies. In and
approaches for executing transactions with mobile agents are presented, but
no concept for fault tolerance is discussed. Finally, approaches for providing
mobile agent persistence and reactivation are common in existing mobile
agent systems. A mechanism for reliably transporting an agent from an
agency to another can be performed, for example, with the use of persistent
message queues.

• Reliable Coordination of Agents

Components taking part in a distributed application need some form for
coordinating their activities. Different applications impose different
requirements on coordination mechanisms, resulting in a set of these
mechanisms being developed for traditional distributed systems. Beyond
direct communication in the form of RPC/RMI, mechanisms such as events,
tuple spaces and group communication systems are commonly supported
 3

A set of mobile agents can also be used to execute a given distributed

application. Not only as a set of replicas cooperating to achieve application
fault tolerance, but also as a set of distinct agents cooperating in achieving a
certain application goal. Multiple agents executing each asynchronously a
part of the same global application . These agents obviously also need forms
of cooperation. Like traditional distributed applications, different mobile
agent based applications impose also different requirements on coordination
mechanisms. Mobile agent based applications, however, impose an added
complexity: the coordination mechanisms must support agents interactions
despite their mobility. Mobile agents can even exhibit high mobility, in the
sense that a single mobile agent can make many hops while executing an
application and interacting with other components. Traditional
communication mechanisms must in general be extended to support
migration, specially if migration transparency should be supported. In a
system providing migration transparency, two agents can
continuecommunicating irrespective of the migration of any of them.
Existing mobile agent systems vary greatly in the provided forms of
communication. The supported communication mechanisms can be divided
into two groups: direct communication, where the communicating peers
explicitly identify themselves; and anonymous communication, where the
sender does not know the identity of the recipients. Direct communication
can involve either only two peers or a sender and a set of receivers
(multicast). The form of multicast supported is unreliable.Forms of
anonymous communication being supported are events, spaces and tuple
spaces . Some support for reliable communication among mobile agents
exists .However, this work describe an algorithm for guaranteeing the
delivery of a message to a mobile agent despite its movement in the absence
of faults. Support for ordering of messages sent to a group of agents is not
addressed. Systems supporting group communication functionality for
mobile agents, comparable to those provided by traditional group
communication platforms are still missing.
• Common Denominator: Mobile Process Groups
As discussed in the previous sections, fundamental to the development of
reliable mobile agent based applications is the existence of appropriate
support for mobile agent fault tolerance and mechanisms for reliable
communication between groups of mobile agents. A common requirement of
both problems is the need for coordinating reliably the actions of members
of a group of migrating agents. We intend to address this requirement in a
generic way by developing the notion of a mobile process group.A process
group is an entity to which an application process refers without knowing
 3

the number and location of the members which form it. Essentially, in a
group communication mechanism, a message sent by a process must be
addressed to all processes in the group and message delivery must be
atomic: either all processes receive the message or no one receive it.
Additionally, message delivery order guarantees such as total or causal
ordering can also be provided by the group communication system A mobile
process group is an extension of the traditional concept of a group of
cooperating processes which can directly support migrating processes as
members of the group. Group communication systems have been
traditionally used to support fault tolerance of replicated components in a
system (e.g., replicated data bases) and for supporting groupware
applications. The coordination requirements of replicas of mobile agents
were made clear , where replication was presented as a means for addressing
mobile agent fault tolerance. Beyond the needs for maintaining consistency
of replicas or independent groups of replicas, mobile process group services
have a broader applicability in agent applications, specially in providing
message delivery guarantees (reliable multicast, causal and total order) for
any set of cooperating agents (for example, for guaranteeing atomic
multicasts to a group of agents that are looking for some information in the
distributed environment). Using mobile process groups represents a form of
unifying the underlying support for fault tolerance and agents coordination,
simplifying the existing solution and potentially increasing the level of fault
tolerance and the implied costs. In relation to support for agents
coordination, mobile process groups represent functionality not yet present
in agent systems. To the best of our knowledge, support for mobile process
groups is not present in existing group communication platforms, such as
Horus and Transis. Previous work exists in supporting group communication
for mobile device computing), but it is devoted to accommodating existing
protocols to the specific properties of the environment (low bandwidth links,
low capacity devices, etc.). Some of the results might be applicable to
mobile process groups. We are however extending traditional group
communication concepts to incorporate ne semantics of message delivery in
the presence of mobility, not present in those systems. Additionally, special
handling of events is being considered to provide a finer tuned way of
handling with movement.
 Security Issues in a Mobile Agent System

• Possible attacks to a mobile agent system

There might be many different kinds of attacks to a mobile agent system.
 3

Since a mobile agent system mainly consists of mobile agents and mobile
agent platforms, most attacks are towards these two main entities. We will
introduce the attacks to them respectively in the following.
• Possible attacks to a mobile agent
A mobile agent has to expose its own information to the platform it migrates
to so that it could be executed. In the case of strong migration, it has to
expose its code, data and state. In the case of strong mobility, its code and
data have to be exposed. Due to this fact, a mobile agent faces more severe
security risks. A malicious platform can try to attack Security Modeling and
Analysis of MAS it in different ways. If we consider the home platform
environment to be the totally secure environment and try to achieve such a
protection level for a mobile agent in other platform, we can identify the
following possible attacks of a malicious platform.
• Leak out/Modify mobile agent's code
The mobile agent's code has to be readable by a guest platform. This
characteristic makes the attack of leaking out/modifying mobile agent's code
unavoidable. A malicious platform could read and remember the instruction
going to be executed and might infer the rest of the program based on that
knowledge. Thus the platform could get to know the strategy and purpose of
the mobile agent. The situation becomes worse if the mobile agent
represents a class of mobile agents or is generated out of standard building
libraries. Therefore a malicious platform can have a complete picture of a
number of mobile agents' behavior. If the malicious platform infers the
physical address and has access to the code memory, it can modify the
agent's code either directly or through inserting some vicious part like a
virus. It could also change the code temporarily to avoid being detected by
modifying the code, executing the code modified and resuming the original
code before the mobile agent leaves.
• Leak out/Modify mobile agent's data
This could be very dangerous too. Since some data are security sensitive,
such as security keys, electronic cash, or social security numbers, it may
cause leak of privacy or loss of money. If a malicious platform knows the
physical location of data, it may modify the data in accordance with the
semantics of data. Therefore it can result in very severe consequences. In
some cases, even if the data being leaked is not that sensitive, a malicious
platform can still take advantage of those data and perform attack. For
example, if a malicious platform gets to know the traveling date of a person,
it may leak it to some thief.
• Leak out/Modify mobile agent's execution flow
 3

If a malicious platform knows a mobile agent's code, data and the physical
location of its program counter, it can infer what instruction will be executed
next. Moreover, it can deduce the state of that mobile agent. Then it might
change the execution flow according to its will to achieve its goal. For
example, it may find that the mobile agent first compares the price of a
product or service provided by the platform with the expected price of the
agent itself, and decides to use it or not afterwards. A malicious platform
might force the mobile agent to ignore the result of the comparison and
accept its product or service directly by making the execution flow jump to
some point. A malicious platform can also take advantage of its ability to
modify the mobile agent's execution to deliberately execute agent's code in a
wrong way.
• Denial of service
A malicious platform can simply not execute the mobile agent migrating to
it or put the agent into waiting list and thus cause delay to that mobile agent.
It is also an attack to the mobile agent since it may make the mobile agent
miss some good chances if the agent can finish its execution on that platform
in time and travel to other platforms.
• Masquerade
A malicious platform may disguise itself as a platform to which a mobile
agent will migrate to or even as the home platform when the mobile agent
returns. If it succeeds, it can get the secrets of the mobile agent by cheating
and at the same time hurt the reputation of the original platform. For
example, a malicious platform may pretend to be an airline company and
give a mobile agent a fake ticket after it gets the money. But the mobile
agent doesn't really get the ticket and may have dispute with the real airline
company later.
• Leak out/Modify the interaction between a mobile agent and other
parties
A malicious platform may eavesdrop on the interaction between a mobile
agent and other parties like another agent or another platform. From the
information it gets, it may infer some secrets about the mobile agent and the
third party. Moreover, if it can alternate the content of the interaction, or
disguise itself as part of the interaction, or direct the interaction to another
unexpected third party, it may perform attacks to the mobile agent and the
third party as well.
• Possible attacks to a mobile agent platform
A mobile agent platform provides the execution and communication
environment for incoming mobile agents. A malicious mobile agent may
 3

exploit the security weaknesses of a mobile agent platform or launch attacks

against the platform. The possible attacks include the following .

• Masquerade
A malicious mobile agent may claim itself as another agent on a mobile
agent platform. Such masquerading action can also be called "faking". The
aim of masquerading of a malicious agent is either to fake as an authorized
agent so as to gain access to the services and resources of this mobile agent
platform which are not assigned to it; or to fake as another unauthorized
agent so as to find a "scapegoat" and shift the blame and punishment of any
malicious actions it will conduct. The results of masquerading include
unauthorized access and even damage to platform resources, leaking
confidential secrets, and ruining the established trust and reputation of the
legitimate agent.
• Denial of Service
The denial of service attack to a mobile agent platform may be from
a malicious mobile agent that deliberately exploits system vulnerabilities or
a mobile agent written with programming errors unintentionally. But the
consequences are similar. The "bad" mobile agents consume an excessive
amount of the resources of this mobile agent platform, degrade the
performance of the platform, make the platform unavailable to other
legitimate agents, or even completely terminate the platform or shut it down.
• Unauthorized Access
If a mobile agent platform is not equipped with an authorization mechanism,
or such mechanism fails for a malicious agent that takes advantage of the
vulnerability of the platform, a malicious agent may have unauthorized
access to the resources of the platform. Not only the privacy and integrity of
this platform may be detrimentally affected, but also other mobile agents
would be attacked from a variety of aspects, which in turn will have a
negative impact on the entire mobile agent system. Obviously, those attacks
are dangerous and harmful to mobile agent systems. In order to avoid those
attacks, a secure mobile agent system must satisfy the following
requirements.
 3

 Secure platform for mobile agents

The main requirements for secure mobile agents relevant to our application
are:

Additionally it is desirable for an agent to be able to trust that a station does

not alter the behavior or data of a visiting agent. This however seems
virtually impossible to implement just using software.
• Requirement 1
The Agent Are Compiled Differently if they are stationary or mobile, where
the mobile agents are denied access to potentially dangerous modules or
system features.
• Requirement 2
A supervisor is attached to every agent that controls its resource and service
usage.

• Requirement 3
Encryption and authentication is used for agent communication. In the rest
of this section we will describe the implementation in greater detail. But
few words on Erlang, our implementation language.
• Erlang
Erlang is a fairly clean functional language: it does not have global variables
and no destructive assignment. State changes are modeled by processes.
 3

In Erlang, processes are created explicitly through the spawn primitive. The
Result Of Spawn is Identier is a reference to the created process and is used
to address it, e.g. when sending messages to the process. On a Unix system
all Erlang processes typically reside in a single Unix process, and the Erlang
run time system schedules all processes in a fair way. The Erlang system
supports distribution since version 4.0, i.e. processes may be spawned on
remote nodes. For a large class of applications, it is quite transparent on
which node a process resides, except for performance, as the send operation
works equally well for processes on distributed nodes. The main di
erence is that it is possible to specify on which node a spawn operation
should be performed. A certain degree of security is provided through a
cookie mechanism. All distributed Er- lang nodes that need to communicate
must know each others cookies. The cookies work essentially like
passwords. It should be noted that this protocol has serious weaknesses.
Once started on a certain node there is no direct way for an Erlang process to
move. The state is carried over through the arguments to the spawned
process.
• Meeting the requirements
In the distributed Erlang system it is quite possible for a process to
misbehave in various ways.. It can spawn thousands of processes stealing
all processing power, or it can allocate large amounts of memory etc. In the
following sections we will see how these problems are solved in STEAM.
Agent closure Our solution to the above mentioned problems is divided in
two parts. The rst is to encapsulate the agent in an agent closure. An agent
can consist of several Erlang processes and these processes execute within
the agent closure. The closure consists of three main parts. First there is an
Agent Supervisor which is responsible for the agent, serving agent processes
and handling charging for resource usage. At regular intervals the Agent
Supervisor checks how much resources the agent processes are using.
Typical resources are the CPU usage, i.e. in the number of reductions of the
virtual machine in the Erlang system and the amount of memory which is
used by each agent process. When the agent cannot pay for its resource
usage the agent will be terminated. With this approach an agent can only use
up a limited amount of resources, To prevent an agent from being equipped
with too much resource use credit, the payment for resource use has to be
con0nected to some sort of real money, e.g. electronic cash. The second part
of the agent is the agent dictionary which acts as a shared persistent memory
for the agent processes. The agent dictionary follows the agent when it
travels between stations. The last part of the agent closure is the KQML
Gate through which the agent can communicate with other agents.
 3

Agent compilation It must be possible to prevent an agent from using

functions that kill other processes, le system etc. Still, some agents must be
able to access local system resources in order to enable the agent system to
perform meaningful tasks. To this end, agents are divided into two classes:
stationary and mobile. Stationary agents can't move and are started by the
user on his own station. They are considered trusted and should not have any
restrictions in using modules or BIFs. Mobile agents, on the other hand,
represent a potential threat and should not have unrestricted access to
dangerous BIFs and modules. are compiled with added runtime checks for
module and BIFs usage. If a mobile agent tries to use a forbidden BIF or
module, it is terminated. Agent representation An agent is represented as a
package in which information concerning the agent is stored, e.g. agent type,
unique agent id, agent dictionary etc. The agent code is also stored within
this package in a precompiled form. This is essentially a parse tree created
from the agent Erlang source code. When an agent arrives at a station, the
station master compiles the code and loads it into the Erlang runtime system.
• library of agent functions

We have chosen to implemented agents in Erlang as groups of

communicating Erlang processes. These processes can then perform specific
tasks, such as communicating with other agents or performing
computations.This is the natural way to design applications in Erlang, and
the language influenced the basic architecture of the agents.

For the agent specic functionality we choose to stay with Erlang as the agent
programming language, instead of implementing a new special-purpose
 3

language. Agent-specic functionality is provided through special functions,

which is the normal way to add functionality to Erlang. First of all we need a
set of libraries to solve the requirements for security:
• Secure communication
• Authentication
• Resource handling
These will be described in more detail below. Then we identied a number of
obvious agent functions, much like the cooperating system for agents.
Agents typically have to interact with other agents and users, write and send
email, and access local information. Remember that one of the requirements
was the ability to exchange sensitiv and condential information. In the next
section we will describe functions for:
• KQML
• Email system
• Visualization
• KQML
KQML is used as the protocol for agent communication. The protocol has
existed some years now, and there are several applications that use it. We
have nothing to say about whether KQML is the most suitable protocol for
our application or not, but we have used it since it is a de-facto standard, and
we want to be able to communicate with agents running inside other agent
systems. We see three types of bidirectional communication in the system:
• station to station
• agent to agent
• agent to user
Our approach is to use KQML for all inter-agent communication, whether it
is between agents in STEAM or between a STEAM agent and an external
agent on an external agent platform. Station-to-station communication is
actually communication between two station masters, a special kind of
stationary agent, and thus uses KQML. Communication between an agent in
STEAM and a user interface also uses KQML { the agent sees its user
interface as another agent. The communication between agents is location
transparent thanks to the distributed name server in the communications
layer which at all times keeps tracks of the current location of an agent. The
STEAM system uses a number of different transport protocols, depending
upon whom the system is communicating with. Internally, between STEAM
stations, distributed Erlang is used, while TCP/IP is used to communicate
with external agents. Adding more transport protocols is transparent to the
existing agents. KQML implementation We have implemented a subset of
 3

KQML which follows the syntax and semantics . We have only

implemented those parts that were useful in our project, i.e. performatives
for questions, responses, and problem reports. STEAM does not implement
a KQML facilitator. The name server functionality is implemented in the
communications sublayer. The broker functionality has been simplied and is
implemented as a simple Service Lookup Agent (SLA) instead. Service
Lookup Agent Each station has an SLA. Agents may register their agent
names with the SLA or the services that they can perform. An agent looking
for another agent, either by its name or by a service that it can perform, asks
the local SLA for theaddress of agent. The agents then communicate
directly.Secure communication To achieve a secure communication between
agents a slightly modified version of the Secure KQML protocol, proposed
in , has been implemented.Communication security is based on the notion of
secure domains. In a secure domain, all stations are assumed to be friendly,
and secure communication is possible without encryption. This is the case in
a company network behind are wall. Communication with stations outside
the domain is done by encrypted connections. A domain may consist
of one or more stations.The security enhancement is added to the KQML
implementation as an agent sub layer without involving the agent
application. The agent application specifies the desired degree of security to
a crypto-aware Security Manager. Through a handshake with the receiving
party it secures the messages up to the desired level. The implemented
Security Manager supports privacy, authentication, integrity of messages,
non-repudiation of message origin and protection against message replay.
The cryptographic and signing facilities are implemented as library calls
using existing RSA implementations .The Secure KQML protocol consists
of two phases: the authentication phase and theprivacy phase. In the
authentication phase initial parameters for a private conversation are setup.
During the privacy phase the actual messages are sent and received.
Performance improvements Achieving privacy by using RSA to encrypt the
whole messages is quite demanding, computation wise.The approach in and
is more efficient as only a small session key is encrypted by RSA. The rest
of the message is encrypted with the session key using symmetric encryption
methods such as DES and IDEA. Only lack of time has prevented us from
doing the same; STEAM could easily be extended to use the more efficient
method. Authentication Agents must be sure of the identity of the party that
they wish to exchange information with. For this a two-way authentication
protocol is used which is based on RSA authentication using 256-bit random
strings. Each agent is given two pairs of RSA keys, one to sign messages
and the other to encrypt.The public keys are distributed in the system
 3

through a distributed database, and are available to all agents. Resource

handling To control the usage of resources in the system a scheme similar to
Teleclicks in Telescript was implemented. In STEAM, the unit of resource
consumption is called a metapill. Each agent has a supply of metapills,
which is decremented each time the agent uses some system service. The
agent is also charged for usage of memory and CPU-time. The purpose of
the system is primarily to stop agents from using all the resources at a station
(and thus denying other agents service). If the system is connected to an
electronic payment system, it would allow agents to bill each other for
services.Email and systemAgents may need to use email to communicate
with users, or to access the data stored in the local system. In order not to
violate security, this is performed through stationary agents. Mobile agents
cannot directly access any local resources, or send email. It was not
necessary to implement new functions for this, as adequate support for email
and system access is provided in standard Erlang libraries.Visualization The
visualization part can be considered as a separate system. It can in fact be
used by another client or run separately with some modifications. The
visualization acts as a separate agent connected to the STEAM station. The
visualization system is used in two ways: to monitor the steam station and to
implement the user interface in the application (our meeting scheduler).
Communication between the client system (in this case a STEAM station)
and the visualization package is done using KQML over TCP/IP. A
conversation is established between a client application (e.g. station master)
and an applet specially designed for the application (e.g. showing the action
taking place on the station). Information is then sent between these two via
the visualization master in the client system and its correspondence in the
visualization system. The system is completely implemented in Java for
portability reasons, and the choice of TCP/IP was to make the visualization
system exible. This makes it is easy to replace the visualization in the
STEAM system or to use it in a di
erent system. 2.5 Application: a meeting scheduler The overall architecture
for an application consists of a set of stationary agents having access to
system specific resources and a set of mobile agents which act on behalf of
the stationary agents. The interaction between agents and the user is
performed via one or more user interface programs (applets or something
else). The user interface programs look like ordinary agents to the
application agents.The application we chose to implement was a meeting
scheduler which was used to validate the requirements of the STEAM
system. The design and implementation was more focused on validating the
requirements than fancy features. The meeting scheduling system is
 3

composed of three separate systems, each with its own autonomous

functionality:

• A user interface that can supply information about a meeting to be

scheduled.
• An existing personal calendar system.
• An agent appointments system that can schedule joint meetings between
several participating users and locations.
The user interface is a Java applet running in a web browser. The existing
calendar system is all the functionality expected from a personal calender
system. It has a nice and easy to use X based user interface and stores the
appointment information in a simple and easily extensible format.
Each user has two agents: a stationary master appointment agent residing on
the user's home station, and a mobile slave appointment agent. Locations
(meeting rooms) also havea pair of agents but these can reside on any
STEAM station. Each group of users and locations that can use the
appointment system has their appointment agents registered in a group
specific name server agent. Both users and locations can belong to several
appointment groups at the same time. One or more constraint solver agents
are used to solve the problem of a time interval in which all participants
have nothing scheduled.The meeting scheduler system can schedule a
meeting given a list of participants, a date,a location, and a time range within
which a meeting of a certain duration is wanted. An example A user, Sue,
wants to set up a meeting and opens the appointments system applet in her
web browser. Sue wants to make sure that no one else is able to set up
meetings in her name so she has made this applet private. This means that
she has to authenticate her identity by entering an encryption key before
continuing. The applet then sets up a connection to Sue's master appointment
agent and it responds by sending back a list of possible participants and
locations to choose from, i.e. those currently registered in the appointments
system's name server. Next, her master appointment agent tells the applet to
show a form where Suells in the data for the meeting. When Sue is finished
she presses the send button and lets the appointment agent system take over.
The stationary master appointment agent on Sue's STEAM station receives a
request to book the new meeting. Its task is to contact the master
appointment agents of the participants and sends them a request specifying
the data of the meeting. All participating master appointment agents extract
the time slots available on the given day from their They then forward the
information to their mobile slave agents. The slaves then travel to the station
where the constraint solver agent resides. When all participating slave agents
 3

have arrived at the constraint solver agent, Sue's slave acts as an

administrator. It then makes sure that all data from the other slave agents
are sent to the constraint solver, which in turn then tries to a suitable time.
The result from the constraint solver is sent back to the administrator (Sue's
slave) which then forwards it to the other slaves. If a joint meeting could be
scheduled the slave agents return back to their home stations with the result.
The master appointment agents then update their respective Ical calendar
less with the new appointment and notes the user by sending them an email
about the new appointment. Sue is noticed via the Java applet instead. If no
meeting could be scheduled Sue is noticed about it via the applet, and she
can try again with new data for the meeting.
• Related and future work
We found that Erlang was fairly well suited for programming an application
with secure mobile agents. Although many essential things such as
encryption, KQML, etc. are missing from Erlang, this functionality can be
added through a set of library functions. The main problem was that
distributed Erlang had to be used since the name server uses the distributed
database Mnesia. This caused problems with the security between stations.
One station can for example halt any station within the agent system due to
the distributed Erlang philosophy. To prevent this the Erlang language itself
must be changed and thereby disable much of the features which distributed
Erlang overs. However, as a workaround we secure domains, where
distribution is allowed, and all communication to other domains is done by
encrypted connections. Further work has to be done to decide which
algorithm to use to spread trusted domain addresses. One possible solution
is to use the PGP model.Our application could perhaps have been better
chosen had mobility been an essential demand. However, there are
advantages even for a simpler application such as our meeting scheduler in
using mobile agents. Related work Many systems are being released which
support mobile agents. Telescript is an environment that supports portable
and secure code. The programming language is objectoriented and provides
an operator that can move running programs with its state between machines
during execution. Telescript has also focused on security with with
encryption and digital signatures. Our approach and also AgentTCL's is in
many areas similar to Telescript. However, our system is based on a high
level symbolic functional language, where we with a set of minor
adjustments are able to satisfy our requirements on security for mobile
agents. A lot of activity can be seen around Java, due to its incorporation in
several Web browsers. Java per se is not a system for mobile agents, but
mobile agents, but with extensions like MOLE, Aglets, JavaAgent etc. you
 3

can build such a system. The security though seems in exible: the message
\security violation" pops up as soon as you try to do something useful.
Java vs. Erlang As the project was using both Java and Erlang it is natural to
compare the two languages, although they were used for di
erent purposes. Java was mainly used for the graphical interface, but code
was also written to parse and generate KQML. The execution performance
of Java was much lower than we had expected, especially in the parser,
which we could compare directly to the corresponding code in Erlang.
To us it seems the garbage collector in our version Java for SUN (JD 1.0.2)
was one of the main reasons for this in efficiency, but the implementation of
the Java Virtual Machine was probably also not particularly client. Some
bugs in the Java development environment indicated that the product is a bit
immature, but nothing that prevents it from being usable. Java (in JDK
1.0.2) uses cooperative multitasking, where each thread must give up its
execution voluntarily. This complicated programming. Erlang on the other
hand has full preemptive multitasking, and seems to handle a large number
of processes much more eciently. Both languages are nice to work with,
although the code in Erlang is more compact and readable. Further work
Although Erlang has some shortcomings as an agent programming language
it seems better suited than most alternative approaches. One aspect that
should be improved is the fact that there is no way to really migrate
processes in Erlang. The only way to achieve this now is to spawn new
processes in the new runtime system and kill the old processes. We intend to
investigate the possibility of extending the Erlang run time system so that a
group of processes may be explicitly moved to another node. We would also
like to add basic security support to the Erlang run time system, based on
results from this work and work on SafeErlang. Mobile agents are
particularly advantageous in systems where it is hard or impossible to
maintain a connection between the nodes, such as in radio-based systems.
An agent with a complicated task need be sent just once, and this will reduce
the trac on the connection considerably. This is particularly important in the
case when the user agent is simplistic,and requires a lot of interaction. A
promising for exploration is therefore the use of mobile agents for
implementing advanced functions in PDA:s and other portable
terminals,such as mobile phones. These systems are a challenge as they have
limited memory and computing capacity, and the security requirements are
vital for most applications.
 3

 Protecting the Agent Platform

One of the main concerns with an agent system implementation is ensuring
that agents are not able to interfere with one another or with the underlying
agent platform. One common approach for accomplishing this is to establish
separate isolated domains for each agent and the platform, and control all
inter-domain access. In traditional terms this concept is referred to as a
reference monitor . An implementation of a reference monitor has the
following characteristics:
• It is always invoked and non-bypassable, mediating all accesses;
• It is tamper-proof; and
• It is small enough to be analyzed and tested.
Implementations of the reference monitor concept have been around since
the early 1980’s and employ a number of conventional security techniques,
which are applicable to the agent environment. Such conventional
techniques include the following:
• Mechanisms to isolate processes from one another and from the control
process,
• Mechanisms to control access to computational resources,
• Cryptographic methods to encipher information exchanges,
• Cryptographic methods to identify and authenticate users, agents, and
platforms, and
• Mechanisms to audit security-relevant events occurring at the agent
platform.
More recently developed techniques aimed at mobile code and mobile agent
security have for the most part evolved along these traditional lines.
Techniques devised for protecting the agent platform include the following:
• Software-Based Fault Isolation,
• Safe Code Interpretation,
• Signed Code,
• Authorization and Attribute Certificates,
• State Appraisal,
• Path Histories, and
• Proof Carrying Code.
 Software-Based Fault Isolation

Software-Based Fault Isolation , as its name implies, is a method of isolating

application modules into distinct fault domains enforced by software. The
 3

technique allows untrusted programs written in an unsafe language, such as

C, to be executed safely within the single virtual address space of an
application. Untrusted machine interpretable code modules are transformed
so that all memory accesses are confined to code and data segments within
their fault domain. Access to system resources can also be controlled
through a unique identifier associated with each domain. The technique,
commonly referred to as sandboxing, is highly efficient compared with
using hardware page tables to maintain separate address spaces for modules,
when the modules communicate frequently among fault domains. It is also
ideally suited for situations where most of the code falls into one domain
that is trusted, since modules in trusted domains incur no execution
overhead.

 Safe Code Interpretation

Agent systems are often developed using an interpreted script or
programming language. The main motivation for doing this is to support
agent platforms on heterogeneous computer systems. Moreover, the higher
conceptual level of abstraction provided by an interpretative environment
can facilitate the development of the agent’s code. The idea behind Safe
Code Interpretation is that commands considered harmful can be either
made safe for or denied to an agent. For example, a good candidate for
denial would be the command to execute an arbitrary string of data as a
program segment. One of the most widely used interpretative languages
today is Java. The Java programming language and runtime environment
enforces security primarily through strong type safety. Java follows a so-
called sandbox security model, used to isolate memory and method access,
and maintain mutually exclusive execution domains. Security is enforced
through a variety of mechanisms. Static type checking in the form of byte
code verification is used to check the safety of downloaded code. Some
dynamic checking is also performed during runtime. A distinct name space
is maintained for untrusted downloaded code, and linking of references
between modules in different name spaces is restricted to public methods. A
security manager mediates all accesses to system resources, serving in effect
as a reference monitor. In addition, Java inherently supports code mobility,
dynamic code downloading, digitally signed code, remote method
invocation, object serialization, platform heterogeneity, and other features
that make it an ideal foundation for agent development. There are many
agent systems based on Java, including Aglets , Mole , Ajanta , and
Voyager. However, limitations of Java to account for memory, CPU, and
network resources consumed by individual threads and to support thread
 3

mobility have been noted. Probably the best known of the safe interpreters
for script-based languages is Safe Tcl which was used in the early
development of the Agent Tcl system. Safe Tclemploys a padded cell
concept, whereby a second “safe” interpreter pre-screens anyharmful
commands from being executed by the main Tcl interpreter. The term
padded cell refers to this isolation and access control technique, which
provides the foundation for implementing the reference monitor concept.
More than one safe interpreter can be used to implement different security
policies, if needed. Constructing policy-based interpreters requires skill to
avoid overly restrictive or unduly protected computing environments.
In general, current script-based languages do not incorporate an explicit
security model in their design, and rely mainly on decisions taken during
implementation. One recent exception is the implementation of secure
JavaScript in Mozilla . The implementation uses a padded cell to control
access to resources and external interfaces, prevents residual information
from being retained and accessible among different contexts operating
simultaneously or sequentially, and allows policy, which partitions the name
space for access control purposes, to be specified independently of
mechanism.
 Signed Code
A fundamental technique for protecting an agent system is signing code or
other objects with a digital signature. A digital signature serves as a means
of confirming the authenticity of an object, its origin, and its integrity.
Typically the code signer is either the creator of the agent, the user of the
agent, or some entity that has reviewed the agent. Because an agent operates
on behalf of an end-user or organization, mobile agent systems commonly
use the signature of the user as an indication of the authority under which the
agent operates. Code signing involves public cryptography, which relies on a
pair of keys associated with an entity. One key is kept private by the entity
and the other is made publicly available. Digital signatures benefit greatly
from the availability of a public key infrastructure, since certificates
containing the identity of an entity and its public key (i.e., a public key
certificate) can be readily located and verified. Passing the agent’s code
through a non-reversible hash function, which provides a fingerprint or
unique message digest of the code, and then encrypting the result with the
private key of the signer forms a digital signature. Because the message
digest is unique, and thus bound to the code, the resulting signature also
serves as an integrity mechanism. The agent code, signature, and public key
certificate can then be forwarded to a recipient, who can easily verify the
source and authenticity of the code. Note that the meaning of a signature
 3

may be different depending on the policy associated with the signature

scheme and the party who signs. For example, the author of the agent, either
an individual or organization, may use a digital signature to indicate who
produced the code, but not to guarantee that the agent performs without fault
or error. In fact, author-oriented signature schemes were originally intended
to serve as digital shrink wrap, whereby the original product warranty
limitations stated in the license remain in effect (e.g., manufacturer makes
no warranties as to the fitness of the product for any particular purpose).
Microsoft's Authenticode, a common form of code signing, enables Java
applets or Active X controls to be signed, ensuring users that the software
has not been tampered with or modified and that the identity of the author is
verified. For many users, however, the signature has gone beyond
establishing authenticity and become a form of trust in the software, which
could ultimately have disastrous consequences.Rather than relying solely on
the reputation of a code producer, it would be prudent to have an
independent review and verification of code performed by a trusted party or
rating service. For example, the decision to execute an agent could be taken
only with the endorsement of a site security administrator, given in the form
of a digital signature applied to the code. While such an approach may be
desirable, experience with trusted computer evaluations indicates that
obtaining quality security reviews in a timely fashion is difficult to achieve.
Nevertheless, some checking is better that none, provided that the limitations
are known by everyone.
 State Appraisal
The goal of State Appraisal is to ensure that an agent has not been somehow
subverted due to alterations of its state information. The success of the
technique relies on the extent to which harmful alterations to an agent's state
can be predicted, and countermeasures, in the form of appraisal functions,
can be prepared before using the agent. Appraisal functions are used to
determine what privileges to grant an agent, based both on conditional
factors and whether identified state invariants hold. An agent whose state
violates an invariant can be granted no privileges, while an agent whose state
fails to meet some conditional factors may be granted a restricted set of
privileges. Both the author and owner of an agent produce appraisal
functions that become part of an agent's code. An owner typically applies
state constraints to reduce liability and/or control costs. When the author and
owner each digitally sign the agent, their espective appraisal functions are
protected from undetectable modification. An agent platform uses the
functions to verify the correct state of an incoming agent and to determine
what privileges the agent can possess during execution. Privileges are issued
 3

by a platform based on the results of the appraisal function and the

platform's security policy. It is not clear how well the theory will hold up in
practice, since the state space for an agent could be quite large, and while
appraisal functions for obvious attacks may be easily formulated, more
subtle attacks may be significantly harder to foresee and detect. The
developers of the technique, in fact, indicate it may not always be possible to
distinguish normal result from deceptive alternatives.
 Protecting Agents
While countermeasures directed towards platform protection are a direct
evolution of traditional mechanisms employed by trusted hosts, and
emphasize active prevention measures, countermeasures directed toward
agent protection tend more toward detection measures as a deterrent. This is
due to the fact that an agent is completely susceptible to an agent platform
and cannot prevent malicious behavior from occurring, but may be able
to detect it. The problem stems from the inability to effectively extend the
trusted environment of an agent’s home platform to other agent platforms.
While a user may digitally sign an agent on its home platform before it
moves onto a second platform, that protection is limited. The second
platform receiving the agent can rely on the signature to verify the source
and integrity of the agent’s code, data, and state information provided that
the private key of the user has not been compromised. On the agent’s
subsequent hop to a third platform, the initial signature from the first
platform remains valid for the original code, data, and state information, but
not for any state or data generated on the second platform. For some
applications, such minimal protection may be adequate. For example, agents
that do not accumulate state or convey their results back to the home
platform after each hop have less exposure to certain attacks. For other
applications, simple schemes may prove protecting an agent include the
following:
• Partial Result Encapsulation,
• Mutual Itinerary Recording,
• Itinerary Recording with Replication and Voting,
• Execution Tracing,
• Environmental Key Generation,
• Computing with Encrypted Functions, and
• Obfuscated Code (Time Limited Blackbox).
 3

 Mobile Agent Security

• Security Requirements
The users of networked computer systems have four main security
requirements:
confidentiality, integrity, availability, and accountability. The users of
agent and mobile agent frameworks also have these same security
requirements. This section provides a brief overview of these security
requirements and how they apply to agent frameworks.
• Confidentiality
Any private data stored on a platform or carried by an agent must remain
confidential. Agent frameworks must be able to ensure that their intra- and
inter-platform communications remain confidential. Eavesdroppers can
gather information about an agent's activities not only from the content of
the messages exchanged, but also from the message flow from one agent to
another agent or agents. Monitoring the message flow may allow other
agents to infer useful information without having access to the actual
message content. A burst of messages from one agent to another, for
example, may be an indication that an agent is in the market for a particular
set of services offered by the other agent. The eavesdropping agent or
external entity may use this information to gain an unfair advantage. Agents
may be able to detect an Agent Communication Language (ACL)
conversation signature pattern to infer further meaning from an agent
conversation. A procurement agent may, for example, send three messages
to a vendor agent, followed by one message to its home platform, and
conclude the transaction with two messages to the vendor agent. The vendor
agent may send two messages to a credit-checking agency and conclude with
a message to its banking agent. Although the contents of the messages
have never been disclosed, an eavesdropper may be able to infer that the
procurement and vendor agents have successfully completed a sale of some
commodity or service. Mobile agents may also want to keep their location
confidential. Mobile agents may communicate through a proxy whose
location is publicly known if the agents want to conceal their presence on a
particular platform. Agents must be allowed to decide if their presence will
be publicly available through platform directories, and platforms may
enforce different security policies on agents that chose to be anonymous. An
 3

agent shopping for goods and services may wish to do so in privacy, but
when a financial transaction is to be carried out the platform may require
some form of authentication. Agents can assume a pseudonym to conceal
their identity from other agents, but this pseudonym is reversible and cannot
be used to conceal its identity from the platform itself. In addition, an agent
may not want to disclose which platforms it has visited on its itinerary, but
the platform security policy of its host may not be willing to accept agents
that have been on certain platforms outside the authority of certain approved
security domains. Since audit logs maintain a detailed record of an agent's
activities on the platform, the contents of the audit log must also be carefully
protected and remain confidential. Access to the audit logs must be restricted
to authorized administrators. A mobile agents' audit log may be distributed
across several security domains, each having a different audit policy, so
some agents may want to carry certain parts of their audit log with them for
future reference. In some cases the mobile agent may require the host
platform to sign portions of the audit log for which it was responsible.
• Integrity
The agent platform must protect agents from unauthorized modification of
their code, state, and data and ensure that only authorized agents or
processes carry out any modification of shared data. The agent itself cannot
prevent a malicious agent platform from tampering with its code, state, or
data, but the agent can take measures to detect this tampering. The secure
operation of mobile agent systems also depends on the integrity of the local
and remote agent platforms themselves. A malicious host can easily
compromise the integrity of a mobile agent that is visiting a remote agent
platform. The trend towards releasing open source platforms and operating
systems makes it easier for unscrupulous administrators or organizations to
make unauthorized modifications to the agent platform and the underlying
framework. The agent's user and developer may have no knowledge of
the behavior of this modified framework and the effects it will have on the
agent's code, state and data that are under the platform's complete control. A
malicious platform may make subtle changes in the execution flow of the
agent’s code and make changes to computed results that are difficult to
detect. A malicious platform could interfere in transactions between agents
representing different organizations and tamper with the audit trails. This
could result in each organization involved in the transaction blaming the
other for not delivering promised goods or services.System access controls
must be in place to protect the integrity of the agent platform from
unauthorized users. Changes to the platform by unauthorized users are more
likely to be detected over time than changes to the platform by authorized
 3

users. Intentional modification or tampering with the agent platform by

authorized or unauthorized users places additional burden on mobile agents
to be able to detect and recover from intentional corruption or alteration.
Many security mechanisms available to the agent to protect itself may come
at a serious performance and development cost and must be carefully
weighed against the advantages offered by code mobility. If the agent is
carrying out a critical or sensitive task for which it must assume an
unreasonable risk or for which it cannot provide suitable protection, the
agent developer or user may choose to restrict the agent's mobility.Thus,
given the current security mechanisms available to mobile agents, agents
may choose to forego mobility during certain security-sensitive transactions,
and limit the types of security-sensitive transactions a mobile agent is
authorized to conduct. Goal-oriented attacks against agent communications
aim to compromise the integrity of an intra- or inter-platform message by
changing the content of the message, replacing the entire message, reusing
an old message, deleting the message, or changing the source or destination
of the message. Goal-oriented malicious attacks on the integrity of agent
communications can do far greater harm to the agent than transmission
errors resulting from poor or intermittent communication channels. Agent
platforms rely on lower-level protocols to ensure the integrity of the agent
communications. For example, TCP/IP ensures the detection of most
transmission errors, and processes in the communications stack detect errors
and arrange for retransmission. This error detection and correction is
transparent to higher-level applications that rely on these protocols to ensure
the integrity of their communications.
• Accountability
Each process, human user, or agent on a given platform must be held
accountable for their actions. In order to be held accountable each process,
human user, or agent must be uniquely identified, authenticated, and audited.
Example actions for which they must be held accountable include: access to
an object, such as a file, or making administrative changes to a platform
security mechanism. Accountability requires maintaining an audit log of
security-relevant events that have occurred, and listing each event and the
agent or process responsible for that event. Security-relevant events are
defined in the platform security policy and should include, at a minimum,
the following: user/agent name, time of event, type of event, and success or
failure of the event. Audit logs must be protected from unauthorized access
and modification. Measures need to be in place to prevent auditable events
from being lost when the storage media reaches its capacity. These measures
can include alerting the system administrator when the audit logs reach a
 3

certain capacity and depend on the system administrator to perform routine

maintenance as part of their normal administrator duties. Audit logs keep
users and processes accountable for their actions. Mobile agents create
audit trails across several platforms, with each platform logging separate
events and possibly auditing different views of the same event (e.g.,
registration within a remote directory). In the case where an agent may
require access to information distributed across different platforms it may be
difficult to reconstruct a sequence of events. Platforms that keep distributed
audit logs must be able to maintain a concept of global time or ordering
of events. Auditing agent actions is very important considering the liability
issues that may arise from the failure of a platform administrator to exercise
due diligence in preventing known denial of service attacks. Legal issues
may also come into play as rules governing the actions of agents may differ
in states, countries, and regional trading blocks. Audit logs are also
necessary and valuable when the platform must recover from a security
breach, or a software or hardware failure. Full recovery from a faulty o
compromised system requires not only restoring the system to a safe state
and performing some sort of fault diagnosis, but also sorting out which
agents belonging to which organizations were affected. Audit logs are also
necessary in cases of agents falsely repudiating their actions and for
potential liability issues that are unique to agent societies. Authentication
mechanisms provide accountability for user actions. Agents must be able to
authenticate their identity to platforms and other agents, while platforms
must be able to authenticate their identity to agents and other platforms. The
level of sensitivity of the transaction or data for which agents request access
may require the agent to offer different degrees of authentication. In agent
societies where reputation is valued and used as a means to establish trust,
an agent platform must exercise due diligence to protect an agent's
reputation from being harmed by other agents through masquerade. An agent
accessing publicly advertised product prices may not be required to
authenticate itself at all and may only have "read access" to certain public
data, but if this agent decides to purchase any of these products the agent
must be able to authenticate itself before the transaction is completed.
Similarly, the purchasing agent will require some proof of the selling agent's
claimed identity. Both the purchasing and selling agent may require the
agent platform to authenticate itself before they visit this platform. Humans
must be able to authenticate themselves to agents through whatever means
the agent platform makes available to the human user, for example, voice
recognition, biometrics, passwords, or smart cards. Accountability is also
essential for building trust among agents and agent platforms. An
 3

authenticated agent may comply with the security policies of the agent
platform, but still exhibit malicious behavior by lying or deliberately
spreading false information. Additional auditing may be helpful in proving
the malicious agent's attempts at deception. For example, the communication
acts of an ACL conversation could be logged, but this results in costly
overhead. If it is assumed that the malicious agent does not value its
reputation within an agent community, then it would be difficult to prevent
malicious agents from lying.
• Availability
The agent platform must be able to ensure the availability of both data and
services to local and remote agents. The agent platform must be able to
provide controlled concurrency, support for simultaneous access, deadlock
management, and exclusive access as required. Shared data must be
available in a usable form, capacity must be available to meet service needs,
and provisions for the fair allocation of resources and timeliness of service
must be made. The agent platform must be able to detect and recover from
system software and hardware failures. While the platform can provide some
level of fault-tolerance and fault-recovery, agents may be required to assume
responsibility for their own fault-recovery. The agent platform must be able
to handle the requests of hundreds or thousands of visiting and remot agents
or risk creating an unintentional denial of service. In the event that a
platform cannot handle its computational and communication load, the
platform must provide graceful degradation of services and notify agents
that it can no longer provide the level and quality of service expected by the
agents requesting its services. The threat of a denial of service attack being
launched by rogue or flawed agents underscores the need for the control and
monitoring of platform resources. A denial of service attack against the
platform is an indirect attack on all the agents that rely on this platform for
agent services and platform resources. Since the platform may be hosting
agents from several other organizations, a denial of service attack on a single
platform may adversely impact more than one agent, platform, organization.
Ensuring confidentiality and integrity places restraints on availability and
also has performance costs. Encrypting agents and messages in transit may
impose unacceptable delays in environments where near real-time response
is required. Ensuring accountability may also place restraints on the
availability of platform services. For example, when the audit log storage
media exhausts its capacity, many security policies disable all services
that create records in the audit log. In an effort to maintain accountability,
this policy may inadvertently create an opportunity for a denial of service
attack by simply producing an inordinate amount of auditable events, such
 3

as repeated failed login attempts, and consume the remaining capacity of the
audit log storage media.
• Anonymity
The agent platform may need to balance an agent's need for privacy with the
platform's need to hold the agent accountable for its actions. The platform
may be able to keep the agent's identity secret from other agents and still
maintain a form of reversible anonymity where it can determine the agent’s
identity if necessary and legal. Anonymity in human communities may help
foster certain types of commerce or promote the freedom of expression by
eliminating the fear of retribution for voicing unpopular viewpoints. There
are many situations, however, in which the participants are reluctant or
unwilling to engage in a transaction with an anonymous counterpart.
Purchasers of goods and services may want to protect their privacy by
remaining anonymous, but credit agencies would not extend credit to
anonymous consumers without being able to verify their credit history and
credit worthiness. The anonymity issues affecting human communities also
apply to agent communities. The security policies of agent platforms and
their auditing requirements must be carefully balanced with agent privacy
expectations. The collection and use of audit information for uses other than
security must also be understood by the agents visiting the agent platform.
Moreover, what information belongs in public agent directories and under
what conditions can the information be accessed from these directories must
also be carefully controlled.
• Countermeasures
Many conventional security techniques used in contemporary distributed
applications (e.g., client-server) also have utility as countermeasures within
the mobile agent paradigm. Moreover, there are a number of extensions to
conventional techniques and techniques devised specifically for controlling
mobile code and executable content (e.g., Java applets) that are applicable to
mobile agent security. We review these countermeasures by considering
those techniques that can be used to protect agent platforms, separately from
those used to protect the agents that run on them. Most agent systems rely on
a common set of baseline assumptions regarding security. The first is that an
agent trusts the home platform where it is instantiated and begins execution.
The second is that the home platform and other equally trusted platforms are
implemented securely, with no flaws or trapdoors that can be exploited, and
behave non-maliciously. The third is that public key cryptography, primarily
in the form of digital signature, is utilized through certificates and revocation
lists managed through a public key infrastructure.
 3

 Why use Mobile Agents In Peer to Peer Networks?

Mobile agents reduce the need for bandwidth. Very often peers using a
distributed protocol establish a communication channel between themselves,
and then perform multiple interactions over this channel. Each of these
interactions generates network traffic. Mobile agents allow these interactions
to be packaged together, and sent as a discrete piece of network traffic. This
then allows all the interactions to take place locally. Mobile agents also
encapsulate all the required data within themselves. Therefore when a
mobile agent arrives on a computer it has all its data with it, and does not
need to communicate with any other computers. In a conventional search
protocol all the raw data travels over the network to be processed, even
though only a subset of this data may be needed. In this scenario, mobile
agents reduce the network traffic by moving the processing to the raw data,
instead of moving the raw data to the processing. Finally, mobile agents can
be very small in size, but can grow dynamically as they need to
accommodate more data. Mobile agents are asynchronous. Therefore when a
mobile agent is dispatched there is no need to wait for it to return. Indeed the
original peer does not even need to remain connected to the network while
the mobile agents are out. The mobile agents can wait until the original peer
is back on the network before attempting to return to it. Mobile agents are
autonomous. This particularly suits network discovery, because the mobile
agent is learning about the network as it progresses through it. The mobile
agent will visit peers that were unknown when it was originally dispatched.
At each peer it can make decisions based on its history of visited peers and
the current peer. Information is being disseminated at every peer that the
mobile agent visits. Every peer benefits from accepting a visiting mobile
agent, because the mobile agent will have either new or more recent
information about resources. Also, every mobile agent benefits from visiting
a peer because it will learn of either new or updated resources. If the mobile
agents do not contain any new information they may be destroyed.
Accepting and hosting mobile agents requires the use of physical resources,
such as memory and computer cycles. Should these become critically
limited, it is easy for the peer to refuse further requests to accept mobile
agents until more physical resources become available. Mobile agents may
easily be cloned and dispatched in different directions. This allows them to
function in parallel. Although this causes more mobile agents to be active on
the network, it does ensure that the network resource discovery is completed
 3

sooner, and therefore the mobile agents spend less time on the network.A
mobile agent based solution is very fault tolerant. Even if some of the
mobile agents are destroyed, all surviving ones will have a positive impact.
Indeed, the destroyed mobile agents will have benefited every peer up to the
point where they were destroyed.Finally, a mobile agent based solution can
be combined with successful features from other P2P based systems to
provide an improved final solution.
 Mobile Agent Use In Dynamic View System?
DVS provides an infrastructure for the dynamic deployment of views over
remote databases. It can be viewed as a multilevel dictionary that maintains
information about the remote databases to allow clients to define and
materialize such views. It also maintains information about previously
materialized views, so that they can be subsequently re-used. Materialized
views can be mobile; they are dynamically relocated following their clients
so that as to stay close to their clients.

 The Dynamic View System Architecture

DVS consists of six types of Java agents: two of them are stationary,
namely, the Dictionary_Vagent and the Assistant_Agent, and four are
mobile, namely, the Dictionary_Sagent, the Dictionary_Vclient, the
DBInfo_Agent, and the View_Agent. The two stationary types constitute
the fixed part of the architecture. The four mobile agent types comprise the
dynamic part of the architecture. Mobile agents are dynamically created and
cooperate with each other and the stationary agents in creating, maintaining,
and querying the views
 3

N e w C li e n t
O p e r a te d b y C e n tr a l A g e n t o f D V S fr a m e w o rk D a ta b a s e S e rv e r
D ic tio n a r y _ V a g e n t O p e r a te d b y a c c e s s e d th ro u g h
D ic ti o n a r y _ S a g e n t D ic t io n a r y _ V a g e n t A s s is ta n t A g e n t
D is p a t c h e s t o r e g is t e r
t h e N e w C lie n t
& d is p o s e s i ts e lf a f te r w a r d s

R e p ly M e s s a g e
- L is t o f M a t e r i a lie d v ie w s
R e q u e s t fo r a - O t h e r O p t io n s
n e w V ie w D B In fo _ A g e n t
D is p a t c h e s t o r e t r ie v e D B In fo _ A g e n t
C lie n t c o n s tr u c ts D a ta b a s e M e ta -D a ta q u e r ie s t h e
a n e w V ie w D a ta b a s e S e r v e r 's
D B In fo _ A g e n t
C a t a lo g
M e t a - D a t a is S e n d s M e ta - D a ta
s e n t to c lie n t
R e q u e s t fo r a V ie w _ A g e n t
n e w V ie w V ie w _ A g e n t
D i s p a t c h e s w it h
c re a te s
C li e n t c a n Q u e r y t h e V i e w r e q u e s te d V ie w
& m a i n ta in s V i e w

An Assistant_Agent resides at each database server . Its task is to

continuously provide incoming mobile agents with information related to the
database itself so they can connect to it and perform SQL queries. Such
information may include an appropriate JDBC driver , a reference
datasource name for the database, and authentication keys.

The Dictionary_Vagent (DVA) is the central agent of the framework. First,

it is responsible for keeping track of the locations of the various database
servers, and maintaining a snapshot of their metadata. Second, it keeps track
of all the materialized views (that is the location of the mobile agents that
maintain each materialized view), and the number of clients that are
currently using a specific materialized view for load balancing reasons.
Finally, DVA serves as a service point (an access point) for clients who wish
to query an existing materialized view or create a new one.

A Dictionary_Vclient (DVC) resides at the client side and it downloadable

from the Dictionary_Vagent host. It provides the users with a simple GUI
for submitting queries on existing materialized views, or defining a new
view in SQL.
A Dictionary_Sagent is created on demand by a Dictionary_Vclient and
dispatched from the client’s side to the DVA for registration purposes,
serving more or less as a messenger between a client and the DVA.
A DBInfo_Agent is created on demand by the DVA and its task is to
retrieve metadata from remote databases. It achieves this by dispatching
themselves to the remote database and then querying its catalog.
 3

A View_Agent (VA) is also created on demand by the DVA and its

functionality is similar to a View Holder . It is capable of creating views on
remote databases, executing queries on existing views, and also maintaining
materialized views.
Figure 1 illustrates how the various components of the system cooperate to
execute a client’s request for the creation and the querying of a view. First,
the DVC at the client communicates with the DVA in order to request its
services. This request is carried by the Dictionary_Sagent, which is created
by the DVC for this purpose. Thus, once it delivers the request to the DVA,
it terminates. Subsequently, the DVA contacts the DVC and provides the
client with the list of available materialized views, and the option of creating
a new view.
If the client selects an existing view, the DVA directs the DVC to either an
existing VA that maintains the requested view, or instantiates a new one.
If the client selects to create a new view, the DVC requests from the DVA to
retrieve the metadata of the database server involved in the new view. The
DVA, in response, creates a DBInfo_Agent, and dispatches it to the database
servers where it retrieves their metadata with the assistance of the local
Assistant_Agent. The metadata is then sent to the client who uses them to
construct the SQL definition of the new view that is subsequently submitted
to the DVA. In response, the DVA instantiates a VA, which dispatches itself
to the database servers to first create and then maintain the new view. The
client can then query the view by contacting the VA directly.

 Other Features

Task Handlers. The mobile shell is separated from the specific task code of
the target application via TaskHandlers . A TaskHandler is a Java object that
implements a particular task, i.e., a specific view update protocol. A
TaskHandler library is a collection of such objects that are serializable and
can travel along with the mobile agents. Each mobile object can load one or
more TaskHandlers and dynamically choose which one to use. For example,
for view maintenance the VA is loaded (and if necessary updated) with the
appropriate TaskHandlers implementing various view materialization
algorithms.
 3

Dynamic Code Deployment. An advantage of our architecture is that there

is no need for a priori configuring it . The static agents of the framework can
be dynamically sent at the appropriate servers at start-up and disposed when
there is no need for them.

Load Balancing. The DVA and the VAs synchronize and coordinate the
creation, update and use of each view. Since a view may be shared by
multiple clients, in the event that the corresponding VA becomes heavily
loaded, the DVA may clone (i.e., create a copy of) the VA. Thus, there may
be more that one VA per view. Furthermore, there may be replicas of the
view, in which case, the VA is responsible to choose the most appropriate
replica for a given request, thus balancing the load on the various replicas.

View Mobility. The VA and the view for a client may move following its
clients . A dynamic location management subsystem is under development
to aid the automatic acquisition of an agent’s location.

Support for Wireless Clients. DVS is appropriate for light-weight and

wireless clients. It supports both synchronous and asynchronous
communication, thus a client may pose a request, disconnect and connect
later to receive the response .

 Mobile Agent-Based Web Service Components in Semantic Web

Why Mobile (movable) Web Services? First of the reasons is the utilized
capacity of the server (which provides a service), shortage of resources when
it should serve a huge stream of online queries. That problem concerns a
service provider, and can be solved by means of service reproduction and
distribution of its copies to other servers in the Web. In this case it is
possible to decrease the utilized capacity of the concrete source. That will
also improve service discovery among a large amount of the services.
 3

Side by side with a provider a service requestor also needs Mobile

(movable) Web Services. Imagine a situation, when a client of a service
needs to use this service very often as such or as a part of a more
complicated transaction involving several services. In this case we have
frequent use of the network for service access. Besides, we cannot guarantee
such important characteristics like:

 Minimal service execution time.

 Guaranteed, permanent connection with service.

 Guaranty of confidentiality and secure private information exchange.

In this case, it would be more effective to place all frequently used services
at the client side. In this case we need to take into account the storage
capacity of a client.

Another important concern is that Web service is often a business unit,

which is being paid for its service. This means that a service that is
transferred to a client side should keep business interests of its creator
(owner). So we have here “self-interested” movable services. In this case,
the mobility of services plays a very important role allowing “inviting” a
service to a client side (platform) to serve locally.

Who and how will provide mobility of services? One solution to this
problem might be the implementation of “Agent-Shell Platforms”.

Agent-Shell Platform (ASP) is an environment for a number of (mobile)

Agent-Shells, which are assumed to be carriers of different Web Services
(Fig.6). “Platform Steward” represents ASP. Concerning the OntoShell
approach, “Platform Steward” is represented by the OntoShellContainer
(“mother shell” of the second type). “Platform Steward” provides connection
with a network of other ASPs (OntoShellContainers), registration of new
agents on the platform, shares information with local agents. In the context
of ASP, which supports agents’ migration between platforms, “Platform
Steward” is rated like a cluster supplied with OntoMobilityService. P2P
management tools for information movement via the network equip the
platform.
 3

N etw ork of A gent

-Shell Platform s

..
Platform Stew ard M obile agents

Fig. 6. Agent-Shell’s Platform

Agent-Shell (AS) is the carrier of a web service (resource). In the context of

the OntoShell approach, Agent-Shell is an OntoShell. It contains a
mechanism of interaction with the platform and other agents, service engine.
But why is it an agent? When we equip an OntoShell with a behavior
mechanism, a goal, a set of mechanisms for participation in business
environment, then it will become an agent. An agent, like a service
representative, has to be responsible for the business interests of its service.
An agent has to support service policy and certification. The mobility of the
service and its agent-based implementation provides a possibility to a Web
Service to learn during the execution on a service requestor site.

Considering both decentralized and centralized approaches to the

management of our service network, it is possible to pick out following
service network types:

• Centralized platforms – centralized agents. Each platform registers its

services (provides descriptions) at some central (mediator) platform of the
network. This platform (“Network Center”) gets direct requests for services
from clients and its “Platform Steward” decides to which platform forward
this request. Similarly, when a local platform steward gets a forwarded
request, it analyzes the request and decides to which agent (service) on the
platform to forward it to serve (Fig.7).
• Centralized platforms – decentralized agents. In this case, like in the
previous one, the central point of the network selects the platform, which is
assumed to be able to serve the request, but inside the platform, which
finally gets the request, the right servant will be found based on a peer-to-
peer (P2P) (semantic) search within the platform (Fig.8).
 3

Network Center

Agents-Services Agents-Services

Requestor Provider

Fig. 7. Centralized platforms – centralized agents

N etworkCenter

A gents-Services A gents-Services

Requestor Provider

Fig. 8. Centralized platforms – decentralized agents

P2P N etw ork

A gents-Services A gents-Services

R equestor Provider

Fig. 9. Decentralized platforms – centralized agents

 3

• Decentralized platforms – centralized platform’s agents. This case is

similar to the first one, but interoperation between platforms is based on a
peer-to-peer semantic service discovery (Fig. 9).
• Decentralized platforms – decentralized agents. This is the case, when
peer-to-peer interaction is considered within both: network of platforms as a
whole and locally within each platform (Fig. 10).

P2P Network

Agents-Services Agents-Services

Requestor Provider

Fig. 10. Decentralized platforms – decentralized agents

In a typical case we have compound services, which combine a set of

distributed (atomic) service components into one service to provide more
complex service for requestors. This complex service when created “on the
fly” decides, which of its sub-services (up to components) corresponds to a
request and how they should interact to resolve it. Outputs provided by some
components could themselves be considered as requests for some other
components etc. like in multiagent systems.

Thus atomic service components are organized in a HAS_PART –

PART_OF hierarchy from a service as a whole (abstract object) via (sub)
services (abstract objects) up to concrete components, which form a
“MegaHybrid” structure of a service network (Fig.11). Interaction between
elements on each level may be organized in either centralized or
decentralized way.
 3

Fig. 11. MegaHybrid network structure

Consider the case, when such complex service receives a request and
provides another request as an output of one of its components. Assume that
there are no other components in its platform, which can resolve this request.
The service queries the network. As a result, such service will be found, and
the request will be resolved. Evidently, it would be better for the service to
accumulate its own set of links to services, which satisfy the requirements,
and use them in violation of the standard search scheme in case of need.
Then we will have a direct interaction between services (peer-to-peer
interaction), not only between elements on some level, but also in the
“vertical” and the “horizontal” plane of the service network hierarchy
(Fig.12).

Requestor

Fig. 12. “Via-Level” Peer-to-Peer interaction

Nowadays there is already a large amount of existing Web Services. They
differ not only by types of service, but also by types of concrete physical
 3

objects that provide and consume the service. While previously services
were meant to be consumed by humans, now industry needs services for
another group of customers like various software applications and even
smart industrial field devices. On the other hand, both humans and artificial
objects (software or devices) can finally provide the service, which was
discovered in the Web.

The evolution of the Semantic Web technology allows the description of

Web Services based on a service domain ontology. Now we have a new
phase in the Web Service evolution, when autonomous service
interoperability plays a main role. However, the human component is still
left and will stay in the Web Service environment both as service-consumer
and service-provider, because many of the services provided by humans
cannot be provided by software components.

Let’s discuss both sides of human participation in the environment of

Semantic Web Services:

• Human components as consumers of a new Web Service generation.

• Human component as providers of Semantic Web enabled Web Services.
A human component, when it is a user of a semantically annotated service,
cannot and does not need to know the ontological service’s description and
specific query languages. He has to know exactly what he wants. To provide
such “simple” interface between a human component and a network of Web
Services, Agent-mediator is used. Agent-mediator is something like user-
wrapper or layer between the human component and the services network,
which knows how to handle both user queries and Web Services formal
descriptions (Fig.13).
 3

Fig. 13. Agent-mediator - intelligent layer between Software and Human

components

The main requirement to such user-wrapper is the provisioning of a simple,

friendly human user-interface:

• Simple mechanism to choose the necessary type or class of service;

• Dynamic interface provision when filling the desired service’s
characteristics;
• Service’s result representation in a human understandable form.
To satisfy this kind of requirements we have to describe the nodes in the
ontology both in software understandable and human understandable form.
Information representation in a human readable form generates a new
problem. This problem is the heterogeneity of human languages. In this
situation there are at least three choices:

• Having the ontology nodes’ description in many languages (more space

needed). Human component uses the description in his language (Fig. 14).

H uman com ponent

Fig. 14. Multilingual node’s description

• Implementing translation services for information adaptation (Fig. 15).

 3

Human component

Translation
services

Fig. 15. Information adaptation via translation service

• Using information visualization methods, different from language

description:
• Graphical (visual) representation of information;
• Multimedia (video and audio) data representation.
Above methods may be used jointly. Of course, we have to take into account
that the human component may use different devices for accessing the
information. It may be a stationary device with more functional capability or
a mobile device with limited resources.

This kind of relation between information type, access device type and
information representation format for human interface can be semantically
annotated. For that it is reasonable to elaborate an appropriate ontology.

What is the role of a human as a service provider within a network of

semantically annotated Web Services? In fact, a service represented by a
human component, it is the same Web Service as others and is described in
the same way as other Web Services. Just like the human component in the
service consuming case, in the service providing case a human component
interacts with a network of other Semantic Web services via Agent-mediator
(Fig.13).

A mobile agent-carrier of a Web Service represents it whenever it moves.

However in the case of human service, the agent-carrier can hardly be
movable within a network, because its burden – “human-service” can be
attached to some location and cannot be moved to the service consumer side.
In such context, the burden of this agent-carrier is a human provider-
 3

interface. In other words, an agent-mediator for such case is a combination

of Agent-Sell, which is carrier of service, and human provider-interface.
Human provider-interface should not only adapt formalized information for
the human component, but at the same time has to make the opposite, i.e.
formalize information from the human component in a software
understandable form.
 3

 Conclusion

Mobile agent technology can offer a new paradigm for communication over
heterogonous network channels. A number of advantages of using mobile
agent computing paradigms have been proposed and identified. These
advantages include: overcoming network latency, reducing network load,
executing asynchronously and autonomously, adapting dynamically,
operating in heterogeneous environments, and having robust and fault-
tolerant behaviour. However, the security and standardising issues still
represent a significant obstacle. The main conclusion which can be drawn
from our findings and investigation is that mobile agent technology has the
potential in increasing the performance of networks as well as for software
adopting MAs. Due to its nature of being a futuristic technology from
the programming environment perspective a lot of work is still required
before the average programmer can buildapplications based on the mobile
agent technology paradigm in an easy manner.
 3

 Bibliography

[1] S. Adnan, J. Datuin, P. Yalamanchili, a survey of mobile

agent systems, URL:
http://www.cs.ucsd.edu/classes/sp00/cse221/reports/dat-yal-adn.pdf,

[2] Aglets platform, 2004, URL:

http://www.research.ibm.com/trl/aglets/spec10.htm

[3] J. Baumann, F. Hohl, K. Rothermel, M. Straßer

Mole, Concepts of a Mobile Agent System”, to appear in the
WWW Journal, Special Issue on Applications and techniques
of web agents, 1998, Baltzer Science Publishers.

[4] Bigus, P., Bigus, J., (1998), Constructing Intelligent

Agents with Java, John Wiley &Sons Ltd, England,
ISBN: 0 471-19135-3.

[5] I. Brusic, V. Hassler, W. Lugmayr, Deployment of mobile

agents in the mobile telephone network management on
System Sciences, 2000, Proc. 33rd Annual Hawaii Int. Conf.
on, Jan 4-7, 2000 Page(s): 3108 -3116

[6] S. Campadello, O. Koskimies,K. Raatikainen, H. Helin,

Wireless Java RMI, Enterprise Distributed Object
Computing Conference, 2000. EDOC 2000. Proceedings.
Fourth International, 25-28 Sept. 2000, Page(s): 114 –123

[7] Concordia, 1997, “Concordia: An Infrastructure for

Collaborating Mobile Agents” Proc. of Workshop
On mobile agents MA’97, Berlin, April 7-8th. LNCS 1219,
Springer Verlag.

[8] P. Dasgupta, N. Narasimhan,L.E. Moser, P.m. Melliar-Smith,

Mobile agents for networked Electronic Trading, 1999 IEEE
3