Поскольку JMS - это всего лишь спецификация, нет ничего, что могло бы помешать реализации обеспечить некоторый уровень устойчивости сообщений на клиенте.Однако на практике все реализации (о которых я все равно знаю) делегируют это посреднику.
Имейте в виду, что изначально система обмена сообщениями была разработана так, чтобы иметь посредника на каждом узле так же, как и каждый узел.TCP / IP, LU6.2 или другой транспортный стек.В этом смысле обмен сообщениями должен был быть транспортным, а не центральным сервисом, таким как база данных.Намерение состояло в том, чтобы предоставить локальную услугу, которая изолировала приложение от недоступности сети, а также от множества доступных синхронных транспортных протоколов.В этой модели брокер был всегда локальным, и единственное сетевое взаимодействие происходило между двумя брокерами.
За прошедшие годы обмен сообщениями добавил возможности клиента, но это больше касалось затрат на лицензирование, чем архитектуры.Соединение клиента обмена сообщениями вновь ввело зависимость от синхронного сетевого соединения, от которого изначально предназначался транспорт для защиты приложения.Теперь мы прошли полный круг, как показывает ваш вопрос, - требование локальной очереди для защиты приложения от недоступности сети.За исключением того, что теперь приложение, требующее локального хранения сообщений, фактически является (предположительно) приложением асинхронного обмена сообщениями.
Конечно, мы могли бы создать локального мини-брокера для постановки в очередь сообщений до того, как они попадут в центральный брокер.Но прежде чем мы сделаем клиентский код намного более сложным (и предложим бесконечную рекурсию поддержки нашего асинхронного обмена сообщениями с еще большим количеством асинхронных сообщений), я бы рекомендовал еще раз взглянуть на оригинальную архитектуру обмена сообщениями - поставить посредника локальным для приложений, которые требуютэтот уровень постоянства.
Один из подходов к этому состоит в том, чтобы относиться к приложениям поставщика услуг иначе, чем к приложениям потребителя услуг.Именно поставщикам услуг требуются глубокие, постоянные хранилища сообщений, и, поскольку они часто являются транзакционными, им нельзя разрешить переключаться на другой экземпляр посредника (в этом случае «другой», как распознает менеджер ресурсов XA).
С другой стороны, простые приложения запросов / ответов могут продолжать анонимно подключаться по сети к облегченному уровню брокеров без постоянных очередей.Эти приложения выдают сообщение с запросом вне точки синхронизации и ждут ответа в динамической очереди.Если они переключаются при сбое, они могут просто повторить запрос, и ответ придет к новому узлу.Это идеальные кандидаты для сетевого обмена сообщениями на основе клиента, поскольку они не имеют отношения к конкретному брокеру.Поскольку между клиентскими и серверными приложениями существует сетевой переход, нет необходимости следить за тем, чтобы клиенты переключались на серверы и т. Д. У поставщиков услуг есть локальные брокеры, а у потребителей услуг есть два (или более) облегченных центральных брокера, к которым можно подключиться..
Конечно, это не удовлетворяет всем требованиям к асинхронному обмену сообщениями, но оно обеспечивает решение, которое обеспечивает высочайшую надежность систем записи и при этом сохраняет стоимость лицензий, позволяя запросчикам сервисов обмениваться централизованными брокерами.