Ответ 1
Кажется, вы хотите внедрить средство уведомления для информирования произвольных анонимных клиентов.
Я предлагаю вам сначала подумать о том, как передать информацию с помощью сообщений SOAP. Затем вы можете рассмотреть, как достичь этого, используя java - JAX-WS или дополнительные нестандартные библиотеки. Дело в том, что могут быть существенные ограничения или предположения, необходимые для передачи сообщений SOAP. Например. брандмауэры могут блокировать ваши HTTP-сообщения, клиенты могут "просто клиенты" без возможности действовать в роли сервера для получения уведомлений SOAP
Примечание. Механизм обратного вызова async определен в JAX-WS 2.0, где служба получает ссылку на конечную точку клиента. Это тот же тип функциональности, предоставляемый фирменным решением WebLogic/Fusion, описанным Deepak Bala. У Websphere есть аналогичное проприетарное решение async. Ни одно из них не отвечает вашим требованиям, поскольку они разрешают только один ответ на запрос.
Параметры SOAP:
-
Собственные сообщения SOAP - "100% -ный вариант Do-It-Yourself"
Вы разрабатываете полные схемы полезной нагрузки SOAP и шаблон обмена сообщениями.
Вы можете отправить уведомление с сервера клиенту, если знаете адрес конечной точки SOAP клиента. Клиент может передать его адрес конечной точки SOAP в исходную полезную нагрузку запроса SOAP. Спустя некоторое время сервер может отправить запрос SOAP клиенту.
Проблемы/Предположения: (1) нужен путь связи SOAP/HTTP для запросов от сервера к клиенту - не гарантируется, когда существуют брандмауэры; (2) клиент должен знать вашу схему уведомлений - на самом деле клиент должен действовать как конечная точка службы для получения запроса уведомления SOAP. Это два больших предположения, если вы пытаетесь поддерживать произвольных анонимных клиентов - это не то, что SOAP "просто поддерживает", оба конца должны подробно конструировать все это. На самом деле, чтобы сделать это с помощью вида serviceafe, клиент должен фактически объявить свой собственный WSDL-интерфейс службы, чтобы вы могли его вызывать. (3) Как было намечено ранее, многие клиенты являются "просто клиентами" - у них может не быть HTTP-сервера для приема запросов SOAP.
Таким образом, для проприетарных "push" уведомлений для работы обеим сторонам необходимо серверы, и оба должны публиковать свои интерфейсы SOA.
Кроме того, вы можете вывести уведомление клиенту. Клиент может использовать запрос уведомления на сервер, который либо блокирует, либо опросит. Сервер может отвечать уведомлением или ничего или ошибка.
Проблемы/допущения: (1) HTTP-серверы (т.е. сервер SOAP) не поддерживают запросы блокировки, как правило, означает, что вы должны опросить; (2) клиент должен знать вашу схему уведомлений - на самом деле клиент должен действовать как конечная точка службы для получения запроса уведомления SOAP. Это два очень больших предположения для произвольного анонимного клиента - что не то, что SOAP "просто поддерживает", оба конца должны подробно излагать все это. На самом деле, чтобы сделать это с помощью вида serviceafe, клиент должен фактически объявить свой собственный WSDL-интерфейс службы, чтобы вы могли его вызывать.
-
То же, что и выше, но включите данные WS-адресации в заголовках SOAP, чтобы информировать обе стороны о другом адресе конечной точки.
В основном те же проблемы/допущения, что и первый вариант. Адресаты WS-адресации помогут вам разумно перенаправлять сообщения SOAP на правильный URL-адрес, но не более.
-
Использовать WS-уведомление
Эта спецификация была разработана для вашего сценария.
Субстандарт WS-BaseNotification будет отвечать вашим потребностям. Он предоставляет определения портов WSDL для производителей уведомлений и потребителей. Он предоставляет стандартное для WS-стандартов решение для подписки от потребителя на производителя и уведомление от производителей к потребителям.Проблемы/ограничения: (1) Он НЕ определяет формат уведомлений. Полезная нагрузка для уведомлений является специфичной для прикладной области (проприетарный дизайн). Стандарт не определяет каких-либо "стандартных" или "встроенных" ситуаций или сообщений уведомления. (2) Он имеет те же проблемы с уведомлениями HTTP, проходящими через брандмауэры, как упомянуто выше. (3) WS-Notification не поддерживается стандартом Java EE/JAX-WS (но есть много серверов приложений, с открытым исходным кодом и рекламы, которые поддерживают его как расширение).
-
Использовать решение для организации очередей сообщений (например, JMS) с трафиком, инкапсулированным в HTTP Для этого требуется проприетарный дизайн полезных нагрузок, проходящих между клиентскими и серверными и обратными контрактами между двумя сторонами. Преимущество заключается в том, что клиент может быть чистым клиентом, при этом прослушиватель сообщений вызывается в потоке при получении сообщения.
Проблемы/Ограничения: (1) Он имеет те же проблемы с HTTP-уведомлениями, проходящими через брандмауэры, как упоминалось выше. (2) Выполняется самостоятельно. (3) Использует больше технологий, чем вы в настоящее время используете.
Конечный результат:
Вам нужно, по крайней мере, часть вашего решения быть проприетарным дизайном - стандарты SOAP/WS не отвечают вашим полным требованиям. Теоретически этот проприетарный дизайн может использовать продукт для обеспечения большей части работы, но дизайн схемы уведомлений должен быть создан и интегрирован вами.
Если вы хотите нажимать уведомления, вам нужен какой-то контракт на передачу уведомлений клиенту, клиент должен действовать как сервер SOA, и вам нужны брандмауэры, открытые для вашего трафика. Большинство корпораций запрещают HTTP-запросы, выходящие из сервера, и переход к клиенту - вам обычно нужна очень веская причина для открытия портов брандмауэра, и даже тогда многие корпорации откажут от него...
Если вы хотите иметь опрос клиентов для уведомлений, вам просто нужен базовый интерфейс WSDL на стороне сервера, который может часто вызываться клиентами.
Будущий вариант: веб-сокеты HTML5
Если ваш клиент является приложением HTML5, то серверы, поддерживающие веб-сокеты, могут перенаправлять трафик на браузер - и есть вероятность, что корпорация откроет брандмауэры. Сообщения SOAP могут перемещаться по HTTP-сокетам HTTP, что позволяет отправлять уведомления.
