Monday, 10 December 2007

flex and server modularisation

I read the linked article and agreed with most of what it said, but when I thought about it further I had an issue with the counter argument to point 8.

I've been getting up to speed with recently Flex as well as the back end product called LiveCycle Data Services. I have to admit it is so easy to create applications with these APIs it is almost silly! For instance, I can call methods on a POJO running on my server from Flex with almost no effort just a couple of lines in my server config and a couple of lines in my Flex application. When called from the UI my POJO can then do whatever it needs to on the backend. Since it is running in an enterprise application I suppose a logical approach to accessing an RDBMS (which is the scenario I am mostly likely to have to implement) would be to lookup and delegate to session beans.

The thing that bugs me though is this means I have to use an application server and I have to package my POJOs inside a web application or enterprise application. I'm averse to this because I don't believe that this presents an approach which gives much flexibility.

In the kind of work I am likely to be doing soon, we want to be able to build a suite of components that we can plug together, just like LEGO, depending on our customers' requirements. Using the approach above it would mean that we end up deploying a single large heavy weight application, that may be slightly different for different customers and that means multiple branched code bases! Nightmare.

Flex supports modularisation and components, so that is part of the way there, but right now I am still unclear how we can deliver an application to a customer that only contains the software they actually need and no more yet still allow us to give them access to more software later without rebuilding and deploy their entire application. The situation is even worse with web applications, though simplying packaging up POJOs and the components they depend on in to a single web application probably isn't as bad as it sounds and can be done with some clever build scripts.

However, what you end up with is a project per customer. I imagine we'll end up with a very complicated structure in our source code respository consisting of Flex components, Flex modules, Server POJOs , web components and ultimately a web application containing a Flex application all of which could have specific implementations for each different customer.

Not exactly LEGO and it all has to all be resolved at build time. This isn't good because if a part changes that is high up in the build hierarchy then I may need to re-package each customer's application to cope with the changes, even if that change was for a single customer! Or you end up with copies and branches of your components with specific changes in them and that becomes a nightmare to maintain.

I think the counter-argument in the linked article is probably correct in an application that is only deployed in a single infrastructure and is built on SOA pattern. In this case you can change the server or the UI with out it necessarily affecting the other. However, this doesn't work very well when you want to deliver a subset of a larger collection of components to different customers possibly with parts of the application customised for those customers.

The solution is to work to interfaces, build the components and be able to deploy them dynamically and at runtime. This is what OSGi is all about and I would love to be able to bridge OSGi and Flex.

It is possible to build something OSGi like within Flex - all the tools are there and has already been done inside Esri's ArcWeb Explorer product, but unfortunately it doesn't look as though you can get to it without having the whole product (or at least some kind of "key" for their API), so I am keeping my eye out for something more open and light-weight.

Further more, Flex allows you to call a HTTP service, WebService or "RemoteObject" (the POJO approach talked about above) and the Cairngorm framework allows you to abstract this in to a Command Pattern with Business Delegate Pattern so that your main Flex code remains de-coupled from the actual chosen approach.

This means we could call in to a HTTPService running on an OSGi container, though I would prefer to call in to a WebService. In fact, my preference would be to deploy server side code as bundles and have the bundle automatically expose it's service(s) as a Web Service that my Flex UI can call in to. However, I'm yet to find a light weight Web Service implementation that uses OSGi's HTTPService which can do this.

In conclusion, using the traditional method of packaging an application as a WAR/EAR means that changes to dependancies really could force you to have to re-package (if not re-build) your entire application, especially when supporting multiple products/customers from a single codebase. To make a truly dynamic application we need to use OSGi technology in both the server and UI. The APIs are available, but we're still missing open and easily accessible implementations:
  • An open OSGi implementation for Flex
  • Some way to expose a bundle's service(s) as a WebService using just the HTTPService within the OSGi framework

No comments: