1 Introduction

This document, and the specifications that are derived from it, defines the FIPA Architecture. The parts of the FIPA architecture include:

· A specification that defines architectural elements and their relationships (this document).

· Guidelines for the specification of agent systems in terms of particular software and communications technologies (Guidelines for Instantiation).

· Specifications governing the interoperability and conformance of agents and agent systems (Interoperability Guidelines).

See Section 2, Scope and Methodology for a fuller introduction to this document.

1.1 Contents

This document is organized into the following sections and a series of annexes.

· This Introduction.

· The Scope and methodology section explains the background of this work, its purpose, and the methodology that has been followed. It describes the role of this work in the overall FIPA work program, and discusses the status of the work.

· The Architectural overview presents an overview of the architecture with some examples. It is intended to provide the appropriate context for understanding the following sections.

· The Architecture and Information Model and Architectural Elements comprise the FIPA architecture itself.

· The section Evolution of the Architecture discusses the way in which this document may evolve.

The annexes include:

· Goals for message transport, directory services, agent communication language and security.

· Relationships to existing FIPA specifications.

· Description of the Abstract ACL.

1.2 Audience

The primary audience for this document is developers of concrete specifications for agent systems – specifications grounded in particularly technologies, representations, and programming models. It may also be read by the users of thee concrete specifications, including implementers of agent platforms, agent systems, and gateways between dissimilar agent systems.

This document describes an abstract architecture for creating intentional multi-agent systems. It assumes that the reader has a good understanding about the basic principles of multi-agent systems. It does not provide the background material to help the reader assess whether multi-agent systems are an appropriate model for their system design, nor does it provide background material on topics such as Agent Communication Languages, BDI systems, or distributed computing platforms.

The abstract architecture described in this document will guide the creation of concrete specifications of different elements of the FIPA agent systems. The developers of the concrete specifications must ensure that their work conform with the abstract architecture in order to provide specifications with appropriate levels of interoperability. Similarly, those specifying applications that will run on FIPA compliant agent systems will need to understand what services and features that they can use in the creation of their applications.

1.3 Acknowledgements

This document was developed by members of FIPA TC A, the Technical Committee of FIPA charged with this work. Other FIPA Technical Committees also made substantial contributions to this effort, and we thank them for their effort and assistance.

2 Scope and Methodology

This section provides a context for the Abstract Architecture, the scope of the work and methodology used in this work.

2.1 Background

FIPA’s goal in creating agent standards is to promote inter-operable agent applications and agent systems. In 1997 and 1998, FIPA issued a series of agent system specifications that had as their goal inter-operable agent systems. This work included specifications for agent infrastructure and agent applications. The infrastructure specifications included an agent communication language, agent services, and supporting management ontologies. There were also a number of application domains specified, such as personal travel assistance and network management and provisioning.

At the heart FIPA’s model for agent systems is agent communication, where agents can pass semantically meaningful messages to one another in order to accomplish the tasks required by the application. In 1998 and 1999 it became clear that it would be useful to support variations in those messages:

· How those messages are transferred (that is, the transport).

· How those messages are represented (as strings, as objects, as XML).

· Optional attributes of those messages, such as how to authenticate or encrypt them.

It also became clear that to create agent systems, which could be deployed in commercial settings, it was important to understand and to use existing software environments. These environments included elements like:

· distributed computing platforms or programming languages,

· messaging platforms,

· security services,

· directory services, and,

· intermittent connectivity technologies.

FIPA was faced with two choices: to incrementally revise specifications to add various features, such as intermittent connectivity, or to take a more holistic approach. The holistic approach, which FIPA adopted in January of 1999, was to create an architecture that could accommodate a wide range of commonly used mechanisms, such as various message transports, directory services and other commonly, commercially available development platforms. For detailed discussions of the goals of the architecture, see:

· Section 7, Informative Annex A: Goals of Message Transport Abstractions.

· Section 8, Informative Annex B: Goals of Directory Service Abstractions.

· Section 9, Informative Annex C: Goals for Abstract Agent Communication Language.

· Section 10, Informative Annex D: Goals for Security and Identity Abstractions.

These describe in greater detail the design considerations that were considered when creating this abstract architecture. In addition, FIPA needed to consider the relationship between the existing FIPA 97, FIPA 98 and FIPA 2000 work and the abstract architecture. While more validation is required, the FIPA 2000 work is probably a concrete realization of this abstract architecture. (This validation is required because both the FIPA 2000 and the architecture are not yet complete.) While one of the goals in creating this architecture was to maintain full compatibility with the FIPA 97 and 98 work, this was not entirely feasible, especially when trying to support multiple implementations.

Agents built according to FIPA 97 and 98 specifications will be able to inter-operate with agents built according to the abstract architecture through gateways with some limitations. The FIPA 2000 architecture is a closer match to the abstract architecture, and will be able to fully inter-operate via gateways. The overall goal in this architectural approach is to permit the creation of systems that seamlessly integrate within their specific computing environment while interoperating with agent systems residing in separate environments.

2.2 Why an Abstract Architecture?

The first purpose of this work is to foster interoperability and reusability. To achieve this, it is necessary to identify the elements of the architecture that must be codified. Specifically, if two or more systems use different technologies to achieve some functional purpose, it is necessary to identify the common characteristics of the various approaches. This leads to the identification of architectural abstractions: abstract designs that can be formally related to every valid implementation.

By describing systems abstractly, one can explore the relationships between fundamental elements of these agent systems. By describing the relationships between these elements, it becomes clearer how agent systems can be created so that they are interoperable. From this set of architectural elements and relations one can derive a broad set of possible concrete architectures, which will interoperate because they share a common design.

Because the abstract architecture permits the creation of many concrete realizations, it must provide mechanisms to permit them interoperate. This includes providing transformations for both transport and encodings, as well as integrating these elements with the basic elements of the environment.

For example, one agent system may transmit ACL messages using the OMG IIOP protocol. A second may use IBM’s MQ-series enterprise messaging system. An analysis of these two systems – how senders and receivers are identified, and how messages are encoded and transferred – allows us to arrive at a series of architectural abstractions involving messages, encodings, and addresses.

2.3 Scope of the Abstract Architecture

