MSMQ / .EXE против веб-службы .... MEF IoC? - PullRequest
1 голос
/ 26 июня 2010

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

Мне кажется, что вы просто создаете веб-сервис, к которому портал интранета (или что-либо еще) может получить доступ, отправив идентификатор пользователя и взамен получая любую информацию (отчет пользователя 425 истекает через 90 дней, приложение отклонено и т. Д. И т. Д.). .) У нас есть несколько приложений для интрасети, а также портал (назовем их приложениями A, B и C).

Другой человек здесь сказал, что нам нужно использовать MSMQ ... поэтому я провел некоторое исследование и, насколько я могу сказать, смысл MSMQ в том, что когда у вас есть пользователь, он выполняет какой-то запрос, который длинный и не может быть запущен синхронно .. Если эти вызовы занимают 0,02 секунды .. В чем преимущество MSMQ? Все, что я делаю, это отправляю обратно сообщение ...

Так что имеет больше смысла?

Бонус: все приложения A, B и C имеют собственную бизнес-логику для определения того, какие сообщения отправлять обратно в главное приложение портала ... Так что я могу.

  1. Содержит ли веб-служба уведомлений всю логику для приложений A B и C? Теперь возникает проблема: я понимаю, как работают приложения A B и C, поэтому я могу отправить сообщение WS обратно соответствующему сообщению ..

  2. Используйте MEF / IoC, и как часть процесса сборки я получаю MEF .DLL, который реализует определенный интерфейс. Итак, моя программа уведомлений jsut переходит к различным приложениям и говорит «ДАЙТЕ МНЕ ВАШУ ЛИЗИКУ DLL BIZ» .... поэтому, когда у меня есть все библиотеки DLL и я знаю интерфейс, я могу просто просмотреть их и получить нужные мне данные ... Таким образом вплоть до разработчиков A, B и C, которые являются экспертами своего домена для реализации этого интерфейса передачи сообщений.

Помощь. (Я едва понимаю MEF, поэтому могу быть далеко)

1 Ответ

1 голос
/ 26 июня 2010

Я думаю, что отчасти проблема заключается в том, что существует некоторая путаница относительно того, какую именно роль в этом сыграет MSMQ. В основном у вас есть два способа сделать эти уведомления:

  1. Иметь ряд веб-сервисов, к которым можно обращаться для получения необходимых уведомлений (скажем, модель pull)
  2. Публикация в приложениях изменений состояния, которые происходят в ходе выполнения ими работы, некоторые из которых могут быть получены службой уведомлений и затем обработаны (push-модель)

Теперь, в случае варианта 2, вы можете использовать что-то вроде NServiceBus , чтобы настроить систему обмена сообщениями публикации / подписки, которая позволит приложениям публиковать важные события в системе, и службу уведомлений. подписаться на сообщения, которые должны генерировать уведомления. Так уж получилось, что NServiceBus использует MSMQ под прикрытием в качестве транспорта по умолчанию, поэтому в этом случае MSMQ появится на снимке, но только как деталь реализации.

В случае варианта 1 это можно реализовать любым количеством способов, включая веб-службы WCF.

Лично я считаю модель Pub / Sub наиболее масштабируемой и гибкой из опций, плюс документация для проекта выше номинальной, что приятно.

...