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

RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout
  -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Thursday, February 20, 2003 11:10 AM
  To: 'Assaf Arkin'; 'Mark Baker'
  Cc: www-ws-arch@w3.org
  Subject: RE: Representing Actions (was RE: AR023.7.1 (was Re: Dead trout


  Assaf

  You said ...

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

  I agree that there is often more information than just the actor/action
that is used to route the message to the correct destination. However I
think, from an implementation perspective, there is benefit this information
being in the header primarily because the information is always in the same
place. This means for example that:

  1. The routing mechanism does not need to understand the "body" of the
message
  2. You can route non XML documents as easily as XML documents
  3. The version of the document can change without having to change the
routing used ... unless you want to.

  No 2 is a very valid point against variant 7. I am not sure about 1 and 3,
though. The SOAP document is the over-the-wire encoding, not the unencoded
message that is passed to the application. The protocol binding rules
therefore indicate where one would find the operation name. The operation
name is then extracted, the message parts are extracted, and together are
passed to the application. The XPath expression you would use in 6 and 7 are
different, but essentially both will do the same work.

  We have discussed firewalls before. Even though firewalls do not represent
the optimal security framework, they are merely basic tools to enforce
primary level of security across all services, they may represent an
interesting test to determine which of the variants has better 'visibility'.
So I propose a firewall test as follows:

  - The firewall establishes a security policy based on the concept that
'what is not explicitly allowed is prohibited'. The firewall is initially
set up to not allow any access from outside the network. Over time, the
action policy is extended to allow access to specific services.

  - The firewall is controlled by the security czar. Access to services can
be added/removed only after they have been reviewed and approved by the
security czar. In no way can a user or application circumvent security by
being allowed to change policies without following this procedure.

  - A packet filtering firewall can deny/grant access based on the
source/destination IP/port or each packet. A content filtering firewall can
deny/grant access based on the content of the packet, if it can understand
the content. However, while rules can be created that address values in the
content of the packets, a plug-in is required for each distinct encoding
(HTTP and SOAP being distinct encodings) and installation of a plug-in or a
change of the policy must be done by the security czar.

  - The firewall is not symmetric. The firewall denies access to various
services from outside the corporate network, but allows users inside the
corporate network to access same services that exist outside the network.
For example, the firewall may prevent outside clients from opening
connections to any port but 80, 8080 and 110, but may allow inside clients
to open connections to any port in any other network.

  Assuming that we want to utilize the firewall to the largest extent
possible, but realize the cost involved in asking the security czar to
review/modify policies, which is the best encoding for the action?

  arkin








  Also, I have just thought of another reason why I prefer the action being
in the body of the message and that is you can then vary the transport
protocol used to transmit the message.

  David



  -----Original Message-----
  From: Assaf Arkin [mailto:arkin@intalio.com]
  Sent: Wednesday, February 19, 2003 11:57 PM
  To: Burdett, David; 'Mark Baker'
  Cc: www-ws-arch@w3.org
  Subject: 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