Re: Views on Web services architecture

On Wed, Jul 24, 2002 at 07:01:14PM -0700, Burdett, David wrote:
> 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.

Right.  Sometimes, #1 and #3 are implicit.

> This is what ebXML did, for example.
> 
> I also agree with you when you say below that the action can go on the
> transport

That's *transfer*. 8-)

> 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"

True, but you don't see that around very much.  It has very poor
scaling and evolution properties.

> 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.

Right, iCalendar does this too.  I consider this a poor separation of
concerns.

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

Yup, agreed.

> 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?

I agree.  Well said.

This kind of approach should point out the issue with many Web services,
namely that they have two conflicting actions, one in the envelope, and
one from the underlying protocol.  It would also describe the two ways
in which REST with SOAP can be used together.  Overall, very
constructive I'd say.

Perhaps the editors of the architecture document can incorporate this
suggestion at some point.  I'd suggest it can wait until later, if we
want to focus on SOAP+WSDL to start.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 24 July 2002 22:38:51 UTC