Edwin Khodabakchian reports
on an Adam Bosworth presention entitled
The Next Inflection Point.
Adam’s an extremely bright guy, and I’m fully expecting him to have a
“REST epiphany” ahead of most others due to both the depth and bredth of his
experiences. But while this is an extremely interesting presentation, there are
some claims that just don’t synch up with the current approach taken with Web
services. In particular, there’s this quote which Edwin pointed out;
We will look back in wonder and ask how we ever survived in the current anarchy where information did not flow as seamlessly and as metered and managed a manner between programs as electricity flows between devices today.
Whether or not you agree that Web services are the next big thing, I would
expect that most people would see the problems in this statement; data flow with
Web services is anything but seamless.
“Seamless data flow” derives from a data flow architectural style in which
components expose a common (no, not necessarily uniform 8-) interface. The
example I’ve used before is
pipe-and-filter,
ala Unix, with stdout/stdin. Non-common (i.e. component-specific) interfaces are
notoriously difficult to compose, and therefore anything but seamless, because new glue
code has to be written for each set of components that need to be composed (the old
integration-complexity argument, O(N^2) or O(NlogN) for Web services vs. O(N) for the
Web).
So I’m all for seamless data flow, but Web services simply don’t have it.
Simon responds to my
comment about ERH’s message;
Does that alienate people? Yes! It should. I’d love to get the Web Services folks to rethink their foundations. Failing that, making clear that there are serious points of friction seems like the best course of action – and being civil has little to contribute to that. Forking is not a risk here – it’s an opportunity.
We’re in complete agreement about that. Where we may differ, is about
the timing; I think the time for alienation has passed. I’ve personally been doing
it for over three years now, and have alienated my fair share of bright and well respected
people (which has come back to haunt me during my search for work, sigh .. but such is
the price of grokking this stuff). I believe the time is right – or at least fast
approaching – to take advantage of the increasing frustration being felt by some Web services
developers who have realized that there may be something to this other way of doing things
that they’ve heard about.
But, I could be wrong, which would be fine by me; it’s a lot less work to alienate. 8-)
Clemens Vasters writes;
I am sorry to say that, but if today you still believe and insist that XML is just another data format, the train may already have left the station for you.
Well, then I guess my train is long gone. Ouch. Sorry Clemens, but
XML is just a data format. Now, good data formats like XML are
nothing to sneeze at, and I’m glad we have it, just like I’m glad we
have/had ASCII. But for heaven’s sake, it’s just syntax, a
context free
grammar.
He also stated;
One of the core messages of my talk is that the XML InfoSet is the focus of integration.
IMO, this is like saying C structs are the focus of integration. Ok, so
you and I agree on what one is, and perhaps even how its represented. Now
what? How do we integrate? We can’t, at least with just that shared knowledge.
If we also shared a model for how to identify, exchange, and manipulate them,
then that could form a focus for integration. Which is, of course, akin
to what REST tries to do around a more general abstraction called a resource.
ERH writes (grr, no permalinks);
It’s interesting that the Web Services community has managed to
alienate three different communities for three different reasons that all
derive from not understanding or accepting
the basic principles of the technologies they’re building on.
They’re either geniuses or idiots. My money’s on idiots, but time will tell.
He’s certainly right in the first part, that these groups have been
alienated; “XML” because of the subsetting and arguably the suitability
for the task, “Security” because of tunneling, and “Web/HTTP” because it
has nothing to do with how the Web works and generated its value in the
first place.
But the “idiots” comment is totally out of line. People have suggested
in the past that I’ve suggested they are idiots during my evangelizing of a
REST based approach to Web services, which really hurts, though
it’s certainly understandable; nobody likes to be told that they don’t understand
something. But that’s all that’s going on here; they don’t currently
understand. It’s absolutely not a statement about anybody’s capacity, or
lack thereof, to learn.
I also wouldn’t call anybody an idiot who was proceeding based on their
best current understanding of how distributed systems are built, when that
understanding is built from years of hard-learned experience. Unfortunately,
practically every Web services proponent I know, gathered their experience
in a LAN environment, which is a very different place than the Internet,
requiring very different solutions. I’d just call them people who need to
broaden their horizons.
So please folks, try to keep it civil. Comments such as this one
only serve to alienate, which is the last thing we need.