W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2003

Re: What protocols are in scope?

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
Message-ID: <20031111115623.D2875@www.markbaker.ca>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:53 GMT