The Web services grid

By my reckoning, J2EE was conceived at Microsoft in 1996, when legendary database guru Jim Gray was hired to lead the Microsoft Transaction Server (MTS) project. In MTS, which begat both COM+ and J2EE, the COM object was the unit of distributed computation. (For J2EE, substitute EJB for COM.) MTS provided a services fabric into which those objects were woven, and from which they acquired transactioning, load balancing, and object pooling. MTS was repackaged as COM+ for Windows NT 4.0. Now it's been carried forward to .Net Server as the guts of System.EnterpriseServices, the .Net Framework classes that nicely encapsulate the COM+ engine.

The idea behind all this was that an ordinary VB (Visual Basic) programmer could use MTS/COM+ to build scalable, transactional apps. All you had to do, Microsoft promised, was "write to COM." No doubt about it, this was a great idea. One astute observer, Roger Sessions, has said that "COMWare" (COM+ and J2EE) represents "the democratization of the middle tier." The timing was perfect. Just as NT 4 got rolling, the Web began pushing "ordinary" VB apps harder than anyone could have imagined.

Unfortunately, COM's egalitarian hopes didn't quite pan out. Figuring out how to develop and deploy COM/COM+ software proved too arduous for many in the target audience. It was Active Server Pages, not COM/COM+, that became the backbone of the first-generation Microsoft Web. On the Java side of the fence, things turned out pretty much the same. There, the EJB tax is equally onerous. Well-funded enterprises are paying it, but I doubt many feel that J2EE has ushered in a democracy of the middle tier.

I retell this history now because a new, more ambitious services fabric is starting to emerge. In May, Akamai announced the next turn of the wheel for its Edge-Side Include (ESI) technology. ESI began as a distributed variant of the classic server-side include mechanism. It was designed to push dynamic page assembly as well as static content out to edge servers. But now Akamai, in partnership with IBM, is pushing WebSphere itself to the edge in order to create a Web services grid. And it plans to roll out similar support for .Net. It's MTS all over again, but on a much grander scale. You, the programmer, just "write to COM" -- or in this case, to the Web services stack. Then you plug your code into the grid to tap its activation, clustering, and fault-tolerance services.

Meanwhile, a spunky little company in Texas called The Mind Electric is doing the same thing in a very different way. TME's Glue -- a lightweight, easy-to-use, and therefore popular Web services toolkit -- is really the warm-up act. The main event: a services grid that CEO Graham Glass calls Gaia. It's still unreleased, but an early version I saw in June does simple, lightweight clustering and load-balancing of Web services. Those services will be written in TME's Java-based Glue or, it's planned, in .Net. In Gaia, a SOAP server doesn't bind to a port, and neither does a SOAP client. Instead the SOAP server publishes a named interface into the grid, the client asks to bind to that interface, and Gaia brokers the connection. If multiple instances are running, work is distributed among them. If an instance dies, failover is automatic. When new servers come up, clients note their arrival, so if they need to fail over no search is needed.

Will Gridware be the people's choice that COMware wasn't? Graham Glass is determined to prove that Gaia's ad-hoc, peer-to-peer services fabric can make it so. If he's right, it'll be good news for Akamai too. To flourish as the Internet's new software democracy, the Web services grid will need a lot of grassroots support.