developing multi-agent system with jade (3)

                                      Payload                     message

                                      Message                     Message
                                                                 parameters

                                                                 Message
                                       Content
                                                                 content




                                  Figure 2.6   FIPA message structure


under restriction of authorization by the AMS. The life of an agent with an AP terminates with its
deregistration from the AMS. After deregistration, the AID of that agent can be removed by the
directory and can be made available to other agents who should request it. Agent descriptions can
also be searched for within the AMS, and the AMS is the custodian of the AP description that can
be retrieved by requesting the action get-description.
   The AMS can request that an agent performs a specic management function, such as to terminate
its execution, and has the authority to enforce the operation if the request is ignored. Only a single
AMS can exist in each AP and if the AP spans multiple machines, the AMS is the authority across
all those machines.

Message Transport Service (MTS): The MTS is a service provided by an AP to transport FIPA-
ACL messages between agents on any given AP and between agents on different APs. Messages
are providing a transport envelope that comprises the set of parameters detailing, for example, to
whom the message is to be sent. The general structure of a FIPA-compliant message is depicted in
Figure 2.6.


2.2.2.4 Abstract Architecture

In addition to agent communication and agent management, between 2000 and 2002 an abstract
agent architecture was created and standardized as a means to circumvent the impact on platform
implementations of incremental revision to core specications. This was achieved by abstracting the
key aspects of the most critical mechanisms such as message transport and directory services into
a unied specication. The overall goal of the approach is to permit the creation of systems that
seamlessly integrate within their specic computing environment while interoperating with agent
systems residing in separate environments.
   Agent systems built according to the earlier FIPA  97 and   98 specications can interoperate
with agent systems built according to the Abstract Architecture through transport gateways with
some limitations. The FIPA2000 architecture is a closer match and allows full interoperability via
gateways. Because the Abstract Architecture permits the creation of multiple concrete realizations,
it also provides mechanisms to permit them to interoperate including gateway transformations for
both transport and encodings.
   The Architecture species the ACL message structure, message transport, agent directory services
and service directory services as mandatory. Other aspects are considered optional.


2.2.3 A SELECTION OF KEY FIPA SPECIFICATIONS

To date FIPA has produced 25 standard specications, with a further 14 remaining at the experi-
mental stage, and 3 at the preliminary stage. The complete list of specications is provided at the

The Foundation for Intelligent, Physical Agents (FIPA)                                              17



end of the bibliography. In this section we highlight a selection of the key standard specications
in a logical, rather than numerical, order.


2.2.3.1 FIPA Abstract Architecture Specication (SC00001)

As discussed previously, the FIPA Abstract Architecture exists to provide a common, unchanging
point of reference for FIPA-compliant implementations that captures the most critical and salient
features of agent systems while providing some isolation from small iterative changes that may
impact on the underlying FIPA2000 specication set.
  The Architecture denes at an abstract level how two agents can locate and communicate with
each other by registering themselves and exchanging messages. Agents communicate by exchanging
messages which represent speech acts and which are encoded in an agent communication language.
Services provide support services for agents and include the standard services of agent directory
services, message transport services and service directory services. The Architecture is explicitly
neutral about how services are presented, stating that they may be implemented either as agents
or as software that is accessed via method invocation using programming. An agent providing a
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.
  Some of the most important items specied by the FIPA Abstract Architecture are:


Agent messages are the fundamental form of communication between agents. The structure of a
  message is a set of key values written in FIPA-ACL. The content of the message is expressed
  in a content language, such as FIPA-SL or FIPA-KIF, and content expressions can be grounded
  by referenced ontologies. Messages can recursively contain other messages within their content
  and must contain key parameters such as the sender and receiver names. Prior to transmission
  messages must be encoded into a payload and a message transport envelope for the particular
  protocol in use.
A message transport service is dened as the means to send and receive transport messages
  between agents. This is considered a mandatory element of FIPA agent systems.
