RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

Do I detect a trout hole again ... anyway here goes ... comments in line ...

David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, February 25, 2003 5:58 PM
To: Christopher B Ferris
Cc: 'www-ws-arch@w3.org '
Subject: Re: Visibility (was Re: Introducing the Service Oriented
Architec tural style, and it's constraints and properties.



(sorry Chris, I meant to send this to the list)

On Tue, Feb 25, 2003 at 10:48:46AM -0500, Christopher B Ferris wrote:
> Okay, let me ask once more, what is the action being performed on a HTTP 
> POST?

POST is the action.

For example, POSTing a purchase order to a purchase order processor.  The
only action in that interaction, is "POST"; the URI identifies the
processor, and the body on the POST request is a representation of a
purchase order (with no method).

<DB>The absence of a method implies that the URI can only be used for one
purpose. For example a Purchase Order Processor could either, for example:
check availability of stock and provide a response; archive the order in an
off-site repository for later retrieval; or, calculate the tax due.

Either way, the method is their either explicity (in the URI or in the
message body) or implicity, because that is the only purpose for which the
server at the URI can be used.
</DB>

> The RFC specifically 
> states that it is determined by the server and can be just about anything 
> it wants it to mean.

Yes, but if the action is anything other than POST (like "getStockQuote",
etc..), then visibility is reduced.  POST is the catch-all HTTP method,
but it does have a use separate from tunneling, and using it in that way
is how visibility is maintained.  Moreover, for every action you tunnel
through the POST body, I can show you a solution to the same problem
using HTTP (likely more than just POST), without an action in the POST
body.  That solution is more visible.

<DB>But ... 1. You don't always want visibility. 2. You don't always want to
use HTTP.</DB>

> There may be
> apparent visibility, but in truth, there is none. All that can be said of 
> the HTTP POST method is that the method 
> is not GET, PUT, DELETE, HEAD or OPTIONS. If anything, when using POST, 
> having the entity body
> well understood and easily parsable increases visibility rather than 
> reducing it. Ad hoc entity body or
> various form encoding is IMO far less visible because it is not 
> standardized.
> 
> As has been pointed out, Web services is also not exclusive to HTTP and 

Yes, of course.  That's why the "action" on an SMTP message-send is
DATA, unless another one goes in the body or subject line, like
"subscribe www-ws-arch".

> one of the objectives
> is that the service should be capable of being bound to any number of 
> underlying protocols without
> requiring that the service itself be changed.

Whoa, where'd that last part come from?  Reference please.  I agree
that protocol independance is a good thing, but not such that there's
no semantic difference between using HTTP and SMTP, for example.  Of
couse there's a difference; they're different applications.

<DB>We need to define what we mean by an "application" if you mean it is
anything above the transport layer, then you are correct but really I think
the layers are typically: Operating System, App Server, "Web Services
Middleware", Application.

I use the term "Web Services Middleware" to embody the "application" that
handles all the web services related processing. Although it is an
application, it is a *middleware* application that provides common
functionality that is usable by many "real application", i.e. it does
something useful that is specific to a business or individual.
</DB>


MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis