Darko Poberţnik INTEGRACIJSKI VZORCI IN PROTIVZORCI Diplomsko delo Maribor, september 2009

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: Študijski program: Smer: Mentor: Lektorica: Darko Poberţnik UN ŠP Računalništvo in informatika Informatika red. prof. dr. Marjan Heričko 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

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 Integracijski stili Sporočilni sistemi Sporočilni kanali Konstrukcija sporočila Usmerjanje sporočil Preoblikovanje sporočil Končna točka sporočil Upravljanje sistema Vzorci File Transfer, Shared Database, Remote Procedure Invocation, Messaging. Message, Message Channel, Pipes and Filters, Message Router, Message Translator, Message Endpoint. Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guarantied Delivery, Channel Adapter, Messaging Bridge, Message Bus. Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator. Content-based router, Message Filter, Dynamic Filter, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter- Gather, Routing Slip, Process Manager, Message Broker. Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model. Messaging Gateway, Message Mapper, Transactional client, Polling Consumer, Event-driven consumer, Competing consumers, Message dispatcher, Selective consumer, Durable subscriber, Idempotent Receiver, Service activator. 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 Ukazno sporočilo Dokumentno sporočilo Dogodkovno sporočilo Zahteva - odgovor Povratni naslov Korelacijski identifikator Sekvenca sporočil Zapadlost sporočila Pokazatelj formata Uporaba Pri proţenju funkcionalnosti druge aplikacije. Za zanesljiv prenos podatkovnih struktur med aplikacijami. Za zanesljivo asinhrono obvestilo o dogodku med aplikacijami. Kadar pošiljatelj potrebuje odgovor na poslano sporočilo. Kadar ţelimo, da se odgovor pošlje na drug naslov. Kadar moramo specificirati, na katero zahtevo se nanaša odgovor. Ko podatki presegajo velikost enega samega sporočila. Kadar je pomemben čas do odziva na sporočilo. Č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 leta 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. Eventdriven 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 Sporočilna vrata Distributer sporočil Transakcijski odjemalec Izbirajoči potrošnik Dogodkovno usmerjen potrošnik Konkurirajoči potrošniki Razpečevalec sporočil Selektiven potrošnik Obstojen naročnik Idempotenten prejemnik Aktivator storitev Uporaba Če ţelimo ločiti sporočilni del od ostalega dela aplikacije. Kadar ţelimo prenašati podatke med domenskimi objekti in sporočilno infrastrukturo, ne da so le-ti odvisni med sabo. Če ţelimo, da odjemalec nadzoruje transakcije s sporočilnim sistemom. Kadar ţelimo, da potrošnik izbira, kdaj bo prejel sporočilo. Sporočilo se preda prejemniku, ko to prispe do kanala. Kadar ţelimo, da potrošniki procesirajo več sporočil hkrati. Ko moramo distribuirati sporočila različnim prejemnikom. Kadar ţelimo, da potrošnik izbira, katera sporočila bo sprejel. Če ţelimo, da se sporočila shranijo, tudi ko prejemnik ni aktiven, in le-te prejme, ko spet postane aktiven. 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. Č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 Spremljanje in kontroling Opazovanje in analiza prometa sporočil Testiranje in razhroščevanje Vzorci Kontrolno vodilo (angl. Control bus), ovinek (angl. Detour). Zgodovina sporočil (angl. Message history), shranjevanje sporočil (angl. Message store), pameten namestnik (angl. Smart Proxy). 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 Ime vzorca Najprimernejši modela SDLM Tabela 3.2: Primer predloge protivzorca špagetasta koda Rešitve preoblikovanja nivo Špagetasta koda. Aplikacija. Tip rešitve preoblikovanja Programska. Glavni vzroki Neuravnotežene sile Ozadje Splošna oblika Simptomi in posledice Tipični vzroki Preoblikovanje kode, čiščenje kode. Ignoranca, lenoba. Upravljanje kompleksnosti, sprememb. Je klasika med programerji, še posebej med manj izkušenimi. Ima zelo malo programskih struktur (objektov, funkcij itd.). Minimalne povezave med objekti, redko za ponovno uporabo, prednosti objektov so izgubljene (ni dedovanja, polimorfizma). Neizkušenost, ni mentorstva, ni načrtovanja, izoliranost razvijalcev. Znane izjeme Kadar so vmesniki skladni in je le implementacija»špagetasta«. Preoblikovane rešitve Podobni vzorci Primer (Zgoraj imamo trivialni primer špagetaste kode, spodaj pa rešitev tega protivzorca.) 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. Paraliza pri analizi (angl. Analysis Paralysis), tok lave (angl. Lava Flow). 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 nivoju. Pomanjkanje skupnih točk zavira večjo interoperabilnost med sistemi, preprečuje ponovno uporabo in s tem povečuje stroške, ki jih imamo z vzdrţevanjem in kasneje z raznimi spremembami oz. razširitvami, ki jih ţelimo opraviti na sistemu. Preoblikovana rešitev opiše, kako izločiti vse podsisteme in komponente, da izboljšamo strukturo celotnega sistema [7, 8]. Zmešnjava (angl. Jumble) Pojavi se, ko se prepletajo horizontalni in vertikalni modelni elementi, kar se kaţe v nestabilni arhitekturi. Vertikalni modelni elementi so odvisni od posameznih aplikacij in specifičnih implementacij programov. Horizontalni pa so tisti, ki so običajni med aplikacijami in specifičnimi implementacijami. Po privzetem so ti elementi med seboj zmešani s strani razvijalcev in arhitektov, takšen način pa limitira robustnost ter zmoţnost ponovne uporabe dane arhitekture in komponent sistema. Problem rešimo tako, da identificiramo horizontalne elemente in jih delegiramo v posebno arhitekturno plast. Kasneje lahko dodamo vertikalne elemente kot razširitve za specializirane funkcionalnosti in povečanje zmogljivosti [7, 8]. Dovod do sistema (angl. Stovepipe system) Je nekakšna zapuščena programska oprema z nezaţelenimi kvalitetami. Glavna značilnost tega protivzorca je pomanjkanje koordinacije in slabo planiranje med vsemi sistemi znotraj organizacije. Glavni problem je pomanjkanje abstrakcije podsistema, saj so le-ti integrirani preveč specifično in uporabljajo raznolike integracijske strategije in mehanizme. Vsi podsistemi so integrirani na način točka do točke, kar pomeni, da je vsak podsistem povezan z vsakim, kot je razvidno na Sliki 3.2. Vidimo, da nam število povezav z dodajanjem podsistemov potenčno raste. Poleg tega je implementacija zelo odvisna od sistemske konfiguracije, podrobnosti namestitve in stanja celotnega sistema. Takšnemu sistemu se izognemo tako, da