An agent directory service is dened as a shared information repository in which agents may
  publish their agent directory entries and in which they may search for agent directory entries of
  interest. This is considered a mandatory element of FIPA agent systems.
A service directory service is dened as a shared repository in which agents and services can
  discover services. Services include, for example, message transport services, agent directory
  services, gateway services and message buffering. A service directory service can also be used to
  store the service descriptions of application-oriented services, such as commercial and business-
  oriented services. This is considered a mandatory element of FIPA agent systems.


2.2.3.2 FIPA-ACL Message Structure Specication (SC00061)

A FIPA-ACL message contains a set of one or more message parameters. Precisely which parameters
are needed for effective agent communication will vary according to the situation; the only parameter
that is mandatory in all ACL messages is the performative, although it is expected that most
ACL messages will also contain sender, receiver and content parameters. The FIPA-ACL message
parameters are shown in Table 2.1 without regard to specic encodings. FIPA denes three specic
encodings: String (EBNF notation), XML and Bit-Efcient.
  User-dened message parameters may also be included by preceding the parameter name with
the string   X-  .

18                                                                             Agent Technology Overview



Table 2.1   ACL message parameters


Parameter                                                      Description


Performative                 Type of the communicative act of the message
sender                       Identity of the sender of the message
receiver                     Identity of the intended recipients of the message
reply-to                     Which agent to direct subsequent messages to within a conversation thread
content                      Content of the message
language                     Language in which the content parameter is expressed
encoding                     Specic encoding of the message content
ontology                     Reference to an ontology to give meaning to symbols in the message content
protocol                     Interaction protocol used to structure a conversation
conversation-id              Unique identity of a conversation thread
reply-with                   An expression to be used by a responding agent to identify the message
in-reply-to                  Reference to an earlier action to which the message is a reply
reply-by                     A time/date indicating by when a reply should be received



This is a simple example of a FIPA-ACL message with a request performative:


(request
      :sender (agent-identifier :name [e-mail])
      :receiver (agent-identifier :name [e-mail])
     ntology travel-assistant
      :language FIPA-SL
      :protocol fipa-request
      :content
         ""((action
              (agent-identifier :name [e-mail])
               (book-hotel :arrival 15/10/2006
                                 :departure 05/07/2002 ... )
         ))""
)




2.2.3.3 FIPA-ACL Communicative Act Library Specication (SC00037)

The FIPA-ACL denes communication in terms of a function or action, called the communicative
act or CA, performed by the act of communicating. This standard provides a library of all the CAs
specied by FIPA. The set of FIPA standardized CAs are listed in Table 2.2.
  In general CAs are based on speech act theory (Searle, 1969) which denes the functions of sim-
ply specied actions. These functions are detailed in the FIPA CA Library specication (FIPA37),
but examples include interrogatives which query for information, exercitives which ask for an
action to be performed, referentials which share assertions about the world environment, phatics
which establish, prolong or interrupt communication, paralinguistics which relate a message to
other messages, and expressives which express attitudes, intentions or beliefs.
  A message can perform several functions at the same time. For example the FIPA CA Agree
is described as the action of agreeing to perform some action possibly in the future. This is
phatic in terms of agreeing to proceed and is paralinguistic in terms of referring to another FIPA
CA Chence, Agree is principally classied as a phatic function. All FIPA CAs inherently support
the expressive function as a secondary function as they are dened in a modal logic form that

The Foundation for Intelligent, Physical Agents (FIPA)                                                        19



Table 2.2  The FIPA communicative acts


FIPA communicative act                                             Description


Accept Proposal                   The action of accepting a previously submitted proposal to perform an
                                   action
Agree                             The action of agreeing to perform some action, possibly in the future
Cancel                            The action of one agent informing another agent that the rst agent no
                                   longer has the intention that the second agent performs some action
Call for Proposal                 The action of calling for proposals to perform a given action
Confirm                           The sender informs the receiver that a given proposition is true, where the
                                   receiver is known to be uncertain about the proposition
