- From: Mark Baker <distobj@acm.org>
- Date: Tue, 11 Nov 2003 11:56:23 -0500
- To: Geoff Arnold <Geoff.Arnold@Sun.COM>
- Cc: public-sws-ig@w3.org
On Tue, Nov 11, 2003 at 10:49:46AM -0500, Geoff Arnold wrote: > > (subject changed; it's kinda creepy having your name in it 8-) > > Agreed. Sorry for any perceived ad hominem.... Oh heavens, I perceived no ad hominem. > > Application interfaces, on the other hand, are presumably in scope. > > So we can have discussions about whether FIPA's INFORM and REQUEST > > operations are suitable/sufficient, right? If so, then I claim that > > discussions about GET and POST are also in scope. > > > > Well, the FIPA messaging model is thoroughly asynchronous. Even a > REQUEST > is merely a proposal that the recipient should update its short-term > goals > (its "intentions") to include the intent to inform the initiator about > something (the "something" being related to the content of the request). > The response to the request is typically encoded as an INFORM (or > perhaps > a series of INFORMs). Yes, that's true, but also do-able with POST. I've used two POSTs instead of a POST and a response before. And certainly REST doesn't require request/response interactions; I've used one-way UDP RESTfully. > So to a first order all FIPA style messages would be POSTs. They are > idempotent one-way messages, possibly one-many. It would certainly > be unwise to construct a hard and fast mapping between the primitive > speech acts of FIPA style agents and particular messaging primitives. I don't follow. Are you claiming that HTTP POST is a "messaging primitive", but FIPA INFORM is not? A mapping between POST and INFORM would be quite straightforward, and could be implemented with an HTTP proxy, ala; telnet fipahttp.example.org 80 POST fipa://some-host.org/agent/k HTTP/1.1 Host: some-host.org Content-Type: application/x-fipa KIF-goes-here which would map that to (inform :receiver k :content [KIF-goes-here] ) > Having said all that, there is clearly some performance benefit to be > gained > from piggy-backing a response within a single message-level transaction. > I'm not sure how best one would accomodate this, in part because of the > broken layering in SOAP/HTTP. However, that's properly the concern of > different W3C groups. Whatever efficient mechanisms are exposed for > one-way messaging can be exploited by BDI-style agents. > > Just to get a little thread convergence here, there are clearly > interests of common concern between the OWL-S process group, the > choreography WG, and multi-agent "interaction patterns". If any of > them get too deeply entwined in lower-level messaging issues, it's going > to complicate any synthesis...... Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Tuesday, 11 November 2003 11:54:22 UTC