Architecture of pos
I'd like to develop a point of sale sotfware.
I'm thinking about the architecture.
* database (products, stock, sales, ... ) -> data communication via jpa
* core api
* swt/swing application + mobile application
What about the best solution for client-server communication ?
- ejb 3.1 for server and remote ejb acces (not local because many pcs) from client
- or webservice (maybe not the best performance)
- or socket (I think it's the best approach but long to develop)
- another solution you're thinking !
I'd like to push clients when events occurs (new product created, low stock,...).
Is this in educational purpose or commercial?
If commercial, your approach can be completely different.
Infrastructure, security and valid transactions are your main concerns and you must build your solution to meet this requirements.
Web or not web user interface on client side? Do you have any idea how can your application change during time considering user interfaces? Pc? Mobile? Some industry POS solutions based on commercial APIs and hardware?
Internet? Intranet? GPS? Cost of traffic?
Number of transactions in second?
Simulators and stress test application is a must and you must include it when calculating resources! Unfinished transactions and broken communication is major headache, how will you recover?
Again: Number of transactions in second?
Number of synch queries to DB? Can you afford expensive hardware with xxx CPUs and cores?
Remember your transaction DB should be never used ad report DB in real time! Nothing should jeopertize successful transaction execution in real time.
It is of most importance to include DBA in your plan on time, one that knows this area, he can save you incredible amount of money and time.
Functionalities on client:
Does RMI meets your needs?
Do you have to/want to create your own protocol?
How will you update version on client, java web start or?
There is a lot of planning to be done here this is not just another java application, if there's gonna be real money and real people in it be sure you make good biz plan and talk to experienced DBA and admins that now how transactional software works.
best of luck!
hi , it's in educational purpose.
MayBe "Pos" term is not really what i mean (i don't speak english fluently). The software should be use in small restaurants, pizzeria's ....
This is software that should be used on a small scale.
there will be no web interfaces but only applications made for touch screens, and mobile devices to waiters.
So communication : intranet
Thank you for your opinion
Possibly some form of RESTful web service setup, using json maybe?
Or you could simply go full fledged SOAP web service if you prefer. Since it's an intranet in a small space the performance difference will be negligible. I doubt the messages you'll be sending back and forth will be terribly large.
The RESTful one may involve more up front work from you to define the messages (I find the structured format of WSDL more convenient for this, but YMMV). But the size of the project might (again) make this a negligible difference.
So, a server that exposes some web services. The clients interact with this.
Have a good day
Tolls can you please recommend some RESTful APIs and doc
for fast and simple introduction.
thanks in advance!