Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Darko Poberţnik
INTEGRACIJSKI VZORCI IN PROTIVZORCI
Diplomsko delo
Maribor, september 2009
I
Diplomsko delo univerzitetnega študijskega programa Računalništvo in informatika, smer
Informatika
INTEGRACIJSKI VZORCI IN PROTIVZORCI
Študent: Darko Poberţnik
Študijski program: UN ŠP Računalništvo in informatika
Smer: Informatika
Mentor: red. prof. dr. Marjan Heričko
Lektorica: Jasna Ledinek, prof. slovenščine in zgodovine
Maribor, september 2009
II
III
ZAHVALA
Zahvaljujem se mentorju red. prof. dr. Marjanu
Heričku za pomoč in vodenje pri opravljanju
diplomskega dela. Zahvala tudi lektorici za hitro in
strokovno delo. Posebna zahvala velja staršem, ki so
mi omogočili študij, in obema bratoma, ki sta mi
kazala pravo pot.
IV
INTEGRACIJSKI VZORCI IN PROTIVZORCI
Ključne besede: Integracijski vzorci, protivzorci, integracija sistema, sporočilni sistemi,
sporočilni kanal
UDK: (659.2:004):004.4(043.2)
Povzetek
Diplomsko delo podaja predstavitev in uporabo posameznih vzorcev ter protivzorcev, ki se
uporabljajo pri integraciji informacijskih sistemov. Prav tako podrobneje spoznamo načine
integracij sistemov z uporabo integracijskih vzorcev. Na drugi strani je pomembna tudi
ozaveščenost o tem, kakšni načini niso primerni za integracijo, zato so opisani tudi
najpogostejši protivzorci. Pri tem je poudarek predvsem na pomenu in umestitvi vzorcev,
tipih, nivojih in klasifikacijah vzorcev. V praktičnem delu je predstavljena integracija spletne
trgovine in sistema ERP ter analizirana uporaba določenih vzorcev.
V
INTEGRATION PATTERNS AND ANTIPATTERNS
Key words: Integration patterns, antipatterns, system integration, messaging system, messaging channel
UDK: (659.2:004):004.4(043.2)
Abstract
This diploma covers mainly the presentation and use of some patterns and antipatterns,
that are used throughout the integration of different information systems. There is also a
detailed decription of all the methods, that are used for the system integration with the use of
integration patterns. Things, that are pointed out here are: review of the meaning, placement
of the patterns, types, levels and classifications. It is also good to know, what methods are not
that good for integration. That is why also the most common antipatterns are described. The
practical part covers the introduction of the integration of an existing web application (web
store) and an existing ERP system. Also the use of some patterns in this integration is
analysed.
VI
VSEBINA
1. UVOD ..........................................................................................................................................1
2. VZORCI INTEGRACIJE ...................................................................................................................2
2.1 Uvod ...................................................................................................................................2
2.2 Integracija sistemov .............................................................................................................2
2.3 Tipi integracij .......................................................................................................................3
2.4 Seznam vzorcev ...................................................................................................................5
2.5 Stili integracije .....................................................................................................................7
2.6 Sporočilni sistemi (angl. Messaging systems) .....................................................................10
2.6.1 Sporočilni kanal (angl. Message channel) ...................................................................10
2.6.2 Sporočilo (angl. Message) ..........................................................................................11
2.6.3 Cevi in filtri (angl. Pipes and filters) ............................................................................11
2.6.4 Usmerjevalnik sporočil (angl. Message router) ...........................................................12
2.6.5 Prevajalnik sporočil (angl. Message translator) ...........................................................13
2.6.6 Končna točka sporočil (angl. Message Endpoint) ........................................................13
2.7 Sporočilni kanali (angl. Message channels).........................................................................14
2.7.1 Odločitev o izbiri sporočilnega kanala ........................................................................15
2.7.2 Kanal tipa točka do točke (angl. Point-to-Point channel).............................................16
2.7.3 Kanal objavi - naroči (angl. Publish-Subscribe channel) ...............................................16
2.7.4 Kanal podatkovnega tipa (angl. Datatype channel) .....................................................17
2.7.5 Kanal neveljavnih sporočil (angl. Invalid message channel).........................................18
2.7.6 Kanal mrtvih sporočil (angl. Dead letter channel) .......................................................19
2.7.7 Zagotovljena dostava (angl. Guaranted delivery) ........................................................19
2.7.8 Kanalni adapter (angl. Channel adapter) ....................................................................20
2.8 Konstrukcija sporočil (angl. Message construction) ............................................................21
2.8.1 Ukazno sporočilo (angl. Command message)..............................................................22
2.8.2 Zahteva - odgovor (angl. Request-Reply) ....................................................................23
2.8.3 Zaporedje sporočil (angl. Message sequence) ............................................................23
2.8.4 Zapadlost sporočila (angl. Message expiration) ..........................................................23
2.9 Usmerjevanje sporočil (angl. Message routing) ..................................................................24
2.9.1 Seznam prejemnikov (angl. Recipient list) ..................................................................25
2.9.2 Načrt poti (angl. Routing slip) .....................................................................................26
2.9.3 Posrednik sporočil (angl. Message Broker) .................................................................26
VII
2.10 Preoblikovanje sporočil (angl. Message transformation) ....................................................27
2.11 Končne točke sporočil (angl. Message endpoints) ..............................................................28
2.11.1 Sporočilna vrata (angl. Messaging gateway) ...............................................................29
2.11.2 Konkurirajoči potrošniki (angl. Competing consumers) ...............................................30
2.12 Upravljanje sistema (angl. System management) ...............................................................31
3. PROTIVZORCI ............................................................................................................................32
3.1 Referenčni model protivzorcev ..........................................................................................34
3.2 Predloge vzorcev in protivzorcev .......................................................................................36
3.3 Razvojni protivzorci ...........................................................................................................38
3.4 Arhitekturni protivzorci .....................................................................................................42
3.5 Protivzorci upravljanja projektov programske opreme .......................................................48
3.6 Integracijski protivzorci ......................................................................................................50
3.6.1 Neredno posredovanje kode (angl. Infrequent check in) ............................................52
3.6.2 Pokvarjena verzija (angl. Broken build) .......................................................................52
3.6.3 Minimalna povratna informacija (angl. Minimal feedback) .........................................53
3.6.4 Vsiljena povratna informacija (angl. Spam feedback)..................................................54
3.6.5 Počasni stroj (angl. Slow machine) .............................................................................54
3.6.6 Razširjena verzija (angl. Bloated build) .......................................................................55
3.6.7 Posredovanje kode pred odhodom (angl. Bottleneck commits) ..................................55
3.6.8 Neprekinjena ignoranca (angl. Continuous ignorance)................................................56
3.6.9 Predvidene izdelave verzij (angl. Scheduled builds) ....................................................56
3.6.10 Delovanje na lastnem računalniku (angl. Works on my machine) ...............................56
3.6.11 Delovanje v lokalnem okolju (angl. IDE-only build) .....................................................57
3.6.12 Ozkomiselno okolje (angl. Myopic environment) ........................................................57
3.6.13 Onesnaženo okolje (angl. Polluted environment) .......................................................58
4. PRAKTIČNI DEL ..........................................................................................................................59
4.1 Uporabljeni vzorci integracije ............................................................................................60
4.2 Izbira potencialnih vzorcev za uporabo ..............................................................................65
5. SKLEP ........................................................................................................................................67
6. VIRI ...........................................................................................................................................68
7. PRILOGE ....................................................................................................................................70
7.1 Naslov študenta.................................................................................................................70
7.2 Kratek življenjepis študenta ...............................................................................................70
VIII
SEZNAM SLIK
Slika 2.1: Grafični prikaz razdelitve kategorij ........................................................................... 6
Slika 2.2: Model prenosa datotek med dvema aplikacijama ..................................................... 8
Slika 2.3: Model deljene podatkovne baze ................................................................................. 9
Slika 2.4: Model sporočilnega stila ............................................................................................. 9
Slika 2.5: Primer oddajanja in prejemanja sporočila skozi sporočilni kanal.......................... 10
Slika 2.6: Pošiljanje sporočila ................................................................................................... 11
Slika 2.7: Cevi in filtri ............................................................................................................... 12
Slika 2.8: Primer usmerjevalnika sporočil ................................................................................ 12
Slika 2.9: Primer prevajanja sporočila iz enega podatkovnega formata v drugega ............... 13
Slika 2.10: Povezava aplikacije s sporočilnim kanalom preko končne točke sporočila ........ 14
Slika 2.11: Primer kanala od točke do točke ............................................................................ 16
Slika 2.12: Primer kanala objavi - naroči ................................................................................. 17
Slika 2.13: Primer kanalov podatkovnega tipa......................................................................... 18
Slika 2.14: Primer kanala za neveljavna sporočila .................................................................. 18
Slika 2.15: Delovanje kanala mrtvih sporočil .......................................................................... 19
Slika 2.16: Model vzorca zagotovljene dostave ....................................................................... 20
Slika 2.17: Uporaba kanalnega adapterja ................................................................................. 21
Slika 2.18: Model vzorca zahteva - odgovor ............................................................................ 23
Slika 2.19: Odločitveno drevo za izbiro usmerjevalnika (prirejeno po [4]) ........................... 25
Slika 2.20: Uporaba vzorca seznam prejemnikov .................................................................... 26
Slika 2.21: Povezovanje formatov aplikacij brez kanoničnega modela in z njim ................. 28
Slika 2.22: Diagram zaporedja pri uporabi sporočilnih vrat ................................................... 30
Slika 2.23: Model vzorca konkurirajoči potrošniki ................................................................. 31
IX
Slika 3.1: Model SDLM [7]....................................................................................................... 36
Slika 3.2: Protivzorec dovod do sistema................................................................................... 44
Slika 3.3: Model rešitve protivzorca zunanje odvisnosti ......................................................... 45
Slika 3.4: Koraki tehnike preprečevanja pokvarjene verzije [9] ............................................. 53
Slika 4.1: Arhitektura sistema ApplicationBridge ................................................................... 59
Slika 4.2: Primer vsebinsko pogojenega usmerjevalnika v spletni trgovini ........................... 62
Slika 4.3: Legenda odločitvene sheme integracijskih vzorcev ............................................... 65
Slika 4.4: Odločitvena shema za izbiro integracijskih vzorcev .............................................. 66
SEZNAM PREGLEDNIC
Tabela 2.1: Seznam vzorcev integracije ..................................................................................... 6
Tabela 2.2: Uporaba vzorcev za konstrukcijo sporočil............................................................ 22
Tabela 2.3: Uporaba vzorcev končnih točk sporočila .............................................................. 29
Tabela 2.4: Seznam vzorcev upravljanja sistema po kategorijah ........................................... 31
Tabela 3.1: Stopnje vpliva glede na vrsto upravljanja ............................................................. 35
Tabela 3.2: Primer predloge protivzorca špagetasta koda ....................................................... 41
Tabela 3.3: Seznam upravljalskih protivzorcev ....................................................................... 49
Tabela 3.4: Integracijski protivzorci ......................................................................................... 51
Tabela 4.1: Seznam uporabljenih vzorcev integracije ............................................................. 61
X
SEZNAM PRIMEROV
Primer 2.1: Ukazno sporočilo tipa SOAP ................................................................................. 22
Primer 3.1: Konfiguracijska datoteka za nastavljanje naslovnikov notifikacij ...................... 54
Primer 4.1: Primer ukaznega sporočila ..................................................................................... 63
Primer 4.2: Primer funkcije za pošiljanje dokumentov spletni storitvi (C#) [12].................. 63
Primer 4.3: Dogodkovno sporočilo o spremembi podatkov stranke....................................... 64
Primer 4.4: Primer uporabe vzorca obogatitev vsebine ........................................................... 64
XI
UPORABLJENE KRATICE
ERP – Enterprise Resource Planning
EAI – Enterprise Application Integration
B2B – Business to Business
SOA – Service-Oriented Architecture
RMI – Remote Method Invocation
ebXML – Electronic Business using eXtensible Markup Language
HTTP – HyperText Transfer Protocol
TCP – Transmission Control Protocol
API – Application Programming Interface
SOAP – Simple Object Access Protocol
IT – Information Technology
SDLM – Software Design Level Model
WSI – Web Service Interface
DLL – Dynamic Link Lybrary
XML – Extensible Markup Language
XSLT – Extensible Stylesheet Transformations
IDE – Integrated Development Environment
WAR – Web Application Archive
JAR – Java Archive
EAR – Enterprise Archive
URL – Uniform Resource Locator
http://en.wikipedia.org/wiki/Information_technology
Integracijski vzorci in protivzorci Stran 1
1. UVOD
Še ne dolgo tega so nekatera najpomembnejša podjetja za programsko opremo trdila, da je z
uvedbo celovitih rešitev (ERP – Enterprise Resource Planning) konec teţav s povezovanjem
informacijskih rešitev. Danes vemo, da je prav v povezovanju ključ do hitrega prilagajanja
trga. Povečanje poslovne vrednosti današnjih informacijskih sistemov lahko zagotovimo samo
z vse večjim povezovanjem posameznih namenskih programov, poslovnih procesov in
celotnih organizacij [1]. Zagotoviti moramo nadzorovano in učinkovito izmenjavo podatkov
in poslovnih procesov med namenskimi programi in viri podatkov znotraj organizacije in
širše. Čim višja je stopnja integracije in krajši so odzivni časi, tem večje učinke lahko
pričakujemo od integriranega sistema.
Namen diplomskega dela je, da spoznamo različne principe integracije in da ugotovimo,
katere principe oz. vzorce se izplača uporabiti, saj so se v preteklosti ţe večkrat izkazali za
primerne rešitve določenih problemov pri integraciji. Prav tako bomo spoznali načine
integracij, ki niso najboljši za rešitev problemov, zato bi se morali uporabi teh vzorcev
izogibati.
V drugem poglavju bomo spoznali vzorce integracije. Predstavili bomo njihove kategorije
in jih podrobneje opisali. V tretjem poglavju bomo na podoben način spoznali njim nasprotne
protivzorce. Opisali bomo razvojne, arhitekturne, upravljavske in integracijske protivzorce. V
četrtem poglavju bo opisan praktičen primer integracije specifične spletne trgovine s
sistemom ERP, ki se imenuje Pantheon. Prav tako bodo predstavljeni posamezni primeri
vzorcev iz te integracije. Spoznali bomo tako dobre kot slabe prakse, ki so se v mnogih
projektih v preteklosti izkazale za pozitivne (vzorci) oz. negativne (protivzorci).
Integracijski vzorci in protivzorci Stran 2
2. VZORCI INTEGRACIJE
2.1 Uvod
Najprej moramo razloţiti, kaj vzorci sploh so. Vzorci pri integraciji lahko pomagajo na
različne načine. Vzorci niso deli kode, ki jih samo skopiramo iz podobnega problema (vzorec
kopiraj - prilepi), ampak so nek nasvet o rešitvah pri ponavljajočih se problemih. Vzorci
predstavljajo mehanizem za učenje in reševanje problemov, na katere pogosto naletimo pri
razvoju programske opreme. Uporaba vzorcev se je v praksi močno razširila po letu 1995, ko
je izšla knjiga Design Patterns: Elements of Reusable Object-Oriented Software [2]. V tej
knjigi so vzorci razdeljeni v tri skupine:
Arhitekturni vzorci
Predstavljajo osnovno strukturo oz. shemo sistema, definirajo podsisteme in dajejo
napotke za definiranje odgovornosti in relacij med temi podsistemi.
Načrtovalski vzorci
So neke vrste predloga za rešitev določenega problema, ki se lahko uporabi v več
situacijah in je neodvisna od programskega jezika. Objektno orientirani načrtovalski
vzorci običajno definirajo povezave med objekti ali razredi. Algoritmov ne
obravnavamo kot del načrtovalskih vzorcev.
Idiomi
So vzorci na najniţjem nivoju abstrakcije, saj definirajo rešitev problema v točno
določenem programskem okolju.
2.2 Integracija sistemov
Projekte zdruţevanja v glavnem delimo na tiste znotraj organizacije (EAI – Enterprise
Application Integration) in na projekte povezovanja z zunanjimi sistemi (B2B – Business to
Business). Pri povezovanju posameznih informacijskih sistemov je ključen proces definicije
in izgradnje integracijske arhitekture. Čim večji je projekt in čim večje je število povezujočih
Integracijski vzorci in protivzorci Stran 3
sistemov, tem pomembnejša je temeljna arhitektura. Zato je zelo pomembno, da si izberemo
pravilno pot integracije. Čeprav je okolje integracijskega projekta zelo heterogeno in
praviloma unikatno, se kljub temu pojavljajo določeni vzorci integracije. Glede na hierarhijo
abstrakcije jih lahko razdelimo na podatkovno, procesno in storitveno integracijo. Podatkovni
pristop k integraciji sistemov kot pripomoček za integracijo uporablja podatke, ki si jih
sistema izmenjujeta. Taka integracija je danes najbolj znana, uporablja se praktično od prvega
trenutka, ko je bilo potrebno povezati različne informacijske sisteme. Procesna integracija
predstavlja novo raven na podlagi podatkovne integracije. Predstavlja moţnost povezovanja
procesov in s tem avtomatizacije procesov, ki se trenutno izvajajo ročno. V osnovni shemi
procesne integracije vsak sistem prevzema nadzor nad poslovnim procesom samo v jasno
določenih točkah. Skupaj z globalno določeno poslovno logiko in določenimi delovnimi
tokovi procesna integracija ponuja moţnost optimizacije izvajanja procesov. Storitvena
integracija omogoča namenskim programom, da objavijo in proţijo skupne aplikacijske
storitve. To lahko doseţemo s pomočjo definicije skupnih metod ali z uporabo infrastrukturne
rešitve za integracijo ob pomoči storitev [2].
Vendarle pa imajo vsi trije pristopi en sam končni cilj – zagotoviti razpoloţljivost
funkcionalnosti posameznega sistema drugim sistemom. Posamezni pristopi različno vplivajo
na sisteme, ki jih ţelimo integrirati. Tako podatkovna integracija praviloma ne zahteva
sprememb izvornega ali ciljnega sistema. Na drugi strani pa storitvena integracija terja
spremembo velike večine sistemov in s tem povezane stroške dopolnitev sistemov [2].
2.3 Tipi integracij
Podjetja imajo običajno več različnih aplikacij, ki so bile razvite posebej za njih. Zato
nastopi velika zmešnjava, ko je potrebno pridobiti podatke iz teh aplikacij. Obstaja odprto
vprašanje, zakaj se podjetja sploh spuščajo v takšno zmedo. V nadaljevanju bomo pojasnili,
zakaj pride v vedno več podjetjih, predvsem večjih, do takšnih situacij. Najprej moramo
povedati, da je pisanje in predvsem načrtovanje informacijskih sistemov zelo teţavno. Skoraj
nemogoče je narediti sistem, ki bi pokril vse funkcionalnosti poslovanja, ki smo si ga zamislili
v posameznem podjetju. Celo največji in najbolj priznani sistemi, kot so SAP, Oracle,
PeopleSoft, podpirajo le peščico funkcionalnosti, ki si jih posamezniki v podjetju zamislijo.
Zato prihaja do največ integracij predvsem v povezavi s posameznimi sistemi ERP. Po
Integracijski vzorci in protivzorci Stran 4
definiciji integracija poteka med različnimi platformami na različnih lokacijah. Največ
problemov običajno nastane zaradi prodajalcev integracij, saj le-ti ponujajo različne
integracijske pakete, ki so neodvisni od platforme in programskega jezika, kar pa vedno ni
mogoče [3].
Imamo več tipov integracij, ki se med sabo razlikujejo. Najpogostejši tipi so [3]:
Informacijski portali
Tukaj moramo dostopati do več sistemov hkrati, da lahko dobimo določene
informacije ali izvedemo določeno poslovno funkcijo.
Podvojitev podatkov
V tem primeru je potrebno vsako spremembo podatkov na določenem sistemu
prenesti tudi na drug sistem, ki uporablja iste podatke, npr. če se spremeni naslov
stranke na enem sistemu, se mora spremeniti tudi na drugem sistemu, kjer
uporabljajo iste informacije o stranki.
Skupna poslovna funkcija
Določena funkcija se lahko kliče iz več sistemov, saj vsi sistemi potrebujejo iste
podatke, npr. funkcija, ki preverja, če je poštna številka pravilna, se lahko uporablja
v več sistemih hkrati.
Storitveno orientirana arhitektura (SOA – Service-Oriented Architecture)
S SOA lahko omogočimo zdruţevanje in prost pretok informacij med različnimi
aplikacijami za podporo pri poslovanju, module storitev lahko uporabljajo različne
skupine uporabnikov znotraj podjetja, lahko pa jih odpremo tudi za zunanje
uporabnike.
Porazdeljeni poslovni proces
Večkrat se zgodi, da določena sprememba v enem sistemu vpliva na več ostalih
sistemov, zato potrebujemo koordinacijo med vsemi temi sistemi, na katere vpliva.
Imeti moramo nekakšno komponento, ki upravlja med temi poslovnimi procesi in
skrbi za vse potrebne spremembe v ostalih sistemih.
Integracijski vzorci in protivzorci Stran 5
Integracija poslovanja med podjetji (B2B – Business to Business)
Podjetje omogoča določeno funkcionalnost, ki je dostopna izven lastnih aplikacij. V
tem primeru je potrebno povezati določene funkcionalnosti nekega sistema z drugim.
Takšno integracijo uporabljajo predvsem poslovni partnerji, npr. dostavna sluţba
omogoča funkcijo za izračunavo stroškov dostave, ki jo lahko poslovni partner
uporabi in tako izda stranki predračun ali račun, v katerega je vključena tudi
vrednost dostave.
2.4 Seznam vzorcev
Opisali bomo nekaj najpogostejših vzorcev integracije iz kataloga [4], kot so agregator,
mediator, sporočilno vodilo, posrednik, zahteva - odgovor, sporočilni most, garantirana
dostava. Te vzorce bomo razdelili v osem kategorij in jih tako tudi predstavili v nadaljnjih
poglavjih. Seznam najbolj uporabljanih vzorcev, ki so razdeljeni v posamezne kategorije, je
prikazan v Tabeli 2.1. Imena vzorcev so navedena v izvornem angleškem jeziku.
Integracijski vzorci in protivzorci Stran 6
Tabela 2.1: Seznam vzorcev integracije
Kategorije Vzorci
Integracijski
stili
File Transfer, Shared Database, Remote Procedure Invocation, Messaging.
Sporočilni
sistemi
Message, Message Channel, Pipes and Filters, Message Router, Message
Translator, Message Endpoint.
Sporočilni
kanali
Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel,
Invalid Message Channel, Dead Letter Channel, Guarantied Delivery,
Channel Adapter, Messaging Bridge, Message Bus.
Konstrukcija
sporočila
Command Message, Document Message, Event Message, Request-Reply,
Return Address, Correlation Identifier, Message Sequence, Message
Expiration, Format Indicator.
Usmerjanje
sporočil
Content-based router, Message Filter, Dynamic Filter, Recipient List,
Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-
Gather, Routing Slip, Process Manager, Message Broker.
Preoblikovanje
sporočil
Envelope Wrapper, Content Enricher, Content Filter, Claim Check,
Normalizer, Canonical Data Model.
Končna točka
sporočil
Messaging Gateway, Message Mapper, Transactional client, Polling
Consumer, Event-driven consumer, Competing consumers, Message
dispatcher, Selective consumer, Durable subscriber, Idempotent Receiver,
Service activator.
Upravljanje
sistema
Control bus, Detour, Wire tap, Message History, Message store, Smart
Proxy, Test Message, Channel purger.
Na Sliki 2.1 imamo grafični prikaz razdelitve omenjenih kategorij integracijskih vzorcev; na
sliki ni prvih dveh omenjenih v tabeli, saj se ti dve kategoriji ne nanašata neposredno na
sporočila.
Slika 2.1: Grafični prikaz razdelitve kategorij
Integracijski vzorci in protivzorci Stran 7
2.5 Stili integracije
Če bi imeli samo eno samostojno aplikacijo, ki bi zadovoljevala vse potrebe podjetja, se
nam ne bi bilo potrebno ukvarjati z integracijo. V realnosti pa je vsaka še tako enostavna
aplikacija odvisna od drugih in vse med seboj odvisne aplikacije morajo delovati pravilno in
usklajeno. Pri izbiri določenega pristopa imamo na voljo kar nekaj osnovnih kriterijev:
Sklopljenost aplikacij
Najbolje je, da je med aplikacijami čim manj odvisnosti, to pomeni, da moramo
zmanjšati tesno medsebojno odvisnost in sklopljenost aplikacij.
Spreminjanje aplikacij
Razvijalci naj teţijo k temu, da pri integraciji čim manj spreminjajo kodo aplikacije,
prav tako naj bo integracijske kode čim manj.
Izbira tehnologije
Različni pristopi integracije uporabljajo različne tehnologije, uporaba teh tehnologij
nas lahko preveč stane, prav tako lahko nove tehnologije povečajo čas integracije
zaradi potrebe po novih tehnologijah in spoznavanju le-teh.
Format podatkov
Aplikacije, ki jih integriramo, morajo imeti nek skupen format podatkov, ki si jih
izmenjujejo, da se le-ti ne izgubijo oz. napačno interpretirajo.
Pravočasnost podatkov
Integracija bi naj minimalizirala čas med trenutkom, ko ena aplikacija da podatke na
razpolago za procesiranje, in trenutkom, ko druga te podatke dejansko procesira.
Podatki ali funkcionalnost
Poleg podatkov lahko pri integraciji določena aplikacija nudi tudi funkcionalnosti.
Oddaljeno procesiranje
Računalniško procesiranje je običajno sinhrono, kar pomeni, da procedura čaka, da
se vse podprocedure izvedejo, ker pa je izvajanje oddaljenih procedur časovno
zahtevnejše, je bolje, da izvajamo klice oddaljenih procedur asinhrono – v tem
Integracijski vzorci in protivzorci Stran 8
primeru še vedno kličemo oddaljeno proceduro, a ne čakamo, da se le-ta konča,
temveč nadaljujemo izvajanje svojih procedur.
Zanesljivost
Oddaljeno proţenje funkcij je zelo nezanesljivo in počasno, zato je priporočljivo, da
vedno preverimo, če je oddaljena funkcija sploh dosegljiva v določenem času, in
tako izvajamo druge stvari, ki niso odvisne od te nedosegljive funkcije.
Ţal ne obstaja takšen pristop k integraciji, ki bi upošteval vse naštete kriterije. Zato so se
skozi čas razvili številni pristopi. Pristope integracij lahko povzamemo v štiri glavne
integracijske stile [4]:
Prenos datotek
Za izmenjavo podatkov med aplikacijami uporabljamo datoteke, trenutno najbolj
razširjen format za izmenjavo datotek je XML. Na Sliki 2.2 je prikazan model
prenosa datotek med dvema aplikacijama.
Slika 2.2: Model prenosa datotek med dvema aplikacijama
Deljena podatkovna baza
Vse aplikacije uporabljajo isto podatkovno bazo, kar pomeni, da bo baza tudi ves čas
dosledna oz. konsistentna. Glavna teţava pri tem stilu je načrtovanje podatkovne
baze, saj mora upoštevati vse moţne podatke vseh aplikacij, ki jo uporabljajo. Na
Sliki 2.3 je prikazan model deljene podatkovne baze.
Integracijski vzorci in protivzorci Stran 9
Slika 2.3: Model deljene podatkovne baze
Oddaljeno proženje metod
Kratica za ta integracijski stil je RMI (angl. Remote Method Invocation). Stil temelji
na enkapsulaciji integracije aplikacij. Če neka aplikacija potrebuje podatke od katere
druge, potem komunicira z njo neposredno s klici njenih funkcij.
Sporočilni stil
Prednost tega stila je, da je delovanje sistema asinhrono, kar pomeni, da ni potrebno,
da sistem, ki mora sprejemati sporočilo, v trenutku pošiljanja deluje in lahko to
sporočilo interpretira kasneje. Na Sliki 2.4 vidimo, da ima več aplikacij povezavo do
sporočilnega sistema [5].
Slika 2.4: Model sporočilnega stila
Integracijski vzorci in protivzorci Stran 10
2.6 Sporočilni sistemi (angl. Messaging systems)
Kot večina tehnologij je tudi sporočanje sestavljeno iz nekaj osnovnih konceptov. Ko enkrat
razumemo te koncepte, si ţe lahko predstavljamo tehnologijo, čeprav še ne vemo točno, kako
bomo to tehnologijo uporabili. Osnovni koncepti sporočanja so: sporočilni kanal (angl.
Message channel), sporočilo (angl. Message), cevi in filtri (angl. Pipes and Filters),
usmerjevalnik sporočil (angl. Message router), prevajalnik sporočil (angl. Message translator)
in končna točka sporočila (angl. Message endpoint) [4].
2.6.1 Sporočilni kanal (angl. Message channel)
Sporočilni sistem ima več sporočilnih kanalov, skozi katere gredo le določeni tipi podatkov.
Ko ţeli določena aplikacija posredovati podatke nekemu drugemu sistemu, ne komunicira
neposredno s sporočilnim sistemom, temveč preko točno določenega sporočilnega kanala, ki
je določen za tako vrsto podatkov. Prav tako mora aplikacija, ki sprejema določene podatke,
le-te pridobiti iz konkretnega sporočilnega kanala, ki je določen za takšne podatke. Na Sliki
2.5 je prikazano potovanje sporočila od oddajajoče aplikacije do sprejemne aplikacije skozi
sporočilni kanal [4].
Slika 2.5: Primer oddajanja in prejemanja sporočila skozi sporočilni kanal
Integracijski vzorci in protivzorci Stran 11
2.6.2 Sporočilo (angl. Message)
Vsak del podatkov, ki potuje preko sporočilnega sistema, mora biti oblikovan v sporočilo, ki
se pošlje skozi sporočilni kanal. Sporočilo je sestavljeno iz dveh delov [4]:
Glava sporočila (angl. Header)
Vsebuje informacije o sporočilu, npr. kaj, kam in od kod se pošilja.
Telo sporočila (angl. Body)
Vsebuje dejanske podatke sporočila.
Za vsak sporočilni sistem so sporočila enaka, telo sporočila se mora prenesti po navodilih,
ki so opisana v glavi sporočila. Vendar obstajajo različni tipi sporočil, ki jih bomo podrobneje
spoznali v poglavju o konstrukciji sporočil. Na Sliki 2.6 lahko vidimo primer pošiljanja
sporočila, ki je sestavljeno iz glave in telesa [4].
Slika 2.6: Pošiljanje sporočila
2.6.3 Cevi in filtri (angl. Pipes and filters)
V večini primerov integracij sistemov pride do stanja, ko mora en sam dogodek sproţiti
neko zaporedje procesov. Z vzorcem cevi in filtrov razdelimo večje opravilo na manjše med
seboj neodvisne korake (filtre), ti koraki pa so med seboj povezani preko cevi. Vsak filter ima
nalogo, da sprejme sporočilo vhodne cevi, ga sprocesira in posreduje rezultate izhodni cevi.
Posamezna cev povezuje filtre med sabo. Na Sliki 2.7 imamo primer treh filtrov in štirih cevi
[4].
Integracijski vzorci in protivzorci Stran 12
Slika 2.7: Cevi in filtri
2.6.4 Usmerjevalnik sporočil (angl. Message router)
Usmerjevalnik je zelo podoben filtru, le da ima več izhodov. Naloga usmerjevalnika je samo
sprejeti sporočilo in ga usmeriti v pravilni sporočilni kanal (cev) glede na dane pogoje. Ta
koncept torej ne spreminja sporočila, ki ga je dobil preko vhodne pipe, ampak ga samo
usmerja. Poznamo več tipov usmerjevalnikov [4]:
Fiksni usmerjevalnik
Ima samo en izhod.
Vsebinsko pogojen usmerjevalnik
Izhod se določi na podlagi vsebine sporočila.
Kontekstno pogojen usmerjevalnik
Izhod se določi na podlagi okolja, npr. če se je določen proces končal z napako, ga
poskušamo ponoviti.
Na Sliki 2.8 imamo primer usmerjevalnika, ki usmerja sporočila iz ene vhodne vrste v več
izhodnih [4].
Slika 2.8: Primer usmerjevalnika sporočil
Integracijski vzorci in protivzorci Stran 13
2.6.5 Prevajalnik sporočil (angl. Message translator)
Različne aplikacije na trgu imajo različne podatkovne modele, zato pri integraciji dveh ali
več različnih sistemov pridemo do problema usklajevanja teh modelov. Določena entiteta ene
aplikacije ima lahko drugačne atribute, kot jih ima enakovredna entiteta v podatkovnem
modelu druge aplikacije. Zato integrirane rešitve običajno komunicirajo med sabo z nekimi
standardiziranimi podatkovnimi formati, kot sta ebXML in RosettaNet, ki temeljita na notaciji
XML. Slika 2.9 prikazuje primer prevajanja sporočila, kjer za vhod dobimo podatek v
določenem podatkovnem formatu, ki ga moramo transformirati v drugega [4].
Slika 2.9: Primer prevajanja sporočila iz enega podatkovnega formata v drugega
2.6.6 Končna točka sporočil (angl. Message Endpoint)
Namen končne točke sporočila je, da ogradi sporočilni sistem od ostalega dela aplikacije.
Ostali del aplikacije ne ve veliko o formatih sporočil, sporočilnih kanalih ali kakršnihkoli
drugih informacijah o komuniciranju aplikacije preko sporočilnega sistema; vsebuje le
zahtevo ali del podatkov, ki jih mora poslati drugi aplikaciji, ali pa pričakuje podatke od
druge aplikacije. Naloga končne točke sporočil je, da vzame dano zahtevo oz. podatke, ki se
morajo poslati, jih spravi v pravilni format in jih pošlje po določenem sporočilnem kanalu.
Prav tako je naloga končne točke sporočil, da sprejema podatke od druge aplikacije, izlušči iz
podatkov ţeljeno vsebino in jo posreduje aplikaciji v obliki, ki jo bo aplikacija znala
sprocesirati. Na Sliki 2.10 lahko vidimo primer povezave aplikacij s sporočilnim kanalom
preko končne točke sporočila [4].
Integracijski vzorci in protivzorci Stran 14
Slika 2.10: Povezava aplikacije s sporočilnim kanalom preko končne točke sporočila
2.7 Sporočilni kanali (angl. Message channels)
Odločitev, ali bomo uporabili sporočilni kanal ali ne, je zelo enostavna. Če ima aplikacija
podatke, ki jih mora pošiljati oz. sprejemati, mora uporabiti kanal. Veliko teţje se je odločiti,
kateri kanal bomo izbrali in kako bomo le-tega uporabili. Imamo več tem, ki jih je potrebno
raziskati pri načrtovanju aplikacije. Te teme so [4]:
Fiksen nabor kanalov
Običajno ima aplikacija vnaprej določen nabor kanalov, ki jih bo uporabljala. Pri
načrtovanju je potrebno vedeti, kam bo usmerjena določena vrsta podatkov in
seveda tudi kje iskati podatke, ki pridejo iz drugih aplikacij. Sporočilni kanali so
večinoma določeni statično z redkimi izjemami, npr. pri kanalu za odgovor v vzorcu
zahteva - odgovor.
Določitev nabora kanalov
Vprašanje je, kdo odloča o tem, kateri kanali bodo uporabljeni – sporočilni sistem
ali aplikacija. Smiselno je, da nabore kanalov načrtujemo iterativno. Najprej
aplikacija določi, katere kanale bo sporočilni sistem potreboval, kasneje se lahko ob
spremembi aplikacije ali dodajanju nove aplikacije po potrebi dodajo novi kanali.
Usmerjenost kanalov
Vprašanje je, ali bo kanal enosmeren ali dvosmeren. Pri enosmernem kanalu
sporočilo potuje od ene aplikacije do druge, torej samo v eno smer. Če bi bil kanal
dvosmeren, bi to pomenilo, da bi aplikacija tako sprejemala kot tudi pošiljala
sporočila po istem kanalu in bi tako tudi sprejemala svoja sporočila, kar pa v
Integracijski vzorci in protivzorci Stran 15
praktičnem smislu uporabe kanalov ne bi imelo smisla, saj je bistvo sporočilnih
kanalov komunikacija med različnimi aplikacijami.
2.7.1 Odločitev o izbiri sporočilnega kanala
Zdaj ko vemo, kaj sporočilni kanali sploh so, lahko pogledamo, katere odločitve je potrebno
sprejeti pri izbiri kanala. Te odločitve so [4]:
Smer 1:1 ali smer 1:N
Tukaj moramo ugotoviti, ali ţelimo, da se podatki delijo le z eno aplikacijo ali z več
aplikacijami. V prvem primeru izberemo kanal tipa točka do točke (angl. Point-to-
Point Channel), v drugem primeru pa uporabimo kanal tipa objavi - naroči (angl.
Publish-Subscribe Channel). Oba tipa kanalov bomo opisali kasneje.
Določitev tipa podatkov
Vsaka oblika podatkov v aplikaciji mora biti določenega tipa, saj le tako lahko
sprejemna aplikacija razume te podatke. Prav to nam govori vzorec kanal
podatkovnega tipa (angl. Datatype Channel), saj morajo po logiki tega vzorca biti vsi
podatki na posameznem kanalu določenega tipa.
Neveljavna in mrtva sporočila
Sporočilni sistem omogoča, da se določeno sporočilo prenese od pošiljatelja do
prejemnika, vendar ni zadolţen za to, da prejemnik sporočila zna razpoznati
sporočilo. V tem primeru lahko uporabimo kanal neveljavnih sporočil (angl. Invalid
Message Channel), ki da to nerazvozlano sporočilo v ta kanal, in nadzorni sistem bo
to sporočilo kdaj kasneje poskusil obdelati. Podobno deluje tudi kanal mrtvih
sporočil (angl. Dead Message Channel) za sporočila, ki so uspešno poslana, a
neuspešno sprejeta.
Odpornost na napake
V primeru napake v sistemu moramo vseeno zagotoviti, da so sporočila poslana in
sprejeta. Za to obstojnost skrbi vzorec zagotovljene dostave (angl. Guaranted
Delivery), ki poskrbi za to, da se vsako sporočilo shrani na disk in tako sporočilo
tudi v primeru napake ni izgubljeno.
Integracijski vzorci in protivzorci Stran 16
Odjemalci brez povezave
Lahko imamo aplikacijo, ki se ne more povezati s sporočilnim sistemom in vseeno
hoče sodelovati pri sporočanju. V tem primeru lahko uporabimo kanalni adapter
(angl. Channel Adapter) ali sporočilni most (angl. Messaging Bridge).
Komunikacijska hrbtenica (angl. Communications backbone)
Vedno več aplikacij se povezuje s sporočilnim sistemom, zato sporočilni sistem slej
ko prej postane t. i. sporočilno vodilo (angl. Message Bus), ki omogoča dostop do
vseh aplikacij in funkcionalnosti integracije.
2.7.2 Kanal tipa točka do točke (angl. Point-to-Point channel)
Kanal tipa točka do točke skrbi za to, da določeno sporočilo dobi samo en prejemnik. Sicer
lahko obstaja več prejemnikov, a le en prejemnik bo to sporočilo lahko sprejel. Ti prejemniki
lahko med seboj tekmujejo in tako postanejo t. i. konkurenčne stranke (angl. Competing
customers). Na Sliki 2.11 lahko vidimo primer tega kanala, ki usmerja sporočila samo enemu
prejemniku [4].
Slika 2.11: Primer kanala od točke do točke
2.7.3 Kanal objavi - naroči (angl. Publish-Subscribe channel)
Ta kanal deluje tako, da ima en vhod in več izhodov, za vsakega naročnika en izhod. Ko
pride sporočilo do tega kanala, ta pošlje kopijo sporočila naprej vsem naročnikom tega kanala
in vsak naročnik lahko to sporočilo prejme le enkrat. Na Sliki 2.12 prikazujemo, kako ta kanal
posreduje sporočilo več naročnikom [4].
Integracijski vzorci in protivzorci Stran 17
Slika 2.12: Primer kanala objavi - naroči
2.7.4 Kanal podatkovnega tipa (angl. Datatype channel)
Včasih se soočimo s problemom, ko istemu prejemniku pošiljamo sporočila, ki niso istega
podatkovnega tipa. Če bi vse te različne podatkovne tipe ţeleli pošiljati po istem kanalu,
prejemnik ne bi vedel, kakšnega tipa bo sporočilo, in bi moral najprej pridobiti podatek o tipu
sporočila, šele nato bi lahko sporočilo razvozlal. Za ta problem obstaja zelo enostavna rešitev.
Izognemo se mu lahko, če uporabimo za vsak predviden podatkovni tip svoj kanal in tako po
vsakem kanalu potujejo samo sporočila istega podatkovnega tipa, tako bo tudi prejemnik znal
vsako sporočilo razvozlati, saj bo vedel, kakšnega tipa je. Na Sliki 2.13 imamo prikazan
primer več kanalov za posamezne podatkovne tipe [4].
Integracijski vzorci in protivzorci Stran 18
Slika 2.13: Primer kanalov podatkovnega tipa
2.7.5 Kanal neveljavnih sporočil (angl. Invalid message channel)
Zgodi se, da prejemnik določenega sporočila ne zna procesirati. V takem primeru je rešitev
sledeča: taka sporočila se enostavno posredujejo v poseben kanal, ki je rezerviran za
sporočila, ki niso bila uspešno procesirana. Sporočilni sistem lahko ima več takih kanalov in s
pomočjo njih lahko kasneje ugotovimo, kaj je šlo narobe, saj imamo ta sporočila še vedno
shranjena. Slika 2.14 kaţe primer, ko prejemnik neveljavno sporočilo usmeri v ta kanal [4].
Slika 2.14: Primer kanala za neveljavna sporočila
Integracijski vzorci in protivzorci Stran 19
2.7.6 Kanal mrtvih sporočil (angl. Dead letter channel)
Pri pošiljanju sporočila lahko pride do napake in kanal ne uspe dostaviti sporočila do
prejemnika. V tem primeru mora sporočilni sistem z nedostavljenim sporočilom nekaj
narediti. Ena izmed moţnosti je, da usmeri nedostavljeno sporočilo v t. i. kanal mrtvih
sporočil in sistem kasneje poskuša ugotoviti, zakaj sporočilo ni bilo dostavljeno. Na Sliki 2.15
imamo prikazan model kanala mrtvih sporočil [4].
Slika 2.15: Delovanje kanala mrtvih sporočil
2.7.7 Zagotovljena dostava (angl. Guaranted delivery)
Največja prednost asinhronega sporočanja je, da pošiljatelju in prejemniku ni potrebno
delovati v istem času. Če je prejemnik nedosegljiv, lahko sporočilni sistem shrani sporočilo v
pomnilniku, dokler prejemnik ne postane dosegljiv in mu takrat posreduje sporočilo. Problem
nastane, če se v tem času sistem zruši in se tako vsi podatki iz pomnilnika izgubijo. Zato
aplikacije uporabljajo datoteke in podatkovne baze, da podatki kljub izpadu sistema ostanejo
shranjeni. Tako je tudi pri vzorcu zagotovljene dostave. Vsak sistem, ki ima sporočilni sistem,
shranjuje podatke lokalno, šele nato pošlje podatke prejemniku, ki najprej shrani podatke
lokalno v datoteko ali podatkovno bazo in jih nato posreduje predvidenemu prejemniku.
Poudarek je seveda na tem, da je vedno potrebno imeti shranjene podatke vsaj na enem
Integracijski vzorci in protivzorci Stran 20
sistemu lokalno. S tem vzorcem sicer pridobimo obstojnost podatkov, a povečuje se
zasedenost sistema, saj je potrebno veliko zmogljivosti za dodatno shranjevanje podatkov,
dodatno zasedamo tudi lokalne diske. Na sliki 2.16 imamo model vzorca zagotovljene dostave
[4].
Slika 2.16: Model vzorca zagotovljene dostave
2.7.8 Kanalni adapter (angl. Channel adapter)
Veliko aplikacij ni bilo načrtovanih z namenom, da bi uporabljale sporočilne sisteme. Da bi
komunicirali z drugimi sistemi, uporabljajo bolj generične rešitve, kot so podatkovne baze,
izmenjava datotek ali komunikacije preko protokolov, kot sta HTTP ali TCP. Ena od rešitev
je tudi uporaba kanalnega adapterja. Z uporabo le-tega lahko dostopamo do podatkov
aplikacije in do t. i. programskega vmesnika aplikacije (angl. API-Application Programming
Interface). Ta adapter deluje kot odjemalec sporočilnega sistema, lahko posluša interne
dogodke v aplikaciji in pošilja oz. sprejema podatke od sporočilnega sistema in tako lahko
vsako aplikacijo poveţemo s sporočilnim sistemom, če le uporabimo pravilni kanalni adapter.
Na Sliki 2.17 je prikazan primer povezovanja aplikacije po vzorcu kanalnega adapterja do
sporočilnega sistema [4].
Integracijski vzorci in protivzorci Stran 21
Slika 2.17: Uporaba kanalnega adapterja
2.8 Konstrukcija sporočil (angl. Message construction)
V tem poglavju se bomo osredotočili na oblikovanje sporočila. Namen oblikovanja
sporočila je, da bo vsebina sporočila pravilno interpretirana, da bo sprejemni sistem sporočila
vrnil odgovor, če bo to zahtevano, da pri veliki količini podatkov sporočilo razbijemo na
manjše dele in jih pošljemo kot neko zaporedje sporočil in da določena sporočila dostavimo
pravočasno, saj bi v nasprotnem primeru lahko prišlo do napake v sistemu. V podpoglavjih
bodo predstavljeni primeri rešitev tovrstnih teţav pri oblikovanju sporočila. Znani vzorci za
konstrukcijo sporočil so: ukazno sporočilo (Command Message), dokumentno sporočilo
(Document Message), dogodkovno sporočilo (Event Message), zahteva - odgovor (Request-
Reply), vračanje naslova (Return Address), korelacijski identifikator (Correlation Identifier),
sekvenca sporočil (Message Sequence), zapadlost sporočila (Message Expiration), pokazatelj
formata (Format Indicator). V Tabeli 2.2 je opisano, kdaj se ti vzorci uporabljajo [4].
Integracijski vzorci in protivzorci Stran 22
Tabela 2.2: Uporaba vzorcev za konstrukcijo sporočil
Ime vzorca Uporaba
Ukazno sporočilo Pri proţenju funkcionalnosti druge aplikacije.
Dokumentno sporočilo Za zanesljiv prenos podatkovnih struktur med aplikacijami.
Dogodkovno sporočilo Za zanesljivo asinhrono obvestilo o dogodku med aplikacijami.
Zahteva - odgovor Kadar pošiljatelj potrebuje odgovor na poslano sporočilo.
Povratni naslov Kadar ţelimo, da se odgovor pošlje na drug naslov.
Korelacijski
identifikator
Kadar moramo specificirati, na katero zahtevo se nanaša
odgovor.
Sekvenca sporočil Ko podatki presegajo velikost enega samega sporočila.
Zapadlost sporočila Kadar je pomemben čas do odziva na sporočilo.
Pokazatelj formata Če moramo specificirati format sporočila, da ta format prejemnik
laţje interpretira.
2.8.1 Ukazno sporočilo (angl. Command message)
Včasih je potrebno skozi sporočilni sistem klicati funkcionalnosti sprejemne aplikacije. To
najlaţje rešimo z vzorcem ukaznega sporočila, ki ogradi to zahtevo po funkcionalnosti
drugega sistema v objekt. Na Primeru 2.1 imamo sporočilo podano v protokolu SOAP (angl.
Simple Object Access Protocol), ki kliče metodo GetLastTradePrice s parametrom symbol
[4].
Primer 2.1: Ukazno sporočilo tipa SOAP
Integracijski vzorci in protivzorci Stran 23
2.8.2 Zahteva - odgovor (angl. Request-Reply)
Ta vzorec velja za enega izmed najpogosteje uporabljanih vzorcev pri spletnih storitvah.
Uporabi se, ko pošiljatelj potrebuje odgovor glede na sporočilo, ki je bilo poslano. Pošiljatelj
pošlje sporočilo oz. zahtevo (angl. Request) po določenemu kanalu prejemniku in čaka na
odgovor. Prejemnik sprejme to sporočilo, ga sprocesira in vrne odgovor (angl. Reply) po
drugem kanalu, kar je prikazano na Sliki 2.18 [4].
Slika 2.18: Model vzorca zahteva - odgovor
2.8.3 Zaporedje sporočil (angl. Message sequence)
Včasih se zgodi, da podatki, ki jih ţelimo poslati naslovniku, presegajo velikost enega
samega sporočila. To najlaţje rešimo z zaporedjem sporočil. Kadarkoli ţelimo poslati večjo
količino podatkov, to najprej razčlenimo v manjše rezine, ki so primerne za eno samo
sporočilo, in tako najprej pošljemo predvideno zaporedje sporočil in označimo vsa sporočila z
identifikacijo zaporedja ter nato pošljemo še posamezna sporočila enega za drugim [4].
2.8.4 Zapadlost sporočila (angl. Message expiration)
Pogosto je vsebina sporočila za prejemnika veljavna le določen čas. Hitra časovna odzivnost
je pomembna predvsem pri interakciji s strankami, kadar ţelijo neposredno dobiti določene
podatke, bodisi preko kakšne aplikacije bodisi preko telefona. Zato lahko sporočilu dodamo
tudi podatek o tem, v kolikšnem času prejemnik sporočilo sploh lahko sprejme in ga
Integracijski vzorci in protivzorci Stran 24
sprocesira, ne da bi to vplivalo na slabo delovanje sistema [4]. V primeru, da se ta čas izteče,
se sporočilo usmeri v kanal mrtvih sporočil, ki smo ga opisali v poglavju 2.7.6.
2.9 Usmerjevanje sporočil (angl. Message routing)
V tem poglavju bomo razloţili, kako se je najbolje lotiti usmerjevanja sporočil pri
integraciji. Vzorce v zvezi z usmerjevanjem sporočil lahko kategoriziramo v naslednje
skupine [4]:
enostavni usmerjevalniki (en vhod ter en izhod ali več izhodov),
sestavljeni usmerjevalniki (kombiniranih je več enostavnih usmerjevalnikov) in
arhitekturni vzorci (opisujejo arhitekturne stile usmerjevanja sporočil).
Na Sliki 2.19 imamo skicirano odločitveno drevo za izbiro pravilnega usmerjevalnika. Če bi
npr. potrebovali enostaven usmerjevalnik, ki lahko sprocesira več sporočil hkrati in vrne manj
sporočil, kot jih je bilo sprocesiranih, bi se odločili za usmerjevalnik tipa agregator. Na skici
ni vzorca dinamični usmerjevalnik, saj lahko vsak usmerjevalnik implementiramo tako, da le-
ta postane dinamična različica. Prav tako ni arhitekturnega vzorca posrednik sporočil (angl.
Message broker). Podrobneje bomo predstavili tri vzorce, in sicer iz vsake kategorije enega
[4].
Integracijski vzorci in protivzorci Stran 25
Slika 2.19: Odločitveno drevo za izbiro usmerjevalnika (prirejeno po [4])
2.9.1 Seznam prejemnikov (angl. Recipient list)
Včasih ţelimo poslati sporočila več prejemnikom hkrati. Dober primer je pošiljanje
elektronskega sporočila več naslovnikom. Vendar pri tem uporabnik sam navede seznam vseh
naslovnikov. Problem nastane, ko mora sistem sam sestaviti seznam prejemnikov. To se
najlaţje rešuje z vzorcem seznam prejemnikov. Logika tega vzorca je sestavljena iz dveh
delov: prvi del sestavi seznam prejemnikov po implementirani logiki, drugi del pa enostavno
gre po tem seznamu in pošlje kopijo sporočila vsakemu prejemniku. Na Sliki 2.20 imamo
model uporabe tega vzorca [4].
Integracijski vzorci in protivzorci Stran 26
Slika 2.20: Uporaba vzorca seznam prejemnikov
2.9.2 Načrt poti (angl. Routing slip)
Ta vzorec se uporabi, kadar se ţelimo izogniti številnim komponentam usmerjanja, ki sproti
usmerjajo sporočilo od enega procesa do drugega. Namesto tega na začetku vsako sporočilo
pošljemo skozi to komponento in ta izračuna ter doda sporočilu točen načrt poti oz. določeno
zaporedje korakov, po katerem mora potovati sporočilo. Po vsakem opravljenem koraku se
pogleda v to zaporedje in to spremenjeno sporočilo usmeri k naslednjemu navedenemu
koraku v zaporedju [4].
2.9.3 Posrednik sporočil (angl. Message Broker)
Če imamo veliko število aplikacij in posledično veliko število sporočilnih kanalov, ki so
med seboj povezani po vzorcu kanala od točke do točke (vsak z vsakim), potem ugotovimo,
da smo dobili neobvladljivo število povezav brez nadzora. Temu se najlaţje izognemo, če
uvedemo centralni posrednik sporočil. Ta bo dobival sporočila od številnih kanalov, ugotovil
pravilno destinacijo in usmeril sporočilo v ustrezni kanal. Če je število povezav še vedno
neobvladljivo, lahko uvedemo več takšnih pogajalcev in jih med seboj poveţemo [4].
Integracijski vzorci in protivzorci Stran 27
2.10 Preoblikovanje sporočil (angl. Message transformation)
Pri preoblikovanju sporočil iz enega formata v drugega moramo upravljati s t. i.
metapodatki. Metapodatki so informacije o dejanskih podatkih, ki jih pošiljamo kot npr.
format, v katerem so podatki. Metapodatki igrajo tako pomembno vlogo pri integraciji, da je
večina integracijskih rešitev načrtovana tako, da se prepletata dva paralelna sistema. Eden je
zadolţen za dejanske podatke, drugi za metapodatke. Večina vzorcev je načrtovanih tako, da
lahko upravljamo metapodatke. Najpogostejši vzorci preoblikovanj sporočil so [4]:
Ovojnica pisma (angl. Envelope wrapper)
Sporočilo se pred pošiljanjem ovije v ovojnico in se ob prispetju na cilj odvije iz
ovojnice.
Obogatitev vsebine (angl. Content enricher)
Ta vzorec uporabimo, kadar potrebujemo nek zunanji izvor podatkov, da dopolnimo
sporočilo z manjkajočimi podatki.
Filter vsebine (angl. Content filter)
Nasprotno od vzorca obogatitev vsebine deluje vzorec filter vsebine: iz sporočila
odstrani nepotrebne podatke in obdrţi le pomembne podatke.
Potrdilo sporočila (angl. Claim check)
Deluje tako, da shranimo sporočilo v neko obstojno zbirko podatkov (disk), potrdilo
sporočila posredujemo določeni komponenti, ta komponenta tako lahko dostopa do
tega sporočila s tem potrdilom (Dober primer iz realnega sveta je oddaja prtljage na
letališču, saj dobimo potrdilo o svoji prtljagi, ki ima identifikacijsko številko oddane
prtljage, in ko prispemo na cilj, lahko prtljago s tem potrdilom tudi dvignemo.).
Normalizator (angl. Normalizer)
Ta vzorec preoblikovanja sporočil uporabimo, kadar ţelimo dobiti isti format
podatkov za vhodna sporočila, ki so različnih tipov. To doseţemo tako, da vsak
določen tip sporočila usmerimo v za to namenjen prevajalnik sporočil, ki sporočila
prevede v skupni podatkovni tip, za usmerjanje pa skrbi ustrezni usmerjevalnik.
Integracijski vzorci in protivzorci Stran 28
Kanonični podatkovni model (angl. Canonical data model)
Ta vzorec uporabimo, kadar imamo oz. pričakujemo več aplikacij, ki med seboj
komunicirajo, in te aplikacije nimajo nekega skupnega podatkovnega formata, kar
pomeni, da potrebujemo prevajalnike sporočil, ki bodo spremenili posamezno
sporočilo v pravilni podatkovni format. Ta vzorec ima osrednji format podatkov, kar
pomeni, da vsaka aplikacija pošilja in sprejema podatke tega modela. Obstaja torej
vmesni sloj med posameznimi formati aplikacij in vsakič, ko se doda nova
aplikacija, se mora ustvariti le transformacija med tem modelom in novo aplikacijo.
Tako pri velikem številu aplikacij potrebujemo veliko manj transformacij, kot bi jih
v primeru, če ne bi uporabili tega modela. Za šest aplikacij bi brez uporabe modela
potrebovali trideset transformacij, z uporabo pa le dvanajst, ta razlika je lepo vidna
na Sliki 2.21 [6].
Slika 2.21: Povezovanje formatov aplikacij brez kanoničnega modela in z njim
2.11 Končne točke sporočil (angl. Message endpoints)
Obstaja veliko moţnosti, da priredimo aplikacijo v končno točko sporočil (angl. Message
endpoint), in to poglavje bo razloţilo, kakšne so te moţnosti ter kako jih najbolje izkoristiti.
Vzorci končnih točk se najpogosteje nanašajo na naslednja dva elementa:
Sporočilni sistem v splošnem (ograditev kode sporočilnega sistema, prevajanje
podatkov, zunanje kontrolirane transakcije)
Sprejemanje sporočil
Integracijski vzorci in protivzorci Stran 29
Najpogostejši tovrstni vzorci so: sporočilna vrata (angl. Messaging gateway), distributer
sporočil (angl. Messaging mapper), transakcijski odjemalec (angl. Transactional client),
izbirajoči potrošnik (angl. Polling consumer), dogodkovno usmerjen potrošnik (angl. Event-
driven consumer), konkurirajoči potrošniki (angl. Competing consumers), razpečevalec
sporočil (angl. Message dispatcher), selektiven potrošnik (angl. Selective consumer), obstojen
naročnik (angl. Durable subscriber), idempotenten prejemnik (angl. Idempotent receiver) in
aktivator storitev (Service activator). V Tabeli 2.3 je opisano, kdaj se ti vzorci uporabljajo [4].
Tabela 2.3: Uporaba vzorcev končnih točk sporočila
Ime vzorca Uporaba
Sporočilna vrata Če ţelimo ločiti sporočilni del od ostalega dela aplikacije.
Distributer sporočil Kadar ţelimo prenašati podatke med domenskimi objekti in
sporočilno infrastrukturo, ne da so le-ti odvisni med sabo.
Transakcijski
odjemalec
Če ţelimo, da odjemalec nadzoruje transakcije s sporočilnim
sistemom.
Izbirajoči potrošnik Kadar ţelimo, da potrošnik izbira, kdaj bo prejel sporočilo.
Dogodkovno
usmerjen potrošnik
Sporočilo se preda prejemniku, ko to prispe do kanala.
Konkurirajoči
potrošniki
Kadar ţelimo, da potrošniki procesirajo več sporočil hkrati.
Razpečevalec sporočil Ko moramo distribuirati sporočila različnim prejemnikom.
Selektiven potrošnik Kadar ţelimo, da potrošnik izbira, katera sporočila bo sprejel.
Obstojen naročnik Če ţelimo, da se sporočila shranijo, tudi ko prejemnik ni aktiven,
in le-te prejme, ko spet postane aktiven.
Idempotenten
prejemnik
Kadar ţelimo, da potrošnik prejme eno in isto sporočilo večkrat in
je rezultat isti, kot če bi le-to prejel samo enkrat.
Aktivator storitev Če ţelimo, da sporočila poveţemo s kanali storitev, ki so bile
dostopane.
2.11.1 Sporočilna vrata (angl. Messaging gateway)
Včasih mora enostavna sporočilna funkcija poslati več kot samo eno sporočilo. Npr.
funkcija, ki ţeli dostopati do podatkov stranke, lahko ustvari več sporočil za te informacije,
Integracijski vzorci in protivzorci Stran 30
eno sporočilo za naslov, eno za osebne podatke, spet eno za zgodovino naročil itd. Zato je
najbolje, da uporabimo vzorec sporočilnih vrat, ki ogradi kodo, ki je specificirana za
sporočanje, in tako ločimo sporočilni del od ostalega dela aplikacije. Na Sliki 2.22 imamo
prikazan diagram zaporedja pri uporabi sporočilnih vrat. Aplikacija za vse podatke, ki jih
potrebuje od sporočilnega sistema, zadolţi sporočilna vrata, ki komunicirajo s sporočilnim
sistemom in vrnejo podatke aplikaciji [3].
Slika 2.22: Diagram zaporedja pri uporabi sporočilnih vrat
2.11.2 Konkurirajoči potrošniki (angl. Competing consumers)
Sporočila se skozi sporočilne kanale vrstijo zaporedno in naravno jih tudi potrošnik
procesira zaporedno. To pa je običajno prepočasno in večkrat se zgodi, da takšno procesiranje
sporočil privede do t. i. ozkega grla, kar pomeni, da potrošnik ne more procesirati sporočil
tako hitro, kot jih kanal dobiva, in tako se le-ta nabirajo v kanalu. Kar potrebujemo v takem
primeru, je, da ima kanal več moţnih prejemnikov sporočil. To rešimo z vpeljavo vzorca
konkurenčnih potrošnikov, ki sočasno procesirajo več sporočil. Ti potrošniki so ustvarjeni
zato, da prejemajo in procesirajo sporočila samo od določenega kanala. Ko ta kanal dostavi
sporočilo, ga lahko prejme katerikoli izmed potrošnikov. Kateri pa ga bo prejel v resnici, je
odvisno od implementacije sporočilnega sistema. Ta rešitev deluje samo pri uporabi kanala
Integracijski vzorci in protivzorci Stran 31
točka do točke, ki smo ga opisali v enem izmed prejšnjih poglavjih. Na Sliki 2.23 imamo
prikazan model tega vzorca. Vidimo, da imamo več sporočil in več potrošnikov, ki med seboj
tekmujejo in kasneje tudi prejmejo ta sporočila [4].
Slika 2.23: Model vzorca konkurirajoči potrošniki
2.12 Upravljanje sistema (angl. System management)
Pri spremljanju sporočilnih rešitev lahko spremljamo sporočila na dveh nivojih abstrakcije.
Tipični upravljalni sistem spremlja, koliko sporočil je bilo poslanih in kako dolgo je trajalo,
da so bila procesirana. Drugače deluje sistem za spremljanje poslovnih aktivnosti, saj je
osredotočen na ostale podatke, ki jih vsebuje sporočilo, kot npr. vrednost vseh pošiljk, ki so
bila poslana na današnji dan. V Tabeli 2.3 so navedeni najbolj znani vzorci upravljanja
sistema, razdeljeni po kategorijah [4].
Tabela 2.4: Seznam vzorcev upravljanja sistema po kategorijah
Kategorije Vzorci
Spremljanje in kontroling Kontrolno vodilo (angl. Control bus), ovinek (angl.
Detour).
Opazovanje in analiza
prometa sporočil
Zgodovina sporočil (angl. Message history), shranjevanje
sporočil (angl. Message store), pameten namestnik (angl.
Smart Proxy).
Testiranje in razhroščevanje Testno sporočilo (angl. Test message), čistilec kanalov
(angl. Channel purger).
Integracijski vzorci in protivzorci Stran 32
3. PROTIVZORCI
Protivzorec je nek koncept, ki opisuje pogosto uporabljeno rešitev nekega problema in
ustvari izrazito negativne posledice. Običajno je rezultat načrtovalca ali razvijalca, ki nima
dovolj izkušenj in znanja za reševanje določenega problema ali pa izbere napačen vzorec
glede na kontekst problema. Protivzorec predstavlja t. i. negativen vzorec, ki povzroča razne
prepreke pri razvoju. Protivzorci imajo torej dva namena, in sicer da identificirajo probleme in
pomagajo pri implementaciji rešitve problema. Ponujajo izkušnje mnogih v realnem svetu, ki
delujejo v industriji programske opreme in so se srečali s podobnimi ponavljajočimi se
problemi, podajo pa tudi najboljše rešitve najpogostejših problemov. Poudarjajo najpogostejše
napake in ponujajo razna orodja za prepoznavo le-teh ter določajo njihove glavne vzroke.
Poleg tega predstavljajo učinkovite ukrepe, ki jih lahko izvedemo na različnih nivojih z
namenom izboljšanja razvoja aplikacij, načrtovanja IT-sistemov in uspešnega upravljanja s
projekti programske opreme. Razlika med vzorci in protivzorci je torej v kontekstu.
Protivzorec je vzorec, uporabljen v neprimernem kontekstu. Protivzorci se delijo glede na
perspektive [7]:
Razvojni protivzorci (angl. Development antipatterns)
Obsegajo tehnične probleme in rešitve, ki jih srečajo predvsem programerji.
Arhitekturni protivzorci (angl. Architectural antipatterns)
Identificirajo in odpravljajo probleme glede strukture sistema.
Upravljavski protivzorci (angl. Managerial antipatterns)
Obsegajo procese programske opreme in organizacijo razvoja.
Izvor protivzorcev
Jezik načrtovalskih vzorcev (Design Pattern) je v trenutku navdušil programsko skupnost, k
čemur je najbolj prispevalo hrepenenje razvijalcev informacijskih rešitev po izboljšanju
kvalitete in standardov IT-industrije. Glede na vse bolj naraščajoče število projektov ni
mogoče razpravljati o notranji vrednosti in morebitni prednosti pri vpeljavi vzorcev v projekt.
Vzorci so se najprej pojavljali v arhitekturi, v IT-industriji pa so se prvič pojavili leta 1987, ko
sta Ward Cunningham in Kent Beck razvila jezik načrtovalskih vzorcev za razvoj
uporabniških vmesnikov v programskem jeziku Smalltalk [7]. V letih zatem je veliko ljudi, ki
Integracijski vzorci in protivzorci Stran 33
je imelo enake ideje o uporabi načrtovalskih vzorcev, poskušalo na podoben način ter z njuno
pomočjo raziskati in razviti stvari z namenom ponovne uporabe vzorcev. V osemdesetih letih
je bilo očitno, da ni dovolj talentiranih arhitektov v objektno orientiranem razvoju programske
opreme in da bo treba to nekako spremeniti. Prav tako je vse več izkušenih zaposlenih tratilo
čas z mentorstvom drugih manj izkušenih zaposlenih, namesto da bi reševalo bolj zahtevne in
kritične probleme. Vse to je pripeljalo do vse večje potrebe po obliki ponovne uporabe, ki bo
zajela znanje izkušenih strokovnjakov in se bo lahko uporabila za ponavljajoče učenje drugih
manj izkušenih sodelavcev. Šele leta 1994 so postali načrtovalski vzorci glavna zanimivost
skupnosti razvoja programske opreme. Takrat je namreč skupina Hillside imela prvo in še
vedno legendarno konferenco o načrtovalskih vzorcih. Industrija se je na njih odzvala nadvse
pozitivno, saj so IT-strokovnjaki iz nivoja podatkovnih struktur in programskih idiomov
prestavili svojo osredotočenost na višji nivo, in sicer na arhitekturni del, in tako so izrazi, kot
so fasade, obiskovalci, adapterji, postali vse pogosteje uporabljani v razpravah na temo
snovanja programske opreme. Po letu 1994 so objave v zvezi z načrtovalskimi vzorci
eksponentno rasle, kar ima tako pozitivne kot negativne posledice. Pozitivno je to, da je bilo
vedno več vzorcev, ki so bili dokumentirani in so jih lahko arhitekti uporabljali pri razvoju
programske opreme. Negativno pa je, da mnogo ljudi, ki je uporabljalo načrtovalske vzorce,
ni dobro uvrstilo vzorca in ocenilo, v kolikšni meri je določen vzorec primeren glede na
določen kontekst in stanje aplikacije.
Leta 1996 se je prvič formalno pojavila beseda protivzorec, in sicer na konferenci »Object
World West«, kjer je Michael Akroyd imel predstavitev z naslovom »Antipatterns«.
Predstavitev je bila osredotočena na prepoznavo škodljivih konstruktov programske opreme,
ki so se ponavljajoče pojavljali skozi različne projekte. Protivzorci so torej vedno obstajali.
Rečemo lahko, da so naraven korak v razvoju vzorcev, saj jih dopolnjujejo in nadgrajujejo.
Glede na pogostost napak in neuspehe projektov lahko rečemo, da so negativne rešitve
bogatejše z raziskovalno vsebino, saj se pogosteje srečamo z napačno zasnovanimi projekti in
moramo odkriti napake, torej poiskati protivzorce ter jih odpraviti, kot pa z razvojem od
začetka, kjer lahko uporabimo vzorce glede na kontekst problema [7, 8].
Integracijski vzorci in protivzorci Stran 34
3.1 Referenčni model protivzorcev
Kadar naletimo na kakšen protivzorec, je dobro imeti pravilen pristop, ki pomaga izboljšati
rešitev in odpraviti pomanjkljivosti. Ta proces sprememb, migracij in razvoja se imenuje
preoblikovanje (angl. Refactoring). Pri preoblikovanju spremenimo neko rešitev v drugo
rešitev z izboljšano strukturo, ki prinaša več prednosti. Najpomembnejša pri vzorcih je
njihova berljivost. Običajno ima vzorec dokaj obseţno dokumentacijo, čeprav je rešitev
pogosto zelo očitna in tako obširna dokumentacija sploh ne bi bila potrebna. To je moţno
zaradi uporabe referenčnega modela, ki definira konceptualno ogrodje in splošne koncepte
med vsemi vzorci. Referenčni model sestavljajo trije ključni koncepti:
Glavni vzroki (angl. Root causes)
To so napake pri razvoju programske opreme, katerih rezultat so ponesrečeni
projekti, prekoračitev sredstev oz. urnika ali neizpolnjene poslovne potrebe.
Zagotavljajo osnovni kontekst protivzorcev. Ţal so te napake zelo pogoste, saj je
kar ena tretjina projektov neuspešno prekinjenih, pet od šestih projektov je
neuspešnih [7]. Ti vzroki temeljijo na t. i. sedmih smrtnih grehih: naglica, apatija,
ozkomiselnost, lenoba, pohlep, ignoranca in ponos. Če ţelimo uspešno zaključiti
projekt, se moramo tem pastem izogibati.
Prvotne motivacije (angl. Primal forces)
Predstavljajo vidike, ki jih je potrebno upoštevati pri odločitvi. Če te vidike
pravilno naslovimo, pridobimo prednosti v projektu, v nasprotnem primeru se
pojavijo negativne posledice. So ključni motivatorji za odločitev glede izbire
protivzorca. V Tabeli 3.1 so podane stopnje vpliva glede na vrsto upravljanja,
navedene so hierarhično glede na skupnosti, na katere vplivajo [7].
Integracijski vzorci in protivzorci Stran 35
Tabela 3.1: Stopnje vpliva glede na vrsto upravljanja
Vrsta
upravljanja
Globalna
industrija
Podjetje Sistem Aplikacija
Funkcionalnost nepomembno delno pomembno pomembno kritično
Zmogljivost pomembno pomembno kritično kritično
Kompleksnost pomembno kritično pomembno delno pomembno
Spremembe nepomembno kritično kritično pomembno
IT-viri nepomembno kritično pomembno delno pomembno
Prenosljivost
tehnologij
kritično pomembno pomembno delno pomembno
Nivojsko načrtovalski model (angl. Software design-level model, SDLM)
Če se lotimo razvoja kakšnega sistema nesistematično, brez celostne arhitekture,
le-ta zaradi vedno širše funkcionalnosti in nenehne potrebe po spremembah ter
dodajanja novih tehnologij postaja vedno bolj neobvladljiv. Ključna prednost
uvedbe arhitekture je ločitev različnih vidikov v posamezne rešljive elemente, kar
je na koncu veliko laţje rešljivo kot reševanje vseh problemov naenkrat. Na Sliki
3.1 imamo prikazan model, kjer je sedem arhitekturnih nivojev, ki so podani
hierarhično od najvišjega (globalno-industrijski nivo) do najniţjega (razredi in
objekti). Globalni nivo je zadolţen za koordinacijo med vsemi organizacijami, ki
med seboj sodelujejo in si delijo informacije. Podjetniški nivo je osredotočen na
komunikacijo in koordinacijo znotraj lastnega podjetja. Sistemski nivo skrbi za
komunikacijo in koordinacijo med aplikacijami. Aplikacijski nivo je osredotočen
na organizacijo aplikacij, da le-te zadoščajo merilom in zahtevam uporabnikov.
Nivo ogrodij skrbi za organizacijo in razvoj ogrodij, ki ga potrebujejo posamezne
aplikacije. Mikroarhitekturni nivo je zadolţen za razvoj programskih komponent,
ki rešujejo ponavljajoče se programske probleme. Nivo objektov in razredov pa
skrbi za razvoj objektov oz. razredov, ki jih je moţno ponovno uporabljati [7].
Integracijski vzorci in protivzorci Stran 36
Slika 3.1: Model SDLM [7]
3.2 Predloge vzorcev in protivzorcev
Predloge vzorcev oz. protivzorcev omogočajo, da odgovorimo na najpomembnejša
vprašanja o posameznem vzorcu oz. protivzorcu v jeziku vzorcev, katalogu vzorcev ali
sistemu vzorcev. Brez predloge ne moremo vedeti, ali je določena rešitev opravljena z
vzorcem, saj nimamo argumentov, ki bi kazali na to, saj brez določene strukture ne moremo
reči, kaj je vzorec in kaj ne. In to zato, ker ni velikih razlik med navadno tehnično razpravo in
literaturo vzorcev. Najbolj znane predloge vzorcev so [7, 8]:
Degenerirana oblika
Poda samo avtorjevo subjektivno mnenje.
Aleksandrova forma
Sestavljena je iz treh sekcij: imena, problema in rešitve.
Minimalna predloga
Podobno kot Aleksandrova forma je sestavljena iz imena (definira enotno
terminologijo), problema (definira kontekst ter uporabnost) in rešitve (opiše
predvideno rešitev problema).
Integracijski vzorci in protivzorci Stran 37
Induktivna mini predloga
Sestavljena je iz imena, konteksta, motivacij in rešitve.
Deduktivna mini predloga
Sestavljena je iz imena, problema, rešitve, moţnih koristi in posledic.
Predloga GoF – Gang of Four Pattern
Sestavljena je iz imena, klasifikacije, namena, alternativnih poimenovanj,
motivacije, uporabnosti, strukture, seznama udeleţencev, opisa sodelovanja
objektov, moţnih posledic, implementacije, vzorca kode, znane uporabe vzorca in
seznama sorodnih vzorcev.
Predloga sistema vzorcev
Sestavljena je iz imena, primera uporabe vzorca, konteksta, problema, rešitve,
alternativnih poimenovanj, strukture, dinamike objektov, rešenega primera uporabe
vzorca, variacije vzorca, moţnih posledic, implementacije, znane uporabe vzorca
in seznama podobnih vzorcev.
Predloga načrtovalskega vzorca CORBA
Sestavljena je iz imena, tipa, namena, alternativnih poimenovanj, seznama prvotnih
motivacij, uporabnosti, moţnih koristi, moţnih posledic, ozadja vzorca in seznama
podobnih vzorcev.
Prav tako obstajajo predloge protivzorcev:
Predloga psevdoprotivzorca
Podana sta samo ime in opis problema, je zelo neuporabna, saj je podan le opis
problema, ne pa tudi opis rešitve.
Mini predloga
Sestavljena je iz imena, opisa problema in opisa preoblikovane rešitve.
Celotna predloga protivzorca
Sestavljena je iz imena, alternativnih poimenovanj, uporabe v različnih nivojih
modela SDLM, imena preoblikovane rešitve, tipa preoblikovane rešitve, seznama
Integracijski vzorci in protivzorci Stran 38
glavnih vzrokov, seznama neuravnoteţenih vzrokov motivacij, ozadja vzorca,
osnovne oblike, seznama simptomov in posledic, seznama tipičnih vzrokov,
seznama znanih izjem, preoblikovanih rešitev, seznama variacij, raznih primerov,
seznama podobnih vzorcev in uporabnosti protivzorca pri ostalih nivojih oz. z
drugih perspektiv.
3.3 Razvojni protivzorci
Glavni cilj razvoja protivzorcev je opisati uporabne oblike preoblikovanja programske
opreme. S preoblikovanjem modificiramo programsko kodo z namenom izboljšanja
programske strukture, da kasneje laţje nadgrajujemo in vzdrţujemo sistem. Preoblikovanje je
zelo priporočljivo ravno pred optimizacijo sistema, saj optimizacije pogosto vsebujejo
kompromise glede programske strukture. Razvojni protivzorci uporabljajo različne formalne
in neformalne pristope preoblikovanja. V nadaljevanju so našteti najbolj znani razvojni
protivzorci in opisani njihovi problemi [7, 8]:
Mehurček (angl. The Blob)
Proceduralni stil snovanja vodi do objekta, ki ima veliko preveč odgovornosti,
medtem ko drugi objekti le vsebujejo določene podatke ali izvajajo enostavne
procese.
Neprekinjena zastarelost (angl. Continuous Obsolescence)
Tehnologija se spreminja tako hitro, da imajo razvijalci pogosto teţave z
vzdrţevanjem najnovejših verzij programske opreme.
Tok lave (angl. Lava Flow)
Pri tem protivzorcu t. i. mrtva koda in pozabljeni načrtovalski podatki ostajajo v
programu. Rešitev vsebuje konfiguracijske upravljavske procese, ki eliminirajo
mrtvo kodo in s preoblikovanjem poskušajo izboljšati kakovost.
Dvoumno stališče (angl. Ambiguous viewpoint)
Modeli objektno orientirane analize in načrtovanje so pogosto opisani brez točno
definiranega stališča, ki je predstavljeno z določenim modelom. Po privzetem je to
implementacijsko stališče, ki je najmanj uporabno.
Integracijski vzorci in protivzorci Stran 39
Funkcionalna razgradnja (angl. Functional decomposition)
Ta protivzorec je rezultat izkušenih neobjektno orientiranih programerjev, ki
poskušajo načrtovati in implementirati v objektno orientiranem jeziku.
Nočni duh (angl. Poltergeist)
Predstavljajo razrede, ki z zelo omejenimi vlogami in ţivljenjskimi cikli pogosto
zaganjajo procese za druge objekte. Rešitev je v ponovni dodelitvi odgovornosti za
dolgotrajnejše objekte.
Sidro (angl. Boat anchor)
To je del programske ali strojne opreme, ki za projekt nima večjega pomena in je
pogosto zelo drag.
Zlato kladivo (angl. Golden hammer)
Je znana tehnologija ali koncept, ki se dosti uporablja pri več programerskih
projektih. Rešitev je razširitev znanja razvijalcev z izobraţevanjem, da le-te
izpostavimo alternativnim tehnologijam in pristopom.
Slepa ulica (angl. Dead end)
Do t. i. slepe ulice pridemo, kadar ţelimo modificirati ponovno uporabljeno
komponento, katere ponudnik ne nudi več vzdrţevanja in podpore. Tako se delo
podpore in vzdrţevanja prenese na lastne razvijalce in podpornike.
Špagetasta koda (angl. Spaghetti code)
Struktura programa onemogoča razširitev in optimizacijo kode, pogosto so razredi
zelo veliki in imajo funkcionalnosti, ki bi morale biti v novoustvarjenem razredu.
Rešitev je v pogostem preoblikovanju kode.
Vhodna neumnost (angl. Input kludge)
Programska oprema, ki ne opravi enostavnega testa obnašanja sistema, kar se
pojavi, če so za vhode podatkov implementirani t. i. algoritmi AD HOC.
Hoja po minskem polju (angl. Walking through a minefield)
V izdanih programskih produktih najdemo številne hrošče. Poznavalci ocenjujejo,
da lahko na vrstico kode najdemo od dva do pet hroščev [7].
Integracijski vzorci in protivzorci Stran 40
Programiranje izreži in prilepi (angl. Cut-and-Paste programming)
Kodo ponovno uporabljamo z navadnim kopiranjem kode, kar privede do velikih
teţav pri vzdrţevanju. Rešitev je v alternativnih vrstah ponovne uporabe, testiranju
in dokumentaciji.
Gobarsko upravljanje (angl. Mushroom management)
Razvijalci ne smejo nikoli priti v stik s končnimi uporabniki sistema, ki ga
razvijajo, saj lahko razvijejo napačen sistem.
V Tabeli 3.2 imamo primer predloge protivzorca špagetaste kode, kjer so podane nekatere
točke predloge.
Integracijski vzorci in protivzorci Stran 41
Tabela 3.2: Primer predloge protivzorca špagetasta koda
Ime vzorca Špagetasta koda.
Najprimernejši nivo
modela SDLM
Aplikacija.
Rešitve preoblikovanja Preoblikovanje kode, čiščenje kode.
Tip rešitve preoblikovanja Programska.
Glavni vzroki Ignoranca, lenoba.
Neuravnotežene sile Upravljanje kompleksnosti, sprememb.
Ozadje Je klasika med programerji, še posebej med manj izkušenimi.
Splošna oblika Ima zelo malo programskih struktur (objektov, funkcij itd.).
Simptomi in posledice Minimalne povezave med objekti, redko za ponovno uporabo,
prednosti objektov so izgubljene (ni dedovanja,
polimorfizma).
Tipični vzroki Neizkušenost, ni mentorstva, ni načrtovanja, izoliranost
razvijalcev.
Znane izjeme Kadar so vmesniki skladni in je le implementacija
»špagetasta«.
Preoblikovane rešitve Najboljši način je seveda preprečevanje nastajanja takšne
kode, drugače pa s preoblikovanjem in čiščenjem kode
ohranimo skladno programsko strukturo, ki podpira razširitve.
Podobni vzorci Paraliza pri analizi (angl. Analysis Paralysis), tok lave (angl.
Lava Flow).
Primer (Zgoraj imamo
trivialni primer špagetaste
kode, spodaj pa rešitev
tega protivzorca.)
Primer špagetaste kode:
10 i = 0
20 i = i + 1
30 PRINT i; " squared = "; i * i
40 IF i >= 10 THEN GOTO 60
50 GOTO 20
60 PRINT "Program Completed."
70 END
Rešitev:
FOR i = 1 TO 10
PRINT i; " squared = "; i * i
NEXT i
PRINT "Program Completed."
END
Integracijski vzorci in protivzorci Stran 42
3.4 Arhitekturni protivzorci
Arhitekturni protivzorci so osredotočeni na sistemski in poslovni nivo aplikacij in
komponent. Strokovnjaki vedno znova ugotavljajo, kako velik pomen ima arhitektura pri
programskem razvoju. Programska arhitektura je nabor celotne sistemske arhitekture, ki
vsebuje vse načrtovalske in implementacijske vidike, tudi izbiro strojne opreme in
tehnologije. Programska arhitektura se razlikuje od programiranja na več načinov. Najbolj
očitna je razlika med glavnima akterjema, torej med arhitektom in programerjem. Arhitekt
vedno upošteva stroške svojih odločitev, medtem ko programerju to ni potrebno. Programska
arhitektura je osredotočena na tri vidike programskega načrtovanja, in sicer na funkcionalno
razdelitev programskih modulov, programske vmesnike med posameznimi moduli ter izbiro
in karakteristiko tehnologije, ki se uporablja za vmesniške povezave med programskimi
moduli. Če ţelimo uporabljati takšno arhitekturo, moramo imeti na voljo veliko več
razvijalcev in vzdrţevalcev oz. morajo biti le-ti zelo izkušeni. Učinkovito upravljanje s temi
elementi predstavlja velik izziv za arhitekte, prav tako sta zelo pomembna upravljanje in
komunikacija z ljudmi. Arhitekturni protivzorci, ki jih bomo omenili v podpoglavjih, so
osredotočeni na splošne probleme in napake pri kreaciji, implementaciji ali upravljanju
arhitekture. Nezmoţnost zagotavljanja interoperabilnosti in ponovne uporabe pri povezanih
sistemih je posledično vzrok za veliko frustracij udeleţencev projekta. To lahko rešimo prav s
planiranjem izboljšane podjetniške arhitekture, kar kasneje prinaša veliko prednosti v smislu
spreminjanja in razširitve sistema. Najbolj znani arhitekturni protivzorci so [7, 8]:
Avtogeneriran dovod (angl. Autogenerated stovepipe)
Ta vzorec se pojavi, kadar migriramo obstoječi sistem v porazdeljeno infrastrukturo,
bolj točno pri pretvorbi obstoječih v razširjene vmesnike. Obstoječi vmesniki so
običajno implementacijsko specifični in bi pri večjem porazdeljenem sistemu
povzročili odvisnosti od podsistemov, prav tako lokalne operacije vsebujejo veliko
predpostavk glede lokalnih argumentov, kot so razni naslovi ali dostop do podatkov
na disku. Problem rešimo tako, da pri načrtovanju razširitve vmesnikov obstoječe
programske opreme ponovno modeliramo vmesnike, najpogosteje se to naredi z
Integracijski vzorci in protivzorci Stran 43
večjim objektnim modelom, pri tem bi moral biti poudarek na interoperabilnosti med
številnimi podsistemi [7, 8].
Dovod do podjetja (angl. Stovepipe enterprise)
Glavna značilnost takšnega sistema je, da zavira spremembe. Razvidno je tudi to, da
so sistemi znotraj podjetja načrtovani neodvisno na vsakem niv