Fuyuki Ishikawa
Graduate School of Information Science and Technology, The University of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo 113-8654, Japan
Nobukazu Yoshioka, Yasuyuki Tahara, and Shinichi Honiden
National Institute of Informatics
2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan
Hierarchical mobile agent, Agent system, Agreement, Service oriented architecture, Multimedia application.
Hierarchical mobile agent model is an emerging extension to traditional agent models, where an agent can
migrate into another agent and establish a strong partnership. The entering agent and accepting agent are
called as a child and its parent, respectively. This model enables agents to establish the strong (parent-child)
partnership and cooperate with each other while maintaining the partnership stable for a long term. This
work discusses requirements for frameworks that support development of HMA applications, and describes
the basic direction of our proposed HMA framework named MAFEH. MAFEH includes two features: (1)
Parent-Child Agreement that specifies an agreement regarding behaviors of a parent and its child, and (2)
Interaction Behaviors Description that is used to specify typical synthesis actions separated from the main
application logic. Supporting these features, MAFEH aims to facilitate development of an agent system where
each agent can obtain required functions on demand by means of synthesis as well as remote interaction. This
work considers multimedia application as a motivating scenario, where an agent encapsulates a multimedia
content and establishes synthesis with various agents encapsulating other contents or additional services.
Agent technologies have attracted widespread atten-
tion, orienting towards adding more autonomy and
flexibility to software components, especially distrib-
uted conpoments interacting and cooperating with
each other (Bradshaw, 1997). Mobility of agents has
also been investigated, i.e. the ability to migrate from
one host to another on its own decision. Mobility has
been considered as a powerful way to facilitate flexi-
ble, on demand deployment of agents adapting to the
surrounding environments e.g. heterogeneity of com-
puting/network resources and movement of users in
pervasive computing.
Hierarchical Mobile Agent (HMA) model is an
emerging extension to traditional agent models,
where an agent can migrate into another agent (Suna
and Fallah-Seghrouchni, 2004; Satoh, 2000; Tahara
et al., 2003)
An agent can enter into another agent or
to take one in that provides additional services, and
form an agent compound. In this paper, we call the
Currently, there is no widely-accepted name for the
model. We follow (Satoh, 2000) for the name HMA. We
follow (Satoh, 2000) for the use of kinship terms, too.
entering agent and accepting agent as a child and its
parent, respectively, and use such kinship terms. As
the most notable point in the HMA model, when an
agent migrates into an agent or a host, it takes all
its descendants along. The HMA model thus enables
agents to establish a strong partnership as an agent
The HMA model enables function-migration as
well as data-migration as the mobile agent model
does. It thus can be used for adaptation to limitation
in computing/network resources in mobile computing
or in multimedia processing. The HMA model ex-
tends the mobile agent model in a sense agents can
maintain their partnership stable for a long term, even
if the agents migrate around.
In addition, the HMA model can be considered as
one way to implement Service-Oriented Architecture
(SOA) (Haas, 2004). In SOA, software systems pro-
vide services to other applications through published
and discoverable interfaces, and the services can be
invoked over a network. The HMA model also con-
siders dynamic discovery and coodination of services
provided by agents. Moreover, it additonally enables
agents to establish stronger partnership by keeping
being together with service instances as an agent, if
Ishikawa F., Yoshioka N., Tahara Y. and Honiden S. (2005).
In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 275-282
DOI: 10.5220/0002529102750282
preferred, not for one-shot invocation but for long-
lasting interaction.
Encapsulation of multimedia contents by agents
has been considered as an attractive application of the
HMA model. Agents encapsulate multimedia con-
tents, form a hierarchy corresponding to the hierar-
chy of the contents, and achieve presentation, deliv-
ery, and composition suitable for the user’s situation
while obeying policies given by their creators and dis-
tributors (Satoh, 2001; Tahara et al., 2003).
Although there seem to be considerable advantages
of the HMA model, little effort have been conducted
on it. Our objective is to provide a framework that
supports development of attractive HMA applications
by addressing its unique issues.
The existing HMA frameworks provide only prim-
itive functions for agents to enter into/exit out of
another agent and to exchange messages (Suna and
Fallah-Seghrouchni, 2004; Satoh, 2000). These
functions are derived by directly adopting the mo-
bile agent model and extending typical mobile agent
frameworks. Although this enables developers to
achieve various behaviors by combining the func-
tions, it leads to complicated codes of low-level func-
tions, where various kinds of behaviors, e.g. discov-
ery and migration, are weaved into the application
logic, resulting in difficulty in development and main-
tenance. In additon, it has not been discussed what
behaviors are typical and should be easy to achieve in
the HMA model, not in the mobile agent model. It
has not been discussed, too, how to support develop-
ers to achieve consistent and cooperative behaviors of
agents to form an agent compound and work together.
This paper discusses two additional requirements
for HMA frameworks: (1) easy control of typical flow
upon interaction with a partner agent, i.e. discovery
and migration (if preferred), and seperation of it from
the main application logic, and (2) support for con-
trols/restrictions over a child’s behaviors by its parent.
This paper also describes our approach to these re-
quirements and introduces two concepts: Interaction
Behavior Description (IBD) and Parent-Child Agree-
ment (PCA) in response to (1) and (2), respectively.
IBD is used by developers to control typical flow
mentioned above by setting parameters. IBD is added
to the application logic, which specifies how to inter-
act with partners dynamically bound in runtime but
does not specify concrete information of them.
PCA denotes an agreement between a child and its
parent for strong controls/restrictions over a child by
its parent, such as encapsulation of the child or con-
finement of the child. Before synthesis, the agents
establish a PCA and then behave according to it until
dissolution of the synthesis. In this work as the first
step, we focus on an easily-built agreement concern-
ing on controls/restrictions of domain-independent
primitive actions supported by frameworks, such as
1. Migration
2. Interaction
3. Migration
4. Interaction
Figure 1: Hierarchical Mobile Agent Model
communication and migration.
This paper is a progress report of our challenge
and describes the basic direction of our ongoing work
on the HMA framework named MAFEH
, which
includes IBD and PCA as its main features. Our
work aims to facilitate development of an agent sys-
tem where agents can request for additional func-
tions on demand and work cooperatively, by synthe-
sis as well as remote interaction. As a motivating
scenario, our work considers multimedia application
where an agent encapsulates a multimedia content
and forms synthesis with various agents encapsulat-
ing other contents or services.
In the remainder of this paper, we first introduce
the HMA model and discuss requirements for HMA
frameworks with the motivating example scenario in
Section 2 and 3. We then describe the basic direction
of the proposed framework in Section 4. Finally we
give some discussion in Section 5 before concluding
remarks in Section 6.
This section introduces the Hierarchical Mobile
Agent (HMA) model.
2.1 Basic Concepts
Figure 1 illustrates the HMA model (Suna and Fallah-
Seghrouchni, 2004; Satoh, 2000; Tahara et al., 2003),
where an agent can migrate into another. The migrat-
ing agent and the accepting agent are called a child
and its parent, respectively. An agent can have only
one parent and any number of children, forming a
tree structure. When an agent migrates into an agent
or a host, it takes all its children along (migration of
agent1 in Fig. 1). The HMA model enables agents to
establilsh a strong partnership and work cooperatively
for a long term forming an agent compound.
We claim inter-agent migration should be divided
conceptually into two phases: inter-host migration
Mobile Agent Framework with Enhanced Hierarchy.
where one agent migrates to the same host of the
other, and the action where they establish a parent-
child relationship. This work refers to the latter as
synthesis and focuses on it.
2.2 Existing Works
SyMPA (Suna and Fallah-Seghrouchni, 2004) is
an HMA platform inspired by Ambient Calculus
(Cardelli and Gordon, 1998), a calculus for concur-
rent process forming hierarchy. SyMPA supports ba-
sic functions from the calculus for inter-agent migra-
tion. However, SyMPA has not focused on how to
make use of the HMA model.
MobileSpaces (Satoh, 2000) is a framework that
provides basic functions for the HMA model. Multi-
media applications on MobileSpaces have been pro-
posed (Satoh, 2001). Agents encapsuate multime-
dia objects and form a hierarchy, which corresponds
to the hierarchy of the multimedia objects, e.g. im-
ages included and managed by a word processor doc-
ument. The agents provide to users, customized func-
tions to operate multimedia objects (play, edit, etc.).
In addition, required services can be added at runtime
as child agents, e.g. streaming functions.
Active Contents project (Tahara et al., 2003) also
proposes encapsulation of multimedia contents in the
HMA model. It additionally considers agents that
contain multiple content agents and (1) integrate them
to provide a united content or (2) provide flexible
delivery functionality by means of migration. This
model has been formalized using Ambient Calculus,
however, implementation issues have not been ad-
Note that for synthesis control, the existing frame-
works (SyMPA, MobileSpaces) provide functions
only to enter into/exit out of another agent (either on
the same host or on a different host), as an extension
to inter-host migration.
In this section, we first describe the motivating exam-
ple application. We then discuss additional require-
ments for HMA frameworks.
3.1 Example Application
In Section 2.2, we have mentioned some multimedia
applications of the HMA model. Agents encapsulat-
ing multimedia contents and related services in the
HMA model are attractive for the following reasons.
Multimedia data cannot be organized like text data.
There exist many formats and functions for each for-
mat such as playing, editing, and translating formats.
There also exist specialized functions to extract use-
ful metadata or provide users customized view. The
HMA model enables adoption of functions on de-
mand, without preparing all in advance. Since mul-
timedia data is typically large in size, it is inadequate
to send data to remote servers with rich functions.
The HMA model enables function migration as well
as data migration. Moreover, multimedia data have a
hierarchy, e.g. an image in a word-processor docu-
ment. Presentation of children is controled by their
parent and whole contents are delivered as a unit.
This is equivalent to the HMA model and the model
adds the abilities to move or establish partnerships au-
tonomously. We believe agent technology will help
address issues in content synthesis, such as confliction
of licenses or presentation policies, as well as system-
atic issues tackled in this work.
As the motivating example scenario, this work
also considers an agent encapsulating a video content
(VCA: Video Content Agent). The VCA is given pre-
sentation, composition, and delivery policies by cre-
ators, editors, and distributors of the contents, repec-
tively. It provides the contents in a way compliant
with the policies. For example, it can control how
many times the user can move the contents as well as
until when the user can play. It can also increase such
licenses after the user answers a questionnaire. Such
control can be achieved without connecting a central
management server, without the need for such func-
tions to be installed in advance. In addition, it can
provide value-added services such as customization
of contents presentation, merge of related information
collected from the Web, and creation / edit manage-
ment by migrating among hosts of software services
or human professionals.
Our concern here is not issues in handling multi-
media contents but control of agent synthesis. Figure
2 shows an overview of the VCA lifecycle where it
interacts with four types of agents.
Advertiement Agent Upon instantiation of the
VCA, it takes in an agent as a child that encapsu-
lates advertisements. The VCA then presents the
advertisements integrated to its own video content.
User Agent The VCA migrates to the user host and
starts interaction with an agent that represents the
Mobile Streaming Agent The VCA provides mo-
bile streaming, i.e. tracking the user and provid-
ing streaming at a host nearby the mobile user. To
achieve this, the VCA enters into an agent that pro-
vides migration and streaming ability.
Privacy Agent To provide presentation customized
for the user, the VCA enters into an agent that im-
poses strong restriction on its behaviors, e.g. out-
bound communication, in return for the user’s in-
Loop for
service provision
Partner3 (entered into as a parent):
an agent provides user -tracking migration
and streaming functions
Partner2 (approached for local interaction):
an agent representing the user
Loop for
Service Provision
Customized mode
Partner4 (entered into as a parent):
an agent providing user information
Partner1 (taken in as a child):
an agent encapsulating advertisements
Customized presentation of the contents
Usual presentation of the contents
or Mobile streaming presentation
Figure 2: Agent Encapsulating Video Content
3.2 Requirements for HMA
For the unique issue in the HMA model, i.e. synthe-
sis, the existing frameworks (SyMPA, MobileSpaces)
provide functions to enter into/exit out of another
agent (either on the same host or on a different host),
as an extension to inter-host migration. Synthesis
control functions can be classified into two types: (1)
building or dissolving a parent-child relationship and
(2) cooperation of between a child and its parent while
the relationship is being maintained.
3.2.1 Synthesis Control
For (1), the existing frameworks (Suna and Fallah-
Seghrouchni, 2004; Satoh, 2000) only provide prim-
itive functions to enter into/exit out of another agent.
This fact causes the following two issues. First, it
means that the frameworks would require a heavy task
of coding, for each partner agent, regarding discov-
ery of a partner instance that can play the required
role, migration and synthesis if required, and dissolu-
tion of the synthesis. However, this flow is considered
rather typical since the HMA model essentially con-
siders on-demand partnerships. Second, in the HMA
model, a parent can not only be a host but can also be
an agent. It is quite natural that a synthesis is activated
by a parent to obtain additional functions as a child
(e.g. the advertisement agent in Section 3.1). It is also
possible that a parent would migrate to the host of a
child, forms a synthesis and provides services (e.g.
the mobile streaming agent in Section 3.1). These be-
haviors have not been facilitated by the frameworks
since developers would have to combine the entering
action and communication to request the action.
3.2.2 Cooperation of Child and Parent
For (2), consistent behaviors of a child and its par-
ent have not been considered in the existing frame-
works. In the frameworks, a child can exit out of its
parent on its own discretion. This may cause termina-
tion of interaction and then unexpected errors to oc-
cur in the parent’s behaviors. One idea is to intro-
duce controls and restrictions over children’s actions
by the parent. It seems like a natural metaphor that
a parent would own and control its children (compo-
nents). Actually, in the MobileSpaces framework, a
parent can kill its child or remove it out (Satoh, 2000).
However, such control by a parent may in turn cause
error in its child’s behaviors. Some mechanism is thus
required to ensure duration of a partnership. In addi-
tion, it has not been discussed whether other types of
controls or restrictions over a child by its parent are
useful or not.
Below we list types of controls/restrictions consid-
ered useful with respect to each purpose. In this work
we limit our discussion to primitive functions typi-
cally managed by frameworks, namely, lifecycle man-
agement, communication, and migration/synthesis.
Duration of Partnership. In the existing work, a
child can migrate out of its parent on its own discre-
tion. On the other hand, in MobileSpaces a parent
can kill its child or move it away. These actions may
cause interruption of interaction that is unexpected by
the partner. It should be assured the partnership is
maintained for a certain duration.
Service Provision Parents may want their chil-
dren to interact with the outside in special manners,
namely, (1) a black box model and/or (2) encapsula-
tion (the advertisement agent in Section 3.1). (1) A
parent makes its child invisible from outside to hide
its internal business logic. In this case, all required
communication of the child would be conducted in
the parent’s name, and forwarded by the parent as ap-
propriate. (2) A parent encapsulates its child so that
the child’s services are not available from the outside,
directly or via the parent, and restricted usages are
achieved by the parent.
Confinement In MobileSpaces, a parent can kill
its child. One usage of this function is to “confine” a
child so that it cannot leak some information such as
the internal business logic or user privacy information
(the privacy agent in Section 3.1). This also requires
restriction on outbound communication of the child.
The extent of these controls/restrictions should be
decided for each agent pair. In Section 3.1, the mobile
streaming agent merely provides carrier functions and
imposes no restriction on the video agent while the
video agent wants to encapsulate the advertisement
agent and control its functions. The above patterns re-
quire a mechanism to make agents agreed before syn-
thesis and then work cooperatively according to the
Sub -Workflow
public void run()
of Atomic Action
Acceptable PCA Condition
Partner Scope
Partner Agents
Agent Description
Acceptable PCA Condition
Figure 3: MAFEH Agent Description Model
agreement, since they may have conflicting desires on
the extent of the controls/restrictions.
This section describes the basic direction of our on-
going work on the MAFEH framework.
4.1 Overview
Considering the requirements discussed in Section
3.2, we are developing an HMA framework named
MAFEH including two features: Interaction Behav-
ior Description (IBD) and Parent-Child Agreement
(PCA). Figure 3 and 4 illustrate the agent descrip-
tion model and the architecture of MAFEH, respec-
tively. Although the concepts of PCA and IPA do not
essentially depend on enviroments, our current work
assumes all agents are registered and can be discov-
ered in global directory services.
The main application logic is described as a work-
flow, which connects sub-workflows and atomic ac-
tions. An atomic action is a unit of execution (com-
putation or interaction with other agents) and imple-
mented in Java. This logic specifies how to interact
with abstract partners without concrete information of
them. We assume developers know the type of each
partner and interaction protocols for communicating
with them.
IBD is then used by agent developers to de-
scribe concrete information and detailed action pa-
rameters related to each abstract partner declared in
the workflow description, for discovery and migra-
PCA denotes an agreement on the extent of con-
trols/restrictions over a child by its parent. Devel-
opers give each agent acceptable PCA conditions.
They denote the conditions about the extent of con-
trols/restrictions under which the agent can achieve its
expected behavior. An agent has accetable PCA con-
Workflow + IBD
for Atomic Actions
PCA Checker
Infrastructure for Primitive Functions
Relation and PCA Management
Application Level Communication (FIPA ACL)
Directory Access
Inter-host Migration
Other Places
Directory Services
with PCA Matching Facility
Figure 4: MAFEH Architecture
ditions for each partner that it asks to provide services
(in case the agent is an initiator of interaction), and
for a partner that asks it to provide services (in case
the agent is a responder). When an agent activates
synthesis, it discovers a partner with which it can es-
tablish a PCA using simple matching rules. Man-
agement of parent-child relationships are conducted
by MAFEH. The relationships are managed as logical
links between agents. Calls for primitive functions are
hooked and changed or denied according to formed
PCAs. The framework is responsible to realize and
assure compliance with formed PCAs. Infraction by
not using IBD or provided APIs is prevented by using
SecurityManager in Java.
4.2 Main Application Logic
The main application logic is described as a combi-
nation of (1) implementation of each atomic action in
Java and (2) a global workflow that connects activ-
ities (atomic actions and sub-workflows). A work-
flow consists of activities and the control/data flow
among them. An activity is either a sub-workflow or
an atomic action. MAFEH provides APIs for imple-
mentation of atomic actions, such as APIs for get-
ting workflow-level inputs and setting outputs, and
sending/receiving messages of FIPA ACL (AGENTS,
1997). For description of control/data flow, we
followed Web Services Flow Language (Leymann,
2001) and extended its notation and semantics with
the concept of exception handling. The control/data
flow is expressed by connecting activities with con-
trol links and data links. Loop execution is expressed
with an exit condition of an activity (until loop).
This two-layer descriptions of the main logic is in-
tended to keep control of migration and synthesis as
abstract as possible by handling it at the workflow
level. Inter-host migration is not activated during exe-
cution of atomic actions but in the interval, according
to IBD (described later in Section 4.4). Upon migra-
tion all activity states and variable values at the work-
flow level are preserved, and then rebuilt after migra-
tion completion. When a parent initiates migration,
the migration is delayed until all the children finish
their current atomic actions and preserve their states.
Partner Scope Declaration
of Atomic Action
Internal Name of the Partner in the Main Logic:
public void run() {
AID aid = getAID(“AdAgent");
Discovery and Selection
Agent ID (Reference)
Bound in Runtime
Figure 5: Partner Scope
The main application logic can be specified with-
out concrete information of interaction partners. Fig-
ure 5 illustrates how each partner is bound. Names
of the involved partners are declared and then can be
used in the implementation of atomic actions. At the
global workflow level, the partner scope of each part-
ner is defined and then used to decide when to initiate
synthesis or dissolve it. Concrete information of the
declared partners and detailed parameters for migra-
tion/synthesis (if preferred) are given in Interaction
Behavior Descriptions (IBD) described later in Sec-
ton 4.4.
4.3 Parent-Child Agreement
PCA specifies an agreement on the extent of con-
trols/restrictions over the child by the parent. As
mentioned in Section 3.2.2, this work handles con-
trols/restrictions related to term of the partnership,
black box/encapsulation, and confinement.
The extent of each control or restriction is spec-
ified as a value of a predefined parameter in PCA.
Each agent is given, by its developers, acceptable
PCA conditions for each partner that it requests (for
the case where the agent is the initiator of inter-
action) and for the partner that requests it to pro-
vide services (for the case where the agent is the re-
sponder). When an agent requests for synthesis, the
MAFEH framework matches conditions of two agents
(the initiator and responder) and forms a PCA. This
work adopts simple matching rules that derive the
least controls/estrictions compliant with the accept-
able conditions. After forming synthesis, the frame-
work achieves the controls and denies actions against
the restrictions in the PCA, causing an exception to be
thrown (both at the workflow and atomic action lev-
Figure 6 shows an example of acceptable PCA
conditons of two agents and the PCA established
by mathching them. The parameters are defined
to achieve controls/restrictions described in Section
3.2.2. Suppose the parent is the video agent and the
child is the advertisement agent in Section 3.1. In
the parent conditions, the parent wants black model
(requireBlackBox) and encapsulation of the adver-
partnerName: careerAgent{
role: MobileStreaming/career
onDemand: yes
interactionType: parent
approach: come
(Other detailed parameters
such as for exception handling)
Figure 7: IBD
tisement provision functionality (deniedInboundMes-
sages and deniedOutboundMessages). It does not
want to kill the child after the partnership expires
(for confinement) (requireKillResolve). On the other
hand, in the child conditions, the child wants to inter-
act with its master servers for update (subscribedIn-
boundMessages and allowedOutboundMessages). It
also wants a guarantee for term of the partnership
(expireDateLaterThan). As requirements of the two
agents are not inconsistent, matching succeeds, lead-
ing to the PCA with the least controls/restrictions
compliant with both of the requirements.
4.4 Interaction Behavior Description
The main application logic specifies how to interact
with abstract partners as mentioned in Section 4.2.
IBD gives concrete information of the partners and
detailed parameters for discovery, migration, and syn-
thesis. Figure 7 shows IBD of the video agent for the
mobile streaming agent in Section 3.1. Below, we de-
scribe how migration and synthesis actions are con-
ducted upon interaction according to IBD.
When to initiate interaction with the partner is
specified in onDemand in IBD. If the item is set to yes,
the partner is discovered on demand, that is, when the
interpreter of the workflow first encounters an activ-
ity that belongs to the partner’s scope. If the item is
set to no, the partner is discovered when the agent is
instantiated, before execution of the main logic.
Agents are discovered from directory services that
can play the role in the protocol specified in role.
When a PCA can be established with an agent in the
query result, the agent becomes the partner.
After the partner is decided, migration and/or syn-
thesis is activated if necessary. The interaction type
is specified in interactionType; (1) parent: interaction
after entering into the partner, (2) child: interaction
after taking the partner in, and (3) parallel: inter-
action without synthesis. In addition, the method of
approaching the partner is specified in approach: its
value can be (a) go: migrating to the partner’s host,
and (b) come: asking the partner to send a new in-
stance of the partner to the agent’s host, and (c) re-
mote: interaction by remote messaging without mi-
gration only in the case of parallel interaction.
In the case of synthesis, dissolution of the synthe-
Parent Conditions Child Conditions Formed Agreement
expiredDateLaterThan: expiredDate:
2004-11-12 00:00:00 JST 2004-11-12 00:00:00 JST
requireBlackBox: yes
acceptBlackBox: yes blackBox: yes
subscribedInboundMessages: subscribedInboundMessages:
(protocol=="adUpdate") (protocol=="adUpdate")
allowedOutboundMessages: deniedOutboundMessages:
(protocol=="ad") (protocol=="playAd")
requireKillDissolve: no
acceptKillDissolve: yes killDissolve: no
Figure 6: Acceptable PCA Conditions and Formed PCA
sis is initiated according to the partner scope. Ba-
sically, when all the activities in the partner scope
have been evaluated (including “skipped” in condi-
tional branch), the synthesis is dissolved. In the case
where a partner scope is involved in a loop, it is not
clear whether it will be a loop targeting the same part-
ner instance or a loop switches partner instances. It
seems typical that an interaction with a partner is de-
scribed as a loop and then that loop is involved in an-
other loop in which partner instances are switched. In
declaration of partner scopes, developers can specify
the activity where partner instances are switched.
All the above actions are executed just before or af-
ter execution of an activity, according to partner scope
declarations and IBDs. Exceptions in these actions
are thrown and can be caught at the workflow level.
4.5 Adoption to Example
Below, we describe how IBD and PCA can be used
for the example in Section 3.1.
Advertisement Agent The VCA takes in the
advertisement agent (interactionType:child, ap-
proach:come in IBD). PCA for this agent pair was
described in the example in Section 4.3.
User Agent VCA interacts with an agent that repre-
senting the user. When initialized, it migrates to
interact with it locally without synthesis (interac-
tionType:parallel, approach:go in IBD).
Mobile Streaming Agent VCA calls and enters a
mobile streaming agent according to the user’s
request (interactionType:parent,approach:come in
IBD). This time in PCA, the black box model is not
adopted and the function for regular presentation
can also be called from the outside. As the agent
provides migration strategy based on knowledge of
the current environment and supports a streaming
protocol supported by the user’s device, this agent
is switched every time requested (onDemand: yes
in IBD).
Privacy Agent The VCA enters into the privacy
agent that imposes strong restrictions in re-
turn for the user’s information (interaction-
Type:parent,approach:go in IBD). According to
the user’s policy, the agent inhibits communication
with the outside and migration out of it (deniedOut-
boundMessages: (true), isEscapable:no in PCA).
This way, various patterns for agent pairs can be
achieved on the framework, MAFEH, especially the
interaction patterns in IBD and the control/restriction
patterns in PCA.
We have briefly described the basic concepts of the
MAFEH framework, especially IBD and PCA. In this
section, we discuss advantages of our approach to
IBD and PCA, though MAFEH is currently under
development and requires evaluation by constructing
real applications. We also discuss further require-
ments on IBD and PCA.
5.1 IBD
We mentioned needs for facilitation of the typical
flow: discovery, synthesis, and dissolution, in Sec-
tion 3.2.1. In MAFEH, developers explicitly declare
partner scopes so that the framework can manage the
flow eliminating the need for developers to insert each
action appropriately. IBD also facilitates the patterns
mentioned in Section 3.2.1, synthesis activation and
inter-agent migration (interactionType and approach).
In the existing frameworks, these patterns have not
been facilitated as they require combining communi-
cation for requests and the primitive function to enter
into an agent.
In addition, as details of interaction partners are
separated from application logic, it is easier for de-
velopers to change them, e.g. to change from synthe-
sis to parallel interaction or to change parameters in
the query for discovery. If such details are not sepa-
rated from application logic, it is difficult to find and
modify actions scattered and enweaved within the ap-
plication logic. However, as this approach of IBD
limits description capability, further evaluation is re-
quired by constructing various agents such as those
mentioned in 3.1.
IBD takes a similar approach to the one in co-
ordination languages in the Web Services activity
for on-demand discovery and coodination of distrib-
uted services, e.g. WSFL (Leymann, 2001) and
BPEL4WS ((editor) et al., 2003). However, they have
not considered strong partnerships as in the HMA
model for long-lasting interaction. On the other hand,
there have been many languages for controling mo-
bile agents by associating migration with actions (ita,
2001; Ishikawa et al., pear). However, no language
has appeared for the HMA model.
It is necessary to extend the current work to facil-
itate decision of acceptance of agent synthesis based
on nonfunctional parameters such as trust and security
policies. We are thinking of introducing some pol-
icy descriptions similar to acceptable PCA conditions,
which allow the framework to support an agent’s de-
cision to accept an offer of synthesis.
5.2 PCA
In 3.2.2, we described basic types of agent cooper-
ation in the HMA model: assurance of partnership
durations, the black box model and encapsulation,
and confinement for information secrecy. MAFEH
allows an agent to change the extent of such con-
trols/restrictions for each of its partners, obeying the
minimum requirements imposed by its developer.
The framework supports realization of controls and
compliance with restrictions in PCA. If they are dele-
gated to each agent, each developer is obligated to im-
plement cooperative behaviors correctly. For exam-
ple, the black box model requires developers to code
appropriately so that a child sends all messages to its
parent and the parent forwards inbound and outbound
messages correctly. However, it is a heavy burden to
code such detailed actions obeying each PCA decided
at runtime. It is also very difficult to assure that each
agent behaves correctly according to the PCA.
Acceptable PCA conditions are given by develop-
ers. Tool support is necessary such as verification of
the conditions or (semi-)automatic extraction of them
by analysing the main logic. In addition, it should be
possible to develop an agent that handles its condi-
tions by itself. For example, the video agent should
decide by itself to accept strict conditions of the pri-
vacy agent only in return for privacy information, and
change its behaviors adapting to the established PCA.
This paper has described the basic direction of our
work on the MAFEH framework for hierarchical mo-
bile agents. MAFEH includes two features: PCA
for an agreement regarding behaviors of a parent and
its child, and IBD for description of synthesis ac-
tions separated from the main application logic. Al-
though our work is still at an early stage, we believe
we can mature MAFEH for development of agents
that autonomously establish synthesis at runtime, by
incrementally focusing on and refining each part of
(2001). Mobile agents itinerary language project.
˜azaslavs/itag/. (Access: 10 June 2004).
AGENTS, F. F. I. P. (1997). Agent communica-
tion language.
Bradshaw, J. M. (1997). An Introduction to Software
Agents. MIT Press.
Cardelli, L. and Gordon, A. D. (1998). Mobile ambients.
In Foundations of Software Science and Computation
Structures: First International Conference.
(editor), S. T. et al. (2003). Business process execution
language for web services, version 1.1. http:
webservices/library/ws-bpel/. (Access:
10 June 2004).
Haas, H. (2004). Web services.
2002/ws/. (Access: 10 June 2004).
Ishikawa, F., Yoshioka, N., Tahara, Y., and Honiden, S. ((to
appear)). Behavior descriptions of mobile agents for
web services integration. In 2004 IEEE International
Conference on Web Services (ICWS 2004).
Leymann, F. (2001). Web services flow language (wsfl1.0).
Satoh, I. (2000). Mobilespaces: A framework for building
adaptive distributed applications using a hierarchical
mobile agent system. In The 20th International Con-
ference on Distributed Computing Systems ( ICDCS
2000), pages 161–168.
Satoh, I. (2001). Mobile agent-based compound documents.
In ACM Symposium on Document Engineering 2001,
pages 76–84.
Suna, A. and Fallah-Seghrouchni, A. E. (2004). A mobile
agents platform; architecture, mobility and security el-
ements. In The 2nd International Workshop on Pro-
gramming Multiagent Systems Languages and tools
(PROMAS 2004).
Tahara, Y., Yoshioka, N., and Honiden, S. (2003). A
formal model of active contents based on the ambi-
ent calculus. In The 5th International Workshop on
Mobile Agents for Telecommunication Applications,
pages 132–141.