Subject: RE: Understanding message send.
From: Dominic Greenwood (dpag@fla.fujitsu.com)
Date: Mon Oct 28 2002 - 21:19:06 MET
Mariusz,
As I understand it the FIPA X2S now have a mapping from the FAA concept
of agent-directory-entry to the FMO concept of AID.
The FAA currently defines an agent-directory-entry (semantically
identical to the concept of an agent-description) as containing 1
agent-name and 0* agent-locators, each agent-locator containing a list
of transport-descriptions.
The FMO currently defines the AID as containing 1 agent-name and 0*
addresses. Each address contains the equivalent of the FAA
transport-description.
Semantically, I believe the only differences between the two are:
1. The FAA mandates the presence of an agent-locator list (although it
can be empty), whereas in the FMO the 'addresses' field is optional. The
FMO AID also contains the 'resolvers' field, but this is also considered
optional.
2. The FAA transport-description field contains two mandatory
sub-fields, a transport-type and a transport-specific-address. In the
FMO addresses are specified as a unitary URL.
Regards,
Dominic
-- Dominic Greenwood Fujitsu Laboratories of America, Inc.> -----Original Message----- > From: owner-jas@webmasterone.com [mailto:owner-jas@webmasterone.com] On > Behalf Of Mariusz Nowostawski > Sent: Friday, October 25, 2002 17:49 > To: jade-develop@sharon.cselt.it > Cc: jaseg@webmasterone.com; public@java-agent.org; Ian_Dickinson@hp.com > Subject: Re: Understanding message send. > > Hi Ian, > > The X2S resolutions from the last FIPA meeting in Pensacola are now > available for review on the FIPA website at > http://www.fipa.org/activities/pensacola_2002.html > > There is no resolution about FAA concepts relating to agent-name, > locator, and agent-description in regards to older FIPA specs and in > particular Fipa Management Ontology concepts, with AID, agent-address, > etc. The suggested clarification has not been approved on the meeting. > > This of course does not change the fact that there are inconsistencies. > The simplest test for inconsistency is to try sending a message from > (and to) pure FAA-based implementation (e.g. JAS RI) to (and from) > legacy FIPA-based implementation (e.g. JADE). Older FIPA 2000 specs, > incl. Fipa Management Ontology do use different conceptual partitioning > of naming and addressing the agents, which has been changed in FAA. > Currently the only way these two worlds can "talk" to each other is via > some ad-hoc custom solutions, where agent-name and locator are extracted > from (and codded into) the AID manually, based on the appropriate grammar. > > Ian and others, if you are keen on helping to resolve these issues, > please follow the FIPA procedures and submit your comments to > appropriate people. > > > best regards > Mariusz Nowostawski > > > > ps. I am attaching the previous discussion about this and related > issues, and I am posting this to JAS mailing lists as well. I believe > the problems with interoperability between JAS RI and legacy FIPA > platforms is common, and there will be people keen on resolving it in > some uniform and standarized way. > > > > --------------------- > Previous discussion > --------------------- > > (from older e-mails on JADE mailing list). > > My comments will not explain the inner-workings of JADE, and are not > intended to do so - I am not a JADE developer. However, my comments > might clear a little bit the confusions between FIPA Abstract > Architecture, FAA (the current experimental specs) and the older > (legacy) FIPA specs (the current FIPA 2000 specs). > > > Dickinson, Ian J wrote: > [...] > > FIPA abstract architecture (FAA) identifies agent _identifiers_ and > > agent _transport addresses_ as separate concepts. Jade's AID class > > seems to encapsulate both of these. An AID wraps a single agent > > identifier (long lived), with zero or more addresses (potentially less > > long-lived or well known > > This is one of the problems with the newest FAA spec and the older FIPA > Management Ontology specs and ACL-related specs. They are a little bit > confusing and inconsistent. Previous FIPA specs do indeed had a concept > of Agent-Identifier (AID), which was indeed a mixture of agent-name, > locators and resolvers. Currently (in newest FAA) this concepts are > decoupled. JADE handles the situation according to the older specs. > > > Now, the FAA talks at some length about the agent directory service, > > and notes the separation of identity and address. But it's not clear > > to me who has the responsibility to perform name resolution. Is it an > > agent's responsibility to resolve identifiers to addresses? If so, is > > that before > > According to the FAA it is not the agent, who is responsible for that, > it is the Transport Service, which does the name-to-address resolution. > According to FAA specs, on the Message level, i.e. on the highest level > of ACL processing, agents do operate purely using agent-names, not > address. On the Transport Message level it gets "translated" according > to some policy to and from physical addresses. > > > the message is sent, or during send? If it's not the agent but the > > platform that has the responsibility to resolve names, what contract > > is there between the platform and the sender, and the platform and the > > directory service? > > These are very good questions, especially in the world where some agent > platforms do use purely the older specs (e.g. JADE), and some do use > purely the new FAA-based spec (Java Agent Services-based > implementations, like JAS RI). > > > For example, assume that agent A wants to send a message to B. It > > knows only B's identifier. In Jade, I would, in the code for agent A, > > create an AID for the message recipient, containing only the GUID for > > B. Let's assume I also have the AID of a directory agent. I guess I > > would manually add this as a resolver to the AID for B? If I then > > attempt to send this message, when will B's identifier be resolved to > > an address? How is the situation of a lack of address, or multiple > > addresses, handled? > > In theory it is very easy, nice and simple. Assuming that A and B live > on two different platforms, before A sends message to B, A must make > sure that their both Directory Services are "federated" or connected in > some way. Then, A just puts as "receiver" the B's agent-name, and the > rest is done via Transport Service, which, based on the federated > Directory Service, can resolve name-to-address of B. > > This is only in theory, because so far there is no FIPA specs how the > "standard" federation of directory services could be achieved. So, we > have a no-win situation. You cannot use "nice" mechanism. There are > several ways of doing it "the ugly way". One is to hardcode the address > by hand (either to agent directly or to his directory > service/facilitator and do the manual search before sending the message > to B). Second is to exploit the older Management Specs and Directory > Facilitator to obtain the content of a directory via ACL (thus achieving > sort of federation). Remeber though, that the new Directory Services are > not required to talk ACL at all. And, both of these solutions violate > FAA in some way or another. > > [ Off topic comments: > The way we deal with this situation currently is, that we manually > register all the remote agents we want to talk to with our local > Directory, thus all our agents can use the nice FAA mechanism for > resolving name-to-address. All "legacy" applications contacting our > platform do use older AIDs, from which we can extract all necessary > information and do the registration automatically, thus once we receive > the message from uknown agent we do register it automatically, and when > our agent is replying all the data for name-to-address resolution is > already in the directory. > As for multiple addresses, we do have a policy manager, which has a > sequence of protocol preferences - it looks like this, e.g. if agent > has HTTP address, use it first, if it fails, if agent has IIOP address, > use it next, if it fails if agent has RMI based address, use it next, if > it fails use first from the list, if it fails, use next, if it fails > sending of the message failed. > ] > > > > The FAA differentiates between the _directory facilitator_, and a > > _directory service_. Is this separation part of the current > > implementation of Jade? If it isn't currently, how would it be? (I'm > > trying to get a better sense of what the FAA is trying to convey) > > Very good questions. I think, the closest definition currently in use is > something like this: Directory Service is an directory entity (with all > the properties specified by FAA) to which you talk not necessary via > ACL, but via some sort of API. If, by design, you can talk to a given > Directory Service via ACL, it is than called also a Directory Facilitator. > > > ------------------------- > > Dickinson, Ian J wrote: > > > Can I assume that it's not a legal state for an agent to know another > > agent's transport address but not its name? This would seem to be > > implied [...] > > I believe this is the case, based on current FAA. > > > One thing remains slightly unclear about the FAA's view on the > > directory service. If it's the _platform's_ role to perform name > > resolution, why does the DF remain with an ACL interface? I mean, I > > assume that ACL interactions happen at the inter-agent communications > > level, which I would have thought was different from the platform to > > service level. If agents aren't expected to do name resolution, why > > provide ACL access to name resolution services? > > [...] In "old" days, FIPA was simpler, there was only one way: "the ACL > way". However, it was discovered that you cannot use ACL for everything, > in particular, using ACL to send ACL-messages was "akward". So it was > decided that for some services a custom API is better suited. And the > Pandora box got opened. Why use APIs and custom platform specific way to > communicate only to transport subsystem? Why not use custom platform > specific way (or custom APIs) to other services as well? Like Directory > Service? Of course we can do that, and this is what FAA is all about. > However, the "older" model is not completely gone. People driving FIPA > are a little bit divided. One group thinks that ACL shall be used purely > for Agent-to-Agent communication, and custom APIs shall be used for > Agent-to-Service and Platform-to-Service communication. The other group > thinks this is fine, but some services should retain their "agent-ish" > aspect, and should be accessible via ACL. The main argument is to have > an interoperable way of accessing some well-known services, like > Directory Service. > So, in summary, Directory Service do not "talk" ACL. Directory > Facilitator, as specified in older specs is in a sense a wrapper Agent > around a service, and, as an Agent, it can speak ACL. So you have this > dualism currently present. > > If only there is a standard way to federate Directory Services, one > would not need to use DF and ACL. But, because there is no standard way > to federate directory services, using a DF as a wrapper and using > "standard" ACL to talk to it is currently the only way of dealing with it. > > [...]
This archive was generated by hypermail 2a22 : Mon Oct 28 2002 - 21:20:07 MET