MOD252 Agent Technology

Bergen University College, Bergen

Theory ,Design and Development of Agent Mobility Application

Participants:

Joachim Keyser
Phalguni Pal
Thomas Svedsen
Muhammad Suleman

University Teacher
Terje Kristensen
Høgskolen I Bergen
tkr@hib.no

1
We are here to discuss about the Theory, Design and Development of Agent Mobility
Application. We are not going in a very detailed discussion about what is agent technology?
Or what is multi-agent system? The reader is supposed to have a good understanding of agent
technology. Mobility in agent is a hot issue, how agent can move in a network, from one
platform to another, which language they need to understand their mobility plus what kind of
messages and protocols should be used. The pattern is presented as; first I am going to write
about a little bit regarding mobility and its types, and then modeling in UML for agent
mobility and Java support for agent mobility application. I will end my report with an
example of agent mobility in e-commerce.

What is Mobility?

The term mobility is used to indicate a change of location performed by the entities of a
system. Starting from simple data, the mobility has had an evolution that has led to move the
execution control, the code and the execution environment. In the first step of such evolution
we find the mobility of files, for example with the FTP protocol. The next step is the remote
procedure call; in this case the execution flow is involved in the movement. Even if the idea is
quite simple and it extends local procedure call, this new model had a great impact in
computer science. Then there was the idea to move code. A piece of program is sent to
another machine and is executed there. This is called remote evaluation (RE) if the sender
starts the action, while it is called code on demand (COD) if the receiver does it. Finally,
active entities became able to move the environment where they are executing, as better
described in the next section. Thus, the natural evolution of mobility seems to be agent
mobility. An agent is an active software entity that shows several degrees of autonomy, since
it has to take decisions and to carry out jobs without the direct participation of the user. A
mobile agent is an autonomous entity with the capability of roaming among nodes in a
network-aware fashion to find the needed resources and services. Typically, a mobile agent
decides the node where to move, for example via a call to a method like go(NewNode).

Mobility with Programming

Recently, code mobility has gained popularity because of two main reasons. On the one hand,
the Java language has provided support and tools to write programs that can move through
networks (applets are the simplest example), playing a fundamental role in future distributed

2
applications. On the other hand, the Internet proposes a dynamic and connected environment
where code mobility can suit the design of several distributed applications.
In the context of applications exploiting code mobility, the mobile agent paradigm is one of
the most promising technologies to build distributed applications in heterogeneous
environments. Mobile agents are autonomous software entities with the capability of
dynamically changing their execution environments in a network-aware fashion, and roaming
through network nodes to carry out tasks on behalf of users. In this way, mobile agent systems
constitute a middleware capable of supporting distributed and dynamic applications based on
mobile agents. The main advantage of mobile agents is that they can significantly save
bandwidth, by moving locally to the resources they need and by carrying the code to manage
them. Moreover, mobile agents can deal with non-continuous network connection, and as a
consequence they intrinsically suit mobile computing systems. With regard to mobility
research issues, two kinds of code mobility are to be outlined. The former one is called strong
mobility and requires that the code, the data state (i.e., the values of the internal variables) and
the execution state (i.e., the stack and the program counter) of the moving active entity are
transferred. The latter one is called weak mobility, and in this case only the code and the data
state are transferred.

The aim of this report is to analyze the Java support to mobility and compare the weak and the
strong mobility from two points of view, the system and the application level. In fact,
mobility requires the implementation of mechanisms to support execution stopping, state
collection, data serialization and transfer, data de-serialization and execution resuming; all
these kinds of facilities must be provided by the runtime system support. Moreover, our
analysis is driven by the application needs: we present different classes of applications that
can be designed using the mobile agent technology. The contribution of this report is to show
that a weak form of mobility is enough to cope with the needs of mobile agent applications,
while the strong mobility – more complex to achieve – affects negatively performances and
introduces security risks.

Strong and Weak Mobility

As described before in mobility definition, both Remote Evolution (RE) and Code on Demand
(COD) paradigms are based on the mobility of the code, but if we consider the mobility of
active entities, such as mobile agents (MA paradigm), we must take into account that they

