I’ve been on a language and infrastructure kick for the past month or so
and posts have reflected that. Unfortunately this means I haven’t had
the time to report on some of the excellent discussion around
simplifying practices at the protocol and format level. Let’s run
through some of this real quick:
Sam Ruby has been churning out good
content on the practical benefits of HTTP and REST architecture,
challenging SOAP/WS-* practioners to consider the immense benefits
resource oriented design offers over the more popular service oriented
(SOAP/WS-*) approaches. The Atom Wiki was slashdotted
but he was able to push the troll-hoards over to an uneditable site due
to HTTP’s redirect capabilities. He uses the occasion to illustrate one
of the many basic features HTTP provides to accomodate massively
distributed and un-coordinated environments that SOAP/WS-* completely
ignores:
The foundation for most of this is rooted in the tantalizing phrase
“hypermedia as the engine of application state”. If one views a wiki
as a state machine,
then being able to do a redirect is effectively changing the
programming of the application.
The fact that I was able to do all this with but a single line of code —
and using only the protocols and products that were already installed —
was of great value to me yesterday. In fact, if one were predisposed to
use such terms, I would go so far as to say it was of significant
business value to me.
Sam provides more thoughts and conclussions in REST vs. API, which
he sums up nicely:
At some point, you need to question the wisdom of having an API which
abstracts away that which is important.
In the meantime, WS-* supporters are still trying to figure out how to
fit the square peg of narrowly distributed systems architecture into the
round hole of the web. Infoworld just published a
story
that tries really hard to slap some lipstick on the WS-pig:
Although the vendors backing Web services are confident they are
properly addressing any kinks, Web services remains hobbled by issues
such as standardization and WSDL complexity. To make matter worse, its
impacts are growing, with both the .Net and Java development
technologies focusing on Web services. Additionally, Web services is
doing double duty as the lynchpin of the growing SOA trend.
And just in case there was any doubt that many leading vendors are
completely clueless when it comes to providing tools to aid their
customer’s operations moving to the web:
Microsoft’s Bixhorn emphasized the company’s planned Indigo technology
as the answer to many issues cited with Web services. Due in 2006 in
the Windows Longhorn client, Indigo removes the reliance on Web
servers by extending beyond HTTP to support protocols such as SMTP,
TCP, and REST (Representational State Transfer).
No, no, no! I don’t even know where to begin disecting the problems with
this statement.
You don’t want to “remove the reliance on web servers,” you want to
provide tools that let customers use it for what it’s worth. Web
servers are good! We need to make more and better use of them.
Extending HTTP to “support REST” would be a truly interesting
demonstration as REST is largely a description of the architecture
HTTP facilities. UPDATE: it’s been pointed out
that I may have mis-represented Krill’s intent here. I’m not sure I see a huge difference
but in the interest of rational debate and all that…
<outrage>
TCP?!!@%##! WHAT THE FUCK!</outrage>
I can only assume this was a horrible misprint or that Microsoft has an
automated press statement request robot capable of combining a random
set of acronyms with upcoming product names.
The blogosphere, at least, is injecting some sanity into the
discussion. Mark Baker wrote a nice piece, Towards truly document
oriented Web services,
which does a good job of explaining why the web’s basic architecture has
been and continues to be a perfect medium for “Web services” since long
before the term was even coined.
There were also at least two enlightening articles on Atom’s potential
as a SOAP/WS-* competitor. Bill de hÓra’s Atoms in a small world
is a response to a computer weekly article
making the following claim:
It is clear that there are lots of server-based applications (not
blogs) that could work by syndicating packets of XML data to client
applications (not RSS aggregators). These will not rival Soap/web
services as a system for executing transactions.
Bill responds:
I don’t see why it would not be a good basis for enterprise concerns
like messaging, authentication, or management interfaces. Atom, RSS
and the Atom Publishing Protocol (APP) as a complement to REST could
disrupt SOAP and WS.
I agree but have a slightly different take on how this will be most
disruptive. In my opinion, REST and web architecture is just plain
misunderstood. There’s a lightbulb moment that’s required to grasp it
fully and it just hasn’t went off for a big portion of the business IT
community. RSS and Atom are showing how following web architecture can
yield huge benefits. These technologies are disruptive because it forces
people to ponder whether the web in its basic, unmolested form may not
be limited to web pages. If Atom can find a niche here than that’s great
but I’m more excited by its potential as an agent for enlightenment.
Kurt Cagle follows Bill’s post with some truly excellent examples of
how, in many cases, RSS/Atom can be superior to WS-* techniques in How
RSS/Atom Is Replacing Web Services,
which he ends with a demonstration of “good web thinking”:
While I suspect that this commentary will be poo-pooed by web services
vendors, the history of the web makes me suspect I’ll be right in the
end. RSS syndication has emerged in a largely ad-hoc fashion to
fulfill a specific need - syndication - that seems to be an intrinsic
characteristic and requirement of the Internet. Syndication in turn is
simply a messaging protocol built around a subscription-oriented PUSH
model. If you make the syndication format too complex for people to
use (as I believe is the case with SOAP) then they will migrate to
simpler formats as they become available. Because ATOM is blessed by
both the IETF and the W3C and is seen as an open standard (whereas
questions remain concerning the precise nature and implementation of
SOAP) it will likely continue to gain the mindshare of developers and
users alike.
To sum up, there’s been good stuff all around from the REST / web
architecture guys and the WS-* death march continues on…