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.
