Архитектор отчаянно хочет использовать SOAP поверх JMS

Question

В прошлом я использовал JMS для создания приложений, и это прекрасно работает. Сейчас я работаю с архитекторами, которые хотели бы использовать Spec: SOAP поверх Java Message Service 1.0.

Эта спецификация выглядит слишком сложной. Я не вижу много реализаций (кроме продавцов, требующих спецификации).

Кто-нибудь здесь использует эту спецификацию в производственной среде? Каково ваше основное преимущество использования этой спецификации?

Ссылка: http://www.w3.org/TR/2009/CR-soapjms-20090604/

Answer 1

Мне не повезло, используя SOAP поверх JMS. Это имеет некоторый смысл, если он используется для операций «забей и забудь» (ответное сообщение не определено в WSDL). В этом случае вы можете использовать WSDL для генерации клиентских скелетов и хранить WSDL в реестре сервисов. Кроме того, вы получаете все обычные преимущества JMS (развязка отправителя и получателя, балансировка нагрузки, расстановка приоритетов, безопасность, мостовое соединение с несколькими пунктами назначения - например, неинтрузивный аудит).

С другой стороны, SOAP в основном используется для операций типа запрос / ответ. Реализация шаблона запроса / ответа через JMS создает следующие проблемы:

• Невозможно правильно обработать тайм-ауты. Вы никогда не знаете, ожидает ли запрос доставки или застрял в вызываемом компоненте.
• Ответы обычно отправляются во временных очередях. Если клиент отключается до получения ответа, и в ответном сообщении не указано явное время жизни, временная очередь может зависнуть на сервере JMS, пока вы не перезапустите его.
• Наличие JMS-сервера в середине значительно увеличивает время прохождения туда и обратно и добавляет ненужную сложность.
• JMS предоставляет надежную транспортную среду, которая отделяет отправителя от получателя, но в случае запроса / ответа клиент не должен быть отделен от сервера. Клиент должен знать, работает ли сервер и доступен ли он.

Единственное преимущество, о котором я мог подумать, это то, что сервер можно перемещать или балансировать нагрузку без ведома клиента, но лучше использовать UDDI и балансировщик нагрузки HTTP.

Answer 2

Я бы сказал, что с точки зрения архитектора тот же вопрос будет о том, зачем иметь 5-уровневую модель Интернета, а 5-е - это приложение, когда можно просто закодировать все приложение на уровне сокетов. Абстрагирование транспортного уровня (JMS в вашем случае) от того, что ваше приложение производит или потребляет (сообщения SOA), является хорошей практикой по ряду причин, среди которых первое, что приходит мне в голову: независимое модульное тестирование и будущая миграция на другие платформы.

Answer 3

Черт возьми, я ненавижу работать с Архитектором Астронавтами. Я чувствую твою боль, брат. Есть ли у них действительная, функциональная причина для этого, кроме «это стандарты»? Собирается ли это решение привязать их к конкретному поставщику контейнеров EE (скажем, WebSphere)? Это так 2002; очень немногие имеют реальную потребность в этом; и на самом деле, SOAP в значительной степени игнорируется большинством практических и успешных реализаций. Если у них нет реальной необходимости в большей надежности, чем то, что обеспечивается только JMS или SOAP-over-HTTP, вас ждет путешествие.

Проверьте сайт Apache CFX для некоторых примеров (специфичных для CFX).

http://cxf.apache.org/docs/soap-over-jms-10-support.html

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

---

EDIT:

Кстати, какой контейнер приложения вы будете использовать? WebLogic, JBoss, WebSphere? А какой фреймворк веб-сервиса? Apache CFX, Axis?

Архитекторы-космонавты с удовольствием скажут, что это детали реализации. Bull. Любое решение в отношении системы, чьи изменения несут большие затраты (или чья реализация приносит значительную экономию), является архитектурным решением. Они в значительной степени определяют, как все будет реализовано (и какова будет стоимость изменений), поэтому определение на раннем этапе, которое вы будете использовать, является архитектурным решением, за исключением очень автономных систем.

Еще несколько ссылок на эту спорную тему:

http://www.subbu.org/blog/2005/03/soap-over-jms http://parand.com/say/index.php/2005/03/29/soap-over-jms-no-such-thing/

Answer 4

SOAP / JMS и SOAP / HTTP используются для различных сценариев, хотя и с использованием Fire Message и Request / Response. SOAP / JMS на самом деле потрясающе для распространения обнаруженных (если требуется преобразованных) сообщений на несколько sourecs просто с помощью SoapAction и targetService. Спецификации JMS также помогают в сложной маршрутизации с использованием заголовков.

Фактически, UDDI, как и серверы сборки, могут и используются в качестве источников для обнаружения опубликованных WSDL (встроенных) из массовых развертываний промежуточного программного обеспечения (независимо от архитектуры механизма) в виде сообщения SOAP / JMS для отдельных приемников SOA Repository Sinks. Очень важно в управлении предприятием

Следовательно, это крайне важно для шаблонов проволочных отводов, особенно когда асинхронность имеет первостепенное значение.

SOAP / HTTP и теперь REST (с моделью существительного глагола) лучше всего работают для доверенных вызовов подсистемы

Answer 5

С здесь :

SOAP через JMS предлагает альтернативный механизм обмена сообщениями для SOAP через HTTP. Пока он еще не стандартизирован и, следовательно, не может быть SOAP over JMS обеспечивает более надежную и поддержка масштабируемых сообщений, чем SOAP через HTTP. Как JAX-RPC и JSR-109 стать неотъемлемой частью стандарта J2EE, корпоративные сообщения в Веб-сервисы, использующие SOAP поверх JMS, станут хорошо известными.

Answer 6

Изображение вы внедрили часто используемый веб-сервис, который имеет тенденцию запускать потоки ouf, в то время как вы обещали, что нет сообщений будет потеряно.

Реализация Webservice (сервер), которая работает над Сессионный компонент поставляется с ограниченным количеством потоков (скажем, n активный PE в вашем пуле), который может запустить n запрос веб-службы одновременно. Что будет с запросом n + 1?

MRDE, разве вы не обещали владельцу приложения, что нет сообщение будет потеряно. Таким образом, JMS гарантирует эту функциональность. Скелет Webservice должен хранить данные только в очереди, и это дает надежность также в отношении пиков нагрузки.

Интересной особенностью WS over JMS является то, что прошедшее время запущенного WS-запроса довольно короткий, поэтому немедленно вернется на сервер к следующему запросу.