The primary focus of this abstract architecture is create semantically meaningful message exchange between agents which may be using different messaging transports, different Agent Communication Languages, or different content languages. This requires numerous points of potential interoperability. The scope of this architecture includes:

· Message transport interoperability.

· Supporting various forms of ACL representations.

· Supporting various forms of content language.

· Supporting multiple directory services representations.

It must be possible to create implementations that vary in some of these attributes, but which can still interoperate.

Some aspects of potential standardization are outside of the scope of this architecture. There are three different reasons why things are out of scope:

· The area can not be describe abstractly.

· The area is not yet ready for standardization, or there was not yet sufficient agreement about how to standardize it.

· The area is sufficiently specialized that it does not currently need standardization.

Some of the key areas that are not included in this architecture are:

· Agent lifecycle and management.

· Agent mobility.

· Domains.

· Conversational policy.

· Agent Identity.

The next sections describe the rationale for this in more detail. However, it extremely important to understand that the abstract architecture does not prohibit additional features – it merely addresses how interoperable features should be implemented. It is anticipated that over time some of these areas will be part of the interoperability of agent systems.

2.3.1 Areas that are not Sufficiently Abstract

An abstraction may not appear in the abstract architecture because is there is no clean abstraction for different models of implementation. Two examples of this are agent lifecycle management and security related issues.

For example, in examining agent lifecycle, it seems clear there are a minimum set of features that are required: Starting an agent, stopping an agent, “freezing” or “suspending” an agent, and “unfreezing” or “restarting” an agent. In practice, when one examines how various software systems worked, there was very little consistency in the mechanisms used in the different systems, nor in how to address and use those mechanisms. Although it is clear that concrete specifications will have to address these issues, it is not clear how to provide a unifying abstraction for these features. Therefore there are some architectural elements that can only appear at the concrete level, because the details of different environments are so diverse.

Security had similar issues, especially when trying to provide security in the transport layer, or when trying to provide security for attacks that can occur because a particular software environment has characteristics that permits that sort of attack. Agent mobility is another implementation specific model that can not easily be modelled abstractly.

Both of these topics will be addressed in the Instantiation Guidelines, because they are an important part of how agent systems are created. However, they can not be modelled abstractly, and are therefore not included at the abstract level of the architecture.

2.3.2 Areas to be Considered in the Future

FIPA may address a number of areas of agent standardization in the future. These include domains, conversational policies, mechanisms which are used to control systems (resource allocation and access control lists), and agent identity. These all represent ideas which require further development.

This architecture has not addressed application interoperability. The current model for application interoperability is that agents which communicate using a shared set of semantics (such as represented by an ontology) can potentially interoperate. This architecture has not extended that model any further.

2.4 Going From Abstract to Concrete Specifications

This document describes an abstract architecture. Such an architecture cannot be implemented as it stands. Instead the abstract architecture forms the basis for the development of concrete architectural specifications. Such specifications describe in precise detail how to construct an agent system, including the agents and the services that they rely upon, in terms of concrete software artefacts, such as programming languages, applications programming interfaces, network protocols, operating system services, and so forth.

In order for a concrete architectural specification to be FIPA compliant, it must have certain properties. First, the concrete architecture must include mechanisms for agent registration and agent discovery and inter-agent message transfer. These services must be explicitly described in terms of the corresponding elements of the FIPA abstract architecture. The definition of an abstract architectural element in terms of the concrete architecture is termed a realization of that element; more generally, a concrete architecture will be said to realize all or part of an abstraction.

The designer of the concrete architecture has considerable latitude in how he or she chooses to realize the abstract elements. If the concrete architecture provides only one encoding for messages, or only one transport protocol, the realization may simplify the programmatic view of the system. Conversely, a realization may include additional options or features that require the developer to handle both abstract and platform-specific elements. That is to say that the existence of an abstract architecture does not prohibit the introduction of elements useful to make a good agent system, it merely sets out the minimum required elements.

Figure 1: Abstract Architecture Mapped to Various Concrete Realizations

The abstract architecture also describes optional elements. Although an element is optional at the abstract level, it may be mandatory in a particular realization. That is, a realization may require the existence of an entity that is optional at the abstract level (such as a message-transport-service), and further specify the features and interfaces that the element must have in that realization.

It is also important to note that a realization can be of the entire architecture, or just one element. For example, a series of concrete specifications could be created that describe how to represent the architecture in terms of particular programming language, coupled to a sockets based message transport. Messages are handled as objects with that language, and so on.

On the other hand, there may be a single element that can be defined concretely, and then used in a number of different systems. For example, if a concrete specification were done for the directory-service element that describes the schemas to use when it is implemented in LDAP, that particular element might appear in a number of different agent systems.

Figure 2: Concrete Realizations Using a Shared Element Realization

In this example, the concrete realization of directory is to implement the directory services in LDAP. Several realizations have chosen to use this directory service model.

2.5 Methodology

This abstract architecture was created by the use of UML modelling, combined with the notions of design patterns as described in Design Patterns (Gamma, Helm, Johnson & Vlissides, Addison-Welsley, 1995). Analysis was performed to consider a variety ways of structuring software and communications components in order to implement the features of an intelligent multi-agent system. This ideal agent system was to be capable exhibiting execution autonomy and semantic interoperability based on an intentional stance. The analysis drew upon many sources:

· The abstract notions of agency and the design features which flow from this.

· Commercial software engineering principles, especially object-oriented techniques, design methodologies, development tools and distributed computing models.

· Requirements drawn from a variety of applications domains.

· Existing FIPA specifications and implementations.

· Agent systems and services, include FIPA and non-FIPA designs.

· Commercially important software systems and services, such as Java, CORBA, DCOM, LDAP, X.500 and MQ Series.

The primary purpose of this work is to foster interoperability and reusability. To achieve this, it is necessary to identify the elements of the architecture that must be codified. Specifically, if two or more systems use different technologies to achieve some functional purpose, it is necessary to identify the common characteristics of the various approaches. This leads to the identification of architectural elements: abstract designs that can be formally related to every valid implementation.

