Architecting the Bus, Part 3

November 16, 2004

Architecting the Bus, Part 3

Having discussed the nature of loose coupling as well as service configuration, deployment and monitoring in an enterprise SOA (service-oriented architecture) environment, we can now focus on the architectural core of an enterprise-service bus (ESB) that brings these elements together into a unified, coherent framework. A framework that supports the tenets of an enterprise SOA: broad-scale application connectivity and interoperability with the ability to dynamically adapt your IT infrastructure to meet the ever-changing needs of business.

The ability to host services and connect services to each other is central to any SOA. As we've seen, services in an enterprise SOA have demands beyond those of typical application components. They need to be dynamically deployed and re-configured independently of one another, often across a network environment. This suggests a capability not found in application platforms, which are designed to support the relatively infrequent deployment of tightly-coupled components and their required resources (such as database drivers). The relationships between components and resources simply don't change that frequently or dramatically in a stand-alone application. Further, an application is typically deployed into a single server or a cluster of like servers, not across various servers in a distributed network. As a result, environments like .NET and the EJB container in J2EE simply aren't ready for the task of managing significant numbers of dynamically-configured services in an enterprise SOA. More hazardous, though, is the very real issue of introducing ever-increasing interdependencies as an enterprise SOA becomes more sophisticated. Recall from our previous discussions that interdependencies are the enemy of flexibility. The dirty little secret of many SOA approaches is the number of interdependencies - and therefore rigidity - that they inherently create. Let's take a deeper look at how message-oriented middleware fits into an SOA as a way of illustrating this issue.

Services that are event-driven (ones that respond asynchronously to business events versus being called in-line like an application function) tend to be more flexible and re-usable than those that are not. This could lead one to the conclusion that simply employing message-oriented middleware solves the flexibility challenge. But most messaging products have no idea what a service is. They simply move messages around; messages that have been handed to them using specific programming interfaces. Each service, therefore, must be written to directly call the messaging middleware and indicate specifically where and how messages should be delivered. This creates the worst kind of a dependency: one that's buried in each application, can't be easily changed, and isn't managed or tracked. Any time the implicit relationship between services changes, such as when altering the routing of messages as part of a business process, the application code needs to be modified and the application re-deployed. How do I even know which applications may be affected? I don't. The situation gets progressively worse when higher-level middleware such as business process management (BPM) and business activity monitoring (BAM) is introduced: the organization is left with a spreading mass of statically-configured dependencies between applications and layer upon layer of disjointed middleware.

Simplifying the situation requires a cohesive services framework throughout the layers of an enterprise SOA (service hosting, messaging, process management, monitoring, etc.) and an architecture that provides the appropriate isolation of concerns between SOA elements. Such a distributed services architecture is fundamental to a well-designed ESB-based product family and separates it from so-called ESB "patterns" cobbled together from older middleware. The services architecture begins with a service container that provides the glue between one or more individual services and the outside world. The container provides the necessary isolation between services and things like specific communication transports, and indeed from the rest of the middleware stack. Service containers are coupled to a distributed management environment optimized for the dynamic deployment and configuration of services across the ESB, and communicate with each other through intelligent communications middleware. This distributed environment manages the orchestration of services within it, so the services themselves don't have to. For example, it can establish paths through the messaging middleware based upon logical flows designed by an SOA architect. Because the SOA middleware is aware of the physical location of services it can automatically route across complex topologies without requiring manual re-configuration of gateways between messaging brokers or clusters. The result is an SOA infrastructure that provides greatly enhanced flexibility and re-use. Dependencies between services become dynamic and managed. Unnecessary dependencies, such as those in application code, are substantially reduced.

Despite this, there are those that claim that the infrastructure for an enterprise SOA can be assembled from existing application platforms, such as J2EE application servers, and "traditional" middleware offerings, such as message-oriented middleware (MOM). The assertion being that no special overarching architecture is required for service-orientation; that merely gluing SOA bits onto the ends of existing middleware is sufficient. While this argument is commercially expedient (it allows a broad range of vendors to enter the ESB market and attempt to validate their claims that ESB is "central" to their middleware strategies), it is also short sighted. Such an approach results in an enterprise SOA that's stitched together through hundreds of unrelated and unmanaged bits of application code, middleware configuration files and process definitions. An enterprise SOA that actually resists change, which is, of course, the kind of mess that SOA was meant to eliminate. What's worse, the vendor will often need to do this work on behalf of the customer because of the complexities involved. When will some vendors stop claiming that you can build an enterprise SOA this way and that, instead, you need a cohesive, unified SOA-based middleware stack? When they have one.

Gordon Van Huizen
Chief Technology Officer
Sonic Software