All aboard! The enterprise service bus pulls in
Published: 29 Jul 2004 11:45 BST
Enterprise Service Bus
In some circles, the architecture being described here is called an Enterprise Service Bus (ESB). Scott Cosby, programme director for IBM's WebSphere, cautions that there is no single definition of an ESB. "Each customer is likely to create their ESB in a unique way," Cosby told me. "The most important thing to remember when considering the definition of an ESB is that flexibility is key. There's no fixed way to build one. As long as you have a connectivity layer that optimises information distribution between service requestors and service providers, one that can respond to event, message, or service-oriented contexts, then it's safe to say what you have fits the description."
As a reminder though, Cosby says there's really nothing new about this arrangement. It's a well known approach -- one that application server vendors like IBM and BEA have included in their offerings for quite some time. Where this architecture really starts to take on the characteristics of a bus, much like the bus inside a computer into which adapter cards of various types can be plugged because they're all in agreement with an interconnect technology like PCI, is where standards get introduced. Reflecting on the legacy ESBs in place, Cosby pointed out that 80 percent of the business transactions taking place today are done over EDI. For this reason, Cosby warns against ESB definitions that fail to acknowledge what's already in place. That said, Cosby agrees that XML and Web services are great ESB enablers.
As most people know by know, protocols like XML and SOAP (the building blocks of Web services) have significantly greased the wheels of integration by giving systems that must interoperate with each other something they can agree to -- a mutual understanding of how to read the data, instructions, and service invocations that each system is putting into its message queues. By doing this, XML-based Web services removed yet another factor of hard-wiring from the old school ways of integration. Before, that mutual understanding had to be programmed somewhere into the logic, and the methods were largely proprietary.
Once Web services came on the scene, everything changed. Not only was there a standard language over which systems could interoperate, but the desire to get systems interoperating is on the rise because the obstacles are diminishing. But, as more systems get tossed into the integration fray, the load on the overall architecture increases and, if any one part ends up overloaded, it might not be long before the cracks start to show.
Keep in mind the downside of adding more gears to the mix. If one of those gears falls out of synch, then the rest could end up waiting. The system is not unlike that of a car's engine. An engine's peak performance depends on the precise timing between the process that opens the valves that let the air-fuel mixture into the engine's cylinders, the compression of that air-fuel mixture by the piston that hopefully is on its way towards the top of the cylinder, and then generation of the spark that ignites the compressed air-fuel mixture (the resulting combustion of which pushes the piston back down through the cylinder so as to turn the crankshaft and, ultimately, the wheels of the car). If, in your car, any one component of that process starts to experience a problem, or gets ahead of the others, the engine sputters when you hit the gas pedal.
Between the need for good performance of real-time processes, the requirement of well-timed components, and the increased interest in integration, there are still opportunities to break down the interoperations. While Web services gives systems a common language with which to hold their discussions, there still isn't a lot of agreement over the structure of the data being passed back and forth (known as the XML schema) or the vocabulary. The SAP ERP system may be Web services compliant, but its schema for customer data may be very different than that of the Siebel CRM systems to which the data might be sent. For example, what fields are being tracked for each customer, what are the exact names of those fields, and how long are they?
When two or more systems have different native treatments for what is ultimately the same data, those differences have to be resolved somewhere before they can interoperate. But where should this translation take place? In the application or transaction logic? In the message queue? In the central post office?
The answer, according IBM's Cosby, is basically any of the above. Given the state of legacy systems where this transformation takes place, the ideal solution will be highly situational. At the same time, if you notice that saddling any one of those components with the responsibility of transformation is causing the engine to sputter, you still have options that conform to the notion of an ESB.
For example, why not have a single, common data format to which all interoperating nodes must resolve, and then give each system access to that format through a transformation adapter. This approach where you have software adapters that help adapt the native data coming from each of the endpoints to a common data format where it can move about the "bus" through brokers until it finally comes in contact with another adapter on another system that in turn takes care of the "outbound translation", suggests BEA's Linkin, is clearly in the spirit of an ESB.
Both BEA's Linkin and IBM's Cosby agree that as with any other bus-oriented systems, a management layer is needed. Linkin describes this as a layer that's charged with housing a directory of the services that are available on the bus around which policies can be set and security can be applied.
If you haven't taken a ride on the Enterprise Service Bus yet, perhaps now is the time to check it out.
Previous
Did you find this article useful?
73 out of 143 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
