The project is a java / swing client / server application. Clients could number in the hundreds. The specification says that clients should be able to view up to date information from other clients and that clients should continue to work normally when the network is not available. There is no stipulation on the duration or frequency of the network downtime support requirements. So, for example, we will have to support a client starting up whilst disconnected from the network.
For now we are assuming that most disconnections will be fairly short duration but have the capability to support longer breaks if needed. Ulitmately I think the disconnected duration will be determined by the quality of the configuration data. We store scheduling data so the breaks may be limited to a few days before the lack of acurate config data causes problems.
The possible candidates I could think of were:
Replication: Each client would have to be capable of subscribing and publishing to the server. We have a fairly tight auditing requirement so the result of publishing data back to the server would have to reflect this. Not sure about such high potential subscriber / publisher numbers. I have a wary feeling about replication in this context.
Messaging (Asynchronous): Have a local datastore for the client configuration and case data. When the update of the local case data is done write a message to a queue. Was going to rely on the queue to guarantee delivery of the message to the server when connection is resumed.
Local transaction store: Store each transaction locally in a persistent datastore then at certain points during the case or when network connectivity is restored we process the datastore queue of transactions using a direct link to the server database.
If you have any suggestions as to what is the best strategy for this type of application, the potential pitfalls and also any technology suggestions that would be a great help and sanity check.