09.20.07

In the time since SOA has become an “IT” technology (or pattern, if you prefer, since SOA is not so much a technology as a design pattern…), there have been some surprisingly vigorous debates about whether SOA implies ESB, is complementary to ESB, or is anathema to ESB.  I claim no objectivity here, as the GXS Trading Grid has been designed with a particular point of view on this topic, but first lets get our definitions clear…

SOA = Service Oriented Architecture.  Good luck getting agreement on a definition here, but I would say that is a method of architecting applications and systems using loosely coupled services working together to accomplish a purpose.  The trick is to do this in such a way that the services involved can be reusable, so that all of the inherent efficiencies of code reuse are realized.

ESB = Enterprise Service Bus.  Another one that is difficult to define, but at a minimum a standard asynchronous message bus that all or most of an Enterprise’s applications utilize to communicate.  The “ESB” was popularized by Sonic Software (a division of Progress Software), with their phenomenal product SonicESB (not many pieces of software can define a new category) — but now most EAI/middleware vendors (think webMethods, TIBCO, etc) have competitive offerings.

So is the relationship between SOA and ESB just some esoteric technology discussion?  No.

The root of the argument is that an ESB becomes a “backbone” through which all communications flow, and thereby tightly couples services via that backbone.  It may seem a small matter, but the “loose coupling” concept is key to SOA.  But, at least with the GXS Trading Grid, there is a “third way”, which borrows from both points of view.

GXS Trading Grid is GXS’s service infrastructure for providing B2B services to our customers and their trading partners (base level messaging to full-blown process collaboration, and everything in between) — but for my purposes here, it is a service oriented architecture.  Services are able to invoke one another in realtime to do “work” (this is referred to as synchronous, because the two services are working together at the same time, or in synchrony), which is typical for “immediate” processing like authenticating a user or checking the status of something.  This is implemented in the traditional model with independent services “talking” to one another directly (the agreed method of “talking” is the interface, or contract).

This is a really easy model to work with, but very challenging to scale, and scalability is our number one priority.  The reason this is challenging is that you have to have enough capacity to respond immediately (within microseconds anyway) on every service!  This is hard to do across the board.

To put it another way, it is reasonable to expect that a grocery store will have a can of chicken soup for every customer that wants one, but not that there will always be available checkouts — no matter how crowded the store gets!

The checkouts (and the deli counter, and the pharmacy) are asynchronous services, and they can scale very effectively (a store can open more checkouts, or increase staff at the deli).  However, there must be an infrastructure (the rows of cash registers, the deli counter), and that is the Enterprise Service Bus.

Because of its ability to handle load without loss (work queues up), and its dynamic scalability (a good architecture lets you add capacity on the fly), we build as much as we can in the ESB model (this is how we have implemented all of our on network translation capabilities, for instance).

By implementing a Service Oriented Architecture on top of an Enterprise Service Bus, you can have the virtues of SOA, with room to grow.