Каковы преимущества использования WCF над фреймворками, такими как MassTransit или рукописный клиент MSMQ? - PullRequest
8 голосов
/ 06 марта 2009

Я смотрю на использование MSMQ в качестве решения для асинхронного выполнения в моем предстоящем проекте. Я хочу знать различия между использованием WCF и средами, такими как MassTransit или даже написанным от руки клиентом MSMQ для размещения / чтения задач из MSMQ.

По сути, приложением будут несколько веб-сайтов (внутренних через локальную сеть или внешних через Интернет), читающих / записывающих данные через уровень обслуживания (будь то WCF или обычный веб-сервис). Затем этот сервисный уровень будет выполнять одно из двух действий: 1. записывать данные в базу данных 2. и / или запускать фоновый процесс, помещая сообщение в очередь. 3. Очевидно, что он также может получать данные из базы данных. Маленький агент (служба Windows) на другой стороне очереди будет отслеживать очередь и выполнять ее на основе команды задачи.

Эту архитектуру будет довольно легко масштабировать (добавлять больше очередей и агентов) и легко реализовать по сравнению с RPC или распределенным выполнением или чем-то еще. И обработка агента не должна быть в реальном времени. И агент, и сервисный уровень являются отдельными приложениями, за исключением того, что они совместно используют общие доменные объекты и репозитории и т. Д.

Что ты думаешь? Предложения по архитектуре для вышеуказанных требований приветствуются. Спасибо!

Ответы [ 3 ]

7 голосов
/ 06 марта 2009

WCF добавляет абстракцию над MSMQ. Фактически, после определения совместимых контрактов (операции должны выполняться OneWay), вы можете прозрачно отключить MSMQ в конфигурации. (Например, вы можете переключиться на обычный HttpWS или привязку NetTcp.)

Вам следует оценить другие преимущества WCF, такие как безопасность и т. Д., Чтобы увидеть, насколько они соответствуют вашим потребностям. Опять же, они должны быть достаточно прозрачными из-за того, что вы используете MSMQ внизу. Например, добавление безопасности SOAP и т. Д. Должно «просто работать», независимо от использования MSMQ.

(Хотя, IIRC, вам все равно необходимо войти в систему на каждом компьютере, использующем MSMQ, с учетной записью службы, которая будет использовать MSMQ , для создания сертификата в локальном профиле компьютеров. И затем это не очень хорошо работает с IIS6, так как профили пользователей не загружаются. Реальная боль в целом, но не имеет ничего общего с WCF специально.)


Кроме этого:

Вы смотрели на SQL Server Service Broker? После использования MSMQ + WCF и SSSB, я думаю, что SSSB значительно проще в настройке и управлении. SSSB работает с командами T-SQL через любой клиент SQL (я использую его из Mono, в Linux, с транзакциями). Это также даст вам транзакционную отправку / получение, даже удаленно (я думаю, что MSMQ 4 теперь позволяет это). Это действительно снимает много боли с очереди сообщений, и если вы уже используете SQL Server ...

SSSB часто упускается из виду, поскольку в SQL Management Studio нет дизайнеров графического интерфейса для всего этого, но это не сложно и является отличным вариантом. Единственным недостатком является то, что если вам нужна возможность локальной отправки (то есть сообщение в очереди, когда сеть не работает), вам необходимо запустить локальный экземпляр SQL Express.

2 голосов
/ 06 марта 2009

Ваша архитектура кажется разумной и разумной. Однако вы должны рассмотреть возможность использования MSFQ-транспорта WCF через классы MSMQ, закодированные вручную. WCF оборачивает эту общую функциональность в хорошую модель программирования. Также я считаю, что в протоколе, используемом wcf, есть некоторые улучшения по сравнению с базовым System.Messaging

1 голос
/ 26 апреля 2012

Посмотрите на добавленную стоимость по сравнению с простым MSMQ:

http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html

Таким образом, вы получаете множество концепций обмена сообщениями, четко представленных в API вместе с MassTransit; до такой степени, что вы бы этого не сделали, если бы вы кодировали его вручную или использовали WCF.

...