Friday, March 13, 2009

grails create-app esb

I know it seems like a strange app to create with grails, especially when there a several other capable opensource ESBs available (mule, servicemix, openesb), but instead of asking yourself why, ask yourself why not. While it may not offer all the same features (BPEL) it's certainly a possibility for certain circumstances. This possibility was spawned together with co-worker Kit Plummer when discussing different options for an upcoming story that required email integration. At first it seemed kind of ridiculous, especially since we were already using openesb in jboss, but it started to make some sense the more we thought about it.

So how could a MVC web framework possibly replace a feature complete ESB? Well, first let me explain my background. I don't consider myself an ESB expert, but I do have some experience with ServiceMix and OpenESB (see openesb topics). In fact, my former company, let our team develop and open source 4 JBI Binding Components for RSS, SIP, UDDI, and XMPP.

Here was a short list of complaints I had with running OpenESB v2 in jboss:
  1. At first it was pretty simple to setup, install, and run for a single developer, but trying to duplicate that across a large distributed team and things get more complicated. This included the difficulty of setting it up in all of our CI and beta environments. It's not as easy as just running Glassfish which includes OpenESB.
  2. OpenESB v2 basically required Netbeans, which again isn't too hard for one developer. But asking your team to run a second unfamiliar IDE is no easy task. The OSGi based OpenESB v3 does not require Netbeans, but it does make it easier.
  3. Composite Applications are less than easy to create, test, maintain, version, deploy in CI, etc. At least not compared to a Grails WAR anyways. Being able to consistently do those 5 things over 12-24 months is really bigger than you think.
  4. Security. It's more difficult to lock it down compared to a WAR running in jboss fronted by apache.
Here are some advantages we saw in treating Grails like an ESB:
  1. Easy. Simple. Trivial for everything including: developing, maintaining, testing, deploying, versioning, securing, and installing.
  2. Grails is plugin based and has a growing number of good plugins. One of the main benefits of an ESB is leveraging all the other work so you don't have to write anything. Things like HTTP, JMS, SMTP, JDBC, RSS, XMPP, FTP, BPEL, XSLT, and FILE just to name a few. Granted many Grails plugins are web focused, but there are several similar capabilities such as HTTP, JMS, JDBC, SMTP, RSS, and Workflow. Beyond that writing your own Grails plugin is easy compared to writing your own ESB component. See the Mail plugin as an example of how easy it is to send an email in Grails.
  3. Doesn't require Netbeans. Developers can continue using their favorite IDE.
Despite all of that, I do think the case can be made better for OpenESB if your team is already using Glassfish+OpenESB (or GlassfishESB) and Netbeans. But it does make it much more difficult if your not. And I know that ServiceMix v3 was deployable as a WAR, but that was not it's default behavior. Not sure about the OSGi based v4, but I can't imagine they stopped supporting WAR deployment. Of the two I think ServiceMix reminds me more of a Grails app as far as simplicity is concerned.

There is one big disadvantage to using Grails like an ESB: fewer incoming protocols. I could be wrong on this one but with grails your probably limited HTTP and maybe JMS (outside of setting up quartz jobs and polling). But with an ESB its really unlimited (HTTP, JMS, JDBC, SMTP, SIP, XMPP).

I am sure I am missing several other key pieces, so interested in hearing from others. The nice thing is our implementation is hidden behind a REST API that could easily be supported by a bloated ESB.
blog comments powered by Disqus