Integracijski vzorci in protivzorci Stran 44 vpeljemo komponentno arhitekturo, ki omogoča večjo fleksibilnost glede zamenjave posameznih modulov programske opreme [7, 8]. Slika 3.2: Protivzorec dovod do sistema Zavaruj svoje premoženje (angl. Cover your assets) Procesi dokumentno vodene programske opreme pogosto podajo nekoristne zahteve in specifikacije, saj se avtorji le-teh izogibajo pomembnim odločitvam, zato postanejo dokumenti zelo obseţni in za bralca kot nekakšna uganka, saj ni pomembnih odločitev in ni vzpostavljenih nobenih prioritet. Tako so razvijalci prepuščeni sami sebi brez uporabnih navodil o tem, kaj implementirati in kaj je prednostna naloga. Rešitev lahko najdemo v podrobnem arhitekturnem načrtu, ki opiše abstrakcije informacijskih sistemov, ki olajšajo komunikacijo o zahtevah in tehničnih načrtih med uporabniki in razvijalci. Ta majhen nabor diagramov in tabel povzame operativno, tehnično in sistemsko arhitekturo trenutnega in bodočega sistema in tako opiše tudi nameravane razširitve sistema [7, 8]. Zunanja odvisnost (angl. Vendor lock-in) Pojavi se pri sistemih, ki so zelo odvisni od lastniških arhitektur. Sistem sprejme tehnologijo nekega produkta in postane popolnoma odvisen od njegove implementacije. Ko lastniki tujega adaptiranega produkta le-tega nadgradijo, se velikokrat pojavi problem pri potrebnih spremembah in interoperabilnosti njihovega produkta, poleg tega pa je potrebno neprekinjeno vzdrţevanje, ki omogoča, da

Integracijski vzorci in protivzorci Stran 45 sistem deluje pravilno. Prav tako nastanejo teţave pri raznih razširitvah produkta, od katerega smo odvisni, saj se običajno zamuja s predvidenimi verzijami in se tako ne moremo povsem zanesti na določene datume. To odvisnost rešimo z izolacijsko plastjo. Uporaba arhitekturnih izolacijskih plasti zagotavlja neodvisnost od prodajalčevih specifičnih rešitev. Ta plast loči programske pakete in tehnologije, kot je prikazano na Sliki 3.3, kjer je med lastnim aplikacijskim delom in zunanjim odvisnim delom izolacijska plast [7, 8]. Slika 3.3: Model rešitve protivzorca zunanje odvisnosti Nesmiselnost standardov (angl. Wolf ticket) Predstavlja produkt, ki podpira odprtost in skladnost s standardi, ki nimajo velikega pomena za projekt. Največja teţava je, da tehnologi predpostavljajo, da odprtost prinaša velike prednosti. V realnosti so standardi pomembni predvsem za prepoznavnost znamke produkta, ne pa toliko za uporabnike programov. Tehnološke vrzeli povzročajo pomanjkljivosti v specifikacijah, razpoloţljivosti produkta, skladnosti, interoperabilnosti, robustnosti in funkcionalnosti. Zapolnitev teh vrzeli je potrebna za končno dostavo produkta [7, 8]. Arhitektura po implikaciji (angl. Arcitecture by implication) Glavna značilnost danega protivzorca je pomanjkanje specifikacij arhitekture sistema med razvojem. Običajno imajo odgovorni arhitekti ţe izkušnje s konstrukcijo predhodnih sistemov in zato predpostavljajo, da dokumentacija ni potrebna. Ta prevelika samozavest zelo povečuje tveganje na ključnih področjih, ki vplivajo na sistem. Rešitev tega problema vsebuje organiziran pristop do sistemske

Integracijski vzorci in protivzorci Stran 46 arhitekturne definicije in se zanaša na več pogledov na sam sistem. Vsak pogled je zmodeliran s perspektive delničarja oz. lastnika podjetja, ki je lahko resničen ali izmišljen, individualen ali obstaja kot druţba [7, 8]. Topla telesa (angl. Warm bodies) Na programskem projektu lahko sodeluje veliko število programerjev z različnimi sposobnostmi in stopnjami produktivnosti. Mnogi sodelavci pa sodelujejo pri večjih projektih le zato, da zadostijo merilom števila zaposlenih. K uspešnosti projektov pripomorejo predvsem sposobni programerji, nekateri programerji so lahko celo tako produktivni, da so pravi junaki med sodelavci. A takšnih je zelo malo, le eden od dvajsetih naključno izbranih ima takšen talent [7]. Idealno število sodelujočih pri projektu bi naj bilo štiri in idealen čas trajanja projekta štiri mesece [7]. Projektne skupine, ki obsegajo več kot pet ljudi, se običajno soočajo s teţavami s koordinacijo skupine. Člani skupine imajo teţave z odločitvami in vzdrţevanjem skupne vizije. Glavna motivacija za vse sodelujoče pa je še vedno bliţnji rok dokončanja projekta. Za uspešno dokončanje projekta torej ni pomembna velikost skupine. Izkazalo se je, da manjše skupine s poudarjeno odgovornostjo posameznikov veliko laţje uspešno zaključijo projekt [6, 7]. Načrt po odboru (angl. Design by comittee) Ta klasični protivzorec vsebuje preveč kompleksno arhitekturo, ki ji primanjkuje skladnosti. Arhitektura je kompleksna zaradi velike mnoţice ljudi, ki so prispevali svoj del k arhitekturi, saj ima vsak drugačen pogled na stvari, in rezultat vseh teh mnenj je obseţnost in dvoumnost modela, ki ga ne bi bilo mogoče stestirati v celoti. Jasno določene arhitekturne vloge in izboljšano omogočanje procesov lahko privede do tega, da sestanki postanejo zelo neproduktivni. Rešitev celotne zmešnjave je, da ponovno skličemo sejo. V večini sejnih sob ure niso nameščene, čeprav je časovna ozaveščenost za napredek sestanka ključna. Udeleţenci seje bi naj komentirali kratko in jedrnato. Posamezni komentarji naj ne bi presegali 25 besed. Cilji sestanka, predviden urnik in ura bi naj bili na vidnem mestu ves čas sestanka. Udeleţencem sestanka moramo nedvoumno povedati, zakaj so na sestanku in kaj bodo tam izvedeli. Zelo pomembno je tudi, da med sestankom jasno določimo vloge, kot so lastnik, menedţer, direktor, arhitekt, razvijalec, tester, vzdrţevalec [7, 8].

