Following Paul’s presentation on the subject at New York Groovy/Grails Meetup we have made our Grails-based event-driven SOA proof-of-concept available in GitHub.

Since the project’s page provides enough details about the components, I don’t want to re-iterate the same. Instead, I would like to outline a little bit of background and history behind the prototype, because it illustrates one important sharp turn in the evolution.

At the beginning, as it usually goes, was a problem: set of batch-oriented monolithic systems that gradually grew over the years into a massive spaghetti bowl of  processes and associated business rules. Looking at this grim landscape from the bird’s perspective, the possible solution became eventually obvious. First, we need services to provide low-level business capabilities like offer catalog, customer billing or product fulfillment. Second, we need ability to quickly develop  business flow implementations that wire these services together in any way the business owners could possibly fathom.

Dealing with established hard-core Java environment and being already big Grails fans, the choice of framework was not that hard.  We had no doubts we can build RESTful web services in Grails easily and lighting-fast. However, a little shadow of skepticism crept in as far as the second ingredient was concerned. Wasting no time we dove head-on into prototyping with an ultimate goal of finding out whether or not Grails is a good match for rapid development of “headless” business process orchestrations. And just for the fun factor, we named it Utopia (no pun intended, although I am not so sure about it in the hindsight).

We started off with use case’s happy path implementation. Web service got called as needed, JSON payloads were produced and crunched like a charm. Everyone was happy and the world was just cheerful place to live in.

Until the heavy clouds of failure scenarios took over the sky.

It became apparent that catering to all those pesky rollbacks, retries and failovers spirals quickly out of control. It was getting exponentially harder and harder with every additional service call. I need to point out at this point, the challenge we faced has nothing to do with Grails per se. Nevertheless, the situation called for drastically different approach, a fresh wind, so to speak. So after a short period of silent cursing and coffee sipping, we went back to the imaginary drawing board just to emerge again few hours later with not-so-original idea of asynchronous events.

It did not take long and the things started fall in place and make sense again even for the worst of the error scenarios. Events broke down more complex flows into highly manageable, almost atomic, business operations. JMS re-submit features provided out-of-the box transactional, failover and re-try capabilities.  In addition, we have also gain some interesting side-effects, we did not even think about. For example easier deployment procedures since component downtime is no longer a problem due to persistent nature of the message queues.

Needless to say, we are happy we have reached our goal. A full-fledged system overhaul using Grails-based components, both RESTful as well as event-driven, is currently chugging ahead full speed. Looking at the Utopia today, it seems rough around some of its edges. We still believe though that releasing it may help boosting Grails use in corporate establishments dealing with similar problems. Enjoy!