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).
Hear, Hear.
It appears as if SOA has devolved into a client/server or request/response paradigm (as described in the “pure WS-oriented views” that the author references.
It is interesting to note that one of the drivers that we saw for Service Oriented Architectures was Location Transparency. Tthat notion was important because we needed to abstract away the need for a requestor to “know” where a component was located. Well we can certainly go that route in our WS architectures, but the usual way of doing this is to use a DNS like intermediary. To me that is just the wrong way around.
I am still in the kind of declarative model. I want to be able to enale (at least) 2 things. One I want to be able to specify what I want done on my behalf (and not where or how). Second, I want to be able to devolve the responsibility for action to the components that should accept the responsibility. That means to me that whatever is responsible for raising an event should not be required to know which components are “interested” and may take action in handling it. Too many things can happen as a result of an event occurring for the system that raises it to know. Knock-on, downstream and other kinds of (relatively) simple processing are frequently not the responsibility of the event raiser, and frequently should not be in band with the process that raised the event in the first place. That is after all what decoupling is all about. Allowing autonomous organizations to handle things they are interested in in their own fashion. owever, of course we are then in a “non-transactional” environment, and so need different mechanisms to make sure that our systems remain in balance.
So what does this comment have to do with ESBs? Just that a potent ESB with content/context routing, dynamic pipeline operations, genuinely asynchronous behaviors (and synchronous ones too!), the openness to inspect the data streams and the containers to allow actions against these streams is absolutely necessary.
Oh and you might need a parser to interpret that last comment. In the imkortal words of Mark Twain, “I am sorry I wrote such a long letter, I did not have time to write a short one.”