3
have also a data state, composed of the values of their variables. Furthermore, if they are
executing, they have also an execution state, mainly composed of a stack and a program
counter. In general, the mobility of a complex entity occurs with the following steps.
1. The execution flow is stopped.
2. The state of the migrating entity is collected.
Intermediate format called bytecode, which can be executed on each platform that hosts a
JVM (Java Virtual Machine).
Strong Mobility: all components are migrated
Weak Mobility: discards execution state across migration

Why Mobility of Agents

Mobility can be defined with respect to the following properties.

1) Efficiency: Computation near data.
2) Security: Intellectual property, containment.
3) Reliability: Offline devices.
4) New types of interaction: Agent cooperation and coordination.

It must be kept in mind that agent is composed of 3things

1) Code
2) Data
3) Execution State

The following section will give a great detail of modeling of agent mobility.

4
 Modelling Agent Mobility with UML Sequence Diagram

Introduction

Agent concepts and mobile software agents have become a part of the system and service
architecture of the new generation networks. Application areas include the use of the agents in
operation and management of networks, systems and services. This is where agent's mobility
offers important advantages.

There are several kinds of diagrams for modelling agent mobility, but these diagrams can be
hardly used for representing moving and execution path. In this report we propose four
variants of a graphical notation for modelling agent mobility that is based on UML Sequence
Diagram: stereotyped mobility diagram, swimlaned mobility diagram, state representation
mobility diagram, and frame fragment mobility diagram. Our proposal is based on the
problem that moving path is hardly to read from existing notations agent. Three basic mobility
elements are modelled: agent creation, mobility path, and current location. In case study
we explain one variant of notation that is the most suitable for presented price searcher
scenario.

AUML supports modelling of agent mobility in Deployment and Activity Diagram. In AUML
Deployment Diagram it is possible to capture the reason (the why) an agent moves to a
different node and the location (where) it moves. In AUML Activity Diagram it is capable to
capture the when (timing) a mobile agent leaves a node to move to another. The activity nodes
model plan, while the transitions model events. The when, the mobile agent moves from node
to node is indicated as a note “when: condition” on the transition that leads to the end point
(Figure 1). (Starts execution in visiting NodeInstance)

5
UML is the standard graphical notation for modelling object-oriented software. Extensions of
UML activity diagrams for modelling agent mobility are presented here. We introduced in
UML the concepts of location, mobile object, mobile location, move action and clone action.
Two notations of mobility in Activity Diagrams are presented. The first notation is
responsibility centred and focuses on who is performing an action and is based on the
standard notation for activity diagrams. The second notation is location centred and focuses
on where an action is performed, and how activities change this relation (Figure 2).

Figure 2 -The move action in UML

In figure 3 we proposed an extension of Activity Diagrams in UML 2.0. A new stereotype

<<Host>> + parameter is introduced for a swimlane, which represents the location with a
unique name (address) as a parameter in order to capture mobility of agents. Agent
communication and cloning are also defined by existing model elements with a rule for sub
activities. Agent moving from location “host1” to “host2” is represented by using “Go”
activity (Figure 3).

6
 Figure 3 - “Go” action in UML 2.0

The notation for modelling agent mobility based on UML Sequence Diagram is used in figure
4. Sequence Diagrams for Mobility (SDM), an extension of UML Sequence Diagrams for
modelling mobile objects, interaction between objects and the network topology of nested
objects.

Agent Modelling Language (AML) defines metaclasses used to model structural and
behavioural aspects of entity mobility. Move is depicted as a UML Dependency relationship
with the stereotype <<move>> (Figure 4). Mobility Action is used to model mobility action of
entity and Move Action is used to model an action that results in a removal of the entity from
its current hosting location.

Figure 4 - Mobility in AML

3. Agent Mobility with Sequence Diagrams

During the modelling agent mobility using existing notations it is noticed that modelling
agent mobility with activity or deployment diagram does not give you the overall view about
agent moving and execution path. Our proposal is to show it using Sequence Diagram. There
are three basic mobility elements that must be shown in diagrams:

← • Current agent location,

← • Agent mobility path,

7
← • Location of agent creation.

In next section we introduce four variants of representing agent mobility in sequence diagram.

1. Stereotyped Mobility Diagram

