Re: Views on Web services architecture

Mike, good stuff!!

I agree with your characterization of "action".  I think it's useful to agree to a term.  I've always used "application semantic", but I don't mind a simpler one.

I disagree where you say that RPC is a MEP.  In my view, "RPC" is where the "action" is free-form, and the service publisher exposes any "actions" they think are useful for invocation, such that it requires an invoker to also understand them.  That is independant from the way in which RPC messages are transferred though.  It's true that RPC is typically point-to-point, synchronous, one request per response, but you can also have RPC over multi-cast, asynch.  For example, the Isis toolkit did this back in '95, which IONA integrated into Orbix+Isis (which I had the pleasure of using for several months).

Re Eric's mention of EAI, I've seen the term EAI used to refer to RPC, so a pointer to a definition would help me out.  FWIW, typical messaging solutions support a single "action" that means much the same as HTTP POST.  Only it isn't explicit like POST, it's implicit through some other means, like a TCP or UDP port.  But like HTTP POST, there's only so many things you can do with it - you can't do GET.  Also, it should be noted that the descriptions I've seen of messaging typically ignore the concept of "action", either explicit or implicit.  This makes it difficult to talk about REST to folks with lots of exposure to messaging, since the terminology is all different.  For example, "message" often refers to the data sent, rather than the data plus the action.  FWIW, and to demonstrate an important implication of this, a SOAP envelope is not a message until an action is included somewhere in the information sent along with the envelope.  When bound to an application protocol,!
 the action comes from the protocol (e.g. HTTP POST).  When bound to a transport protocol, which defines no actions, the action must be specified in the envelope.

MB
--
Mark Baker, Ottawa Canada. (613)261-5172
PLEASE RESPOND ONLY TO DISTOBJ@ACM.ORG

Received on Monday, 22 July 2002 22:59:57 UTC