[Fwd: Don Box, Tim Bray, FOO camp,and loyal opposition [The Mountain of Worthless Information]]

[Matthew MacKenzie <mattm@adobe.com>]

Interesting blog entry...

-------- Original Message --------
Subject: 	Don Box, Tim Bray, FOO camp, and loyal opposition [The 
Mountain of Worthless Information]
Date: 	Tue Sep 21 2004 13:28:35 GMT-0400 (EDT)
From: 	<java.blogs Day's Entries>



A few different facts over the last couple of weeks come together to 
bring you this weblog entry:

   1. New WS-* specs, WS-Transfer and WS-Enumeration, shipped last week.
   2. I met Tim Bray at FOO Camp last weekend, along with Nelson Minar,
      Adam Bosworth, Sam Ruby and a few others whose names escape me
      (sorry, guys), all of whom are Very Bright People.
   3. Don Box is interested to see how people will slowly come to
      embrace the WS-Transfer Zen.
   4. Tim Bray looks to maintain loyal opposition to the WS-* stuff, on
      the grounds that (a) it's the right thing to do, and (b) he (and
      I'm paraphrasing here) doesn't get the whole WS-* thing anyway.
   5. I've been doing a lot of interoperability work and research, so
      I've got a few thoughts on this whole angle-bracketed middleware
      platform that we're building, too.

Here's the deal: Amazon, Yahoo, eBay and others are all finding that 
trying to implement production-quality Web services right now is Hard 
Thing To Do. The tool stacks are still half-baked, the standards aren't 
really ubiquitous nor widely-supported yet (c'mon, folks, we're still 
seeing vendor implementations that are choosing the WS-I-obsoleted SOAP 
1.1 Spec over the WS-I-approved SOAP 1.2 version, we're clearly not 
keeping up with the spec movement), and the specs just keep coming, and 
coming and coming. If these companies, whose very business depends on 
both the traditional consumer chain transforming into a more lucrative 
business-to-business chain, are finding that the WS-* stack is failing 
them, what chance do the rest of us have of making all this stuff work?

This is where Tim Bray comes in 
<http://www.tbray.org/ongoing/When/200x/2004/09/18/WS-Oppo>:

    *WS-Transfer, WS-Enumeration* What happened was, someone on an
    internal mailing list pointed to this, noting that Transfer and
    Enumeration are new things. His commentary:

        WS-Transfer is basically HTTP (GET, PUT, POST, DELETE) using
        SOAP, i.e. HTTP over SOAP rather than the more usual SOAP over
        HTTP. (Really - it isn?t April 1st ;-)) 

    My initial reaction, I admit, was sarcastic, along the lines of
    "Since the thousands of pages of incomprehensible WS-*
    specifications are so far failing to take over the world of
    enterprise applications, what?s clearly required is a few more
    hundred pages."

    But then I got nervous.

    *Not Stupid* Here?s the problem: the people writing these WS-things
    aren?t stupid. In particular, Don Box isn?t stupid. And I?m starting
    to see names of people here at Sun pop up as WS-coauthors; people
    who aren?t stupid.

    Furthermore, when I snarled about WS-Transfer on that internal
    mailing list, Bill Smith, who?s not stupid at all, piped up and said
    "Well, I hear that XXX thinks that this stuff is going to be
    important for what they?re doing in YYY", where XXX is the name of a
    Sun VIP who?s totally not stupid and YYY is his group, one that?s
    really important to our plans.

    *I Still Don?t Buy It* No matter how hard I try, I still think the
    WS-* stack is bloated, opaque, and insanely complex. I think it?s
    going to be hard to understand, hard to implement, hard to
    interoperate, and hard to secure.

    I look at Google and Amazon and EBay and Salesforce and see them
    doing tens of millions of transactions a day involving pumping XML
    back and forth over HTTP, and I can?t help noticing that they don?t
    seem to need much WS-apparatus.

    I?m deeply suspicious of "standards" built by committees in advance
    of industry experience, and I?m deeply suspicious of Microsoft and
    IBM, and I?m deeply suspicious of multiple layers of abstraction
    that try to get between me and the messages full of angle-bracketed
    text that I push around to get work done.

    *Loyally Opposing* So here?s what I?m going to do. I?m going to stay
    out of the way and watch the WS-visionaries and WS-dreamers and
    WS-evangelists go ahead and WS-build their WS-future. Because I?ve
    been wrong before, and maybe they?ll come up with something that
    WS-works and people want to WS-use. And if they do that, I?ll stand
    up and say "I was WS-wrong."

    In the meantime, I?m going to be talking to those other people I
    mentioned; the ones who are actually doing what feels to me like Web
    Services today, and I?ll try to see if there are some shared lessons
    and shared frameworks and shared architectures that emerge, and
    should be captured and documented.

