Рекомендуемая архитектура шины сообщений для публикации событий клиента - PullRequest
Новая
       39

Рекомендуемая архитектура шины сообщений для публикации событий клиента

0 голосов
/ 09 сентября 2011

Какая архитектура обмена сообщениями рекомендуется для следующего сценария:

  • Несколько рабочих станций, на которых работает клиент WinForms
  • Клиенты должны надежно уведомить две (или более) службы Windows о событии

Изначально мы хотели избежать настройки MSMQ на клиентских рабочих станциях, поэтому мы создали веб-сервис. Это оказалось трудно настроить, и затем я прочитал, что публикация сообщений NServiceBus из веб-приложения не рекомендуется .

Является ли лучшая практика для:

  • Заказывают ли клиенты веб-службу, которая отправляет (не публикует) сообщение службе Windows, которая публикует сообщение?
  • Отправить (не публиковать) сообщение непосредственно из клиентских приложений в удаленную очередь на сервере, с которого служба Windows публикует сообщение?
  • Другое

В настоящее время я пытаюсь реализовать это с помощью NServiceBus, но, надеюсь, ответ не зависит от шины.

Edit:

Если клиенты просто отправляют (не публикуют) в удаленную очередь, нужно ли настраивать (или даже устанавливать) MSMQ на клиентских рабочих станциях? В таком случае, что произойдет, если удаленная очередь недоступна?

Ответы [ 2 ]

1 голос
/ 09 сентября 2011

Вы можете предоставить конечную точку NServiceBus в качестве службы WCF.

Снизу страницы NServiceBus и WCF : 

public class MyService : NServiceBus.WcfService<MyCommand, MyErrorCodes>
{
    ...
}

Взгляни на это. Вы должны иметь возможность подключать клиентские приложения к службам WCF для отбрасывания сообщений. Вы можете настроить службу WCF с помощью http, net.tcp или любого другого транспорта WCF, который вам подходит.

Эта служба тогда НЕ будет веб-приложением, даже если оно использует транспорт HTTP (хотя вам, возможно, придется выбрать нестандартный порт). Это будет служба Windows, предоставляющая интерфейс веб-службы. Было бы хорошо публиковать сообщения здесь. Это дает вам свободу от необходимости конфигурировать MSMQ на всех клиентах, но при этом все еще обеспечивает простоту и гибкость NServiceBus.

Конечно, если масштабируемость этого сервиса вызывает беспокойство, вам может потребоваться размещенный на IIS веб-сервис с балансировкой нагрузки. В этом случае создайте обычную веб-службу WCF, которая отправит сообщение конечной точке NServiceBus.Host.exe, установленной в качестве службы Windows, а затем опубликуйте события из этой службы Windows.

1 голос
/ 09 сентября 2011

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

Это дает преимущество сквозного срока службы.

Я заметил, что вы говорите об отправке и публикации, однако я не вижу ничеговаш сценарий, который оправдывает использование NSB pub-sub.

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

...