Integracijski vzorci in protivzorci Stran 47 Švicarski vojaški nož (angl. Swiss army knife) To je pretirano kompleksen vmesnik, saj načrtovalec ţeli razredom omogočiti, da bodo uporabljeni za različne namene. Zato doda veliko število abstraktnih metod vmesniku v poskusu, da zadosti vsem danim zahtevam. V realnosti se pojavi tudi do tisoč raznih metod za posamezen razred. Takšni protivzorci nastanejo predvsem zaradi prodajalcev, ki obljubljajo nerealne produkte, ki morajo biti uporabni v najrazličnejših aplikacijah [7, 8]. Odkrivanje tople vode (angl. Reinvent the wheel) Zelo veliko pomanjkanje prenosa tehnologij iz posameznih projektov nas privede do tega, da vedno znova rešujemo iste probleme. Večina informacijskih sistemov se gradi od začetka, čeprav obstaja veliko sistemov s prekrivajočo se funkcionalnostjo. To pa zelo omejuje ponovno uporabo programske opreme. Enostavnejša rešitev je, da izvlečemo vzorce iz obstoječe arhitekture (angl. Architecture mining) in tako dobimo objektno orientirano arhitekturo, ki je robustna, neodvisna od aplikacij ter zmoţna razširitve in ponovne uporabe [7, 8]. Stari dobri vojvoda iz Yorka (angl. The great old Duke of York) Da bi dosegli enakopravnost ljudi v procesih razvoja programske opreme, redke talente ljudi pogosto spregledamo, kar seveda škodi projektu. Programski talent ni enak talentu definiranja abstrakcij. Pri razvoju programske opreme obstajata dve vrsti ljudi: abstrakcionisti in njim nasprotni implementatorji [7]. Prvih je veliko manj, zato zaradi enakopravnosti ljudi v skupini pri odločanju le-te običajno manj upoštevamo, čeprav je upravljanje s kompleksnostjo procesa ključnega pomena. Posledica tega nepravilnega načrtovanja privede do prevelike kompleksnosti sistema, kar še oteţuje razvoj, spremembe, razširitve, dokumentiranje in testiranje. Rešitev je v različnih vlogah organizacije skupine. Abstrakcioniste z veliko izkušnjami določimo za arhitekte, za razvijalce komponent pa izkušene programerje, ki pripravijo infrastrukturo in komponente, ki se lahko ponovno uporabijo. Aplikacijski razvijalci so ostali programerji, ki integrirajo omenjene komponente in jih poveţejo v delujoče sisteme. Ti uporabljajo predvsem skriptne jezike, kot so VisualBasic, JavaScript, PHP, Perl [7, 8].

Integracijski vzorci in protivzorci Stran 48 3.5 Protivzorci upravljanja projektov programske opreme V modernem inţenirskem poklicu več kot polovica sluţb vključuje komunikacijo med ljudmi in reševanje njihovih problemov. Upravljalski protivzorci identificirajo glavne scenarije, kjer ti problemi destruktivno vplivajo na procese razvoja programske opreme. Tabela 3.3 vsebuje seznam upravljalskih protivzorcev s kratkimi opisi problemov [7, 8].

Integracijski vzorci in protivzorci Stran 49 Ime protivzorca Paraliza analize (angl. Analysis Paralysis) Smrt zaradi planiranja (angl. Death by planning) Strah pred uspehom (angl. Fear of success) Težavni ljudje (angl. Corncobs) Intelektualno nasilje (angl. Intellectual Violence) Iracionalno upravljanje (angl. Irrational management) Dim in ogledala (angl. Smoke and mirrors) Napačno upravljanje projekta (angl. Project mismanagement) Požarna vaja (angl. Fire drill) Spor (angl. Feud) E-pošta je nevarna (angl. Email is dangerous) Opis Tabela 3.3: Seznam upravljalskih protivzorcev Ţelja po popolnosti pri analizi pripelje do blokade projekta. Rešitev je v opisu inkrementalnih oz. iterativnih procesov razvoja brez podrobnosti analize. Pretirano planiranje vodi do zapletenih urnikov in povzroča probleme med projektom. Rešitev je v planiranju razumnih razvojnih procesov, ki vključujejo znana dejstva. Tik pred uspešno zaključenim projektom nekatere ljudi začnejo pretirano skrbeti stvari, ki bi lahko šle narobe. Na dan pridejo profesionalne negotovosti. Rešitev je v razglasitvi uspeha projekta. Problem so teţavni ljudje, ki so prevladujoči v procesih razvoja programske opreme. Rešimo ga tako, da naslovimo njihov dnevni red z različnimi taktičnimi ter strategično-organizacijskimi akcijami. Pojavi se, kadar nekdo, ki razume neko teorijo ali tehnologijo, druge ustrahuje s tem znanjem. Rešitev je v uvedbi mentorstva in spodbujanju, da se znanje prenaša. Neodločnost in slabe upravljalne navade vodijo do nenehnih razvojnih kriz. Vodjam projekta razloţimo, kako se naj racionalno odločajo. Prav tako vpeljemo tehnike za izboljšavo projekta in nadzor nad vodjami projekta. Demonstracijski sistemi so pomembna orodja prodaje, a pogosto stranke te sisteme interpretirajo kot končne sisteme in upravitelji projekta pogosto naredijo obveze, za katere podjetja nimajo zmoţnosti. Včasih je bolje, da omejimo pričakovanja stranke, saj je tako ob koncu projekta pozitivno presenečena. Nepazljivost pri upravljanju projekta lahko privede do napačne usmerjenosti razvojnih procesov. Rešitev je v uvedbi primernega spremljanja in nadzora. Projekt se ţe začne, medtem ko razvijalci zavlačujejo z načrtovanjem in razvojem, saj ni nobenega pritiska vodilnih. Nato sledi ugotovitev, da bo potrebno hitro pokazati rezultate projekta. Osebnostni spori med vodilnimi pri projektu lahko močno vplivajo na delovno okolje. Konflikt lahko običajno rešimo z enostavnim prijateljskim srečanjem, ki ne vključuje dela. E-pošta je pomemben medij za komunikacijo projektnih upraviteljev, vendar določene teme za komunikacijo z e-pošto niso primerne. Teţavo rešimo s previdno uporabo tega medija. E-pošte ne uporabljamo za naslednje teme: kritike, soočanje, osebne podatke, politično neprimerne teme itd.

