Marko Lah EDA + SOA – DOGODKOVNO VODENE STORITVENE APLIKACIJE Diplomsko delo Maribor, junij 2009
Marko Lah
EDA + SOA – DOGODKOVNO VODENE STORITVENE APLIKACIJE
Diplomsko delo
Maribor, junij 2009
I
Diplomsko delo univerzitetnega – univerzitetni študijski program
EDA + SOA – DOGODKOVNO VODENE STORITVENE
APLIKACIJE
Študent: Marko Lah
Študijski program: UN – Računalništvo in informatika
Smer: Informatika
Mentor: prof. dr. Marjan Heričko
Maribor, junij 2009
II
ZAHVALA
Zahvaljujem se mentorju prof. dr. Marjanu Heričku
za pomoč in vodenje pri opravljanju diplomskega
dela.
Posebna zahvala velja mami in bratu, ki sta mi
omogočila študij. Hvala tudi Katarini za podporo.
III
EDA + SOA – DOGODKOVNO VODENE STORITVENE
APLIKACIJE
Ključne besede: dogodkovno vodene, storitveno usmerjene, dogodek, storitveno vodilo,
Objavi/Naroči, nServiceBus, OpenESB
UDK: 004.451.2(043.2)
Povzetek:
V diplomskem delu smo predstavili značilnosti in gradnike dogodkovno
vodenih arhitektur. Opisali smo tudi načine procesiranja dogodkov ter
natančneje preučili razvoj dogodkovno vodenih sistemov in procesiranja
dogodkov zadnjih 50 let. Preučili smo tehnologije tiste SOA, ki nam lahko
pomagajo pri razvoju dogodkovno vodenih sistemov. Pridobljeno teoretično
znanje smo uporabili pri implementaciji pilotskega projekta, ki zajema
integracijo dveh dogodkovno vodenih sistemov, grajenih na različnih
programskih platformah (JAVA in .NET). V ta namen smo uporabili
odprtokodni ogrodji nServiceBus, ki temelji na .NET okolju , in storitveno
vodilo OpenESB povezavi s komponento za procesiranje dogodkov IEP SE, ki
temelji na JAVA okolju.
IV
EDA + SOA – EVENT DRIVEN SERVICE APPLIACTIONS
Key words: event-driven, service oriented, event, enterprise service bus,
Publish/Subscribe, nServiceBus, OpenESB
UDC: 004.451.2(043.2)
Abstract:
In this diploma work we have represented the concepts and features of event -
driven architecture. We described the event process types, especially the
complex event processing, and created an overview of the event -driven
architecture and event processing development in the last 50 years. We studied
also those SOA technologies, which could help us to implement event-driven
architecture based systems. We used the obtained theoretical knowledge on an
implementation of an event-driven prototype project, which consist o f event-
driven system built on different programming platforms (JAVA and .NET). We
used nServiceBus to implement the messaging framework in the .NET part and
the enterprise service bus implementation OpenESB in combination with the
event processing component IEP SE, which is based on JAVA.
V
KAZALO
1. Uvod ............................................................................................................................... 1
2. Značilnosti dogodkovno vodenih arhitektur .................................................................. 5
2.1. Definicija dogodkovno vodenih arhitektur ............................................................. 7
2.2. Definicija dogodka ................................................................................................ 11
2.3. Iniciatorji dogodkov .............................................................................................. 13
2.4. Odjemalci dogodkov ............................................................................................. 13
2.5. Procesor dogodkov ............................................................................................... 13
2.6. Sporočilna hrbtenica ............................................................................................. 14
2.7. Komponente implementacije dogodkovno vodenih arhitektur ............................. 14
2.8. Procesiranje dogodkov .......................................................................................... 15
2.8.1. Preprosto procesiranje dogodkov ...................................................................... 15
2.8.2. Tokovno procesiranje dogodkov ....................................................................... 17
2.8.3. Kompleksno procesiranje dogodkov ................................................................. 18
Diskretne simulacije dogodkov ....................................................................................... 19
Računalniška omreţja ...................................................................................................... 20
Aktivne podatkovne baze ................................................................................................ 22
Povezovalne tehnologije .................................................................................................. 23
3. Povezava med storitveno orientiranimi in dogodkovno vodenimi arhitekturami ........ 25
3.1. Spletne storitve ..................................................................................................... 26
3.2. SOAP oblika sporočila .......................................................................................... 27
3.3. WSDL dokument .................................................................................................. 27
3.4. UDDI register ....................................................................................................... 28
3.5. Storitveno vodilo (ESB – Enterprise Service Bus) ............................................... 28
3.5.1. Storitve storitvenih vodil ................................................................................... 29
VI
3.7. Šibka sklopljenost ................................................................................................. 32
3.8. Uporaba storitveno orientiranega pristopa pri dogodkovno vodenih arhitekturah 32
3.9. Primerna razvojna ekipa za implementacijo dogodkovno vodenih sistemov s
pomočjo SOA .................................................................................................................. 33
3.9.1. Idealen primer ................................................................................................... 33
3.9.2. Situacija v realnih projektih .............................................................................. 34
4. Implementacija dogodkovno vodenih arhitektur.......................................................... 36
4.1. IBM rešitev ........................................................................................................... 37
4.2. Oracle rešitev ........................................................................................................ 38
4.3. TIBCO rešitev ....................................................................................................... 40
4.4. Microsoftova rešitev ............................................................................................. 42
4.5. Implementacija prototipa sistema na dogodkovno orientirane arhitekture ........... 45
4.5.1. Javansko storitveno vodilo OpenESB in procesor dogodkov IEP .................... 45
4.5.2. nServiceBus ....................................................................................................... 47
4.5.3. Uporaba vzorca Objavi/Naroči.......................................................................... 48
4.5.4. Sprejemnik ........................................................................................................ 48
4.5.5. Oddajnik ............................................................................................................ 50
4.5.6. Opis scenarija .................................................................................................... 51
4.5.7. Implementacija scenarija ................................................................................... 55
4.5.8. Implementacija dogodkovno vodene arhitekture s pomočjo ogrodja
nServiceBus ..................................................................................................................... 56
4.5.9. Implementacija preprostega procesiranja dogodkov ......................................... 63
4.5.10. Implementacija kompleksnega procesiranja dogodkov ................................. 65
4.5.11. Implementacija dogodkovno vodene arhitekture s pomočjo OpenESB in IEP
66
4.5.12. Integracija med sistemoma, ki implementirata EDA na različnih tehnoloških
platformah 69
VII
5. Sklep ............................................................................................................................. 70
6. Viri, literatura ............................................................................................................... 73
VIII
KAZALO SLIK
Slika 1: Prikaz osnovnega koncepta dogodkovno vodenih arhitektur ................................... 6
Slika 2: Prikaz delovanja ABS sistema s pomočjo dogodkov ............................................... 8
Slika 3: Prikaz sodelovanja uporabniških interesnih skupin v dogodkovno vodenem
sistemu ................................................................................................................................. 10
Slika 4: Komponente implementacije dogodkovno vodenih sistemov [1] .......................... 15
Slika 5: Shematičen prikaz primera procesiranja preprostih dogodkov .............................. 16
Slika 6: Shematičen prikaz primera tokovnega procesiranja dogodkov.............................. 18
Slika 7: Prikaz razvoja dogodkovno procesnih tehnologij skozi zadnjih 50 let .................. 19
Slika 8: Primer abstrakcije dogodkov, kjer prikaţemo pogled »aplikacija-do-aplikacije« . 21
Slika 9: Shematičen prikaz aktivnih podatkovnih baze ....................................................... 22
Slika 10: Shematičen prikaz kompleksnega procesiranja dogodkov .................................. 24
Slika 11: Prikaz osnovnega principa delovanja storitveno orientiranih arhitektur ............. 26
Slika 12: Shematičen prikaz osnovnega koncepta delovanja spletnih storitev ................... 27
Slika 13: Prikaz vloge storitvenega vodila pri komunikaciji dveh storitev preko različnih
protokolov [7] ...................................................................................................................... 30
Slika 14: Prikaz spreminjanja vsebine sporočil s strani storitvenega vodila ....................... 31
Slika 15: Prikaz korakov razvoja EDA + SOA v idealnih pogojih ..................................... 34
Slika 16: Prikaz korakov razvoja EDA + SOA v realnih pogojih ....................................... 35
Slika 17: Shematičen prikaz Oracle EDA Suite [10] .......................................................... 38
Slika 18: Shema zgradbe sistema TIBCO Business Events [18] ........................................ 41
Slika 19: Shematičen prikaz razmerja med poslovnimi pravili, dogodki in procesiranjem
dogodkov [18] ..................................................................................................................... 41
Slika 20: Prikaz moţnosti, ki jih ponuja streţnik BizTalk v vlogi storitvenega vodila [20]42
Slika 21: Shematičen prikaz delovanja komponent streţnika BizTalk v dogodkovno
vodenem scenariju ............................................................................................................... 44
Slika 22: Mesto IEP v arhitekturi OpenESB ....................................................................... 46
Slika 23: Shematičen prikaz delovanja vzorca Objavi/Naroči ............................................ 49
Slika 24: Prikaz delovanja vzorca Objavi/Naroči z uporabo centralne konfiguracijske enote
............................................................................................................................................. 50
Slika 25: Prikaz zgradbe pametnega vozička ...................................................................... 52
IX
Slika 26: Zgradba sistema za spremljanje pametnih vozičkov ............................................ 53
Slika 27: Zgradba sistema podjetja MySecurity Corp. ........................................................ 54
Slika 28: Celotna shema sodelovanja podjetij ..................................................................... 55
Slika 29: Koncept spletne storitve, ki skrbi za pošiljanje sporočil ...................................... 59
Slika 30: Prikaz diagrama zgradbe podatkovne baze, kamor procesor dogodkov shranjuje
podatke o prejetih dogodkih ................................................................................................ 60
Slika 31: Posnetek procesorja dogodkov v izhodiščnem stanju .......................................... 64
Slika 32: Prikaz na ekranu izhodiščnega stanja na ekranu pametnega vozička .................. 64
Slika 33: Prikaz stanja v procesorju v trenutku, ko ta prejme dogodek, povezan z menjavo
lokacije ................................................................................................................................ 65
Slika 34: Prikaz stanja na ekranu vozička v trenutku, ko prejme dogodek procesorja ....... 65
Slika 35: Koraki primera kompleksnega procesiranja dogodkov ........................................ 66
Slika 36: Prikaz grafičnega okolja v Netbeans za implementacijo procesiranja dogodkov za
podjetje MySecurity ............................................................................................................ 67
Slika 37: Prikaz primera uporabe operatorja "Stream Projection And Filter" .................... 68
Slika 38: Prikaz BPEL procesa, ki prikazuje dogajanja po tem, ko zaznamo relevanten
dogodek ............................................................................................................................... 69
KAZALO TABEL
Tabela 1: Osnovne karakteristike SOA [7].......................................................................... 29
Tabela 2: Osnovne karakteristike EDA [7] ......................................................................... 29
X
KAZALO PRIMEROV
Primer 1: Primer dela konfiguracijske datoteke, kjer določimo konfiguracijo prejemnika
dogodkov ............................................................................................................................. 57
Primer 2: Primer dela konfiguracijske datoteke, kjer določimo konfiguracijo oddajnika
dogodkov ............................................................................................................................. 58
Primer 3: Prikaz izseka kode, ki je potreben za objavo sporočila na vodilu ....................... 59
Primer 4: Koda, ki definira vmesnik IEvent ........................................................................ 61
Primer 5: Implementacija razreda, ki definira tip dogodka, kateri se pojavi, ko stranka
prevzame nov voziček ......................................................................................................... 62
Primer 6: Izsek kode, ki definira opravilnik sporočil tipa CartRequested........................... 63
XI
UPORABLJENE KRATICE
LAN – Local Area Network
CRM – Customer Relationship
Management
SCADA – Supervisory Control And Data
Acquisition
RFID – Radio-Frequency Identification
SOAP – Simple Object Access Protocol
WSDL – Web Services Description
Language
UDDI – Universal Description, Discovery
and Integration
ESB – Enterprise Service Bus
SOA – Service-Oriented Architecture
EDA – Event-Driven Architecture
EE – Enterprise Edition
JBI – Java Business Integration
JMS – Java Messaging System
WS – Web Service
XML – Extensible Markup Language
XSLT – Extensible Stylesheet Language
Transformations
SAML – Security Assertion Markup
Language
MTOM – Message Transmission
Optimization Mechanism
BPEL – Business Process Execution
Language
SE – Service Engine
IEP – Intelligent Event Processor Service
Engine
CQL – Continous Query Language
JDBC – Java Database Connectivity
SQL – Structured Query Language
IIS – Internet Information Server
IBM – International Business Machines
Corporation
EDI – Electronic Data Interchange
BAM – Business Activity Monitoring
MSMQ – Microsoft Message Queuing
CEP – Complex Event Processor
MQ – Message Queuing
ORB – Object Request Broker
Pub/Sub – Publish/Subcribe
MOM – Message Oriented Middleware
DISP - Device Service Provider Interface
ARPA Net - Advanced Research Projects
Agency Network
ECA - Event-Condition-Action
ORD - Object Request Broker
MOM - Message Oriented Meddleware
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 1
1. UVOD
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 2
Če pogledamo svet okoli nas, nam ne uide, da se venomer nekaj spreminja in dogaja. V
naravi se tako spreminja zračni tlak, temperatura, vlaţnost, koncentracija različnih plinov,
itn. Tudi v poslovnem okolju ni drugače. Vsak dan, vsako uro, minuto in danes celo
sekundo se dogajajo spremembe, ki lahko dramatično vplivajo na razvoj podjetja. Gibanje
delnic, sprememba zalog v skladiščih, spreminjanje cen surovin, spreminjanje obrestnih
mer in še bi lahko naštevali. Vse prej naštete spremembe so posledice dogodkov.
Glavni cilj dogodkovno vodenih storitvenih aplikacij in sistemov je ponuditi organizacijam
informacijsko podporo, ki omogoča spremljanje, analiziranje in reagiranje na relevantne
spremembe v čim krajšem času. [1]
Ker lahko dogodki spremenijo tudi delovanje in usmeritve organizacij, je zelo pomembno,
da zagotovimo agilnost sistemov. Omogočiti moramo enostavno, hitro in cenovno ugodno
prilaganje in delovanje sistema, v smislu spremljanja in obdelave dodatnih tipov
relevantnih dogodkov.
Namen diplomske naloge je razloţiti delovanje dogodkovno vodenih storitvenih aplikacij
ter opisati moţnosti njihove implementacije s pomočjo orodij, kot so spletne storitve,
storitveno vodilo (ESB) ali SOAP (Simple Object Acess Protokol), ki jih s seboj prinaša
uporaba storitveno usmerjenih arhitektur (SOA).
Osnovna cilja diplomske naloge sta prikazati zmoţnost implementacije dogodkovno
usmerjenih aplikacij in sistemov s pomočjo SOA ter prikazati moţnost njihove
implementacije in integracije s pomočjo odprtokodnih ogrodji, ki temeljijo na okoljih
.NET in JAVA.
Pri raziskavi dogodkovno usmerjenih storitvenih sistemov se bomo osredinili na uporabo
asinhronega komunikacijskega vzorca Objavi/Naroči.
Implementacijo praktičnega primera bomo ločili na dva večja dela. Prvi del bomo
implementirali s pomočjo odprtokodnega komunikacijskega ogrodja nServiceBus 1.9 RC1,
ki temelji na Microsoftovem okolju .NET 3.5. Za implementacijo drugega dela
implementacije bomo uporabili storitveno vodilo OpenESB, ki temelji na okolju JAVA,
skupaj s komponento IEP SE (Intelligent Event Processor Service Engine).
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 3
Najprej se bomo lotili dogodkovno vodenih storitvenih aplikacij in sistemov s teoretičnega
vidika. Definirali bomo dogodek, vrste procesiranja dogodkov, storitveno orientirane
arhitekture s pripadajočimi tehnologijami in njihov pomen za razvoj dogodkovno
usmerjenih sistemov. Prav tako bomo opisali komunikacijski vzorec Objavi/Naroči. Za
prikaz moţnosti implementacije in integracije dogodkovno usmerjenih aplikacij in
sistemov, z uporabo SOA konceptov, bomo implementirali dva dogodkovno usmerjena
sistema, ki bosta spremljala dogajanje in med seboj sodelovala v namišljenem scenariju.
Na začetku bomo definirali dogodek, ki predstavlja osnovno enoto v sistemih, temelječih
na dogodkovno usmerjenih arhitekturah. Prav tako bomo definirali generatorje oz.
iniciatorje dogodkov, odjemalce dogodkov, procesorje dogodkov in sporočilno hrbtenico.
Podrobneje bomo pogledali osnovne tipe procesiranja in njihovo delovanje razloţili s
praktičnim primerom.
V naslednjem poglavju bomo našo pozornost bolj preusmerili na povezavo med SOA in
dogodkovno vodenimi arhitekturami (EDA). Pogledali bomo, kako lahko tehnologije, kot
so spletne storitve, SOAP, storitvena vodila (ESB) in UDDI (Universal Description,
Discovery and Integration) registre, uporabimo pri realizaciji dogodkovno usmerjenih
storitvenih aplikacij.
V četrtem poglavju se bomo najprej lotili pregleda komercialnih programskih platform in
rešitev, ki so namenjene razvijanju dogodkovno vodenih sistemov. Nato bomo pregledali
implementacijo pilotnega dogodkovno usmerjenega sistema, ki bo sluţil kot informacijska
podpora pri sodelovanju med namišljenima podjetjema MyWallmart in MySecurity Corp.
MyWallmart bo predstavljal namišljeno veleblagovnico, ki jo varuje varnostna sluţba
MySecurity Corp. Za obe druţbi bomo implementirali sistema, ki bosta upoštevala
paradigme dogodkovno usmerjenih arhitektur. Razlika med njima bo v platformah, na
katerih sta sistema druţb grajena. Rešitev za namišljeno podjetje MyWallmart bomo
implementirali na osnovi komunikacijskega ogrodja nServiceBus in okolja .NET 3.5.
Drugi del primera, ki pokriva sistem namišljenega podjetja MySecurity Corp., pa bo
temeljil na odprtokodnem storitvenem vodilu OpenESB in pripadajoči komponenti za
modeliranje procesiranja dogodkov IEP SE (Intelligent Event Processor Service Engine).
V tem poglavju bomo prav tako predstavili nekaj komercialnih paketov, namenjenih
razvijanju dogodkovno usmerjenih aplikacij in sistemov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 4
Z implementacijo praktičnega primera ţelimo prikazati eno izmed moţnosti
implementacije dogodkovno vodenih arhitektur (EDA) s pomočjo SOA tehnologij,
moţnosti implementacije in delovanja asinhronega komunikacijskega vzorca
Objavi/Naroči in moţnosti realizacije procesiranja dogodkov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 5
2. ZNAČILNOSTI DOGODKOVNO VODENIH ARHITEKTUR
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 6
Če bi izkušenega podjetnika vprašali, kaj je edina konstanta v poslovnem svetu, bi
najverjetneje odgovoril, da so to spremembe. Le-teh pa ne smemo reducirati samo na
poslovanje podjetij, ampak so del našega vsakdanjega ţivljenja. Tako lahko vsak dan
zaznamo različne spremembe, na primer spreminjanje naravnih pojavov (npr. temperatura,
vlaţnost ali zračni tlak), spreminjanje ekonomskih in političnih razmer, spreminjanje
našega telesa. Gonilna sila sprememb pa so dogodki. Dogodek, kot je na primer vojna na
Bliţnjem vzhodu, lahko povzroči višanje cen surove nafte. Povišanje je spet dogodek, ki
spremeni ceno naftnih derivatov. Ta sprememba spet lahko vpliva na letno raven inflacije
in še bi lahko naštevali. Pri dogodku gre za spremembo obstoječega stanja, ki lahko vpliva
na določeno mnoţico drugih elementov [2].
Pri dogodkovno vodenih arhitekturah gre za analogno razmišljanje. V sistemu imamo
avtonomne komponente, kot so senzorji, čitalci, analitični algoritmi ipd., ki spremljajo
dogajanje v določenem domenskem prostoru. Ta se lahko razteza od temperature v
prostoru, zasedenosti diska, spremljanja transakcij banke ali porabe energije v enodruţinski
hiši. Ob vsaki določeni spremembi bo ta komponenta objavila dogodek na skupno vodilo.
Te komponente imenujemo iniciatorji ali generatorji dogodkov. Na drugi strani pa imamo
odjemalce dogodkov, ki pa so na skupno vodilo priklopljeni in čakajo na določen tip
dogodka. Ko ga zaznajo, lahko proţijo nadaljnje izvajanje, katerega posledica bodo spet
novi dogodki.
Stanje A Stanje B
Dogodek
Iniciatorji dogodkov Odjemalci dogodkov Procesorji dogodkov Reakcije na dogodke
Sporočilna hrbtenica
Tok sporočil
Slika 1: Prikaz osnovnega koncepta dogodkovno vodenih arhitektur
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 7
2.1. Definicija dogodkovno vodenih arhitektur
Dogodkovno vodena arhitektura ima zmoţnost zaznavati dogodke in se inteligentno
odzvati na njih. Dogodek je definiran kot sprememba stanja, ki si zasluţi pozornost
oziroma je relevantna za sistem in njegovo delovanje [1]. Pri spremljanju okolja se pojavi
ogromna količina različnih sprememb, ki bi jih lahko interpretirali kot relevantne dogodke.
Zato je pomembno premišljeno določiti meje relevantnosti. Prevelike količine podatkov bi
precej oteţile procesiranje dogodkov in njihovo tolmačenje.
Primer dogodkovno vodenih arhitektur lahko najdemo v naših avtomobilih. Sistem ABS je
postal nepogrešljiv v modernejših motornih vozilih. Njegova naloga je preprosta. Če se
kolesa vrtijo z večjo hitrostjo kot 8 kilometrov na uro, potem prepreči, da bi zavore
blokirale kolesa. Na zavorah imamo senzor, ki spremlja nenehno vrtenje nazobčane
pogonske ročice. Ko zazna relevantno spremembo, se pravi blokiranje koles pri predhodno
višji hitrosti kot 8 kilometrov na uro, pošlje signal v centralno nadzorno enoto avtomobila.
Tam čaka določena rutina na takšen tip dogodka in ob njegovem pojavu pošlje do
zavornega sistema ukaz, naj za kratek čas sprosti zavore. Zatem je spet naloga senzorja na
zavorah, da zazna, ali se kolesa premikajo ali stojijo.
Iz tega primera lahko vidimo, da osnovna ideja pri dogodkovno vodenih arhitekturah ni
nova. Osnovni koncept delovanja je uporabljen v aplikacijah avtomobilske industrije,
vojske oziroma na področjih, kjer je potrebno spremljati in se odzvati na spremembe v
realnem času.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 8
Senzorji, ki z posredujejo dogodke oz. informacijo o
rotaciji koles
Procesna enota, ki sprejema dogodke oz. podatke o rotaciji koles, na podlagi katerih analizira ali kolo
med zaviranje blokira.
Rotacija: DAHitrost: 20 km/hČas: 19:17:22156
Rotacija: DAHitrost: 20 km/hČas: 19:17:2333
Rotacija: DAHitrost: 20 km/hČas: 19:17:2288
Rotacija: DAHitrost: 20 km/hČas: 19:17:2199
Slika 2: Prikaz delovanja ABS sistema s pomočjo dogodkov
Za boljše razumevanje poglejmo še scenarij, ki opisuje uporabo dogodkovno vodenih
sistemov v mednarodnem letalstvu. V zadnjih dvajsetih letih je naraščalo število potnikov
in s tem letal ter letalskih druţb. S povečanjem prometa v zraku in konkurence na tleh se je
povečala tudi zahtevnost samega dela za letališča in letalske ponudnike.
Z vidika letalske druţbe je pomembno, da se njihovo letalo čim manj nahaja na tleh in da
leti čim bolj zasedeno. Takšna situacija za njih pomeni največji dobiček. Nepričakovani
dogodki, kot so čakanje pri vzletu ali pristajanju, zamuda potnikov, tehnične okvare letala
itn. lahko negativno vplivajo na poslovanje. Zato je ključnega pomena, da jih odkrijemo
prej, kot se dejansko pojavijo, oz. da se na njih pravilno odzovemo.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 9
Interes lastnikov letališč in podpornih sluţb (npr. serviserji letal, čistilne ekipe, prehrana,
itn.) je, da na njihovih letališčih pristane in z njih odleti čim več letal v čim krajšem času,
saj bi to za njih pomenilo večji dobiček. Pozabiti pa ne smemo še na kontrolne inštitucije,
ki mora, kljub večanju frekvence letov, zagotavljati konstantno raven varnosti za potnike.
Kot lahko vidimo je v samo letenje vključenih kar nekaj strank, ki morajo v primeru
nepričakovanih dogodkov uskladiti svoje delo. Sistem, ki ţeli tako podpreti takšno
dogajanje mora izpolnjevati naslednje zahteve [3]:
sporočanje stanja v realnem času za strojne in človeške odjemalce,
moţnost avtomatičnega odzivanja na določene situacije,
strojni in človeški vmesniki morajo biti prilagodljivi in razširljivi,
zagotavljanje delovanja za spremenljivo število interesnih skupin,
moţnost predvideti, razrešiti in pozneje analizirati probleme ozkega grla, ki lahko
nastopijo pri letalskem prometu,
moţnost modeliranja »kaj če« scenarijev za uporabniške interesne skupine
Omogočiti komunikacijo med uporabniškimi interesnimi skupinami
Zagotoviti varnost, zanesljivost, sledljivost in poročanje
Naš sistem bi tako predstavljal povezovalni člen med vsemi interesnimi skupinami, ki
sodelujejo pri izvajanju mednarodnih poletov. Zaplet pri eni izmed interesnih skupin lahko
vpliva na delovanje vseh ostalih. Za primer poglejmo, kako lahko sistem s prej opisanimi
lastnostmi pomaga pri reševanju problemov, ki se zgodijo na nivoju ene interesne skupine
in se potem vlečejo skozi delo vseh ostalih.
Denimo, da letalo pristane na letališču in pri tem pilot ugotovi, da armatura za
prikazovanje višine in lege letala ne deluje pravilno. Ker gre za ţivljenjsko pomemben
sistem, mora biti teţava odpravljena pred naslednjim letom. Nepredvideno popravilo
vpliva neposredno na delo čistilnih in ostalih vzdrţevalnih ekip. Tudi potniki, ki so
namenjeni na to letalo, ţe čakajo v čakalnicah na letališču. Ker je parkirno mesto zasedeno,
se morajo tudi druga letala in potniki prerazporediti, kar spet vzame določen čas. Posledica
vseh teh sprememb so zamude in stroški, ki bodo vplivali na delovanje letališč še nekaj
dni.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 10
Vpeljava dogodkovno vodenega sistema ne bo preprečila takšnih dogodkov, ampak bo
omogočala reševanje posledic. V seznamu zahtev sistema smo omenili moţnost
sodelovanja med uporabniškimi interesnimi skupinami. Moţnost sodelovanja in
distribucija informacij po sistemu je ključnega pomena. V našem primeru bo naš sistem
skrbel, da bo ujel vse dogodke, ki bodo nastali v domenah interesnih skupin in jih dostavil
do vsake. Te bodo lahko s pomočjo obravnavanja »Kaj če« scenarijev in načrti odločanja,
začeli reševati problem z najkrajšim moţnim odzivnim časom. Rezultate njihovih
odločitev bo sistem spet dostavil do vsake interesne skupine. Tako bo imela vsaka skupina
pregled nad delom in posledicami drugih skupin. Primarni cilj našega dogodkovno
vodenega sistema je zmanjšanje časovnega zamika, ki nastane od pojava do rešitve
problema.
Iskanje podatkov o letihOcenitev stanja in možnosti
ukrepanjaPonudba/Razreševanje Prerazporeditev
Letalska družba
Deljenje podatkov leta
Ocenjevanje zamud in pregled
»Kaj če« scenarijev
Določanje akcijskega načrta
Ponudba/Razreševanje
Sprejem ponudbe
Ne
Potrditev/nov urnik
Da
Urad za nadzor
Deljenje podatkov leta
Ocenjevanje zamud in pregled
»Kaj če« scenarijev
Določanje akcijskega načrta
Ponudba/Razreševanje
Sprejem ponudbe
Ne
Potrditev/nov urnik
Da
LetališčeDeljenje
podatkov leta
Ocenjevanje zamud in pregled
»Kaj če« scenarijev
Določanje akcijskega načrta
Ponudba/Razreševanje
Sprejem ponudbe
Ne
Potrditev/nov urnik
Da
Podporne službe
Deljenje podatkov leta
Ocenjevanje zamud in pregled
»Kaj če« scenarijev
Določanje akcijskega načrta
Ponudba/Razreševanje
Sprejem ponudbe
Ne
Potrditev/nov urnik
Da
Zbiranje, procesiranje in distribucija
podatkov o letih
Sinhronizacija in ponovna distribucija podatkov o ponudbi rešitev in njihovem sprejemanju
Obnovitev podatkov in ponovitev
Slika 3: Prikaz sodelovanja uporabniških interesnih skupin v dogodkovno vodenem sistemu
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 11
Na nivoju delovanja storitvenih arhitektur v poslovnem okolju lahko naštejemo naslednje
značilnosti delovanja [3]:
Dogodkovno vodena arhitektura je šibko sklopljena.
Dogodkovno vodene arhitekture uporabljajo metode asinhronega komuniciranja,
običajno mehanizme, ki uporabljajo vzorec Objavi/Naroči (Publish/Subscribe).
Osnovna enota dogodkovno vodenih arhitektur je dogodek.
Dogodkovno vodene arhitekture vsebujejo iniciatorje oz. generatorje dogodkov in
prejemnike oz. odjemalce dogodkov. V idealnem primeru poteka komunikacija s
pomočjo SOAP protokola in spletnih storitev.
Dogodkovno vodene arhitekture uporabljajo splošno dostopne komunikacijske
sisteme, kot so storitvena vodila (ESB), adapterje in mediatorje, ki omogočajo
prenos sporočil.
Dogodkovne arhitekture niso odvisne od centralnih kontrolnikov.
V poslovnem informacijskem okolju dogodkovno vodene arhitekture [3]:
omogočajo agilnost pri operativnem upravljanju,
omogočajo vzpostavljanje povezav med podatki, ki jih lahko podjetje uporabi pri
analizi poslovanja, modeliranju poslovnih procesov ali upravljanju,
pomagajo podjetju pri realizaciji vzpostavitve sistema za analize poslovanja,
omogočajo dinamično vpeljavo poslovnih pravil, ki določajo odzivanje na določene
posamezne dogodke ali serije dogodkov,
lahko povečajo vpliv pojave določenega dogodka na podjetje.
2.2. Definicija dogodka
Osnovna enota dogodkovno vodenih arhitektur je dogodek. Dogodek je definiran kot
relevantna sprememba v okolju znotraj ali zunaj sistema [2].
Dogodek je zgrajen iz glave in telesa. Glava dogodka vsebuje podatke, kot so identifikator
dogodka, tip dogodka, ime dogodka, časovni ţig, zaporedna številka ponovitve dogodka in
podatki o iniciatorju dogodka [2].
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 12
Telo dogodka poda informacije o samem dogajanju. Če se naveţemo na prej omenjeni
primer ABS sistema v avtomobilih, bi v tem primeru telo dogodka lahko vsebovalo
informacijo o spremembi stanja iz premikanja v zastoj pogonske ročice in o predhodni
hitrosti avtomobila. Telo mora vsebovati čim bolj natančne podatke o dogajanju. To
omogoči poznejšim odjemalcem pravilen odziv.
Ţivljenjski cikel dogodka obsega štiri večje sklope:
Generator dogodka: kot pove ţe samo ime, gre za instanco, ki generira oziroma
ustvari dogodek. Vir dogodkov je lahko senzor, kakšna druga aplikacija, poslovni
proces ali kakšen pripomoček za komunikacijo, kot je elektronska pošta. Zaradi
velike mnoţice potencialnih virov dogodkov je potrebno poskrbeti za njihovo
transformacijo v enotno obliko pred prenosom [1].
Kanal prenosa dogodka: predstavlja pot za pošiljanje sporočil. Določa standardno
obliko dogodka, ki potuje od generatorja dogodka do procesne enote dogodkov [1].
Procesiranje dogodkov: prispele informacije soočijo s pravili procesiranja in
njihovimi posledicami. Ko dogodek prispe v enoto za procesiranje, se ovrednotijo
njegove informacije, shranjene v telesu. Lahko se izvede poznejše zdruţevanje
dogodkov ali njihovo filtriranje na podlagi vnaprej določenih pravil. Procesna enota
deluje neodvisno od generatorjev dogodka [1]. Dogajanje lahko primerjamo z
delovanjem televizijskih oddajnikov in televizijskih sprejemnikov. Oddajnik oddaja
na določeni frekvenci televizijski program. Mi kot odjemalec programa moramo
sprejemnik nastaviti na to frekvenco. Kaj pozneje s prejetim signalom naredimo, ni
več skrb oddajnika. Prav tako ni njegova skrb, koliko televizijskih sprejemnikov
prejema njegov signal.
Posledične aktivnosti dogodka: zgodijo se v situaciji, ko se pojavi dogodek,
zanimiv za določenega odjemalca, ki spremlja dogajanja. Tipov odjemalcev je
lahko več. Lahko je kakšna spletna storitev, ki spet sproţi nadaljnje dogajanje,
lahko je podatkovno skladišče, lahko je poslovni proces, ki čaka na signal za
prehod na naslednji korak, ali pa tudi človek [1].
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 13
2.3. Iniciatorji dogodkov
Proizvajalce dogodkov lahko najdemo kjerkoli, bodisi znotraj ali zunaj sistema podjetja.
Gre za strojno ali programsko opremo, katere naloga je spremljanje okolice in obveščanje
o določenem tipu dogodka, ki se je zgodil. Pomembna naloga producentov je
transformacija dogodka v dogovorjeno obliko. Obliko določa kanal prenosa, ki poskrbi za
to, da sporočilo prispe do procesne enote dogodkov. V fazi procesiranja se določi pomen in
na njegovi osnovi se proţijo naslednja dejanja. Prijavljeni odjemalci, med katere lahko sodi
tudi procesna enota, čakajo na določen tip dogodka, katerega lahko samo prepoznajo, če je
zapisan v njim poznani obliki. [3]
2.4. Odjemalci dogodkov
Glavna naloga odjemalcev je spremljanje točno določenih tipov dogodkov. Da to zmorejo,
morajo znati razumeti sporočila, ki prispejo do njih. Poslušalec mora biti sposoben
prepoznani dogodek pravilno interpretirati. To pomeni, da mora ovrednotiti relevantnost
dogodka na podlagi vrednosti parametrov, ki se nahajajo v glavi in telesu dogodka [3].
Odjemalec lahko prav tako vsebuje logiko, ki določa dogajanje po prejetju dogodka. Tako
omogočimo večjo fleksibilnost pri razširjanju določenega poslušalca, saj za dodajanje
novih funkcionalnost ni potrebno spreminjati obstoječe kode, ampak se napiše dodaten
poslušalec, ki čaka na isti dogodek in delo nadaljuje [4].
2.5. Procesor dogodkov
Procesor dogodkov je programska oprema, ki zna predvideti potencialni vpliv, vrednost in
posledice dogodka [3]. Kompleksnost delovanja procesorja dogodkov pa je odvisna od
načina procesiranja, ki ga uporabljamo. Če uporabljamo preprosto procesiranje dogodkov,
je dogajanje določeno po logiki, ki jo definirajo prijavljeni odjemalci dogodkov. V primeru
tokovnega in kompleksnega obravnavanja dogodkov pa je vloga dogodkovnega procesorja
veliko večja. Tukaj procesor obravnava celotne serije dogodkov, ki so se polnile čez daljše
časovno obdobje, ter poskuša na podlagi vnaprej določenih pravil sklepati na njihov pomen
in določiti posledične akcije.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 14
2.6. Sporočilna hrbtenica
Sporočilna hrbtenica predstavlja skupek programske in strojne opreme ter mreţnih
protokolov, ki skrbijo, da dogodkovno vodene aplikacije sploh delujejo. Hrbtenica ni
vezana na eno lokacijo, podjetje ali proizvajalca. Njena najpomembnejša lastnost je
agilnost. Načrtovana mora biti tako, da so programske in strojne komponente čim bolj
šibko sklopljene. Se pravi, če kakšen odjemalec ali producent dogodkov zataji, morajo
ostale komponente delovati normalno. Prav tako mora omogočiti preprosto širjenje in
moţnost integracije z drugimi starejšimi in novejšimi sistemi [3].
2.7. Komponente implementacije dogodkovno vodenih arhitektur
Z vidika implementacije dogodkovno vodenih arhitektur ločimo naslednje komponente:
Metapodatki dogodkov: resne dogodkovno vodene aplikacije in sistemi imajo
dobro definirano arhitekturo metapodatkov. Vsebujejo specifikacije dogodka in
njihova procesna pravila. Specifikacije dogodka morajo biti na razpolago
generatorjem, oblikovnim transformatorjem, procesnim enotam in odjemalcem
dogodkov. Trenutno še ne obstaja enoten standard, ki bi točno določal strukturo in
obvezne podatke, s katerimi bi opisali dogodek.
Procesna enota dogodkov: njena naloga je procesiranje preprostih in kompleksnih
dogodkov. Med tem, ko enote za enostavno procesiranje dogodkov v večini
primerov implementiramo sami, se pri kompleksnem procesiranju odločimo za
uporabo kakšnega produkta na trgu (IBM, Aptsoft, KnowHow, Progress Software,
StreamBase in Tibco), ki ga integriramo v sistem.
Orodja za delo z dogodki: razvojna orodja za definiranje dogodkov nam
pomagajo pri določanju specifikacij, procesnih pravil in pri upravljanju odjemalcev
za določen tip dogodkov.
Poslovna integracija: v namen integracije uporabimo poslovno integracijsko
vodilo, ki mora imeti naslednje lastnosti:
o podpirati mora predprocesne operacije, kot so filtriranje, usmerjevanje in
transformacije
o vsebovati prenosni kanal dogodkov
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 15
o omogočati mora proženje storitev
o omogočati proženje poslovnih procesov
o podpirati mora komunikacijski vzorec Objavi/Naroči
o omogočati mora dostop do podatkov poslovanja
Viri: gre za vire dogodkov, kot so, aplikacije, storitve, poslovni procesi,
podatkovna skladišča, relacijske baze, avtomatizirani agenti in ljudje
Orodja za delo z dogodki
Orodja za upravljanje dogodkov
Procesna pravila dogodkov
Specifikacije dogodkov
Podatki dogodka
Proženje storitev Prenos dogodkovPredpomnilnik
poslovnih podatkov
Procesna enota dogodkov
Poslovno integracijsko vodilo
Podatkovna skladiščaPodatkovna skladišča StoritveStoritve
Dogodki
Upravni portaliUpravni portaliPoslovne aplikacijePoslovne aplikacije
Slika 4: Komponente implementacije dogodkovno vodenih sistemov [1]
2.8. Procesiranje dogodkov
Poznamo tri glavne tipe procesiranja dogodkov, in sicer preprostega, tokovnega in
kompleksnega. V zrelih sistemih, ki so koncipirani po dogodkovno vodenih načelih,
najdemo uporabo vseh treh pristopov, saj lahko z njimi pokrijemo večino zahtev.
2.8.1. Preprosto procesiranje dogodkov
V obravnavanju preprostega procesiranja dogodkov je naša pozornost usmerjena v
relevantne oziroma pričakovane dogodke. Ko je dogodek zaznan s strani prijavljenega
odjemalca, ta glede na podatke iz telesa dogodka sproţi določene posledične akcije. Tak
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 16
način procesiranja se uporablja predvsem pri spremljanju dogajanja v realnem času. S tem
zmanjšamo odzivni čas na spremembe [1].
Za primer vzemimo skladišče v podjetju, ki proizvaja avtomobile. Tovarne imajo strog
načrt proizvodnje in na njegovi podlagi morajo biti tudi načrtovane minimalne količine
zalog delov, ki so potrebni za izgradnjo avtomobila.
Naš generator dogodkov naj bo pametna naprava, opremljena s senzorjem, ki nadzira
količino razpoloţljivih izpušnih sistemov za določen model avtomobila. Prav tako je
povezan v lokalno omreţje podjetja, kar mu omogoča sporočanje sprememb enoti za
procesiranje dogodkov. Ko naprava zazna pomanjkanje, generira dogodek in ga preko
kanala za prenos pošlje do procesne enote dogodkov. V procesni enoti imamo definirana
pravila, ki določijo posledično dogajanje. Tako lahko s pravilom neposredno določimo klic
storitve ali začetek delovnega toka. Prav tako pa lahko objavimo dogodek prijavljenim
odjemalcem. Za naš primer predpostavimo, da ob pojavitvi dogodka o pomanjkanju
izpušnih naprav tega objavimo potencialnim odjemalcem. Naš odjemalec spremlja
dogajanje in ob pojavitvi dogodka naredi zapis v podatkovno bazo CRM (Customer
Relationship Management) sistema in preko elektronske pošte obvesti vodjo skladišča.
GENERATOR
DOGODKOV
KANAL PRENOSA
DOGODKOV
PROCESIRANJE
DOGODKOV
POSLEDIČNE AKCIJE
Izvor dogodka:
Senzor zazna nizko
stanje zaloge
izpušnih cevi
Prenos dogodka:
Dogodek se prinese preko
prenosnega kanala, ki
zahteva določeno obliko,
do procesne enote
Procesiranje dogodka:
Dogodek prispe v
procesno enoto, kjer se
ovrednotijo njegovi atributi
Pravila procesiranja:
Specificiramo pravila
procesiranja, ki določajo
dogajanje neposredno po
ovrednotenju in
procesiranju dogodka
...
Objava dogodka
Proženje spletne storitve
Proženje poslovnega
procesa
...
Prijavljeni odjemalci
dogodkov
Odjemalec 1
...
Odjemalec N
Posledične akcije
Kreiranje opravila v
CRM sistemu
Zapis v podatkovno
skladišče
...
Slika 5: Shematičen prikaz primera procesiranja preprostih dogodkov
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 17
2.8.2. Tokovno procesiranje dogodkov
Pri tokovnem procesiranju dogodkov imamo opraviti z relevantnimi in preprostimi
dogodki. Ključna razlika med relevantnimi in preprostimi dogodki je njihov pomen za
uporabnika. Medtem ko relevantni dogodki ţe ob eni sami pojavitvi zahtevajo ukrepanje,
je pri preprostih potrebno spremljati njihov tok. Cilj procesiranja toka dogodkov je
ugotoviti obstoj relevantne strukture znotraj sekvence več preprostih dogodkov. Prav tako
lahko opazujemo čas, prostor ali druge lastnosti, ki pomagajo pri določanju pomena. Če
najdemo relevanten dogodek, tega posredujemo do odjemalcev, ki nato sproţijo določene
posledične akcije. Vir toka preprostih dogodkov so po navadi naprave, kot so RFID čitalci,
čitalci črtnih kod, SCADA (Supervisory Control And Data Acquisition) ipd. [1]
Za primer tokrat vzemimo prodajalca elektronike. V njegovem skladišču je vsak izdelek
opremljen z RFID čipom. Lastnik ţeli biti obveščen samo o dogodku, ko skladišče zapusti
izdelek, ki ga uvršča v višji cenovni rang. Tako bo generator vseboval še filter, ki mu bo
omogočil, da do procesne enote ne pošilja vseh dogodkov, ampak le tiste, pri katerih je bila
cena prodanega izdelka višja od 4000 €. Ko dogodek prispe v procesno enoto, je obnašanje
spet pogojeno s pravili, ki zadevajo tak tip dogodka. V našem primeru ga bomo samo
objavili potencialnim odjemalcem, ki bodo dogodek zabeleţili v podatkovno bazo.
Ker pa prodajalec elektronike prodaja izdelke tudi preko interneta, ima interes spremljati
prodajo in nagrajevati najboljše in zveste kupce. Vsako naročilo izdelka preko spletne
strani generira preprost dogodek, ki se posreduje do procesne enote. Od tam se objavi
naprej do odjemalca, ki poskrbi za to, da se podatki o naročilu zapišejo v podatkovno
skladišče. Za iskanje »dobrega« naročila, ki po mnenju prodajalca znaša več kot 1500 $,
skrbi implementirano procesno pravilo, ki spremlja prejete preproste dogodke in generira
relevanten dogodek v primeru, če naročila določene stranke preseţejo 1500 $. Takrat
procesna enota sproţi spletno storitev, ki na primer kreira opravilo v CRM sistemu podjetja
[1].
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 18
GENERATOR
DOGODKOV
KANAL PRENOSA
DOGODKOV
PROCESIRANJE
DOGODKOV
POSLEDIČNE AKCIJE
Izvor dogodka:
RFID senzor
prepozna premik
artikla iz skladišča
Prenos dogodka:
Dogodek se prinese preko
prenosnega kanala, ki
zahteva določeno obliko,
do procesne enote
Procesiranje dogodka:
Dogodek prispe v
procesno enoto, kjer se
ovrednotijo njegovi atributi
...
Objava dogodka
Proženje spletne storitve
Proženje poslovnega
procesa
...
Prijavljeni odjemalci
dogodkov
Odjemalec 1
...
Odjemalec N
Posledične akcije
Kreiranje opravila v
CRM sistemu
Zapis v podatkovno
skladišče
...
Lokalni filter izloči
dogodke, kjer ne gre
za izdelek višjega
ranga
Izvor dogodka:
Dodan nov artikel v
spletni voziček
V pravilih procesiranja
lahko vključimo iskalnik
sekvenc, ki bo v našem
primerov iskal nakup nad
1500€
Pravile procesiranja:
Specificiramo pravila
procesiranja, ki določajo
dogajanje neposredno po
ovrednotenju in
procesiranju dogodka
Slika 6: Shematičen prikaz primera tokovnega procesiranja dogodkov
2.8.3. Kompleksno procesiranje dogodkov
Podobno kot pri tokovnem procesiranju tudi pri kompleksnem spremljamo tako relevantne
kot preproste dogodke. Razlika se pojavi pri velikosti časovnih intervalov, v katerih se
dogodki pojavijo. Pri tokovnem procesiranju je cilj podpreti kratkoročno poslovno
odločanje. Pri kompleksnem procesiranju pa se lahko pojavijo v daljših časovnih
intervalih. Prav tako so zaporedja in vzorci toka dogodkov veliko bolj kompleksni in
zahtevajo zapletene metode za razpoznavanje. Korelacija med dogodki je lahko vzročna,
časovna ali prostorska. Kompleksno procesiranje dogodkov se v večini primerov uporablja
za razpoznavanje anomalij, groţenj ali nepravilnosti v poslovanju. [1]
V zadnjih petdesetih letih razvoja so nastale štiri glavne tehnologije, ki so vplivale na
razvoj procesiranja dogodkov [5]:
diskretne simulacije dogodkov
računalniška omrežja
podatkovne baze
povezovalne tehnologije
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 19
Diskretno simuliranje dogodkov 1987: VHDL
1985: Verilog
1977: ISP In drugi jeziki za opisovanje strojne opreme ( HDLs )
1960: GPSS, Simscript , Simula67, ......
Razvoj mrežnih tehnologij
1990 HP OpenView, CA-
Unicenter , IBM Tivoli, 1991 Internet 1976: Ethernet, ......, 2000:
10gb Ethernet
1969: DARPA Net
Povezovalne tehnologije / SOA
1992MQ,......, ESB,... SOA .....
1985 Pub/Sub, 1990 MOM, ORBs
Aktivne podatkovne baze
1992 DSM systems, Tapestry1986 InterBase , ...
1960 1970 1980 1990 2000
Slika 7: Prikaz razvoja dogodkovno procesnih tehnologij skozi zadnjih 50 let
Diskretne simulacije dogodkov
Dogodkovno procesiranje se je začelo s simulacijo diskretnih dogodkov v 50. letih
prejšnjega stoletja. Osnovna ideja je bila, da bi se sistemi, kot so kontrolniki, letalski
sistemi, proizvodnja v tovarnah ali kakšen naravni pojav (vreme), modelirali s pomočjo
računalniškega programa, napisanega s pomočjo simulacijskega programskega jezika. Na
podlagi vhodnih podatkov bi sistem kreiral določene dogodke, katerih sled bi na koncu
omogočila spremljanje in analiziranje delovanja modela.
Vsak dogodek bi se zgodil ob točno časovno določenem trenutku, ki ga določa takt
sistemske ure. Tako lahko opazujemo dogajanje v realnem času. Takšni modeli so se
imenovali diskretne simulacije dogodkov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 20
Sporočila, ki so predstavljala dogodke, so imela pribliţno naslednjo obliko: »Komponenta
C1 me je ustvarila ob času T1 s podatki A in B ter me poslala do komponent C2 in C3«.
Naloge simulatorja so bile usmerjanje toka dogodkov, proţenje funkcionalnosti komponent
in proţenja takta ure. Razporejevalnik je takrat bil sestavljen iz vrste čakajočih dogodkov,
ki so bili razporejeni na podlagi časa njihovega pojava. Preden se je funkcionalnost
komponente izvedla, je na njen vhod dobila dogodke, ki so bili za njo pripravljeni v
čakalni vrsti. V izvajanju je spet generirala nove dogodke, ki so spet sluţili kot vhodni
podatki kateri od drugih komponent v sistemu. Vsak generiran ali sprejet dogodek se je
zabeleţil v sistemu. Tako je bilo mogoče iz sledi, ki se je zgradila skozi delovanje sistema,
sklepati na pravilnost in kakovost delovanja modela sistema.
Sistemi v tistem času so ţe imeli ključne lastnosti današnji dogodkovno vodenih arhitektur.
V središču pozornosti je bila implementacija simulatorja, razporejanja opravil in
učinkovitosti distribuiranja dogodkov. Simulatorji so postali še kompleksnejši, ko se je
izvajanje simulacije preneslo na več računalnikov hkrati.
Kar je iz tistega časa zanimivo za današnje moderne implementacije, je koncept sledi. Sled
nam daje točen pregled nad delovanjem modela. V 90. letih prejšnjega stoletja so začeli
raziskovati avtomatizirano analizo dogodkovnih sledi. Rezultat raziskav so bili veliko bolj
natančni in koristni sklepi o samem delovanju modela, kot je vzročnost med dogodki. Cilj
raziskav je bil oblikovati čim bolj natančen model določenega problemskega področja,
katerega izvajanje nam bo podalo natančne in zanesljive podatke o delovanju v realnem
okolju. [5]
Računalniška omrežja
Druga zvrst procesiranja dogodkov je povezana z razvojem računalniških omreţij z začetki
v poznih 60. letih prejšnjega stoletja (ARPA Net). Cilj je bil razviti učinkovit in zanesljiv
sistem za komunikacijo med računalniki skozi omreţje s pomočjo dogodkov, ki so
vsebovali sekvence binarnih podatkov, imenovane pakete. Pošiljanje oz. sprejemanje je
predstavljalo dogodek.
Ena izmed prioritet pri razvoju komunikacij preko računalniškega omreţja je bil razvoj
protokola, ki bo omogočil zanesljivo komunikacijo v omreţju, ki samo po sebi ni 100-
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 21
odstotno stabilno in dopušča pojavitev napak. Skozi proces razvoja se je izkazalo
definiranje standardnih mreţnih protokolov s pomočjo koncepta slojev dogodkov oz.
razslojevanja dogodkov. Dva primera takšnih protokol sta TCP/IP in ISO-7 sloj.
Definicija slojev dogodkov je uporabljala koncept imenovan abstrakcija dogodkov. Če
ţelita preko protokola TCP/IP dva računalnika med seboj komunicirati, lahko na ta
problem gledamo z vidika aplikacij, ki tečeta na teh računalnikih in si ţelita med seboj
izmenjevati podatke. Tako dobimo pogled »aplikacija-do-aplikacije«. Vse ostale
podrobnosti pri prenosu sporočila nas pri abstrakciji ne zanimajo.
Tako sloj TCP/IP kot sloj OSI-7 sloj oba definirata sloj dogodkov od visokonivojskih
(aplikacijskih) do nizkonivojskih (elektronskih). Definicija vsakega sloja predstavlja nabor
dogodkov in moţne operacije nad njimi. Deljenje dogodkov v sloje je bilo pomembno za
poznejši razvoj kompleksnega procesiranja dogodkov, ki je na podlagi tega koncepta
razvilo hierarhije dogodkov.
Dogodek:
Elektronska pošta
Za:
username@domain
Čas: 19:38:33
30.5.2009
...
Aplikacija za
pošiljanje in
sprejemanje
elektronske pošte
Aplikacija za
pošiljanje in
sprejemanje
elektronske pošte
Slika 8: Primer abstrakcije dogodkov, kjer prikažemo pogled »aplikacija-do-aplikacije«
Z iznajdbo računalniških omreţij so se na trgu pojavila tudi orodja za nadzorovanje in
upravljanje omreţij, katerih naloga je bila spremljanje sledi dogodkov v omreţju in njihova
grafična vizualizacija. Ta orodja so bili predniki aplikacij, ki jih danes poznamo pod
imenom BAM (Business Actitvity Monitoring). [5]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 22
Aktivne podatkovne baze
Aktivne podatkovne baze so se začele razvijati v 80. letih prejšnjega stoletja. Bile so
rezultat večjega povpraševanja po procesiranju dogodkov in pregleda nad poslovanjem v
realnem času. Tradicionalne podatkovne baze so bile razširjene s funkcionalnostmi, ki so
jim omogočile procesiranje dogodkov in proţenje posledičnih reakcij.
Tako je lahko podatkovna baza, ki je vsebovala podatke o zalogah v skladišču, v primeru
pomanjkanja samodejno generirala obvestilo. Da je to bilo mogoče realizirati, so
tradicionalne podatkovne baze dobile dodaten sloj, namenjen procesiranju dogodkov. Ta
sloj je s pomočjo pravil ECA (Event-Condition-Action) omogočal ustvariti proţilce, ki so
lahko prepoznavali in odreagirali bodisi na posamezne dogodke ali, s pomočjo analize
sekvenc, na kompleksnejše tipe dogodkov.
Klasična podatkovna baza
Podatkovna
baza 1
Podatkovna
baza 1
Podatkovna
baza N...
Dodaten sloj za procesirane dogodkov
Prožilci Pravila procesiranja ...
Slika 9: Shematičen prikaz aktivnih podatkovnih baze
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 23
Aktivne podatkovne baze predstavljajo tako osnovo za nekatere aplikacije v realnem času,
kot so izvajanje delovnega toka, premik podatkov iz omreţnih na mobilne naprave ter za
mnoţico orodij za analizo in upravljanje poslovanja podjetja. Ena izmed posledic aktivnih
podatkovnih baz in pripadajočega načina procesiranja je tokovni način procesiranja
dogodkov, ki smo ga opisali v poglavju 2.8.2 in predstavlja podmnoţico metodam
kompleksnega procesiranj dogodkov. [5]
Povezovalne tehnologije
Podjetje Teknekro, ustanovljeno 1985 in danes imenovano Tibco, je bilo prvo, ki je začelo
izdelovati povezovalne tehnologije. Ena izmed prvih razvitih tehnologij na tem področju
se je pojavila v 70. letih prejšnjega stoletja. Gre za RPC (Remote Procedure Call). Prvi
komercialni izdelki iz tega segmenta so se pojavili pozneje v 80. letih. Prva zvrst te
tehnologije se je imenovala ORD (Object Request Broker). Pozneje je izšla rešitev, ki je
temeljila na sporočilno usmerjeni povezovalni tehnologiji, t. i. MOM (Message Oriented
Meddleware). Medtem ko so ORB-ji temeljili na RPC konceptu je MOM baziral na
komunikaciji s sporočili oz. dogodki. Uporabljali so vrste dogodkov in vzorec
Objavi/Naroči.
Dandanes je pojem povezovalnih tehnologij pogosto sinonim za vzorec storitvenega vodila
(ESB - Enterprise Service Bus) oz. storitvenega vodila. Storitveno vodilo predstavlja
orodje za visokonivojski način komunikacije »aplikacija-do-aplikacije«. Podrobnejši opis
storitvenega vodila najdemo v poglavju 3.5.
Sodobna komercialna storitvena vodila ţe sama po sebi ponujajo podporo za procesiranje
dogodkov oz. za splošno podporo dogodkovno usmerjenim arhitekturam. Vsebujejo
infrastrukturo za pošiljanje sporočil oz. dogodkov (XML, SOAP, spletne storitve) ter
procesno enoto. Pri storitvenih vodilih gre za tipičen primer realizacije dogodkovno
vodenih sistemov s pomočjo SOA. [5]
Kompleksno procesiranje dogodkov je mogoče lepo razloţiti na primeru spremljanja
uporabe plačilnega prometa kreditnih kartic. Recimo, da oseba Janez Novak redno
uporablja svojo kreditno kartico za plačevanje nakupov v tradicionalnih in spletnih
trgovinah. Njegov mesečni limit znaša 1000 €. Vsako plačilo s kreditno kartico predstavlja
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 24
dogodek, ki je zanimiv za ponudnika kreditne kartice. Ko Janez Novak opravi nakup s
svojo kreditno kartico, se podatki prenesejo v sistem ponudnika. Ta dogodek se prenese do
procesne enote, kjer se vodi evidenca plačil tega meseca za uporabnika Janeza Novaka.
Vrsta plačil ni nič drugega kot neka vrsta dogodkov, iz katere procesna enota s pomočjo
definiranih pravil skuša ugotoviti, ali je limit ţe preseţen. Tak dogodek plačila mora
vsebovati podatke, kot so identifikacijska številka uporabnika kreditne kartice, znesek
plačila, čas in kraj plačila ter podatki o prejemniku plačila. Prav tako ti podatki lahko
pomagajo pri odkrivanju zlorabe kartice. Nekega dne Janezu Novaku naključno prestreţejo
številko kreditne kartice, saj je plačeval nakupe preko spleta, medtem ko je bil s svojim
prenosnim računalnikom povezan na nešifrirano brezţično povezavo. Ropar sedaj poskuša
z ukradenimi podatki opraviti nakup preko spleta. Istočasno plačuje svoje nakupe Janez
Novak, ki ne ve, da so mu bili podatki kreditne kartice ukradeni. Sistem ponudnika oz.
procesna enota dogodkov ponudnika lahko sedaj preko razpoznavanja dogodkov spozna
sum kaznivega dejanja, saj so bila plačila izvedena v zelo kratkem časovnem obdobju na
dveh geografsko različnih mestih, in sproţi potrebne posledične akcije, kot so blokiranje
kartice ali obveščanje uporabnika.
GENERATOR
DOGODKOV
KANAL PRENOSA
DOGODKOV
PROCESIRANJE
DOGODKOV
POSLEDIČNE AKCIJE
Izvor dogodka:
Janez Novak ko
opravi plačilo s svojo
kreditno kartico
Prenos dogodka:
Dogodek se prenese preko
prenosnega kanala.
Vsebovani so podatki:
- Indetifikacijska številka
uporabnika
- čas in kraj plačil
- prejemik plačila
- znesel plačila
Procesiranje dogodka:
Dogodek prispe v
procesno enoto, kjer se
ovrednotijo njegovi atributi
...
Objava dogodka
Proženje spletne storitve
Proženje poslovnega
procesa
...
Prijavljeni odjemalci
dogodkov
Odjemalec 1
...
Odjemalec N
Posledične akcije
Blokiranje kartice
Zapis v podatkovno
skladišče
...
Izvor dogodka:
Nepooblaščena oseba
opravi plačilo s
ukradenimi podatki
Kompleksni algoritmi so
zadolženi za
prepoznavanje vzorce
Pravila procesiranja:
Pravila določajo kdaj je
presežen mesečni limit in
kdaj se pojavijo sumljiva
dogajanja v plačilnem
prometu
Prepoznana zloraba kartice
Slika 10: Shematičen prikaz kompleksnega procesiranja dogodkov
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 25
3. POVEZAVA MED STORITVENO ORIENTIRANIMI IN
DOGODKOVNO VODENIMI ARHITEKTURAMI
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 26
Storitveno orientirane arhitekture zdruţujejo tehnologije in koncepte za grajenje aplikacij,
sestavljenih iz šibko sklopljenih storitvenih komponent. Šibka sklopljenost se kaţe v tem,
da komponente ne vedo za obstoj in delovanje drugih komponent v sistemu. Komponente
so lahko programski ali strojni konstrukti. Prednost storitveno usmerjenega razvoja je
predvsem v niţanju stroškov. Podjetje lahko razvije določeno storitev in jo uporabi v
aplikaciji, ki jo potrebuje. Če še katera druga aplikacija potrebuje podobno funkcionalnost,
lahko uporabi obstoječo rešitev. Vse spremembe uporabljene storitve v prihodnosti bodo
veljale za vse aplikacije, ki jo uporabljajo.
Za boljšo razlago poglejmo praktičen primer. Predstavljajmo si podjetje, ki ima med
drugimi tudi kadrovski oddelek in oddelek za osebne dohodke. Kadrovski oddelek
uporablja intranet aplikacijo, s katero urejajo podatke o zaposlenih. Njihova aplikacija se
posluţuje različnih storitev, ki jim omogočajo dostop do podatkov v podatkovni bazi ali
prepoznati uporabnika pri prijavi v sistem. Oddelek za osebne dohodke je zadolţen za
preračunavanje in izplačevanje plač zaposlenih. Skupna točka obeh oddelkov je seznam
zaposlenih z njihovimi podatki. V tem primeru lahko oddelek za osebne dohodke koristi
storitev, ki dostopa do podatkovne baze in vrne seznam zaposlenih.
Oddelek za
osebne dohodke
Kadrovska služba
Aplikacija za
urejanje
osebnih
dohodkov
Aplikacija za
vodenje
kadrovske
službe
Podatkovna baza
podjetja
Nabor storitev
Vrni seznam
uporabnikov
…
Autentificiraj
uporabnika
Slika 11: Prikaz osnovnega principa delovanja storitveno orientiranih arhitektur
3.1. Spletne storitve
Spletne storitve predstavljajo enega izmed najbolj uporabljenih gradnikov storitvenih
arhitektur. Koncept delovanja spletnih storitev temelji na izmenjavi tako imenovanih
SOAP sporočil. Lokacija, kjer gostuje spletna storitev, po navadi ni enaka tisti, na kateri
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 27
uporabnik poganja odjemalca. Zato je pomembno, da poleg signature spletne storitve
poznamo še lokacijo oddaljenega streţnika in strukturo podatkov. Vse te informacije se
nahajajo v WSDL dokumentu. Ko odjemalec pošlje zahtevo za proţenje spletne storitve, se
ta izvede in se odzove z odgovorom v obliki SOAP sporočila. [3]
OdjemalecStrežnik, ki gosti
spletno storitev
Spletna
storitev
Zahteva po spletni
storitvi (SOAP sporočilo
preko HTTP protokola)
Odgovor spletne
storitve (SOAP sporočilo
preko HTTP protokola)
Slika 12: Shematičen prikaz osnovnega koncepta delovanja spletnih storitev
3.2. SOAP oblika sporočila
SOAP, Simple Object Access Protokol, predstavlja standardno obliko sporočila za
komuniciranje s spletnimi storitvami. [3]
Sporočila so sestavljena iz dveh delov:
Glava sporočila:
V glavi sporočila običajno najdemo podatke, ki so povezani z usmerjanjem
sporočila, varnostjo, ipd.
Jedro sporočila:
Jedro sporočila nosi dejanske podatke, ki jih ţeli dobiti odjemalec.
3.3. WSDL dokument
Uporaba spletnih storitev zahteva določeno znanje o storitvi. Vedeti moramo, kje se
storitev nahaja, kakšna je struktura podatkov, ki jih vsebuje telo SOAP sporočila, kakšne
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 28
parametre zahteva spletna storitev ipd. Vse te podatke vsebuje WSDL dokument. Osnovni
gradniki WSDL dokumenta so naslednji [3]:
Tipi podatkov (types): povedo, kateri podatkovni tipi so na voljo
Sporočila in operacije (messages and operations): povedo, katere metode so na
voljo
Tipi vrat (port types): opisujejo skupine razpoloţljivih metod
Vezava (binding): specifikacije za dostop do skupin metod
Vrata (port): lokacija, kjer je storitev na voljo
3.4. UDDI register
Universal Description, Discovery and Integration je na XML temelječi standard za register
spletnih storitev. Omogoča iskanje primernih spletnih storitev s pomočjo metapodatkov.
Sprva je bil UDDI koncipiran kot globalni seznam spletnih storitev, kamor bodo avtorji
objavljali razvite rešitve. Potencialna stranka bi tako lahko preko UDDI registra našla za
sebe primerno rešitev in pripadajoč WSDL, ki bi posredoval potrebne informacije za
uporabo. Zapletlo pa se je na področju licenc in plačevanja uporabe spletnih storitev. Leta
2005 so se podjetja, kot so Microsoft, IBM in SAP, ki so ponujala največje UDDI registre,
odločila, da zaprejo svoje registre za javnost. Danes najdemo uporabo UDDI registrov
znotraj podjetij, ki ţelijo dinamično povezovati odjemalce z razvitimi storitvami. [6]
3.5. Storitveno vodilo (ESB – Enterprise Service Bus)
Storitveno vodilo zdruţuje dogodkovno vodene in storitveno usmerjene pristope,
enostavno integracijo poslovnih enot in premagovanje ovir pri zdruţevanju heterogenih
platform in okolij. [7] Storitveno vodilo ima vlogo mediatorja, ki poskrbi za varno in
zanesljivo komunikacijo med procesi. V primeru dogodkovno vodenih arhitektur so ti
procesi poslušalci in generatorji dogodkov ter procesna enota dogodkov. Storitveno je tako
centralno vodilo, po katerem poteka objavljanje, sprejemanje in procesiranje dogodkov.
Podpira sinhrono in asinhrono komunikacijo med procesi, ki komunicirajo ena-ena (en
proces komunicira hkrati samo z enim procesom) ali mnogo-mnogo (mnogo procesov
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 29
komunicira hkrati z mnogo drugimi). Storitveno vodilo tako ustreza zahtevam storitvenih
in tudi dogodkovnih arhitektur.
Tabela 1: Osnovne karakteristike SOA [7]
Zahteva Opis
Šibko sklopljene interakcije Storitve se lahko proţijo neodvisno od njihove
lokacije.
Komunikacija ena proti ena Ena določena storitev je lahko sproţena s strani
enega odjemalca v določenem časovnem
trenutku. Komunikacija med njima je
obojestranska.
Proženje na željo odjemalca Odjemalec začne komunikacijo s storitvijo.
Sinhrono način delovanja Odzivi so poslani do odjemalca preteţno
sinhrono.
Tabela 2: Osnovne karakteristike EDA [7]
Zahteva Opis
Ločena interakcija Producent dogodkov ne ve za morebitne
poslušalce.
Komunikacija mnogo proti mnogo Sporočanje Objavi/Naroči, kjer ima lahko
specifični dogodek vpliv na več poslušalcev.
Proženje na dogodek Dogajanje je odvisno od prejemnikov dogodka,
ki se nanj odzovejo glede na njegov tip.
Asinhrono način komunikacije Podpira asinhrone operacije s pomočjo sporočil.
3.5.1. Storitve storitvenih vodil
Za implementacijo storitvenega vodila ne obstajajo določeni standardi. Splošno je sprejeto,
da bi naj ponujal naslednje storitve [7]:
Prenos sporočil: Storitveno vodilo mora zagotoviti dostavljanje sporočil. Sporočila
lahko vsebujejo določene informacije o enem ali več prejemnikih, katere mora biti
sposoben zajemati in na njihovi podlagi tudi dostaviti sporočila. V varnostno
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 30
kritičnih sistemih je storitev prenosa podprta s transakcijami, šifriranimi kanali
komunikacije in spremljanjem dogajanja.
Obravnavanje dogodkov: Storitev obravnavanja mora zagotoviti funkcionalnosti
za odkrivanje dogodkov, njihovo proţenje in distribucijo. Ta storitev je v povezavi
s procesiranjem dogodkov, kjer je potrebno opazovati mnoţice dogodkov in na
podlagi analiz proţiti posledične akcije.
Mediacija: Mediacija ima dva različna razloga za obstoj. Prvi je zagotavljanje
komunikacije med procesoma, ki zahtevata komunikacijo preko različnih
nekompatibilnih protokolov. Naloga storitvenega vodila je v tem primeru
transformacija sporočil med komuniciranjem v formate, ki jih procesa razumeta.
Druga pomembna naloga je transformacija podatkov v samem sporočilu. Pri tem
lahko dodamo ali odstranimo nekatere podatke. Cilj spreminjanja vsebine je
razumevanje sporočil s strani vseh prisotnih procesov.
ESB
Storitev
A
Storitev
B
Komunikacija
poteka med
storitvijo A in b
Protokol A
Protokol B
ESB obvlada
komuniciranja
preko protokola A
kot preko
protokola B. V tem
primeru je v vlogi
posrednika med
storitvijo A in B
Slika 13: Prikaz vloge storitvenega vodila pri komunikaciji dveh storitev preko različnih protokolov [7]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 31
ESB
Storitev
B
Storitev
A
Objekt A
Podatek 1
Podatkek 4
Podatek 3
Podatek 2
Objekt B
Podatek 1
Podatek 2
Storitvi A in B
komunicirata z
objekti z različno
strukturo in
vsebino. ESB
poskrbi za
pretvarjanje v
prejemniku prijazno
obliko
Slika 14: Prikaz spreminjanja vsebine sporočil s strani storitvenega vodila
3.6. Prednosti uporabe storitvenega vodila
Prednosti uporabe storitvenega vodila pri implementaciji dogodkovno vodenih
arhitektur so [7]:
Standardna povezljivost: storitveno vodilo ima v dogodkovno vodenih
arhitekturah vlogo komunikacijske hrbtenice, ki smo jo v poglavju 2.6
omenjali kot eno glavnih sestavnih delov. Storitveno vodilo mora tako
ponujati več različnih tehnik integracije heterogenih platform in veliko
izbiro standardnih tehnologij.
Prodorna integracija: Jedro ideje storitvenega vodila je enostavna
integracija različnih okolij. Z njegovo uporabo je mogoče med seboj
povezovati npr. oddelke znotraj podjetja, poslovne partnerje, druga
storitvena vodila, ki jim ni potrebno temeljiti na enaki programski
platformi. V dogodkovno vodenih sistemih je ta lastnost ključnega pomena,
saj so lahko tako producenti kot poslušalci dogodkov grajeni na različnih
programskih ogrodjih kot storitveno vodilo ali procesorja dogodkov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 32
Ugodna integracija: Storitveno vodilo izboljšuje varnost, skalabilnost in
dostopnost. Podpira tako sinhron kot tudi asinhron način dela s sporočili.
Storitev prenosa zagotavlja zanesljivost in integriteto podatkov.
3.7. Šibka sklopljenost
Dogodkovno vodene arhitekture delujejo najbolje, če med njimi obstaja le visokonivojska
povezava. Tem bolj se izogibamo tesnim povezavam med komponentami, tem večja bo
agilnost sistemov. V idealnem primeru komponente dogodkovno usmerjenih arhitektur, kot
so producenti in poslušalci dogodkov, ne vedo za obstoj drugega in delovanje drugih
komponent. [3] SOA z uvajanjem koncepta spletnih storitev in komuniciranja s sporočili
ponuja primerno ogrodje za grajenje dogodkovno vodenih rešitev.
Magična beseda pri šibki sklopljenosti oziroma pri omogočanju le-te je XML. XML
predstavlja format zapisa podatkov, ki je bil sprejet s strani glavnih proizvajalcev SOA
programskih paketov. Med te proizvajalce sodijo IBM, Microsoft in SAP.
3.8. Uporaba storitveno orientiranega pristopa pri dogodkovno vodenih
arhitekturah
V prejšnjih poglavjih smo predstavili različne komponente, ki jih prinaša storitveno
orientirana arhitektura. V nadaljevanju pa poglejmo, kako z njimi rešujemo zahteve
dogodkovno vodenih arhitektur:
Spletne storitve in SOAP: Generatorji in odjemalci morajo znati med seboj
komunicirati. Spletne storitve v povezavi s SOAP, ki temelji na XML in s tem
omogoča komuniciranje med komponentami iz heterogenih programskih okolij,
tako predstavljajo elegantno in učinkovito rešitev, ki omogoča objavo in sprejem
dogodkov.
UDDI: UDDI register odigra pomembno vlogo pri doseganju šibke sklopljenosti
sistema. Generator, poslušalec ali katera druga komponenta dogodkovno vodenega
sistema bi tako lahko preko povpraševanj našla v registru primerno storitev za
uporabo oz. ustrezen odziv na določen dogodek.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 33
Storitveno vodilo (ESB): Vloga storitvenega vodila v dogodkovno usmerjenih
arhitekturah je komunikacijska hrbtenica. Storitveno vodilo poskrbi, da je mogoče z
uporabo spletnih storitev dogodek objaviti in ga prinesti do prijavljenega
poslušalca. Pri tem poskrbi za potrebno mediacijo med protokoli ali transformacijo
podatkov, če je to potrebno.
3.9. Primerna razvojna ekipa za implementacijo dogodkovno vodenih sistemov s
pomočjo SOA
Sestavo ekipe so bomo pogledali z dveh vidikov. Prvi bo predstavljal idealne razmere, kjer
imamo dovolj izkušenega kadra in nas ne ovira kakšna obstoječa programska oprema
podjetja. Drugi pogled bo bolj povezan z razmerami pri realnih projektih, kjer nimamo na
voljo posebej specializirane in izkušene ekipe in kjer je potrebno upoštevati integracijo z
obstoječimi sistemi v podjetju.
3.9.1. Idealen primer
V idealnem primeru lahko začnemo graditi SOA del dogodkovno vodenega sistema od
zgoraj navzdol. Da to lahko doseţemo, moramo vzpostaviti ekipo arhitektov, ki bo
delovala na nivoju celotnega podjetja. Ekipo moramo sestaviti iz izkušenih in
usposobljenih sistemskih arhitektov, ki dobro poznajo potrebne tehnologije in področje,
katerega bo sistem pokrival. Velikost ekipe je odvisna od velikosti organizacije in
kompleksnosti nalog sistema. Tako lahko velikost variira med tremi in dvajsetimi člani. [3]
Odgovornosti ekipe so naslednje [3]:
Definiranje dolgoročne strategije razvoja SOA, ki so skladne s poslovnimi cilji
podjetja.
Določiti nekaj kratkoročnih poslovnih ciljev kot del SOA strategije.
Definiranje dobrih praks in smernic pri razvoju spletnih storitev, namestitvi,
upravljanju itn.
Posredovanje SOA strategije vodstvu podjetja, razvojnim in podpornim ekipam.
Prilagoditi trenutno okolje in metode razvoja na način, ki bo skladen z novimi SOA
smernicami.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 34
Vzpostaviti okolje sodelovanja, ki bo sluţilo pregledu implementacije storitev.
Določitev tehnologije, ki bo omogočala vodenje in objavljanje ţe razvitih spletnih
storitev.
Izračunati dobiček, ki ga novo ustvarjena arhitektura posledično prinese s seboj in
rezultate predstaviti vodstvu.
Slika 15: Prikaz korakov razvoja EDA + SOA v idealnih pogojih
3.9.2. Situacija v realnih projektih
V realnih projektih se velikokrat soočamo z omejitvami. Tako imamo na voljo omejen
proračun in kader, ki bi imel primerne izkušnje za razvoj dogodkovno vodenih sistemov s
pomočjo SOA. Prav tako sta omejena čas in denar. V tem primeru si lahko pomagamo z
naslednjimi štirimi koraki [3]:
1. korak: V tem koraku kreiramo projekt in določimo vodjo projekta, ki ima
pregled nad zahtevami SOA arhitekture in datumi dostave. Začnemo fazo 1
projekta.
SOA strategija
•Poslovni cilji vpeljave SOA
•Dobre prakse in smernice SOA
•Predstavitev SOA strategije vodstvu
•Prilagoditev trenutnega okolja
SOA okolje
•Vzpostavitev okolja za sodelovanje
•Določitev tehnologij
Povzetek prednosti in izračun dobička
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 35
2. korak: Formiramo razvojno ekipo. Če je ekipa razporejena še na druge projekte,
jo v tej fazi prosimo, da 20% časa posveti SOA. Če je mogoče jih za njihov trud
nagradimo. Če ni na razpolago kandidatov, ki bi to delo opravljali vzporedno s
svojim drugim delom, lahko znotraj podjetja poiščemo strateški projekt, na katerem
bi lahko raziskovali vprašanja povezana s SOA. Za to nalogo vzpostavimo manjšo
ekipo, ki ţe deluje znotraj projekta.
3. korak: Zdruţimo raziskave in ugotovitve naše skupine za raziskovanje SOA.
Rezultate predstavimo vodstvu, ki bo s tem imelo lepši pregled nad delom in
potencialom projekta.
4. korak: Začenjamo 2. fazo projekta, v kateri je naš cilj določiti dobre prakse pri
razvoju SOA rešitve. Načrtovalska ekipa mora začeti sodelovati z ekipami,
zadolţenimi za implementacijo. Pomembno je, da se izdelki kot so dobre prakse,
prvi prototipi in strategija, nahajajo v pregledni in dostopni obliki, tako da lahko
ima vodstvo podjetja vedno pregled nad dogajanjem, napredkom in morebitnimi
teţavami. Previdni moramo biti predvsem pri uporabi novih tehnologij na trgu, saj
lahko pri prehitri odločitvi spregledamo kakšen scenarij, ki ga z njimi ne zmoremo
pokriti. Čeprav novo orodje na prvi pogled ponuja nekatere prednosti in olajšanje
dela, je treba skrbno pregledati njegove moţnosti in jih primerjati z zahtevami
našega podjetja.
Slika 16: Prikaz korakov razvoja EDA + SOA v realnih pogojih
Korak 1• Kreiranje projekta in določitev vodje
Korak 2• Formiranje razovjno - raziskovalne ekipe
Korak 3• Združitev in predstavitev rezultatov raziskav
Korak 4• Določitev dobrih praks in načrtovanje implementacije
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 36
4. IMPLEMENTACIJA DOGODKOVNO VODENIH
ARHITEKTUR
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 37
V tem poglavju bomo raziskovali moţnosti in poti, ki jih imamo pri implementaciji
dogodkovno usmerjenih arhitektur (EDA) s pomočjo tehnologij in pristopov storitveno
usmerjenih arhitektur (SOA). Na povečano povpraševanje trga po spremljanju in
analiziranju relevantnih dogodkov, ki se dogajajo znotraj ali zunaj podjetja, so se odzvali
nekateri proizvajalci SOA platform in rešitev.
Pogledali si bomo ponujene rešitve podjetij IBM, Oracle, Microsoft in TIBCO. Da bi
dobili bolj globlji vpogled v delovanje komponent dogodkovnih arhitektur, bomo s
pomočjo odprtokodnih rešitev nSevericeBus (.NET okolje) in OpenESB v povezavi s
komponento za modeliranje procesiranja dogodkov razvili pilotski dogodkovno voden
sistem.
4.1. IBM rešitev
IBM Websphere Business Events je posebna namenska programska oprema za spremljanje
dogodkov oz. dogajanja v podjetju. Poslovne dogodke odkriva s pomočjo primerjave
definiranih poslovnih ciljev in pričakovanj ter dejanskega stanja. Če pride do odstopanj od
načrta v pozitivnem ali negativnem smislu ima sistem moţnost, da samodejno odreagira s
predvidenimi ukrepi ali pa zgolj obvesti pristojnega sodelavca v podjetju. [8]
Ključne lastnosti produkta [8]:
Omogočena definicija logike sodelovanja med dogodki.
Prepoznavanje določenih posameznih dogodkov in kompleksnejših vzorcev.
Rešitev vsebuje vizualna orodja za modeliranje procesiranja dogodkov.
Omogoča vizualizacijo ţelenega oz. planiranega stanja v podjetju v primerjavi z
dejanskim stanjem. Pri tem uporabi t. i. armature (Dashboards), ki vsebujejo
vizualne indikatorje stanja.
Podpira tako preprosto kot tudi kompleksno procesiranje dogodkov.
Dopolnjuje in uporablja obstoječo IBM-ovo SOA infrastrukturo
Za primer uporabe IBM Websphere Bisiness Events je bila izvedena študija primera, ki
opisuje njegovo uporabo pri implementaciji informacijskega sistema farmacevtske druţbe.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 38
Podjetje je ţelelo pridobiti sistem, ki bi jim omogočal sodelovanje in analizo sodelovanja z
njihovimi partnerji in končnimi uporabniki.
Podjetje proizvaja zdravila, katera pacienti ne morejo zauţiti oralno. Njihova konzumacija
je mogoča le s pomočjo injekcije, ki jo lahko vbrizga samo zdravnik. Vizija podjetja je bila
vzpostaviti sistem, ki bi v trenutku, ko zdravnik pacientu predpiše njegovo zdravilo, znalo
preveriti usposobljenost zdravnika za dodeljevanje tega zdravilo. Prav tako bi istočasno
preverilo, ali se zdravilo nahaja na zalogi in ali je pokrito s strani zavarovalnice klienta.
Končen sistem in pripadajoče aplikacije je podjetje zgradilo s pomočjo IBM Websphere
Business Events. To delo je opravljalo 40 razvijalcev, in sicer kar 18 mesecev.
Trenutno podjetje sodeluje z 10 000 do 15 000 klinikami. 2 000 000 pacientov se je v
procesu zdravljenja z njihovimi produkti tudi srečalo z uporabo njihovega sistema. [9]
4.2. Oracle rešitev
Oracle je svoja orodja, namenjena dogodkovni obdelavi, zdruţil v eno zbirko imenovano
Oracle EDA Suite. Zbirka je grajena iz naslednjih produktov:
Slika 17: Shematičen prikaz Oracle EDA Suite [10]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 39
Oracle J-Developer: gre za razvojno okolje, ki nam omogoča razvijati rešitve, ki
temeljijo na Oracle platformah. Tako je z njim mogoče razviti javanske namizne
aplikacije, spletne storitve, BPEL procese itn. [11]
Oracle BAM (Business Activity Monitor): je rešitev za grajenje interaktivnih
armatur, ki prikazujejo stanje okolja v realnem času. Orodje je predvsem
namenjeno podpori upravi podjetja pri sprejemanju odločitev, ki vplivajo na
prihodnje poslovanje. [12]
Oracle Business Processes: je orodje, ki dovoljuje večji nivo fleksibilnosti
sistema in sicer tako, da omogoča poslovnim analitikom in vsem ostalim ne-
programerjem, da vplivajo na delovanje sistema z definiranjem poslovnih pravil
brez spremembe izvorne kode. [13]
Oracle ESB: predstavlja sporočilno hrbtenico dogodkovno usmerjenega sistema.
[14]
Oracle JRockit družina produktov: produkti JRockit predstavljajo zbirko
javanskih navideznih strojev, ki so performančno optimizirani in skrbijo za to, da se
javanske aplikacije izvajajo dovolj hitro. Predvsem se ti navidezni stroji uporabljajo
pri aplikacijah v realnem času. Oracle navaja, da je izvajanje javanske kode v
primeru JRockit produktov za 70 % hitrejše kot pa pri standardnih primerljivih
produktih. [15]
Oracle Complex Event Processing: Oracle ima ţe relativno dolgo tradicijo na
področju kompleksnega procesiranja dogodkov z začetki na področju aktivnih
podatkovnih baz v začetku 90. let prejšnjega stoletja. Danes ponuja procesor za
obdelavo kompleksnih dogodkov, ki je grajen na jeziku CQL, ki omogoča
neprekinjene povpraševanje nad mnoţico tisočih podatkov. Tako modelirani
podatkovni toki in pripadajoči algoritmi za razpoznavanja vzorcev in korelacij nam
omogočajo, da izluščimo za nas relevantno dogajanje in se pravilno odzovemo
nanj. [16]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 40
4.3. TIBCO rešitev
Razvoj podjetja TIBCO je bil vedno povezan z razvojem programske opreme, namenjene
spremljanju poslovanja podjetja v realnem času. Prednik podjetja TIBCO je bilo leta 1985
ustanovljeno podjetje Teknekron. Ustanovitelj Vivek Ranadive je takrat skupaj s svojo
ekipo razvijal produkt, znan pod imenom »The Information Bus« ali TIB. Glavni namen
tega produkta je bila integracija zunanjih podatkovnih virov, kot so cene delnic na
svetovnih borzah, novice, rezultati finančnih analiz itn. v informacijske sisteme večjih
bank ali drugih podobnih finančnih institucij.
Leta 1994 je podjetje Teknekron prevzela druţba Reuters Group PCL, ki je nadaljevala z
razvojem TIB in ga uporabljala predvsem v lastne namene. Januarja 1997 je bilo
ustanovljeno podjetje TIBCO z namenom, da bi se produkti, kot je TIB, razvijali za trge, ki
niso neposredno povezani samo s financami. Produkti bi naj omogočali strankam
posredovanje in integracijo poslovnih podatkov, procesov in aplikacij. [17]
Ena izmed glavnih dejavnosti podjetja TIBCO danes je razvoj sistemov za kompleksno
procesiranje dogodkov, med katere sodi tudi produkt Business Events. Rešitev omogoča
podjetju, da prenese svoje znanje in izkušnje v obliki poslovnih pravil na informacijski
sistem.
Rešitev Business Events je zgrajena iz treh večjih komponent [18]:
Procesor za procesiranje kompleksnih dogodkov (CEP).
Storitveno vodilo, ki ima vlogo sporočilne hrbtenice sistema (ESB).
Opazovalec poslovnih aktivnosti, ki sistem oskrbuje z informacijami iz okolja
(Business Activity Monitoring - BAM).
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 41
Slika 18: Shema zgradbe sistema TIBCO Business Events [18]
Programska oprema nadzoruje mnoţico dogodkov v dogodkovnem oblaku. Na podlagi v
naprej določenih pravil, ki jih lahko preko uporabniškega vmesnika v sistem vnesem
analitik, procesor dogodkov išče relevantne vzorce dogodkov. V primeru, ko je relevanten
dogodek najden se sproţijo posledične akcije v obliki opozorila, obvestila ali, v primeru
uporabe SOA, kakšen BPEL proces.
Slika 19: Shematičen prikaz razmerja med poslovnimi pravili, dogodki in procesiranjem dogodkov [18]
Pomembno vlogo v Business Event produktu ima analizator pravil. Ta spremlja frekvenco
in rezultate proţenja pravila. Če se določeno pravilo ne izvede v pričakovanem številu v
določenem času oz. če njegove posledice povzročajo kakšne nepričakovane rezultate, nas
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 42
analizator na to opozori. Učinkovitost poslovnih pravil pa lahko spremljamo preko
vgrajenih armatur, ki prikazujejo stanje pravil s pomočjo grafov in indikatorjev. [18]
4.4. Microsoftova rešitev
Na področju storitvenih arhitektur in integracije se vse giblje okoli streţnika BizTalk.
Trenutno se nahaja v šesti izdaji in predstavlja rešitev podjetjem, ki ţelijo med seboj
povezati heterogena informacijska okolja. Vsebuje 25 različnih tipov adapterjev, ki
sluţijo povezovanju z različnimi sistemi, ki so morda ţe zastareli ali pa so grajeni na
tuji platformi, kot je na primer Java. Ena izmed osrednjih komponent streţnika BizTalk
je zagotovo njegova sporočilna infrastruktura, ki omogoča varno, robustno in
skalabilno komuniciranje. Prav tako ima privzeto podporo za komunikacijo med
napravami EDI (Electronic Data Interchage), spremljanje poslovanja BAM (Business
Activity Monitoring), RFID (Radio-frequency indentification) in podporo
komuniciranja z IBM delovnimi postajami in mainframe streţniki [19].
Slika 20: Prikaz možnosti, ki jih ponuja strežnik BizTalk v vlogi storitvenega vodila [20]
Produktov, ki bi bili eksplicitno namenjeni uporabi v dogodkovno vodenih sistemih, pri
Microsoftu še v tem trenutku ne najdemo, vendar orodja za implementacijo najdemo ţe v
samem BizTalk streţniku. V prejšnjih poglavjih smo omenili, da za implementacijo EDA
sistemov potrebujemo generatorje oz. iniciatorje dogodkov, odjemalce dogodkov, vodilo,
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 43
po katerem lahko distribuiramo sporočila (sporočilna hrbtenica), ter procesno enoto
dogodkov. [21]
Iz trenutnega nabora funkcionalnosti, ki jih ponuja trenutna izdaja BizTalk streţnika, so z
vidika dogodkovno vodenih sistemov zanimive naslednje [21]:
Nadzorovanja poslovnega okolja (BAM – Business Activity Monitoring):
Ponuja nam vmesnik uporabniškega programa (API) za implementacijo dogajanja v
primeru pojava določenega tipa dogodkov. Na voljo so tudi orodja za kreiranje
indikatorjev uspešnosti (KPI – Key Performance Indicators), ki se lahko nanašajo
na vnaprej določene cilje, povezane z doseganjem časovnih rokov ali določene
številske vrednosti. Najpomembnejša lastnost, povezana z dogodkovno
usmerjenimi arhitekturami, pa se nanaša na obvladovanje prispelih podatkovnih
tokov. Te je mogoče s pomočjo BizTalk streţnika preusmeriti v začasne tabele
relacijske podatkovne baze. Lahko bi rekli, da gre za vmesno shranjevanje
dogodkov. Pozneje je mogoč premik začasno shranjenih tokov v podatkovna
skladišča. Če potem ţelimo analizirati prejete toke dogodkov, si lahko pomagamo z
Microsoft Analysis Services, ki omogoča kreiranje tabelaričnih in grafičnih poročil
na podlagi katerih lahko opravljamo analize.
RFID podpora: Omogoča dostop do vmesnika DSPI (Device Service Provider
Interface) in do pripadajočih upravljavskih orodij. To nam omogoča, da z BizTalk
okoljem poveţemo raznovrstne naprave, kot so RFID oddajniki, čitalci kod,
senzorji itn. Mogoče je tudi simuliranje delovanja teh naprav, kar olajša delo v času
razvoja. BizTalk tudi vsebuje podporo za asinhrono obdelovanje dogodkov prejetih
dogodkov. Ob veliki obremenitvi, ko je tok dogodkov zelo gost, streţnik prejete
dogodke razvrsti v tri hierarhično razporejene cevovode. Ko dogodek prispe do
streţnika, ga ta najprej razvrsti na najniţji cevovod, kjer se dogaja dodatna filtracija
in agregacija. Ko dogodek prispe do glavnega cevovoda, je njegova naslednja
postaja pripadajoči opravilnik.
Pogon poslovnih pravil: Produkcijski sistem pravil, ki deluje po principu veriţenja
naprej, implementira Rete algoritem. Gre za algoritem, ki na učinkovit način
zaznava povezave in enakosti med vzorci. [22] Pogoni, zasnovani na Rete
algoritmu ponujajo močno podporo sklepanju nad raznovrstnimi tipi dejstev.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 44
Njegova pozitivna lastnost je hitrost delovanja in s tem manjšanje časovnega
zamika, ki nastane od prihoda dogodka do njegove obdelave. Pogon poslovnih
pravil ni namenjen prevzemanju vloge procesorja dogodkov, ampak ga
uporabljamo na višjem nivoju, kadar obravnavamo hierarhije dogodkov.
DSP
IČitalci kod
RFID
Senzorji
TOK DOGODKOV
Cevenje dogodkov
Primarni cevovod
Sekundarna cevovoda
Shranjevanje podatkov
Začasno shranjevanje v tabelah SQL strežnika
Začasno shranjevanje v tabelah SQL strežnika
Analiza podatkov
Prenos podatkov v podatkovno skladišče
Prenos podatkov v podatkovno skladišče
Podatkov in proženje posledičnih akcij
dogodkov s strani pogona poslovnih pravil
Podatkov in proženje posledičnih akcij
dogodkov s strani pogona poslovnih pravil
Vizualizacije analize podatkov s pomočjo
Microsoft Analysis Srvices
Slika 21: Shematičen prikaz delovanja komponent strežnika BizTalk v dogodkovno vodenem scenariju
Glede na to, da Microsoft v sami specifikaciji BizTalk streţnika eksplicitno ne omenja
podpore dogodkovno usmerjenim arhitekturam, ponuja skoraj vse potrebne komponente za
njihovo implementacijo. V trenutnem stanju, lahko s pomočjo BizTalk streţnika
implementiramo scenarije, kjer ne potrebujemo posebnega procesorja za procesiranje
dogodkov. Manjkajoč del bil naj bil del nove izdaje podatkovnega streţnika SQL Server
2008. V različici R2 bi naj vseboval procesno enoto za procesiranje kompleksnih
dogodkov s čim krajšo latenco. S tem dodatkom bo tako mogoče zgraditi EDA na osnovi
Microsoftove palete produktov [23].
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 45
4.5. Implementacija prototipa sistema na dogodkovno orientirane arhitekture
4.5.1. Javansko storitveno vodilo OpenESB in procesor dogodkov IEP
OpenESB je projekt, katerega cilj je omogočiti gradnjo robustnih, skalabilnih in proţnih
storitvenih aplikacij. Projekt je popolnoma odprtokoden in temelji na standardih, kot so
Java EE ali JBI. Grajen je na odprtih standardih ter podpira njihovo uporabo in s tem
omogoči interoperabilnost z različnimi produkti.[24] Za razliko od nekaterih drugih
odprtokodnih projektov je OpenESB podprt s strani velike korporacije Sun Microsystems.
OpenESB je sestavljen iz jedra, ki je lahko v obliki samostojne aplikacije ali kot del
aplikacijskega streţnika, iz pripadajočih komponent in podpornih orodij za delo
razvijalcev. Zelo pomemben del pa predstavljajo komponente. Glavni cilj komponent je
pospešiti in poenostaviti razvoj aplikacij, povezanih z OpenESB. Naloga komponente je,
da omogoči uporabo določene funkcionalnosti, ki bi v primeru lastne implementacije
predstavljala velik izziv za razvijalca. Takšen primer je asinhrono proţenje spletnih
storitev. Ta problem rešuje ţe priloţena komponenta BPEL SE. S pomočjo pripadajočega
jezika WS-BPEL je kompleksna logika izraţena z le nekaj vrsticami kode oz. nekaj
diagrami, če uporabljamo vizualni urejevalnik [25].
Pomembna naloga OpenESB je prav tako upravljanje napak, h kateremu sodi ponovno
poskušanje in alarmiranje. Vse to je mogoče z omogočanjem komunikacije med
komponentami.
OpenESB prav tako ponuja komponento za procesiranje dogodkov z imenom IEP SE ali
Intelligent Event Processor Service Engine in se razvija pod okriljem OpenESB skupnosti.
Podpira tako tokovno kot kompleksno procesiranje dogodkov. IEP lahko sprejema in
oddaja dogodke vsem zunanjim sistemom, ki jih OpenESB podpira. Iz mnoţice prejetih
dogodkov lahko generira in analizira oblak dogodkov in tudi tok dogodkov. Pri analizi
dogodkov pa si lahko pomagamo s Continous Query Language ali CQL, ki zelo spominja
na SQL in z mnoţico operatorjev pomaga pri obdelavi prej omenjenih mnoţic dogodkov
[25].
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 46
Java SE/Java EE
JBI Framework
Sloj za
upravljanje
sistemaUsmerjevalnik sporočil
IEP SE
komponenta...
Ostale
storitvene
komponente
Podatkovna baza
HTTP
Povezovalna
komponenta
SMTP
Povezovalna
komponenta
... Ostale
povezovalne
Komponente
Zunanji odjemalec
storitev
Zunanji odjemalec
storitev
Slika 22: Mesto IEP v arhitekturi OpenESB
Kot je razvidno s slike 8, IEP deluje znotraj JBI ogrodja in za procesiranje dogodkov
uporablja pogon podatkovne baze. Zbira lahko dogodke od vseh storitvenih ali
povezovalnih komponent, ki delujejo znotraj JBI. Med te sodijo storitvene komponente,
kot so BPEL SE ali XSLT SE, in povezovalne komponente, kot so SOAP komponenta,
JMS komponenta ali JDBC komponenta. [25]
Osrednji člen komunikacije je usmerjevalnik sporočil, ki je del JBI ogrodja. Storitvene in
povezovalne komponente lahko neposredno komunicirajo z usmerjevalnikom. Tako lahko
SOAP povezovalna komponenta pošlje sporočilo, ki vsebuje podatke o dogodku, preko
usmerjevalnika do IEP. Seveda lahko proces izvedemo tudi v obratni smeri, kadar IEP ţeli
komunicirati s katero od komponent. Tako je mogoča posredna komunikacija z vsemi
komponentami v sistemu.
OpenESB bomo uporabili pri javanskem delu implementacije našega praktičnega primera.
Kot razvojno okolje bomo uporabili Netbeans 6.5.1 in aplikacijski streţnik Glassfish, ki bo
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 47
gostil OpenESB. Tako Netbeans kot Glassfish sta odprtokodna projekta, ki se razvijata pod
okriljem Sun Microsystems. Za implementacijo procesne logike dogodkov pa bomo
uporabili IEP grafični urejevalnik, ki se namesti kot dodatek k razvojnemu okolju
Netbeans.
4.5.2. nServiceBus
Drug del našega praktičnega primera implementacije dogodkovno vodene arhitekture bo
implementiran s pomočjo Microsoftovega ogrodja .NET 3.5 in pripadajočimi orodji, kot so
Visual Studio 2008, IIS 7.0 in SQL streţnik 2008.
Glede na opis lastnosti BizTalk streţnika iz prejšnjih poglavij, ta zagotavlja zadovoljiv
nabor lastnosti, da ga lahko uporabimo kot storitveno vodilo pri implementaciji. Vendar se
kljub vsem naštetim prednostim nismo odločili za njegovo uporabo. Če bi ţeleli uporabljati
streţnik BizTalk, bi morali na samem streţniku namestiti še vrsto drugih Microsoftovih
produktov, ki jih BizTalk potrebuje za delovanje. I z vidika manjših in srednjih podjetij, bi
to zanje predstavljajo veliko investicijo.
Cilj tega poglavja, ki govori o implementaciji praktičnega primera dogodkovno vodenih
arhitektur, je prikazati smernice in moţnost implementacije, ki ne zahteva vezave na
enega ponudnika programske opreme, in kako lahko s pomočjo ţe obstoječih programskih
produktov (podatkovnih baz, aplikacijskih streţnikov, spletnih streţnikov itn.)
implementiramo dogodkovno voden sistem.
Tako kot javanski del naše implementacije bo tudi .NET del temeljil na odprtokodnih
rešitvah. Vsaj kar zadeva infrastrukture sporočanja. Izbrali smo ogrodje nServiceBus. Gre
za odprtokodni projekt, katerega cilj je zagotavljati kompaktno in enostavno
komunikacijsko ogrodje za gradnjo distribuiranih .NET poslovnih sistemov. [26] Kot
osnovno vodilo za komuniciranje nServiceBus omogoča uporabo sporočilne vrste
Microsoft Message Que (MSMQ). MSMQ je Microsoftova implementacija sporočilne
vrste, ki je odgovorna za dostavo sporočil znotraj ali zunaj poslovnega okolja. V Windows
okolju je ţe prisotna od Windows 95 v verziji 1.0 in do danes v Windows Server 2008 in
Vista v verziji 4.0. [27]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 48
4.5.3. Uporaba vzorca Objavi/Naroči
V prejšnjih poglavjih smo definirali dogodkovno vodene sisteme kot sisteme, ki se
odzivajo na objavljene dogodke. Ko naš generator dogodkov prepozna relevantno
spremembo v opazovanem območju, to objavi s pomočjo sporočilne hrbtenice sistema.
Tam čakajo poslušalci dogodkov, ki so prijavljeni na določen tip dogodka. V bistvu smo
spremembo oz. dogodek objavili in ga s pomočjo poslušalcev, ki so naročeni na določen
tip dogodka, sprejeli.
Vzorec Objavi/Naroči je tako asinhrona komunikacijska paradigma, kjer pošiljatelj
(oddajnik) ni programiran tako, da bi pošiljal sporočila točno določenega sprejemnika
(naročnik). Sporočila so razdeljena v različne tipe, brez vednosti o morebitnih prejemnikih
[28].
Vzorec Objavi/Naroči glede na omenjene lastnosti omogoča visok nivo šibke sklopljenosti.
V času implementacije razvijalcem sistema ni potrebno vedeti, kdo in kaj bo poslušal
dogodke. Implementacija mora le omogočati mehanizme za prijavo potencialnih
prejemnikov dogodkov.
4.5.4. Sprejemnik
Sprejemnik dogodka mora biti obveščen o tem, kateri oddajnik dogodkov je zadolţen za
določene tipe dogodkov. Ta informacija je po navadi del pogodbe med oddajnikom in
naročnikom dogodkov, kjer je zapisana končna točka, kamor mora naročnik oz. sprejemnik
poslati svojo zahtevo. Del prejemnikove zahteve je tudi tako imenovan naslov vračanja ali
»Return Address«, kjer oddajnik dobi informacijo, kam poslati dogodek. Oddajnik
dogodkov lahko informacije o tem, kateri poslušalci so prijavljeni nanj, shrani v dostopni
obliki in s tem omogoči, da lahko tudi drugi oddajniki, ki oddajajo enake tipe dogodkov,
pošiljajo dogodke do poslušalcev.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 49
Sporočilno vodilo
Oddajnik
dogodkov
Poslušalec
dogodkov tipa C
Poslušalec
dogodkov tipa B
Poslušalec
dogodkov tipa A
Tip
ATip
C
Tip
B
Slika 23: Shematičen prikaz delovanja vzorca Objavi/Naroči
Da doseţemo večjo stopnjo agilnosti pri komuniciranju med oddajnikom in poslušalcem,
lahko vzpostavimo centralno konfiguracijsko enoto, ki ima informacije o tem, kateri
oddajniki so na voljo in katere tipe dogodkov oddajajo ter kateri poslušalci bi ţeleli
prejemati določen tip dogodka. Tako bi poslušalec moral vsebovati samo funkcionalnost,
ki bi omogočila prijavo na centralno konfiguracijsko enoto, ki bi potem prevzela tisti del
komunikacije z oddajnikom, ki skrbi za naročanje sporočil.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 50
Sporočilno vodilo
Oddajnik
dogodkov
Poslušalec
dogodkov tipa C
Poslušalec
dogodkov tipa B
Poslušalec
dogodkov tipa A
Tip A
Tip B
Tip C
Centralna
konfiguracijska enota:
Podatki o prijavljenem
poslušalcu, vključno s
naslovom vračanja
Slika 24: Prikaz delovanja vzorca Objavi/Naroči z uporabo centralne konfiguracijske enote
4.5.5. Oddajnik
Naloga oddajnika je, da dostavi sporočilo oz. dogodek do vseh sprejemnikov, ki so nanj
naročeni. Pošiljanje vsakega dogodka vsakemu prijavljenemu poslušalcu pomeni veliko
obremenitev komunikacijskih kanalov in v določenih primerih ni optimalna ali pa je celo
nemogoča. Zato lahko oddajnik spremlja dogajanje v okolju, ki ga opazuje, in oblikuje eno
večje poročilo o dogajanju. To poročilo dostavlja v enakomernih časovnih intervalih do
prijavljenih sprejemnikov. Takšna rešitev je primerna za okolja, v katerih ni potrebno
spremljati dogodkov v realnem času.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 51
4.5.6. Opis scenarija
Glavna akterja v našem scenariju bosta namišljena trgovska veriga MyWallmart in
namišljena sluţba za varovanje objektov MySecurity Corporation. Informacijska sistema
obeh sluţb sta zasnovana po načelih storitveno orientiranih in dogodkovno vodenih
arhitektur. Cilj scenarija je pokazati zahteve pri implementaciji dogodkovno vodenih
arhitektur s pomočjo storitvenih in moţnosti integracije ter sodelovanja med sistemi, ki so
zasnovani na heterogenih ogrodjih.
Za začetek poglejmo zgradbo sistema pri druţbi MyWallmart. Odločili so se za vpeljavo
t. i. pametnih vozičkov. Ti imajo na sebi mnoţico RFID senzorjev, ki zaznavajo različne
RFID signale iz okolja. Vsak izdelek, ki ga lahko kupimo v njihovih veleblagovnicah, je
opremljen z RFID oddajniki. Tudi posamezni oddelki v sami veleblagovnici imajo svoj
RFID oddajnik, ki ga voziček zazna. Z naborom oddajnikov in senzorjev je tako mogoče
pridobiti naslednje informacije:
Stanje vozička: Iz podatkov lahko razberemo, ali je voziček v uporabi oz. je
neaktiven.
Lokacija vozička: Ker ima voziček moţnost sprejemanja signalov oddajnikov, ki
oddajajo informacije oddelkov, v katerem se trenutno nahajamo, je mogoče določiti
točno lokacijo vozička in spremljati njegovo gibanje.
Trenutna vsebina vozička: Kot smo ţe omenili, je vsak izdelek na policah
veleblagovnice opremljen z RFID oddajnikom. Iz prejetih signalov je mogoče
identificirati vsak izdelek, ki se nahaja v vozičku.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 52
LCD Zaslon, ki prikazuje:
- reklamna sporočila posebne ponudbe
- seznam artiklov, ki jih stranka položi v voziček
- seznam artiklov, ki so zajeti v posebno
ponudbo
RFID sprejemnik, ki
spremlja signal
oddajnikov, kateri
označujejo lokacijo v
veleblagovnici.
RFID sprejemnik, ki
spremlja signale, kateri so
bili oddani od RFID
oddajnikov na artiklih
RFID oddajnik na
artiklu, ki oddaja
indentifikator izdelka
RFID sprejemnik, ki
prepozna artikle v
neposredni bližini stranke
(v njegovi torbi, žepih, ...)
Voziček je opremljen v
vgrajeno napravo, ki je
zmožna poganjati operacijski
sistem, kot je Windows XP ali
CE.
Omogočeno mora biti:
- Povezava na Wi-Fi omrežje
- Nameščeno ogrodje .Net 2.0
ali več
Slika 25: Prikaz zgradbe pametnega vozička
Z vidika vodstva druţbe MyWallmart so prej našteti podatki zelo dragoceni. Iz trenutnega
stanja vozička lahko vidijo trenutno število strank, ki so aktivne v njihovih
veleblagovnicah. Prav tako lahko vidijo, ali ima posamezna poslovna enota na razpolago
preveč ali premalo vozičkov. Iz podatkov o lokaciji vozičkov lahko spremljajo gibanje
strank ves čas nakupa. S tem dobijo pomembne podatke o frekvenci obiska posameznih
oddelkov, o zaporedju nakupa itn. Takšne informacije so pomembne pri postavitvi samih
izdelkov, in tudi pri določanju lokacij oglasnih sporočil. Informacija o trenutni vsebini
vozička pa je koristna, ko stranka pride na blagajno. Tam lahko sistem prepozna trenutno
vsebino vozička, stranki izda račun in ji ponudi več različnih moţnosti plačila.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 53
CEP (complex event processor) –
Enota za procesiranje dogodkov:
Prepoznavanje pojavov enostavnih dogodkov
Prepoznavanje vzorcev kompleksnješih dogodkov
ESB (MyWallmart)
Pameten Voziček:
Zaznava, kateri stranka vanj položi / odstrani izdelek
Zaznava pozicijo v trgovini in glede na njo
stranko obvesti o »akcijskih« ponudbah
Ime vlogo tako generatorja kot odjemalca dogoskov
Pameten Voziček:
Zaznava, kateri stranka vanj položi / odstrani izdelek
Zaznava pozicijo v trgovini in glede na njo
stranko obvesti o »akcijskih« ponudbah
Ime vlogo tako generatorja kot odjemalca dogoskov
Poslan dogodek:
Vstavljen/
Odstranjen
izdelek št. XXX-
XXX
Poslan dogodek:
Spremenjena
lokacija vozička
Baza
podatkov
Informator o lokacijah
Prepoznana lokacija
Posreduje opis
Posreduje ponudbo
Posreduje multimedijski
materialPrijava na
dogodek:
Sprememb
a lokacije
vozička
Poslan
dogodek:
Posodoblje
ni lokacijski
podatki za
voziček št.
XXX-XXX
Prijava na
dogodek:
Sprememba
lokacijskih
podatkov
Paznik artiklov v vozičku
Spremlja spremembe pri
stanju artiklov v vozičku
Označi artikel kot kupljen, ko
ga prepozna blagajna
Prijav na
dogodek:
Spremljanje
sprememb
v vozičku
Hitra RFID blagajna:
Pregleda produkte, ki se nahajajo v bližini osebe
in so še neplačani
Hitra RFID blagajna:
Pregleda produkte, ki se nahajajo v bližini osebe
in so še neplačani
Poslan
dogodek:
Prepoznan
artikel v
vozičku
Prijava na
dogodek:
Prepoznan
artikel v
vozičku
Poslan
dogodek:
Najden
izdelek pri
stranki, ki
pa ni v
vozičku
Slika 26: Zgradba sistema za spremljanje pametnih vozičkov
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 54
V nadaljevanju poglejmo še stanje pri podjetju MySecurity Corporation. Tudi tukaj so
vpeljali informacijski sistem, ki je zasnovan na dogodkovno vodeni arhitekturi. Cilj te
odločitve je bila laţja komunikacija z ţe obstoječimi varnostnimi sistemi njihovih strank.
CEP (complex event procesor) –
Enota za procesiranje dogodkov:
Prepoznavanje pojavov enostavnih dogodkov
Prepoznavanje vzorcev kompleksnješih dogodkov
ESB (MySecurity Corp.)
Paznik
Spremlja dogodke, ki
spadajo v skupino morebitnih
kaznivih dejanj
Obvestijo pristojne organe
Poslan
dogodek:
Sum
poskusa
kraje v
poslovalnic
Wallmart
XXX-XXX
Prijava na dogodek:
Kriminalno dejanje v
MyWallmart poslovalnici
Slika 27: Zgradba sistema podjetja MySecurity Corp.
Trgovska veriga MyWallmart in sluţba za varovanje objektov MySecurity Corporation sta
se odločili za sodelovanje. MyWallmart ima v sklopu svojega informacijskega sistema, ki
obsega pameten voziček in avtomatske blagajne, moţnost, da prepozna moţno krajo
izdelkov, s tem ko primerja vse izdelke v vozičku z izdelki, ki se nahajajo v neposredni
bliţini stranke. Natančneje bo delovanje razloţeno v naslednjih poglavjih, ko bomo
obravnavali implementacijo posameznih sistemov. Ko sistem prepozna morebitno krajo
izdelka, ima moţnost posredovanja tega dogodka do informacijskega sistema oz.
storitvenega vodila MySecurity Corporation. Sistem varnostne sluţbe dogodek prepozna,
iz njega izlušči potrebne podatke (npr. lokacija stranke, izdelki, ki so domnevno ukradeni
itn.). Posledično dejanje na prejeti dogodek je delegiranje podatka do varnostnikov, ki
preko mobilne naprave dobijo sporočilo z vsemi potrebnimi podatki za intervencijo.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 55
Točka integracije med sistemomaCEP (complex event procesor) –
Enota za procesiranje dogodkov:
Prepoznavanje pojavov enostavnih dogodkov
Prepoznavanje vzorcev kompleksnješih dogodkov
CEP (complex event processor) –
Enota za procesiranje dogodkov:
Prepoznavanje pojavov enostavnih dogodkov
Prepoznavanje vzorcev kompleksnješih dogodkov
ESB (MyWallmart) - nServiceBus
Pameten Voziček: Zaznava, kateri stranka vanj položi / odstrani izdelek Zaznava pozicijo v trgovini in glede na njo
stranko obvesti o »akcijskih« ponudbah Ime vlogo tako generatorja kot odjemalca dogoskov
Pameten Voziček: Zaznava, kateri stranka vanj položi / odstrani izdelek Zaznava pozicijo v trgovini in glede na njo
stranko obvesti o »akcijskih« ponudbah Ime vlogo tako generatorja kot odjemalca dogoskov
Poslan
dogodek:
Vstavljen/
Odstranjen
izdelek št.
XXX-XXX
Poslan
dogodek:
Spremenjena
lokacija
vozička
Baza
podatkov
Informator o lokacijah
Prepoznana lokacija
Posreduje opis
Posreduje ponudbo
Posreduje multimedijski material
Prijava na
dogodek:
Sprememba
lokacije
vozička
Poslan
dogodek:
Posodobljeni
lokacijski
podatki za
voziček št.
XXX-XXX
Prijava na
dogodek:
Sprememba
lokacijskih
podatkov
Paznik artiklov v vozičku
Spremlja spremembe pri
stanju artiklov v vozičku
Označi artikel kot kupljen,
ko ga prepozna blagajna
Prijava na
dogodek:
Spremljanje
sprememb v
vozičku
Hitra RFID blagajna:
Pregleda produkte, ki se nahajajo v bližini osebe
in so še neplačani
Hitra RFID blagajna:
Pregleda produkte, ki se nahajajo v bližini osebe
in so še neplačani
Poslan
dogodek:
Prepoznan
artikel v
vozičku
Prijava na
dogodek:
Prepoznan
artikel v
vozičku
Poslan
dogodek:
Najden
izdelek pri
stranki, ki pa
ni v vozičku
ESB (MySecurity Corp.) - OpenESB
»Agent MySecurity«
Spremlja
dogodke
relevantne za
varno poslovanje
MyWallmart
Paznik
Spremlja dogodke, ki
spadajo v skupino morebitnih
kaznivih dejanj
Obvestijo pristojne organe
Spletna
storitev, ki
je na voljo
strankam
MySecurity
orporation,
da
objavljajo
dogodke
povezane s
sumom
kaznivega
dejanja
Poslan
dogodek:
Sum
poskusa
kraje v
poslovalnic
Wallmart
XXX-XXX
Prijava na
dogodek:
Kriminalno
dejanje v
MyWallmart
poslovalnici
Slika 28: Celotna shema sodelovanja podjetij
4.5.7. Implementacija scenarija
V tem poglavju si bomo natančneje pogledali arhitekturo obeh sistemov, njuno integracijo
in pilotno implementacijo. Sistem, ki ga uporablja druţba MyWallmart, bo temeljil na
ogrodju nServiceBus in tehnologiji.NET. Na tem primeru bomo prikazali delovanje vzorca
asinhronega komuniciranja Objavi/Naroči v sklopu dogodkovno vodenih arhitektur, kjer na
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 56
ta način poteka komunikacija med generatorji (oddajniki) in odjemalci (sprejemniki)
dogodkov, ter primer preprostega in kompleksnega procesiranja dogodkov.
Rešitev za podjetje MySecurity Corporation bo temeljila na javanskem okolju in na
storitvenem vodilu OpenESB. Procesiranje dogodkov bo v tem primeru prevzel dodatek
storitvenemu vodilu IEP (Intelligent Event Processor). Z njegovo pomočjo bomo poiskali
ţelene strukture v zaporedju prispelih dogodkov. Glavni razlog za izbiro omenjenih orodij
je moţnost prikaza prednosti pri integraciji dveh sistemov, ki temeljita na različnih
ogrodjih.
4.5.8. Implementacija dogodkovno vodene arhitekture s pomočjo ogrodja
nServiceBus
Kot smo omenili v prejšnjih poglavjih, predstavlja osnovno enoto dogodkovno vodenih
arhitektur dogodek. Na nivoju implementacije to ne pomeni nič drugega kot sporočilo s
podatki, ki opisujejo določeno spremembo opazovanega okolja.
Komunikacijo s sporočili je mogoče z ogrodjem nServiceBus speljati preko Microsoft
Message Queue (MSMQ). V konfiguraciji komponent je tako potrebno definirati, kam
bodo generatorji dogodkov objavljali dogodke in kam shranjevali prijave odjemalcev. Na
drugi strani pa morajo odjemalci v svoji konfiguraciji določiti, katera instanca MSMQ naj
bo vhodna vrsta in katera naj bo tista, po kateri bo prejemala sporočila od oddajnika.
V konfiguracijsko datoteko sprejemnika sporočil je potrebno vključiti naslednje
komponente:
Konfiguracijsko sekcijo, ki določa način prenosa sporočila. V našem primeru
MsmqTransportConfig, ki napove uporabo MSMQ za prenos. Pri tem se objekt, ki
s pomočjo atributov opisuje dogodek, serializira in pošlje do prejemnika.
Konfiguracijsko sekcijo, ki določa način za prenos sporočil do prejemnikov (v
našem primeru UnicastBusConfig). V dejanskem elementu konfiguracije nato točno
določimo, kateri tip sporočil oz. kateri tipi objektov, ki so pripotovali po MSMQ,
so relevantni za poslušalca.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 57
Primer 1: Primer dela konfiguracijske datoteke, kjer določimo konfiguracijo prejemnika dogodkov
...
<section name="MsmqTransportConfig"
type="NServiceBus.Config.MsmqTransportConfig, NServiceBus" />
<section name="UnicastBusConfig"
type="NServiceBus.Config.UnicastBusConfig, NServiceBus" />
</configSections>
<MsmqTransportConfig
InputQueue="worker2"
ErrorQueue="error"
NumberOfWorkerThreads="1"
MaxRetries="5" />
<UnicastBusConfig DistributorControlAddress=""
DistributorDataAddress="">
<MessageEndpointMappings>
<add Messages="MyWallmart.ESB.Lib.Msg" Endpoint="messagebus" />
</MessageEndpointMappings>
</UnicastBusConfig>
...
V konfiguracijsko datoteko oddajnika sporočil je tako potrebno vključiti naslednje
elemente:
Konfiguracijsko sekcijo, ki določa način prenosa sporočila (v našem primeru
MsmqTransportConfig).
Konfiguracijsko sekcijo, ki določa tip načina za prenos sporočil do prejemnikov (v
našem primeru UnicastBusConfig).
Konfiguracijsko sekcijo, ki definira shranjevanje naročenih prejemnikov sporočil (v
našem primeru MsmqSubscriptionStorageConfig).
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 58
Primer 2: Primer dela konfiguracijske datoteke, kjer določimo konfiguracijo oddajnika dogodkov
...
<section name="MsmqTransportConfig"
type="NServiceBus.Config.MsmqTransportConfig, NServiceBus" />
<section name="UnicastBusConfig"
type="NServiceBus.Config.UnicastBusConfig, NServiceBus" />
<section name="MsmqSubscriptionStorageConfig"
type="NServiceBus.Config.MsmqSubscriptionStorageConfig, NServiceBus" />
</configSections>
<MsmqTransportConfig InputQueue="messagebus"
ErrorQueue="error"
NumberOfWorkerThreads="1"
MaxRetries="5"/>
<UnicastBusConfig DistributorControlAddress=""
DistributorDataAddress="">
<MessageEndpointMappings>
<add Messages="MyWallmart.ESB.Lib.Msg" Endpoint="messagebus" />
</MessageEndpointMappings>
</UnicastBusConfig>
<MsmqSubscriptionStorageConfig Queue="subscriptions" />
...
V naslednjem koraku implementacije dogodkovno vodene arhitekture bomo uporabili
pomembno orodje, ki ga ponuja storitveno orientiran pristop, spletne storitve. Za vse
oddajnike dogodkov, ki jih bomo trenutno potrebovali, bomo implementirali spletno
storitev, ki bo vsebovala metode za objavo sporočil oz. dogodkov v našem sporočilnem
vodilu. Tako bo za vsak dodaten oddajnik, ki ga bomo pozneje še dodali, potrebno le
poklicati primerno metodo, ki bo zagotovila objavo dogodka. Če metoda, ki zna objaviti
določen tip dogodka, še ne obstaja, jo lahko preprosto dodamo. Sama koda, potrebna za
vzpostavitev objave v nServiceBus okolju, pa ostane enaka.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 59
nServiceBus
Spletna storitev za objavo dogodkov
iz določenega imenskega prostora
Oddajnik 1 Oddajnik 2 Oddajnik 3 Oddajnik n...
Slika 29: Koncept spletne storitve, ki skrbi za pošiljanje sporočil
Primer 3: Prikaz izseka kode, ki je potreben za objavo sporočila na vodilu
public static void PublishCartRequestedEvent(Guid eventGuid,
DateTime time,
string name,
string description,
string cartId)
{
/// kreiranje spremenljivke tipa IBus
IBus bus = NServiceBus.Configure.With()
.SpringBuilder()
// na podlagi konfiguracije se preberejo naročniki dogodkov
.MsmqSubscriptionStorage()
.XmlSerializer()
// na podlagi konfiguracije se določi transportni kanal
.MsmqTransport()
.IsTransactional(true)
.PurgeOnStartup(false)
.UnicastBus()
.ImpersonateSender(false)
.CreateBus()
.Start();
// Kreiramo objekt, ki bo nosi podatke o dogodku
CartRequested cartRequestedEvent =
bus.CreateInstance<CartRequested>();
cartRequestedEvent.EventId = eventGuid;
cartRequestedEvent.Time = time;
cartRequestedEvent.Name = name;
cartRequestedEvent.Description = description;
cartRequestedEvent.CartId = cartId;
bus.Publish(cartRequestedEvent);
}
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 60
Naslednji korak je implementacija procesorja dogodkov. V prejšnjih poglavjih smo
omenili, da poznamo tri vrste procesiranja dogodkov: preprosto, tokovno in kompleksno.
Za vsako od teh vrst procesiranja pa je odgovoren procesor oz. procesna enota dogodkov.
Procesna enota je edina, v kateri lahko opazimo, da se shranjuje stanje dogodkov. Eno
izmed osnovnih načel v dogodkovno orientiranih arhitekturah govori o stanju gradnikov.
Vsi gradniki morajo biti brez stanja (stateless), razen nekaterih delov, kjer se ne moremo
izogniti potrebi po stanju. Gradniki morajo načeloma opraviti svojo nalogo, posredovati
podatke naprej in čakati na naslednji dogodek. To načelo zagotavlja vzdrţevanje visoke
stopnje šibke sklopljenosti. Stanje sistema je shranjeno v dogodkih in ne v njihovih
gradnikih. [3]
Ena izmed dovoljenih izjem je procesor. Če ţelimo izvajati kompleksno procesiranje
dogodkov, moramo shraniti podatke o prispelih dogodkih. Kako oz. kje shranjujemo
podatke, je prepuščeno posameznemu načrtovalcu. V tem scenariju smo se odločil za
uporabo podatkovnega streţnika SQL Server Express 2005. Jedro sheme podatkovne baze
sestavljata med seboj povezani tabeli »Events« in »EventAttributes«. Številnost relacije je
1 : N, kar pomeni, da ima lahko ena zapis v tabeli »Events« več atributov, zapisanih v
tabeli »EventAttributes«.
Slika 30: Prikaz diagrama zgradbe podatkovne baze, kamor procesor dogodkov shranjuje podatke o prejetih
dogodkih
Zgradba našega procesorja bo vsebovala ţe znane komponente. Tako bo procesor
sestavljen iz mnoţice poslušalcev in generatorjev dogodkov. Sposoben bo spremljati
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 61
dogajanje na storitvenem vodilu, zanj relevantne podatke shranjevati in jih z različnimi
algoritmi analizirati.
Da pa lahko sploh začnemo operirati s sporočili oz. dogodki in se odzivati nanje, moramo
najprej ustvariti pristojne razrede. Za tip objektov, katere ţelimo objaviti na našem
storitvenem vodilu, temelječem na ogrodju nServiceBus, moramo implementirati vmesnik
IMessage. V našem primeru sem tako ustvaril še en vmesnik z imenom IEvent, ki deduje
od prej omenjenega vmesnika. Sedaj vsak tip sporočila, ki označuje dogodke znotraj
sistema MyWallmart, deduje od vmesnika IEvent.
Primer 4: Koda, ki definira vmesnik IEvent
namespace MyWallmart.ESB.Lib.Msg
{
public interface IEvent : IMessage
{
Guid EventId { get; set; }
DateTime Time { get; set; }
string Name { get; set; }
string Description { get; set; }
}
}
Vsi razredi, ki definirajo dogodke, morajo biti prav tako označeni kot »Serializable«, saj
jih mora ogrodje nServiceBus, preden jih pošlje po vodilu, serializirati. Z uvedbo skupnega
vmesnika pa smo zagotovili enoten nabor podatkov pri vseh dogodkih v sistemu.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 62
Primer 5: Implementacija razreda, ki definira tip dogodka, kateri se pojavi, ko stranka prevzame nov voziček
namespace MyWallmart.ESB.Lib.Msg
{
[Serializable]
public class CartRequested : IEvent
{
#region IEvent Members
// Nabor skupnih atributov, ki jih določa vmesnik IEvent
// Ti podatki se zapišejo v tabelo Events
public Guid EventId { get; set; }
public DateTime Time { get; set; }
public string Name { get; set; }
public string Description { get; set; }
#endregion
// Dodaten atribut
// Zapiše se v tabelo EventAttributes
public string CartId { get; set; }
}
}
Kako se bo določen poslušalec odzval na določen tip dogodka, je potrebno implementirati
v pripadajočem opravilniku oz. »Handler-ju«. To storimo tako, da v določenem razredu, ki
bo vseboval logiko za upravljanje z določenim tipom dogodka, implementiramo vmesnik
IMessageHandler<[TipDogodga]>. Ta vmesnik od razreda zahteva, da implementira
metodo Handle([TipDogodka]). Metoda se sproţi v trenutku, ko poslušalec zazna določen
tip dogodka.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 63
Primer 6: Izsek kode, ki definira opravilnik sporočil tipa CartRequested
namespace MyWallmart.ESB.Lib.Msg
{
[Serializable]
public class CartRequested : IEvent
{
#region IEvent Members
// Nabor skupnih atributov, ki jih določa vmesnik IEvent
// Ti podatki se zapišejo v tabelo Events
public Guid EventId { get; set; }
public DateTime Time { get; set; }
public string Name { get; set; }
public string Description { get; set; }
#endregion
// Dodaten atribut
// Zapiše se v tabelo EventAttributes
public string CartId { get; set; }
}
}
Na strani procesorja moramo le še implementirati logiko procesiranja. Za to bo v pomoč
shramba prejetih dogodkov v podatkovni bazi.
4.5.9. Implementacija preprostega procesiranja dogodkov
V poglavju 2.8.1 smo se ţe srečali s formalno definicijo preprostega procesiranja
dogodkov. V tem primeru procesor glede na tip dogodka sproţi posledične akcije. To je
lahko preprost zapis v podatkovno bazo, zagon kakšnega delovnega toka ali spet objava
kakšnega dogodka. Preprosto procesiranje ne shranjuje dogodkov v bazi dalj časa, ampak
le tako dolgo, da jih procesor dogodkov obdela.
V našem scenariju bomo opazovali preprosto procesiranje dogodkov na primeru menjave
lokacije vozička. Kot smo omenili ţe v opisu scenarija, ima voziček senzorje, ki mu
omogočajo, da zazna spremembo RFDI oddajnika, zadolţenega za oddajanje informacij o
trenutni lokaciji. Ko voziček zazna spremembo lokacije, s pomočjo spletne storitve objavi
dogodek tipa »CartLocationChange«, ki vsebuje atribut identifikator vozička. Ko procesor
tak tip dogodka prepozna iz podatkovne baze, ki vsebuje podatke o posebnih ponudbah
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 64
določene lokacije in reklamne videospote, pobere podatke in jih v obliki dogodka spet
objavi na storitvenem vodilu. Naš pametni voziček, ki je opremljen z LCD-zaslonom in
majhno vgrajeno računalniško napravo, je prav tako zmoţen sodelovati kot poslušalec.
Prijavljen je na tip dogodka, ki ga bo po menjavi lokacije generiral in objavil procesor. Ob
menjavi lokacije bo tako stranka na ekranu vozička zagledala seznam posebnih ponudb
določene lokacije in reklamni videospot.
Slika 31: Posnetek procesorja dogodkov v izhodiščnem
stanju
Slika 32: Prikaz na ekranu izhodiščnega stanja na
ekranu pametnega vozička
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 65
Slika 33: Prikaz stanja v procesorju v trenutku, ko ta prejme
dogodek, povezan z menjavo lokacije
Slika 34: Prikaz stanja na ekranu vozička v
trenutku, ko prejme dogodek procesorja
4.5.10. Implementacija kompleksnega procesiranja dogodkov
Pri kompleksnem procesiranju dogodkov je vloga procesorja in shranjenih podatkov veliko
bolj izrazita. Ko stranka pristopi k hitri blagajni v veleblagovnici druţbe MyWallmart,
senzor vozička prepozna vse izdelke, ki se nahajajo v samem vozičku in v neposredni
bliţini stranke. Če je na primer stranka hotela odtujiti določen izdelek in ga je s tem
namenom skrila v ţep ali torbico, je pameten voziček to prepoznal in podatke posredoval
do procesorja. V trenutku, ko procesor dogodkov prepozna tip dogodka, ki označuje
namero plačevanja stranke, preveri vse prej prejete dogodke, ki se nanašajo na polaganje
izdelkov v voziček. Če se število in tip najdenih izdelkov iz baze dogodkov ujema s
prejetimi podatki v dogodku plačevanja, potem je poskus nakupa regularen. Če se prejeti
seznam zaznanih izdelkov ne ujema s shranjenimi podatki v bazi dogodkov, potem obstaja
sum kraje.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 66
Slika 35: Koraki primera kompleksnega procesiranja dogodkov
V tem primeru seveda zanemarimo moţnost, da je lahko stranka med nakupovanjem
določen izdelek poloţila v pameten voziček in ga pozneje vrnila na polico. Namen tega
primera je pokazati pomen shranjevanja dogodkov in moţnosti njihove analize.
Cilj kompleksnega procesiranja je najti podatke, ki jih vsebujejo dogodki, povezani z
delovanjem podjetja, analizirati njihove povezave in pomen. S pomočjo pridobljenih
informacij lahko tako vodstvo spremlja njihov vpliv na poslovanje, cilje in poslovne
procese v realnem času. Kompleksno procesiranje tako zajema zaznavanje kompleksnih
vzorcev dogodkov, procesiranje toka dogodkov, ustvarjanje hierarhij dogodkov in iskanje
relacij [29].
4.5.11. Implementacija dogodkovno vodene arhitekture s pomočjo OpenESB in
IEP
Storitveno vodilo OpenESB temelji na javanskem ogrodju in je del aplikacijskega
streţnika Glassfish. V prejšnjem primeru implementacije dogodkovno vodene arhitekture,
ko smo si pomagali z nServiceBus in okoljem .NET, nismo imeli na voljo enote za
procesiranje dogodkov. Ogrodje je ponujalo funkcionalnost Objavi/Naroči, logiko
kompleksnega procesiranja pa smo morali implementirati sami. Z uporabo storitvenega
Voziček zazna prihod na pametno blagajno
Iščejo se artikli prisotni v vozičku in bližini stranke
Dogodek se posreduje preko storitvenega vodila
Procesna enota sprejme in izlušči vsebinske podatke (identifikator vozička in
artikla )
Procesna enota preišče bazo dogodkov po zadnjih
nakupih tega vozička
Procesna enota primerja skladiščene podakte s prejetimi in poskuša
prepoznati, njej poznan, vzorec
Če se podatki ne ujemajo , enota kontaktira varnostno službo MySecurity Corp.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 67
vodila OpenESB je mogoče uporabiti komponento IEP (Intelligent Event Processor). Tako
OpenESB kot IEP sta podrobneje opisana v poglavju 0.
Kot razvijalno okolje OpenESB omogoča uporabo Netbeans. Z namestitvijo določenih
dodatkov, ki so dosegljivi na spletni strani OpenESB, je mogoče vizualno modeliranje
procesiranja dogodkov.
Slika 36: Prikaz grafičnega okolja v Netbeans za implementacijo procesiranja dogodkov za podjetje MySecurity
IEP ponuja nabor operatorjev, s katerimi lahko modeliramo procesiranje. V primeru
podjetja MySecurity bomo izbrali nabor naslednjih operatorjev:
»Stream Input« – operator določa vhodno točko za tok dogodkov, ki lahko izvira
iz naprav, kot so RFID, ali iz kakšne druge aplikacije, ki opazuje določeno okolje.
Povezava do vstopne točke in objava dogodka se vrši preko spletnih storitev.
Podatki za uporabo teh storitev se nahajajo v WSDL dokumentu, ki se generira kot
stranski produkt pri prevajanju sheme. [30]
»Time Base Window« – operator določa časovni okvir, v katerem opazujemo
dogodke znotraj določenega časovnega obdobja. [31] V našem primeru bo to 1 ura.
»Insert Stream« – naloga operatorja je pretvorba relacije v tok podatkov.
Uporablja se, kadar ţelimo obdelati novi ali spremenjeni dogodek. [32]
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 68
»Stream Projection And Filter« – operator se uporablja, kadar ţelimo zdruţiti
več tokov dogodkov in ustvariti novi dogodek ali kadar ţelimo filtrirati dogodke
glede na vrednosti njihovih podatkov. Za samo zdruţevanje in filtracijo si v
primeru uporabe IEP lahko pomagamo s CQL. V samem operatorju naprej iz
različnih tokov izberemo ţelene podatke (predstavlja SELECT del CQL stavka) in
nato specificiramo pogoje, po katerih izbiramo. [33]
Slika 37: Prikaz primera uporabe operatorja "Stream Projection And Filter"
»Stream Output« – operator omogoča pretvorbo izhodnega toka dogodkov v
obliko, s katero zna operirati usmerjevalnik na storitvenem vodilu. [34]
IEP seveda še vsebuje veliko več vrst tipov operatorjev, kot so agregacijski, relacijski, več
vhodnih in izhodnih, pretvorniki relacij in sekvenčni.
V našem primeru, kot kaţe slika 29, bomo ustvarili vhodni tok dogodkov, ki so se zgodili v
časovnem okvirju enega dneva. Tok dogodkov bomo vodili naprej do filtra, kjer bomo
iskali dogodke, katerih vrednost atributa »securitycode« je enaka vrednosti »alert«. V tem
trenutku bomo poslali dogodek do izhodnega toka, ki bo sluţil naprej kot vstopna točka
BPEL procesa. Naloga tega BPEL procesa bo sproţiti spletno storitev, ki bo podatke
poslala naprej v sistem obveščanja varnostnikov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 69
Slika 38: Prikaz BPEL procesa, ki prikazuje dogajanja po tem, ko zaznamo relevanten dogodek
4.5.12. Integracija med sistemoma, ki implementirata EDA na različnih
tehnoloških platformah
Pri integraciji med obema sistemoma si spet lahko pomagamo s spletnimi storitvami, ki jih
s seboj prinese SOA. Kot smo omenili ţe v prejšnjem poglavju, operator »Stream Input«
omogoči, da dogodek posredujemo s klicem spletne storitve. Tako lahko podjetje
MySecurity Corporation za svoje odjemalce objavi mnoţico takšnih storitev in jim
omogoča pošiljanje podatkov o varnostnem stanju iz njihovih obstoječih sistemov. Za
specifične primere procesiranja morajo le spreminjati model procesiranja dogodkov v IEP.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 70
5. SKLEP
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 71
V diplomskem delu smo raziskovali osnovne značilnosti dogodkovno vodenih arhitektur.
Definirali smo osnovne gradnike kot so dogodki, procesne enote dogodkov, iniciatorji in
odjemalci dogodkov, ter njihov pomen pojasnili s pomočjo praktičnih primerov.
Seznanili smo se z različnimi tipi procesiranja in si podrobneje ogledali kompleksno
procesiranje dogodkov. Ugotovili smo, da se je razvoj dogodkovno vodenega pristopa in
procesiranja dogodkov razteza skozi zadnjih 50 let. Če smo ga naprej našli v sistemih za
simuliranje diskretnih dogodkov, ga danes v povezovalnih tehnologijah.
Prav tako smo napravili pregled tehnologij SOA, ki nam pomagajo pri razvoju
dogodkovno vodenih sistemov. Ugotovili smo, da SOA, kot tehnološka platforma,
predstavlja kakovostno pot za implementacijo sestavnih delov EDA. Kot posebej koristen
se je izkazal programski vzorec storitveno vodilo (ESB) v povezavi s spletnimi storitvami.
Z njegovo pomočjo je bilo mogoče implementirati šibko sklopljeno in decentralizirano
sporočilno infrastrukturo.
Kombinacijo dogodkovno usmerjenega pristopa v povezavi s SOA smo preizkusili z
implementacijo pilotskega projekta. Ta zajema sistema, ki sta grajena po principu
dogodkovno vodenih arhitektur, ampak temeljita na različnih programskih platformah.
Tako je rešitev namišljenega podjetja MyWallmart zasnovana na odprtokodnem
sporočilnem ogrodju nServiceBus, ki temelji na platformi .NET. Distribucijo sporočil oz.
dogodkov smo omogočili z uporabo asinhronega sporočilnega vzorca Objavi/Naroči, ki
spada med osnovne načine distribuiranja dogodkov v svetu EDA. Iniciatorji so dogodke
objavljali s pomočjo spletnih storitev, ki so na podlagi vhodnih parametrov zgradile
sporočilo oz. dogodek in ga z načinom Objavi/Naroči dostavile do prijavljenih odjemalcev.
V tem delu našega projekta smo tudi ročno implementirali procesno enoto dogodkov.
Izkazalo se je, da procesno enoto obravnavamo kot navadnega odjemalca. Za razliko od
ostalih odjemalcev, bo procesor le prijavljen na večje število dogodkov. Prejete dogodke
smo tako hranili v začasni shrambi, kjer s pomočjo implementiranih algoritmov iščemo
ţelene vzorce v prejetih sekvencah dogodkov. Izkaţe se, da je implementacija procesorja
dogodka zelo zahtevna naloga, saj hitro na letimo na probleme pri obvladovanju velikega
števila podatkov.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 72
V drugem delu našega projekta smo razvili dogodkovno voden sistem za namišljeno
podjetje MySecurity Corporation. Pri razvoju sistema smo se bolj sredinili na uporabo
vizualnega orodja, ki ga prinaša IEP SE v povezavi z Netbeans razvojnim okoljem. Uspelo
nam je definirati preprost model procesiranja dogodkov, kjer upoštevamo čas pojava in
vrednosti nekaterih atributov.
Integracijo med obema sistemoma smo omogočili z uporabo spletnih storitev. Tako smo v
sistem druţbe MySequrity Corporation dodali spletno storitev, ki omogoča strankinim
sistemom objavo dogodkov.
Pri razvoju smo naleteli tudi na nekatere teţave. Ker gre za relativno nova odprtokodna
projekta, se še pojavljajo določene teţave. V primeru nServiceBus gre predvsem za
pomanjkanje dokumentacije. Pri storitvenem vodilu OpenESB smo imeli največ teţav pri
konfiguraciji razvojnega okolja Netbeans v povezavi za IEP SE in aplikacijskim
streţnikom Glassfish 2.0.
Na to, da dogodkovno vodene arhitekture dobivajo pomembno vlogo v razvoju sodobnih
storitvenih sistemov, kaţe dejstvo, da glavni proizvajalci programskih in storitvenih
platform kot so IBM, Oracle, Tibco in posredno tudi Microsoft, v svojih paketih rešitev
ponujajo podporo distribuiranju in procesiranju dogodkov. V prihodnosti bi bilo zanimivo
raziskovanje moţnosti povezave dogodkovno vodenih arhitektur, grajenih na SOA, v
povezavi s t. i. »Cloud Computing«, kjer bi lahko zahtevno kompleksno procesiranje
dogodkov prenesli v oblak in s tem razbremenili vire na lokalnem sistemu.
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 73
6. VIRI, LITERATURA
[1] Brenda M. Michelson, »Event-Driven Architecture Overview«,
http://www.psgroup.com/detail.aspx?id=681, obiskano: maj 2009
[2] Wikipedia, »Event-driven architecture«,
http://en.wikipedia.org/wiki/Event_Driven_Architecture, obiskano: maj 2009
[3] Hugh Taylor, Angela Yochem, Les Phillips, and Frank Martinez, »EVENT-
DRIVEN ARCHITECTURE, How SOA enables the Real-Time Enterprise«, 2009.
[4] K. Mani Chandy and Roy Schulte, »Complex Event Processing«,
http://complexevents.com/wp-
content/uploads/2007/07/EDA%20article%20long%20Chandy%20and%20Schulte
%2015%20July%202007%20final.pdf, obiskano: maj 2009
[5] David Luckham, »A Short History of Complex Event Processing1«,
http://complexevents.com/wp-content/uploads/2008/07/2-final-a-short-history-of-
cep-part-2.pdf, obiskano: junij 2009
[6] Wikipedia, »Universal Description Discovery and Integration«,
http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration,
obiskano: maj 2009
[7] Jean Louis Maréchaux, »Combining Service-Oriented Architecture and Event-
Driven Architecture using an Enterprise Service Bus« ,
http://www.ibm.com/developerworks/library/ws-soa-eda-esb/, obiskano: maj 2009
[8] IBM, »WebSphere Business Events«,. http://www-
01.ibm.com/software/integration/wbe/features/, obiskano: junij 2009
[9] IBM, »Healthcare company cuts the cost of injection therapy by 90 percent with
IBM WebSphere Business Events«, http://www-
01.ibm.com/software/success/cssdb.nsf/cs/CPOR-
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 74
7MULCP?OpenDocument&Site=software&cty=en_us, obiskano: junij 2009
[10] Oracle, »Event-Driven Architecture Suite«,
http://www.oracle.com/technologies/soa/eda/eda-suite.html, obiskano: maj 2009
[11] Oracle, »JDeveloper 11g«,. http://www.oracle.com/tools/jdev_home.html,
obiskano: maj 2009
[12] Oracle, »Business Activity Monitoring«,
http://www.oracle.com/appserver/business-activity-monitoring.html, obiskano: maj
2009
[13] Oracle, »Business Rules«,. http://www.oracle.com/appserver/rules.html, obiskano:
maj 2009
[14] Oracle, »Enterprise Service Bus«, http://www.oracle.com/appserver/esb.html,
obiskano: maj 2009
[15] Oracle, »JRockit Family of Products«,
http://www.oracle.com/appserver/jrockit/index.html, obiskano: maj 2009
[16] Oracle, »Complex Event Processing«,
http://www.oracle.com/technologies/soa/complex-event-processing.html, obiskano:
maj 2009
[17] TIBCO, »Company«,. http://www.tibco.com/company/default.jsp, obiskano: maj
2009
[18] TIBCO, »BusinesEvents.« ,. http://www.tibco.com/software/complex-event-
processing/businessevents/default.jsp#, obiskano: maj 2009
[19] Microsoft, »BizTalk Overview«,
http://www.microsoft.com/biztalk/en/us/overview.aspx, obiskano: maj 2009
[20] codeplex, »Microsoft ESB Guidance«,
http://esb.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=21605, obiskano:
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 75
maj 2009
[21] Charles Young, »Complex-Event Processing (CEP) Explained for Microsoft
BizTalk Users«,
http://geekswithblogs.net/cyoung/archive/2009/05/18/cep_explained_for_biztalk_u
sers.aspx, obiskano: maj 2009
[22] Wikipedia,. »Rete algorithm« [Online],
http://en.wikipedia.org/wiki/Rete_algorithm, obiskano: junij 2009
[23] Swiss Enterprise Blog, »What’s hot on SQL Server 2008 R2?«,
http://blogs.technet.com/swisseb/archive/2009/05/14/what-s-hot-on-sql-server-
2008-r2.aspx, obiskano: junij 2009
[24] IEP, »Open Source Complex Event Processing (CEP) and Event Stream Processing
(ESP) Engine«,. https://open-esb.dev.java.net/IEPSE.html, obiskano: april 2009
[25] open-esb, »The Open Source ESB for SOA & Integration« , https://open-
esb.dev.java.net/AboutOpenEsb.html, obiskano: april 2009
[26] nServiceBus, »Overview«, http://www.nservicebus.com/overview.aspx, obiskano:
april 2009
[27] Wikipedia, »Microsoft Message Queuing«, http://en.wikipedia.org/wiki/MSMQ,
obiskano: april 2009
[28] Wikipedia, »Publish/subscribe«, http://en.wikipedia.org/wiki/Publish/subscribe
obiskano: april 2009
[29] Complex Event Processing, »About CEP« http://complexevents.com/?page_id=3
obiskano: april 2009
[30] JAVA CAPS, »Stream Input« ,
http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.gfoqq.html obiskano: april
2009
Marko Lah EDA + SOA – Dogodkovno vodene storitvene aplikacije 76
[31] JAVA CAPS, »Time Based Window«,
http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhop.html obiskano:
april 2009
[32] JAVA CAPS, »Time Based Window«,
http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhpj.html obiskano: april
2009
[33] JAVA CAPS, »Stream Projection and Filter«,
http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhki.html obiskano: april
2009
[34] JAVA CAPS, »Stream Output«,
http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhoz.html obiskano: april
2009
[35] OpenESB, »IEP Application Developer Resources«,. http://wiki.open-
esb.java.net/Wiki.jsp?page=IEPApplicationDeveloper obiskano: april 2009
[36] James McGovern, McGovern Sims, Ashish Jain, and Mark Little, Enterprise
Service Oriented Architectures, »Event-Driven Architecture«, Springer
Netherlands, 2006. obiskano: april 2009