EDA + SOA DOGODKOVNO VODENE STORITVENE APLIKACIJE · 2017. 11. 27. · EDA + SOA – EVENT DRIVEN SERVICE APPLIACTIONS Key words: event-driven, service oriented, event, enterprise

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


Č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).


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.


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.


2. ZNAČILNOSTI DOGODKOVNO VODENIH ARHITEKTUR


Č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


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.


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




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.


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.


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






Sprejem ponudbe

Ne

Potrditev/nov urnik

Da

LetališčeDeljenje

podatkov leta





Sprejem ponudbe

Ne

Potrditev/nov urnik

Da

Podporne službe






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


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].


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].


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.


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


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


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


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].


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


Dogodek prispe v



...

Objava dogodka



procesa

...


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


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.


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-


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]


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


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


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


Dogodek prispe v



...

Objava dogodka



procesa

...


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


3. POVEZAVA MED STORITVENO ORIENTIRANIMI IN

DOGODKOVNO VODENIMI ARHITEKTURAMI


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


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


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


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


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]


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.


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.


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.


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


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


4. IMPLEMENTACIJA DOGODKOVNO VODENIH

ARHITEKTUR


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.


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]


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]


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).


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


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,


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.


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].


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].


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


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]


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.


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.


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.


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.


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.


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




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


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) –




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.


Točka integracije med sistemomaCEP (complex event procesor) –




CEP (complex event processor) –




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







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


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.


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).


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.


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);

}


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


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.


Primer 5: Implementacija razreda, ki definira tip dogodka, kateri se pojavi, ko stranka prevzame nov voziček


{

[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.


Primer 6: Izsek kode, ki definira opravilnik sporočil tipa CartRequested


{

[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


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


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.


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.


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]


»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.


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.


5. SKLEP


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.


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.


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-

http://www.psgroup.com/detail.aspx?id=681

http://en.wikipedia.org/wiki/Event_Driven_Architecture

http://complexevents.com/wp-content/uploads/2007/07/EDA%20article%20long%20Chandy%20and%20Schulte%2015%20July%202007%20final.pdf



http://complexevents.com/wp-content/uploads/2008/07/2-final-a-short-history-of-cep-part-2.pdf

http://complexevents.com/wp-content/uploads/2008/07/2-final-a-short-history-of-cep-part-2.pdf

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

http://www.ibm.com/developerworks/library/ws-soa-eda-esb/

http://www-01.ibm.com/software/integration/wbe/features/

http://www-01.ibm.com/software/integration/wbe/features/

http://www-01.ibm.com/software/success/cssdb.nsf/cs/CPOR-7MULCP?OpenDocument&Site=software&cty=en_us

http://www-01.ibm.com/software/success/cssdb.nsf/cs/CPOR-7MULCP?OpenDocument&Site=software&cty=en_us


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:

http://www.oracle.com/technologies/soa/eda/eda-suite.html

http://www.oracle.com/tools/jdev_home.html

http://www.oracle.com/appserver/business-activity-monitoring.html

http://www.oracle.com/appserver/rules.html

http://www.oracle.com/appserver/esb.html

http://www.oracle.com/appserver/jrockit/index.html

http://www.oracle.com/technologies/soa/complex-event-processing.html

http://www.tibco.com/company/default.jsp

http://www.tibco.com/software/complex-event-processing/businessevents/default.jsp

http://www.tibco.com/software/complex-event-processing/businessevents/default.jsp

http://www.microsoft.com/biztalk/en/us/overview.aspx

http://esb.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=21605


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


[29] Complex Event Processing, »About CEP« http://complexevents.com/?page_id=3


[30] JAVA CAPS, »Stream Input« ,

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.gfoqq.html obiskano: april

2009

http://geekswithblogs.net/cyoung/archive/2009/05/18/cep_explained_for_biztalk_users.aspx

http://geekswithblogs.net/cyoung/archive/2009/05/18/cep_explained_for_biztalk_users.aspx

http://en.wikipedia.org/wiki/Rete_algorithm

http://blogs.technet.com/swisseb/archive/2009/05/14/what-s-hot-on-sql-server-2008-r2.aspx

http://blogs.technet.com/swisseb/archive/2009/05/14/what-s-hot-on-sql-server-2008-r2.aspx

https://open-esb.dev.java.net/IEPSE.html

https://open-esb.dev.java.net/AboutOpenEsb.html

https://open-esb.dev.java.net/AboutOpenEsb.html

http://www.nservicebus.com/overview.aspx

http://en.wikipedia.org/wiki/MSMQ

http://en.wikipedia.org/wiki/Publish/subscribe

http://complexevents.com/?page_id=3

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.gfoqq.html


[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

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhop.html

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhpj.html

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhki.html

http://developers.sun.com/docs/javacaps/jbi/jcapsdeviep.ghhoz.html

http://wiki.open-esb.java.net/Wiki.jsp?page=IEPApplicationDeveloper

http://wiki.open-esb.java.net/Wiki.jsp?page=IEPApplicationDeveloper

Documents

EDA + SOA DOGODKOVNO VODENE STORITVENE APLIKACIJE · 2017. 11. 27. · EDA + SOA – EVENT DRIVEN SERVICE APPLIACTIONS Key words: event-driven, service oriented, event, enterprise