|
Source |
FIPA
bake-off |
|
Title |
Minutes
and report of the activity. |
|
Editor |
Fabio
Bellifemine (Telecom Italia) |
|
Date |
Sunday 1st
April, 10:30 – Thursday 5th April 19:00 |
|
Document
revision |
Update at
Thursday 5th April, 17:40.
End of the bakeoff. |
-
JADE (Telecom Italia)
o Fabio Bellifemine, Tiziana Trucco,
Giovanni Rimassa[1]
-
FIPA-OS (Emorphia)
o Alan Treadway , Chris Newland
-
ZEUS (BT)
o Simon Thompson
-
HTTP-MTP
(EPFL)
o Ion Constantinescu
-
Sunday
1st April, 10:30 – Thursday 5th April 19:00
-
Room
403 (4th floor) just in front of the plenary room
-
Test
the FIPA specifications by proving the interoperability of the platforms.
-
Possibly
produce a simple demo for the FIPA membership
-
Write
an output document to FIPA with the following content
o Report of the bake-off activity
o Suggestions to improve the
effectiveness / reduce the ambiguity of the FIPA specs
-
Produce
a workplan for a FIPA compliance test
o Possibly edit a draft document (for
the Agent Management specs & others) based on the input document from EPFL
& Motorola (Agentcities test suite Discussion Document v. 1.0)
-
Identify/Recommend
someone with the responsibility of checking that the proposed modifications are
actually done in the FIPA specs, or at least a valid alternative solution is
found.
|
IIOP MTP
FIPA 2000 |
SUNDAY |
|
ACLString
encoding |
SUNDAY |
|
FIPASL0 |
SUNDAY |
|
FIPARequest
interaction protocol |
SUNDAY |
|
PingAgent
(based on the AgentCities specs) |
SUNDAY |
|
FIPAAgentManagement
Ontology |
SUN/MON |
|
AMS:
search, register, deregister, modify, getAPDescription |
MONDAY |
|
DF:
search, register, deregister, modify, register a DF with the other DF, search
with federated DFs and propagating the search |
MONDAY |
|
Propose a solution to FIPA to solve the bootstrapping problem |
(Monday 16:00 – 18:00) |
|
HTTP ACC
(Zeus <> JADE) |
TUESDAY
mor. 9:00 |
|
ACL
bitefficient encoding (JADE <> FIPAOS) |
TUESDAY
afternoon |
|
Producing a proposed solution to FIPA about the failures in the
transport problem |
(Wednesday 10:00 – 12:00) |
|
Producing a proposed solution to FIPA about the possible misinterpretation
of timeout problem |
(Wednesday 10:00 – 12:00) |
|
Multicasting
a message |
WEDNESDAY |
|
Creating
& testing exceptional conditions (i.e. NotUnderstood/Failure/Refuse) |
WEDNESDAY |
|
Going
through the list of tests provided by AgentCities |
WEDNESDAY |
|
Writing
report to FIPA + feedback to FIPA + workplan to FIPA |
THURSDAY |
|
Preparation
of a simple demo |
THURSDAY |
|
Demo |
THURSDAY
16:00 |
|
(possibily
IIOP FIPA97) (low priority) |
.. |
|
Testing
other interaction protocols (low priority) |
.. |
-
Noise:
not so much
-
room
503 size: 6 persons for the bake-off + audience.
-
The
Imperial mini-hub (we can give the Telecom Italia mini-hub to Kaveh)
-
A
Computer Projector
-
Agent
Management specs
-
Message
Transport Service
-
MTP
for IIOP
-
MTP
for HTTP
-
Agent
Communication Language Parameters
-
String
ACL Encoding
-
Bit-efficient
ACL Encoding
-
FIPA-SLO
content language
-
FIPA-Request
Interaction Protocol
-
FIPA-Query
Interaction Protocol
-
Content
languages: full SL, CCL, KIF, RDF
-
ACL
Encodings: XML
-
most
of the interaction protocols
-
Human-agent
interaction
-
Ontology
service
-
Agent-software
integration
-
4
informative applications
-
Nomadic
support
-
WAP
-
Mobility
-
Abstract
architecture
Note: That
does not mean that these specs are less useful!
A LAN has
been configured by using a mini-hub kindly provided by Imperial College.
A directory
has been shared to exchange provisionally and easily the addresses of the
platforms.
An
anonymous ftp has been setup on cmddata for the same purpose, alternatively.
-
Using:
Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORB and String encoding of ACL by directly
exchanging the IORs
o Sending a single message
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
o Ping-Alive Conversations (fipa-query
protocol with no exceptions). The Initiator gets the IOR directly from a file,
while the responder gets the address of the initiator directly from the ACL
message.
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
-
AMS
Using: Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORB and String encoding of ACL by
directly exchanging the IORs. The Initiator gets the IOR directly from a file,
while the responder gets the address of the initiator directly from the ACL
message.
o GetAPDescription
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
o Search with the AMS
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
OK |
OK |
|
o Register
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
o Deregister
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
o Modify
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
OK |
OK |
|
-
DF
Using: Sun Jdk1.3, IIOP FIPA2000 MTP, Sun ORBand String encoding of ACL by
directly exchanging the IORs. The Initiator gets the IOR directly from a file,
while the responder gets the address of the initiator directly from the ACL
message.
o Search with the DF
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
o Register
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
|
|
|
o Deregister
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
|
|
|
o Modify
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
o Federate the DF. The initiator
registers its DF with the DF of the responder platform. The responder correctly
recognizes this registration as a registered DF.
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
o Search with a DF that propagates to
another DF. The initiator searches in its DF with a max-depth>1. The DF
propagates the search to the federated DFs and correctly collects all the
results. The federated DF belong to the responder platform.
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
-
HTTP
MTP Using String encoding of ACL by directly exchanging the URLs
o Sending a message.
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
o Ping conversation. The Initiator
gets the address directly from a file, while the responder gets the address of
the initiator directly from the ACL message.
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
OK |
|
FIPA-OS |
OK |
|
OK |
|
ZEUS |
OK |
OK |
|
-
IIOP
MTP Using bit-efficient encoding of ACL by directly exchanging the URLs
o Sending a message.
|
Initiator\Responder |
JADE |
FIPA-OS |
|
JADE |
|
OK |
|
FIPA-OS |
OK |
|
o Ping conversation. The Initiator
gets the address directly from a file, while the responder gets the address of
the initiator directly from the ACL message.
|
Initiator\Responder |
JADE |
FIPA-OS |
|
JADE |
|
OK |
|
FIPA-OS |
OK |
|
-
HTTP
MTP Using bit-efficient encoding of ACL.
o NOT TESTED
-
Multicast
homogeneous (i.e. one agent from the platform initiator sends 1 message to two
agents in the platform responder) by using IIOP, String encoding and
AgentCities Ping
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
-
Multicast
heterogeneous (i.e. one agent from the platform initiator sends 1 message to
three agents (two in the platform responder and 1 in the initiator)) by using
IIOP, String encoding and AgentCities Ping
|
Initiator\Responder |
JADE |
FIPA-OS |
ZEUS |
|
JADE |
|
OK |
|
|
FIPA-OS |
OK |
|
|
|
ZEUS |
|
|
|
All the specifications related to encoding/decoding should clearly specify that parsing is case-insensitive. In particular, the following FIPA specs have been identified:
In the Management specs, the APDescription is defined ambiguously. In fact, it is necessary that FIPA specifies the reserved values for all the names of the MTPs currently defined (e.g. “fipa.mtp.iiop”, “fipa.mtp.http”, “fipa.mtp.wap”). Also FIPA should unambiguously define how different addresses for the same MTP must be arranged (e.g. if there are 2 IIOP addresses for the same MTP, should they belong to just 1 MTPDescription or to 2?). Also, FIPA should define for each MTP the format of the valid URLs (i.e. addresses) for that MTP or, at least, it should point to the correct external specs (e.g. OMG for IIOP URLs).
The constants that identify the MTPs, the Interaction Protocols, the content languages, and the ontologies should be published somewhere and simple to browse. In particular, the constants that identify the Interaction Protocols are not defined in any FIPA specs (probably they were defined in the library of IPs, that is now obsolete probably)
HTTP MTP. This MTP is synchronous
while the IIOP MTP is asynchronous. That contradicts the MTP abstraction of
FIPA.
A sender agent is blocked forever if a malicious receiver does not send back
the HTTP response code or if it does not flush and close the socket. That works
for the browser paradigm but it does not apply for the agent communication. Even
if at the implementation-level something can be done to avoid the problem.
However, we suggest FIPA should clarify if the communication model is
asynchronous MTP or synchronous MTP. Some options have been identified:
o
remove
the oneway attribute of the IIOP IDL interface and make the MTP synchronous ;
o
change
the specs of the HTTP MTP such that it becomes asynchronous (not simple to do,
given that HTTP is a synchronous protocol)
o
change
the specs of the HTTP MTP by adding a timeout to wait for (this is not really
an elegant solution)
o
clarify
this problem in the HTTP MTP specs and invite implementations to take care of
it.
o
In all
the cases, it is important that FIPA specifies that the communication must be
perceived by agents as asynchronous (i.e. they are not blocked until the
message is actually delivered) even if the MTP was synchronous.
-
FIPA
Agent Management Specs.
o clarify what an hap is (i.e. it must
be unique and it is exactly the value of the slot :name of the APDescription)
o clarify that the slot name of the
AID of the AMS MUST be composed as AMS@hap and
that hap is a unique identifier of the platform
o the names of the other agents can be
searched with the AMS
-
MTS
specs
-
IIOP
MTP specs
o a valid address for the AID of the
AMS MUST either contain a persistent IOR, or a persistent location (i.e.
corbaloc or corbaname)
o include the syntax for the URI of
these MTPs
-
HTTP
MTP specs
o a valid address for the AID of the
AMS MUST be a unique URL (i.e. it is restricted just to the HTTP protocol in
the protocol part of the URL syntax)
-
WAP
MTP specs
o TC Gateways is invited to propose
-
Recommendation
o one or more AMS AIDs can be provided
when bootstrapping a platform.
Definition:
How to discover a remote Agent Platform at run-time, i.e. how to exchange AP
Descriptions
Requirements:
Proposals:
-
P1:
publish the APDescription onto a URI.
The content of the URI should be a String-encoded APDescription
-
P2:
have a front-end of the platform with a
persistent address
-
P3:
use an MTP-dependent naming system. For IIOP it would be the CORBA Naming
Service
-
P4:
LDAP-based
-
P5:
a-la gnutella solution
Requirements
of the solution:
-
start
with one solution which scales and goes through firewalls
-
should
allow discovering a network of APs
-
should
work also in presence of failure of nodes
-
topology
must be configurable and manageable
-
should
minimize effort
-
use
DNS
-
should
allow to build a software tool that makes human-browsable the network of APs
-
should
work for current FIPA specs
Ion’s issue
about a list of remote platforms. An example scenario is the following:
-
platform
P1 knows the AID of the AMS of platform P2.
-
P1
(actually any agent of P1) sends a getAPDescription to the AMS of P2.
-
P1
sends a search to the AMS of P2. From the result, it can discover the AID of
the DF of P2
-
P1 can
then send a search to the DF of P2 and discover in this way all the registered
platforms (if any).
The current
FIPA specs no. 67 “MTP Service” states that:
-
[…] An ACC is only required to read the message
envelope; it is not required to parse the message body. In performing message
transfer tasks, the ACC may be required to obtain information from the AMS or
DF on its own AP. […]
-
Error and confirmation messages sent to a
sending agent by the MTS are in the form of ACL messages over the MTS. These
MTS information messages are sent on behalf of the AMS agent responsible (the :sender parameter of
the message must be set the local AMS’s AID) of the ACC's AP. How the message
is generated (whether by the AMS or by the ACC on behalf of the AMS) is not
specified by FIPA. If an error message needs to be returned, the message
generated must follow the exception model defined [FIPA00023] such that:
· The
communicative act is a failure,
· The
predicate symbol is internal-error,
and,
· The
argument parameter is a string describing the error, which occurred (the form
and content of which is not defined here).
The
problem:
Proposed solutions:
Final agreed
solution:
-
Add an
error-reason slot in the Envelope. The type of this slot is a String which
indicates the error type. The slot must only be used for failure messages.
-
All
MTSs should send an Envelope with error-reason when they detect a failure to
deliver the message. The payload of the Envelope is the sent message. The
intended-receiver of the Envelope must be set to the original sender of the
message.
-
All
MTSs that receive an Envelope with the error-reason slot set, and the
intended-receiver is a local agent, will notify that agent that the message
delivery has failed. This notification must be done by sending a FAILURE ACL
message, as already specified by FIPA. How this is done (i.e. via the AMS, or
directly by the MTP, …) is implementation-dependent. This FAILURE message
should have set the conversation-id and in-reply-to in the right way.
-
Platforms
can provide explicit APIs that prevent local agents from receiving these
FAILURE messages.
-
Furthermore,
agents would benefit from the MTP description defined by FIPA being extended
with QoS parameters.
We suggest
FIPA to improve its specs by clarifying the following issues:
-
all
ACLMessages in an Interaction Protocol should have a non-null conversation-id
-
all
responses to that message in the scope of that IP should have the same
conversation-id value
-
recommend
(but not mandate) to use unique values for this conversation-id for instance by
using the slot name of the sender AID
-
the
timeout value in the reply-by slot of an ACLMessage within the scope of an
Interaction Protocol refers to when the next message in the protocol flow
should be received and not to when the IP should terminate
-
a
Frame representing Interaction Protocols and their attributes (e.g. deadlines
to terminate the protocol, …) should be defined by FIPA
-
the
FIPA specs that have been tested in these 5 days are mature and allow
commercial exploitation of multi-agent systems
-
the
Agent Platforms that have participated are also mature
-
Bugs
have been found, and in most cases, fixed on the agent platforms
-
Bugs
have been found, and solutions have been proposed, on the FIPA specs
o they are minor bugs, easy to fix
both from the FIPA specs point of view and from the implementation point of
view
-
These
tests have proved that FIPA specs enables interoperability between agent
platforms but, in no way, they have proved compliance of the platforms
to FIPA specs!
-
As an
output of these tests, the following four Input documents to FIPA have been
produced:
o this report of the activity
o the plain text log of the exchanged
messages
o a document with the list of
identified problems in the FIPA specs and the proposed solutions
o a Workplan for a FIPA-compliance
test
§
in 2
meetings (8 days of work) we believe that we can bring to preliminary the tests
on most of the FIPA specs (Agent Management, MTS, IIOP MTP, HTTP MTP, SL,
ACLCodecs, Interaction Protocols, …) but serious commitment is needed from
participants
-
A
final demonstration have been given to FIPA members
o Thursday at 16:00 in room 403 (4th
floor) just in front of the plenary room
-
General
issues
o a lot of effort has been devoted to
this bake-off
§
Thanks
to all the participants and all the people who participated at the discussions
o all the platforms went very well
§
some
platforms have a more strict view on the standard, others are more lenient
§
some
platforms had support for these tests already integrated in their management
tools, others needed some manual support
o more interoperability tests are
welcome but
§
the
spirit of the FIPA interoperability tests should continue to be that of
verifying and improving the FIPA specs and not fixing the bugs of the
platforms!
We finally propose to FIPA to consider bringing the following specifications to the Standard status:
-
Agent
Management specs
-
Message
Transport Service
-
MTP
for IIOP
-
MTP
for HTTP
-
Agent
Communication Language Parameters
-
String
ACL Encoding
-
Bit-efficient
ACL Encoding
-
FIPA-SLO
content language
-
FIPA-Request
Interaction Protocol
-
FIPA-Query
Interaction Protocol