Хочется знать, когда логичным и правильным выбором внутреннего транспорта системы является messaging (Apache Qpid, RabbitMQ etc.) Если требуется работать по схеме Multi-Producer/Multi-Consumer? Есть ли еще преимущества перед классической архитектурой клиент-сервер?

Здравствуйте, los puercos, Вы писали:

LP>Хочется знать, когда логичным и правильным выбором внутреннего транспорта системы является messaging (Apache Qpid, RabbitMQ etc.) Если требуется работать по схеме Multi-Producer/Multi-Consumer? Есть ли еще преимущества перед классической архитектурой клиент-сервер?

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

Здравствуйте, <Аноним>, Вы писали:

А>Причин может быть много. Необходимость обеспечения высокой доступности, в этом случае брокер должен поддерживать durable сообщения, которые не теряются если получатель в данный момент не запущен. Упрощение сетевой архитектуры, узлам не нужно знать ничего друг о друге, им достаточно уметь подключаться к брокеру. Узлам, что-бы обмениваться сообщениями даже не обязательно работать в один и тот же момент времени(отправитель послал сообщение, через сутки запустился получатель и без проблем получил все свои сообщения).
А>Недостаток — брокер это узкое место системы, по производительности и надежности.
Это недостаток классической централизованной ESB, но сейчас есть так называемые федеративные ESB, в которых все функции Service Broker поделены между несколькими облегченными физическими ESB, сгруппированными в единую федеративную сущность. В них озвученных недостатков уже нет. Подробнее см. здесь: «Облегченные» SOA: шаблоны и принципы нового поколения SOA-решений.

Здравствуйте, los puercos, Вы писали:

LP>Хочется знать, когда логичным и правильным выбором внутреннего транспорта системы является messaging (Apache Qpid, RabbitMQ etc.) Если требуется работать по схеме Multi-Producer/Multi-Consumer? Есть ли еще преимущества перед классической архитектурой клиент-сервер?
Кросс-платформенность из коробки.