Agent Mobility Application

8/14/2019 Agent Mobility Application

1/19

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

Hgskolen I Bergen

[email protected]

1


2/19

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 agentis 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


3/19

applications. On the other hand, the Internetproposes 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 calledstrong

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 weakmobility, 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


4/19

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


5/19

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


6/19

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

+ 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


7/19

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 (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


8/19

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 . At the beginning of the diagram, agent is located at

node n1 what is represented as a message with stereotype . After that, agent moves

from this location to location at node n2, and that is represented with message and stereotype

. 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


9/19

2. Swimlaned Mobility Diagram

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

. Swimlaned represents execution at the specified node. An agent moved from one

node to another is represented by message with stereotype 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


10/19

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


11/19

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


12/19

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


13/19

Mobility support in Java

The Java language is strongly network-oriented and provides some supports for the mobility

of code, from the dynamic class loadingto the definition ofapplets. In addition, it permits to

implement a form ofweakmobility, 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 astrongkind of agent mobility. To implement it, in fact, the JVM code

should be modified in order to extract theJava stackand theprogram counterof the thread(s)

to be moved. In particular, they should be collected and sent alongwith the serialized form of

the agent. With regard to the program counter, it is an internalvariable of the JVM that can be

easily accessed, transferred and restored at the destinationnode with a light modification to

the JVM. The main difficulty is related to the Java stack; infact, 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


14/19

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 inttype 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


15/19

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


16/19

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


17/19

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


18/19

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


19/19

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.

Documents

Agent Mobility Application