SOA Suite je zajímavou kompilací technologií, které, poskládány dohromady, stojí na architektonickém principu SCA (
Service Component Architecture). Patří sem například implementace BPELu, business rules a human tasků. A jednou z těchto technologií je i
Event Delivery Network (EDN), což je implementace paradigmatu
Event Driven Architecture (EDA).
Event Driven Architecture
Even Driven Architecture (EDA) může být alternativou, nebo doplňkem k Servisně orientované architektuře (SOA). Ale EDN se netýká pouze SOA - tento architektonický princip najdeme i uvnitř GUI frameworků, jako je Java
Swing, nebo Apache (dříve Adobe)
Flex.
Jak už napovídá název, vše se v této architektuře motá kolem událostí. Událost je v EDA first-class citizen. Vlastně je to jediný citizen (obyvatel). Ale co to vlastně ta událost je? Událost je v podstatě zpráva, podobně jako zpráva má hlavičku a tělo. V hlavičce jsou samozřejmě meta-data, např. jméno a typ zprávy, timestamp apod. Zásadní rozdíl je v obsahu těla události (payload), ten bývá zpravidla velmi malý a měl by obsahovat pouze popis faktu, který událost instancoval. Někdy payload ani být nemusí - pokud je událost určitého typu, stačí pouze vědět, že nastala.
A jak taková událost zapadá do architektury? Dalším významem akronymu EDA by mohlo být: Extremely Decoupled Architecture. Události, které nejsou nijak svázány s konkrétním producentem, jsou publikovány do nějaké centrální generické infrastruktury. Producenti publikují události stylem fire-and-forget a vůbec se nestarají o to, kdo je jejich konzumentem.
Konzumentem je pak kdokoli, kdo se zajímá o výskyt určitého typu události. Pro konzumenty je původ události neznámý - neví kdo ji publikoval, oni se pouze dozvědí, že nastala. Na konzumentovi pak leží veškerá zodpovědnost za správné business zpracování události. S tím souvisí i to, že příjemce může konzumované události filtrovat.
 |
| Event Driven Architecture (barvy představují typy událostí) |
Z předešlého komponentového diagramu vyplývá několik věcí. Jednak že v EDA existují v podstatě jen dva základní komponenty - Event Coordinator, který si můžeme představit jako jakýsi "event bus" (podle vzoru
service bus) pro události, který se stará o publikování událostí, přihlášení (subscription) konzumentů apod.
A pak jednotlivé uzly (nody). Ty mohou fungovat buď jako producenti událostí (Node 3), nebo jejich konzumenti (Node 2, Node 5), anebo obojí (Node 1, Node 4). Každý node může publikovat nebo přijímat více typů událostí. Že jeden typ události může být konzumovaný více nody asi nikoho nepřekvapí (
oranžová událost konzumovaná Nody 1 a 4). Daný typ události ale může taky být publikovaný více producenty (
fialová událost publikovaná Nody 3 a 4).
To by, myslím, mohlo stačit, jako takový velmi lehoulilinký úvod do EDA a teď se podíváme na jednu její konkrétní implementaci.
Event Delivery Network
Event Delivery Network (EDN), která je součástí
SOA Suite, je infrastruktura (postavená na JMS), která poskytuje deklarativní způsob definice událostí, jejich publikování a registraci jejich konzumace. Tři hlavní entity, se kterými pracuje jsou producent událostí, konzument událostí a události samotné.
Definice události
Události jsou v EDN definované názvem a typem a jsou uloženy v souboru s příponou
edl. Tento soubor může být umístěný buď v rootu projektu, nebo v MDS (MetaData Services repository).
xml version="1.0" encoding="UTF-8" standalone="yes"
<definitions
xmlns="http://schemas.oracle.com/events/edl"
targetNamespace="http://sw-samuraj.cz/events/SimpleEvent-v1">
<schema-import
namespace="http://sw-samuraj.cz/events/simpleMessage-v1"
location="xsd/simpleMessage-v1.0.xsd"/>
<event-definition name="SimpleEvent">
<content
xmlnssim="http://sw-samuraj.cz/events/simpleMessage-v1"
element="sim:simpleMessage"/>
</event-definition>
</definitions>
 |
