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