Integracijski vzorci in protivzorci Stran 50 3.6 Integracijski protivzorci Protivzorce, omenjene v prejšnjih poglavjih, ne srečujemo samo pri integraciji sistemov, ampak pri vsakem programskem projektu. Če se uporabe integracijskih vzorcev loti ekipa manj izkušenih programerjev, to običajno pripelje do napačne uporabe in tako nastanejo negativne posledice oz. protivzorci. V tem poglavju bomo opisali tiste, ki se pojavljajo predvsem pri integraciji sistemov in so koristni za uspeh integracijskih projektov. Čeprav vsi opisani protivzorci niso neposredno povezani s stili integracije sistemov, lahko njihovo poznavanje bistveno poveča uspešnost integracije tako znotraj kot izven organizacije. V Tabeli 3.4 so našteti omenjeni protivzorci in dodani kratki opisi [9, 10].

Integracijski vzorci in protivzorci Stran 51 Tabela 3.4: Integracijski protivzorci Imena protivzorcev Neredno posredovanje kode Pokvarjena verzija Minimalna povratna informacija Vsiljena povratna informacija Počasni stroj Razširjena verzija Posredovanje kode pred odhodom Neprekinjena ignoranca Predvidene izdelave verzij Delovanje na lastnem računalniku Delovanje na lokalnem okolju Ozkomiselno okolje Onesnaženo okolje Opis Izvorna koda ni pravočasno oddana v repozitorij zaradi prevelikega obsega dodeljenih opravil programerjem. Verzija ostane pokvarjena dalj časa, kar onemogoča preverjanje delujoče kode. Sodelujoči pri projektu se odločijo, da informacij o statusu verzij ostalim sodelujočim pri projektu ne bodo posredovali, zato ostali večkrat ne vedo, da obstaja pokvarjena verzija. Projektne sodelavce lahko obremeni prekomerno število elektronskih sporočil, zato jih namenoma spregledajo. Delovna postaja z omejeno zmogljivostjo se uporablja za izdelavo verzij, kar privede do dolgotrajnega postopka. V proces izdelave verzij je dodanih preveliko stvari, kar spet podaljša čas izdelave verzije. Razvijalci večinoma posredujejo kodo v repozitorij, preden gredo domov, in tako velikokrat nastanejo napake v verziji. Če je določena verzija delujoča, vsi predvidevajo, da predviden produkt deluje pravilno, a v resnici ni tako. Verzija se poganja občasno (dnevno, tedensko), ne ob vsaki spremembi. Verzija deluje na lokalnem računalniku, a kasneje se ugotovi, da ista verzija v drugih okoljih ne deluje. Nanaša se na prejšnji protivzorec, le da je tu specifičen problem z integriranim razvojnim okoljem (IDE Integrated Development Environment). Predvidevanje, da bo zaradi delovanja verzije v določenem okolju le-ta delovala v vseh ostalih okoljih. Inkrementalna verzija je narejena, da bi prihranili čas, vendar obstaja napaka v eni izmed prejšnjih verzij.

Integracijski vzorci in protivzorci Stran 52 3.6.1 Neredno posredovanje kode (angl. Infrequent check in) Glavni problem tega protivzorca je, da so posamezna opravila prevelika oz. trajajo predolgo časa, zato je tudi dodajanje kode v skupen repozitorij tako neredno. Večina razvijalcev predvideva, da je potrebno dokončati celotno opravilo, preden se odloči za dodajanje sprememb v repozitorij. Ena od predpostavk neprekinjene integracije je hitra povratna informacija projektni skupini o stanju kode v razvojnem procesu. Z nerednim posredovanjem kode dejansko zavlačujemo s projektom; dlje kot obdrţimo kodo zase, večji trud je potreben za kasnejše spremembe zaradi neţelenih posledic, kot je hkratno spreminjanje enakega dela kode dveh različnih razvijalcev, kar običajno privede do konflikta v repozitoriju [9]. Priporočljivo je, da se v repozitorij dodajajo spremembe vsaj enkrat na dan, po moţnosti večkrat na dan. Razvijalci se pritoţujejo, da je zelo teţko pogosto dodajati spremembe, če so zaposleni s spreminjanjem tako velikega števila datotek, zato je idealna rešitev naslednja: posamezna opravila razčlenimo na manjša podopravila in kasneje pogosteje posredujemo manjše kose kode, namesto da na koncu dodamo eno veliko spremembo v celotnem sistemu [9]. 3.6.2 Pokvarjena verzija (angl. Broken build) Dlje kot ostane napaka v verziji programske opreme in le-ta ni popravljena, teţje jo je popraviti, in to zato, ker obstaja vedno več datotek, sprememb in odvisnosti, ki oteţujejo izolacijo napake. Zaradi tega bi naj v primeru ugotovitve napake bila prva naloga projekta to napako odpraviti. Pokvarjene verzije nimajo samo negativne plati, saj se lahko iz njih naučimo, kdaj je s programsko opremo kaj narobe. Lahko pa nastane resen problem, če se te napake pojavljajo pogosto ali če določena napaka ni odpravljena dalj časa. Ena od zelo uporabnih tehnik preprečitve nedelujoče verzije je t. i. zaganjanje privatne verzije, preden dodamo kodo v repozitorij. Ta tehnika je sestavljena iz petih korakov: 1. prenos najnovejše kode iz repozitorija, 2. lokalno dodajanje spremenjene kode,