| Definice události |
Typ je popsán pomocí XSD:
xml version="1.0" encoding="UTF-8"
<xsdschema xmlnsxsd="http://www.w3.org/2001/XMLSchema"
xmlnssim="http://sw-samuraj.cz/events/simpleMessage-v1"
targetNamespace="http://sw-samuraj.cz/events/simpleMessage-v1"
elementFormDefault="qualified">
<xsdelement name="simpleMessage">
<xsdcomplexType>
<xsdsequence>
<xsdelement name="timestamp" type="xsd:dateTime"/>
<xsdelement name="status">
<xsdsimpleType>
<xsdrestriction base="xsd:string">
<xsdenumeration value="ON"/>
<xsdenumeration value="OFF"/>
</xsdrestriction>
</xsdsimpleType>
</xsdelement>
</xsdsequence>
</xsdcomplexType>
</xsdelement>
</xsdschema>
 |
| Typ události definovaný v XSD |
Publishers
Producentem události může být buď BPEL proces, nebo Mediator. V případě Mediatoru je publikování události přímočaré - v definici akce se místo
invoke zavolá
raise s patřičnou události.
 |
| Publikování události v Mediatoru |
Graficky pak vypadá kompozitní aplikace s publikujícím Mediatorem takto:
 |
| Mediator event publisher (kompozitní aplikace) |
U BPEL procesu je situace maličko složitější. Vzhledem k tomu, že BPEL je otevřený standard, do kterého události nepatří, řeší to SOA Suita (standardním) BPEL extension. Událost se tak dá publikovat pomocí rozšíření z aktivity
Invoke.
 |
| Publikování události v BPELu z aktivity Invoke |
 |
| BPEL event publisher (kompozitní aplikace) |
Všimněte si, že jak v případě Mediatoru, tak BPELu končí implementace publikování události na dané komponentě. Kdyby totéž bylo implementováno pomocí messagingu, musel by být v kompozitní aplikaci definován ještě JCA adaptér s pevně uvedenou destinací. Tohle u EDA/EDN není potřeba.
Subscribers
Konzumentem události může být opět buď Mediator nebo BPEL komponent.
 |
| Subskripce události v Mediatoru |
 |
| Mediator event subscriber (kompozitní aplikace) |
Podobně jako u publikování i u konzumace událostí si BPEL vypomáhá rozšířením, tentokrát v rámci aktivity
Receive.
 |
| Subskripce události v BPELu v aktivitě Receive |
 |
| BPEL event subscriber (kompozitní aplikace) |
Monitorování událostí
Asi trochu překvapí, že již publikované, ale ještě nezkonzumované události nelze nikde vidět. Alespoň ne standardními nástroji. V podstatě lze vidět pouze "historický otisk" událostí. Něco jako: tudy kráčely dějiny :-)
Cestu události lze vidět v Enterprise Manageru:
 |
| Audit trace události (Enterprise Manager) |
V uvedeném logu publikuje Mediator
Publisher událost, která je konzumována dvěma konzumenty: Mediator
Subscriber a BPEL komponent
BpelSubscriber. Zároveň je vidět, že Enterprise Manager loguje celou cestu události - ačkoliv jsou producent a konzumenti události od sebe odděleni a vůbec o sobě nemají povědomí, v audit logu je to zaznamenáno jako jeden souvislý tok události.
BPEL nebo Mediator?
Na základě čeho se rozhodnout, kterou komponentu použít pro konzumaci/publikování události? Jednodušší a přímočařejší je použití Mediatoru. Koneckonců to doporučuje i sám Oracle. BPEL má jedinou výhodu - jako konzument může události korelovat. Čili pokud je reakcí na nějakou událost jiná událost a obě dvě jsou zpracovávány stejnou kompozitní aplikací, tak jejich korelace je možná pouze v BPEL procesu.
Závěr
Event Delivery Network (EDN) je standardní součástí SOA Suity a nabízí out-of-the-box implementaci Event Driven Architecture (EDA). Pokud nepotřebujeme robustní a konfigurovatelné messaging řešení, může být EDN vhodnou, rychle provozovatelnou alternativou.
Rozhodně bych ale EDN nedoporučoval použít pro kritické části systému. Byť je postavena na prověřené JMS platformě, její možnosti z hlediska konfigurace, provozování, monitoringu atd. jsou velmi omezené - berte jak to je, nebo nechejte být.
Související články
