Есть ли у кого-нибудь архитектурная информация для MSMQ?

Я пытаюсь решить, является ли MSMQ подходящим инструментом для связи между нашим приложением и сторонней веб-службой, с которой мы в настоящее время общаемся напрямую. Мы пытаемся разъединить это так, чтобы в случае сбоя службы жизнь могла продолжаться как обычно.

Я не могу найти ничего, кроме обычной чепухи MS о том, что это лучшая вещь и решает все ваши проблемы и т. д. Было бы очень полезно, если бы я мог найти какую-то информацию, которая была бы где-то между маркетинговой чепухой и API — например, архитектурную диаграмму компоненты и то, как они интегрируются друг с другом, и, что более важно, как я интегрируюсь с ними.

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


msmq
person BenAlabaster    schedule 09.10.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Типичная архитектура MSMQ будет состоять из 3 частей...

  • Очередь сообщений — это будет на одном из ваших серверов. Вам нужно будет установить биты MSMQ и создать свою очередь.
  • Клиент — ваш клиент будет вставлять сообщения в очередь. Я предполагаю, что вы используете .NET. Если да, то большая часть того, что вам нужно, будет располагаться в пространстве имен System.Messaging.
  • Служба Windows. Это также будет работать на сервере, возможно, на том же сервере, что и ваша очередь. Его работа будет заключаться в наблюдении за очередью, обработке сообщений по мере их поступления, проверке доступности внешней службы и, возможно, в ведении журналов.

Вот статья, в которой следует остановиться на более подробном и дать вам несколько примеров кода.

person codeConcussion    schedule 09.10.2009
comment
Итак, судя по звуку, это значительный объем работы. У меня уже есть сделанный вручную дизайн, который концептуально сглажен, по крайней мере, включая крайние случаи, о которых мы могли подумать. Если использование MSMQ требует значительной работы, мне интересно, выгодно ли использовать его по сравнению со специализированной очередью для этого приложения. - person BenAlabaster; 09.10.2009
comment
Установка MSMQ, создание очереди и вставка сообщений не представляет особого труда. Основная часть работы будет выполняться в службе Windows. Все это вполне выполнимо, особенно если вы хорошо знакомы с .NET. - person codeConcussion; 09.10.2009
comment
Хорошо, это проясняет то, что я думал, что мне придется написать службу Windows, которая обрабатывает очередь, а также процесс постановки в очередь элемента. Таким образом, MSMQ на самом деле не экономит мне много времени по сравнению с использованием таблицы в моей существующей базе данных. - person BenAlabaster; 13.10.2009
comment
Эта ссылка на статью ведет на пустую страницу. - person ADH; 30.07.2016

arrow_upward
1
arrow_downward

MSMQ — это реализация очереди сообщений, как и websphere mq и множество других систем. Изучая концепции и архитектуру высокого уровня, я бы посоветовал прочитать об очередях сообщений и о том, как они применяются в сценариях с отключением. Я очень рекомендую Шаблоны архитектуры корпоративных приложений. Конкретные примеры по msmq см. в Pro MSMQ: программирование очереди сообщений Microsoft. он не содержит специальной информации, но группирует ее намного лучше, чем большинство ресурсов, доступных в Интернете. Этот Статья Hello World с MSMQ даст вам хороший обзор того, что это влечет за собой, и ее легко выполнить в системе разработки.

person olle    schedule 09.10.2009
comment
Ранее я уже интегрировался с SonicMQ, который представляет собой ту же концепцию. Я пытаюсь выяснить, является ли MSMQ архитектурно тем, что я ищу. - person BenAlabaster; 09.10.2009

arrow_upward
0
arrow_downward

Если вы вызываете удаленную веб-службу из своего приложения, имеет смысл использовать очередь, чтобы отделить обработку вашего приложения от удаленной системы. Абстрагируясь от обмена сообщениями и имея службу шлюза, которая отвечает за связь с веб-службой, вы изолируете свое приложение от задержки веб-службы и создаете отказоустойчивость в дизайне, уменьшая использование запросов/ответов внутри вашего приложения ( поскольку обмен сообщениями по умолчанию является асинхронным — вы разбираетесь с этим заранее).

Существуют платформы для .NET, которые значительно упрощают эту задачу (например, MassTransit или NServiceBus).

Вы также можете ознакомиться с «Шаблонами SOA» (автор Arnon Rotem-Gal-Oz, Manning Press, в MEAP) и «Шаблоны интеграции предприятия» (Hohpe, Woolf), последний из которых необходимо прочитать всем, кто создает систему на основе сообщений.

person Chris Patterson    schedule 13.10.2009