純粋な技術レベルでは、これは開始するのに良いポイントかもしれません：http: //java.sun.com/products/jms/tutorial/
また、「エンタープライズ統合パターン」という本のコピーを絶対に入手する必要があります。これは、キューイングシステムを使用するさまざまな方法をすべて説明しています。
あなたの説明から、私は次のパターンが役立つと思います（申し訳ありませんが、私は今それを持っていないので、本で使用されている用語を知りません。自分で作ります）：
パブリッシュサブスクライブ：サーバーは、その種類の情報をサブスクライブしているすべてのクライアントに配信されるメッセージ（価格情報の更新など）をパブリッシュします。カバーしなければならない重要なケースの1つは、そのようなブロードキャスト中にクライアントが切断されたときに何が起こるかという質問です。メッセージを見逃さないようにするか、もう一度追いつく方法があることを確認する必要があります。
ファイアアンドフォーゲット：1つの通信パートナー（クライアントなど）は、いかなる種類の応答も期待せずにメッセージを送信します。キューイングシステムが最終的な配信を処理します。これは、注文の送信などに使用できます。
コールバック：これは、2回以上のファイア・アンド・フォー・メッセージのようなものです。以前に受信した特定のメッセージへの応答としてメッセージにタグを付けるために、後続の呼び出しにはIDがあります。これは注文を送信するときに便利ですが、何らかの回答が必要です。もちろん、回答は1日後に届く可能性があるため、未処理の注文のリストが必要になります。これは、おそらくユーザーにも表示されるか、個人のリストサポートに表示されるはずです。複数の返信を送信する場合は、メッセージが順不同で届く場合に対処する必要があります。可能であれば、これを処理するための良い方法は、後続の各メッセージに以前のメッセージのすべての情報を含めることです。このようにして、古いメッセージを簡単に破棄できます。
したがって、通信は次のように機能する可能性があります。-サーバーがすべてのクライアントに更新を送信することがあります。クライアントがすべてのメッセージを持っていることを確認できるように、メッセージにはおそらく何らかのバージョン情報が含まれている必要があります。-定期的に（または、しばらくの間サーバーから更新を受信しないアフターなど）、クライアントは、サーバーに最新の情報がすべて含まれていることを確認するために、サーバーに特別な更新を要求します。上記のバージョン情報を使用して、不足している情報を特定できます-クライアントはメッセージを受信してローカルデータベースにコンテンツを保存します-クライアントはユーザーに情報を提示するためにデータベースから読み取ります-クライアントは注文などをサーバーに送信します同期していない回答を受け取っている可能性があります
いくつかの一般的なアドバイス：
キューイングを使用すると、並行性の地獄の真っ只中にいます。だから、「間違っている」可能性のあるすべてのものについて創造的になりましょう。例：-メッセージが順不同で到着する-送信時に受信者が利用できない（そもそもメッセージングを使用する理由です）-受信者が利用できず、オンラインに戻らない。メッセージングサーバーには、配信を保証するオプションがあります。これは、実際にメッセージが配信されるまでメッセージを保存する必要があることを意味します。クライアントがオンラインに戻らない場合、メッセージは永久に残り、保管場所がいっぱいになります
テストを容易にするために、すべてのメッセージング処理がアプリケーションの他の部分から明確に分離されていることを確認してください。
特にメッセージ形式が変更された場合は、サーバーとクライアントをアップグレードするプロセスを検討してください。ダウンタイムを挟んですべてを同時にアップグレードするか、サーバーが新旧のメッセージ形式をしばらくの間処理できる必要があります。