In stereotyped mobility diagram we introduce three stereotypes (Figure 5). Agent is

represented with stereotype <<agent>>. At the beginning of the diagram, agent is located at
node n1 what is represented as a message with stereotype <<at>>. After that, agent moves
from this location to location at node n2, and that is represented with message and stereotype
<<move>>. When the agent creates a new agent, it is indirectly done by sending message to
node where the new agent should be created.

Figure 5 – Stereotyped Mobility Diagram

This representation of mobility is similar to figure 4. Mobility is based on representing the

change of the state of object that moves from one location to another. Agent moves by
sending stereotyped message to the node where it wants to go. This representation gives
overall view of nodes and agent mobility path. The downside of this notation is that for each
node there is an object that represents the node. In the case of large number of nodes, the
diagram is useless.

8
2. Swimlaned Mobility Diagram

In swimlaned mobility diagram (Figure 6) a node is represented by swimlaned with stereotype

<<node>>. Swimlaned represents execution at the specified node. An agent moved from one
node to another is represented by message with stereotype <<move>> but the lifeline of agent
at source is terminated and new representation at destination is created. Creating new agent is
represented by message new and agent is created at the same node. Indirect creation of agent
can not be represented in this diagram.

Figure 6 – Swimlaned Mobility Diagram

The diagram has clear representation of mobility and needs less space than stereotyped
diagram but in the case of large number of nodes it is also useless.

3. State Representation Mobility Diagram

Idea for this diagram is taken from figure 4 where the mobility is represented by changing the
state of the moving agent. In this diagram (Figure 7), mobility is represented with the state
element in sequence diagram as specified in UML 2.0 specification. State element starts with
“at node” and the rest is node name where agent is placed. When an agent moves from one
node to another, a new state represents mobility. Creating new agent is represented with new
message and after creation; agent must have state with specified node.

9
 Figure 7 – State Representation Mobility Diagram

This diagram is good solution for notation of agent moving and execution in the multi-agent
system with large number of nodes. The shortcoming is poorer representation of mobility.
This diagram consumes more space in vertical representation than the former. In the practice,
programming and debugging agents, for instance JADE agents, programmer is using Sniffer
agent to represent message exchanging in Sequence Diagram. This diagram is candidate for
implementing mobility in Sniffer agent because it is very similar to classic Sequence Diagram

3.4. Frame Fragment Mobility Diagram

Frame Fragment Mobility diagram represents mobility with frame fragments in sequence
diagram (Figure 8). Each frame fragment, with interaction operation node, represents
execution on that node. Agent mobility is represented by entering next fragment.

10
 Figure 8 –Frame Fragment Mobility Diagram

This diagrams it better than state representation mobility diagram because mobility is clearer
and occupied space is smaller. In some cases it is not possible to order agents in a way that
one frame fragment can represent agents at the same node.

Nice explanation by example: Price Searcher

The case study includes (Figure 9) three network nodes: Home, Host1 and Host2. On Host1
and Host2 resides store agent, which is responsible for providing pricelist. The Searcher agent
is created on Home node. Input parameters are list of nodes and the item. The Searcher agent
migrates from Home node to Host1 node and requests Store1 agent to give it the price list.
The Store1 agent responds with the whole pricelist. The Searcher extracts the price for the
item and migrates to the next node. After visiting all nodes the Searcher agent migrates back
to the Home node and informs the user where and at what price it has found the specified
item.
Price list Caffe 6€ Juice 10€

Price list Caffe 5€ Juice 12€

Figure 9 -Price searcher scenario

11
This case study is shown using Stereotyped Mobility Diagram (Figure 10). Stereotyped
Mobility Diagram is chosen because the system includes only mobile agents and small
number of nodes. This notation clearly represents agent execution and mobility path.

new get request

show results

Figure 10 – Stereotyped Mobility Diagram of Scenario

Next section is going to describe about agent mobility programming, but we are not
emphasizing mostly on it. Not a very detailed discussion will be presented here.

Mobility Support in JAVA Language

12
Mobility support in Java

