How to design a distributed application using a Message Broker and a Database?

I would like to implement an distributed Point-Of-Sale system, somewhat like the one described in Point of sale app architecture advice.

It is a distributed system with these charachteristics:

• The clients are mission critical, they should work even if the network connection or the server fails, but just for a few days or so.
• The clients 开发者_如何学Pythonmust be easy to install.
• Each client has it's own local embedded database.
• The communication between the clients and the server is using a message queue.
• The server is used for backup, bookkeeping, statistics and distribute prices to the clients.
• The server is placed on internet.

I am implementing the client in Java Swing with JavaDB as the database.

How should my application communicate with the message broker and the database?

I have never used Message Queues and Message Brokers before. My idea is that the application reads from the database, but writes to the message broker, and the message broker writes to the database and communicates with the server. Or is this a bad idea? How should I solve this?

So besides my embedded database, I need to find a message broker, preferably one written in Java that could be embedded in my application, for easy installation.

On a pure technical level this might be a good point to start: http://java.sun.com/products/jms/tutorial/

You also should absolutely get a copy of the book "Enterprise Integration Patterns" It explains all the various ways one can use queuing systems.

From what you describe, I envision the following patterns to be useful (sorry, don't know the terms used in the book, since I don't have it right now. Making up my own):

• publish subscribe: The server would publish messages (e.g. updates to price information) which get delivered to all clients subscribing to that kind of information. One important case you'll have to cover is the question, what is going to happen, when your client is disconnected during such a broadcast. You have to make sure it doesn't miss any message, or has a way to catch up again.

• fire and forget: One communication partner (e.g. the client) will sent a message, without expecting any kind of response. The queuing system will take care of eventual delivery. This could be used for submitting orders and the like.

• call back: This is like two or more fire and forget messages in opposite directions. Where subsequent calls will have an id in order to tag the message as a response to a certain message received before. This is usefull when you submit orders, but need some kind of answer. Of course the answer might arrive a day later, so you'll need a list of outstanding orders, which probably should also be visible to the user, or at list support personal. When sending multiple replies, you must handle the case of messages arriving out of order. When possible a nice way to handle this is to include all the information of earlier messages in each following message. This way you can simply discard older messages.

So communication could work like this: - server occasionally sends updates to all clients. The message probably should contain some kind of version information, so the clients can make sure, they have all the messages. - on a regular basis (or aftger receiving no update from the server for some time or ...) the client requests a special update from the server in order to ensure that it has all the current information. The version information mentioned above can be used to identify the missing information - clients receive the message and store the content in the local db - client reads from db in order to present information to the user - client submits orders or what ever to the server, possibly receiving an out of sync answer

Some general advice:

With queuing you are in the middle of concurrency hell. So get creative about all the things that can go 'wrong'. Examples are - messages arriving out of order - receiver not available at time of sending (well that is the reason for using messaging in the first place) - receiver not being available and never going back online. Messaging server have options to guarantee delivery. This means they have to store the message until the actually deliver it. If clients never come back online, messages will stay for ever, filling up the storage place

Make sure all the messaging handling is cleanly separated from the rest of your application for easy testing.

Think through the process of upgrading server and clients especially when the message formats change. You either have to upgrade all at the same point of time with some downtime in between, or your server must be able to process old and new message format for some time.