You can now run the Madura Perspectives Manager demo online. Once you’ve logged in (admin, admin) it looks like this:

The rest of the demo script is in the previous post and I won’t repeat it all here.

The last few days we have been making some minor tweaks to the Madura Perspectives Manager. MPM is an awkward beast to explain but easy enough to demo… provided I can get you to build it and set it up yourself. So maybe not so easy.

The problem is the bundles, and I solved that yesterday. I’m going to explain how here. Madura Bundle are jar files that load into an application dynamically, ie while the application is still running. If you know about OSGi you’ll be nodding about now and maybe wondering why I don’t just use OSGi. Good question. But not for this post.

Madura Perspectives Manager loads entire sub applications from bundles as described in my earlier post and the bundle manager normally works by scanning a directory for bundles it can load. It does this every few seconds (configurable, of course) and while this can work fine in a real environment it doesn’t play too well with CloudFoundry which we use to host our demos. Even if you install it yourself you’ll need to edit the directory location and copy the jar file bundles into it. A bit clumsy really.

What OpenShift would be happiest with is storing the jar files inside MongoDB or similar and they happily support that kind of thing. This would work fine but it seems a lot of messing about for a demo, so we bypassed that and kept it simple. The bundles are stored in the relevant Github projects so we modified the bundle manager to pull bundles from a list of URLs. It doesn’t show the dynamic-ness of the bundle management, but it does show everything else.

This has got me rethinking some things about that dynamic-ness. The rule is that if you add a new bundle then users who are already logged in will not see it. So if you are a user working in sub application A and there is an update to A then you will not see it, and the application you are using will continue as normal. This is what we want, we don’t want users disrupted by new versions in mid flight.

Once you log out and back in you’ll find the new version of sub application A. Naturally the people who worked on the update of that sub application have made sure any work you saved under the old version is compatible with the new one.

It is actually possible to do two other things as well.

You can delete a sub application. I’m wondering if this is ever a good idea, though. Deleting a sub application is supported by the bundle manager but in practice it screw up anyone who is using it, so the plan is to modify the bundle manager to simply disable deleted applications  rather than actually unload them. That means that newly logged in users will see the option, but it will be disabled.

You can actively decide to pick an older version. Let’s say the bundled sub application you are using generates a quote for some complex product you want to sell a customer. The customer worked through a quote with you yesterday and you gave him a price good for a month. This morning, when you log in and look at that quote, you find the price has changed. This is because marketing have just released their new pricing plan or rules or numbers or whatever. It is all bundled into the application and the latest application gives you a different price.

But that is okay. If you are able to select from all the versions you can get the one you want. In fact if you fetch that quote from a database you can have the system automatically pick the right version for you based on the date on the quote. We haven’t added this feature into the Madura Perspectives Manager demo, it is complicated enough, but it is certainly a natural extension and easy enough to implement.