Skip to main content

Dealing With Rapid Change

Posted by doj on January 16, 2006 at 5:19 AM PST

At the heart of virtually every application that my team and I work on, is the logic that implements a business process. Being involved with web applications, we're all about exposing business processes through the web.

As web developers, we're always trying to think in abstract terms - to make the logic as configurable as possible; trying to produce a generic solution that can be tailored to the specific need. This takes a lot of time. Time spent planning architectures, modes of operation, hot re-configuration and many more aspects. This is because the nature of our business demands that these processes undergo constant (and sometimes complete) change.

Being that we use Java as our platform of choice, one of the drawbacks of our traditional development model is that it is quite viscous - that is, making changes is a little like walking through molasses! Our applications typically use a framework like Struts, and we've been good little developers and separated the logic from the presentation. With the logic all neatly tucked away in a variety of classes, any change to that logic needs to be configurable at runtime, or else a new build will need to be made - and we know how time consuming that can be!

This got me to thinking some time ago, a variation on the mythical Service Oriented Architecture (SOA). Why don't we build out discrete services, that we glue together with some kind of scripting language that's interpreted at runtime. This seems to have a few advantages:

  • We can move the logic into script, this script can be modified on-the-fly to adjust the logic of the application.
  • If we pick a scripting language that's familiar or easy enough to learn, perhaps we open up the logic to be maintained by "power users" or support staff.

Of course, nothing comes for free - this approach does have some drawbacks that I'll leave as an exercise in thought. But does this represent a possible way of leveraging the benefits of SOAs without the full overhead of Web Services and the associated set of technology? There's also the world of Rules Engines and technologies to express business processes - but these can seem a bit formal and not so much open to gluing things together. There's an awful lot of cool systems out there bound together by duct-tape and superglue :-)

I'm a big believer in keeping things simple. Fortunately for us, with a JavaScript engine based on Mozilla Rhino coming with Mustang, this notion may well be a first-class option for consideration when planning that next big system. Food for thought.