Архитектор отчаянно хочет использовать SOAP по JMS
Я использовал JMS в прошлом для создавания приложения, и это работает отлично. Теперь я работаю с Архитекторами, которые хотели бы использовать Спецификацию: SOAP по Службе сообщений Java 1.0.
Эта спецификация швы чрезмерно сложной. Я не вижу многих реализация (Около поставщиков, стремящихся к спецификации).
Кто-либо здесь использует эту спецификацию в продуктивной среде? Каково Ваше основное преимущество использования этой спецификации?
3 ответа
Мне не повезло с использованием SOAP через JMS. Это имеет некоторый смысл, если используется для операций fire-and-forget (нет ответного сообщения, определенного в WSDL). В этом случае вы можете использовать WSDL для генерации клиентских скелетов и хранить WSDL в реестре сервисов. Кроме того, вы получаете все обычные преимущества JMS (разделение отправителя и получателя, балансировка нагрузки, определение приоритетов, безопасность, мостовое соединение с несколькими пунктами назначения - например, неинтрузивный аудит).
С другой стороны, SOAP в основном используется для операций типа запрос/ответ. Реализация паттерна запрос/ответ через JMS влечет за собой следующие проблемы:
- Невозможно правильно обрабатывать таймауты. Вы никогда не знаете, ожидает ли запрос доставки или застрял в вызываемом компоненте.
- Ответы обычно отправляются во временных очередях. Если клиент отсоединяется до получения ответа и для ответного сообщения не установлено явное время жизни, временная очередь может застрять в JMS-сервере, пока вы не перезапустите его.
- Наличие JMS-сервера в середине значительно увеличивает время обхода и добавляет ненужную сложность.
- JMS обеспечивает надежную транспортную среду, которая отделяет отправителя от получателя, но в случае запроса/ответа клиент не должен быть отделен от сервера. Клиенту необходимо знать, что сервер работает и доступен.
Единственное преимущество, о котором я могу думать, это то, что сервер может быть перемещен или сбалансирован по нагрузке без ведома клиента, но использование UDDI и HTTP балансировщика нагрузки является лучшим решением.
Черт возьми, я ненавижу работать с архитектором-астронавтом. Я чувствую твою боль, брат. У них на самом деле есть реальная функциональная причина для этого, кроме «это стандарты»? Собирается ли это решение привязать их к конкретному поставщику контейнеров EE (например, WebSphere)? Это так 2002 год; очень немногие люди действительно нуждаются в этом; и, фактически, большинство успешных практических реализаций практически игнорировали SOAP. Если у них нет реальной потребности в большей надежности, чем та, которую обеспечивают только JMS или SOAP-over-HTTP, вас ждет путешествие.
Посетите сайт Apache CFX для некоторых примеров (специфичных для CFX).
http://cxf.apache.org/docs/soap-over-jms-10-support.html
Практическим правилом было бы действительно использовать голые минимумы, а не полный стек. Если ваши астронавты-архитекторы по-прежнему настаивают на использовании всего этого, возможно, вы просто попадаете в мир боли. Извините.
РЕДАКТИРОВАТЬ:
Кстати, какой контейнер приложения вы будете использовать? WebLogic, JBoss, WebSphere? И какая структура веб-сервисов? Apache CFX, Axis?
Архитекторы-космонавты будут любить говорить, что это детали реализации. Бык. Любое решение по системе, изменение которой требует больших затрат (или реализация которой дает значительную экономию), является архитектурным решением. Они в значительной степени определяют, как все будет реализовано (и какова будет стоимость изменений), поэтому определение того, что вы будете использовать, является архитектурным решением, за исключением очень автономных систем.
Еще несколько ссылок на эту спорную тему:
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 /
Я бы сказал, что от поиска архитектора тот же вопрос будет о том, зачем нужна пятиуровневая модель Интернета, где пятым является приложение, когда можно просто кодировать все приложение на уровне сокета. Абстрагирование транспортного уровня (JMS в вашем случае) от того, что ваше приложение производит или потребляет (сообщения SOA), является хорошей практикой по ряду причин, среди которых независимое модульное тестирование и будущая миграция на другие платформы приходят мне в голову первыми.