Архитектура обратного вызова веб-службы SOAP?

Я совершенно новичок в веб-сервисах, JAX-WS и т.д., так что, возможно, вопрос noob...

Итак, я хочу реализовать веб-сервис, чтобы две системы обменивались данными. Система "клиент" интересуется событиями, которые генерируются в системе "сервер". Но "клиентская система" сама по себе является сервером для другого приложения. Сервер - Java (WAR в tomcat). Клиент -.Net.

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

Я буду использовать серверную часть и тестовый клиент. Кто-то другой выполнит код .Net.

Текущая последовательность должна быть вдоль этой строки:

Сервер работает...
Клиент инициирует разговор, "регистрирует" на сервере и запрашивает некоторые исходные данные.
Сервер хранит список конечных точек зарегистрированных клиентов.
На сервере есть прослушиватель, который уведомляется, когда происходят определенные события. Затем он перейдет через список зарегистрированных клиентов и переадресует событие каждому из них.
В какой-то момент клиент может "отменить регистрацию" не уведомлять сервер о том, что он больше не хочет получать события.

Во-первых, это звучит как-то разумно выполнимое?

И есть ли стандартный встроенный механизм, используя SOAP (JAX-WS на сервере, что доступно с .Net n клиентом) - что сервер может использовать для получения конечной точки обратного вызова от клиента?

Например, я сделал что-то очень похожее с помощью RMI, в этом случае клиент может просто отправить удаленную ссылку себе, что сервер может просто сохранить ant, ссылаясь позже.

Наконец, существует ли стандартная библиотека для хранения ссылок на конечные точки, создания (коллективных) обратных вызовов и, возможно, обновления списка, удаления клиентов, которые не реагируют на какой-то вызов "ping"?

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

Ответ 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, что позволяет отправлять уведомления.

Ответ 2

Асинхронные клиенты поддерживаются для служб на основе WSDL с помощью опроса и обратных вызовов. В вашем случае я считаю, что требование относительно сложнее.

Средство промежуточного программного обеспечения Oracle fua doc имеет описанный сценарий, который поможет вам. В нем описывается метод, который позволяет клиентам отправлять запросы, которые генерируют HTTP 202 (принято), а клиенты затем ждут ответа в очередях сообщений. В вашем случае сценарий можно изменить из приведенного ниже.

Инициировать несколько очередей ответов для каждой категории обратного вызова. Клиенты могут фильтровать их, предоставляя клиенту и идентификатор категории для очереди. Это будет служить механизмом обратного вызова для каждого клиента или процессами, которые регулируются каждым клиентом. MDB может поддерживаться хранилищем файлов или хранилищем БД для обеспечения надежности и одноразовой доставки.

Конечно, для реализации этого не требуется Oracle fusionware. Вы можете использовать RabbitMQ или Redis (с транзакциями), чтобы подтвердить получение сообщения на клиенте. Если ваш клиент хочет отменить регистрацию, сделайте вызов и прекратите прослушивание очереди.

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

Ответ 3

Рассматривали ли вы более простой подход "pub-sub" с использованием продукта обмена сообщениями? (Например, MQ, EMS или ActiveMQ)

Требования, которые вы описываете, похоже, не соответствуют "классическим" сценариям запроса/ответа синхронизации/асинхронного SOAP-веб-службы.

В решении Pub/Sub клиент подписывается на тему один раз, и издатель (в вашем случае Сервер) может отправлять любое количество релевантных сообщений всем подписчикам.

В качестве бонуса большинство продуктов для обмена сообщениями включают поддержку "надежных подписчиков", поэтому клиент может быть автономным время от времени и получать все сообщения после повторного подключения.

В вашем случае сервер может содержать (бесплатный) сервер ActiveMQ... Предоставление большинства функций, которые вы, похоже, ищете.

Если вы пойдете так, я предлагаю вам выбрать JMS-совместимый продукт с поддержкой .Net.

Ответ 4

Для тех, кто попадает сюда из поисковых систем:

В настоящее время вы можете использовать WebHook для веб-API, который работает, по существу, как описано OP.

Например, в REST клиент будет иметь конечную точку HTTP, которая предназначена для приема событий/уведомлений POST с реального сервера. Клиент регистрирует свою конечную точку с фактическим сервером, предоставляя ему URI на своей конечной точке уведомления. С этого момента фактический сервер может отправлять POST в конечную точку уведомлений клиентов. Это, по сути, свернутый обратный вызов, если вы знакомы с асинхронной терминологией.

Возможно, у Java или .NET есть библиотеки для WebHooks.

Тем не менее, стандарты SSE и Websockets предоставляют фактические сообщения push и real-time, будучи совместимыми с HTTP и большинством браузеров.

В прошлом использовались также длинные варианты опроса, которые иногда называются кометами как совокупность.