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

Chairs,

Can we take this off-list?  I was going to write up a response similar to
Chris's, and then I realized that this conversation now has nothing to do
with what we need to do in our working group.  It's certainly no longer
suggesting any text for our documents.

Cheers,
Dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Christopher B Ferris
  Sent: Sunday, March 02, 2003 5:38 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 03/02/2003 12:07:10 AM:

  >
  > On Sat, Mar 01, 2003 at 07:56:58PM -0500, Champion, Mike wrote:
  > > And GET http://www.quotes-be-us.com/ibm is opaque to JMS
implementations.
  >
  > Of course.  Most things are invisible to a vanilla (i.e. without any
  > prior knowledge of any application semantic) JMS implementation, because
  > JMS provides an abstraction to OSI layer 6 protocols like BEEP or SOAP
  > or IIOP.  It does not abstract application protocols.  If it's used to
  > do so (which it is, of course 8-), then that means HTTP is being used as
  > a layer 6 protocol too, not the layer 7 protocol that it is.
  >
  > > That's why SOAP exists to allow SOAP intermediaries to work the same
across
  > > protocol bindings.  They tunnel over HTTP, FTP, SMTP, JMS
impelementation,
  > > MQ and other proprietary stuff with equal oblivion.
  >
  > I'm aware that this is the common view, as you're aware of my opinion
  > that this use of SOAP has no future.

  Everyone is entitled to their opinion. I think though that you are in a
  significant minority on this point.

  >
  > FWIW, you can track the adoption of this use of SOAP here;
  >
  > http://www.markbaker.ca/2002/04/WebServicesGrowth/
  >
  > As you can see, SOAP's growth over the Internet has been approximately
  > linear.  A far cry from the Web's growth, which can be seen here;
  >
  > http://www.mit.edu/people/mkgray/net/web-growth-summary.html
  >
  > There may be other reasons for this, but I have a good technical one
  > that suffices to explain it; integration complexity is too high due to
  > each service having a different interface than the next.

  I'm sorry, but this resoning is quite specious. The same integration costs
  (if not greater) exist when integrating an application with a Web
front-end,
  even a fully REST-ful Web interface.

  >
  > > Huh?  The SOAP paradigm gives a single framework -- XML, headers,
  > > intermediaries -- that provides a place to put semantically meaningful
  > > information in the content of a message that is equally meaningful
  > > irrespective of the transport layers it exploits, tunnels, or
whatever.  The
  > > use case is precisely the fact that it is hard to map semantically
important
  > > information from one protocol-specific form to another, so putting the
  > > semantics in the content rather than relying on "bridging" the
protocols
  > > makes lots of sense.
  >
  > It is hard, but not impossible.  And the good news is, there aren't very
  > many application protocols.
  >
  > The downside of avoiding this hard work by just treating all these
  > application protocols as transport protocols, is that it disregards
  > the very reasons that these protocols became successful in the first
  > place, as well as the useful architectural properties that their
  > associated architectural styles exhibit.  Different application
  > protocol exist because there are different applications.  Email is not
  > the Web.  The Web is not Usenet.  Usenet is not IRC.  IRC is not FTP.
  > And they differ not just in their connectionless/connection,
  > stateless/stateful, asynch/sync nature, they differ because they have
  > different methods that are appropriate to those applications; uniform
  > operations for hypermedia, file/directory-specific operations for FTP,
  > chat channel specific operations for IRC, etc..
  >
  > > Let's take this down a few levels of abstraction and just talk about
  > > personal opinions on best practice.
  >
  > I think I've made my opinions pretty clear in many discussions
  > here and elsewhere.  We're miles apart, obviously.
  >
  > > So, back to "visibility."  I think we have a pretty good outline of
the
  > > costs, benefits, and tradeoffs pertaining to visibility in different
  > > scenarios.
  >
  > Is that true?  Does the WG understand the costs?  You've made it clear
  > that you disagree with the problems I've described with Web services
  > and firewalls.  These are real problems that real developers have
  > already felt, and will continue to feel.  Surely the architecture

  The fact of the matter is that there are trade-offs made every day. You
seem to be
  suggesting that we, and the thousands of corporate IT architects and
executives
  are all a bunch of idiots without the first clue.

  Have you stopped to think, even for a moment, that there may be more going
on
  here than meets the eye? Have you had responsibility for managing a large
  corporate IT environment, with its hundreds of "legacy" (the ones that
work!)
  applications, each requiring some degree of integration with significant
  numbers of its peers? You cannot simply wish these systems away.

  > document should provide some guidance on this?  This, btw, is why I was
  > chasing Dave as hard as I was; so that if it was recognized that
  > visibility was reduced with Web services, even in "single protocol
  > mode" <cough/), that there would be little choice except to say
  > something about it.  I would ideally like to see something like this
  > said;
  >
  > "When it is desirable for a service to be used over the Internet,
  > serious consideration should be given to using the REST architectural
  > style, or other architectural styles which have greater visibility
  > than WSA/SOA (such as those styles used by Internet email, FTP, IRC,
  > etc..).  This recommendation is being made because visibility is
  > important to a firewall's ability to do its job, and firewall
  > adminstrators may choose not to pass messages whose semantics are not
  > as visible as they would like them to be."

  I'm sorry, but REST is not the Web. The Web flourished long before anyone
was aware of REST. And,
  I might add, people were doing all of the "sucky" things with the Web and
HTTP and CGI that Roy keeps
  telling us they should not be doing. Funny how the Web has managed to
survive this suckiness. Makes
  one think...

  You keep making claims that IMO have NOT been proven. They have been put
forth as an
  hypothesis. Where is the proof?

  <snip/>

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