Mostly Earless

OpenQuote 2.0 will be an earless release. As I blogged last time, up until 2.0 OpenQuote was packaged into an EAR, but issues with Liferay's support for portlets within EARs has lead us down a different road now, and it's not one I'm sorry to be travelling down.

So, since the latest commits into the 2.0 tree, the EAR is history. Our various JEE components now all sit in the deployments folder and their dependencies are managed using JBoss modules and are resolved at build time using Ivy.

The move to JBoss modules and Ivy was pretty smooth. Very smooth in fact. The only slight annoyance left is that I can't as yet find a way to have Ant resolve classpaths for javac (etc) with respect to modules. What I'd really like to do is to derive a classpath by referring to a bunch of module names, but right now the build still has to do this using combinations of <fileset> and <dirset>. This leads to some duplication.

Even so, this is a big step forward, so the classpath issue hasn't dampened my sense of satisfaction too much.

Of course, Ivy is only part of the picture. Our old dependency repository, hosted at openquotecommunity.org, has done a fine job, but it would have needed some serious restructuring to make it work well with Ivy. So, enter, Sonatype's Nexus! We now have an instance of the same running on openquotecommunity.org.

I have to say, I'd thoroughly recommend Nexus. It was an absolute breeze to setup and configure. The only wrinkle being that I originally wanted deploy it as a WAR in our existing JBoss development server - which hosts JIRA and Bamboo. The WAR deployed okay, but it exhibited some odd authentication behaviour. Logging into Nexus as the default "admin" user apparently worked, but none of the admin menus appeared. Weird.

I put this down to the fact that we're running a pretty old version of JBoss on that server. As we're going to be moving to Atlassian's on demand service, I didn't want to spend time picking about in that particular can of worms, so I installed Nexus as a standalone (Jetty based) server instead. And that works like a dream.

You gotta love open source!

2.0 platform taking shape

I was expecting that the job of moving OpenQuote from the old JBoss Portal/Alfresco based platform to Liferay would be a pretty tough one, but so far... well... it just hasn't been.

The first set of commits are in the 2.0 SVN branch now and are ready for the intrepid to play with. We're not building a binary bundle yet, so you'll have to build from source. What you'll get as a reward for your efforts is a running instance of Liferay based on JBoss 7.1.1 with the OpenQuote backend components all in place, all the product content in place, and a somewhat familiar home page. The unit tests all pass too. It  really couldn't have gone much more smoothy... so far.

The elements that are left are the portlets, themes, integration and UI tests. Of those, portlets are giving me a headache right now.

It seems that Liferay is really expecting portlets to appear in the domain directory rather than inside an EAR as has been the style of OpenQuote deployments since the project began. There are various workarounds suggested on the web (interesting stuff here and here), but so far these workarounds aren't working in the way I'd like. They're also a bit messy. So messy that they're having the effect of making me rethink the bigger picture: Why are we using an EAR anyway?

Back in the days when OpenQuote was still called MultiQuote (and that is a long time ago), EARs were really the way to go, but JEE has moved on since then and so has JBoss. The primary value that we gained from EARs was all about class loaders. Our JEE components all get so share a common set of dependent jars which sit in the EAR's lib folder. But with JBoss Modules being a fundamental part of JBoss AS now, we have what can be seen as a much more flexible and expressive way of dealing with dependencies.

Ideally, of course, we'd wait for Project Jigsaw to deliver a module system right inside the JVM, but JBoss Modules is here now and could ease our path considerably.

I still have one or two straws to clutch at with regards to getting portlets working from the EAR, but if that fails we may be waving goodbye to our EARs in 2.0.

Change is good!

Thank you Atlassian!

A big thank you goes to Atlassian this week for allowing the OpenQuote project to use their OnDemand service absolutely for free!

Atlassian's JIRA and Bamboo have been a mainstay of OpenQuote project development since we outgrew the support that SourceForge offered many years ago. They are both essential and excellent products.

OnDemand is a cloud based service which will mean that we get all of the benefits of the Atlassian products without the server admin work.

As well as Bamboo and JIRA, we also have the use of Confluence, Crucible and Fisheye.

All I need now is some time to migrate and set them up.

Goodbye old friends...

Alfresco and JBoss Portal have been part of OpenQuote for a long time now and both have served the project very well. But, for 2.0, the wind of change is blowing.

The decision to move away from JBoss portal was, to some extent, forced upon us. The version that we were using up to and including OpenQuote 1.4 has itself been put out to grass and replaced with a totally new implementation from eXo. The upgrade path for Alfresco was less problematic, but Alfresco has grown enormously in capability; to the point that we're only scratching the surface of it's functionality in OpenQuote.

So, the time was ripe for a review.

Two front runners came out of the review: JBoss+Liferay, and JBoss+eXo. We gave consideration to Glassfish rather than JBoss as the base JEE server, but on balance both are comparable and as we have experience of JBoss and it has served us well up to now, we chose to stick with it. Likewise, we considered building Tomcat. Taking a web container and adding the features that you need to it (transaction managers etc) is quite a common approach these days. However, in our case it seemed the simpler approach to start from a JEE server and take out what we didn't need.

So, we stuck with JBoss. Though, we are stepping up to the latest version (7.1.1). Both Liferay and eXo have pretty well built out content management systems already, so Alfresco was also out of the picture.

In the end, we chose Liferay over eXo principally because it has a larger installed base and a more active community. If I'm honest, I also found it hard at the time to draw a line between the parts of eXo that were open source and the parts that were commercial. We can't afford to find that we're dependent on a commercial system, or find that a feature that we really need is commercial only.

So, OpenQuote 2.0 is based on Liferay 6.1.1.

The improvements we've seen so far are huge! More on that as the upgrade work progresses.

The diverse future of PageFlow

Opening up alternative ways for users to communicate with OpenQuote is something we've been giving some thought to lately. While 1.4 had both HTML and XForms support, the reality was pretty much that you could use any markup you wanted as long as it was HTML. In truth, that works fine for most applications, but with our growing focus on Microinsurance we need more flexibility.

The new template driven UI that I blogged about the other day goes a long way to addressing this, but what if you want users to communicate with OpenQuote using mobile phones. In developing countries where we see the OpenQuote for Microinsurance really having an impact mobile phones are comparatively common. Smart phones may still be a rarity, but feature phones and dumb phones are common?

A bit of research threw up some interesting open source Java projects that OpenQuote may be able to integrate with:

• Asterisk is interesting. It handles voice calls. Typically, in my experience at least, this surfaces as something like: "Press 1 for X, press 2 for Y... Now, to speed things up for you, we have 8 options: Press 1 for A, press 2 for B"... the kind of call centre nonsense perfectly designed to piss people off, so it would be nice to do something more innovative. Microinsurance products are typically quite simple. So, maybe five or six questions like: "Please enter your age, then press *" would be workable.
  
  Asterisk isn't 100% java, but it does have java support so it should integration well with OpenQuote.

• SMSLib provides a consistent interface to a number of 2 way SMS transport mechanisms. It support commercial bulk SMS providers like Clickatell and BulkSMS and also support direct communication via modems.
  
  While it's hard to imagine conversational processes, like quote, working via SMS, notifications make total sense. 

WAP is another technology that we shouldn't lose sight of. It got a pretty bad reputation in the technical community, largely due marketing hype, but it does provide a good option on low cost feature phones.