FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
FIPA Agent Management
Support for Mobility Specification
|
Document
title
|
FIPA
Agent Management Support for Mobility Specification
|
|
Document
number
|
DC000087C
|
Document
source
|
FIPA
Architecture Board
|
|
Document
status
|
Deprecated
|
Date
of this status
|
2002/05/10
|
|
Supersedes
|
None
|
|
Contact
|
fab@fipa.org
|
|
Change
history
|
|
2002/05/10
|
Deprecated
by FAB
|
© 2000 Foundation for Intelligent
Physical Agents - http://www.fipa.org/
Geneva, Switzerland
|
Notice
|
|
Use of the technologies described
in this specification may infringe patents, copyrights or other intellectual
property rights of FIPA Members and non-members. Nothing in this
specification should be construed as granting permission to use any of the
technologies described. Anyone planning to make use of technology covered by
the intellectual property rights of others should first obtain permission
from the holder(s) of the rights. FIPA strongly encourages anyone
implementing any part of this specification to determine first whether
part(s) sought to be implemented are covered by the intellectual property of
others, and, if so, to obtain appropriate licenses or other permission from
the holder(s) of such intellectual property prior to implementation. This
specification is subject to change without notice. Neither FIPA nor any of
its Members accept any responsibility whatsoever for damages or liability,
direct or consequential, which may result from the use of this specification.
|
Foreword
The Foundation for Intelligent Physical Agents
(FIPA) is an international organization that is dedicated to promoting the
industry of intelligent agents by openly developing specifications supporting
interoperability among agents and agent-based applications. This occurs through
open collaboration among its member organizations, which are companies and
universities that are active in the field of agents. FIPA makes the results of
its activities available to all interested parties and intends to contribute
its results to the appropriate formal standards bodies.
The members of FIPA are individually and
collectively committed to open competition in the development of agent-based
applications, services and equipment. Membership in FIPA is open to any
corporation and individual firm, partnership, governmental body or
international organization without restriction. In particular, members are not
bound to implement or use specific agent-based standards, recommendations and
FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through direct
involvement of the FIPA membership. The status of a specification can be either
Preliminary, Experimental, Standard, Deprecated or Obsolete. More detail
about the process of specification may be found in the FIPA Procedures for
Technical Work. A complete overview of the FIPA specifications and their
current status may be found in the FIPA List of Specifications. A list of terms
and abbreviations used in the FIPA specifications may be found in the FIPA
Glossary.
FIPA is a non-profit association registered in
Geneva, Switzerland. As of January 2000, the 56 members of FIPA represented 17
countries worldwide. Further information about FIPA as an organization,
membership information, FIPA specifications and upcoming meetings may be found
at http://www.fipa.org/.
Contents
1 Scope. 1
2 Agent Management Support for
Mobility Reference Model 2
2.1 Protocols as a Metaphor for
Expressing Mobility. 2
2.2 Mobility Life Cycle. 3
2.3 Mobility Protocols. 4
2.3.1 Agent Migration. 5
2.3.2 Agent Cloning. 2
2.3.3 Agent Invocation. 2
2.4 Agent Profiles. 2
3 Agent Mobility Ontology. 3
3.1 Object Descriptions. 3
3.1.1 Mobile Agent Description. 3
3.1.2 Mobile Agent Profile. 3
3.1.3 Mobile Agent System.. 4
3.1.4 Mobile Agent Language. 4
3.1.5 Mobile Agent Operating
System.. 4
3.2 Function Descriptions. 4
3.2.1 Migrate a Mobile Agent 5
3.2.2 Transfer the Identity of a
Mobile Agent 5
3.3 Exceptions. 5
3.3.1 Failure Exception
Propositions. 5
4 Annex A — Integration of
FIPA Agent Mobility and MAF. 7
5 References. 9
FIPA is concerned with two types of
mobility; mobility in devices such as portable computers and Personal Digital
Assistants (PDAs) that can be intermittently connected to the network, and
mobility in software such as mobile agents that can move between hosts.
This specification is concerned with
specifying the minimum requirements and technologies to allow agents to take
advantage of mobility. This specification integrates closely with [FIPA00023]
and provides a wrapping mechanism for existing mobile agent systems to promote
interoperability. Therefore, the scope of this specification is limited to:
·
This specification does not mandate the use of
mobility features. Instead, it mandates how agents and APs may support
mobility, if mobility is desired.
·
This specification does not mandate the use of
any explicit technology for supporting mobility. Instead, it provides a
wrapping mechanism for mobile agent systems.
·
This specification does not define how mobile
agents and mobile agent systems operate or are implemented. However, the
mobility capabilities defined in this specification rely on their existence.
·
Mobile agent security is not currently addressed
by this specification. This topic will be addressed in future versions of this
specification.
·
This specification defines extensions that are
necessary to the AMS to support mobility.
·
The platform profile can become a standard way
for an agent to discover the type of mobility supported by an AP. If an AP does
not support mobility, then it should refuse any mobility operation.
It is recognised that there are many ways
of expressing mobility within agents, such as code mobility, agent migration
and agent cloning. For this reason, FIPA does not mandate a single form of
agent mobility but supports a core set of actions that allow flexible and
extensible forms of mobility protocols to be supported. Two example protocol
abstractions are explained here:
·
Simple Mobility Protocols
An agent relies
on a high level protocol that uses a single action (for example, move)
which causes it to be moved to a destination AP. In this case, the AP upon
which the agent is executing will have to implement the necessary protocol to
realise the entire migration operation. This is illustrated in Figure 1,
where an agent is delegating its mobility operation to the agent platform.
The perceived
advantages of the simple mobility protocols are that there is a reduced
complexity in application agent development since mobility is supported by the
AP, they are oriented towards existing mobile agent frameworks (for example,
[OMGmaf]) and easy implementation on existing mobile agent platforms via FIPA
ACL enhancement, and, there is a reduced number of remote interactions.
Figure
1: Example Simple Mobility Protocol
·
Full Mobility Protocols
An agent directs
the mobility protocol itself and does not delegate responsibility to the AP. As
shown in Figure 2, an agent first moves its agent code (and
possibly state) to a destination AP and eventually transfers its
identity and authority once it is assured that the new agent has been created
successfully. Note that the agent mobility operation is not deemed to be
completed until both the agent code (and possibly state) and the agent identity
have been successfully transferred. Additionally, this protocol also allows the
agent to inform its HAP and any other APs that it has moved to a new location.
The perceived
advantages of full mobility protocols are that is a reduced complexity in AP
implementation, there are enhanced capabilities for the application agent in
controlling the mobility operation, and, it represents a more secure form of
mobility.
Figure
2: Example Full Mobility Protocol
It is expected that both of these protocols
(and others) can be appropriate in different application contexts. Therefore,
this specification expects that FIPA AP, that support mobility will implement
either low level or high level mobility protocol, or both.
To initiate agent mobility (such as
migration, cloning or invocation) with the move operation, the sending
agent will identify the mobility protocol to be used for that mobility
operation (see section 2.3, Mobility Protocols). Using this information, the involved AMS and agents determine and take subsequent actions to complete the mobility operation that may involve the use of other operations, such as transfer.
This specification extends the existing
life cycle given in [FIPA00023] by adding a new state (Transit) and two
new actions to enter and leave that state (Move and Execute).
This allows the current state of the agent to be represented within the AMS.
This new life cycle illustrated in Figure 3.
Only mobile agents can enter the Transit
state, or to put it another way, stationary agents never enter the Transit
state. This ensures that a stationary agent executes all of its instructions on
the node where it was invoked. The actions of agents can be described as:
·
Move
Puts the agent in
a transitory state; this can only be initiated by the agent.
·
Execute
Brings the agent
out of a transitory state; this can only be initiated by the agent system.
The relationship between the life cycle
actions of Move and Execute can be associated with the Agent Management actions
of Move, Transfer and Execute in the following way. To
enter the Transit state, a mobile agent initiates the execution of a
mobility protocol that involves sending a Move (and possibly a Transfer
in the case of a full mobility protocol) to an AMS. Correspondingly, a mobile
agent is brought out of the Transit state by an AMS issuing an execute
action upon its code (see section 2.3, Mobility Protocols).
Figure
3: Mobile Agent Life Cycle
A number of standard protocols have been
defined to cover various forms of agent mobility. Specifically, they address:
·
Agent migration,
·
Agent cloning, and,
·
Agent invocation.
As described in section 2.1, Protocols as a Metaphor for Expressing Mobility, there are essentially two types of protocols; simple and full. The simple protocols base most of the functionality of the mobility operation within the local and remote APs; the full protocols spread the task
across the mobile agent and the APs.
Figures 4 to 9 represent the three mobility
operations for each type of protocol; when an agent wishes to move to another
AP, it can specify one of these as a mobility protocol that describes the
actions and reactions of each involved parties. Other protocols can be
constructed from the actions given in section 3.2,
Function Descriptions to permit flexible and extensible forms of agent mobility.
Agents that wish to transport themselves
between two APs invoke the agent migration protocols. The simple migration
protocol (see Figure 4) requires that the migrating agent delegate
all responsibility for the migration operation to the APs, who complete the
task on its behalf. By comparison, the full migration protocol (see Figure
5) requires the agent to participate in the migration operation and to
control aspects of its completion; the task is not completed until the transfer
action has been approved.
Figure
4: Simple Agent Migration Protocol
Figure
5: Full Agent Migration Protocol
Agents that wish to create an agent on an
AP invoke the agent invocation protocols. These protocols follow the same
principles and responsibilities as agent migration and agent cloning (see Figure
8 and Figure 9).
Figure
8: Simple Agent Invocation Protocol
Figure
9: Full Agent Invocation Protocol
Since a mobile agent can be transported
between APs in a variety of formats it can make a number of demands upon an AP
for a required set of conditions to be met before such an agent can be
executed. Some common examples of the form of a mobile agent might be:
·
Written in Java (version 1.2) using the Aglets
mobile agent toolkit (0.1 beta) represented as serialised byte-code,
·
Written in C represented as native code compiled
for Linux (version 2.2.15) on i386 hardware, or,
·
Written in April (version 4.4) represented as
byte-code.
Each of these dependencies can be expressed
as part of the meta-information of a mobile agent within the :profile
parameter (see section 3.1.2, Mobile Agent Profile). This parameter contains three description sections that allow various characteristics of the mobile agent to be specified:
·
:system
Expresses
requirements of the mobile agent system which the mobile agent uses (if any),
such as Aglets, Mole, AgentTcl or Voyager (see section 3.1.3, Mobile Agent System).
·
:language
Expresses
requirements of the language in which the mobile agent is written, such as Java
source code, i386 native code or April byte-code (see section 3.1.4, Mobile Agent Language).
·
:os
Expresses
requirements of the operating system for which the mobile agent was intended
(if any), such as a Solaris SPARC box or a Linux i386 box (see section 3.1.5, Mobile Agent Operating System).
This permits a great deal of flexibility in
stating the execution requirements of a mobile agent and can be used by a
receiving AP to determine whether it can support an agent of that type. A particular deficiency in any stated
profile description section may cause the agent to be rejected on the grounds
of lack of support or for security reasons (agent-profile-unsupported).
Extra dependency information can be stated
in the :dependencies parameter of each profile description section. This is a free-form
parameter that may or may not be supported by an AP for that particular class
of agent. For example, language dependencies may express additional class
libraries required by the mobile agent and operating system dependencies may
express additional software that should be installed on the OS (such as Perl,
TCL/Tk, etc.).
This ontology represents extensions to the FIPA-Agent-Management ontology defined in [FIPA00023] if mobility is supported.
This section describes a set of frames that
represent the classes of objects in the domain of discourse within the
framework of the FIPA-Agent-Management ontology.
The following terms are used to describe
the objects of the domain:
·
Frame. This is
the mandatory name of this entity that must be used to represent each instance
of this class.
·
Ontology. This is
the name of the ontology, whose domain of discourse includes the parameters
described in the table.
·
Parameter. This
is the mandatory name of a parameter of this frame.
·
Description. This
is a natural language description of the semantics of each parameter.
·
Presence. This
indicates whether each parameter is mandatory or optional.
·
Type. This is the
type of the values of the parameter: Integer, Word, String, URL, Term, Set or
Sequence.
·
Reserved Values.
This is a list of FIPA-defined constants that can assume values for this
parameter.
|
Frame
Ontology
|
mobile-agent-description
FIPA-Agent-Management
|
|
|
Parameter
|
Description
|
Presence
|
Type
|
Reserved
Values
|
|
|
The
identifier of the agent.
|
|
agent-identifier
|
|
|
profile
|
A list
of mobility requirements of the agent.
|
Optional
|
Set of
mobile-agent-profile
|
|
|
|
The
version of the agent.
|
|
String
|
|
|
|
A list
of mobility protocols supported by the agent.
|
|
Set
of String
|
|
|
|
The
code-base of the agent
|
|
Byte-Stream
|
|
|
|
The dynamic data (state) of the agent.
|
|
Byte-Stream
|
|
|
Frame
Ontology
|
mobile-agent-profile
FIPA-Agent-Management
|
|
|
Parameter
|
Description
|
Presence
|
Type
|
Reserved
Values
|
|
|
The
mobile agent system environment supported by the agent.
|
|
mobile-agent-system
|
|
|
language
|
The
language environment supported by the agent.
|
Mandatory
|
mobile-agent-language
|
|
|
|
The operating system environment supported by the agent.
|
|
mobile-agent-os
|
|
|
Frame
Ontology
|
mobile-agent-system
FIPA-Agent-Management
|
|
|
Parameter
|
Description
|
Presence
|
Type
|
Reserved
Values
|
|
|
The
name of the mobile agent system.
|
|
String
|
|
|
major-version
|
The
major version of the mobile agent system.
|
Mandatory
|
String
|
|
|
|
The minor version of the mobile agent system.
|
|
String
|
|
|
|
The dependencies required by the mobile agent system.
|
|
Set
of property
|
|
|
Frame
Ontology
|
mobile-agent-language
FIPA-Agent-Management
|
|
|
Parameter
|
Description
|
Presence
|
Type
|
Reserved
Values
|
|
|
The
name of the mobile agent language.
|
|
String
|
|
|
major-version
|
The
major version of the mobile agent language.
|
Mandatory
|
String
|
|
|
|
The minor version of the mobile agent language.
|
|
String
|
|
|
|
The format of the code base of the mobile agent.
|
|
String
|
|
|
|
The filter that should be executed over the code base
before execution.
|
|
String
|
|
|
|
The dependencies required by the mobile agent language.
|
|
Set
of property
|
|
|
Frame
Ontology
|
mobile-agent-os
FIPA-Agent-Management
|
|
|
Parameter
|
Description
|
Presence
|
Type
|
Reserved
Values
|
|
|
The
name of the operating system.
|
|
String
|
|
|
major-version
|
The
major version of the operating system.
|
Mandatory
|
String
|
|
|
|
The minor version of the operating
system.
|
|
String
|
|
|
|
The hardware of the operating system.
|
|
String
|
|
|
|
The dependencies required by the operating
system.
|
|
Set
of property
|
|
The following tables define usage and
semantics of the functions that are part of the FIPA-Agent-Management
ontology and that are supported by the agent management services and agents on the
AP.
The following terms are used to describe
the functions of the FIPA-Agent-Management domain:
·
Function. This is
the symbol that identifies the function in the ontology.
·
Ontology. This is
the name of the ontology, whose domain of discourse includes the function
described in the table.
·
Supported by. This
is the type of agent that supports this function.
·
Description. This
is a natural language description of the semantics of the function.
·
Domain. This
indicates the domain over which the function is defined. The arguments passed
to the function must belong to the set identified by the domain.
·
Range. This
indicates the range to which the function maps the symbols of the domain. The
result of the function is a symbol belonging to the set identified by the
range.
·
Arity. This
indicates the number of arguments that a function takes. If a function can take
an arbitrary number of arguments, then its arity is undefined.
|
Function
|
move
|
|
|
Ontology
|
FIPA-Mobile-Agent-Management
|
|
|
Supported by
|
AMS
|
|
|
Description
|
An agent issues a move request to transfer itself to a local/remote
AMS. However, the AMS may refuse to accept the move request due to lack of agent profile support or other
local restrictions.
|
|
Domain
|
mobile-agent-description
|
|
Range
|
The execution of this function
results in a change of the state but it has no explicit result. Therefore
there is no range set.
|
|
Arity
|
1
|
|
Function
|
transfer
|
|
|
Ontology
|
FIPA-Mobile-Agent-Management
|
|
|
Supported by
|
AMS
|
|
|
Description
|
An agent issues a transfer request to send its identity and authority to
another agent on a destination AMS. However, the receiving agent may refuse
to accept the transfer request for security reasons.
|
|
Domain
|
mobile-agent-description
|
|
Range
|
The execution of this function
results in a change of the state but it has no explicit result. Therefore
there is no range set.
|
|
Arity
|
1
|
These exceptions extend those defined in
[FIPA00023].
|
Communicative
Act
Ontology
|
failure
FIPA-Agent-Management
|
|
|
Predicate
symbol
|
Arguments
|
Description
|
|
|
String
|
The
receiving AMS does not support agent mobility.
|
|
|
String
|
The
receiving AMS does not support the specified mobility profile description.
|
|
|
String
|
The
receiving AMS already has an agent registered with the same name as the
migrating agent.
|
The intention of the Mobile Agent Facility
(MAF - see [OMGmaf]) specification is to achieve a certain degree of
interoperability between mobile agent platforms of different manufacturers. A
MAF-compliant agent platform can be accessed via two standardised interfaces
that are specified by means of the OMG's Interface Definition Language (IDL): MAFAgentSystem
and MAFFinder. These interfaces provide fundamental operations for agent
management, agent tracking and agent transport. Note that these interfaces
represent the access point to agent systems and registration components; their
concrete implementation is not specified.
Several similarities between a FIPA AP that
supports agent mobility and a MAF-compliant AP can be drawn regarding their
functionality:
·
The FIPA AMS can be compared to a MAF agent
system, represented by the MAFAgentSystem interface; both are responsible for the management of agents,
·
The FIPA DF is similar to the MAF registration
component, represented by the MAFFinder interface; the task of these entities is the maintenance of
registration information about agents in a distributed environment,
·
The equivalent of the Message Transport System
(MTS - see [FIPA00067]) is the Object Request Broker (ORB) in the context of
MAF; these entities care for the transfer of messages in a distributed agent
environment, and,
·
FIPA and MAF provide their specifications in an
implementation-independent way.
Beside these similarities, several
differences have to be mentioned which are mainly associated with the general
design approach of the FIPA specifications and the MAF specification:
·
FIPA standards try to cover the set of functionality
that is required for the execution and support of mobile agents by means of a
high-level speech act language, the ACL, as well as appropriate content
languages. ACL allows for the specification of operations and high-level
communication protocols, and,
·
The MAF specification covers a minimal set of
functionality since it is meant as an add-on to existing agent platforms rather
than as the basis for completely new systems. The functionality of a
MAF-compliant platform is accessible via IDL interfaces. These interfaces
provide, among others, methods for the management (that is, creation,
suspension, resumption and termination), transport and tracking of agents. In
contrast to FIPA, no high-level language is used above the IDL methods.
Instead, each IDL method is directly mapped onto a method of the associated,
implemented object.
Regarding these characteristics of FIPA and
MAF, the two standardisation approaches can be combined to a unified mobile
agent framework. One promising way seems to be the integration of the IDL
operation(s) defined in FIPA for the transfer of ACL messages into the MAF IDL
specifications (see Figure 10). To realise an agent platform that is
FIPA- and MAF-compliant, the following three possibilities exist:
·
The existing MAF interfaces MAFAgentSystem
and MAFFinder can be enhanced by new operations that enable a FIPA-compliant
platform access,
·
The existing operations of the MAF interfaces
can be modified in order to adapt them to the requirements of the FIPA
specifications, and,
·
Completely new interfaces are specified
additionally to the existing MAF interfaces.
While the first two approaches require
modification of the existing MAF specification, the third approach can be
regarded as a pure extension that does not require any changes.
Figure
10: Integration of FIPA and MAF
However, the FIPA specifications could be
enhanced by some "specialised" methods as defined in the MAF
specification. This could be desirable for methods that have a simple parameter
structure and that can be sufficiently represented without using a high-level
content language.
[FIPA00023] FIPA Agent Management Specification.
Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/
[FIPA00067] FIPA Agent Message Transport Service Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00067/
[OMGmaf] OMG Mobile Agent Facility Specification. Object Management Group, 2000. http://www.omg.org/cgi-bin/doc?formal/00-01-02.pdf
