Enterprise Service Bus: Lasting concept or latest buzzword?


News: Enterprise Service Bus: Lasting concept or latest buzzword?

  1. A new term has appeared in the field of application integration: the "Enterprise Service Bus" (ESB). According to Gartner ¬ďAn ESB is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow."

    A new article by research firm Techmetrix looks at the motivations behind ESBs, and their likely impact on the middleware and software market.

    Read Enterprise Service Bus (ESB): Lasting concept or latest buzzword?.

    Threaded Messages (9)

  2. Login for Article[ Go to top ]

    Floyd, do you guys have guidelines for linking to sites that require a login to read an article? I personally feel it is a bad idea but I guess you guys feel it is a necessary evil?
  3. Please note when login is required[ Go to top ]

    I don't mind having links to sites that require a login, but please note -- in the cover blurb -- when it will be required and whether it is free.

    Just my 2 cents.
  4. Login required to read the article[ Go to top ]

    I would never register in any site just to read an article. My mailboxes are already full with junk mails from such sites. I think you guys should not link to article requiring such logins even it's for free.
  5. Login required to read the article[ Go to top ]

    I would never register in any site just to read an article. My mailboxes are already full with junk mails from such sites. I think you guys should not link to article requiring such logins even it's for free.

    The simple solution here would be to create yourself a junk email address from say Hotmail and use that to register with such sites. That way your real email address is not cluttered with promotional offers.


  6. The simple solution here would be to create yourself a junk email address from say Hotmail and use that to register with such sites. That way your real email address is not cluttered with promotional offers.

    Of course I should have also stated that, naturally, this does not apply to The Server Side :o)
  7. Hop off now[ Go to top ]

    Oh no, not another message bus!

    I'll wager that, after wrestling with big ESB implementations for a while, hub and spoke systems will suddenly regain their attraction.

    The reasons for scepticism may not be particularly obvious, but they are pervasive: security, integrity, resilience, manageability and performance
    are all aspects that typically take a turn for the worse when a message bus model is attempted.

    A few supporting theses I'd nail to the door:

    Security: Messages destined for more than one party must be encrypted using a key known to all parties. Any requirement to discriminate between them requires
    creating new keys for new combinations of parties. Also, per-message encryption is typically much more expensive than transport-level encryption since there is
    no end-to-end session. Hub and spoke or PTP links, by contrast, can usually get
    away with something like SSL.

    Integrity: Message buses and sensible transaction models do not mix well. One might guess that the ESB model originated from the world of simple atomic events
    such as stock price changes - it's really quite unsuited to corporate transactional data. One problem is as basic as getting messages delivered in the right order - buses often encourage the separation of messages which
    actually have some dependence on each other into separate 'topics' or 'subjects'. Once information originating from distinct transactions
    has been fragmented into different channels, recovering the real order
    of events (such as the relationship of an order to a change in customer details or price) becomes very difficult. Another problem is that buses can
    (with luck) participate your application's transactions, the message store supporting XA or similar, but they don't bother bracketing those messages that originate from a specific transaction in any sort of context - this
    information is generally thrown away, leaving a receiver to reconstruct
    the transaction by inference.

    Resilience: probably the most serious problem with message buses relates to their asynchronous, "push" nature and impact this has on architectures requiring any sort of resilience. In a configuration where a sender fails (the sender can be the bus itself, if you wish), and a receiver must switch over to another sender, how is failover coordinated so that messages are not lost or duplicated? The bottom line is that any practical message bus configuration cannot guarantee this, since the overhead of the necessary bulletproof synchronization between alternate senders is prohibitive. The solution lies not in ever-more complex coordination protocols, but in simply letting receivers have control - they track the messages they've received, they failover to a new sender. The old-fashioned, point-to-point "pull" model wins hands-down here.

    Manageability: an esteemed acquaintance of mine used to remark that 'there's no such thing as asynch guaranteed delivery'. I think he means that, whatever level of checks you build into your 'asynchronous' platform, the message isn't delivered until the destination application says it is. I don't care if my message bus tells me that I already received a message - I might have done, but I failed to process it properly, I timed out, my transaction deadlocked, I've been down and my database restored etc. Again, the principle here should be that the receiver has control - if it wants to re-receive a message then the sender should be able to retransmit it - no questions asked, no manual intervention required. Message buses are hopeless at this - their whole ethos revolves around sending something once for all parties, and if someone fails to process it then it's hard luck. To get around this, implementations that I've worked on have added belt and braces in the form of a message history cache on the sender side (in case we need to resend), and on the receiver side (in case we need to reprocess received messages). With this level of complexity, needless to say recovery is far from automatic and in terms of manageability such a model introduces a huge manual overhead.

    Performance: Perhaps the most unexpected accusation to level at message buses is that of poor performance. Don't they have a more efficient model of communication? Doesn't sending a message once, asynchronously, for all destinations mean a massive reduction in processing effort? Well, not really, at least not so as you'd notice in most situations. The first problem is that for reasons described above, you may well be sending the same message multiple times anyway (different security principals, retransmissions, delayed transmissions, almost-but-not-quite compatible formats...) And any sort of reliability requires synchronization to be reintroduced, so we're back to the equivalent of RPCs. The second problem is the remarkable lack of batching capability in most message bus products. I have yet to find a product that allows a receiver to accept a batch of 20 messages and process them in one transaction when appropriate - any batching has to be implemented at the (sending) application level, where of course it has no idea of the receiver's circumstances. A third problem is that a message bus is also a message store, and the storing of messages must be transactional to be reliable, meaning a 2-phase commit with each party's database. This is an example of what I call the message bus "negative value proposition": Would you like the most critical transactions in your system slowed down by an order of magnitude (approximately)? In a point-to-point model, messages would typically be stored by the sender in its own database, something which incurs a marginal overhead in most applications. In a message bus model, passing the message to your friendly local infrastructure introduces a significant overhead. (It's also a pain to configure as determining XA compatibility is an uncertain science).

    So there you have my arguments in favour of the status quo. We shall see if the magic dust of "loosely-coupled Web Services" manages to obscure the fundamentals and establish yet another breed of infrastructure for us to deal with. Certainly there is a role for web service 'orchestration' or workflow, but such systems should be built on established and, above all, practical models of information exchange.
  8. Having worked with both bus and hub/spoke architectures, its worth mentioning that a bus is typically a series of interconnected hubs. The "bus" name is normally misleading (it's usually a network, not a daisy chain) - but let's not worry about that.

    Taking Alex's points one at a time:

    a message server can use SSL or any other form of transport level encryption too; either for sender->server, server->server, or server-receiver connections.

    The whole point of a message bus is to register an event within the (sending) transaction and then let the transaction complete; related "background" work can then be handled asynchronously with the original transaction. There's a trade off here between immediacy (it's great to update your general ledger, change your warehouse inventory, modify your manufacturing schedule etc) and practicality. At some point, you will find systems that either (a) can't be tied into your original XA transaction or (b) are too slow or (c) may be offline when you need them. Messages from a single transaction ARE delivered together, in order; hopefully the message content provides adequate context.

    Resilience - push vs pull:
    I agree that pull is good; message passing allows sender to push and receiver to pull more or less independently (ie the sender doesn't have to wait for the receiver). It's true that the receiver may want to restart from an earlier (already received) message; many message buses don't support this (JMS doesn't require it, for example, except in the more limited sense of durable topics) - but there's no reason in principle why not.

    This is a fair point (for hub and spoke systems too, which as I said are just the simplest case of a message bus). Even if you successfully deliver a message to an application, and it successfully "commits" the result, can you be sure that the whole datacenter wont be flooded or burnt down, requiring a recovery from last night's offsite backup (and re-application of all messages)? You can pay for offsite hot backup - you have to decide if it's worth it or not.

    Another aspect of manageability is "tunability". Message networks offer this in spades - being able more easily to balance the workload between senders and receivers. Need 5 senders to every 7 receivers? no problem.

    The potential performance issue with a message network is not throughput; it's latency. A message may pass through more than one hub (message server) on its way from sender to receiver. On the other hand, the message network can optimize message traffic to multiple receivers (eg, send one copy of the message across the WAN or internet to each local message hub). Only the last (local) leg of the journey is replicated. A single hub can't do this. And neither can a peer-peer system (unless it is layered over a message network!) - in effect a P2P system is a message network where each peer is a message server.

    Meanwhile, 2PC issues can often be sidestepped by combining the message store into the application RDBMS; many JMS implementations give you the option to do this. And sure, it is possible for sender and receiver to work in different batch sizes.

    In summary:
    - yes, ESBs are premised on the message bus (or network)
    - yes, of course there are tradeoffs involved in moving from synchronous to asynchronous patterns - but with messaging used extensively for the last 12-15 years, we already knew that
    - no, message based systems do not have to be "10 times slower". Au contraire, except in the most trivial cases (one sender, one receiver) they should offer better throughput, more manageability/tunability/scalability etc.
    - being more loosely coupled, message based systems are easier to develop and maintain than synchronous systems.

    We do need to be careful as message based systems meet web services (where some inter-node communication may have to be over WS-Reliability or some such, and a "message network" may contain sub-networks provided by different vendors) but that should be something to welcome, not to fear.

    Regards Nigel
  9. Nigel,

    Thanks for taking the trouble to respond to this rant.

    I appreciate that messaging middleware is a rather broad church, but my impression was that the article was specifically contrasting a bus model with hub and spoke and PTP ones. My experience has been limited to those widely implemented middleware systems that are definitely buses, with no intrinsic provision for the more exotic network structure you refer to.

    Unfortunately the article makes no mention of where messages might actually be stored, making the intended model rather difficult to divine - no doubt such concerns are mere detail when one has a whole new paradigm to expound...

    Regarding the points you raise:


    While it's true that a messaging system can use SSL for transport, the point is that, unlike a point-to-point arrangement, SSL isn't enough. If the bus concept means anything at all, it must represent a common channel for communication between more than two parties, as you go on to illustrate in your points regarding performance. Any end-to-end security must therefore rely on something other than SSL, and in turn this typically means a) expensive per-messaging crypto and b) the encryption and transmission of the same message to multiple destinations, thereby negating the supposed advantages of the bus communication model.


    I don't follow your response here - my problem is not what's inside and what's outside a particular transaction, but how a message bus receiver is supposed to relate to a transactional sender. If no transaction bracketing is transmitted and the order between messages is lost (e.g. fragmented among multiple JMS topics) then a massive overhead is imposed on the logic of the downstream system to recover the proper context. In my experience, typical systems do not deliver messages 'together', nor, in the case of subject/topic distribution systems, do they even deliver in order.

    In fact, I tend to get suspicious whenever 'events' or 'asynchrony' are mentioned in the context of transactional systems - usually customers wanting a bit of "decoupling" are not actually saying that their messages are completely independent and can be processed in any order you fancy, however convenient that assumption might be.

    Resilience - push vs pull:
    We agree here on what's missing from JMS etc.

    I think we basically agree here too. You focus on the rather extreme example of the data centre burning down, my concern is as mundane as a transaction deadlocking or orders being misprocessed (perhaps because of inconsistent 'static data'). I'm sure you'll agree that it's reasonable to expect middleware to be able to resend data on demand in such circumstances, if not after some catastrophy.

    You mention the notion of balancing or tuning networks by supporting multiple senders or receivers. This might work for relatively atomic actions such as web page serving, but my experience is that such parallel features are rather glibly offered by vendors without the necessary health warnings on keeping your transactions strictly ordered. Most systems I've seen that can process orders in parallel are also those that get confused in parallel when some of them are cancelled or otherwise updated.

    I'm afraid I've yet to find a message bus system with truly impressive throughput. I've already given reasons why I think this might be the case. I don't really have such concerns about latency, within reason, to oversimplify somewhat, if someone is waiting for a response this is really a synchronous system!

    I agree that it would be a good thing for a messaging system to permit its messages to be stored in the sender's database, so avoiding the 2PC overhead. Assuming that typical systems really allow this, the only question is then whether it's really worth going to the trouble of installing a messaging system rather than just providing a remote interface to the DB.


    I don't quite see how you've arrived at some of these conclusions from your earlier statements.

    Performance remains a concern for the reasons given, with the exception of the 2PC overhead which you assure us can be avoided with the cooperation of some implementations. Although at the brochure-level, sending a message once for multiple recipients *should* be faster than point-to-point links, my point is that thanks to security and retention/retransmission/delay issues such benefits are rarely realized - either not all recipients are ready to receive, or the message isn't intelligible by more than one of them anyway. In fact, now that the nightmares are starting to come back, it occurs to me that message bus systems of my acquaintance are particularly bad at achieving the kind of performance needed to quickly recover from downtime, where many messages may be backed up. Their one-at-a-time notify/receive/process mechanism typically fares badly in comparison with some hack like a Perl scripted bulk loader.

    If you're agreeing with my problems on the management front, I can't see how I'm to accept that in 'non-trivial' situations somehow these problems will disappear and the balance suddenly shift in favour of ESBs. My experience is, unsurprisingly, that the more complex the interaction model the more troublesome ESB-like systems become.

    Lastly, I see you bring up an area we haven't yet explored - the fun and games involved in developing and maintaining ESB systems. Fun that is if your idea of amusement is writing code to serialize every data structure to be communicated over the bus, and the subsequent maintenance of the consistency of these structures across widely differing systems. (Remember that the old hat RPC systems have always been able to generate the necessary serialization code, and typically have very simple means of sharing structural information). Perhaps this is not entirely the fault of message buses - RPCs do after all fit more neatly into typical program models - but it still adds up to another "negative-value proposition" for messaging systems to overcome. And, seriously, ask yourself if ease of maintenance the first characteristic that comes to mind regarding the message integration systems you've worked on!

    So to belatedly conclude, I don't think that the problems I describe can sensibly be characterised as tradeoffs between ESB and hub or PTP models. For the kind of general corporate EAI systems we've both alluded to, it seems clear that the balance weighs heavily against a broad investment in bus-like technologies.

  10. As one who worked with ESB for a bit, currently being in a reasonably large financial organization, I feel like I should be able to comment.

       - Generally, unless you expose your ESB to external parties, you can live either w/o on-wire security (because your most dangerous people are actually users and DBAs), or with one key. Moreover, very often you're more interested in ensuring that people can't modify data than reading them. Not to mention I don't see what advantage P2P has over ESB in this - if my client needs to talk P2P to three other different applications, why should it differ how I encrypt my messages? Surely you don't claim that RPC is more secure than sending a message?

       - If you use ESB to replicate RPC, of course you would have problems. Bus is good at solving some problems, not so good at others. For example, a trade can be booked, which also sends a confirmation fax, GLs the information and prepares the payments. All of these are essentially non-connected (i.e. I can GL w/o a confirmation fax) so they are not the same transaction. One of the can fail w/o causing any problems with the others. But maybe I don't understand your point.
       - Ordering _is_ a problem. On the other hand, ordering of events is a problem in a lot of situations, not just ESB. In most situations you can manage it if you are aware of it - and I'd agree that ESB tends to hide it.
       Quite often you can safely discard out of order messages (i.e. recieving msg 4 after you received 7). Not always, but often enought for it to matter (for the same reasons as why optimistic update works well enough in a lot of situations)

       - saving the information to DB and then sending out a notification is quite different from having remote interface to DB. If nothing else, your receiving application would have to poll the database. Not very efficient thing at best times.

    Re - fun with maintaining (especially the structures). XML helps here a lot. XLST as well, as you can then build components that translate between versions etc.
    I could point out fun with P2P (especially if they are built on RPC) systems when it comes to upgrades of one side - or even worse when they are so linked that both of them have to be upgraded at the same time - or doing parallel runs. With ESB, you can run your beta in parallel w/o much troubles.

    If your enterprise has a fairly linear workflow, then it makes sense to use P2P. If, on the other hand, a change in one system can (independently) affect a number of systems (as tends to be the case in financial institutions in my experience), I would say ESB has its advantages.
    ESB is not a silver bulet. Neither is P2P. Unfortunately, almost every vendor sells his solution as "this is all you're ever gonna need".