I was surprised to see that, in the SOA world, there is some debate as to the usefulness of the Enterprise Service Bus. One reason for this might be the evolution of the term “ESB”, from enhanced middleware to service container framework (a.k.a. Enterprise SOA Bus?). Or possibly the anti-ESB lobby take a narrow definition of SOA (e.g. hierarchy of orchestrated synchronous services), rather than those who include Complex Event Processing within the definition of SOA (e.g. any combination of event-driven, synchronous or asynchronous, independently managed or developed contract-defined services). In the latter case, which includes Event Driven Architectures, ESBs / message buses are a very common / de facto [*1] means of communicating events to, and between, Event Processing systems – indeed “ESB” could be an abbreviation of “Event Service Bus” for the CEP community.
One of the complaints about ESBs seem to be their proliferation and the need to manage appropriate gateways. I would have thought that System Architects would be happy to partition their message buses and domains, just as network specialists manage physical networks with bridges and routers based on configuration needs. Probably the main problem with ESBs is that they don’t fit into some architect’s pure WS-oriented view of the world – but I would suggest this is the architect’s “problem”, not the ESB’s.
Notes:
[1] In TIBCO BusinessEvents, for example, we include default channel adapters for TIBCO RV and TIBCO EMS (which is JMS).