Integracijski vzorci in protivzorci Stran 53 3. posodobitev svoje kode iz repozitorija, da bodo dodane spremembe drugih, 4. zaganjanje lokalne verzije, 5. ko je verzija brez napak, nastopi dodajanje sprememb v repozitorij. Na Sliki 3.4 imamo prikazane posamezne korake [8]. Slika 3.4: Koraki tehnike preprečevanja pokvarjene verzije [9] 3.6.3 Minimalna povratna informacija (angl. Minimal feedback) V projektni skupini se izogibamo prepogostemu pošiljanju obvestil prek elektronske pošte. Vendar se po drugi strani ne moremo odzvati, če ne dobimo informacije o tem, da je nekaj narobe. Povratna informacija je zato pri integraciji ključnega pomena, vendar mora ta informacija biti učinkovita. Če ţelimo izboljšati mehanizme za obveščanje, lahko uporabimo vizualne ali zvočne naprave (v primeru, da bi bila napaka v sistemu, bi lahko gorela zelena luč ali pa bi se oddajal kakšen zvočni signal). Na ustvarjalen način lahko dodamo različne mehanizme povratnih informacij (npr. sporočilo se pošlje na telefon), da sodelujoči pri projektu ne namerno spregledajo statusa verzije [9].

Integracijski vzorci in protivzorci Stran 54 3.6.4 Vsiljena povratna informacija (angl. Spam feedback) V nasprotju z minimalno povratno informacijo ima ta protivzorec ravno obratni problem. Tukaj je informacij o statusu projekta namreč preveč oz. so poslane osebam, ki za to niso pristojne in jim je to sporočilo dejansko vsiljeno (angl. spam). Prav tako ni priporočljivo, da pretiravamo s pošiljanjem obvestil za vsak majhen problem, saj bi v takem primeru usluţbenci sporočila namerno spregledali in se kasneje, ko bi bila ta sporočila zelo pomembna, nanje ne bi odzvali. Na primeru vidimo konfiguracijsko datoteko, ki vsebuje parametre za učinkovito pošiljanje notifikacij, saj pošilja vsa sporočila samo tehničnemu vodstvu. V primeru, da ima verzija napako, se sporočilo pošlje tudi vodji projekta. Prav tako so o tem obveščeni vsi razvijalci, ki so v zadnjem času dodali kodo v repozitorij [9]. <project name="brewery">... <publishers> <htmlemail css="./webapps/cruisecontrol/css/cruisecontrol.css" mailhost="localhost" xsldir="./webapps/cruisecontrol/xsl" returnaddress="cruisecontrol@localhost" buildresultsurl="http://localhost:8080" mailport="25" defaultsuffix="@localhost" spamwhilebroken="false"> <always address="techlead@localhost"/> <failure address="pm@localhost" reportwhenfixed="true"/> </htmlemail> </publishers>... Primer 3.1: Konfiguracijska datoteka za nastavljanje naslovnikov notifikacij 3.6.5 Počasni stroj (angl. Slow machine) Predstavljajmo si, da je za prevajanje kode določenega projekta potrebna ena ura ali celo več. Lahko se tudi zgodi, da prevajanje vedno ne uspe, in sicer zaradi napak v projektu. V tem primeru traja takšno prevajanje v strojni jezik tudi cel dan. Zato je za takšno pomembno in časovno zelo obseţno nalogo potrebno uporabiti računalnik, ki ima veliko zmogljivost (hitri procesor, velik pomnilnik in veliko prostora na disku), saj to zelo pripomore k povečanju hitrosti prevajanja kode. Čas, ki ga prihranimo zaradi hitrejšega prevajanja, nam omogoča, da hitreje pridemo do povratnih informacij o sistemu, hitreje

Integracijski vzorci in protivzorci Stran 55 popravimo napake in nenazadnje hitreje napredujemo do naslednjega opravila v razvoju, kar nam skrajša čas celotnega projekta [9]. 3.6.6 Razširjena verzija (angl. Bloated build) Nekatere razvojne skupine postanejo navdušene nad vsemi procesi, ki so lahko dodani avtomatski verziji, pri tem pa pozabijo, da je potreben dodaten čas, da se vsi ti procesi izvedejo. Če se zgodi, da je proces prevajanja kode neupravičeno časovno potraten, kljub temu da so časovne izboljšave ţe izvedene (uporaba visoko zmogljivega računalnika, časovna optimizacija zagona testov), je potrebno uvesti posamezne veje prevajanja. Namen teh vej je, da se nesinhrono izvršujejo dolgotrajajoči procesi, in ko razvijalci posredujejo kodo v repozitorij, ne čakajo tako dolgo na povratno informacijo. Npr. če celotno ustvarjanje verzije traja deset minut, lahko ustvarimo posebno vejo za dolgotrajajoče procese in se za razvijalca, ki je posredoval kodo v repozitorij, ustvari manjša verzija, ki vsebuje le manj časa trajajoče procese (prevajanje, hitre teste enot), in tako na hitro dobi povratne informacije o statusu verzije. Zatem se izvede še omenjena veja za dolgotrajnejše procese (daljši testi, inšpekcije programa, nalaganje na streţnik) [9]. 3.6.7 Posredovanje kode pred odhodom (angl. Bottleneck commits) Ta protivzorec je dejansko variacija vzorca nerednega posredovanja kode. Predvidevamo, da kodo posredujemo vsaj enkrat na dan. Problem nastane, ker večina razvijalcev doda kodo ob istem času, običajno ob koncu dneva, posledično je to tudi čas, ko nastane največ pokvarjenih verzij. Rešitev je enostavna: kodo je potrebno posredovati čim pogosteje. Najbolje je, da si neko večje opravilo razdelimo na manjše dele, ki jih nato posamezno posredujemo v repozitorij. Tako kasneje laţje rešimo napako, če se ta pojavi, saj imamo manjše dele kode in jo je veliko laţje poiskati ter odpraviti [10].

