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

+1

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Sunday, March 02, 2003 12:09 PM
To: 'Christopher B Ferris'; www-ws-arch@w3.org
Subject: 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