In some areas, the identification of common abstractions is essential for successful interoperation. This is particularly true for agent-to-agent message transfer. The end-to-end support of a common agent communication language is at the core of FIPA's work. These essential elements which correspond to mandatory implementation specifications are here described as mandatory architectural elements. Other areas are less straightforward. Different software systems, particularly different types of commercial middleware systems, have specialized frameworks for software deployment, configuration, and management, and it is hard to find common principles. For example, security and identity remain tend to be highly dependent on implementation platforms. Such areas will eventually be the subjects of architectural specification, but not all systems will support them. These architectural elements are optional.

This document models the elements and their relationships. In Section 3, Architectural Overview there is an overview of the architecture. In Section 4, Agent and Agent Information Model there are diagrams in UML notation to describe the relationships between the elements In Section 5, Architectural Elements, each of the architectural elements is described.

2.6 Status of the Abstract Architecture

There are several steps in creating the abstract architecture:

1. Modelling of the abstract elements and their relationships.

2. Representing the other requirements on the architecture that can not be modelled abstractly.

3. Describing interoperability points.

This document represents the first item in the list. It is nearing completion, and ready for review.

The second step is satisfied by guidelines for instantiation. This document will not be written until at least one specification based on the abstract architecture has been created, as it is desirable to base such a document on actual implementation experience.

Interoperability points and conformance are defined by specific interoperability profiles. These profiles will be created as required during the creation of concrete specifications.

3 Architectural Overview

The FIPA architecture defines at an abstract level how two agents can locate and communicate with each other by registering themselves and exchanging messages. To do this, a set of architectural elements and their relationships are described. In this section the basic relationships between the elements of the FIPA agent system are described. In Section 4, Agent and Agent Information Model and Section 5, Architectural Elements, there are UML Models for the architecture, and a detailed description of each element, and its status within the architecture (such as whether it is mandatory or optional).

This section gives a relatively high level description of the notions of the architecture. It does not explain all of the aspects of the architecture. Use this material as an introduction, which can be combined with later sections to reach a fuller understandin g of the abstract architecture. There are some terms that are used in this document that should be described. Reserved terms are given in Table 1.

Word	Definition
Actual	Description of an element. The element relates to actual functionality in the system. Some elements that are explanatory are introduced because they provide a way to group or collect other entities. Some elements are actual, others explanatory Editor’s note: read all the other definitions and then re-read this one. It will make more sense after you read the rest
Can, May	In relationship descriptions, the word can or may is used to indicate this is an optional relationship. For example, a FIPA-service may provide an API invocation, but it is not required to do so.
Element (or architectural element)	A member of this abstract architecture. The word element is used here to indicate an item or entity that is part of the architecture, and participates in relationships with other elements of the architecture
Explanatory	An entity that may not appear in the system. Introduced for the purposes of modelling and clarity, rather than as a likely element of the system.
Functional element	Description of an element. If this element appears, it can be implemented either as a single software entity or can have its functionality embedded across multiple software entities. For example, a service which provides message transport could be implemented as single entity, or as a set of software that offers things such as a conversation factory, a communication handler, a message tracking and recording service, and so on. As long as this set answers the requirements defined for that element, and the element is defined as functional, then the implementation would be in accordance with the FIPA Architecture.
Mandatory	Description of an element or relationship. Required in all implementations of the FIPA Abstract Architecture
Must	In relationship descriptions, the word must is used to indicate this is a mandatory relationship. For example, an agent must have an FIPA-entity-name means that an agent is required to have an FIPA-entity-name.
Optional	Description of an element or relationship. May appear in any implementation of the FIPA Abstract Architecture, but is not required. Functionality that is common enough that it was included in model.
Realize, realization	To create a concrete specification or instantiation from the abstract architecture. For example, there may be a design to implement the abstract notion of directory-services in LDAP. This could also be said that there is a realization of directory-services.
Relationship	A connection between two elements in the architecture. The relationship between two elements is named (for example “is an instance of”, “sends message to”) and may have other attributes, such as whether it is required, optional, one-to-one, or one-to-many. The term as used in this document, is very much the way the term is used in UML or other system modelling techniques.
Single element	Description of an element or relationship. If this element appears, it will be implemented as an identifiable software entity (though it may be composed of many components). For example, an agent, an directory-entry, and a FIPA-message are all “single entities” in the system.

Table 1: Terminology

3.1 FIPA Entities, FIPA Services and Agents

One of the basic building blocks of the FIPA agent model is the FIPA-entity. FIPA-entities are named entities in the FIPA architecture. In this version of the Abstract Architecture, there is only one type of FIPA-entity: the agent. The abstraction FIPA-entity is introduced in order to provide a smooth transition to future versions of the architecture in which entities other than agents may be named.

Agents communicate by exchanging messages which represent speech acts, and which are encoded in an agent-communication-language.

FIPA-services provide support services for agents. This version of the abstract architecture defines two support services: directory-services and message-transport-services.

FIPA-services may be implemented either as agents or as software that is accessed via method invocation, using programming interfaces such as those provided in Java, C++, or IDL. An agent providing a FIPA-service is more constrained in its behaviour than a general purpose agent. In particular, these agents are required to preserve the semantics of the service. This implies that these agents do not have the degree of autonomy normally attributed to agents. They may not arbitrarily refuse to provide the service.

When implementing the Abstract Architecture, a FIPA-entity will not necessarily be mapped to a single feature of the implementation. It is an element that simply serves as a useful abstraction in describing the architecture.

3.2 Directory Services

The basic role of the directory-service function is to provide a place where FIPA-entities (agents) register directory-entries. Other agents can search the directory-entries to find agents with which they wish to interact.

The directory-entry consists of:

FIPA-entity-name	A unique name for the FIPA-entity (agent)
Locator	One or more transport-descriptors that describe the transport-type and the transport-specific-address to use to communicate with that agent
FIPA-entity-attributes	Optional descriptive attributes, such as what services the FIPA-entity offers, cost associated with using the FIPA-entity, restrictions on using the FIPA-entity, etc.. Represented as keyword and value pairs.

3.2.1 Starting an Agent

Agent A wishes to advertise itself as a provider of some service. It first binds itself to one or more transports. In some implementations it will delegate this task to the message-transport-service; in others it will handle the details of, for example, contacting an ORB, or registering with an RMI registry, or establishing itself as a listener on a message queue. As a result of these actions, the agent is addressable via one or more transports.

