Выбор решения для обмена сообщениями - PullRequest
Новая
       5

Выбор решения для обмена сообщениями

2 голосов
/ 04 июня 2009

поэтому я создаю клиент-серверное приложение, и мне нужно выбрать, как они будут общаться друг с другом. я могу:

  1. иметь TCP-соединение между клиентом и сервером
  2. отправлять сообщения через REST или SOAP
  3. с использованием Tibco RV, EMS или IBM MQ. ,

есть ли где-нибудь матрица, которая может показать мне, где я буду использовать одну из этих технологий по сравнению с другой? такие вещи, как производительность, надежность и т. д. были бы полезны.

Ответы [ 3 ]

7 голосов
/ 04 июня 2009

Пойдите для WCF, если у вас есть чистое приложение .NET к .NET. Это сделает вашу жизнь простой, когда дело доходит до создания TCP / IP, но сохраняя приятный уровень объектно-ориентированного дизайна в вашем обмене сообщениями. Это также делает безумно простым модульное тестирование кода обмена сообщениями, что, я думаю, является самым большим преимуществом.

WCF будет выполнять TCP / IP, каналы на локальной машине, а также поддерживает множество решений на основе HTTP. Вы также получаете безопасность на большинстве из них, и код выполняет большую часть обработки ошибок для вас.

Если вам нужно решение MQ, тогда получайте удовольствие. MSMQ поддерживается, но опять же, это также MSMQ.

Использование других решений выиграет от большего количества функций, но с функциями возникают сложность и риск. Я лично интегрировал приложение .Net с websphere MQ, и меня не впечатлили стоимость и преимущества этого решения. Не говоря уже о том, что производительность MQ на оборудовании, отличном от P-Series, по меньшей мере отсутствует.

6 голосов
/ 04 июня 2009

В очереди или не в очереди?

Что вам нужно от вашего решения для обмена сообщениями?

  1. Interoperability ? Вы должны быть в состоянии представить свое решение другим приложениям? Затем вам нужно будет использовать один из поддерживаемых форматов и протоколов, и в 99% случаев это означает REST или SOAP
  2. Наличие ? Если ваш клиент должен иметь возможность отправлять сообщения, даже если сервер не работает, недоступен или проходит техническое обслуживание, тогда вам наверняка понадобится решение в очереди (MSMQ, MQ, SSB)
  3. Безопасность ? Должны ли клиент и сервер проходить аутентификацию в доверенных доменах? Затем вам нужно убедиться, что ваше решение имеет не доменную историю для аутентификации (например, сертификаты).
  4. Надежность ? Если ваш клиент дает сбой, нужно ли возобновить отправку ожидающих сообщений? Опять же, только решение в очереди поможет здесь.
  5. Корреляция ? Вам нужно обрабатывать коррелированные сообщения по порядку, нужен ли вам эксклюзивный доступ к коррелированным сообщениям, нужно ли отправлять ответы обратно? Не все решения предлагают семантику сеанса.
  6. Масштабируемость ? Вам нужно поддержать одного клиента или миллион? Опять же, только решение из очереди будет работать после определенного масштаба.
  7. Шипы ? Есть ли у вашего трафика скачки, например, в определенные часы или дни, когда он растет? Связанное решение должно быть спланировано так, чтобы оно могло принимать наибольший всплеск, с которым оно может столкнуться, иначе оно будет бесцеремонно отвергать клиентов. Если ваше оборудование не справляется с обычными всплесками, вам придется использовать решение в очереди.

Если вам нравится WCF , то вы получите много от него бесплатно. Но в основном есть два режима обмена сообщениями: в очереди и без очереди. WCF предлагает огромную матрицу взаимозаменяемых каналов, привязок, форматов, протоколов и методов аутентификации, которые можно включать и выключать при простом изменении файла .config. Но они все для режима без очереди . Если ваше решение в порядке со связанным каналом связи, то, вероятно, нет ничего лучше, чем WCF на данный момент для приложений CLR. Если ваши требования предполагают решение на основе очередей, то вы потеряете все классные взаимозаменяемые связующие игрушки и воспользуетесь WCF сериализацией и, возможно, моделью активации вашего сервиса.

И последнее, но не менее 90% сообщений, отправляемых в любых решениях для обмена сообщениями, попадают в базу данных, и многие из них также происходят из базы данных. Если вам нужна тесная интеграция с базами данных SQL Server, которая обеспечивает производительность и гарантирует надежную доставку, то - это решение для SSB .

.
2 голосов
/ 04 июня 2009

При создании коммуникационного приложения в .NET ответом почти всегда является WCF. WCF делает

  • SOAP - включая WS - *
  • REST - XML, JSON, другие
  • розетки
  • Трубы * * 1 010
  • двоичные форматы
  • Tibco RV
  • IBM MQ
  • MSMQ
  • SAP
  • много больше

Идея WCF заключается в следующем: это общая коммуникационная структура, которая отображает любую коммуникационную основу, которую вы хотите использовать. Это означает, что модель программирования согласована, концепции согласованы, а операции / администрирование согласованы. Если вы выбираете WCF и хотите регистрировать, это работает одинаково, независимо от того, какую подложку вы выберете. И, если вы выбираете WCF, вы можете использовать именованные каналы, когда стороны являются локальными, и переключаться на TCP, когда вы их распределяете. Это не требует изменения кода, только изменение конфигурации. Который может быть хорошим.

Что касается выбора подложки - ну, это решать вам. Зависит от функций и возможностей, которые вам нужны, ваши требования.

...