One of our current Customers have a very interesting requirement for an upcoming project. The nature of the project requires mobile clients and frequent (or even instant) database updates, but there is no guarantee to have constant connectivity. We more or less have full control on the choice of tools to use for this application, but since our developer resources are limited, it would be great if we could use the architecture from a previous project. We’ve been working with András on this for quite a while and it seems we found a pretty interesting way to do this.

The current architecture looks like this:

The RCP client connects to the application server using Axis based web services that uses our framework to call the business logic which accesses the database through Hibernate.

As the application currently uses web services to access the framework containing the business logic and this is already separated in the application it’s relatively straightforward to modify this dispatcher to access the business logic.

When online the modified application works just like the one above, and during the online period the application will synchronize its database with the server using DB2 Everyplace.

When the application is off-line the actions will perform the actions on the locally synchronized database, and send MQ messages of these actions through the local MQ Everyplace. Thus the application will see the local database as it’s own and perform the actions on it’s local database. The requirements allow for this, as the data is distributed among the users, (it’s more of a data collector, than business application) and there is only a very little chance of simultaneous updates.

When the client goes on-line again first the MQ messages will be sent to the server, the client will then wait for all the sent messages to be consumed by a message bean on the application server. After the messages are consumed the local database can be synchronized with the server so the data modified by other clients will be reflected on the client.

We’ve also considered using the features of the Lotus Expeditor platform, which works similarly, but decided against it. Our two main concerns were, that firstly we have limited resources and learning a new platform is time consuming, especially for such a new framework, the other was that Lotus Expeditor’s works offline like the original Lotus Notes platform (this is our assumption, based on a very short research) has the preconception, that noone is allowed to use the same database at the same time. If someone does the records are marked as save conflicts that must be reconciled manually.

Our way would permit the business logic to handle these updates gracefully, by either simply applying the updates on the given record in sequence, or refusing the update using either a version- or timestamp, or in workflow like cases statuses.

I’m sure this is not the only, and very likely not the best way to do this, but it’s most certainly the one that would require the smallest effort.

The images suck, I know, but I’m not in a drawing mood right now. 🙂