Having established one or more transport mechanisms, the agent must advertise itself. It does this by constructing an directory-entry and registering it with the directory-service. The directory-entry includes the agent’s name, its transport addressing information, and a set of properties that describe the service. A stock service might advertise itself as “agent-service com.dowjones.stockticker” and “ontology org.fipa.ontology.stockquote”.

Figure 3: An Agent Registers with a Directory Service

3.2.2 Finding an Agent

Agents can use the directory-service to locate agents with which to communicate. If agent B is seeking stock quotes, it may search for an agent that uses the ontology “org.fipa.ontology.stockquote”. If it does so, it will retrieve the directory-entry for agent A. It might also retrieve other directory-entries for agents that support that ontology.

Figure 4: Directory Query

Agent B can then examine the directory-entries to determine which agent best suits its needs. The directory-entries include the FIPA-entity-name, the locator, which contains information related to how to communicate with the agent, and other attributes.

3.2.3 Starting a FIPA Service

In some implementations, a FIPA-service is implemented as an agent. In such cases, the process of starting a FIPA-service is similar to starting an agent. When a FIPA-service starts, it may bind itself to a particular message-transport-service. It then registers with the directory-service, supplying a directory entry. This permits agents and FIPA-services to find the service through directory query.

In other implementations, a FIPA-service is accessed via a programmatic interface in a language such as Java, C++ or IDL. In these cases, the issues of starting, finding, and registering the service are not relevant.

Figure 5: Directory Query for a Service

3.3 Agent Messages

In FIPA agent systems agents communicate with one another, by sending messages. Here are some basic notions about agents messages, and their communications. There are two aspects of the messages passed between agents: the structure of the message itself, and the message when it is being prepared to be sent over a particular transport.

3.3.1 Message Structure

The basic message unit is the FIPA-message. A FIPA-message is written in an agent-communication-language, such as FIPA ACL. The content of the FIPA-message is expressed in a content-language, such as KIF or SL. The content-language may reference an ontology, which grounds the concepts being discussed in the content. The FIPA-messages also contains the sender and receiver names, expressed as FIPA-entity-names. FIPA-entity-names are unique names for an agent.

FIPA-messages can contain other FIPA-messages.

Figure 6: A FIPA-message

3.3.2 Message Transport

When a FIPA-message is sent it is transformed into a payload, and included in a transport-message. A payload is the message-encoding-representation appropriate for the transport. For example, if the message is going to be sent over a low bandwidth transport (such a wireless connection) a bit efficient representation may used instead of a string representation to allow more efficient transmission.

The transport-message is the payload plus the envelope. The envelope includes the sender and receiver transport-descriptions. The transport-descriptions contain the information about how to send the message (via what transport, to what address, with details about how to utilize the transport). The envelope can also contain additional information, such as the message-encoding-representation, data related security, and other realization specific data that needs be visible to the transport or recipient.

Figure 7: A FIPA-message Becomes a transport-message

In the above diagram, a FIPA-message is transformed into a payload suitable transport over the selected message-transport. An appropriate envelope is created that has sender and receiver information that uses the transport-description data appropriate to the transport selected. There may be additional envelope data included as well. The combination of the payload and envelope is a transport-message.

3.4 Agents Send Messages to Other Agents

In FIPA agent systems agents communicate with one another. Here are some basic notions about agents, and their communications.

Each agent has an FIPA-entity-name. This FIPA-entity-name is unique and unchangeable. Each agent also has one or more transport-descriptions, which are used by other agents to send a transport-message. Each transport-description correlates to a particular form of message transport, such as IIOP, SMTP, or HTTP. A transport is a mechanism for transferring messages. A transport-message is a message that sent from one agent to another in a format (or encoding) that is appropriate to the transport being used. A set of transport-descriptions can be held in an locator.

For example, there may be an agent with the FIPA-entity-name “ABC”. This agent is addressable through two different transports, HTTP, and an SMTP e-mail address. Therefore, agent has two transport-descriptions, which are held in the locator. The transport descriptions are as follows.

Directory entry for ABC

FIPA-entity-name: ABC

Locator:

Transport-type	Transport-specific-address	Transport-specific-property
HTTP	http://www.whiz.net/abc	(none)
SMTP	Abc@lowcal.whiz.net	(none)

FIPA-entity-attributes: Attrib-1: yes

Attrib-2: yellow

Language: French, German, English

Preferred negotiation: contract-net

Note: in this example, the FIPA-entity-name is used as part of the transport-descriptions. This is just to make these examples easier to read. There is no requirement to do this.

Another agent can communicate with agent “ABC” using either transport-description, and know that which agent it is communicating with. In fact, the second agent can even change transports and can continue its communication. Because the second agent knows the FIPA-entity-name, it can retain any reasoning it may be doing about the other agent, without loss of continuity.

Figure 8: Communicating Using Any Transport

In the above diagram, Agent 1234 can communicate with Agent ABC using either an SMTP transport or an HTTP transport. In either case, if Agent 1234 is doing any reasoning about agents that it communicates with, it can use the FIPA-entity-name “ABC” to record which agent it is communicating with, rather than the transport description. Thus, if it changes transports, it would still have continuity of reasoning.

Here’s what the messages on the two different transports might look like:

Figure 9: Two transport-messages to the Same Agent

In the diagram above, the transport-description is different, depending on the transport that is going to be used. Similarly, the message-encoding of the payload may also be different. However, the FIPA-entity-names remain consistent across the two message representations.

3.5 Providing Message Validity and Encryption

There are many aspects of security that can be provided in agent systems. See Section 10, Informative Annex D: Goals for Security and Identity Abstractions for full discussion of possible security features. In this abstract architecture, there is a simple form of security: message validity and message encryption. In message validity, messages can be sent in such a way that it possible to determine the message has not been modified during transmission. In message encryption, a message is sent in such a way that the message itself is encrypted, so that the message content can not be read by others.

