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.
Former URL: http://weblog.infoworld.com/udell/2005/05/19.html#a1235