Disconfirm                        The sender informs the receiver that a given proposition is false, where the
                                   receiver is known to believe, or believe it likely that, the proposition is
                                   true
Failure                           The action of telling another agent that an action was attempted but the
                                   attempt failed
Inform                            The sender informs the receiver that a given proposition is true
Inform If                         A macro action for the agent of the action to inform the recipient whether
                                   or not a proposition is true
Inform Ref                        A macro action allowing the sender to inform the receiver of some object
                                   believed by the sender to correspond to a specic descriptor, for example
                                   a name
Not Understood                    The sender of the act (for example, i) informs the receiver (for example, j)
                                   that it perceived that j performed some action, but that i did not
                                   understand what j just did. A particular common case is that i tells j that
                                   i did not understand the message that j has just sent to i
Propagate                         The sender intends that the receiver treat the embedded message as sent
                                   directly to the receiver, and wants the receiver to identify the agents
                                   denoted by the given descriptor and send the received propagate
                                   message to them
Propose                           The action of submitting a proposal to perform a certain action, given
                                   certain preconditions
Proxy                             The sender wants the receiver to select target agents denoted by a given
                                   description and to send an embedded message to them
Query If                          The action of asking another agent whether or not a given proposition is true
Query Ref                         The action of asking another agent for the object referred to by a referential
                                   expression
Refuse                            The action of refusing to perform a given action, and explaining the reason
                                   for the refusal
Reject Proposal                   The action of rejecting a proposal to perform some action during a
                                   negotiation
Request                           The sender requests the receiver to perform some action
                                 One important class of uses of the request act is to request the receiver to
                                 perform another communicative act
Request When                      The sender wants the receiver to perform some action when some given
                                   proposition becomes true
Request Whenever                  The sender wants the receiver to perform some action as soon as some
                                   proposition becomes true and thereafter each time the proposition
                                   becomes true again
Subscribe                         The act of requesting a persistent intention to notify the sender of the value
                                   of a reference, and to notify again whenever the object identied by the
                                   reference changes

20                                                                           Agent Technology Overview



expresses attitudes, intentions and beliefs. Additionally, all FIPA CAs can refer to concepts from
an explicit conceptualization dened by, for example, an ontology.


2.2.3.4 FIPA-SL Content Language Specication (SC00008)

The FIPA Semantic Language (SL) is used to dene the intentional semantics for the FIPA CAs as
a logic of mental attitudes and actions, formalized in a rst-order modal language with identity. SL
is dened in terms of a string expression grammar, dened to be a sub-grammar of the more general
s-expression syntax. Content expressions are dened in terms of action expressions or propositions.
These in turn are represented as well-formed formulas (wff) consisting of terms (constant, set,
sequence, functional term, action expression) and constants (numerical constants, string, datetime).
A well-formed formula is constructed from an atomic formula by applying construction opera-
tors or logical connective operators. Examples of these include negation, conjunction, disjunction,
implication, equivalence, universal quantier, belief, intention, done, iota, any and all. Details of
all these and others are provided in the specication document.
   FIPA denes three subsets of SL (SL0, SL1 and SL2), differing in terms of which operators are
supported. FIPA SL1 extends the minimal representational form of FIPA SL0 by adding Boolean
connectives to represent propositional expressions, such as not, and, or. FIPA SL2 extends SL1 by
adding construction, logic modal operators and the action operator feasible. SL2 allows rst-order
predicate and modal logic but is restricted to ensure that it must be decidable. Different CAs require
the use of different SL subsets, e.g. queries requires the use of a referential operator to assign a
value for the results as dened in SL2, whereas requests requires use of the action operator   done  
dened in SL0.
   A FIPA-SL content expression may be used as the content of an ACL message. There are three
cases:


1. A proposition, which may be assigned a truth value in a given context. A proposition is used
   in the inform CA and other CAs derived from it.
2. An action, which can be performed. An action may be a single action or a composite action
   built using the sequencing and alternative operators. An action is used as a content expression
   when the act is request and other CAs derived from it.