In this abstract architecture, these are accommodated through message-encoding-representations and the use of additional attributes in the envelope. For example, as the payload is transformed, one of the transforms might be to a digitally encrypted set of data, using a public key and particular encryption algorithm. Additional parameters are added to the envelope to indicate these characteristics.

Therefore, the creation message validation and encryption is treated like any other type message transformation.

Figure 10: Encrypting a Message Payload

In the above diagram, the payload is encrypted, and additional attributes are added to the envelope to support the encryption. Those attributes must not be encrypted, or the receiving party would not be able to use them.

3.6 Providing Interoperability

There are several ways in which the abstract architecture intends to provide interoperability. The first is transport interoperability. The second is message representation interoperability.

To provide interoperability, there are certain elements that must be included throughout the architecture to permit multiple implementations. For example, earlier, it was described that an agent has both an FIPA-entity-name and a locator. The locator contains transport-descriptions, each of which contains information necessary for a particular transport to send a message to the corresponding agent. The semantics of agent communication require that an agent’s name be preserved throughout its lifetime, regardless of what transports may be used to communicate with it.

4 Agent and Agent Information Model

This section of the abstract architecture provides a series of UML class diagrams for key elements of the abstract architecture. In Section 5, Architectural Elements you can get a textual description of these elements and other aspects of the relationships between them. In order to make these diagrams more readable, certain elements are included in multiple diagrams.

Comment on notation: In UML, the notion of a 1 to many or 0 to many relationship is often noted as “1…*” or “0…*”. The tool that was used to generate these diagrams used the convention “1…n” and “0…n” to express the concept of many. The diagrams use the “n” style notation.

4.1 Agent Relationships

The following UML diagram outlines the basic relationships between an agent and other key elements of the FIPA abstract architecture. In other diagrams in this section you can get details on the locator, and the transport-message.

Figure 11: UML - Basic Agent Relationships

4.2 Transport Message Relationships

Transport-message is the object conveyed from agent to agent. It contains the transport-description for the sender and receiver or receivers, together with a payload containing the FIPA-message.

Figure 12: UML - Transport Message Relationships

4.3 Directory Entry Relationships

The directory-entry contains the FIPA-entity-name, locator and FIPA-entity-attributes. The locator provides ways to address messages to an agent. It is also used in modifying transport requests.

Figure 13: UML - Directory-entry and locator Relationships

4.4 FIPA Message Elements

This diagram shows the elements in a FIPA-message. A FIPA-message is contained in a transport-message when messages are sent.

Figure 14: UML - FIPA-message Elements

4.5 Message Transport Elements

The message-transport-service is an option service that can send transport-messages between agents. These elements may participate in other relationships as well.

Figure 15: UML - Message Transport Entities

4.6 FIPA Entity Relationships

The following UML diagram describes the FIPA-entity relationships. A FIPA-entity is an addressable software component that delivers some of functionality of the abstract architecture.

Figure 16: UML - FIPA Entity Relationships

5 Architectural Elements

The architectural elements are defined here. For each element, the semantics are described informally. Then the relationships between the element and other elements are defined.

5.1 Introduction

5.1.1 Classification of Elements

The word element is used here to indicate an item or entity that is part of the architecture, and participates in relationships with other elements of the architecture.

The architectural elements are classified in three ways. Firstly, they are classified as mandatory or optional. Mandatory elements must appear in all instantiations of the FIPA abstract architecture. They describe the fundamental services, such as agent registration and communications. These elements are the core aspects of the architecture. Optional elements are not mandatory; they represent architecturally useful features that may be shared by some, but not all, concrete instantiations. The abstract architecture only defines those optional elements which are highly likely to occur in multiple instantiations of the architecture.

The second classification is whether elements are actual or explanatory. Actual elements must be created as a software that meets the required functionality. They may be either mandatory or optional. Explanatory elements exist simply as useful constructs in the system, such as gathering together similar elements. For example, there is an explanatory entity, FIPA-service, which contains attributes that all FIPA-services should have. However, there is no independent entity, FIPA-service. Instead, there are various services, such as message-transport-service and directory-service, that inherit characteristics from that element.

The third classification is whether the element must be implemented as a single software entity, or if the functionality can be spread across multiple entities. Note that a single software entity may be in turn composed of several components, but functionality there is a mechanism that makes that entity addressable (for example, it can accept messages, has an API, or something similar). These are said to be single or functional elements

Type	Definition
Mandatory	Required in any implementation of the FIPA Abstract Architecture
Optional	May appear in any implementation of the FIPA Abstract Architecture. Functionality that is common enough that it was included in model
Actual	Relates to actual functionality in the system. Some elements that are explanatory are introduced because they provide a way to group or collect other entities
Explanatory	An entity that may not appear in the system. Introduced for the purposes of modelling and clarity, rather than as a likely element of the system.
Single Entity	If this element appears, it will be implemented as an identifiable software entity (though it may be composed of many components). For example, an agent, an directory-entries, and a FIPA-message are all “single entities” in the system.
Functional	If this element appears, it can be implemented either as a single software entity or can have its functionality embedded across multiple software entities. For example, a service which provides message transport could be implemented as single entity, or as a set of software that offers things such as a conversation factory, a communication handler, a message tracking and recording service, and so on. As long as this set answers the requirements defined for that element, and the element is defined as functional, then the implementation would be in accordance with the FIPA Architecture.

Table 2: Categorization of Elements

5.1.2 Key-Value Tuples

Many of the elements of the abstract architecture are defined to be key-value tuples, or KVTs. The concept of a KVT is central to the notion of architectural extensibility, and so it is discussed in some length here.

A KVT consists of an unordered set of key-value pairs. Each key-value pair has two elements, as the term implies. The first element, the key, is a token drawn from an administered name space. All keys defined by the Abstract Architecture are drawn from a name space managed by FIPA. This makes it possible for concrete architectures, or individual implementations, to add new architectural elements in a manner which is guaranteed not to conflict with the Abstract Architecture.

The second element of the key-value pair is the value. The type of value depends on the key; in some concrete specifications this type may correspond to a type in some programming language or object model.

5.1.3 Services

A FIPA-service is defined in terms of a set of actions which it supports. Each action defines an interaction between the service and the FIPA-entity which is using the service. The semantics of these actions are described informally, to minimize assumptions about how they might be reified in a concrete specification.

