BT FIPA Proposal
An Architecture,
Life-cycle & Generic Model for Service-Oriented Agents
Paul O'Brien & Mark Wiegand
Intelligent Systems Research Group
Advanced Applications & Technology
BT Labs
Martlesham Heath
Ipswich IP5 7RE
U.K.
Filing : Turin-1-97.doc
Status : Issue
Issue : 1.0
Date : 8/01/97
Intelligent Systems Research
Advanced Applications and Technology
0. Summary
This proposal describes a service-oriented agent architecture,
an agent service management life-cycle and an associated generic
reference model. This proposal is intended to meet the
requirements described in section 5.2.4 for an agent life-cycle model
and provide a framework for the analysis of proposals.
1.0 A Service-Oriented Agent Architecture
There are three high level requirements of the architecture :
1. Autonomy - agents are empowered to define how they will manage their local tasks and services.
2. Concurrency - services must be able to be run concurrently, with the interactions monitored and managed automatically.
3. Extensibility - Agents will need to define new services
incrementally, without the need to redesign an entire distributed system.
The multi-agent system architecture is designed to ensure
maximum flexibility to adapt as the agent service market changes. The
autonomy of each agent and the agreements it enters into with
other agents is the key to this flexibility. An agent will behave
in a proactive manner where possible; for example it can enter into
negotiation in anticipation of a future need for some component
service. Agents use negotiation as a mechanism for the
distribution of resources, problem solving effort, and the
management of dependencies between the activities to be carried
out. The result of negotiation is a service level agreement. The existence
of such an agreement is both a precondition for a service to be
provided, and serves to bind future activity and any subsequent
resource commitments. This architecture provides a method for
designing service-oriented agent systems.
Agency
The basic building block of the architecture is shown in
Figure 1. This basic unit comprises an agent and the tasks that
are under its direct control. This unit provides one or more
services all of which are under the control of the agent. In a
`free market' model each of these units would be able to
negotiate with any other agent when supplying a service.
Furthermore, an agent could negotiate with any other agent in
order to enhance its services or to create new services.
FIGURE 1. Basic Unit of Agent Organisation
The free market agent model is very simplistic, and not
practical in a commercial environment. Commercial environments are founded
on organisational models where an organisation is logically
divided into a collection of services. This architecture draws
upon this principle to group services and tasks where it makes
pragmatic sense. A grouping of tasks and services is known
collectively as an agency.
An agency is defined recursively: an agency consists of a
single responsible (or controlling) agent, a (possibly empty) set
of tasks that the responsible agent can perform, and a (possibly
empty) set of sub-agencies. An agency must contain at least one task
or two sub-agencies for it to be meaningful. For example, in
Figure 1 agency D has a single responsible agent that has two
distinct tasks (Task3 and Task4) and two sub-agencies (agencies E
and F). (A task is an atomic service; a service being some unit
of problem solving activity performed by some application). The
responsible agent represents the interests of the agency to its
peers. Peer agencies are those with responsible agents that may
communicate without crossing an agency boundary. For example, in
Figure 1 agency F is a peer of agency E and agency A is a peer of
agency D, but agency E is not a peer of agency A.
Any communication with the agency must go through the responsible agent. A sub-agency (e.g. agency F is a sub-agency of agency D) typically behaves in a co-operative manner towards its responsible agent, this agent being responsible for representing the interests of the agency in the wider community. This relationship between sub-agency and responsible agent can be viewed as a type of social commitment, and provides a mechanism for the encapsulation and abstraction of services. This commitment can be enforced by restricting access to/use of agent services to the responsible agent. Suppose that the responsible agent requests a service from one of its sub-agencies. This request cannot be flatly refused, a legitimate reason must be given. However, a sub-agency is not a subroutine, but rather a subsidiary agency. A sub-agency retains a high degree of local autonomy, but will necessarily co-operate with the responsible agent where possible.
The hierarchical structuring of agencies in the architecture
provides a mechanism for the encapsulation and abstraction of services.
It allows agents to represent and reason about services at an
appropriate level of abstraction. To the agent managing a task,
that task can be viewed as an atomic service with well defined
input, output and functional specifications.
During its lifetime, an agent may register new services as
they become available, or withdraw services if necessary (e.g.
due to other agents or tasks becoming inactive). An agent will
agree to provide a service that it has registered only if a
mutually advantageous agreement can be made with the agent requesting
that service. The agent registering a service is responsible for negotiating
the terms under which that service may be provided to other
agents, and the reliable execution of the service under the terms
of such an agreement. If an agent agrees to provide a service to
another, it is referred to as the `server' agent, and the agent
receiving the service is the `client' agent for that service
(roles that may be reversed). (Note that this characterisation of
agents as client agents and server agents is different from the
use of these terms in more traditional client-server systems; the
agents are autonomous, and will only co-operate under a
negotiated agreement.)
A Virtual Agency
The grouping of services in support of a single service instance
is termed a virtual agency. It is a collection of tasks and sub-services
involved in the provision of some service by a controlling agent.
The controlling agent will have (or require) contracts for the
sub-services that it requires from other participating agents.
The advantage of virtual agencies is that services can be
provisioned automatically in real-time by pooling resources.
2.0 Agent Service Life-cycle Model
The following life-cycle model describes the full life-span of
an agent, the services it provides, and each invocation of that service.
It does not define the internal states of an agent as this is not
considered a topic of standardisation in FIPA. The model consists
of three distinct life-cycles : agent service development
life-cycle, agent service registration life-cycle, and agent
service-instance usage life-cycle.
FIGURE 2 : Agent Management Life-cycle Model
Agent Service Development Life-cycle
The Agent service development life-cycle consists of those
management activities involved in the construction, modification, maintenance
and withdrawal of an agent service. A single agent can offer more
than one service.
An important aspect of development is the ability to verify
and validate an agent service to ensure it meets its functional requirements
before it is placed on-line. This is particularly difficult when
dealing with autonomous systems that are capable of adaptation
over time. In addition to this, it is important to establish
suitable minimum levels of performance, resilience and stability
so that an agent offers a suitable Quality of Service.
The developers of an agent service must be aware of the
availability and interfaces for component tasks and component agent services.
Like most large distributed systems, agent services need to be
defined incrementally without the need for an entire distributed system
redesign. Similarly, some agent services can be critical and so
would be upgraded and registered on-line.
Agent Service Registration Life-cycle
Agent Service Registration
Agent service registration ensures that users and agents are aware of the existence of a new agent service. Agent registration can be achieved by a number of means including :
Agent Service Suspension
Agent services can be temporarily suspended for a variety of
reasons both technical (e.g. the upgrading of software) and commercial
(e.g. no-longer profitable to offer service). Suspension could
involve the removal of a service offering from a trader or
broadcasting the unavailability of a service.
Agent Service Usage Life-cycle
Provision
Provisioning occurs when a registered service is requested
from or offered by an agent. This might involve agents entering into negotiation
using an inter-agent negotiation protocol. The result of a
successful process of negotiation is an agreement (referred to as
a service level agreement, or SLA) to provide some service under
terms and conditions which are acceptable to all parties. Agents
negotiate over the contents of an SLA, and if the agents involved
in negotiation agree on a final SLA this represents a binding
contract between these agents.
The SLA can be a standard unit of exchange between agents, and
hence serve to focus the negotiation process. When negotiating
over the contents of an SLA, agents must not only agree how a
problem is to be solved among the participating agents, but also
under what conditions these problem solving activities should
take place.
During negotiation the values of parameters in an SLA are
agreed (e.g. cost) and if successful a service instance is executed, (see
execution). If the negotiation is not successful, then no SLA is
made and no service instance executed.
The progress towards an agreement depends on the strategies adopted by the agents involved, which may be different. However, in a practical system agreements must be made in a timely manner, and avoid unnecessary communication (especially in domains such as the Internet where bandwidth is at a premium). Hence, there are three primary motivating factors in the development of inter-agent negotiation mechanisms:-
(1) to minimise computational effort in generating a response;
(2) to minimise communication overheads;
In general, the convergence of the negotiation process (and
hence the typical volume of communication required) depends on the
relationships between the parties involved, and the negotiation
strategies employed.
For agents to negotiate they require:-
(1) a protocol;
(2) a data structure that represents the result of negotiation (i.e. something to negotiate over);
(3) a reasoning model.
Delivery
Service delivery involves the agent executing an agreed
service by executing functions it can perform itself, or invoking functionality
from external tasks. An SLA governs the terms and conditions for
the delivery of a service.
When a service is successfully completed to the satisfaction
of both agents the service is deemed completed.
If exceptions occur which cannot be resolved by the agent
during execution and which result in the agent not meeting its obligations
described in the SLA, then the service reverts to the
provisioning phase for re-resourcing or re-negotiation.
Completion
On completion of an agreed service an agent may dispose of the
service instance created and recover resources that were reserved
to support that service. Depending on the application context an
execution record might be recorded in support of a service audit
trail.
Failure
On failure of an agreed service an agent may dispose of the
service instance created and recover resources that were reserved
to support that service. Depending on the nature of the failure
corrective action (e.g. logging a fault) might be necessary..
Re-negotiation
Agents can agree modifications to an existing SLA if the
original terms and conditions cannot be met. If re-negotiation
fails then the service can no longer be provided and is
terminated.
3.0 Generic Agent Reference Model
There are four key components and five bi-directional
interfaces in the generic agent reference model, (figure 3).
These interfaces may be realised in a variety of ways in the
design of an agent system.
FIGURE 3. Components of an Agent System and Key
Agent Interfaces
The key components of the reference model are :
User Interface : The user interface allows users to
access agent based services. This can be achieved by a variety of terminal
devices (e.g. Personal Digital Assistants) and software packages
(e.g. World Wide Web browser).
Agent : An agent is a co-operating knowledge based
system capable of communicating and negotiating with other agents and users
for the provision and execution of services.
Agent Management System (AMS) : The AMS supports
developers in engineering and monitoring agent-based systems. Ideally
standardised system languages and interfaces are provided that
allow developers to implement and maintain the agent. The design
of an agent system involves the transformation of some
description of an agent service into a number of communicating
and co-operating software agents.
The monitoring and administration of a number of agents
demands the ability to collate information from all the agents involved,
filter this information, and present it in a way that allows an
owner/manager to understand the contribution from all agents in
the enterprise, and to see where problems might occur.
Task : Agents can access external systems in
support of services they provide to other agents and users. A
task is an application that is managed by an agent in support of
the services it provides.
The key interfaces in the reference model are:-
A. The task management interface (Section 5.4 FIPA Call for Proposals).
This is an agent-task communication interface that allows an
agent to monitor and control applications that are under its direct management
or it can access in the execution of services.
B. The agent-user interface. (cf. Section 5.3.2 FIPA Call for Proposals)
This interface supports user interaction with the agent.
C. The agent-agent interface. (cf. Section 5.3.2 FIPA Call for Proposals)
This is an agent-agent communication interface that supports
both inter-agent negotiation and service management when an agreed
service is being delivered.
D. The management system-agent interface.
This interface supports agent management functions (i.e.
monitoring, maintenance etc.) both pre-service and in-service. Whether
this interface is a topic for standardisation is an area for
debate. The choice is between having an open management interface
to agents or keeping it specific to the organisation/individual
that is responsible for that agent and its services.
E. The task-task interface
This is likely to be an application specific interface
supporting application interaction as agreed by the managing
agents and should not be defined by FIPA. Although the nature of
this interface is outside the scope of FIPA, agents could be responsible
for managing the use of such interfaces. For example, if the two
applications are two video conferencing terminals agents could
manage when and how the two applications establish a connection.
O'Brien P.D. & Wiegand M.E. (1996). Agents of Change in
Business Process Management, in BT Technical Journal 14(4):133-140.
O'Brien P.D. & Davison R.G. (1994). Decision Support for
Service Provisioning, BT Technical Journal, 12(4).
Wiegand M.E. (1996) Building Practical Agent-based Systems
(tutorial notes), 1st International Conference on the Practical Applications
of Intelligent Agents and Multi-Agent Technology, London, UK,
pp.345-360.
Nwana H.S. & Ndumu D.T. (1996) An Introduction to Agent Technology, in BT Technical Journal 14(4):55-68
| Issue | Date of Issue | Comments | Reviewer |
| 1.0 | 8/1/97 | - | DN HN |
Appendix : General Issues
Agent Heterogeneity
To enable functions such as negotiation and service
management, each agent must have the ability to communicate with agents that
it needs to interact with through some mechanism. However, agents
may be developed for different purposes, by different people at
different times, and so neither the languages used in the
development of the agent software nor the methods of representing
knowledge in each agent will be uniform; i.e. agents are
heterogeneous.
Common Information Models
In common with a number of existing approaches to software
agent inter-operation in order for an agent to collaborate with other
agents it is necessary for it to communicate using a common
expressive language. This common language consists of a protocol
(i.e. a set of speech acts) and a syntax for expressing information.
Furthermore, for one agent to understand the meaning of another's
communicative actions they must either share a common information
model or have the ability to transform information between their
respective models. This use of a common knowledge sharing
language and a common semantic interpretation of the symbols used
within messages composed using this language enables agents within
the community to:
(1) know the intention of a communicating agent via a set of speech acts (e.g. is the message intended to inform, deny, or request some proposition?);
(2) interpret the contents of the message through the use of a common syntax;
(3) understand what the contents of the message mean via the
use of ontological commitments (e.g. what is the meaning of the proposition
that the agent is being informed of, that is being denied, or
requested).
An agent must use one of a set of specified communicative
action types to specify the intention of a message. Consider the action
"propose": this indicates that the agent sending the
message intends the content of the message to be interpreted as a proposal
for the provision of a particular service that the recipient has
registered as being able to provide.
As well as understanding the intention behind the message, a
recipient must be able to interpret the contents of a message for it
to be understood. Therefore, either each agent must use the same
syntax to communicate information, or the syntax used must be
explicitly stated in the message. In the latter case, for agents
to communicate they must both be able to interpret the syntax
specified in the message. The final requirement for effective
inter-agent communication is that the agent receiving a message
must be able to understand the intended meaning of the symbols
contained in the message.