This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Architecture for a POS

Apr 25th, 2006, 09:19 PM

Hi All,

I am working in a POS system. the functional requirement which may affect the architecture is as follow:

1) There is a web application for backoffice staffs who can view the centralized data from all shops
2) the POS workstations in shop should be able to support offline mode. i.e. the workstations located in the shop many not have internet connection. However, they would upload all transactions at the day end to the backoffice db.

1) would be implemented by using spring.
and 2) would be implemented by using java swing application.

The problem is that, how can i synchronizate the data between 1) plus 2).

i am thinking of having one centralized db at the backoffice for storing centralized data, and each workstation would have its own db for storing its own data. To synchronizate the data between 1) and 2), i would like to use JMS. once the user in the shop is going to upload the data to the backoffice at the day end, the workstation db will retrieve the data and put them in the queue to publish to the backoffice server.

I would like to ask whether it is a reasonable architecture for the system?

i am thinking of having one centralized db at the backoffice for storing centralized data, and each workstation would have its own db for storing its own data. To synchronizate the data between 1) and 2), i would like to use JMS. once the user in the shop is going to upload the data to the backoffice at the day end, the workstation db will retrieve the data and put them in the queue to publish to the backoffice server.

I would explore the possibility of each shop running a small JMS implementation, like ActiveMQ. Then you could create each JMS message and store it locally, at the time of sale. Since creation of the JMS message will be scoped in the same transaction as the actual sale, you should improve the integrity of your transactions.

Now, your end-of-day process would consist only of forwarding all of the JMS messages from the store queue to the backoffice queue.