Integracijski vzorci in protivzorci Stran 56 3.6.8 Neprekinjena ignoranca (angl. Continuous ignorance) Ko se pojavlja ena uspešna verzija za drugo, lahko postanejo razvijalci preveč samozavestni. Niti pomislijo ne na to, da se bi to lahko dogajalo zaradi dejstva, da kodo premalo preverjajo. Manj kot se preverja verzija programske opreme, manj podatkov imamo o tem, ali programska oprema dejansko deluje, kot je bilo pričakovano, ali ne. To rešimo tako, da vključimo dodatne procese, kot so integracijo podatkovne baze, razvojni testi (testi enot, komponent, funkcionalnosti itd.), avtomatizirane inšpekcije kode ali inštalacijske distribucije. Pri tem je potrebno spet upoštevati časovno komponento, kajti več procesov kot bomo vključili v izdelavo verzije, dlje časa bo trajalo, da se to izvede, zato je mogoče priporočljivo, da se uvede posebna veja za dolgotrajajoče procese (Glej poglavje 3.6.6.) [10]. 3.6.9 Predvidene izdelave verzij (angl. Scheduled builds) Bistvo neprekinjene integracije je, da se koda integrira pogosto, kar pomeni vsakič, ko se spremeni. Tako tudi laţje odkrijemo napako v sistemu. Problem nastane, če imamo določen urnik izdelave verzije (npr. vsak dan ob dvanajstih), saj se lahko zgodi, da ni bilo od zadnje izdelave nobene spremembe ali pa, da je bilo toliko sprememb, da bo vsak odkrit problem teţko rešiti. To najlaţje rešimo z uvedbo izdelave verzij ob vsaki spremembi. Torej, če se v repozitorij dodajo spremembe, se vsakič izdela nova verzija in tako laţje dobimo povratno informacijo o vsaki spremembi posebej. Obstajajo tudi primeri, ko je urnik izvajanja zelo učinkovit, npr. zaganjanje obremenitvenih in zmogljivostnih testov čez noč zaradi dolgega trajanja takšnih procesov [10]. 3.6.10 Delovanje na lastnem računalniku (angl. Works on my machine) Zgodi se, da razvijalec v repozitorij doda spremembo kode, ki deluje na lokalnem računalniku, kot je pričakoval razvijalec. Nekoliko kasneje drug razvijalec vzame omenjeno kodo iz repozitorija in jo naloţi v svoje okolje ter ugotovi, da ne deluje.

Integracijski vzorci in protivzorci Stran 57 Za tak pojav obstaja več razlogov, glavni je običajno ta, da je razvijalec pozabil dodati datoteko ali pa določeni konfiguracijski parametri v drugem okolju niso enaki kot v delujočem. Teţava se običajno reši z integracijskim računalnikom za nalaganje, ki naloţi verzijo za vsako spremembo, ki se pojavi v repozitoriju [10]. 3.6.11 Delovanje v lokalnem okolju (angl. IDE-only build) Z uporabo integriranega razvojnega okolja (IDE Integrated Development Environment) za pisanje kode ali z oblikovanjem t. i. skript»build«(angl. Build script) za prevajanje kode ni nič narobe. A če so procesi prevajanja tako tesno prepleteni z razvojnim okoljem, da brez namestitve tega okolja ne moremo prevesti verzije, nastopi velika teţava, saj se zelo redko zgodi, da bo le-to nameščeno v produkcijskem okolju. Prav tako bi odvisnost od razvojnega okolja povečala verjetnost za razne konfiguracijske probleme, ki bi jih zelo teţko odkrili. Za rešitev te teţave ustvarimo skripto Build, ki jo še vedno lahko uporabljamo v lastnem integriranem razvojnem okolju. Ista skripta se lahko uporablja za integracijsko prevajanje kode, ki je neodvisno od okolja [10]. 3.6.12 Ozkomiselno okolje (angl. Myopic environment) Če ţelimo, da verzija deluje v različnih okoljih, moramo odstraniti vsako predvidevanje, ki je lahko vezano na okolje. Temu dodamo še odstranjevanje okolju specifičnih omejitev in jih nadomestimo z nastavitvenimi datotekami (Npr. če ţelimo program zaganjati tako v platformi Windows kot v platformi Linux, odstranimo vsako referenco na C: direktorij, saj Linux drugače naslavlja diskovne pogone.). Da rešimo ta problem, je potrebno zamenjati vse okolju specifične reference s parametri (parametri povezave z bazo, ime streţnika, avtentikacija itd.), ki se nastavljajo v času nalaganja verzije [10].

Integracijski vzorci in protivzorci Stran 58 3.6.13 Onesnaženo okolje (angl. Polluted environment) Še bolj frustrirajoča kot zaganjanje nedelujočih verzij je ugotovitev, da verzija ne deluje zaradi raznih»umetnij«, ki so bile dodane v eni izmed prejšnjih verziji (datoteke WAR Web Application Archive, datoteke JAR Java Archive, datoteke EAR Enterprise Archive in posodobitve podatkovne baze). Zelo pomembno je torej, da postavimo okolje v stanje, kot bi bilo pred vsakimi relevantnimi aktivnostmi nalaganja verzij. Enostavna rešitev je brisanje prejšnjih direktorijev za shranjevanje zgodovine, distribucij, starih datotek razredov, stare dodane datoteke WAR, EAR oz. JAR in datotek za poročila. Lahko postavimo podatkovno bazo v primerno stanje (zbrišemo celotno bazo ter jo ponovno oblikujemo), ponovno inicializiramo pot do razredov (angl. Classpath). Priporočljiva je tudi uporaba spremenljivk za okolje [10].

Integracijski vzorci in protivzorci Stran 59 4. PRAKTIČNI DEL V praktičnem delu diplomske naloge si bomo ogledali nekaj uporabljenih integracijskih vzorcev in protivzorcev pri integraciji spletne trgovine AspDotNetStoreFront in ERP-sistema Pantheon podjetja Datalab. Pri tem se uporablja spletna storitev spletne trgovine in podatkovna baza sistema ERP. Celotna rešitev za avtomatsko sinhronizacijo podatkov med tema dvema aplikacijama se imenuje ApplicationBridge. Na Sliki 4.1 je modelirana njena arhitektura. Rešitev je sestavljena iz dveh aplikacij, ki prenašata podatke v obeh smereh: ECommUpdater prenaša spremembe iz sistema ERP na podatkovno bazo spletne trgovine, ErpUpdater prenaša spremembe iz spletne trgovine na podatkovno bazo sistema ERP. Obe aplikaciji delujeta v ozadju in sta za navadnega uporabnika nevidni. Kot je vidno na modelu, se za komunikacijo s spletno trgovino uporablja vmesnik spletnih storitev oz. WSI (angl. Web Service Interface) [11, 12]. Slika 4.1: Arhitektura sistema ApplicationBridge Program prenaša iz sistema ERP v spletno trgovino sledeče podatke: artikle (ident, ime, opis artikla, proizvajalčeva šifra artikla, slike artikla),

