Заслуги системи "Передача повідомлень" проти системи "На основі подій"

Моє питання йде з дещо неосвіченої точки зору.

Які відносні переваги системи " передача повідомлення " проти системи " на основі подій ".

Чому б обирати один над іншим? Які їх сильні та слабкі сторони?

Мені хотілося б знати не лише «теоретично», але і «на практиці».

Редагувати:

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

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

Послуги можуть:

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

Мета системи - перетворити один потік подій низького рівня в іншій системі на інформацію більш високого рівня та додатково забезпечити повернення каналу до іншої системи, що забезпечує єдину серію подій.

Я можу надати більш детальну інформацію, якщо цього недостатньо.

Подивившись ще трохи. Це і це, мабуть, краще описує мою ситуацію.

Схоже, це може бути добре підходить для моєї ситуації: http://akka.io/

На мій досвід, єдина відмінна відмінність у тому, що в більшості систем передачі повідомлень відправник повідомлення знає (і часто заявляє), хто є одержувачем повідомлення.

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

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

Це яблука та апельсини:

Система, керована подіями, може реагувати на події, передані у вигляді повідомлень (повідомлення в цьому контексті маються на увазі незмінні дані, що не поділяються загалом ) у міру збільшення подій. Це суто архітектурний дизайн.

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

Два не є взаємовиключними.

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

Значна частина плутанини між "передачею повідомлення" та "на основі подій" пов'язана з архітектурними та деталями реалізації. Я бачив (і письмово) системи, керовані подіями, які фактично використовують повідомлення, надані ОС для своєї реалізації. Я здогадуюсь, ти справді маєш на увазі архітектурні ідеї.

Оскільки багато людей вже вказали, що "передача повідомлень" та "подія на основі" насправді не є достатньо хорошими термінами, щоб уникнути двозначності.

Які відносні переваги системи "передача повідомлення" проти системи "на основі подій".

Повідомлення проходить

Я розпочну з здогадки, що коли ви говорите систему "проходження повідомлення", ви говорите про систему, якій один об'єкт витрачає повідомлення на певний інший об'єкт. Коли я думаю про систему, засновану на цій парадигмі, я загалом думаю про систему, де об’єкт, який щось виявляє, знає, кому потрібно про щось розповісти. (Я не вказую, як це знає, просто те, що він знає.)

Цей тип архітектури дуже хороший для систем, де виробники та споживачі добре відомі. Або виробник повідомлення знає, хто повинен його отримати, або споживач повинен знати, від кого отримати повідомлення.

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

На основі подій

Інша система, на яку я вважаю, про яку ви думаєте, коли ви говорите про систему, що базується на подіях - це та система, де об’єкт викликає "подію", не знаючи, хто (якщо хтось) відповість на це.

Цей тип архітектури, керованої подіями, дуже добре підходить для систем, де виробник не переймається тим, хто споживає подію або де споживач не переймається тим, хто подіяв.

Загалом ці системи чудові там, коли ви не знаєте відносин між споживачами та виробниками, і де очікуєте, що відносини будуть динамічними.

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

Наприклад, припустимо, умова підвищеної події EA, яка зазвичай викликала відповідь RA. Об'єкт, який викликав відповідь РА, просто зареєструвався для отримання ЕА події та діяв на нього, коли він прибув. Скажімо, ми хочемо додати нову відповідь до EA під назвою RA_1. Для цього ми просто додаємо новий об’єкт, який шукає EA та генерує відповідь RA_1.

Ось кілька прикладів (використовуючи вашу термінологію):

• "повідомлення проходить" : Ваш начальник каже вам заповнити свій часовий лист.
• "подія" : Секретар відділу розсилає електронне повідомлення всім, нагадуючи їм, що їх графіки розроблені сьогодні.

У SOA у вас є концепція командних повідомлень та подій повідомлень про . Існує потреба в обох.

Однак повідомлення команд мають більш високу поведінкову зв’язок із кінцевою точкою одержувача, оскільки явно просять кінцеву точку виконати якусь функцію. Його не потрібно прив’язувати до певної кінцевої точки (це можна налаштувати або визначити під час виконання).

Повідомлення про події, з іншого боку, не мають поведінкової зв'язку між відправником / одержувачем, оскільки відправник поняття не має, що одержувач буде робити з повідомленням. Навіть не відомо, чи підписаний на подію хтось .

Щоб отримати докладнішу інформацію, ви можете ознайомитись з сайтом мого сервісного автобуса тут: http://www.servicebus.co.za

На мій досвід, найбільша різниця між ними полягає в тому, що повідомлення в системі передачі повідомлень є першокласними об'єктами, тоді як події в системах, керованих подіями, набагато простіші. Повідомлення, як правило, несуть інформацію, і ця інформація може бути перетворена, збережена, вилучена та повторно надіслана. Події, як правило, несуть менші, більш зосереджені шматочки інформації, які негайно споживаються, а потім відкидаються. Вони, як правило, надсилаються з джерела події безпосередньо до однієї або декількох потоків подій, тоді як повідомлення частіше передаються між декількома приймачами і можуть бути перетворені / переведені / загорнуті або оброблені іншим чином у будь-якій точці маршруту. Вони використовують подібні технології (автобуси, черги, фільтри тощо), але вони справді розрізнені звірі.

З практичної точки зору, повідомлення, як правило, реалізуються як блок пам'яті, який копіюється з адресного простору відправника в адресний простір одержувача (або іншим чином примушується бути незмінним об'єктом), тому ви отримуєте безпеку потоку негайно.

У деяких випадках повідомлення, що передає відправника, повинен вказати одержувача, але в інших випадках ви можете просто опублікувати повідомлення на поштову скриньку, і будь-хто може слухати повідомлення в цій поштовій скриньці, тому є деяка гнучкість у тому, наскільки вони щільно з'єднані. Звичайно, у вас може бути поштова скринька, де укладено договір: «Я опублікую повідомлення на цю поштову скриньку під час цієї події станеться».

У випадку подій ви реєструєте делегата чи зворотний дзвінок у власника події. В об'єктно-орієнтованому програмуванні це означає, що власник події зберігає посилання на об'єкт, який зареєстрований для отримання події. Іноді це може призвести до кошмарів у бухгалтерському обліку, намагаючись з’ясувати, який об’єкт забув скасувати реєстрацію їх обробника подій. Це означає, що ціль не може збирати сміття, поки власник події не збирає сміття, навіть якщо ціль більше не робить нічого корисного.

Особисто я б вибрав повідомлення, що передають події, за винятком випадків, коли вам примусові такі події, як програмування графічного інтерфейсу Windows тощо.