13

I have three incoming projects that share a common problem:

they need to have the logic on a web system and they need a local application (e.g. point of sale) that communicates with such system through a RESTful web service.

My Solution

The solution I managed to come up with is to implement in the desktop application message queuing to store operations while the service is offline, more precisely, asynchronous message queuing. However, that is the easy part (if such is the best solution). I'm also concerned with data syncing and conflict resolution.

The main system needs to be web based since a web app is required for reports and monitoring by the stakeholders, and the web services would handle requests for several establishments.

The desktop clients (preferably thin) will be implemented with Java (more specifically Netbeans) and the web system with Symfony2. Two of the projects require hardware integration for the client, so making the desktop application with web technology (e.g. Appcelerator Titanium) could be a major pain.

My Question

  1. What is a better solution that scales, meaning maximum efficiency with minimum effort (and preferably no additional costs, like buying a backup server for local operation) ?

  2. Who else has dealt with this before? How did you solve your problem? What lessons can you share?

  3. How did you deal with synchronization?

Edit: Added a missing part to my question in point #3

Improve this question
0

3 Answers 3

Reset to default
3
+100

I know your question is java, but I really like this message bus style architecture for this type of thing.

Basically when messages are sent they get potentially two responses. The first is from the local cache, the second comes from the server once it gets connected.

I'm pretty sure you could adapt this architecture (rhino bus and nhib) to yours (MQ and hib) pretty easily.

Improve this answer
1
  • Yup, I was looking exactly for that kind of message oriented architecture. The cache arguments and the last sentence in your linked convinced me.
    – dukeofgaming
    May 28, 2011 at 6:12
10

Do everything locally, and sync periodically.

Here is what I would do if I was you (I'm not aware of sync framework in Java like we have in .NET).

Maintain a timestamp in the local application that will hold the last time you connected successfully.

Regardless the time you reconnect, that timestamp will be used to pull out new data, then send new orders generated locally.

You will then maintain two timestamps. One to define when the order has been created (locally or online) and one when it has been recorded by the server.

I don't recommend Message Queuing for that. I used MQ in the past for an e-commerce website that had to be connected to Navision. Everything was operated within Navision, and changes sent to the e-commerce website through MQ, including order status and everything including product descriptions, pricing, etc. New orders were sent to Navision through MQ too.

Improve this answer
7
  • Hmmm, I do like the idea of a push model, however I see the problem that if the computer time is changed there might be data-loss. BTW, I have the convention to have each and every record timestamped in my database designs. Why do you not recommend MQ?
    – dukeofgaming
    May 18, 2011 at 7:45
  • That's right, you must use time synchronized PCs and UTC, but it's pretty standard now (at least on Windows). MQ is sometimes necessary, but I think it would be too much for the kind of application you are developing.
    – user2567
    May 18, 2011 at 7:56
  • Ok, so in order to prioritize reliability, it is better to rather think that the desktop app will be disconnected and thus its better to treat the desktop app as a first-class citizen, however, I'm still under the impression that MQ would be an easier replacement for a local database implementation. Also, I think making all the CRUD operations in the server implicitly has better security. What do you think about these two points?.
    – dukeofgaming
    May 18, 2011 at 9:08
  • @dukeofgaming: in my case, orders could be taken from any POS (also the application could be used as a order taking system and not an order processing system), including web. Everything was distributed accross the country. It was absolutely necessary for every desktop to be autonomous in case of disconnection. MQ would work in that scenario too, so I'm not against it. I just feel it is more easy to implement strong data sync between master servers and clients. Therefore, CRUD operation on the master server was not an option.
    – user2567
    May 18, 2011 at 9:16
  • 2
    +1 - this is how I've seen it done in the past. I would also say that the use of uniqueidentifier (Guids) as primary keys simplifies things immensely. Doing that is one of those things that really makes your life easier down the road if you need synchronization.
    – Scott Whitlock
    May 18, 2011 at 12:38
1

Or you should look at occasionally connected systems database implementations which does the grunt work of sync'ing remote clients to the server. (SQL Server has this with SQL CE to an extent, Outlook does this).

This way, you can do all your changes locally in a small footprint database (It maintains versioning/logical timestamps etc. so that you don't have to worry about PC clocks etc) and whenever you go online, you sync this with the main server.

I wouldn't go for a REST solution when the system can't be online most of the time.

Improve this answer
2
  • Are you describing a distributed database?, can you elaborate on that?
    – dukeofgaming
    May 23, 2011 at 19:28
  • No - this is not a distributed db in the real world sense. A distributed db usually expects almost everything to be online as well, but the logic of replication among peers that went down applies here too. There are some desktop / device databases that have a facility to do the replication work (blogs.msdn.com/b/stevelasker/archive/2007/03/18/…) - So all you have to do is setup this device db, log your changes here and when you connect to the computer network, call sync - and that will do the data transfer to the main server for you.
    – Subu Sankara Subramanian
    May 23, 2011 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.