When to use an ESB? messaging with Email/XMPP/SMS

Question

Hi all,

I am adding some more depth to the application by supporting multiple methods for notification. Currently, if there is an exception on the site or an event occurs on the site, an email will be sent out to those users, but I want that to be more generic. I want the users to be able to prioritize their notification methods. If they want to get an XMPP message when they're online, then they will be notified that way. If they're not online, then they'll get an email, so on and so forth.

It seems like an ESB would be what I would want to use here, but every ESB I look at looks like it is heavyweight. Right now, I don't have any intentions of sending/moving files or the need yet for clustering/failover.

I have played with Smack a little bit, and it works well for what I want. It is simply an XMPP client library. I guess after reading these responses, I have to determine how much do I gain from Apache Camel or Active MQ, etc. The main component I want is the routing engine. I can easily write one of my own, that prioritizes/orders different methods, but I'm wondering if it is more beneficial to bite the bullet now as opposed to later and have to scrap my custom routing engine.

Answer 1

ESBs are very heavyweight. Unless you have a man from Accenture whispering in your ear, I strongly suggest going with something a bit more manageable.

Something like EventBus would seem to be more in keeping with your requirements, or, if you're using Spring, it has a built-in sync/async event dispatcher mechanism that does the job nicely on a single JVM.

Answer 2

ESBs are heavy weight. One of the integration projects should do the trick. Apache Camel and Spring Integration come to mind. Apache Camel already has built in support for Email and XMPP. Spring Integration has Email built in but you'll need to build your own XMPP adapter at the moment but it appears to be on the way see Spring Integration 2.0.

You'll need to build some routing logic in either of these so that when you send a message to a user, it can tell whether the user is online and route appropriately.

Edit: Technically both Apache Camel and Spring Integration could be considered ESBs but they're definitely at the lightweight end of the scale as neither of them enforce a container mechanism. More information on whether Camel is an ESB.

Answer 3

I'd recommend Apache Camel - its very easy to use and comes with XMPP and mail support - along with many other components.

If at a later point, you want to manage camel standalone - you can deploy it in an OSGI container too.

Answer 4

I think for now as I've done in the past with other projects, I will roll out my own message router for the time being. It will be lighter weight and I'll have greater appreciation/understanding for how that stuff works.

The infrastructure I'm using can use a JMS backend, but is currently using the Observer/Publisher model for a single JVM presently. I am using Quartz jobs to handle all requests so the server is not overwhelmed with too many requests. When I scale out to more servers, I can use a JMS queue if needed without changing my code base.

Walter