3. An identifying reference expression, which identies an object in the domain. This is the refer-
   ential operator and is used in the inform-ref macro act and other CAs derived from it.


There follows a simple example depicting an interaction between agents A and B that makes use
of the iota operator, where agent A is supposed to have the following knowledge base KB= {P(A),
Q(1, A), Q(1, B)}. The iota operator introduces a scope for the given expression (which denotes
a term), in which the given identier, which would otherwise be free, is dened. The expression
(iota x (P x)) may be read as   the x such that P [is true] of x  . The iota operator is a constructor
for terms which denote objects in the domain of discourse.

   (query-ref
      :sender (agent-identifier :name B)
      :receiver (set (agent-identifier :name A))
      :content
         "((iota ?x (p ?x)))"
      :language fipa-sl
      :reply-with query1)


   (inform
      :sender (agent-identifier :name A)

The Foundation for Intelligent, Physical Agents (FIPA)                                            21



      :receiver (set (agent-identifier :name B)
      :content
        " ((= (iota ?x (p ?x)) alpha)) "
      :language fipa-sl
      :in-reply-to query1)



The only object that satises proposition P(x) is alpha; therefore, the query-ref message is replied
by the inform message as shown.



2.2.3.5 FIPA Request Interaction Protocol Specication (SC00026)

Depicted by the sequence diagram in Figure 2.7, the FIPA Request Interaction Protocol (IP) allows
one agent, the Initiator, to request another, the Participant, to perform an action. The Participant
processes the request and makes a decision whether to accept or refuse the request.



                         FIPA-Request-Protocol



                                  Initiator                        Participant




                                                    request




                                                   refuse

                                                   [refused]


                                                     agree

                                             [agreed and
                                             notification necessary]


                                                   failure




                                           inform-done : inform

                                                                    [agreed]




                                           inform-result : inform




                            Figure 2.7     The FIPA Request Interaction Protocol

22                                                                            Agent Technology Overview



   If conditions indicate that an explicit agreement is required (that is,   notication necessary   is
true), then the Participant communicates an agree. This agreement may be optional depending on
circumstances, for example, if the requested action is very quick and can happen before a time
specied in the reply-by parameter. Once the request has been agreed upon, then the Participant
must communicate either:

A failure if it fails in its attempt to ll the request,
An inform-done if it successfully completes the request and only wishes to indicate that it is
   done, or
An inform-result if it wishes to indicate both that it is done and notify the interaction Initiator
   of the results.

Any interaction using this interaction protocol is identied by a globally unique, non-null
conversation-id parameter, assigned by the Initiator and set in the ACL message structure. The
agents involved in the interaction must tag all of its ACL messages with this conversation identier.
This enables each agent to manage its communication strategies and activities; for example, it allows
an agent to identify individual conversations and to reason across historical records of conversations.
   At any point in the IP, the receiver of a communication can inform the sender that it did not
understand what was communicated. This is accomplished by returning a not-understood message.
Figure 2.7 does not depict a not-understood communication as it can occur at any point in the IP.
The communication of a not-understood within an interaction protocol may terminate the entire IP
and termination of the interaction may imply that any commitments made during the interaction
are null and void.
   In addition, at any point in the IP, the Initiator may cancel the interaction by initiating the
Cancel Meta-Protocol shown in Figure 2.8. The conversation-id parameter of the cancel interaction
is identical to the conversation-id parameter of the interaction that the Initiator intends to cancel.
The semantics of cancel should roughly be interpreted as meaning that the Initiator is no longer
interested in continuing the interaction and that it should be terminated in a manner acceptable to
both the Initiator and the Participant. The Participant either informs the Initiator that the interaction
is done using an inform-done or indicates the failure of the cancellation using a failure.



                  FIPA-Cancel-Meta-Protocol



                                Initiator                              Participant




                                       cancel(canceled-communicative-act)



                                           inform-done : inform

                                                [not failed]



                                                  failure

                                                            [failed]



                               Figure 2.8   The FIPA Cancel Meta-Protocol

The Foundation for Intelligent, Physical Agents (FIPA)                                              23




                FIPA-Contract Net-Protocol


                                Initiator                                Participant




                                                       cfp                m




                                       i 2n         refuse

                                                                         n
                                                                     dead-
                                                                       line


                                       j = n  i    propose



                                                  reject-proposal        k 2j




                                                 accept-proposal    I = j  k


                                                   failure


                                            inform-done : inform


                                            inform-result : inform




                          Figure 2.9      The FIPA Contract Net Interaction Protocol



2.2.3.6 FIPA Contract Net Interaction Protocol Specication (SC00026)

As an example of a slightly more complex interaction protocol, the FIPA Contract Net Interaction
Protocol (IP) describes the case of one agent (the Initiator) that wishes to have some task performed
by one or more other agents (the Participants) and further wishes to optimize a function that
characterizes the task. This characteristic is commonly expressed as cost, but could also be soonest
time to completion, fair distribution of tasks, etc. For a given task, any number of the Participants
may respond with a proposal; the rest must refuse. Negotiations then continue with the Participants
that proposed. The IP is depicted in Figure 2.9.
  The Initiator solicits m proposals from other agents by issuing a call for proposals (cfp) CA
which species the task and any conditions the Initiator places upon the execution of the task.
Participants receiving the call for proposals are viewed as potential contractors and are able to
generate n responses. Of these, j are proposals to perform the task, specied as propose CAs.
  The Participant  s proposal includes the preconditions that the Participant is setting out for the
task, which may be the price, time when the task will be done, etc. Alternatively, the i = n  j
Participants may refuse to propose. Once the deadline passes, the Initiator evaluates the received

24                                                                            Agent Technology Overview



j proposals and selects agents to perform the task; one, several or no agents may be chosen. The l
agents of the selected proposal(s) will be sent an accept-proposal CA and the remaining k agents
will receive a reject-proposal CA. The proposals are binding on the Participant, so that once the
Initiator accepts the proposal the Participant acquires a commitment to perform the task. Once the
Participant has completed the task, it sends a completion message to the Initiator in the form of
an inform-done or a more explanatory version in the form of an inform-result. However, if the
Participant fails to complete the task, a failure message is sent.
   This IP requires the Initiator to know when it has received all replies. In the case that a Participant
fails to reply with either a propose or a refuse CA, the Initiator may potentially be left waiting
indenitely. To guard against this, the cfp CA includes a deadline by which replies should be
received by the Initiator. Proposals received after the deadline are automatically rejected with the
given reason that the proposal was late. The deadline is specied by the reply-by parameter in the
ACL message.


2.2.3.7 FIPA Agent Message Transport Service Specication (SC00067)

A FIPA Message Transport Service (MTS) provides the mechanism for the transfer of FIPA-ACL
messages between agents using a Message Transport Protocol (MTP). The agents involved may
be local to a single AP or on different APs. On any given AP, the MTS is provided by an Agent
Communication Channel (ACC).
   A message is made up of two parts: a message envelope for expressing transport information and a
message payload comprising the encoded ACL message of the agent communication. Any MTP may
use a different internal representation to describe a message envelope, but must express the same
terms, represent the same semantics and perform the corresponding actions. A message envelope
comprises a collection of parameters each of which is a name/value pair with the mandatory elds
of to, from, date and acl-representation.
   An ACC provides an MTS and is responsible for sending and receiving messages on an AP. An
ACC must transfer the messages it receives in accordance with the transport instructions contained
in the message envelope and is only required to read the message envelope; it is not required to
parse the message payload. In performing message transfer tasks, the ACC may be required to
obtain information from the AMS or DF on its own AP. Some implementations of ACCs may
provide some form of buffering capability to help agents manage their messages.
   Each ACC handling a message may add new information to the message envelope, but it may
never overwrite existing information. ACCs can also add new parameters to a message envelope
which override existing parameters that have the same parameter name; the mechanism for disam-
biguating message envelope entries is specied by each concrete message envelope syntax. The
message forwarding behaviour of an ACC is determined by the instructions for message delivery
that are expressed in the message envelope, the parameters of which are described in Table 2.3.
   The recipients of a message are specied in the to parameter of a message envelope and take
the form of AIDs. Depending upon the presence of intended-receiver parameter, the ACC
forwards the message in one of the following ways:

If an ACC receives a message envelope without an intended-receiver parameter, then it
  generates a new intended-receiver parameter from the to parameter (possibly containing
  multiple AIDs). It may also generate multiple copies of the message with different intended-
  receiver parameters if multiple receivers are specied. In all cases, the ACC is required to
  process all entries in the to eld parameter and not to add and not to remove any AID that was
  contained in the original message. The intended-receiver parameters form a delivery path
  showing the route that a message has taken.
If an ACC receives a message envelope with an intended-receiver parameter, this is used
  for delivery of this instance of the message and the to parameter is ignored.

The Foundation for Intelligent, Physical Agents (FIPA)                                                    25



Table 2.3   FIPA message envelope parameters


Parameter                        Description


to                               The names of the primary recipients of the message
from                             The name of the agent that sent the message
comments                         Text comments
acl-representation               The syntax representation of the message payload
payload-length                   The length in bytes of the message payload
payload-encoding                 The language encoding of the message payload
date                             The creation date and time of the message envelope
intended-receiver                The name of the agents to whom this instance of a message is to be delivered
received                         A stamp indicating the receipt of a message by an ACC
transport-behaviour              The transport requirements of the message



If an ACC receives a message envelope with more than one intended-receiver parameter,
  the most recent is used.

Before forwarding the message, the ACC adds a completed received parameter to the message
envelope. Once an ACC has forwarded a message it no longer needs to keep any record of the
existence of that message.
  The AID given in the to or intended-receiver parameter (in the case of both parameters
being present, the information in the intended-receiver parameter is used) of a message
envelope may contain multiple transport addresses for a single receiving agent. The ACC uses the
following method to try to deliver the message:

Try to deliver the message to the rst transport address in the addresses parameter; the rst
  is chosen to reect the fact that the transport address list in an AID is ordered by preference.
If this fails, because the agent or AP was not available or because the ACC does not support the
  appropriate message transport protocol, etc., then the ACC creates a new intended-receiver
  parameter containing the AID with the failed transport address removed. The ACC then attempts
  to send the message to the next transport address in AID in the intended receiver list (now the
  rst in the newly created intended-receiver parameter).
If delivery is still unsuccessful when all transport addresses have been tried (or the AID contained
  no transport addresses), the ACC may try to resolve the AID using the name resolution services
  listed in the resolvers parameter of the AID. Again, the name resolution services should be
  tried in the order of their appearance.

Finally, if all previous message delivery attempts have failed, then an appropriate error message
for the nal failure is passed back to the sending agent.
  An ACC uses the following rules in delivering messages to multiple intended receivers:

If an ACC receives a message envelope with no intended-receiver parameter and a to
  parameter containing more than one AID, it may or may not split these up to form separate
  messages. Each message would contain a subset of the agents named in the to and intended-
  receiver parameters.
If an ACC receives a message envelope with an intended-receiver parameter containing
  more than one AID, it may or may not split these up to form separate messages.
If an ACC splits a message as described above, then it is enforced not to add and not to remove
  any AID that was contained in the original message.

The resulting messages are handled as in the single receiver case.

26                                                                          Agent Technology Overview



   An agent has three options when sending a message to another agent resident on a remote AP:


1. Agent A sends the message to its local ACC using a proprietary or standard interface. The ACC
   then takes care of sending the message to the correct remote ACC using a suitable MTP. The
   remote ACC will eventually deliver the message.
2. Agent A sends the message directly to the ACC on the remote AP on which Agent B resides.
   This remote ACC then delivers the message to B. To use this method, Agent A must support
   access to one of the remote ACC  s MTP interfaces.
3. Agent A sends the message directly to Agent B, by using a direct communication mechanism.
   The message transfer, addressing, buffering of messages and any error messages must be handled
   by the sending and receiving agents. This communication mode is not covered by FIPA.


Finally, the transport description forms part of an AP and is expressed in fipa-sl0. The following
transport description is for an AP which supports IIOP and HTTP-based transports:

  (ap-description


  :name myAPDescription
  :ap-services
   (set
     (ap-service
      :name myIIOPMTP
      :type fipa.mts.mtp.iiop.std
      :addresses
       (sequence
           corbaloc:iiop:agents.fipa.org:10100/acc
           IOR:00000000002233
           corbaname::agents.fipa.org:10000/nameserver#acc))
     (ap-service
      :name myHTTPMTP
      :type fipa.mts.mtp.http.std
      :addresses
       (sequence
           http://agents.fipa.org:8080/acc))) )



2.2.4 THE RELEVANCE OF FIPA TO JADE

We recall that FIPA is based on the tenet that only the external behaviour of system components
should be specied, leaving internal architecture and implementation details to the developers
of individual platforms. This ensures seamless interoperation between fully compliant platforms.
JADE complies with this notion by ensuring complete compatibility with the primary FIPA2000
specications (communication, management and architecture) that provide the normative framework
within which FIPA agents can exist, operate and communicate, while adopting a unique, proprietary
internal architecture and implementation of key services and agents.
   JADE is of course only one of several agent platforms, applications and collaborative projects
that have been, and are continuing to be, compliant with the FIPA standards. This compliance has
been tested on several occasions through such events as the FIPA interoperability tests conducted in
1999 and 2001 and the large-scale Agentcities project (Agentcities) that integrated several globally
distributed FIPA-compliant platforms. With the continued growth of inter-organization application
domains such as supply networks and inter-provider telecommunications, there is an increased
likelihood that open interoperation will become an important factor.

The Foundation for Intelligent, Physical Agents (FIPA)                                              27



   In terms of its coverage of the FIPA standards, JADE implements the complete Agent Manage-
ment specication including the key services of AMS, DF, MTS and ACC. Of course through use
and experience these services have been extended with additional features, but the core compliance
to FIPA has been maintained. JADE also implements the complete FIPA Agent Communication
stack, ranging from the availability of FIPA-ACL for message structure, FIPA-SL for message
content expression, plus support for many of the FIPA interaction and transport protocols.
   An example of where JADE exceeds, but does not break, the FIPA standards, is the JADE
transport mechanism which supports all specied operations, but is also capable of adapting a
connection type by seamlessly selecting the best available protocol according to the particular
usage situation.
   Some of the ancillary aspects of the FIPA standards, such as some of the more esoteric interaction
protocols and non-standardized work such as the ontology service, have yet to be developed for
JADE even if programmers can nd all the tools and abstractions needed to implement them.
However, there are also many JADE components that go far beyond the FIPA specications.
For example, JADE provides a distributed, fault tolerant, container architecture, internal service
architecture, persistent message delivery, semantic framework, security mechanisms, agent mobility
support, web-service interaction, graphical interfaces, and much more. Many of these are described
in the main body of this book, as is the critical aspect of agent-oriented systems that FIPA does
not address  C the internal architecture of agents themselves.
   Due to its open source status, strong support from industry and a broad user community, JADE
is now generally considered to be the leading FIPA-compliant open source agent framework.


3

The JADE Platform


This chapter provides a basic overview of the JADE platform and the main components constituting
its distributed architecture. Furthermore, it describes how to launch the platform with the various
command-line options and how to experiment with the main graphical tools.


3.1 BRIEF HISTORY
The rst software developments, that eventually became the JADE platform, were started by Tele-
com Italia (formerly CSELT) in late 1998, motivated by