Подійно-орієнтована архітектура
Подійно-орієнтована архітектура (англ. Event-driven architecture; надалі EDA) — шаблон архітектури програмного забезпечення, який призначений для створення подій, їх виявлення, споживання і реагування на них.
Подія може бути визначена як значна зміна стану.[1] Наприклад, коли споживач купує автомобіль, стан автомобіля змінюється з «на продаж» до «продано». Архітектура системи дилера автомобілів може трактувати цю зміну стану як подію, поява якої може стати відомою іншим застосункам даної архітектури.
З формальної точки зору, те, що виробляється, публікується, поширюється, виявляється і споживається (як правило, асинхронно) є повідомленням, яке називають сповіщенням про подію (або нотифікацією), а не самою подією, яка є зміною стану, що викликає появу повідомлення.
Події не подорожують, вони просто відбуваються. Проте термін подія часто використовується метонімічно для позначення самого нотифікаційного повідомлення, що може призвести до певної плутанини.
Цей архітектурний шаблон може застосовуватися при проектуванні і реалізації застосунків і систем, які передають події між слабкозв'язаними компонентами програмного забезпечення і сервісами (службами).
Подійно-орієнтована система як правило складається з емітерів подій (або агентів) і споживачів подій (або стоків). Стоки несуть відповідальність за здійснення реагування на появу події. Реакція не завжди може бути повністю забезпечена самим стоком. Наприклад, стік, може бути відповідальним лише за фільтрацію, трансформацію і відправку події до іншого компонента або він може забезпечити повністю самостійну реакцію на таку подію. Перша категорія стоків може бути заснована на традиційних компонентах, таких як проміжне програмне забезпечення, орієнтоване на обробку повідомлень (англ. message oriented middleware, MOM), в той час, як друга категорія стоків (самостійна реакція в режимі онлайн) може вимагати більш придатної платформи (фреймворку) для виконання транзакцій.
Розробка застосунків і систем в подійно-орієнтованій архітектурі дозволяє їм бути сконструйованими способом, який більш відповідає вимогам до їх створення, оскільки такі системи в більшій мірі пристосовуються до непередбачуваних і асинхронних середовищ.[2]
Подійно-орієнтована архітектура (EDA) може доповнювати сервісно-орієнтовану архітектуру (SOA), оскільки сервіси (служби) можуть бути активовані тригерами, які ініціюються при настанні подій.[2][3]
Ця парадигма особливо корисна, коли стік не забезпечує власного виконання будь-яких дій.
Обчислювальна техніка та сенсорні пристрої (сенсори, датчики, контролери) можуть виявляти зміни стану об'єктів або умов і створювати події, які потім можуть бути оброблені сервісом (службою) або системою.
Подія може складатися з двох частин: заголовка події та тіла події. Заголовок події може включати в себе інформацію таку як, наприклад, назва події, часова мітка події і тип події. Тіло події — це частина, яка описує факт, що стався в дійсності. Тіло події не слід плутати з шаблоном або логікою, яка може бути застосована як реакція на саму події.
Архітектура, керована подіями, складається з чотирьох логічних рівнів (шарів). Вона починається з виявлення факту, його технічного подання у формі події і закінчується непустою множиною реакцій на цю подію.[4]
Першим логічним шаром є генератор подій, який виявляє факт і представляє цей факт подією. Оскільки фактом може бути практично все, що може бути сприйнято, то ним може бути і генератор подій. Наприклад, генератором може бути клієнт електронної пошти, система електронної комерції або певний тип датчика. Перетворення різних даних, отриманих від датчиків, в єдину стандартизовану форму даних, які можуть бути оцінені, є основною проблемою при розробці та реалізації цього шару.[4] Однак, враховуючи, що подія є строго декларативною, можна легко застосовувати будь-які операції трансформації, тим самим усуваючи необхідність забезпечення високого рівня стандартизації.
Канал подій — це механізм, через який інформація від генератора подій передається до обробника подій (event engine)[4] або стоку. Це може бути з'єднання TCP/IP або вхідний файл будь-якого типу (простий текст, формат XML, e-mail тощо). В один і той же час може бути відкрито кілька каналів подій. Як правило, оскільки обробник подій повинен працювати в режимі, наближеному до реального часу, канали подій зчитуються асинхронно. Події зберігаються в черзі, очікуючи наступної обробки механізмом обробки подій.
Механізм обробки подій (event processing engine) є місцем, де подія ідентифікується і вибирається відповідна реакція на нього, яка потім виконується. Це також може призвести до породження ряду тверджень. Якщо подія, яка надійшла до механізму обробки подій, є наприклад такою «Запаси продукту ID досягли нижнього допустимого рівня», це може ініціювати, наприклад, такі реакції як «Замовити продукт ID» і «Сповістити персонал».[4]
Щодо того, як можуть проявлятися наслідки події, слід відмітити, що вони можуть проявитись багатьма різними способами і у різноманітних формах (наприклад, повідомлення електронної пошти, надіслане комусь, або застосунок, що виводить деяке попередження на екран).[4] Залежно від рівня автоматизації, який забезпечується стоком (механізмом обробки подій), ці дії можуть виявитись зайвими.
Є три основні стилі обробки подій: простий, потоковий і складний. Часто ці три стилі використовуються спільно у розвинутій подійно-орієнтованій архітектурі.[4]
Проста обробка подій стосується подій, які безпосередньо належать до специфічних вимірних змін умов. У випадку простої обробки подій, мають справу з появою відомих подій, що ініціюють післядію (післядії). Проста обробка подій зазвичай використовується для управління потоком робіт в реальному часі, скорочуючи тим самим час затримки і вартість робіт.[4]
Наприклад, прості події можуть створюватись (породжуватись) датчиком, що виявляє зміну тиску в шині або температуру навколишнього середовища.
При обробці потоку подій (ESP — англ. event stream processing) відбуваються як звичайні, так і відомі події. Звичайні події (заявки, передачі RFID) перевіряються на те, чи є вони відомими, і передаються інформаційним передплатникам. Обробка потоку подій зазвичай використовується для управління потоком інформації в реальному часі і на рівні підприємства, що дозволяє своєчасно приймати рішення.[4]
Обробка складних подій (Complex event processing (CEP)[en]) дозволяє за шаблонами простих і звичайних подій проводити аналіз того, чи сталася складна подія. Обробка складних подій полягає в оцінюванні взаємного впливу подій і в наступному виконанні дій. При цьому, типи подій (відомих або звичайних) можуть перетинатись, а події можуть виникати протягом тривалого періоду часу.
Кореляція подій може бути причинною, тимчасовою або просторовою. CEP вимагає використання складних інтерпретаторів подій, визначення і підбору шаблонів подій, а також відповідних кореляційних методів. Обробка складних подій зазвичай використовується для виявлення і реагування на аномальну поведінку, загрози і можливості у бізнесі.[4]
Подійно-орієнтована архітектура є екстремально слабко зв'язаною і добре розподіленою. Найкраща розподіленість цієї архітектури обумовлена тим, що подією може бути майже все, що завгодно, і подія може існувати майже скрізь, де завгодно.
Архітектура є екстремально слабко зв'язаною, оскільки подія сама по собі не знає про наслідки свого виникнення, тобто якщо у нас є охоронна система, що записує інформацію при відкритті зовнішніх дверей, то двері самі по собі не знають, що охоронна система додасть інформацію про відкриття дверей відразу, як тільки вони будуть відчинені.[4]
Подійно-орієнтовані архітектури мають слабкий зв'язок у просторі, часі і синхронізації, чим забезпечують масштабовану інфраструктуру для обміну інформацією і розподілених потоків робіт (workflow). В той самий час, подійні архітектури є тісно зв'язаними через підписку на події і шаблони подій з семантикою базової схеми подій і їх значень.
Високий рівень семантичної неоднорідності подій у масштабних і відкритих проектах, таких як «розумні міста» або сенсорні мережі типу «sensor web[en]», що застосовуються для моніторингу навколишнього середовища, ускладнює розвиток і підтримку подійно-орієнтованих систем. Усунення цих проблем є активною областю досліджень в галузі застосування методів наближеного семантичного зіставлення подій.[5]
Прикладний програмний інтерфейс (API) бібліотеки Java Swing заснований на подійно-орієнтованій архітектурі.
Це особливо добре узгоджується з мотивацією Swing надавати необхідні компоненти і функціональність, що відносяться до інтерфейсу користувача. Інтерфейс використовує домовленості про найменування (наприклад, «ActionListener» і «ActionEvent») для встановлення зв'язків і організації відносин між подіями. Клас, який потребує сповіщення про певну подію, просто реалізує відповідного слухача, перевизначає успадковані методи і додається до об'єкта, який породжує подію. Нижче приведено досить простий приклад:
public class FooPanel extends JPanel implements ActionListener {
public FooPanel() {
super();
JButton btn = new JButton("Click Me!");
btn.addActionListener(this);
this.add(btn);
}
@Override
public void actionPerformed(ActionEvent ae) {
System.out.println("Button has been clicked!");
}
}
Як альтернативу можна навести приклад реалізації з додаванням слухача в об'єкт анонімного класу.
public class FooPanel extends JPanel {
public FooPanel() {
super();
JButton btn = new JButton("Click Me!");
btn.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ae) {
System.out.println("Button has been clicked!");
}
});
}
}
- Подійно-орієнтоване програмування
- Багатоетапна подійно-орієнтована архітектура (SEDA)
- Сервісно-орієнтована архітектура (SOA)
- Стаття про відмінності між EDA і SOA: How EDA extends SOA and why it is important [Архівовано 8 березня 2021 у Wayback Machine.] by Jack van Hoof. (англ.)
- Реальний приклад потоку бізнес-подій в SOA: SOA, EDA, and CEP — a winning combo [Архівовано 7 листопада 2013 у Wayback Machine.] by Udi Dahan. (англ.)
- ↑ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
- ↑ а б Jeff Hanson, Event-driven services in SOA [Архівовано 2 червня 2013 у Wayback Machine.],Javaworld, January 31, 2005
- ↑ Carol Sliwa Event-driven architecture poised for wide adoption [Архівовано 20 березня 2017 у Wayback Machine.], Computerworld, May 12, 2003
- ↑ а б в г д е ж и к л Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006
- ↑ Hasan, Souleiman, Sean O'Riain, and Edward Curry. 2012. «Approximate Semantic Matching of Heterogeneous Events.» [Архівовано 11 травня 2013 у Wayback Machine.] In 6th ACM International Conference on Distributed Event-Based Systems (DEBS 2012), 252—263. Berlin, Germany: ACM. «DOI».
- Industry website on Event Processing [Архівовано 8 березня 2022 у Wayback Machine.] (англ.)
- Website for the Event Processing Technical Society [Архівовано 4 вересня 2019 у Wayback Machine.] (англ.)
- 5th Anniversary Edition: Event-Driven Architecture Overview, Brenda M. Michelson [Архівовано 7 листопада 2013 у Wayback Machine.] (англ.)
- Complex Event Processing and Service Oriented Architecture [Архівовано 30 жовтня 2012 у Wayback Machine.] (англ.)
- How EDA extends SOA and why it is important [Архівовано 8 березня 2021 у Wayback Machine.] by Jack van Hoof (англ.)
- Романов А. В. Событийно-управляемая архитектура (EDA) как эффективное развитие сервис-ориентированной архитектуры (SOA)[недоступне посилання з липня 2019] (рос.)