Architecting the Bus, Part 1

September 14, 2004

Architecting the Bus, Part 1

I'm reminded all too frequently that despite all the discussion around enterprise service buses (ESBs), we have not yet arrived at a common industry definition for what one is. Aside from the oft-times substantial differences in functionality between vendor implementations—or indeed the debate over whether an ESB product is required for building an ESB—I believe that the main thing holding us back from agreeing on a common definition is the issue of architecture. Many ESB definitions remain oddly silent on a number of important architectural issues, such as the service interface model, run-time capabilities like service configuration and deployment, and the relationship or binding between services and the middleware that spans them. The implication being, I suppose, that as long as an ESB contains the main ingredients (nearly-universally agreed to be messaging, Web services, intelligent routing and transformation) that its architecture doesn't matter. The reality is that it matters a great deal. Architecture directly affects how flexible, manageable and scalable an ESB actually is. Perhaps what's needed, then, is a way to discuss ESB architecture in tangible terms. Allow me to put forth a few ideas to that end.

Loose Coupling: The Key to Flexibility
There's been a great deal of attention paid lately within software architecture circles to the idea of "loose coupling". And for good reason. Historically, applications and systems have suffered from too much rigidity: it's simply too hard to change things once they've been built. While this is problematic for stand-alone applications, it's often catastrophic for large-scale systems. In today's operating climate, it's vital that I be able to rapidly adapt my IT systems to support changing business conditions. If the time and cost of change is too high, I can't do that. So how can I build flexibility into my systems? By minimizing dependencies between components within them. That's all loose coupling really means: minimizing the dependencies between things. There are two main areas to consider when connecting applications together: the interface model, and the relationship between an application and other applications (and indeed the relationship between the application and middleware, which we'll discuss later).

The interface model most familiar to developers is that of the client/server model, in which a carefully crafted client application interacts with a server using a (hopefully) well-documented interface. This is inherently a tightly coupled architecture, in that the client application includes a reference to the server's exposed interface, and therefore will have to be modified whenever it needs to talk to a different server. What's more, if the order in which applications interact needs to be changed—to support a new business process, for example—I would have to alter and re-deploy the affected applications. Not really a flexible model, is it? But this is the model that most Web services embody today. A more loosely-coupled alternative is to use a message as the contract between applications. By passing messages back and forth, applications are none the wiser about the applications they're calling and who they in turn are being called by.

While this is a strong start, there's more that can be done. Most messaging applications today are written to employ programming interfaces of the middleware that they use. There's no longer a dependency introduced by calling another application, but the so-called interaction model—how messages are moved between applications—is built into the application itself. If I want to change the interaction model, I'm back to re-coding applications. This leads to the first key architectural difference between ESBs and messaging-oriented middleware in general: services in an ESB are said to be "event-driven". Instead of building interaction patterns into applications by calling specific messaging system APIs, the applications simply respond to events and emits event. The ESB is responsible for implementing the required interactions between them, optimally through tool-driven configuration instead of coding. I'm free to change the interaction model from a basic messaging construct like point-to-point or publish-and-subscribe to an intelligent routing scheme, or even use a BPM engine to orchestrate service interactions—all without touching a single line of application code in the relevant applications. They're none the wiser.

We've begun our descent into ESB architectural concerns. Next time, I'll discuss service configuration, deployment and monitoring. I'll conclude by discussing a unified, coherent architecture for connecting enterprise services, and why it's necessary.

Gordon Van Huizen
Chief Technology Officer
Sonic Software