Веб-приложение подписано на очередь сообщений - PullRequest
0 голосов
/ 03 августа 2011

В Интернете есть (1) веб-приложение , где пользователь создает некоторые задачи и (2) другая система ( служба на основе Java), которая обрабатывает задачи.

Задачи зависят от даты / времени - пользователь создает задачу, устанавливает дату ее начала, например, завтра в 1:00, и он готов.Служба Java завтра в 1:00 начинает обработку задачи и сообщает приложению текущий статус обработки.

Мы планируем использовать ActiveMQ для (а) уведомления службы о новой задаче, (б) уведомления веб-приложенияо текущем статусе задачи.(А) часть без проблем.

Мой вопрос - (б) хорошая идея ?Веб-приложение должно быть подписано на очередь сообщений, чтобы оно вызывалось при наличии сообщения, сообщающего о ходе выполнения текущей задачи.Веб-приложение должно обработать это и сохранить информацию в БД.Я сомневаюсь, что мы должны сделать это таким образом, потому что если нет трафика к веб-приложению, оно умирает и умирает подписчик .Поэтому сообщения не будут обрабатываться.

Лучше ли создавать службу .NET, которая постоянно подключена к очереди?Преимущество подписки в веб-приложении заключается в том, что в случае необходимости использования кэша второго уровня в Nhibernate все работает.Если есть два процесса (веб-приложение, новый сервис), которые используют Nhibernate и кэш 2-го уровня, это может вызвать проблемы, поскольку каждый из них может работать с разными данными.веб-сервис, но коллеги сообщили, что довольно сложно обмениваться данными через wcf от java до .net и использовать сертификат для безопасного общения.

Ответы [ 2 ]

1 голос
/ 03 августа 2011

МЫ делаем аналогичную вещь и используем очередь сообщений для хранения задач, которые необходимо выполнить в разных сервисах. Если служба умирает, очередь сообщений продолжает записываться, мы не пишем на сервер sql, поскольку используемдругая машина И она также может выйти из строя

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

0 голосов
/ 04 августа 2011

Мы создали аналогичные системы, в нашем случае мы сделали это немного по-другому.

  • Мы использовали таблицу вместо очереди.Это позволило нам регистрировать, когда элемент был обработан, и повторно отправлять, изменяя статус на «не отправлено»
  • Мы также опрашивали таблицу с помощью службы таймера вместо триггерного уведомления

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

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