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

Excellent point.  I'll try to address this in my response to mike.

Dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Christopher B Ferris
  Sent: Tuesday, February 25, 2003 7:49 AM
  To: 'www-ws-arch@w3.org '
  Subject: 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