Integracijski vzorci in protivzorci Stran 60 količino zalog artiklov v skladišču, proizvajalce artiklov, kategorije in podkategorije artiklov, kupce z lastnim uporabniškim imenom in geslom, razne pogodbene cenike za partnerje (cene v sistemu ERP se ujemajo s cenami v spletni trgovini), stanje internetnih naročil (pripravljeno, poslano), za partnerje (kupce, ki imajo partnerske cenike) se dodatno prenašajo finančne obveznosti (nezapadle, zapadle), seznam naročil Pantheon stanje, postavke (naročene, dostavljene, nedostavljene), predviden čas dostave. V drugo smer, iz spletne trgovine v sistem ERP pa prenaša sledeče podatke: podatke kupcev, ki se na novo prijavijo v spletno trgovino (ime, priimek, podjetje, telefon, naslov, davčna številka idr.), na svetovnem spletu spremenjene podatke kupcev (velja samo za tiste, ki so se prijavili preko svetovnega spleta), naročila iz spletne trgovine (naročeni artikli, količine, cene, naročnik (oseba), podjetje, naslov za dostavo, naslov za izstavitev računa, način dostave, opomba). 4.1 Uporabljeni vzorci integracije Analizirali in predstavili bomo nekaj uporabljenih vzorcev pri omenjeni integraciji ter opisali njihovo uporabo. V Tabeli 4.1 so našteti določeni uporabljeni vzorci v omenjenih aplikacijah, razvrščeni so po kategorijah in aplikacijah. Določeni vzorci so uporabljeni v več aplikacijah.

Integracijski vzorci in protivzorci Stran 61 Tabela 4.1: Seznam uporabljenih vzorcev integracije EcommUpdater ErpUpdater Spletna trgovina Integracijski stili Sporočilni sistemi Sporočilni kanali Konstrukcija sporočila Usmerjanje sporočil Preoblikovanje sporočil Končna sporočil točka Sporočilni stil. Sporočilni stil. Sporočilni stil. Sporočilo, prevajalnik sporočila, končna točka sporočil. Zagotovljena dostava. Ukazno sporočilo, dokumentno sporočilo, zahteva - odgovor. Obogatitev vsebine. Sporočilna vrata. Sporočilo, prevajalnik sporočila, končna točka sporočil. Ukazno sporočilo, dokumentno sporočilo, zahteva - odgovor. Obogatitev vsebine. Sporočilna vrata, idempotenten prejemnik. Usmerjevalnik, sporočilo. Točka do točke, kanal neveljavnih sporočil, kanal mrtvih sporočil. Dogodkovno sporočilo. Vsebinsko pogojen usmerjevalnik. Obstojen naročnik. Najprej bomo začeli s stilom integracije. Omenjena spletna trgovina uporablja sporočilni stil (angl. Messaging), saj se uporablja spletna storitev, ki komunicira preko sporočil SOAP. To pomeni, da uporablja tudi vzorec sporočilo. Vzorec sporočila uporabljata tudi komponenti EcommUpdater in ErpUpdater, saj komunicirata s spletno storitvijo spletne trgovine preko sporočil v obliki XML. Od vzorcev sporočilnih sistemov se uporablja tudi primer usmerjevalnika, in sicer vsebinsko pogojenega usmerjevalnika, ki je uporabljen v spletni trgovini in je podan na Sliki 4.2. Za posamično vsebino sporočila (npr. za dodajanje v košarico, za novo naročilo, za brisanje uporabniškega računa) se lahko nastavi poseben kanal, tj. naslov (na sliki»callout URL«), kamor se bo to sporočilo poslalo. Pri tem se uporablja tudi tip kanala od točke do točke (angl. Point-to-Point channel), eden za vsako vsebino oz. URL-naslov posebej [12].

Integracijski vzorci in protivzorci Stran 62 Slika 4.2: Primer vsebinsko pogojenega usmerjevalnika v spletni trgovini Obe aplikaciji integracije uporabljata vzorec prevajalnik sporočil (angl. Message translator). Pri komponenti ErpUpdater je potrebno iz oblike XML izluščiti podatke za spremembe na podatkovni bazi sistema ERP. Pri komponenti EcommUpdater pa imamo pretvorbo v obratni smeri, zatorej je potrebno iz podatkovnega modela sistema ERP oblikovati obliko XML za pošiljanje sporočila na spletno storitev spletne trgovine, v nadaljevanju WSI spletne trgovine. Aplikaciji prav tako uporabljata vzorec končna točka sporočila (angl. Message Endpoint), ki je vključen kot knjiţnica DLL in omogoča, da lahko komuniciramo z WSI. Uporabljena sta tudi vzorca kanal neveljavnih sporočil in kanal mrtvih sporočil, ki sta v našem primeru uporabljena skupaj, torej imamo samo en kanal namesto dveh. V primeru, da kakršnokoli sporočilo iz spletne trgovine ni dostavljeno oz. pride do napake pri sprejemanju sporočila, se le-to shrani v podatkovno bazo in se kasneje, ko je prejemnik spet sposoben prejeti sporočilo, pošlje še enkrat, seveda pred vsemi ostalimi, saj je časovno zaporedje sporočil zelo pomembno in se morajo spremembe, ki so bile narejene v spletni trgovini, prenesti v istem vrstnem redu na sistem ERP, drugače lahko pride do napake pri podatkih. Vzorec zagotovljene dostave smo uporabili pri aplikaciji EcommUpdater, in sicer na naslednji način: Vse spremembe, ki se zgodijo na podatkovni bazi sistema ERP, se najprej zapišejo v določeno tabelo podatkovne baze. Te spremembe se po parametrično določenem časovnem intervalu prenašajo v spletno trgovino po enakem vrstnem redu, kot so bile zapisane v bazo. Šele ko nam WSI spletne trgovine vrne odgovor o uspešno dokončani spremembi, izbrišemo zapis te spremembe, saj je bila sprememba uspešno prenesena.

