|Document title||Bake-off Suggestions for London, April 2001 Meeting|
|Document number||f-in-00026||Document source||Fabio Bellifemine|
|Document status||Preliminary||Date of this status||2001/04/05|
interoperability test has been performed during the FIPA meeting since Sunday 1st
April, 10:30 to Thursday 5th April 19:00 with the following
Bellifemine, Tiziana Trucco, Giovanni Rimassa
Alan Treadway ,
main goal was to test the FIPA specifications by proving the interoperability of
the platforms. As described in the companion document Minutes and report of
the activity the goal has been successfully achieved.
a result, a list of minor issues have been identified in the FIPA specs, and
detailed in the following section, where ambiguity or effectiveness should be
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. Infact, 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 to clarify if the communication model is asynchronous MTP or synchronous MTP. Some options have been identified:
oneway attribute of the IIOP IDL interface and make synchronous the MTP;
specs of the HTTP MTP such that it becomes asynchronous (not simple to do, given
that HTTP is a synchronous protocol)
specs of the HTTP MTP by adding a timeout to wait for (this is not really an
problem in the HTTP MTP specs and invite implementations to take care of it.
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.
clarify what an
hap is (i.e. it must be unique and it is exactly the value of the slot :name of
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
the names of
the other agents can be searched with the AMS
a valid address
for the AID of the AMS MUST either contain a persistent IOR, or a persistent
location (i.e. corbaloc or corbaname)
syntax for the URI of these MTPs
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)
TC Gateways is
invited to propose
one or more AMS
AIDs can be provided when bootstrapping a platform.
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
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
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.
suggest FIPA to improve its specs by clarifying the following issues:
in an Interaction Protocol should have a non-null conversation-id
to that message in the scope of that IP should have the same conversation-id
not mandate) to use unique values for this conversation-id for instance by using
the slot name of the sender AID
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
representing Interaction Protocols and their attributes (e.g. deadlines to
terminate the protocol, …) should be defined by FIPA
We finally propose to FIPA to consider bringing the following specifications to the Standard status:
MTP for IIOP
MTP for HTTP
Communication Language Parameters
 AOT Lab of the University of Parma (Italy)