|
Fabric flavors
Last month, when I discussed the proper use of the HTTP verbs POST and GET, the benefits and
hazards seemed abstract. Recently, though, two compellingly concrete
examples emerged. The first involved a collision between Google's new
Web Accelerator and an application called Backpack, which is built
with Ruby on Rails, a web application framework for the Ruby
programming language. This was an unfortunate but timely demonstration
of what can go wrong when HTTP-based software fails to distinguish
requests that alter resources from requests that do not.
The second example involved Coral, an open
content distribution network, and underscored what can go right when
the rules of the road are respected. HTTP's proxying and caching
features can do much more than we usually imagine.
...
Think how much speed -- and
how many nines of reliability -- could result from a deployment of
Coral approaching the scale of BitTorrent.
If intermediaries can't distinguish between fetch requests and update
requests, of course, we'd wind up with an Internet-scale ugly mess.
But if applications play by the rules, they could leverage such a
network to deliver content, and even services, with speed and
reliability beyond their normal means. Peer-to-peer isn't the
cocktail-party topic it was a few years back. But it's still
percolating, and it will create a world of opportunity for
well-behaved HTTP applications. [Full story at InfoWorld.com]
One of my panels at our recent pair of SOA forums was chartered to define the SOA platform. In hindsight, "platform" is one of those overloaded words that it's best to avoid. Nonetheless we took at stab at it, and I'll summarize our conclusions. The SOA platform controls the space between service boundaries, as opposed to the operating-system and application-server platforms which control what happens within service boundaries. Some examples of infrastructure that's shared across service boundaries: messaging, routing, caching, intermediation, policy enforcement, metadata.
A lot of successful applications today rely on a common messaging substrate but, beyond that, it's hard to point to much shared infrastructure. And that's true for both of the competing styles: REST and Web 2.0 versus SOAP and WS-*.
I've come to regard this as a good thing. We frankly don't know just what that shared stuff between service boundaries needs to be, and parallel evolutionary paths are a healthy way to find out. The SOAP and WS-* crowd are running a bunch of experiments. What this week's column made me realize is that we can, and should, run similar experiments in the realm of REST and Web 2.0. The notion of a service fabric applies in both cases. And in the case of REST, the notion of HTTP as a fabric -- though it's been around since the beginning -- has yet to be fully explored.
|
NEWS 