5.1.4 Format of Element Description

The architectural elements are described below. The format of the description is:

· Summary. A summary of the element.

· Relationship to other elements. A complete description of the relationship of this element to the other architectural elements.

· Relationship to concrete specification. Whether this is a mandatory or optional element, and whether the element is actual or explanatory in a concrete instantiation. There may be additional comments related to making this element concrete.

· Description. Additional description and context for the element, along with explanatory notes and examples.

5.1.5 Abstract Elements

Element	Description	Mandatory Optional	Actual Explanatory	Single or Functional Element
Action-status	An indication delivered by a service indicating the success or failure of an action	Mandatory	Actual	Functional
Agent	Computational process that implements the autonomous, communicating functionality of an application	Mandatory	Actual	Single
Agent-communication-language	Language with a precisely defined syntax semantics and pragmatics, which is the basis of communication between independently designed and developed agents.	Mandatory	Actual	Functional
Content	Content is that part of a communicative act that represents the domain dependent component of the communication.	Mandatory	Actual	?
Content-language	A language used to express the content of a communication between agents.	Mandatory	Actual	Single
Directory-entry	A composite entity containing the name, locator, and FIPA-entity-attributes of a FIPA-entity	Mandatory	Actual	Single
Directory-service	A FIPA-service providing a shared information repository in which directory-entries may be stored and queried	Mandatory	Actual	Single
Envelope	That part of a transport-message which contains information about how to send the message to the intended recipients. May also include additional information about the message encoding, encryption, and so on.	Mandatory	Actual	Single
Explanation	An encoding of the reason for a particular action-status.	Optional	Actual	Single
FIPA-entity	A FIPA-entity is a software component that delivers a portion of the functionality of the abstract architecture.	Optional	Explanatory	N/A
FIPA-entity-attributes	A set of properties associated with a FIPA-entity by inclusion in its directory-entry	Optional	Actual	Single
FIPA-entity-name	An opaque, non-forgeable token which uniquely identifies a FIPA-entity (agent)	Mandatory	Actual	Single
FIPA-message	A unit of individual communication between two agents. The FIPA-Message is expressed in agent-communication-language, and is encoded in a particular message-transport-encoding.	Mandatory	Actual	Single
FIPA-service	A service provided for agents and other FIPA-services	Optional	Explanatory	N/A
Locator	A locator consists of the set of transport-descriptions which can be used to communicate with a FIPA-entity (agent)	Mandatory	Actual	Single
Message-encoding-representation	A way of representing an abstract syntax in a particular concrete syntax. Examples of possible representations are XML, FIPA strings, and serialized Java objects.	Mandatory	Actual	Functional
Message-transport-service	A FIPA-service that supports the sending and receiving of transport-messages between agents.	Optional	Actual	Functional
Ontology	A set of symbols together with an associated interpretation that may be shared by a community of agents or software. An ontology includes a vocabulary of symbols referring to objects in the subject domain, as well as symbols referring to relationships that may be evident in the domain	Mandatory	Actual	Functional
Payload	A FIPA-message encoded in a manner suitable for inclusion in a transport-message.	Mandatory	Actual	Single
Transport	A transport is a particular data delivery service which is supported by a message-transport-service	Mandatory	Actual	Functional
Transport-description	A transport-description is a self describing structure containing a transport-type, a transport-specific-address and zero or more transport-specific-properties	Mandatory	Actual	Single
Transport-message	The object conveyed from agent to agent. It contains the transport-description for the sender and receiver or receivers, together with a payload containing the FIPA-message.	Mandatory	Actual	Single
Transport-specific-property	A transport-specific-property is a property associated with a transport-type.	Optional	Actual	Single
Transport-type	A transport-type describes the type of transport which is associated with an transport-specific-address.	Mandatory	Actual	Single

Table 3: Abstract Elements

5.2 Agent

5.2.1 Summary

An agent is a computational process that implements the autonomous, communicating functionality of an application. Typically, agents communicate using an Agent Communication Language.

5.2.2 Relationships to Other Elements

Agent is an instance of FIPA-entity

Agent may have an locator, which lists the transport-descriptions for that agent

Agent may be sent messages via a transport-description, using the transport corresponding to the transport-description

Agent may send a transport-message to one or more agents

Agent may register with one or more directory-services

Agent may have an directory-entry, which is registered with a directory-service

Agent may modify its directory-entry as registered by a directory-service

Agent may delete its directory-entry from a directory-service.

Agent may query for an directory-entry registered within a directory-service

5.2.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.2.4 Description

In a concrete instantiation of the abstract architecture, an agent may be realized in a variety of ways: as a JavaÔ component, a COM object, a self-contained Lisp program, or a TCL script. It may execute as a native process on some physical computer under an operating system, or be supported by an interpreter such as a Java Virtual Machine or a TCL system. The relationship between the agent, its computational context, is specified by the agent lifecycle. The abstract architecture does not address the lifecycle of agents, because of it is handled so differently in different computational environments. Realizations of the abstract architecture must address these issues.

Since an agent is a FIPA-entity, it inherits the attributes of a FIPA-entity, in particular a FIPA-entity-name, which identifies the agent uniquely

5.3 Agent Communication Language

5.3.1 Summary

An agent-communication-language (ACL) is a language in which communicative acts can be expressed. The FIPA architecture is defined in terms of an Abstract ACL, or AACL. Any abstract language must have a written form, however it may be that no deployed systems and ACLs use that written notation. Instead, it is required that any given ACL can be seen as a realization of the abstract ACL.

An abstract syntax is a syntax in which the underlying operators and objects of a language are exposed; together with a precise semantics for those entities. When specifying an abstract syntax it inevitably becomes “concrete” by virtue of the fact that it has been written down as characters and tokens. However, generally, written abstract syntaxes are still simpler and have far fewer features than their concrete cousins. The primary role of an abstract syntax is to facilitate focussing on the meaning of constructs in the language at the possible expense of legibility and convenience of expression.

5.3.2 Relationships to Other Elements

FIPA-message is written in an agent-communication-language.

5.3.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Functional

5.3.4 Description

???

5.4 Content

5.4.1 Summary