The Java language is strongly network-oriented and provides some supports for the mobility
of code, from the dynamic class loading to the definition of applets. In addition, it permits to
implement a form of weak mobility, by serializing objects and sending them to another JVM
via sockets or Remote Method Invocation. The serialization mechanism permits to maintain
the values of the instance variables, but it cannot keep track of the execution flow. Several
weak mobility systems based on Java have been implemented both by academic researchers
and by enterprises. When the serialized object arrives at the destination JVM, it is de-
serialized (i.e.) it is restored) and it is reactivated by invoking a given method.
The choice of that method is defined by each mobile agent system: for example, it can be the
run method, or it can be specified by the agent as a parameter of the go statement. Java-based
mobile agent systems realize one agent by using one or more threads. The official JVM from
SUN does not support a strong kind of agent mobility. To implement it, in fact, the JVM code
should be modified in order to extract the Java stack and the program counter of the thread(s)
to be moved. In particular, they should be collected and sent along with the serialized form of
the agent. With regard to the program counter, it is an internal variable of the JVM that can be
easily accessed, transferred and restored at the destination node with a light modification to
the JVM. The main difficulty is related to the Java stack; in fact, the JVM accumulates the
operands of each microinstruction in the stack, whose elements are of a generic type stack
item. The stack disregards the real type of each element, which is determined by the
corresponding microinstruction when it is executed and pops the operands from the stack1.
Looking at the C code of the JVM, the type of the elements of the stack is defined as a union
of different possible types, as shown in Figure 11.

Figure 11. Definition of the stack item.

13
Since each microinstruction knows exactly which type of operand must use, the SUN JVM
works even if the real type of the stack elements is unknown. The problem rises when we
want to transfer the stack to another JVM. Since it is written in C language, it is not assured
that the same type has the same internal representation, in terms both of number of bytes and
of order of bytes (little or big endian). For example, if one element is an int, it is coded with 1
actually, the internal structures of the Java Virtual Machine are more complex, and we report
only some concepts useful to understand the involved problems. four bytes on a UNIX
platform; if the stack is transferred “as it is” to another platform where the int type is coded
with only two bytes (such as MS Windows on Intel), when such element is popped out from
the stack can be misinterpreted because of the different coding convention. Therefore, if we
want to safely transfer each element of the stack, it is necessary to build a “parallel stack” that
keeps track of the type of each element in the Java stack, as shown in Figure 12. Such parallel
stack is interleaved with the normal stack, and is used to determine the type of each element
so that it can be correctly translated into the right representation at the destination node.
Whenever an element is inserted in the stack, the JVM must insert also a “tag” which records
the type of the element; when an element is popped from the stack, the JVM must extract also
the tag; tags are used to pack the stack when a movement is required. This introduces a
notable overhead that influences the overall performance.

Figure 12.The parallel stack to keep track of element types

Moreover, when the movement occurs during a nested method invocation, all the Java stacks
related to the previous-invoked methods are to be collected, significantly increasing the
complexity of the movement. The developers of MESSENGER (a Java-like interpreted

14
language) recognize the difficulties implied in the extracting and restoring the computational
state (in particular, the call stack) when the movement statement can occur anywhere in the
code. They propose an intermediate approach between a strong and a weak mobility. They
restrict the points in the execution at which to perform a movement; in fact, a movement
statement can occur only in the execution top level, i.e. the equivalent of the main program. In
this way, they overcome the hurdle of extracting the stack. Another interesting hybrid
approach based on a Java preprocessor is reported here briefly. Such preprocessor is used to
transform the Java source code of a program that would require the strong mobility in a Java
source code that, instead, relies on weak mobility mechanisms. This is done by inserting
checkpoint-like instructions in several points of the execution, which emulate the execution
state saving. The main advantage of this solution is that programmers can build their
programs based on strong mobility and they can be executed on standard Java, achieving
portability. However, portability is limited by the fact that the source code must be
preprocessed, and already-compiled code cannot be used. The preprocessor approach leads to
an increase of the code of about 4 times, while it implies a 20% of overhead with regard to the
execution time.

Mobility Issues

From the application agent point of view, mobility is achieved by invoking a given method,
usually called goes, specifying somehow the destination node. Figure 13 shows two fragments
of the Java code of an agent2. The former one relies on weak mobility: the invocation of the
method go causes the agent to be sent to the node NewNode and there the execution restarts
from the method NewMethod specified as a parameter of the method go. The latter code
assumes a strong mobility system; also in this case the invocation of the method go causes the
agent to be sent to the node NewNode but the execution is restarted from the first instruction
after the method go itself.

