Enterprise buses and dirt roads

The emerging focus on SOA (service-oriented architecture) is creating a fleet of buses. I'm hearing names such as enterprise service bus, universal Web services information bus, enterprise information bus, and message bus. According to my New Penguin Dictionary of Computing, a bus is "the electrically conducting path along which data is transmitted inside any digital electronic device." Inevitably, though, vehicular metaphors creep in, as when Cape Clear'sAnnrai O'Toole said that "the information bus runs on a dirt road."

In other words, humble protocols such as HTTP and SMTP are, by virtue of ubiquity, the only possible substrate for XML Web services and for the service-oriented architectures we'll layer on top of them. This argument often takes an apologetic tone, as though the success of these protocols were an accident of history. Instead of apologizing, we should pay closer attention to the reasons for that success.

Internet protocols, and the applications built on top of them, are remarkably open and flexible in ways that we've yet to fully exploit. XML Web services embody one kind of openness: the use of human-readable and program-friendly data formats, both on the wire and on disk.

Service-oriented architectures will exploit another kind of openness: the ability to inject proxies into communication paths. HTTP and SMTP are inherently capable of proxying. We're familiar with server-side proxies that cache Web pages, monitor access, and rewrite mail messages. Less familiar but equally powerful are the client-side versions of these proxies. For years, I've used a local Web proxy called Proxomitron (www.proxomitron.org) to monitor and filter my connections to Web sites. I've also experimented with Zoe (http://guests.evectors.it/zoe), a local e-mail proxy that creates a searchable index of your e-mail and builds categorized views.

SOA vendors emphasize the notion of proxying SOAP traffic. But when push comes to shove, they'll work with what you've got. The first version of Confluent Software's Core -- a Web services monitoring and management platform -- enforced security policies and guaranteed service levels only for services that presented SOAP interfaces. The new Version 3.0 is more promiscuous. Now, even if your legacy system uses FTP to ship data, you can still use Confluent's overlay network to declare that transmitted files must use WS-Security encryption, and that transmissions must meet a service-level agreement.

This declarative approach is the real essence of SOA, though not a new idea. I trace its lineage to MTS (Microsoft Transaction Server), which begat COM+ and J2EE. All these middleware technologies pull services (transaction management, connection pooling, etc.) out of components and weave them into to the fabric in which the components are deployed. "Just write to COM," Microsoft told developers, "and we'll take care of the rest." It sounded great, but with COM and then COM+ and EJB, that first step was a doozy. Tools and frameworks have done a lot in recent years to reduce the complexity of these programming models. But the tools and frameworks can also add complexity.

As vendors begin to identify themselves with SOA, I hope they won't apologize for the dirt road or demand that we pave it. SOAP traffic flowing over the Web and through e-mail isn't a bad thing. We already know how to proxy this stuff. We're about to discover a whole new set of reasons to do it.