Как мне создать асинхронную систему уведомлений с помощью веб-сервисов RESTful?

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

Вариант использования примерно следующий:

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

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

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


events notifications rest message messaging
person James Adams    schedule 07.07.2009    source источник
comment
На самом деле я построил именно такую ​​систему для своей компании с прицелом на то, чтобы выпустить ее с открытым исходным кодом. Он написан на Groovy, но не зависит от того, установлен ли Groovy на сервере — он работает как Java-приложение с использованием Restlet и Java Services Wrapper. Его можно довольно легко модифицировать для работы на сервере приложений Java. Он использует объект доступа к данным в качестве уровня абстракции для базы данных. Он поставляется с адаптером для CouchDB, но было бы довольно легко реализовать его для другой БД. Была бы вам интересна эта система, если бы я выпустил ее с открытым исходным кодом?   -  person Avi Flax    schedule 09.07.2009

Ответы (4)


arrow_upward
9
arrow_downward

Я могу придумать четыре подхода:

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

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

  3. Возьмите URL-адрес во время запроса на регистрацию и отправляйте его каждому клиенту индивидуально, когда у вас есть уведомление. Вряд ли Pub/Sub, но эффект будет похожим. Конечно, вы предполагаете, что клиент прослушивал эти уведомления и реализовал свой клиент в соответствии с вашими спецификациями.

  4. Купить IBM WebSphere MQ (MQSeries). Лучший продукт IBM. Не REST, но он отлично подходит для многоплатформенной интеграции.

person Damo    schedule 07.07.2009

arrow_upward
4
arrow_downward

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

  1. Polling: Hammer the list of resources you need with GET requests
  2. Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.
person Community    schedule 13.10.2009

arrow_upward
3
arrow_downward

В ответ на запрос RESTful вы можете предоставить индивидуальный URL-адрес RESTful, который клиент может отслеживать на наличие обновлений.

То есть у вас есть один URL-адрес (скажем, /Signup.htm), который принимает информацию о клиенте (идентификатор, если это необходимо, идентификатор объекта для мониторинга) и возвращает настроенный URL-адрес (/Monitor/XYZPDQ), где XYZPDQ — это созданный UUID. для этого конкретного клиента. Клиент может запрашивать этот настроенный URL-адрес с некоторым интервалом и получит уведомление, если произойдет обновление.

Если вас не волнует, кто является клиентом (и вы не хотите создавать так много UUID), вы можете просто иметь отдельные URL-адреса RESTful для каждого объекта, который может потребоваться отслеживать, а URL-адрес «регистрации» просто вернет правильный.

Как говорит Джон Сондерс, вы не можете сделать более простую публикацию/подписку через HTTP.

person Jacob Mattison    schedule 07.07.2009

arrow_upward
1
arrow_downward

Если опрос неприемлем, я бы рассмотрел возможность использования веб-сокетов (например, см. здесь). Хотя, если честно, мне нравится идея, предложенная пользователем189423 из составной тип содержимого или также закодировал передачу по частям.

person cdiggins    schedule 15.09.2012