And the fact is, Tim is right: in many respects, for what those 
aforementioned companies are doing, the stack *is* bloated, opaque and 
insanely complex. Why on earth do I need to work out WS-Policy details 
when all I want to do is query for a book's details via a simple GET 
request passing in an ISBN? Why on earth do I need to set up a 
WS-Security token when doing the whole thing over HTTPS is much much 
simpler? Why is Microsoft, IBM, BEA, Sun, and the others seeking to 
create complexity where none is needed?

Because, folks, the complexity isn't needed /yet/. And therein lies the key.

Look, for what Amazon needs to do /right now/, the whole WS-* stack is 
horribly overkill. The same would be true of a Java developer looking to 
do a file upload turning to the J2EE stack to do it, or a .NET developer 
looking to do a simple ping and doing it via EnterpriseServices. The 
stacks weren't meant for the simple stuff, they were meant for the hard 
stuff, such as when I need to securely send a message across multiple 
network hops, including potentially different transport mechanisms that 
don't support wire-level security. That's something that HTTPS cannot 
buy you.

The thing of it is, REST and the WS-* stack aren't mutually exclusive 
ends of the continuum, and the beauty of it is, SOAP is what makes this 
doable. SOAP 1.2 (not 1.1, mind) is just framing and extensibility rules 
for XML packets, nothing more, nothing less. It's just a standard place 
to put extensions (like WS-Addressing, which you'll need as soon as you 
get out of a point-to-point model and start wanting to pass these 
messages around internally, via some kind of workflow model or routing 
model; see "Enterprise Integration Patterns" for more of what I mean) 
where others will know to look for them. Overhead? Not much--in a 
barebones SOAP packet, we're talking two additional elements: the root 
Envelope element, and the immediate child Body element in which your 
payload can comfortably snuggle. It's overhead, I'll grant you, and 
you'd be stupid not to wonder, "Can't I just send the payload directly?" 
But the payoff comes the day when your boss turns to you and says, "Oh, 
by the way...." THAT's when having a place for headers and other 
out-of-band information (including headers for your own use) comes into 
play.

Tim's right--for what Amazon and eBay and some of the others are doing, 
which is to say, basic point-to-point communication right now, the WS-* 
stack is really a horrendous waste of time and energy. But the beautiful 
part of all this is, you can pick and choose parts of the WS-* stack to 
make use of, and only use those parts that are meaningful to you at the 
time you need them, so long as make that first step to using SOAP as the 
basic message framework instead of your own homegrown thing.

As to the usefulness of WS-Transfer? Well, time will undoubtedly tell, 
but it's been becoming more clear that just approaching everything from 
a WSDL-oriented "it's just RPC" model wasn't going to work. WS-Transfer 
runs the danger of being misinterpreted as "let's create remote objects 
with just Get/Put/Delete options on it", but if it helps to perhaps mend 
the rifts between the folks who are trying to get by on a RESTful model 
and the folks who insist that "if it don't say WS- in front of it, it 
just ain't worth spit", I'm all for it.

But as for Tim, I staunchly encourage and support his loyal opposition; 
not enough people are doing so, I think. I try to sometimes, but I don't 
really spend enough time in the WS-* space to really be able to 
cohesively argue against Don (among others). What I do know, at the end 
of the day, is that if the WS-* stack is too hard to use, programmers 
will turn to something else and Get By with that: CORBA taught us that, 
if nothing else.