RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Burdett, David
> Sent: Wednesday, February 19, 2003 3:07 PM
> To: 'Mark Baker'
> Cc: www-ws-arch@w3.org
> Subject: RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout
>
>
>
> I'm changing the email subject since I *think* we have reached consensus
> that POST, on its own, is not enough. There needs to be some additional
> metadata, that has to be represented somewhere on the message, that
> identifies the actor or the action that is to be carried out on
> the message.
>
> I will try and enumerate several of the potential ways of representing the
> action so that we can debate the alternatives ;). They will all assume an
> order sent to example.com.
>
> VARIANT 1 - HTTP relative path
>
> POST http://ecommerce.example.com/processorder
>
> VARIANT 2 - HTTP Query
>
> POST http://ecommerce.example.com?action=processorder
>
> VARIANT 3 - Separate Server
>
> POST http://processorder.example.com
>
> VARIANT 4 - New HTTP Method
>
> PROCESSORDER http://ecommerce.example.com
>
> VARIANT 5 - SOAP Role
>
> POST http://ecommerce.example.com
>
> <SOAP:Envelope>
>   <SOAP:Header role="urn:.../processorder">
>   </SOAP:Header>
>   ...
> </SOAP:Envelope>
>
> VARIANT 6 - SOAP Header
>
> POST http://ecommerce.example.com
> ...
> <SOAP:Envelope>
>   <SOAP:Header role="messagehandler">
>    <x.Actor>processorder</x.actor>
>   </SOAP:Header>
>   ...
> </SOAP:Envelope>
>
> VARIANT 7 - SOAP Body
>
> POST http://ecommerce.example.com
> ...
> <SOAP:Envelope>
>   <SOAP:Header>
>   ...
>   </SOAP:Header>
>   </SOAP:Body>
>   <y.Order type="processorder">
>   ...
>   </y.Order>
> </SOAP:Envelope>
>
> Are these enough, or are there further reasonable examples to
> consider that
> I've missed? Please suggest more if you can think of any.
>
> MY PERSONAL PREFERENCES
>
> My personal preference is for variant 6 (sorry Mark it's not URI's!) and
> here's why ...
>
> All the options that involve putting information in the URI (Variants 1
> through 4) mean that the data is visible to anyone who sees the
> information
> go over the net. While this might not often be a worry sometimes
> it is. The
> simple fact, for example, that Microsoft was placing an order with Sun (or
> vice versa), could be the basis of some very interesting articles ... not
> that I am suggesting that either would do such a thing ;)

+1

I never thought about that angle. Thanks for brining it up!


> On the other hand, if the data is recorded in the body of the message
> somewhere then it can be encrypted which helps ensure privacy.
>
> I'm not keen on Variant 5 (SOAP Role) as it means that, in theory, the
> message HAS to be handled by a SOAP node that can accept an order, unlike
> Variant 6, where you are targeting a SOAP node that can handle
> any message -
> it's my experience that, for eCommerce, having a general "front door" or
> gateway that can accept any eCommerce message is what implementors want to
> do as it makes it easier for them to put all the security, firewall
> protection, message logging, etc, in a single place.

For same reason I prefer 6 over 5.

> I'm also not keen on Variant 7 as the data is buried in the body of the
> message which means that you cannot work out what to do with the message
> unless you understand the semantics of the body of the message.

I think it all boils down to whether you route the message based on its
content or just the headers. There is more information in the message that
is used to route it to the right component, e.g. which process handles it,
correlation of response to request, etc. So we need to look at more than
just one header, or one element in the body.

I would say that once the service gateway is done processing security,
transaction and other headers, the message is passed to the service
implementation which decides which operation to perform in what context
(e.g. which process is responsible for performing that operation). So by
that rational whether the operation is encoded in the body or the header (6
or 7) makes no difference.

At least in my understanding this is not a problem of the service gateway
but of the service implementation, so variant 7 is more applicable.

arkin


>
> So Variant 6 is the one I prefer.
>
> What do other people think?
>
> David
>
>
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, February 19, 2003 1:28 PM
> To: Burdett, David
> Cc: www-ws-arch@w3.org
> Subject: Re: AR023.7.1 (was Re: Dead trout
>
>
> On Wed, Feb 19, 2003 at 10:59:52AM -0800, Burdett, David wrote:
> > OK, you might be able to use POST, but I think its meaning could be
> > ambiguous as there are different things you can do with an order, for
> > example:
> > 1. Send it to a supplier so that they can check it and provide
> a response
> > (as previously described)
> > 2. Send it to tax calculation service, provides the taxes due in a
> response
> > 3. Send it to an off-site archival service for long-term storage
>
> Sure.  To distinguish between these things, you'd still use the POST
> method, but you'd just POST to different URIs identifying those
> different actors you mentioned (though much more granular than that
> wording suggests, as you'd have to send it to a supplier's "checking"
> resource, not just to some single URI where everything goes).
>
> > In all instances the content of the message is the same, but the action
> you
> > are requesting is quite different. I don't think we could use
> POST for all
> > three.
>
> The method, body, and headers of the messages may be identical, but the
> URI would be different.  Like putting an "I love you" message in different
> mailboxes will have different results. 8-)
>
> > For this reason I would think there would be benefit in
> defining new terms
> > with appropriate semantics for each of the above such as:
> > 1. PROCESSORDER - Check this request for goods or services and provide a
> > response that indicates the extent to which you can satisfy it
> > 2. CALCULATEORDERTAX - Check the taxes due on this order and provide a
> > response that includes the taxes due
> > 3. ARCHIVE - Store the content of this message securely and provide an
> > identify by which it may later be retrieved
>
> Or how about just defining different types of resources, for example
> an OrderProcessor, Archiver, etc...  Then, knowing the type, you could
> just POST your order to it.
>
> > Note that the first two are specific to the processing of an order and
> > therefore dependent on the content of the message while the last one is
> > generic and could apply to any message.
>
> Right.  POSTing a vCard to an OrderProcessor would presumably result in
> a 4xx error of some kind.  But POSTing to an Archiver, you could get
> back a 201 which would provide the resulting URI of the archived
> document in the response.
>
> > Does this type of approach make sense?
>
> *nods* Definitely, modulo the URI issue.
>
> > If it does then we can identify the principle that there the
> basic actions
> > in REST which have their own specific semantics and then additional
> actions
> > that can identify additional processes that are non REST that need to be
> > invented when required.
>
> Well, let's see what you think about the varying-URI idea...
> I'm not against what you're suggesting, I'm just hoping you can see the
> additional value in what I'm describing.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 20 February 2003 02:58:31 UTC