На чисто техническом уровне это может быть хорошим началом: http://java.sun.com/products/jms/tutorial/
Вы также должны обязательно получить копию книги "Шаблоны корпоративной интеграции", в которой объясняются все возможные способы использования.системы очередей.
Исходя из того, что вы описываете, я предполагаю, что следующие шаблоны будут полезны (извините, не знаю терминов, использованных в книге, поскольку у меня их сейчас нет.):
публикация подписки: сервер будет публиковать сообщения (например, обновления ценовой информации), которые доставляются всем клиентам, подписавшимся на такую информацию.Один важный случай, который вам нужно рассмотреть, это вопрос о том, что произойдет, когда ваш клиент отключится во время такой трансляции.Вы должны убедиться, что оно не пропустило ни одного сообщения или способно его перехватить.
выстрелить и забыть: один партнер по коммуникации (например, клиент) отправит сообщение, не ожидая какого-либо ответа.Система очередей позаботится о возможной доставке.Это может использоваться для отправки заказов и т. П.
обратный вызов: это как два или более огня и забыть сообщения в противоположных направлениях.Где последующие звонки будут иметь идентификатор, чтобы пометить сообщение как ответ на определенное сообщение, полученное ранее.Это полезно, когда вы отправляете заказы, но вам нужен какой-то ответ.Конечно, ответ может прийти на следующий день, поэтому вам понадобится список неоплаченных заказов, которые, вероятно, также должны быть видны пользователю, или в личной поддержке списка.При отправке нескольких ответов вы должны обработать случай, когда сообщения приходят не по порядку.Когда это возможно, хороший способ справиться с этим - включить всю информацию о предыдущих сообщениях в каждое следующее сообщение.Таким образом, вы можете просто отбросить старые сообщения.
Таким образом, связь может работать следующим образом: - сервер иногда отправляет обновления всем клиентам.Сообщение, вероятно, должно содержать какую-то информацию о версии, чтобы клиенты могли убедиться, что у них есть все сообщения.- на регулярной основе (или aftger не получал обновления от сервера в течение некоторого времени или ...) клиент запрашивает специальное обновление с сервера, чтобы убедиться, что он имеет всю текущую информацию.Упомянутая выше информация о версии может использоваться для идентификации недостающей информации - клиенты получают сообщение и сохраняют содержимое в локальной базе данных - клиент читает из базы данных для представления информации пользователю - клиент отправляет заказы или что-либо еще на сервер,возможно, получая несинхронный ответ
Несколько общих советов:
С очередями вы находитесь в аду параллелизма.Так что будьте изобретательны во всем, что может пойти не так.Примерами являются - сообщения, поступающие не по порядку - получатель недоступен во время отправки (хорошо, это причина использования сообщений в первую очередь) - получатель недоступен и никогда не возвращается в онлайн.Сервер обмена сообщениями имеет возможность гарантировать доставку.Это означает, что они должны хранить сообщение до фактического его доставки.Если клиенты никогда не возвращаются в онлайн, сообщения останутся навсегда, заполнив место для хранения
Убедитесь, что вся обработка сообщений четко отделена от остальной части вашего приложения для простого тестирования.
Подумайтечерез процесс обновления сервера и клиентов, особенно когда меняются форматы сообщений.Вы должны либо обновить все в одно и то же время с некоторым временем простоя, либо ваш сервер должен быть в состоянии обработать старый и новый формат сообщений в течение некоторого времени.