Модель запроса-ответа для гибридного SOAP через HTTP /JMS поверх промежуточного программного обеспечения

Question

Один из наших продуктов реализует следующую структуру одностороннего веб-сервиса:

Server <--------------------- Middleware <---------------- Client
        SOAP over JMS (queue)              SOAP over HTTP

В этой модели клиенты отправляют SOAP-сообщения по протоколу HTTP нашему промежуточному программному обеспечению (Progress SonicMQ).Сообщения помещаются SonicMQ в очереди JMS, и наш сервер извлекает их оттуда.Однако, как вы можете видеть, сервер не отправляет ответ клиенту (асинхронный JMS).

Мы хотели бы внедрить канал отклика для этой модели.Часто предлагаемое решение заключается в создании временной очереди ответов ("на лету") в промежуточном программном обеспечении, позволяющем серверу отправлять ответ в эту очередь.Затем клиент может получить ответ, и очередь replyTo закрывается.Это звучит достаточно удобно, но, к сожалению, наши клиенты работают через обычный HTTP, а не через JMS, поэтому их клиенты не могут легко настроить очереди ответов.

Одним из подходов к созданию канала ответа в такой гибридной модели HTTP / JMS SOAP было бы настроить промежуточное программное обеспечение так, чтобы оно открывало очередь ответов при каждом успешном получении SOAP, добавляло информацию о очереди ответов и отправителе к сообщению SOAP и отправляло сообщение в очередь, откуда оно было бы извлечено сервером.После получения и обработки сообщения сервер мог отправить ответ в указанную replyTo-очередь в промежуточном программном обеспечении.Наконец, промежуточное программное обеспечение отправило бы ответ (SOAP) по протоколу HTTP обратно исходному клиенту, используя данные из сообщения SOAP (данные, которые были вставлены туда в процедурах промежуточного программного обеспечения при первом получении запроса).

Хотя это вполне возможно, это звучит несколько банально.Итак, вопрос в том,:есть какие-нибудь более чистые способы достижения такой модели запроса / ответа в нашем случае?Серверная часть была реализована на Java.

Решение:

Progress SonicMQ поддерживает HTTP-акцептор "Content Reply Send", который позволяет легко отправлять JMS-ответ.Средство приема отправки ответа на контент работает следующим образом:

• Принимающий получает HTTP-сообщение, отправленное клиентом
• Acceptor создает временную очередь JMS
• Acceptor создает сообщение JMS, содержащее тело HTTP, и добавляет идентификатор временной очереди к вновь созданному сообщению JMS
• Принимающий отправляет сообщение JMS в очередь назначения (не во временную очередь).
• Принимающий начинает использовать временную очередь ответов
• Когда клиент извлекает сообщение из исходной очереди назначения, оно содержит установленный идентификатор очереди ответа
• Клиент потребляет сообщение
• Клиент отправляет ответ в очередь ответов
• Принимающий получает сообщение из очереди
• Принимающий отправляет сообщение как HTTP клиенту, который первоначально отправил HTTP-сообщение

Если потребитель (в нашем случае "сервер") выходит из строя и не отправляет ответ, вызывающий тайм-аут, HTTP-акцептор Sonic отправляет HTTP-сообщение клиенту с указанием тайм-аута.Это очень стандартная функция в SonicMQ.Я полагаю, что это существует и в других продуктах.

Это позволяет использовать стандартное SOAP поверх JMS (см. Ответ скаффмана) в разделе "сервер", избегая любого пользовательского программирования в промежуточном программном обеспечении.

Тем не менее, я все еще вижу некоторые проблемы в модели JMS, но это определенно улучшение.

Обновление 2009-11-05:

После еще более тщательного изучения этого вопроса выясняется мое подозрение против HTTP<--> промежуточное программное обеспечение<--> JMS была актуальна.

В этой модели есть несколько критических проблем.Синхронно-асинхронная модель с промежуточным программным обеспечением просто не удобна.Либо пусть оба конца реализуют JMS-соединение (которое должно сработать), либо используйте HTTP на обоих концах.Смешивание их приводит только к головной боли.Из этих двух SOAP-over-HTTP проще и лучше поддерживается, чем SOAP-over-JMS.

Еще раз:если вы разрабатываете такого рода систему...НЕ НАДО.

Answer 1

Я вообще не думаю, что предложенное вами решение является хакерским, я думаю, что это правильное решение.У вас есть уровень клиент-середина с синхронным протоколом, а затем уровень средний сервер, использующий асинхронный уровень, к которому вы должны добавить путь ответа, чтобы удовлетворить синхронную семантику.Вот для чего существует промежуточное программное обеспечение.Помните, что JMS предоставляет явную поддержку временных очередей ответов, поэтому вам вообще не нужно будет возиться с полезной нагрузкой.

Более левая возможность заключается в использовании того факта, что SOAP 1.2 был разработан с учетом JMS, и поэтому вы могли бы использовать уровень веб-сервиса между промежуточным программным обеспечением и серверным уровнем, который выполняет SOAP поверх JMS.Это означает, что вы можете использовать SOAP из конца в конец, при этом промежуточное программное обеспечение меняет только транспорт.

Единственный известный мне стек веб-сервисов, поддерживающий JMS transport, - это Весенние веб - сервисы, где процесс и разработка являются задокументировано здесь.Это также дало бы вам возможность перенести ваш слой SOAP на Spring-WS, который надирает задницу :)

Answer 2

Почему бы не добавить ссылку на страницу, которая позволяет пользователям проверять, готов ли ответ, например, по идентификатору Fed Ex tracker ID?Дайте вашим пользователям идентификатор трекера, когда они отправят запрос.

Это вписывалось бы в идиому HTTP request / response, и ваши пользователи все равно знали бы, что запрос - "запустить и забыть".