15
Figure 13 Fragments of the code of an agent using a) Weak and b) Strong mobility

The example of Figure 13 outlines the different programming style of the two approaches.
Even if the first one seems to be more complex, we argue that it leads to a cleaner
programming, as better explained in the following of this Section. Moreover, this simple
example shows that a mobile-agent application must be designed depending on the underlying
support.

Figure 14 The typical work cycle of data oriented mobile

In general, the applications based on mobile agents exploit the mobility to search for
interesting resources. Such resources can be data, computation and people. Currently, the
most applications exploit mobile agents to deal with remote information, to avoid transferring
of a large amount of data over the network. Therefore, the agent tasks on remote nodes are
often repetitive, because the change of execution environment permits to perform the same

16
action on different data. Figure 14 shows a typical work-cycle of a mobile agent that roams to
deal with different data; the grey box represents the job executed by the agent on each site it
visits. In this case, the agent does not need to resume the execution exactly where it stops
before moving; on the contrary, it is useful that it restarts the job, as happens in the weak
mobility case. It is important that the results of each node are accumulated in state variables
that are moved along with the agent.

Figure15. Implementation of repetitive job using strong mobility

In the former case, the programmer must define a method ExecuteOnArrival in that will be
invoked as soon as the agent arrives at a node, just after the creation of the Java object that
implements the mobile agents. Such method contains the instructions of the repetitive job and
then the go method that permits the movement of the agent. As can be seen, the travel is
organized in a recursive fashion, since the ExecuteOnArrival method calls itself via the go
one. In the latter case, all the code can be embedded in a while cycle of the main method.
Differently from the previous approach, this solution follows an iterative fashion, since the
travel is caused by the while cycle.
The comparison of the two fragments of code points out that the implementation using the
weak mobility is quite similar to the one using the strong mobility. The main difference relies
on the structure of the code: in the former case the job must be coded in a separate method,

17
while in the latter case it can be coded in the main flow of instructions. At a first glance it
could seem a further programming effort and a more complex code, but from the point of
view of the clean programming style, it contributes to separate different pieces of code,
resulting in a more clear and understandable program. Moreover, if an agent is programmed
to clone itself –for example to follow several links – the recursion style of the weak mobility
fits better the scenario, since well defined methods can be assigned to every new generated
agent, without the need of complex “if/switch” statements (as it happens, for example, in
UNIX concurrent programming with fork). As a final note, we mention that an important
issue related to mobility concerns the loading of the Java classes. Usually, when an object is
instantiated, a system entity called ClassLoader is in charge of retrieving the needed classes.
In an open world, this task can be hard because the classes are likely to be retrieved from
remote sites. Moreover, when agents have to exchange information using common classes
different from the basic ones, the right ClassLoader must be chosen in order to avoid casting
or interpretation problems.

Application area where mobility mostly required

1) Information Retrieval
2) E-Commerce
3) Network Management
4) Load Balancing

We would like to put an end note while explaining the application area i.e Electronics
Commerce with a brief explanation.

E Commerce

One of the most attractive applications of the mobile agent technology is electronic
commerce. In fact, mobile agents well suit to model buyers and sellers that roam through a
network to carry out exchanges of goods, services and money. In this scenario, network nodes
can model virtual marketplaces – where interaction between buyers and sellers can occur – or
virtual shops, with fixed seller agents. A buyer agent can travel from site to site to act in
behalf of a user that wants to buy goods (see Figure 16). The “intelligence” of the agent can
be exploited in different ways. For example, the agent can visit different sites that offer the

18
same service, recording each price to make a comparison and to choose the cheapest one;
another example is when the task of an agent can be composed of different services that must
be coordinated.

Figure 16: A mobile buyer agent visits the virtual shops on the net.

Also in the case of e-commerce, the jobs are the same on each site (evaluation of goods and
prices, contract activity, and so on). The main difference with the previous case is that the
collected information is used to take decisions on different sites. However, the weak mobility
is enough to grant that the results of each site are available during the whole life of agents.

19