RE: Views on Web services architecture

Mark

I have always thought of a message as consisting of, as a minimum:
1. A description of where the message should be delivered, i.e. an address,
2. Some data (typically XML) that needs to processed, and
3. A statement of what the process should be, i.e. the action.

This is what ebXML did, for example.

I also agree with you when you say below that the action can go on the
transport protocol or on the envelope. There are also, actually a number of
other possible alternatives, e.g.
1. The address implies the action as that particular address can only do one
thing. This means you don't need a separate "action"
2. The action is stored inside the data. For example an XML order document
could include a status element of "new order" which implies the action to
take.

I'm not actually recommending these last two approaches although they are
certainly used.

However what I think we do need to do is to identify the architectural
concepts of, for example, address, data (to be processed) and action (or
whatever other words we want to use.

We can then think of separate ways of binding these concepts to particular
protocols or styles of use. I think this might then allow both the REST and
SOAP oriented approaches to coexist but based on the same architecture.

Thoughts?


-----Original Message-----
From: Mark Baker [mailto:mbaker@myblackberry.net]
Sent: Monday, July 22, 2002 7:58 PM
To: Mike.Champion@SoftwareAG-USA.com; www-ws-arch@w3.org
Subject: 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 Wednesday, 24 July 2002 22:01:17 UTC