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

17

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

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

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

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

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

задан James Adams 07.07.2009 в 20:13
источник
  • Я на самом деле создал именно такую ​​систему для своей компании, чтобы ее можно было выпускать с открытым исходным кодом. Он написан в Groovy, но не зависит от Groovy, установленного на сервере, - он работает как приложение Java с помощью Restlet и Java Services Wrapper. Его можно довольно легко модифицировать для запуска на сервере приложений Java. Он использует объект доступа к данным в качестве уровня абстракции для базы данных. Он поставляется с адаптером для CouchDB, но было бы довольно легко реализовать его для другой БД. Вы бы заинтересовались этой системой, если бы я выпустил ее как открытый источник? –  Avi Flax 08.07.2009 в 23:46

4 ответа

7

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

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

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

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

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

ответ дан Damo 07.07.2009 в 20:28
4

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

  1. Опрос: Запустите список ресурсов, которые вам нужны, с запросами GET
  2. Обновление потоковых событий: Предоставить ресурс монитора. Сервер держит соединение открытым. По мере того, как события происходят, сервер передает потоки описаний событий, используя многостраничный тип содержимого или закодированное кодирование передачи.
ответ дан user189423 13.10.2009 в 23:20
3

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

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

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

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

    
ответ дан Jacob Mattison 07.07.2009 в 20:29
1

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

    
ответ дан cdiggins 15.09.2012 в 23:52