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

Mark Baker wrote on 02/25/2003 10:26:30 AM:

> 
> On Tue, Feb 25, 2003 at 07:37:54AM -0700, Champion, Mike wrote:
<snip/>
> 
> > OK, Mark, Walden, or whoever ... what don't you like about that?
> 
> I like what's there.  I don't like what's not there. 8-O
> 
> What's not in there, is any mention of the issue of what the impact is
> on visibility, of using methods/operations/actions other than the
> methods of the underlying application protocol.  Roy and I say this
> reduces visibility.  Even Dave seemed to agree when he wrote;
> 
>  "The RESTful SOA has the advantage better visibility, as the firewall 
can
>   simply examine the generic interface to determine the action being
>   performed."
>   -- http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
> 

Okay, let me ask once more, what is the action being performed on a HTTP 
POST? The RFC specifically 
states that it is determined by the server and can be just about anything 
it wants it to mean. 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 
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. As always, there are 
trade-offs and it may just be the case
(as I believe that it is) that this is one such case where the benefits of 
NOT having to have application
software be written specially for each underlying protocol might just 
outweigh the perceived loss of
visibility that you seem so intent on insisting that we are imposing on 
ourselves because we just don't
get it like you do.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624