Content is that part of a communicative act that represents the component of the communication that refers to a domain or topic area. Note that "the content of a message" does not refer to "everything within the message, including the delimiters", as it does in some languages, but rather specifically to the domain specific component. In the ACL semantic model, a content expression may be composed from propositions, actions or terms.

5.4.2 Relationships to Other Elements

Content is expressed in a content-language

Content may reference one or more ontologies

Content is part of a FIPA-message

5.4.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.5 Content Language

A content-language is a language used to express the content of a communication between agents. FIPA allows considerable flexibility in the choice and form of a content language; however, content languages are required to be able to represent propositions, actions and terms (names of individual entities) if they are to make full use of the standard FIPA performatives.

5.5.1 Relationships to Other Elements

Content is expressed in a content-language

FIPA-SL is an example of a content-language

FIPA-RDF is an example of a content-language

FIPA-KIF is an example of a content-language

FIPA-CCL is an example of a content-language

5.5.2 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.5.3 Description

The FIPA 2000 content languages are described in detail in [FIPA00007].

5.6 Directory Entry

5.6.1 Summary

An directory-entry is a key-value tuple consisting of the FIPA-entity-name, a locator, and zero or more FIPA-entity-attributes. A directory-entry refers to an agent; in some implementations this agent will provide a FIPA-service.

5.6.2 Relationships to Other Elements

Directory-entry contains the FIPA-entity-name of the FIPA-entity to which it refers

Directory-entry contains one locator of the FIPA-entity to which it refers. The locator contains one or more transport-descriptions

Directory-entry is available from a directory-service

Directory-entry contains FIPA-entity-attributes

5.6.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.6.4 Description

Different realizations that use a common directory-service, are strongly encouraged to adopt a common schema for storing directory-entries. (This in turn implies the use of a common representation for locators, transport-descriptions, FIPA-entity-names, and so forth.)

Agents are not required to publish an directory-entry. It is possible for agents to communicate with agents that have provided an transport-description through a private mechanism. For example, an agent involved in a negotiation may receive a transport-description directly from the party with which it is are negotiating. This falls outside the scope of the using the directory-services mechanisms.

5.7 Directory Service

5.7.1 Summary

A directory-service is a shared information repository in which agents may publish their directory-entries and in which they may search for directory-entries of interest.

5.7.2 Relationships to Other Elements

Agent may register its directory-entry with a directory-service.

Agent may modify its directory-entry as registered by a directory-service.

Agent may delete its directory-entry from a directory-service.

Agent may search for an directory-entry registered within a directory-service.

A directory-service must accept request for registering, de-registering, deletion, and modification of agent descriptions.

A directory-service must accept requests for searching.

A directory-service is a FIPA-entity.

5.7.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.7.4 Actions

A directory-service supports the following actions.

5.7.4.1 Register

An agent may register a directory-entry with a directory-service. The semantics of this action are as follows:

The agent provides a directory-entry which is to be registered. In initiating the action, the agent may control the scope of the action. Different reifications may handle this in different ways. The action may be addressed to a particular instance of a directory-service, or the action may be qualified with some kind of scope parameter.

If the action is successful, the directory-service will return an action-status indicating success. Following a successful register, the directory-service will support legal modify, delete, and query actions with respect to the registered directory-entry.

If the action is unsuccessful, the directory-service will return an action-status indicating failure, together with an explanation. The range of possible explanations is, in general, specific to a particular reification. However a conforming reification must, where appropriate, distinguish between the following explanations:

· Duplicate – the new entry “clashed” with some existing directory-entry. Normally this would only occur if an existing directory-entry had the same FIPA-entity-name, but specific reifications may enforce additional requirements.

· Access – the agent making the request is not authorized to perform the specified action.

· Invalid – the directory-entry is invalid in some way.

5.7.4.2 Modify

An agent may modify a directory-entry which has been registered with a directory-service. The semantics of this action are as follows:

The agent provides a directory-entry which contains the same FIPA-entity-name as the entry which is to be modified. In initiating the action, the agent may control the scope of the action. Different reifications may handle this in different ways. The action may be addressed to a particular instance of a directory-service, or the action may be qualified with some kind of scope parameter.

The directory service verifies that the argument is a valid directory-entry (Dn). It then searches for a registered directory-entry with the same FIPA-entity-name (Dx). If it does not find one, the action fails. Otherwise it modifies Dx by examining each key-value pair in Dn. If the value is non-null, the pair is added to Dx, replacing any existing pair with the same key. If the value is null, any existing pair in Dx with the same key is removed from Dx.

If the action is successful, the directory-service will return an action-status indicating success, together with a directory-entry corresponding to the new contents of the registered entry. Following a successful register, the directory-service will support legal modify, delete, and query actions with respect to the modified directory-entry.

· Not-found – the new entry did not match any existing directory-entry. This would only occur if no existing directory-entry had the same FIPA-entity-name.

· Access – the agent making the request is not authorized to perform the specified action.

· Invalid – the new directory-entry is invalid in some way.

5.7.4.3 Delete

An agent may delete a directory-entry from a directory-service. The semantics of this action are as follows:

The agent provides a directory-entry which has the same FIPA-entity-name as that which is to be deleted. (The rest of the directory-entry is not significant.) In initiating the action, the agent may control the scope of the action. Different reifications may handle this in different ways. The action may be addressed to a particular instance of a directory-service, or the action may be qualified with some kind of scope parameter.

If the action is successful, the directory-service will return an action-status indicating success. Following a successful delete, the directory-service will no longer support modify, delete, and query actions with respect to the registered directory-entry.

· Not-found – the new entry did not match any existing directory-entry. This would only occur if no existing directory-entry had the same FIPA-entity-name.

· Access – the agent making the request is not authorized to perform the specified action.

· Invalid – the directory-entry is invalid in some way.

5.7.4.4 Query

An agent may query a directory-service to locate directory-entries of interest. The semantics of this action are as follows:

The agent provides a directory-entry which is to be treated as a search pattern. In initiating the action, the agent may control the scope of the action. Different reifications may handle this in different ways. The action may be addressed to a particular instance of a directory-service, or the action may be qualified with some kind of scope parameter.