Integracijski vzorci in protivzorci Stran 63 Vzorec ukaznega sporočila se je dosti uporabljal pri raznih povpraševanjih z jezikom XSLT v obeh omenjenih aplikacijah integracije. Primer 4.1 je primer takega povpraševanja, ki direktno kliče metodo GetMLValue spletne trgovine z namenom pridobitve imena produkta. <ProductName> <xsl:value-of select="aspdnsf:getmlvalue(/root/products/product/name)" /> </ProductName> Primer 4.1: Primer ukaznega sporočila Dokumentno sporočilo srečamo pri vseh treh aplikacijah, saj se za komunikacijo pošiljajo dokumenti XML. Primer funkcije za pošiljanje takšnih dokumentov vidimo na Primeru 4.2. To funkcijo za pošiljanje dokumentov spletni storitvi uporabljata aplikaciji ErpUpdater in EcommUpdater. Isti primer hkrati ponazarja princip zahteva - odgovor (angl. Request-Reply), saj spletna storitev vrne rezultat, ki ga mi shranimo v spremenljivko result. public string Send(string message) { string username = m_appparamdao.getusername(); string password = m_appparamdao.getpassword(); String result = String.Empty; } if (m_usewse3) { int saltkey = m_appparamdao.getsaltkey(username); string encriptedpassword = EncryptPassword(password, saltkey); UsernameToken token = new UsernameToken(username, encriptedpassword, PasswordOption.SendHashed); AspDotNetStorefrontImportWebServiceWse svc = new AspDotNetStorefrontImportWebServiceWse(); svc.url = m_address; svc.requestsoapcontext.security.tokens.add(token); result = svc.doitwse3(message.trim()); } else { AspDotNetStorefrontImportWebService svc = new AspDotNetStorefrontImportWebService(); svc.url = "http://192.168.1.57/aspdotnetstorefront71/ipx.asmx"; result = svc.doitusernamepwd(username, password, message.trim()); } return result; Primer 4.2: Primer funkcije za pošiljanje dokumentov spletni storitvi (C#) [12] Pri spletni trgovini AspDotNetStoreFront srečamo tudi primere dogodkovnega sporočila, in sicer se pošiljajo različna obvestila o dogodkih na uporabniško določene URL-naslove (glej Sliko 4.2). Primer 4.3 prikazuje obvestilo o spremembi podatkov stranke s specifičnim argumentom CustomerID. To obvestilo je v obliki XML [12].

Integracijski vzorci in protivzorci Stran 64 <?xml version="1.0" encoding="utf-8"?> <EventNotification> <EventDate>3/5/2009</EventDate> <EventTime>3:45 PM</EventTime> <EventSite>yourdomain.com</EventSite> <Event>UpdateCustomer</Event> <EventData> <CustomerID>58756</CustomerID> </EventData> </EventNotification> Primer 4.3: Dogodkovno sporočilo o spremembi podatkov stranke Obogatitev vsebine je potrebna, kadar v prejetem sporočilu ne dobimo vseh ţeljenih podatkov in je potrebno določene podatke dobiti drugje ter sporočilu dodati manjkajoči del. Primer 4.4 prikazuje princip obogatitve vsebine. Metoda za pridobitev podatkov kontaktne osebe GetcontactPerson uporabi argument GUIDCONTACT, ki je poslan v sporočilu in vrne rezultat, ki ga kasneje dodamo k sporočilu. private string GetcontactPerson(Guid Cusguid) { string contactpersonname = ""; string contactpersonsurname = ""; string contactperson = ""; using (SqlConnection connection = new SqlConnection(m_ConnectionString)) { connection.open(); SqlCommand selcontpersname = new SqlCommand(SELECT_CONTACT_PERSON_NAME, connection); SqlParameter perscontactguid = selcontpersname.parameters.add("@guidcontact", SqlDbType.UniqueIdentifier, 16); perscontactguid.value = Cusguid; contactpersonname = selcontpersname.executescalar().tostring(); SqlCommand selcontperssurname = new SqlCommand(SELECT_CONTACT_PERSON_SURNAME, connection); SqlParameter perscontactguida = selcontperssurname.parameters.add("@guidcontact", SqlDbType.UniqueIdentifier, 16); perscontactguida.value = Cusguid; contactpersonsurname = selcontperssurname.executescalar().tostring(); contactperson = contactpersonname + " " + contactpersonsurname; } return contactperson; } } Primer 4.4: Primer uporabe vzorca obogatitev vsebine Vzorec sporočilnih vrat se uporablja pri aplikacijah ErpUpdater in EcommUpdater, in sicer je sporočilni del vključen v obe aplikaciji kot lasten projekt, ki se imenuje

Integracijski vzorci in protivzorci Stran 65 AppBridgeCommon. Ta del se uporablja za komunikacijo s spletno storitvijo in je ločen od ostalega dela izvorne kode. Princip obstojnega naročnika se uporabi pri pošiljanju sporočil iz spletne trgovine, in sicer na način, opisan v tem poglavju pri primeru kanala neveljavnih in mrtvih sporočil. Princip idempotentnega prejemnika uporabimo v aplikaciji ErpUpdater. Npr. če se iz spletne trgovine pošlje sporočilo o spremembi podatkov specifične stranke, najprej preverimo, če so ti podatki ţe shranjeni oz. če so enaki podatkom, poslanim iz spletne trgovine. V primeru, da so, ne naredimo sprememb na podatkovni bazi, v nasprotnem primeru le-to posodobimo. 4.2 Izbira potencialnih vzorcev za uporabo Pri uporabi vzorcev se ljudje večkrat sprašujemo, kateri vzorec uporabiti kdaj oz. kako vedeti, kdaj je določen vzorec primeren. Za laţjo izbiro potencialnih kandidatov za uporabo vzorcev pri integraciji smo oblikovali odločitveno shemo, ki nam pomaga skozi različne odločitve priti do omenjenih kandidatov in tako laţje izbirati integracijske vzorce, ki bi jih lahko uporabili v praksi. Da bo shema laţje razumljiva, navajamo tudi legendo (Slika 4.3), ki pojasnjuje, kateri element sheme kaj predstavlja. Vidimo, da rdeče obarvan pravokotnik predstavlja začetek odločitvene sheme, modro obarvan pravokotnik predstavlja vzorec, zelenkasto obarvana elipsa predstavlja kategorijo oz. tematiko problema, medtem ko vijolični romb predstavlja odločitev v shemi. Na Sliki 4.4 je prikazana odločitvena shema, preko katere lahko pridemo do primernih vzorcev, ki bi jih po vsej verjetnosti bilo priporočljivo uporabiti ali vsaj razmisliti o njihovi uporabi. Slika 4.3: Legenda odločitvene sheme integracijskih vzorcev