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

Question

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

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

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

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

Answer 1

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 нет дизайнеров GUI для всего этого, но это не сложно и является хорошим вариантом. Единственным недостатком является то, что если вам нужна возможность локальной отправки (то есть сообщение в очереди, когда сеть не работает), вам необходимо запустить локальный экземпляр SQL Express.

Answer 2

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

Answer 3

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

http://readthedocs.org/docs/masstransit/en/ последний / обзор / valueadd.html

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