The directory service verifies that the argument is a valid directory-entry (Dp). It then searches for registered directory-entries which satisfy Dp. A registered entry, Dx, satisfies Dp if for each key-value pair in Dp there is a pair in Dx with the same key and a matching value. The semantics of “matching” are likely to be reification-dependent; at a minimum, there should be support for matching on the same value and matching on any value.

If the action is successful, the directory-service will return an action-status indicating success, together with a set of directory-entries which satisfy the search pattern. The mechanism by which multiple entries are returned, and whether or not an agent may limit or terminate the delivery of results, is not defined in the abstract architecture.

· Not-found – the search pattern did not match any existing directory-entry.

· Access – the agent making the request is not authorized to perform the specified action.

· Invalid – the directory-entry is invalid in some way.

5.7.5 Description

A directory-service may be implemented in a variety of ways, using a general-purpose scheme such as X.500 or some private agent-specific mechanism. Typically a directory-service uses some hierarchical or federated scheme to support scalability. A concrete implementation may support such mechanisms automatically, or may require each agent to manage its own directory usage.

Different realizations that are based on the same underlying mechanism are strongly encouraged to adopt a common schema for storing directory-entries. This in turn implies the use of a common representation for destinations, names, and so forth. For example, if there are multiple implementations for directory service in LDAP, it would be use for all of the implementation to interoperate because they are using the same schemas. Similarly, if there were multiple implementations in NIS, they would need the same NIS data representation to interoperate.

The directory-service described here does not have the full flexibility found in the directory-facilitator (DF) of existing FIPA specifications. In practice, implementing the search capabilities of the existing DF is not feasible with most directory systems (i.e. LDAP, X.500, NIS). There seems to be a need for a Lookup Service, which is here called the directory-service, which allows an agent to identify and get the transport-description for another agent, as well as a more complex search system, which can resolve complex searches. The former system, which supports a single level of search on attributes, is the directory service. The latter might be implemented as a broker, and might be implemented in systems that allow for arbitrary complexity and nesting such as Prolog or LISP. This division of functionality reflects the experience of many implementations, where there is a “quick” lookup service and a more robust, but slower complex search service.

5.8 Envelope

5.8.1 Summary

An envelope is a key-value tuple which contains message delivery and encoding information. It is included in the transport-message, and includes elements such as the sender and receivers transport-descriptions. It also contains the message encoding representation for the FIPA-message included in the message. It optionally contains other message information, such as validation and security data, or additional routing date.

5.8.2 Relationship to Other Elements

Envelope contains transport-descriptions

Envelope optionally contains validity data (such as keys for message validation)

Envelope optionally contains security data (such as keys for message encryption or decryption)

Envelope optionally contains routing data)

Envelope contains message-encoding-representation for the payload being transported

Envelope is contained in transport-message.

5.8.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Actual	Single

5.8.4 Description

In the realization of the envelope data, the realization can specify envelope elements that are useful in the particular realization. These can include specialized routing data, security related data, or other data which can assist in the proper handling of the encoded FIPA-message.

5.9 FIPA Entity

5.9.1 Summary

A FIPA-entity is a software component that delivers a portion of the functionality of the abstract architecture. There is one types of FIPA-entity: agents.

Note: In a previous version of this document, FIPA-services were also considered to by FIPA-entities. However the requirement that a FIPA-entity be registered in a directory-service and be addressable in terms of its transport-descriptions means that such an abstract relationship is not generally applicable.

5.9.2 Relationships to Other Elements

FIPA-entity has a FIPA-entity-name.

FIPA-entity is registered in the directory-service, using a directory-entry.

FIPA-entity is addressable by the mechanisms described in its transport-descriptions in its directory-entry.

FIPA-entity may have FIPA-entity-attributes

5.9.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Mandatory	Explanatory	N/A

5.9.4 Description

FIPA-entity is an abstraction introduced to allow for a future generalization. In this version of the architecture, a FIPA-entity is essentially an agent.

5.10 FIPA Entity Attributes

5.10.1 Summary

The FIPA-entity-attributes are optional attributes that are part of the directory-entry for a FIPA-entity. They are represented as a key/value pairs within the key-value tuple that makes up the directory-entry. The purpose of the attributes is to allow searching for directory-entries that match FIPA-entities of interest.

5.10.2 Relationships to Other Elements

A directory-entry may have zero or more FIPA-entity-attributes

FIPA-entity-attributes describe aspects of a FIPA-entity

5.10.3 Relationship to Concrete Specification

Mandatory/Optional	Actual/Explanatory	Single/Functional
Optional	Actual	Single

5.10.4 Detailed Description

When a FIPA-entity registers a directory-entry, the directory-entry may optionally contain key and value pairs that offer additional description of the FIPA-entity. The values might include information about costs of using the agent or FIPA-service, features available, ontologies understood, or any other data that FIPA-entities deem useful, or names that the service is commonly known by. Other FIPA-entities can then search in the directory service for FIPA-entities that meet particular requirements.

In practice, when defining realizations of this abstract architecture, domain specific specifications should existing about the FIPA-entity-attributes that are going to be presented, to allow for interoperation.

Directory-entry must contain the FIPA-entity-name of the FIPA-entity to which it refers

Document title	FIPA Abstract Architecture Specification
Document number	PC00001C	Document source	FIPA TC Architecture
Document status	Preliminary	Date of this status	2000/08/03
Supersedes	None
Contact	arch@fipa.org
Change history
2000/02/15	While this is the first version of this document published under the new document control system, it an update from earlier drafts of this document. The changes are Agent-directory-entry becomes directory-entry, Agent-name becomes FIPA-Entity-name, added Transform-service for gateway support, new entity FIPA-Entity-Attributes and made Agent-platform a FIPA-Service; Remove references to future work. These will be published as soon as the FAB assigns a number for that document.
2000/04/04	Removed all agent-platform constructs; Cleaned up various hanging references; Added service-references.
2000/07/31	This revision restores the definitions of the actions supported by the directory and communication services. The Transform-service material is withdrawn, since it seems premature (and possibly wrong) to assume that gateways are explicitly addressable entities.
2000/08/03	Editorial changes for consistency with FIPA 2000 specifications