Преимущества системы «передачи сообщений» по сравнению с системой «на основе событий»

Мой вопрос идет с несколько необразованной точки зрения.

Каковы относительные достоинства системы « передачи сообщений » по сравнению с системой «на основе событий ».

Почему один выбирает один над другим? Каковы их сильные и слабые стороны?

Я хотел бы знать не только «в теории», но и «на практике».

РЕДАКТИРОВАТЬ:

Конкретная проблема :

Я хочу создать систему подключаемых компонентов, которые ведут себя как небольшие сервисы (каждый выполняет какую-то небольшую задачу или предоставляет некоторую информацию).

Услуги могут:

• быть наслоенным таким образом, чтобы вывод одного сервиса мог действовать как один из входов другого
• иметь иерархии содержания, так что один сервис может содержаться другим без определенного отношения ввода-вывода, как упомянуто в предыдущем предложении

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

Я могу предоставить более подробную информацию, если этого недостаточно.

После осмотра еще немного. Это и это, вероятно, лучше описывает мою ситуацию.

Похоже, это хорошо подходит для моей ситуации: http://akka.io/

По моему опыту, единственное конкретное отличие состоит в том, что в большинстве систем передачи сообщений отправитель сообщения знает (и часто объявляет), кто является получателем сообщения.

Таким образом, вместо того, чтобы вызывать событие, и тот, кто подписан на событие, получает его, отправитель определяет некоторый идентификатор предполагаемого получателя (ей) или логической группы получателей, а затем либо отправляет сообщение непосредственно им, либо проходит через посредник сообщений. (хотя ОС может рассматриваться как посредник сообщений в системе, основанной на событиях).

Очевидно, что есть случай многопоточности, который Telastyn упоминает при реализации событий в C #, но вы все равно можете создать свою собственную модель pub / sub, которая выполняется в разных потоках.

Это яблоки и апельсины:

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

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

Два не являются взаимоисключающими.

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

Большая часть путаницы между «передачей сообщений» и «на основе событий» связана с деталями архитектуры и реализации. Я видел (и писал) управляемые событиями системы, которые фактически используют предоставленные ОС сообщения для их реализации. Я предполагаю, что вы действительно имеете в виду архитектурные идеи.

Поскольку многие люди уже отметили, что «передача сообщений» и «на основе событий» не являются достаточно хорошими терминами, чтобы избежать двусмысленности.

Каковы относительные достоинства системы «передачи сообщений» по сравнению с системой «на основе событий».

Передача сообщений

Я начну с предположения, что когда вы говорите «система передачи сообщений», вы говорите о системе, в которой один объект передает сообщение определенному другому объекту. Когда я думаю о системе, основанной на этой парадигме, я в целом имею в виду систему, в которой объект, который обнаруживает что-то, знает, кому нужно что-то сказать. (Я не уточняю, как он знает, просто он знает.)

Этот тип архитектуры очень хорош для систем, где производители и потребители хорошо известны. Либо производитель сообщения знает, кто должен его получить, либо потребитель должен знать, от кого получить сообщение.

Если вы пишете банковское приложение, можно ожидать, что вы действительно хотите знать, кому вы отправляете свои транзакции и от кого они приходят.

Основанный на событии

Другая система, о которой я думаю, вы думаете о том, когда вы говорите, что система, основанная на событиях, - это система, в которой объект вызывает «событие», не зная, кто (если кто-то) ответит на него.

Этот тип архитектуры, управляемой событиями, очень хорош для систем, где производитель не заботится о том, кто потребляет событие, или где потребитель не заботится о том, кто произвел событие.

В целом, эти системы хороши там, где вы не знаете взаимоотношений между потребителями и производителями, и где вы ожидаете, что отношения будут динамичными.

Одной из систем, в которой я использовал это, была система, в которой приложение было фактически составлено из динамически настроенных модулей (плагинов), которые были загружены во время выполнения. Когда модуль был загружен, он регистрировался на события, о которых заботился. Результатом стала система, в которой было очень легко расширить функциональность.

Например, скажем, условие A вызвало событие EA, которое обычно вызывало ответ RA. Объект, вызвавший ответ RA, просто зарегистрировался для получения события EA и действовал на него, когда он прибыл. Теперь предположим, что мы хотим добавить в EA новый ответ, который называется RA_1. Для этого мы просто добавляем новый объект, который ищет советника и генерирует ответ RA_1.

Вот пара примеров (используя вашу терминологию):

• «передача сообщений» : ваш босс говорит вам, чтобы заполнить ваше расписание.
• «управляемый событиями» : секретарь департамента рассылает электронное письмо всем, напоминая им о том, что их расписание должно быть сегодня.

В SOA у вас есть концепция командных сообщений и сообщений о событиях . Существует необходимость в обоих.

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

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

Для получения дополнительной информации вы можете просмотреть мой сайт сервисных автобусов здесь: http://www.servicebus.co.za

По моему опыту, самое большое различие между ними состоит в том, что сообщения в системе передачи сообщений являются первоклассными объектами, тогда как события в управляемых событиями системах намного проще. Сообщения, как правило, несут информацию, и эта информация может быть преобразована, сохранена, извлечена и повторно отправлена. События, как правило, несут меньшие, более сфокусированные биты информации, которые немедленно потребляются, а затем отбрасываются. Как правило, они отправляются из источника событий непосредственно в один или несколько приемников событий, тогда как сообщения чаще маршрутизируются среди нескольких получателей и могут быть преобразованы / переведены / упакованы или иным образом обработаны в любой точке маршрута. Они используют похожие технологии (шины, очереди, фильтры и т. Д.), Но они действительно разнородные звери.

С практической точки зрения сообщения, как правило, реализуются как блок памяти, который копируется из адресного пространства отправителя в адресное пространство получателя (или иным образом принудительно является неизменным объектом), поэтому вы сразу получаете безопасность потока.

В некоторых случаях передачи сообщений отправитель должен указать получателя, но в некоторых других случаях вы можете просто отправить сообщение в почтовый ящик, и любой может прослушивать сообщения в этом почтовом ящике, поэтому существует некоторая гибкость в том, насколько они тесно связаны. Конечно, у вас может быть почтовый ящик с контрактом: «Я отправлю сообщение в этот почтовый ящик, когда произойдет это событие ».

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

Лично я бы выбрал передачу сообщений по событиям, кроме случаев, когда на вас навязывают события, такие как программирование Windows GUI и т. Д.