Embed Size (px)
Citation preview
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO,
RAČUNALNIŠTVO IN INFORMATIKO
Nikola Risteski
INTEGRACIJA POSLOVNIH APLIKACIJ Z UPORABO PLATFORME TIBCO AMX BW
Diplomsko delo
Maribor, maj 2016
S t r a n | ii
S t r a n | iii
INTEGRACIJA POSLOVNIH APLIKACIJ Z UPORABO
PLATFORME TIBCO AMX BW
Diplomsko delo
Študent: Nikola Risteski
Študijski program: univerzitetni študijski program
Računalništvo in informatika
Smer: Informatika
Mentor: prof. dr. Marjan Heričko
Lektorica: Irena Žunko, prof. slov. j.
S t r a n | iv
S t r a n | v
S t r a n | vi
S t r a n | vii
Zahvala
Zahvaljujem se mentorju prof. dr. Marjanu Heričku za
pomoč in vodenje pri pripravi diplomskega dela.
Zahvaljujem se družini za nenehno podporo v času
študija. Hvala tudi vsem prijateljem, ki so mi
popestrili in polepšali čas študija.
Hvala tudi Bojani za ljubezen in podporo.
S t r a n | viii
S t r a n | ix
INTEGRACIJA POSLOVNIH APLIKACIJ Z UPORABO PLATFORME TIBCO AMX BW
Ključne besede: integracija poslovnih aplikacij, storitveno usmerjena arhitektura, SOA,
TIBCO
UDK: 004.273+004.434:005(043.2)
Povzetek:
V diplomskem delu obravnavamo integracijo poslovnih aplikacij in povezovalnega
programja. Predstavimo smernice razvoja integracije poslovnih aplikacij s posebnim
poudarkom na storitveno usmerjeni arhitekturi. Sledi opis tehnologij, ki so prisotne pri
storitveno usmerjeni arhitekturi in opis storitvenega vodila kot koncepta. V nadaljevanju
podrobno opišemo ogrodje TIBCO ActiveMatrix BusinessWorks s komponentami, ki ga
sestavljajo. V praktičnem delu predstavimo primer integracije poslovnih aplikacij z uporabo
ogrodja TIBCO ActiveMatrix BusinessWorks na primeru fiktivnega mobilnega operaterja.
S t r a n | x
S t r a n | xi
ENTERPRISE APPLICATION INTEGRATION USING THE TIBCO AMX BW
PLATFORM
Keywords: enterprise application integration, service oriented architecture, SOA, TIBCO
UDK: 004.273+004.434:005(043.2)
Abstract:
In this final work we discuss enterprise application integration and middleware. We present
the development of enterprise application integration with a special focus on service
oriented arhitecture. We continue by describing the technologies present in service oriented
architectures and a description of the enterprise service bus as a concept. Then follows a
detailed description of the TIBCO ActiveMatrix BusinessWorks platform along with the
components, which it is consisted of. In the practical part of the final work, we show an
example of enterprise application integration using TIBCO ActiveMatrix BusinessWorks
with the case of a fictional mobile operator.
S t r a n | xii
S t r a n | xiii
KAZALO
1. UVOD ........................................................................................................................ 1
2. INTEGRACIJA POSLOVNIH APLIKACIJ ................................................................... 3
2.1. Definicija integracije poslovnih aplikacij .............................................................. 3
2.2. Podatkovno usmerjena integracija ...................................................................... 4
2.3. Funkcijsko usmerjena integracija ........................................................................ 6
2.4. Storitveno usmerjena arhitektura ........................................................................ 8
2.5. Storitveno vodilo ................................................................................................. 8
3. STORITVENO USMERJENA ARHITEKTURA ........................................................... 9
3.1. Koncepti ............................................................................................................. 9
3.2. Tehnologije ........................................................................................................13
3.2.1. Jezik XML ...................................................................................................13
3.2.2. Tehnologiji XSD in DTD ..............................................................................14
3.2.3. Jezik za opis storitev WSDL .......................................................................15
3.2.4. Specifikacije WS-Security ...........................................................................16
3.2.5. Jezik XPath ................................................................................................17
3.2.6. Jezik za povpraševanje XQuery..................................................................18
3.2.7. Jezik BPEL .................................................................................................18
3.3. Storitveno vodilo ................................................................................................18
4. Ogrodje TIBCO ActiveMatrix BusinessWorks ...........................................................21
4.1. Primerjava različnih programskih ogrodij za integracijo poslovnih aplikacij ........23
4.2. Ogrodje TIBCO ..................................................................................................26
4.3. Ogrodje TIBCO ActiveMatrix BusinessWorks ....................................................27
4.4. Adapterji ............................................................................................................28
4.5. Orodje TIBCO Administrator ..............................................................................29
S t r a n | xiv
4.6. Orodje TIBCO Hawk ..........................................................................................30
4.7. Orodje TIBCO Designer .....................................................................................31
4.8. Palete ................................................................................................................32
4.9. Procesi ..............................................................................................................33
4.10. Globalne spremenljivke ..................................................................................36
5. PRAKTIČNI PRIMER INTEGRACIJE POSLOVNIH APLIKACIJ ...............................37
5.1. Pregled arhitekture ............................................................................................38
5.2. Implementacija storitev ......................................................................................39
5.3. Upravljanje varnosti ...........................................................................................48
5.4. Namestitev na strežniku.....................................................................................49
6. SKLEP ......................................................................................................................52
7. LITERATURA ...........................................................................................................55
8. PRILOGE..................................................................................................................59
8.1. Kazalo slik .........................................................................................................59
8.2. Kazalo izvorne kode ..........................................................................................59
8.3. Kazalo tabel .......................................................................................................60
S t r a n | xv
Seznam uporabljenih kratic
AMX ActiveMatrix
B2B Business-to-Business
BPEL Business Process Execution Language
BSS Business System Support
BW BusinessWorks
CRM Customer Relationship Management
DOM Document Object Model
EMS Enterprise Message Service
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
HTTP Hypertext Transfer Protocol
iPaaS Integration Platform as a Service
JavaEE Java Platform, Enterprise Edition
JDBC Java Database Connectivity
JMS Java message service
M2M Machine-to-Machine
MOM Message-oriented Middleware
MSISDN Mobile Subscriber ISDN Number
OSS Operations System Support
RMI Remote Method Invocation
RPC Remote Procedure Call
SAX Simple API for XML
SOA Service-oriented Architecture
SQL Structured Query Language
SSL Secure Socket Layer
TCO Total Cost of Ownership
TIBCO The Information Bus Company
TLS Transport Layer Security
W3C World Wide Web Consortium
S t r a n | xvi
WCF Windows Communication Foundation
WSDL Web Service Definition Language
WSS Web Service Security
XML Extended Markup Language
XSD XML Schema Definition
S t r a n | 1
1. UVOD
Informacijske tehnologije so postale del našega vsakdana. Sodobnega življenja si ne
predstavljamo več brez hitrosti, udobja in učinkovitosti, ki ga prinaša sodobna tehnologija.
Omenjeno dejstvo še toliko bolj velja v poslovnem svetu, še posebej v velikih poslovnih
sistemih, kjer je konkurenčnost na vseh področjih ključnega pomena, pri čemer
informacijska tehnologija postaja temeljni pogoj za uspešno izvajanje poslovnih procesov.
Ob vedno večjih potrebah po informacijskih sistemih se pojavljajo tudi vse večji izzivi, kako
razviti programsko opremo hitreje, ceneje in lažje kot tudi, kako ponovno uporabiti že
obstoječe procese in se izogniti redundanci oziroma paralelnemu razvoju enake ali podobne
programske opreme. Pri vse večji vlogi informacijskih sistemov v poslovanju in povezanosti
različnih sistemov se pojavljajo novi izzivi na področju zanesljivosti, preglednosti in varnosti
teh sistemov.
Integracija poslovnih aplikacij je tesno povezana oziroma temelji na t. i. povezovalnem
programju (angl. middleware). Povezovalno programje je programje, ki je namenjeno
komunikaciji med posameznimi programskimi komponentami, sistemi ali aplikacijami. [1]
Zaradi vloge, ki jo ima povezovalno programje v integraciji poslovnih aplikacij, diplomska
naloga bolj podrobno opisuje povezovalno programje, tehnologije, ki jih povezovalno
programje uporablja, kot tudi nekatere zelo pogosto uporabljene koncepte integracij
poslovne programske opreme.
Na začetku diplomskega dela smo opisali teoretične temelje in zgodovino razvoja
integracij poslovnih procesov. V istem poglavju smo opisali tudi povezovalno programje kot
S t r a n | 2
»lepilo« med posameznimi poslovnimi aplikacijami znotraj enega integriranega sistema.
Opisali smo tudi različne pristope pri integraciji poslovnih aplikacij, skupaj s tehnologijami,
ki jih pristopi uporabljajo.
V tretjem poglavju smo opisali storitveno usmerjene arhitekture oziroma SOA (angl.
Service Oriented Architecture), saj so le-te poglavitni sodobni pristop k integracijam
poslovnih aplikacij. Prav tako smo opisali osrednje tehnologije pri implementaciji SOA. V
istem poglavju smo opisali tudi storitveno vodilo, ki je zelo pogosto uporabljen koncept pri
integraciji.
Sledi četrto poglavje, kjer smo na kratko predstavili različna ogrodja za integracijo
poslovnih aplikacij. V nadaljevanju smo podrobneje predstavili ogrodje TIBCO ActiveMatrix
BusinessWorks, prav tako pa tudi elemente in podporno okolje, ki ga sestavljajo.
V petem poglavju smo prikazali praktičen primer integracije poslovnih aplikacij na
primeru fiktivnega mobilnega operaterja, kjer smo prikazali primere integracije podatkov iz
različnih podatkovnih virov preko različnih komunikacijskih kanalov. Uporabili smo ogrodje
TIBCO ActiveMatrix BusinessWorks. Prikazali smo tudi uporabo različnih varnostnih
mehanizmov.
V zadnjem, šestem poglavju smo predstavili sklepe, do katerih smo prišli med pisanjem
te naloge.
S t r a n | 3
2. INTEGRACIJA POSLOVNIH APLIKACIJ
2.1. Definicija integracije poslovnih aplikacij
Integracija poslovnih aplikacij (angl. Enterprise Application Integration, v nadaljevanju
EAI) je širok izraz, ki se je pojavil na začetku prejšnjega desetletja, z namenom, da opiše
določene procese, ki so se dejansko pojavljali že prej. Čeprav ni enotne definicije integracije
poslovnih aplikacij, ena širših oziroma bolj splošnih definicij predstavlja EAI kot neomejeno
izmenjavo podatkov in procesov med katerimikoli povezanimi aplikacijami in podatkovnimi
viri znotraj določenega poslovnega sistema. [2]
EAI se je pojavil relativno spontano, kot odgovor na potrebe po povečani učinkovitosti
pri razvoju poslovnih aplikacij, na začetku znotraj istega podjetja, kasneje pa tudi pri
poslovanju med različnimi podjetji. Za razumevanje nastanka in razvoja EAI moramo
pogledati zgodovinski razvoj informacijskih sistemov v poslovnih sistemih. Zaradi omejenih
tehničnih možnosti, kot tudi pomanjkanja širšega strateškega načrtovanja, je razvoj
informacijskih sistemov v podjetjih v preteklosti pogosto potekal na nivoju posameznih
oddelkov, ki so razvijali medsebojno izolirane sisteme. Rezultati takšnega razvoja
informacijskih sistemov so bili oziroma so sistemi, ki so zgrajeni s pomočjo tehnologije, ki
je bila sodobna v času začetka razvoja ter je »pisana na kožo« obstoječim poslovnim
procesom v tem segmentu poslovanja. Takšne aplikacije pogosto označujemo kot
»informacijske silose«. Pod »informacijski silos« (angl. information silo) ali »dimnik
aplikacija« (angl. stovepipe application) razumemo aplikacijo, ki nima možnosti vzajemnega
komuniciranja z drugimi aplikacijami znotraj istega podjetja. Tipični primeri aplikacij, ki so
S t r a n | 4
pogosto »informacijski silosi«, so rešitve za odnose s strankami (angl. Customer
Relationship Management oz. CRM), za upravljanje virov podjetja (angl. Enterprise
Resource Planning oz. ERP), rešitve za kadrovsko poslovanje in človeške vire (angl.
Human Resources oz. HR) ali rešitve za področje oskrbovalne verige (angl. Supply-Chain
Management).
Tako kot so se razvijale informacijske tehnologije v poslovanju, tako so se spreminjale
tudi potrebe po integracijah poslovnih aplikacij. Na začetku so bile integracije namenjene
sodelovanju aplikacij znotraj oddelkov, kasneje pa sodelovanju različnih oddelkov in
celotnega podjetja. Z razvojem interneta je postajalo povezovanje z zunanjimi podjetji in
neposredno s končnimi kupci vse bolj pomembno, kar se odraža v nadaljnjem razvoju
komunikacije B2B (Business-to-Business), B2C (Business-to-Customer) in M2M (Machine-
to-Machine). Zaradi te spremembe vloge, ki jo povezovalno programje igra, se spreminja
razumevanje pojma povezovalnega programja, kot tudi sama kompleksnost in tehnologije,
ki se za povezovalno programje uporabljajo. [1]
Izraz, ki je povezan z integracijo poslovnih aplikacij, je vsekakor pojem povezovalnega
programja. Obstaja veliko definicij termina povezovalno programje. Linthicum [1] navaja, da
je najbolj primerna tista definicija, ki se nanaša na funkcijo, ki jo povezovalno programje
opravlja. Linthicum torej definira povezovalno programje kot »kakršnokoli programsko
opremo, ki olajša oziroma omogoča komunikacijo med dvema ali več programskimi
sistemi«. Kot obrazložitev za tako široko definicijo pojma povezovalno programje Linthicum
navaja raznolikost povezovalnega programja – od spletnih storitev in storitvenega vodila,
do enostavne komunikacije med dvema procesoma (angl. communication pipe).
Področje integracije poslovnih aplikacij obstaja že nekaj časa, posledično poznamo več
pristopov k integraciji poslovnih aplikacij, saj so se pristopi in tehnologije spreminjali z
razvojem računalništva. Posamezni pristopi ali vzorci integracije poslovnih aplikacij se
razlikujejo glede na nivo, na katerem integrirajo podatke oziroma procese, glede
tehnologije, ki jo uporabljajo za komunikacijo med posameznimi aplikacijami ali
podatkovnimi viri, kot tudi glede na sklopljenost med aplikacijami. Različne pristope smo
predstavili v naslednjih podpoglavjih.
2.2. Podatkovno usmerjena integracija
Kot izhaja iz samega poimenovanja pojma, je podatkovno usmerjena integracija pristop
k integraciji, ki temelji oziroma se izvaja na podatkovnem nivoju. Ker pri podatkovno
usmerjeni integraciji operiramo neposredno s podatki, to načeloma pomeni, da gremo mimo
S t r a n | 5
poslovne logike, ki je zapisana v aplikacijah, ki jih želimo integrirati. [3] Obstaja več načinov,
kako lahko tehnično implementiramo podatkovno usmerjeno integracijo:
‒ z deljenjem datotek,
‒ s souporabo podatkovnih baz,
‒ s transformacijo podatkov.
Prvi način pri podatkovno usmerjenih integracijah izhaja še iz časov centralnih
računalnikov (angl. mainframe), na katerih so se generirale datoteke za prenos do drugih
aplikacij. Nekateri menijo, da v tem primeru ne gre za dejansko integracijo podatkov, temveč
samo za prenos podatkov iz enega v drugo okolje. [3] Format, ki se uporabi za izmenjavo
datotek med aplikacijami, je dogovorjen med aplikacijami in je odvisen od posameznih
aplikacij. Pri tem lahko uporabimo binarne datoteke, tekstovne datoteke, ki so ločene z
določenim znakom, ter XML-datoteke pri sodobnejših aplikacijah.
Prednost izmenjave datotek je enostavnost samega postopka – ena aplikacija datoteko
ustvari, druga aplikacija pa datoteko prebere, pri čemer praviloma ne potrebujemo nobene
dodatne programske opreme. Komunikacija preko datoteke obenem omogoča šibko
sklopljenost med aplikacijama, saj se aplikaciji lahko nemoteno razvijata naprej, če format
datoteke ostane enak. Seveda ima takšen način integracij tudi nekaj slabosti. Ena od teh
slabosti je časovna usklajenost podatkov. Generiranje datotek po navadi poteka po
dogovorjenem terminskem načrtu. Zamuda pri prenosu podatkov z izmenjavo datotek lahko
privede do zastarelosti podatkov, kar lahko povzroči težave za podjetje. [4]
Naslednji način implementacije je souporaba podatkovnih baz. Pri tem načinu imamo
več različnih aplikacij, ki uporabljajo skupno podatkovno bazo. Z večanjem uporabe
podatkovnih baz SQL je uporaba skupne podatkovne baze postala vse bolj popularen način
integracije podatkov. [4] Ta način rešuje težave z zastarelostjo podatkov ali morebitne
težave z različno obliko podatkov, vendar prinaša druge slabosti. Ena osrednjih težav je
priprava skupnega podatkovnega modela, ki bo enoten za več različnih aplikacij. Še večjo
težavo pa predstavlja integracija zunanjih aplikacij, saj zunanje aplikacije uporabljajo svoje
podatkovne modele in četudi morda omogočajo določeno stopnjo prilagoditve, to pogosto
ne zadostuje potrebam integracije. [4]
Tretji način, ki smo ga omenili, je transformacija podatkov. V tem primeru imamo
podatke v ločenih podatkovnih bazah. V primeru dodajanja novih podatkov ali spreminjanja
obstoječih podatkov se spremembe beležijo in podatke v transformirani obliki prenesejo v
druge ustrezne podatkovne baze. Primer transformacije podatkov je sprememba
S t r a n | 6
podatkovnega tipa ali sprememba valute. [3] Ta način predvideva uporabo orodja, ki bo
skrbelo za sinhronizacijo in transformacijo podatkov.
2.3. Funkcijsko usmerjena integracija
Funkcijsko usmerjena integracija je pristop k integraciji, ki se loteva integracije na
nivoju poslovne logike. Na področju funkcijsko usmerjene integracije lahko omenimo
naslednje integracijske postopke:
‒ klici oddaljenih procedur (angl. Remote Procedure Calls oziroma RPC),
‒ sporočilno usmerjena integracija (angl. Message Oriented Integration),
‒ porazdeljeni objekti (angl. Distributed Objects).
Klic oddaljenih procedur oziroma RPC je klic za izvedbo procedur na drugem
računalniku, brez eksplicitnega poznavanja podrobnosti o mrežni komunikaciji obeh
računalnikov. [5] RPC uporablja način delovanja strežnik – odjemalec. S pojavom objektne
tehnologije se je koncept RPC pojavil tudi pri objektni tehnologiji, kjer ga poznamo pod
nazivom RMI (angl. Remote Method Invocation).
Sporočilno usmerjena integracija (angl. Message Oriented Integration) je pristop k
integraciji, ki temelji na sporočanju. Za začetek postavimo definicijo sporočanja (angl.
messaging). Sporočanje v tem kontekstu razumemo kot uporabo tehnologije, ki omogoča
hitro asinhrono komunikacijo med sistemi oziroma komponentami z zanesljivo dostavo
sporočil. [4] Pri sporočanju uporabljamo logične poti za komunikacijo med dvema
sistemoma, ki jih po navadi imenujemo kanali (angl. channels) ali vrste (angl. queues).
Komunikacija poteka preko izmenjave sporočil, ki so atomarni nosilci informacij.
Osrednjo vlogo pri sporočanju ima povezovalno programje, ki nudi podporo za
sporočanje. Shema sporočilno usmerjenega povezovalnega programja je prikazana na sliki
2.1.
S t r a n | 7
Slika 2.1 Shema sporočilno usmerjenega povezovalnega programja, prirejeno po [6]
Sporočilno usmerjena integracija ponuja določene prednosti v primerjavi s pristopom
RPC oziroma s tehnologijami porazdeljenih objektov [4]:
‒ asinhrona komunikacija,
‒ bolj zanesljiva komunikacija,
‒ večja stopnja platformne oziroma jezikovne neodvisnosti,
‒ lažje upravljanje večje obremenitve in druge prednosti.
Obenem se pri sporočilno usmerjeni integraciji soočamo z izzivi, ki so specifični za to
področje: kompleksnejši programski model, težave z vrstnim redom operacij, sinhronimi
scenariji izvajanja, kot tudi težavami v komunikaciji med različnimi implementacijami MOM,
saj pogosto pride do odvisnosti od proizvajalca (angl. vendor lock-in), kar otežuje
vzpostavitev komunikacije med implementacijami MOM različnih proizvajalcev. [4]
Tehnologije porazdeljenih objektov so popularnost pridobivale skupaj s porastom
popularnosti objektnih tehnologij. Tehnologije porazdeljenih objektov so tehnologije, s
pomočjo katerih uporabljamo objekte, ki se nahajajo na različnih računalnikih. Najbolj
pogost način komunikacije s porazdeljenimi objekti je preko klicev oddaljenih metod
oziroma RMI. [2]
Obstaja več tehnologij porazdeljenih objektov različnih proizvajalcev. Med najbolj
znanimi sta CORBA (Common Object Request Broker Architecture) in DCOM (Distributed
Common Object Model). Porazdeljeni objekti ponujajo višji nivo abstrakcije v primerjavi s
podatkovno usmerjeno integracijo, vendar imajo hkrati bolj sklopljen način delovanja, saj je
povezava med različnimi tehnologijami zelo otežena. S pojavom spletnih storitev se je
popularnost tehnologij porazdeljenih objektov bistveno zmanjšala. [7]
S t r a n | 8
2.4. Storitveno usmerjena arhitektura
Storitveno usmerjena arhitektura (angl. Service Oriented Architecture, v nadaljevanju
SOA) je izraz, ki je bil v pogosti uporabi zadnjih nekaj let in predstavlja najbolj pogosto izbiro
za sodobne integracije. Definicija storitveno usmerjene arhitekture s strani Open Group je
naslednja: [8]
»Storitveno usmerjena arhitektura je arhitekturni stil, ki omogoča storitveno
usmerjenost. Storitvena usmerjenost je način razmišljanja v terminih storitev in razvoj, ki
temelji na storitvah in rezultatih storitev.« Definicija je namenoma tako splošna, da zagotovi
platformno oziroma tehnološko neodvisnost, saj gre za paradigmo in ne specifično
tehnologijo. Ob tem velja omeniti, da večina zastopnikov SOA pri razlagi tehničnih
podrobnosti SOA principe predstavlja kot »enostaven dostop do objektov, brez protokola«,
torej kot SOAP, brez protokola. [9]
Zaradi pomena, ki ga ima SOA v sodobnih integracijah poslovnih aplikacij, smo
storitveno usmerjeno arhitekturo bolj podrobno obrazložili v poglavju 3.
2.5. Storitveno vodilo
Storitveno vodilo (angl. Enterprise Service Bus, v nadaljevanju ESB) je še en koncept,
ki je pogosto uporabljen pri sodobnih integracijah poslovnih aplikacij. ESB se načeloma
uporablja znotraj storitveno usmerjene arhitekture. Med prvimi definicijami pojma ESB je
Gartnerjeva [10]: »ESB je arhitektura, ki uporablja spletne storitve, sporočilno povezovalno
programje, inteligentno usmerjanje in transformacijo. ESB služi kot lahka, vseprisotna
hrbtenica, skozi katero tečejo programske storitve in aplikacijske komponente«.
Storitveno vodilo pogosto igra vlogo »hrbtenice« v storitveno usmerjeni arhitekturi.
Poleg komunikacijske funkcije, ki jo opravlja, opravlja tudi funkcijo zagotavljanja varnosti ter
funkcijo nadzora in beleženja podatkov. Podobno kot pri storitveno usmerjeni arhitekturi
smo se tudi pri storitvenem vodilu odločili, da mu je treba posvetiti več pozornosti, zato smo
značilnosti storitvenega vodila obravnavali v tretjem poglavju skupaj s storitveno usmerjeno
arhitekturo.
S t r a n | 9
3. STORITVENO USMERJENA ARHITEKTURA
Storitveno usmerjeno arhitekturo smo že omenili v podpoglavju 2.4., vendar se nismo
spustili v podrobnosti, kaj storitveno usmerjena arhitektura predstavlja in kakšna je njena
vloga pri integraciji aplikacij. Tam smo tudi podali definicijo storitveno usmerjene arhitekture
po skupini Open Group. Za boljše razumevanje pojma storitveno usmerjena arhitektura,
podajamo še nekaj definicij. Skupina OASIS definira SOA na naslednji način: »SOA je
paradigma za organiziranje in izkoriščanje porazdeljenih kapacitet, ki so lahko v različnih
lastniških domenah. Omogoča poenotene načine ponujanja, odkrivanja in izkoriščanja
kapacitet, da bi dosegli želene učinke, v skladu z merljivimi predpogoji in pričakovanji«. [11]
Prav tako kot skupina OASIS, tudi W3C definira SOA precej splošno: »Množica komponent,
ki jih lahko pokličemo, jih lahko objavimo in odkrijemo njihove opise vmesnikov«. [12]
V nadaljevanju pa smo bolj podrobno opisali glavne lastnosti in tehnologije, ki so
značilni za storitveno usmerjeno arhitekturo.
3.1. Koncepti
Kateri so torej glavni koncepti storitvene arhitekture? Tako kot nimamo ene natančne
definicije storitveno usmerjene arhitekture, tudi ne obstaja noben splošno sprejet dokument
ali standard, ki bi določal, kateri so principi SOA. Josuttis kot glavne principe omenja
storitve, interoperabilnost in šibko sklopljenost. [13]
Kaj torej je storitev? Open Group storitvi pripisuje naslednje lastnosti [8]:
‒ je logična reprezentacija ponovljive poslovne aktivnosti, ki ima določen izid (primer:
preverjanje stanja na bančnem računu),
S t r a n | 10
‒ samozadostnost (angl. self-contained),
‒ lahko je sestavljena iz drugih storitev,
‒ predstavlja »črno škatlo« za uporabnike te storitve.
Obstaja več klasifikacij storitev, pogosto pa jih ločimo na osnovne (ali atomarne),
sestavljene (ali komponirane) storitve in procesne storitve. [13] Osnovne storitve so storitve,
ki opravljajo osnovne funkcionalnosti in delitev na manjše storitve bi bila nesmiselna.
Tipičen primer takšne storitve so podatkovne storitve, ki opravijo enostavno operacijo na
podatkovnem viru (npr. izvedejo zapis podatkov v podatkovno bazo).
Naslednja skupina storitev so sestavljene storitve. Kot izhaja iz samega imena, so
sestavljene storitve tiste storitve, ki so sestavljene iz drugih storitev, bodisi osnovnih bodisi
drugih sestavljenih storitev in so abstrakcijsko gledano višje od osnovnih storitev. Kljub
temu so ti procesi razmeroma enostavni, kratki in konceptualno brez pomnjenja (angl.
stateless). Tipičen primer takšne storitve je storitev, ki prebere podatke iz več zalednih
sistemov, jih preoblikuje in vrne odjemalcu. [13]
Procesne storitve so abstrakcijsko še višja skupina storitev. Procesne storitve so tudi
sestavljene storitve, vendar so za razliko od predhodno opisanih sestavljenih storitev bolj
kompleksne in dalj časa trajajoče ter se lahko prekinejo s strani uporabnika. Za razliko od
sestavljenih storitev procesne storitve ohranijo stanje. Tipični primer takšne storitve je
nakupovalna košarica v spletni trgovini.
Na podlagi tipov storitev lahko definiramo tudi stopnje razširjenosti storitveno usmerjene
arhitekture. Če imamo osnovne spletne storitve, govorimo o temeljni SOA (angl.
Fundamental SOA), v primeru sestavljenih storitev združeni SOA (angl. Federated SOA),
če pa smo že pripravili procesne storitve, govorimo o procesni storitveno usmerjeni
arhitekturi (angl. Process-enabled SOA). Povezava med tipi storitev in stopnji razširjenosti
SOA je prikazana na sliki 3.1.
S t r a n | 11
Slika 3.1 Stopnje razširjenosti SOA glede na storitve [13]
Naslednji omenjen koncept je interoperabilnost. Interoperabilnost je lastnost oziroma
sposobnost sistema ali produkta, da deluje z drugimi sistemi ali produkti brez potrebnega
dodatnega truda. [14] Interoperabilnost je bistvena lastnost sistema v času integracije in
povezovanja, saj je veliko integracij namenjenih premostitvi nezdružljivosti različne strojne
in programske opreme. Interoperabilnost kot princip ni novost, saj je bila potreba po
interoperabilnosti prisotna že pred pojavom storitveno usmerjene arhitekture in je tudi
koncept predhodnih pristopov k integraciji poslovnih aplikacij. [13]
Še en koncept storitveno usmerjene arhitekture je šibka sklopljenost. Princip šibke
sklopljenosti pomeni, da komponente oziroma storitve, ki medsebojno sodelujejo, niso
medsebojno odvisne oziroma praviloma vedo le malo o storitvi, s katero sodelujejo. [15] S
šibko sklopljenostjo dosežemo avtonomnost storitev, saj se lahko izvajajo v poljubnem
okolju, s pomočjo poljubne programske opreme, hkrati pa v primeru sprememb na storitvi
zmanjšujemo potrebo po popravkih in spremembah na drugih sodelujočih storitvah. [16]
Poleg zgoraj omenjenih konceptov lahko kot osnovne koncepte storitveno
usmerjene arhitekture opredelimo tudi naslednje koncepte [17]:
‒ abstrakcija storitev,
‒ ponovna uporaba storitev,
‒ avtonomnost storitev,
‒ ponovna uporaba storitev,
‒ granularnost storitev.
Ponovna uporaba, kot tudi sestavljanje storitev, sta med temeljnimi koncepti storitveno
usmerjene arhitekture. Pri tem ločimo dva pristopa k sestavljanju storitev: koreografijo in
S t r a n | 12
orkestracijo. Oba pristopa stremita k vzpostavljanju reda pri uporabi procesov, vendar se
razlikujeta glede načina, kako poskušata to uresničiti.
Koreografija, kot izhaja iz samega imena, deluje na podlagi analogije plesa – vsakega
udeleženca v nastopu poskuša naučiti, kaj mora posamezni udeleženec v koreografiji (tj.
posamezen proces) delati. V primeru koreografije nimamo centraliziranega procesa, ki bi
upravljal vsak proces, imamo pa koreografijo kot seznam pravil, ki regulirajo, kako naj se
vsak proces obnaša. Procesi poznajo samo svoj del naloge in nobeden ne upravlja vseh
korakov posameznih procesov. Na drugi strani imamo orkestracijo. Analogija z orkestrom
pomeni, da imamo pri orkestraciji centralizirano vodenje oziroma upravljanje posameznih
procesov, podobno kot dirigent dirigira orkestru. Centralizirano vodenje poteka preko
spletne storitve, ki je namenjena koordiniranju ostalih procesov. [9], [13]
Za ilustracijo razlik med koreografijo in orkestracijo smo na slikah 3.2. in 3.3. prikazali
komunikacijo med dobavitelji in trgovci preko orkestracije in koreografije. Primer velja za
kakršnekoli udeležence v komunikaciji v storitveno usmerjeni tehnologiji. [18]
Slika 3.2 Koreografija med trgovci in dobavitelji
S t r a n | 13
Slika 3.3 Orkestracija med trgovci in dobaviteljem
3.2. Tehnologije
Storitveno usmerjena arhitektura je pridobila na popularnosti s pojavom spletnih
storitev, čeprav se je storitveno usmerjena arhitektura kot koncept pojavila bistveno pred
pojavom spletnih storitev. [13] Storitveno usmerjena arhitektura je kot arhitektura pristop k
reševanju problemov in ne specifičen nabor tehnologij, vendar je smotrno omeniti in opisati
poglavitne tehnologije, ki se uporabljajo za implementacijo arhitekture.
Prav zaradi pomena, ki ga imajo spletne storitve pri implementaciji storitveno
usmerjenih tehnologij, komično opisujemo storitveno usmerjeno arhitekturo z besedami
»SOA je SOAP brez besede protokol«. [9] Kaj so pravzaprav spletne storitve? Splošna
definicija spletne storitve s strani organizacije W3C definira spletno storitev kot storitev, ki
jo ena elektronska naprava ponuja drugi preko omrežja. [19] Definicijo spletne storitve
podamo z uporabo jezika za definicijo spletnih storitev WSDL (angl. Web Service Definition
Language). WSDL je posebej pripravljen jezik, ki temelji na XML (eXtended Markup
Language), s pomočjo katerega definiramo vse pomembne lastnosti spletne storitve.
3.2.1. Jezik XML
Jezik XML je temelj številnih tehnologij, ki so povezane s spletnimi storitvami. Jezik
XML je označevalni (angl. markup) jezik, ki je berljiv tako s strani človeka, kot tudi
S t r a n | 14
računalnika. Razvili so ga leta 1998 v okviru delovne skupine pod okriljem konzorcija W3C.
Namen je bil, da pripravijo jezik, ki se bo uporabljal preko interneta in bo formalno definiran,
enostaven ter hiter za uporabo. [20] Z uporabo oznak in imenskih prostorov lahko poleg
podatkov zapišemo tudi metapodatke, ki olajšajo kasnejše procesiranje dokumentov, hkrati
pa lahko metapodatki, ki so zapisani v oznakah, olajšajo branje dokumentov človeku. XML
omogoča tudi podporo Unicode, kar pomeni, da podpira različne pisave in je primeren za
različna jezikovna okolja. Jezik XML je zaradi svojih lastnosti, kot tudi zaradi izboljšanja
procesorske moči računalnikov, hitro postal zelo popularen. Prav tako je postal osnova za
veliko število tehnologij. Nekatere bomo opisali v nadaljevanju.
Pri programskem procesiranju dokumentov XML ločimo dva pristopa oziroma
tehnologiji: DOM (Document Object Model) in SAX (Simple API for XML). Pri tehnologiji
DOM preslikamo dokument XML v drevo objektov, s katerim manipuliramo. Vsak del
dokumenta XML (npr. element ali atrubit) predstavlja vozlišče v drevesu, naenkrat pa
preberemo celoten dokument. SAX je tehnologija, ki je namenjena samo branju
dokumentov, saj deluje na način, da prebira dokument in ob tem sproža ustrezne dogodke,
ki jih razvijalec programske opreme lahko obravnava. SAX ima prednost pri procesiranju
velikih dokumentov XML, saj za razliko od tehnologije DOM ni potrebe po nalaganju
celotnega dokumenta v pomnilnik.
3.2.2. Tehnologiji XSD in DTD
Še ena uporabna lastnost dokumentov XML je, da lahko definiramo njihovo obliko
oziroma vsebino. To lahko dosežemo s pomočjo tehnologij XSD (XML Schema Definition)
ali DTD (Document Type Definition).
DTD je množica deklaracij, ki definira dokumentni tip za dokument, spisan v
označevalnem jeziku iz družine SGML, kot sta XML in HTML. [21] DTD se lahko deklarira
v samem dokumentu XML, ali pa se v dokumentu XML referencira pot do datoteke, ki
vsebuje DTD-opis dokumenta. Z uporabo zapisov DTD lahko pripravimo enostavnejše
definicije v primerjavi s shemami XML. DTD omogoča štiri glavne elemente, ki jih lahko
uporabimo pri definicijah: ELEMENT (za definicijo elementov), ATTLIST (za definicijo
atributov), ENTITY (za definicijo entitet) in NOTATION (uporabljamo ga za enumeracijo
možnih vrednosti pri atributih).
Sheme XML so bolj popularen način definiranja dokumentov XML. Tudi W3C
priporoča uporabo XML-shem za pripravo besednjakov za dokumente XML. Za razliko od
definicij DTD definicije XML-shem definirajo tudi imenske prostore. Sheme XML so
S t r a n | 15
pravzaprav dokumenti XML, ki predstavljajo abstraktno kolekcijo metapodatkov, ki je
sestavljena iz množice komponent. [22] Med komponentami, ki so na voljo, so deklaracije
elementov, deklaracije atributov, deklaracije enostavnih in kompleksnih tipov, kot tudi
definicije glede kardinalnosti elementov in omejitev podatkovnih tipov. Glavni elementi XSD-
shem so prikazani na sliki 3.4.
Slika 3.4 Glavni elementi sheme XML [23]
Za razliko od definicij DTD ponujajo sheme XML veliko možnosti za natančno
definicijo podatkovnih tipov v shemi – od definicije samega podatkovnega tipa, do definicij
minimalne in maksimalne vrednosti številčnih tipov, dolžino tekstovnih podatkov,
omogočajo pa tudi uporabo regularnih izrazov. Zaradi teh lastnosti sheme XML omogočajo
veliko možnosti za validacijo podatkov, kar je priročno za pripravo zapletenih podatkovnih
struktur in olajša razvoj končnemu razvijalcu, ki mu ni treba veliko skrbeti o implementaciji
podatkovnih struktur.
3.2.3. Jezik za opis storitev WSDL
WSDL (angl. Web Service Definition Language) je jezik za opis oziroma definicijo
vmesnikov spletnih storitev, ki temelji na jeziku XML. Namen jezika je, da omogoči opis
funkcionalnosti spletne storitve. S prehodom iz verzije 1.1. na verzijo 2.0. se je spremenil
naziv jezika, in sicer iz jezika za opis spletnih storitev v jezik za definicijo spletnih storitev.
Izraz WSDL uporabljamo tudi za opis specifične storitve, ki smo jo že definirali s pomočjo
jezika WSDL. V takšnem primeru to po navadi imenujemo kar datoteka WSDL. Definicija
WSDL dokumenta verzije 1.1., kot tudi 2.0., je prikazana na sliki 3.5. [24] Dokument WSDL
definira vse elemente, ki so potrebni za uporabo spletne storitve s strani uporabnika.
Elementi jezika WSDL verzije 1.1 so naslednji:
S t r a n | 16
‒ element »types« definira podatkovne tipe, ki se uporabljajo v sporočilu. Za definicijo
uporablja tehnologijo XSD. Shemo lahko definiramo v dokumentu WSDL ali pa
referenciramo pot do datoteke s shemo;
‒ element »message« definira sporočila za operacije;
‒ element »portType« definira spletno storitev z njenimi operacijami, dokument WSDL
pa lahko vsebuje več teh elementov;
‒ element »binding« definira tip sporočila in protokol, ki je uporabljen za prenos;
‒ element »service« definira ime storitve, prav tako pa tudi lokacijo, kjer bo le-ta
dosegljiva.
Slika 3.5 Definicija dokumenta WSDL verzije 1.1. in 2.0 [24]
3.2.4. Specifikacije WS-Security
WS-Security oziroma WSS je razširitev protokola SOAP, namenjena zagotavljanju
varnosti na področju spletnih storitev. WSS so izdali s strani skupine OASIS in je del
specifikacij spletnih storitev.
Namen specifikacij WSS je zagotoviti tri glavne mehanizme:
‒ podpisovanje sporočil SOAP za zagotavljanje integritete sporočil,
‒ enkripcija sporočil za zagotavljanje zasebnosti komunikacije,
‒ omogočiti uporabo varnostnih žetonov, da potrdimo identiteto pošiljatelja sporočil.
S t r a n | 17
Specifikacija dovoljuje več različnih načinov podpisovanja, algoritmov za enkriptiranje,
kot tudi uporabo različnih varnostnih žetonov, kot so kombinacija uporabniškega imena in
gesla, žetoni Kerberos ali certifikati X.509. WS-Security deluje z vključevanjem varnostnih
komponent v glavo dokumenta SOAP. Način delovanja WS-Security je prikazan na sliki 3.6.
WS-Security omogoča možnosti za varnost od konca do konca (angl. end-to-end
security). V takšnem primeru je treba sporočila podpisati in enkriptirati. Mehanizmi, ki jih
WS-Security specifikacija ponuja, so le del varnostne rešitve za spletne storitve,
odgovornost pa je na strani tistega, ki rešitev implementira, da zagotovi rešitev, ki je dovolj
varna. [25]
Slika 3.6 Delovanje WS-Security [16]
3.2.5. Jezik XPath
XPath ali XML Path Language je jezik, ki omogoča povpraševanje po delih
dokumenta XML. Jezik je definiral konzorcij W3C, temelji pa na drevesni predstavitvi
dokumenta XML. Ponuja možnosti navigiranja po drevesu in izbiro posameznih vozlišč na
podlagi številnih kriterijev. Najnovejša različica jezika je 3.0, čeprav je različica 1.0 še vedno
najbolj razširjena in uporabljena. [26]
Najbolj pomemben izraz v jeziku XPath je lokacijska pot (angl. location path). Pot do
lokacije je sestavljena iz lokacijskih korakov. Vsak lokacijski korak je sestavljen iz treh delov:
os, test vozlišča in nič ali več predikatov. Os definira smer iskanja vozlišč (primer: »child«
definira otroke v drevesu), test vozlišča in predikati pa filtrirajo rezultate, ki smo jih dobili po
osi. [26] Primer uporabe jezika XPath smo prikazali v opisu ogrodja TIBCO ActiveMatrix
BusinessWorks, za preslikavo podatkov med aktivnostmi, na sliki 4.9.
S t r a n | 18
3.2.6. Jezik za povpraševanje XQuery
XQuery je jezik za povpraševanje, kot tudi funkcijski programski jezik, ki je namenjen
povpraševanju in transformaciji podatkov. Razvila ga je delovna skupina pod okriljem
konzorcija W3C. Najbolj pogosto povpraševanje izvajamo nad podatki XML, lahko pa se
izvajajo tudi nad tekstovnimi ali drugimi specifičnimi formati podatkov, ki bi se lahko
predstavili tudi kot dokumenti XML. Primer takšnega formata podatkov so relacijske
podatkovne baze. XQuery uporablja enak podatkovni model kot XPath. XPath predstavlja
podmnožico jezika XQuery. XQuery uporablja tako imenovane izraze FLWOR v stilu jezika
SQL. Termin FLWOR izhaja iz prvih črk ukazov, ki se uporabijo v takšni strukturi: FOR,
LET, WHERE, ORDER BY, RETURN. [27]
Najnovejša verzija XQuery 3.0 je postala leta 2014 priporočilo konzorcija W3C. Ena od
novosti, ki jo le-ta prinaša, je celovita podpora za funkcijsko programiranje.
3.2.7. Jezik BPEL
WS-BPEL ali na kratko BPEL (angl. Business Process Execution Language) je izvršljiv
jezik, ki je namenjen določanju akcij v poslovnih procesih, ki uporabljajo spletne storitve.
[28] Tudi jezik BPEL temelji na tehnologiji XML, standard za jezik pa je leta 2004 postavila
skupina OASIS. Jezik je definiran s pomočjo shem XSD. Za izvrševanje procesov,
definiranih v tem jeziku, potrebujemo tudi okolje, ki zna izvajati procese, ki so definirani s
pomočjo jezika BPEL. [29]
Jezik BPEL je namenjen orkestraciji in ne koreografiji. S pomočjo jezika BPEL
definiramo potek poslovnega procesa in procesno logiko uporabe spletnih storitev, ki so
vključeni v proces. Jezik omogoča določene funkcionalnosti, ki so podobne standardnim
programskim jezikom, kot so zanke ali vejitve. V jeziku BPEL ločimo med izvršljivimi procesi
in abstraktnimi procesi. Abstraktni procesi so procesi, ki niso namenjeni dejanskemu
izvajanju. Abstraktni procesi določajo splošno obnašanje izmenjave sporočil med
vključenimi stranmi (npr. kdaj čakati sporočilo ali kdaj poslati sporočilo). Po drugi strani
izvršljivi procesi opisujejo dejansko obnašanje udeležencev in sledijo principom orkestracije
storitev. [30]
3.3. Storitveno vodilo
Storitveno vodilo (angl. Enterprise Service Bus) ali ESB je programsko-arhitekturni
model, ki se uporablja za komunikacijo med različnimi sistemi v storitveno usmerjeni
arhitekturi. Obstajajo številne definicije, ki opredeljujejo storitveno vodilo. Ena izmed njih je
S t r a n | 19
naslednja: »Storitveno vodilo je arhitektura, ki uporablja spletne storitve, sporočilno
povezovalno programje, inteligentno usmerjanje in transformacijo. Le-to mora podpirati
komunikacijo preko zahtevkov in odgovorov med šibko sklopljenimi SOA poslovnimi
komponentami in enosmerno dostavo sporočil za pošiljanje obvestil dogodkovno-vodenim
poslovnim komponentam. Prav tako mora dovoljevati bolj kompleksne vzorce izmenjave
sporočil«. [31] Model storitvenega vodila je prikazan na sliki 3.7.
Slika 3.7 Model storitvenega vodila [32]
Storitveno vodilo je med drugim namenjeno reševanju težav s skalabilnostjo in
nekompatibilnostjo v velikih sistemih. Neposredno povezovanje dveh storitev ali komponent
predstavlja povezovanje od točke do točke (angl. point-to-point). V primeru velikih in
kompleksnih sistemov postane vzdrževanje mreže povezav od točke do točke zelo
zahtevno in zamudno. Ob predpostavki, da je vsak sistem povezan z vsakim drugim
sistemom, število potrebnih povezav raste kvadratno, število vseh povezav pa lahko
izračunamo s pomočjo formule n*(n-1)/2. [31]
Prav tako, kot je razvidno iz slike 3.7, ponuja storitveno vodilo tudi možnosti
»prevajanja« oziroma posredovanja med različnimi komunikacijskimi protokoli, s čimer
omogoča večjo neodvisnost med posameznimi komponentami.
S t r a n | 20
Lastnosti storitvenega vodila v veliki meri izhajajo iz definicije, ki smo jo prej zapisali.
Ena izmed ključnih lastnosti le-tega je inteligentno usmerjanje. Ideja za inteligentno
usmerjanje je, da tistemu, ki pošilja sporočilo na storitveno vodilo, ni treba vedeti, kje je
končna destinacija oziroma prejemnik sporočila. To informacijo ima storitveno vodilo in le-
to skrbi za posredovanje spročila na končni cilj, kot tudi za posredovanje odgovora iz
končnega sistema nazaj k tistemu, ki je zahteval odgovor. [31]
Še ena lastnost, ki je prisotna pri sodobnih storitvenih vodilih, je preslikava podatkov.
Šibka sklopljenost ima pogosto za posledico stanje, kjer je na voljo le nekaj osnovnih
podatkovnih tipov. Ena izmed možnih rešitev je preslikava oziroma transformacija podatkov
na nivoju storitvenega vodila. V takšnem primeru je seveda treba definirati pravila
transformacij na storitvenem vodilu. [13]
Zelo pomembna lastnost storitvenih vodil je tudi zanesljivost. Komunikacijski protokoli,
kot je HTTP, ne zagotavljajo, da bo sporočilo dostavljeno enkrat in le enkrat. Implementacija
storitvenih vodil z uporabo vzorcev za izmenjavo sporočil (angl. message exchange
patterns) pa zagotavlja robustno izmenjavo sporočil, kot tudi transakcijsko obnašanje.
Pogosto storitveno vodilo uporabljamo tudi za nadzor in beleženje komunikacije. Zaradi
tega, ker je storitveno vodilo v osrčju arhitekture in naj bi preko njega potekala praktično
celotna komunikacija med akterji v sistemu, je tudi idealna lokacija za implementacijo
mehanizmov za nadzor (angl. monitoring) in beleženje (angl. logging) komunikacije.
Posledično lahko storitveno vodilo služi kot orodje za razhroščevanje porazdeljenih
procesov, ki tečejo na različnih sistemih. [13]
Ena izmed lastnosti storitvenega vodila je tudi skrb za varnost. Zaradi tega, ker ima
storitveno vodilo vlogo komunikacijske hrbtenice v arhitekturi, je varnost ključnega pomena.
Pogosto je za varnost poskrbljeno z uporabo standarda WS-Security.
S t r a n | 21
4. Ogrodje TIBCO ActiveMatrix BusinessWorks
Skupaj z rastjo potreb in razvojem novih tehnologij se je razvijala namenska programska
oprema za integracijo poslovnih aplikacij. Praktično so vsi proizvajalci poslovne programske
opreme pripravili svoje rešitve na področju integracije poslovnih aplikacij. Gartner je v svoji
analizi za programsko opremo za integracijo aplikacij z lokalno namestitvijo (angl. on-
premises software) med vodilne ponudnike na tem področju vključil naslednje produkte:
[33]
‒ IBM Websphere Integration Bus,
‒ Microsoft BizTalk Server,
‒ Oracle Fusion Middleware,
‒ Software AG webMethods,
‒ SAP NetWeaver in
‒ TIBCO ActiveMatrix BusinessWorks.
Gartnerjev magični kvadrant za ogrodja za integracijo poslovne programske opreme je
prikazan na sliki 4.1.
S t r a n | 22
Slika 4.1: Gartnerjev magični kvadrant za ogrodja za integracijo [34]
Kot na drugih področih računalništva prinaša računalništvo v oblaku spremembe tudi
na področju integracije poslovnih aplikacij. Podjetja, ki ponujajo ogrodja za integracijo
poslovnih aplikacij, sedaj ponujajo tudi ogrodja, ki so na voljo kot storitev (angl. Integration
Platform as a Service oziroma iPaaS). Ponudba integracij poslovnih aplikacij v oblaku raste
predvsem zaradi razlogov skalabilnosti in hitrosti razvoja, še posebej na področju rešitev
B2B in zalednih sistemov za mobilne aplikacije. [35] Tehnologije so še v nastajanju, vendar
Gartner napoveduje, da bo že leta 2019 večina projektov integracij poslovnih aplikacij
izdelanih z uporabo iPaaS. [36]
S t r a n | 23
4.1. Primerjava različnih programskih ogrodij za integracijo poslovnih
aplikacij
Primerjava različnih ogrodij za integracijo poslovnih aplikacij je lahko zelo zahtevna, saj
se orodja razlikujejo po uporabljenih konceptih, tehnologijah, namenu, kot tudi po stroških,
ki jih organizacije imajo z vpeljavo tehnologij.
Podjetje Appvance je leta 2013 pripravilo primerjavo različnih ogrodij za integracijo
poslovnih aplikacij z naslovom »SOA Integration Knowledge Kit«. [37] Primerjava je
potekala na način, da so zastavili problemsko-usmerjeno nalogo s področja integracije
poslovnih aplikacij, ki so jo potem razvijalci implementirali v različnih okoljih: TIBCO
ActiveMatrix BusinessWorks, IBM Websphere Process Server, SoftwareAG WebMethods,
Oracle BPM Server in Redhat JBoss SOA Platform. Po razvoju prvotne naloge, kjer so
implementirali več identičnih procesov v vseh okoljih, je bilo treba implementirati določene
spremembe, ki so predstavljale vzdrževanje okolja, npr. spremembo načina komunikacije
(iz JMS v HTTP), nastavitev višjega nivoja varnosti (avtentikacija), spremembo podatkov
oziroma sheme XSD.
Razvijalci niso bili izkušeni pri uporabi teh orodij in so morali na začetku tudi sami
namestiti razvojna okolja. Razvijalci so kot glavni vir podatkov uporabljali dokumentacijo, ki
je bila na voljo s strani proizvajalcev integracijskih ogrodij. Vsak razvijalec je svoje izkušnje
z orodjem zapisoval v dnevnik razvoja, ki so jih kasneje analizirali, na koncu pa pripravili
tudi model za celotne stroške lastništva programske opreme, ki so jo razvili (angl. Total Cost
of Ownership, oziroma TCO). Nekaj glavnih opomb, ki so jih razvijalci zapisali v dnevnikih,
smo povzeli v nadaljevanju. [38]
TIBCO ActiveMatrix BusinessWorks:
‒ veliko število programskih produktov, posledično strma krivulja učenja,
‒ enostavna namestitev vseh produktov,
‒ zastareli videz orodja TIBCO Designer,
‒ enostavna uporaba strežnika EMS s konzolno aplikacijo TIBCO EMSadmin,
‒ enostavni razvoj od zgoraj navzdol, bolj zapleten razvoj od spodaj gor.
IBM Websphere Process Server:
‒ dobra ločitev nivoja poslovne logike in transportnega nivoja,
‒ dokumentacija, ki je na voljo, je odlična,
‒ razvojno okolje zahteva zmogljivo strojno opremo,
S t r a n | 24
‒ enostavno grafično oblikovanje procesov BPEL.
SoftwareAG Webmethods:
‒ dobro deluje v primeru celovitega modeliranja procesov,
‒ enostavno oblikovanje poslovnih procesov,
‒ ponuja možnosti avtomatskega generiranja grafičnih vmesnikov, vendar je
avtomatiziran postopek zahteven,
‒ za JavaEE je potrebno predhodno spoznavanje številnih komponent ogrodja
Webmethods.
Oracle BPM Server:
‒ težavna namestitev (več GB namestitvenih datotek, težave s kompatibilnostjo
posameznih komponent),
‒ nejasnosti glede tega, katero razvojno orodje naj bi razvijalec uporabil za razvoj
spletnih storitev,
‒ Oracle Weblogic ima svoj strežnik JMS, ki ga lahko enostavno uporabimo za
komunikacijo.
JBoss SOA Platform:
‒ odprtokodno orodje,
‒ zahteven postopek namestitve in prilagajanja razvojnega okolja,
‒ »nerodna« grafična podpora za modeliranje poslovnih procesov,
‒ v veliki meri se zanaša na pisanje oziroma spreminjanje kode ali ročno spreminjanje
konfiguracij,
‒ zahtevne spremembe logike, ki smo jo že pripravili.
Rezultati glede skupnega stroška lastništva na tem testnem primeru, do katerih so prišli
v podjetju Appvance, so prikazani v tabeli 4.1. Kot je razvidno iz tabele, ima najnižji skupni
strošek lastništva ogrodje TIBCO, drugi najnižji ogrodje IBM, najvišji skupni strošek
lastništva pa so izračunali pri odprtokodnem ogrodju JBoss.
S t r a n | 25
Skupni strošek lastništva TIBCO IBM SoftwareAG Oracle JBoss
Namestitev 788 $ 762 $ 828 $ 1253 $ 788 $
Načrtovanje 418 $ 814 $ 1023 $ 418 $ 839 $
Učenje 694 $ 286 $ 162 $ 596 $ 681 $
Podpora 103 $ 478 $ 614 $ 103 $ 103 $
Priprava storitev ‒ sinhrono 422 $ 426 $ 305 $ 469 $ 469 $
Priprava storitev ‒ asinhrono 511 $ 793 $ 1027 $ 1355 $ 1074 $
Orkestracija 741 $ 694 $ 422 $ 511 $ 1777 $
Postavitev 307 $ 401 $ 354 $ 448 $ 483 $
Sprememba – varnost 422 $ 286 $ 520 $ 328 $ 1125 $
Sprememba – JMS 418 $ 426 $ 473 $ 469 $ 230 $
Sprememba – kompleksni XSD 277 $ 281 $ 188 $ 418 $ 324 $
Skupaj 5100 $ 5646 $ 5914 $ 6366 $ 7893 $
Tabela 4.1 Skupni stroški lastništva za različna integracijska ogrodja [37]
Gartner v svojem magičnem kvadrantu za orodja za integracijo poslovnih aplikacij
izpostavlja naslednje prednosti ogrodja TIBCO AMX BW: [34]
‒ TIBCO ima odlično zastopanost na velikem tržišču orodij za integracijo poslovnih
aplikacij;
‒ TIBCO ponuja obsežen nabor orodij, ki so se dokazale v praksi. Poleg orodij za
integracijo ponuja tudi sorodna orodja za modeliranje poslovnih procesov in
kompleksno procesiranje dogodkov, ki so uspešno integrirani z ogrodjem TIBCO
AMX BW;
‒ TIBCO nadaljuje marketinško »valovanje« na področju integracij z dvomesečnimi
aktivnostmi, ki se osredotočajo na integracije in vključujejo idejno vodstvo, spletne
seminarje in objave belih knjig.
Gartner v istem poročilu opozori tudi na naslednje zadeve:
‒ nezadostna podpora za komuniciranje na področju IoT (angl. Internet of Things);
‒ model licenciranja od strank pogosto zahteva več licenc, kot jih dejansko
potrebujejo, kar posledično vodi do višanja stroškov;
‒ različica ogrodja TIBCO AMX BW Express, ki je namenjena malim in srednjim
podjetjem, ni sprejeta na trgu, saj manjši uporabniki težijo k oblačnim rešitvam za
integracijo poslovnih integracij.
S t r a n | 26
V nadaljevanju bomo podrobno prikazali ogrodje TIBCO ActiveMatrix BusinessWorks.
4.2. Ogrodje TIBCO
Ime podjetja TIBCO Software, ki je razvilo ogrodje BusinessWorks, je okrajšava izraza
»The Information Bus Company«, kar v prevodu pomeni »Podjetje informacijskega vodila«.
Podjetje je bilo ustanovljeno leta 1997, in sicer kot nadaljevanje predhodnega podjetja
Teknekron Software Systems, ki je za potrebe banke Goldman Sachs razvilo prvo platformo
za elektronsko trgovanje na Wall Street. Podjetje se skozi leta nenehno razvija na področju
integracij, kot tudi na drugih področjih poslovne informatike in čeprav nima takšne medijske
publicitete, sta njegova glavna konkurenta IBM in Oracle. [39] Poleg področja integracije
poslovnih aplikacij razvija TIBCO še rešitve na področju računalništva v oblaku, kot tudi
poslovne analitike in poslovne inteligence. [33] Na področju integracij je najbolj uveljavljena
produktna skupina ActiveMatrix, ki je sestavljena iz več produktov, ki so namenjeni različnim
vidikom integracij s poudarkom na implementaciji storitveno usmerjene arhitekture v
podjetjih. Produkti, ki sestavljajo produktno skupino TIBCO ActiveMatrix, so: [40]
‒ TIBCO BusinessWorks je osrednji del programskega paketa ActiveMatrix in
omogoča razvoj in orkestracijo storitev,
‒ TIBCO ActiveMatrix Service Bus je storitveno vodilo,
‒ TIBCO ActiveMatrix Service Grid je orodje za izgradnjo storitveno usmerjene
arhitekture na podlagi obstoječe programske opreme, ki je lahko programska
oprema, implementirana v različnih tehnologijah,
‒ TIBCO ActiveMatrix Adapters so številne programske komponente, ki so namenjene
enostavnemu povezovanju različnih sistemov (na primer adapter Salesforce,
adapter za protokol LDAP ali adapter za računalnike CISC) v storitveno usmerjeni
arhitekturi, ki temelji na produktih TIBCO ActiveMatrix,
‒ TIBCO ActiveMatrix BPM je programski paket, namenjen upravljanju poslovnih
procesov,
‒ TIBCO ActiveMatrix Lifecycle Governance Framework je ogrodje, ki podjetjem
ponuja možnosti za upravljanje življenjskih ciklov storitev, repozitorij in register
storitev.
Produkti, ki so znotraj produktne skupine TIBCO ActiveMatrix, so prikazani na sliki 4.2.
S t r a n | 27
Slika 4.2 Produktna skupina TIBCO ActiveMatrix [40]
4.3. Ogrodje TIBCO ActiveMatrix BusinessWorks
TIBCO ActiveMatrix BusinessWorks (v nadaljevanju BW) je orodje za razvoj in
modeliranje poslovnih procesov ter vzpostavitev storitveno usmerjene arhitekture. Trenutno
aktualna različica BW je 6.3. Verzija 6 je prinesla temeljito prenovo BW. Ena izmed glavnih
sprememb je bila sprememba orodja, ki se uporablja za načrtovanje aplikacij. V prejšnjih
različicah je bilo to mogoče z orodjem TIBCO Designer, sedaj pa se uporablja prilagojena
različica razvojnega okolja Eclipse. BW je spisan v programskem jeziku Java, kar omogoča
neodvisnost od platforme oziroma operacijskega sistema. V okviru te diplomske naloge smo
se zaradi praktične uveljavljenosti, dostopnosti virov in dokumentacije odločili za uporabo
in predstavitev BW različice 5.13.
Značilnost, s katero se ponaša ogrodje BW, je tako imenovana brezkodna integracija
(angl. zero-code-required integration). [41] BW preko svojih grafičnih vmesnikov ponuja
možnosti integracije poslovnih aplikacij, kot tudi razvoj novih aplikacij in procesov brez
pisanja ene vrstice kode. Prednost tega je, da v integraciji poslovnih procesov lahko
sodelujejo osebe, ki nimajo poglobljenih znanj iz področja informacijskih tehnologij oziroma
programiranja in je dovolj, da so seznanjeni s poslovnimi procesi, ki jih modelirajo oziroma
razvijajo. Pri tem pa se lahko posvetijo predvsem poslovni logiki oziroma dodani vrednosti,
ki jo razvoj nove poslovne logike prinaša, namesto da se ukvarjajo s tehničnimi vidiki same
izvedbe te poslovne logike.
Ogrodje BW je sestavljeno iz več elementov, izvajanje pa poteka znotraj komponente
TIBCO Runtime Agent. TIBCO Runtime Agent je »skupek programske opreme TIBCO
Software, kot tudi tretjih proizvajalcev, ki je potrebna za izvajanje številnih aplikacij TIBCO,
S t r a n | 28
kot so TIBCO BW in in adapterji TIBCO«. [42] Komunikacijo med posameznimi deli ogrodja
BusinessWorks smo prikazali na sliki 4.3.
Slika 4.3 Arhitektura komunikacije znotraj domene BusinessWorks [43]
4.4. Adapterji
Eden izmed namenov povezovalnega programja je, da omogoči komunikacijo med
različnimi aplikacijami oziroma podatkovnimi viri, ki so spisani v različnih tehnologijah, na
različnih platformah, s popolnoma drugačnimi podatkovnimi strukturami, s tehnologijami, ki
so nastajale v različnih časovnih obdobjih. Z namenom, da omogoči čim lažjo, enostavno
in hitro integracijo različnih sistemov znotraj enega podjetja, ogrodje BW ponuja tako
imenovane »priključke« (angl. connectors), ki jih najdemo tudi pod imenom TIBCO
Adapterji.
Obstaja več vrst TIBCO Adapterjev, in sicer glede na namen oziroma področje, za
katero se uporabljajo. Obstajajo adapterji, ki so namenjeni enostavnemu integriranju
popularnih sistemov CRM ali ERP, kot so SAP, Microsoft Dynamics CRM ali Salesforce.
Obstajajo adapterji, ki so namenjeni posameznim tehnologijam za obstoječe sisteme, kot
tudi adapterji za povezave z različnimi podatkovnimi bazami (Oracle, MS SQL, MySQL itd.).
S t r a n | 29
Adapterji hkrati omogočajo komunikacijo med različnimi aplikacijami in sistemi na eni strani
in sporočilnim sistemom na strani TIBCO, prav tako pa izolirajo kompleksnost in specifike
posamezne aplikacije oziroma sisteme od drugih aplikacij. [44] V času obsežnih povezovanj
med zelo različnimi sistemi uporaba adapterjev podjetjem prihrani čas in olajša povezovanje
z različnimi sistemi, ki bi ga sicer podjetja morala implementirati sama. Povezovanje
različnih sistemov s pomočjo adapterjev TIBCO je prikazano na sliki 4.4.
Slika 4.4: Adapterji TIBCO povezujejo različne sisteme [44]
4.5. Orodje TIBCO Administrator
Orodje TIBCO Administrator je namenjeno upravljanju aplikacij v ogrodju BW.
Sestavljeno je iz dveh glavnih komponent: administrativnega strežnika in grafičnega
vmesnika TIBCO Adminstrator. Naloga administrativnega strežnika je upravljanje virov
znotraj svoje administrativne domene, medtem ko grafični vmesnik uporabnikom omogoča
nameščanje, konfiguracijo in nadzor aplikacij, kot tudi upravljanje uporabniških računov.
[45] Grafični vmesnik TIBCO Administrator ponuja naslednje module: upravljanje
uporabnikov (angl. User Management), upravljanje aplikacij (angl. Application
Management), upravljanje virov (Resource Management) in upravljanje nadzora (angl.
Monitoring Management). Grafični vmesnik TIBCO Administrator je predstavljen na sliki 4.5.
TIBCO Administrator se uporablja tudi za upravljanje z drugimi aplikacijami, ki se izvajajo v
TIBCO Runtime Agent, kot so na primer aplikacije za kompleksno procesiranje dogodkov
(angl. complex event processing), ki so pripravljene z uporabo ogrodja TIBCO
BusinessEvents.
S t r a n | 30
Slika 4.5: Grafični vmesnik komponente TIBCO Administrator
Poleg upravljanja preko grafičnega vmesnika TIBCO Administrator TIBCO AMX BW
omogoča tudi upravljanje aplikacij preko skript oziroma preko ukazne vrstice. Uporabnikom
je s tem namenom na voljo konzolna aplikacija AppManage, s pomočjo katere lahko tudi
avtomatizirajo upravljanje aplikacij.
TIBCO Administrator omogoča tudi različne možnosti glede nameščanja aplikacije na
različne računalnike znotraj domene TIBCO. Z nameščanjem aplikacije na več različnih
računalnikov povečamo skalabilnost, robustnost in dostopnost storitev. S pomočjo
programske opreme za izenačevanje obremenitve (angl. load balancing) lahko porazdelimo
obremenitev na več strežnikov, zagotovimo delovanje aplikacij oziroma storitev v primeru
izpada enega ali več računalnikov, prav tako pa zagotovimo ničelni čas izpada v primeru
vzdrževanja aplikacij. [45]
4.6. Orodje TIBCO Hawk
Orodje TIBCO Hawk je dogodkovno-usmerjeno orodje za nadzorovanje, ki temelji na
konceptu porazdeljenih in avtonomnih pametnih agentov, ki se izvajajo na vsakem
računalniku znotraj mreže. Naloga orodja Hawk je nadzorovati delovanje vseh računalnikov
in aplikacij, ki so del domene TIBCO. Arhitektura orodja Hawk je predstavljena na sliki 4.4.
S t r a n | 31
Slika 4.6 Arhitektura orodja TIBCO Hawk za monitoriranje. [46]
TIBCO Hawk za komunikacijo med posameznimi komponentami uporablja eno izmed
treh možnosti. Privzeta izbira je TIBCO Rendezvous, ki je komunikacijski protokol, razvit s
strani podjetja TIBCO. Rendezvous omogoča robustni sistem izmenjave podatkov preko
omrežja in podpira širok nabor sistemov, s čimer omogoča komunikacijo med različnimi
aplikacijami, ki so lahko tudi na različnih operacijskih sistemih. [46] Drugi dve izbiri sta
TIBCO DataGrid, ki je porazdeljeno pomnilniško podatkovno polje (angl. Distributed in-
memory data grid), in TIBCO EMS (angl. Enterprise Messaging Service).
4.7. Orodje TIBCO Designer
Orodje TIBCO Designer je grafično orodje za načrtovanje BW aplikacij. Je orodje, ki
uporabnikom omogoča razvoj TIBCO BW-aplikacij s pristopom »povleci in spusti«
gradnikov, ki jih ponuja. Rezultat aplikacije je datoteka EAR (Enterprise Archive), ki jo lahko
s pomočjo aplikacije TIBCO Administrator namestimo v okolje TIBCO. Poleg aplikacij lahko
s pomočjo grafičnega orodja TIBCO Designer razvijamo tudi knjižnice. V knjižnicah
shranimo poslovno logiko (procese, povezave do virov, kot so podatkovne baze ali spletne
S t r a n | 32
storitve itd.), ki jih lahko ponovno uporabimo v različnih projektih oziroma aplikacijah. Videz
orodja TIBCO Designer je predstavljen na sliki 3.
Slika 4.7: Videz orodja TIBCO Designer
Uporabnik grafičnega orodja TIBCO Designer lahko gradi poslovno logiko z uporabo
posameznih komponent, ki so organizirane znotraj palet. Palete vsebujejo komponente, ki
se nanašajo na posamezno logično področje: komunikacija s podatkovno bazo,
komunikacija s strežnikom JMS, klici SOAP, Java koda itn. Podatki v procesih so definirani
pretežno preko shem XSD, vsakemu elementu pa se definira vhodna oziroma izhodna
struktura podatkov.
Podatki se med posameznimi komponentami prenašajo s pomočjo izrazov XPath.
Jezik XPath omogoča izbiro in določeno stopnjo transformacije podatkov XML, ki so
uporabljeni znotraj komponent. Poleg standardnih izrazov XPath TIBCO Designer
uporabnikom omogoča, da naložijo tudi svoje metode, ki so programirane v programskem
jeziku Java.
4.8. Palete
Za razvoj aplikacij v ogrodju BusinessWorks lahko uporabimo veliko število že
pripravljenih komponent, ki so na voljo za specifične namene. Vsaka komponenta ima
specifični namen in se nanaša na določeno področje, kot na primer komponente JDBC,
S t r a n | 33
komponente XML, komponente SOAP, komponente, ki se nanašajo na adapterje in
podobno. Skupine, v katere so razvrščene komponente, imenujemo palete. V ogrodju
TIBCO AMX BW imamo tudi možnost, da sami sestavimo svoje lastne palete oziroma
komponente.
Na sliki 5 so prikazane komponente, ki so del palete General Activities (Splošne
aktivnosti). V spodnjem delu slike so vidne tudi ostale palete, ki so del standardnega
programskega paketa.
Slika 4.8: Palete v ogrodju TIBCO AMX BW
4.9. Procesi
Osnova za razvoj aplikacij z uporabo ogrodja BusinessWorks so procesi. Proces
oziroma definicija procesa (angl. Process definition) je grafična predstavitev dejanskega
poslovnega procesa, ki se odvija v nekem poslovnem okolju [47]. Procesi lahko vsebujejo
naslednje komponente: aktivnosti, tranzicije med posameznimi aktivnostmi, skupine,
deljene konfiguracijske vire in podprocese [47]. Pod pojmom aktivnosti razumemo
S t r a n | 34
posamezne enote, ki opravljajo določeno delo znotraj definicije procesa. Tranzicije so
povezave med aktivnostmi, ki definirajo potek poslovnega procesa. Tranzicije lahko
vsebujejo tudi pogoje, na podlagi katerih usmerjamo oziroma krmilimo izvajanje procesa.
Skupine so, kot izhaja iz samega imena, namenjene grupiranju posameznih aktivnosti z
namenom doseganja transakcijskega delovanja ali obnašanju, ki je podobno zankam v
programskem jeziku. Pod pojmom skupni konfiguracijski viri podrazumevamo specifikacije,
ki si jih aktivnosti delijo: povezave do podatkovnih baz, povezave HTTP, povezave do
strežnikov JMS, datoteke WSDL ipd.
V okolju BusinessWorks se vsak proces začne z aktivnostjo Start in konča z aktivnostjo
End. Izjema so procesi, ki se začnejo z aktivnostjo, ki je tako imenovan sprejemnik, in kjer
se proces začne s klicem od zunaj. Primer takšnih aktivnosti so sprejemnik HTTP (angl.
HTTP receiver) ali sprejemnik JMS (angl. JMS receiver). Procesi lahko vsebujejo tudi klice
drugih procesov oz. podprocesov. Za klic podprocesov uporabimo aktivnost »Call
Process«. Vhodni podatki pri aktivnosti za klic procesa se pojavijo kot podatki na začetni
aktivnosti v podprocesu, medtem so podatki na končni aktivnosti v podprocesu izhodni
podatki aktivnosti za klic procesa.
Podatki se pri izvajanju procesa prenašajo iz aktivnosti v aktivnost s pomočjo izrazov
XPath. Aktivnosti lahko uporabljajo podatke od aktivnosti, ki so se predhodno že izvedle, ali
od globalnih spremenljivk ali od kontekstnih podatkov procesa. Prenos oziroma preslikava
podatkov je prikazana na sliki 4.6. Za vsak proces je treba definirati, kakšno obliko podatkov
pričakuje na začetku procesa (na Start aktivnosti), kot tudi kakšno obliko podatkov vrne (na
aktivnosti End).
Slika 4.9 Prikaz preslikave podatkov v aktivnost End.
Proces se shrani v datoteko tipa .process, v osnovi pa gre za datoteko XML, kjer so
shranjeni podatki o aktivnostih in prehodih v procesu. Vsebina datoteke
S t r a n | 35
GetAllUsers.process iz praktičnega primera v sklopu te naloge je prikazana na izvorni kodi
4.1. Kot je prikazano, so v datoteki tipa .process zapisane vse lastnosti, ki jih potrebujemo
za definicijo procesa: aktivnosti, prehodi med aktivnostmi, sheme, kot tudi meta-podatki, ki
so potrebni za grafični prikaz procesa v orodju TIBCO Designer.
<?xml version="1.0" encoding="UTF-8"?> <pd:ProcessDefinition xmlns:pd="http://xmlns.tibco.com/bw/process/2003" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:pfx2="http://xmlns.example.com/1458463069852" xmlns:pfx="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd"> <xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema" namespace="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd" schemaLocation="/Resources/XSD/GeneralSchema.xsd"/> <wsdl:import namespace="http://xmlns.example.com/1458463069852" location="/Resources/WSDL/WSDL.wsdl"/> <pd:name>Processes/Public/GetAllActiveUsers.process</pd:name> <pd:startName>Start</pd:startName> <pd:startType wsMsgRef="pfx2:GetAllUsersRequest"/> <pd:startX>152</pd:startX> <pd:startY>64</pd:startY> <pd:returnBindings> <pfx2:GetAllUsersResponse> <part1> <xsl:copy-of select="$GetAllUsers/pfx:GetAllUsersResponse"/> </part1> </pfx2:GetAllUsersResponse> </pd:returnBindings> <pd:endName>End</pd:endName> <pd:endType wsMsgRef="pfx2:GetAllUsersResponse"/> <pd:endX>647</pd:endX> <pd:endY>63</pd:endY> <pd:errorSchemas/> <pd:processVariables/> <pd:targetNamespace>http://xmlns.example.com/1452964156881</pd:targetNamespace> <pd:activity name="GetAllUsers"> <pd:type>com.tibco.pe.core.CallProcessActivity</pd:type> <pd:resourceType>ae.process.subprocess</pd:resourceType> <pd:x>388</pd:x> <pd:y>64</pd:y> <config> <processName>/Processes/Business/GetAllUsers.process</processName> </config> <pd:inputBindings> <pfx:GetAllUsersRequest/> </pd:inputBindings> </pd:activity> <pd:transition> <pd:from>Start</pd:from> <pd:to>GetAllUsers</pd:to> <pd:lineType>Default</pd:lineType> <pd:lineColor>-16777216</pd:lineColor> <pd:conditionType>always</pd:conditionType> </pd:transition> <pd:transition> <pd:from>GetAllUsers</pd:from> <pd:to>End</pd:to> <pd:lineType>Default</pd:lineType> <pd:lineColor>-16777216</pd:lineColor> <pd:conditionType>always</pd:conditionType> </pd:transition> </pd:ProcessDefinition>
Izvorna koda 4.1: Vsebina datoteke GetAllUsers.process
S t r a n | 36
4.10. Globalne spremenljivke
Z namenom lažjega konfiguriranja aplikacij omogoča ogrodje TIBCO AMX BW uporabo
globalnih spremenljivk. Namenjene so spreminjanju raznih konfiguracijskih podatkov, ki ne
zahtevajo sprememb samih poslovnih procesov (naslovi, uporabniška imena, gesla ipd.).
Do globalnih spremenljivk imajo dostop vse aktivnosti v vseh procesih, zaradi česar so
priročne za uporabo skupnih vrednosti. Termin globalnih spremenljivk je v tem kontekstu
rahlo zavajajoč, saj v času izvajanja aplikacij globalnih spremenljivk ni možno spreminjati.
Za spremembo vrednosti globalnih spremenljivk ni potreben dostop do izvorne kode,
spreminjamo jih lahko preko orodja TIBCO Administrator. Na ta način se lahko razmeji
operativni del vzdrževanja aplikacije od razvoja aplikacij.
S t r a n | 37
»In theory, theory and practice are the same.
In practice, they are not«. L. Berra
5. PRAKTIČNI PRIMER INTEGRACIJE POSLOVNIH APLIKACIJ
Praktični primer integracije poslovnih aplikacij bomo predstavili na primeru fiktivnega
mobilnega operaterja. Razlog, zaradi katerega smo se odločili za mobilnega operaterja, je
narava dela pri mobilnih operaterjih, kjer pogosto srečamo uporabo množičnih poslovnih
aplikacij za različne segmente poslovanja: programsko opremo CRM za odnose s
strankami, specifično programsko opremo za zaračunavanje (angl. billing software),
programsko opremo za predplačniške uporabnike, programsko opremo za klicni center ipd.
Hkrati pa obstajajo tudi različni kanali komunikacije s strankami: preko fizičnih poslovalnic,
kjer zaposleni uporabljajo poslovno programsko opremo za omogočanje storitev strankam,
preko spletnih portalov za samooskrbo strank (angl. Self-care), preko sporočil SMS,
komunikacije M2M (machine-to-machine) s poslovnimi strankami itn.
Pomembna pojma pri telekomunikacijskih sistemih sta OSS (Operations System
Support) in BSS (Business Systems Support). Izraz OSS uporabljamo za računalniške
sisteme, ki jih telekomunikacijska podjetja uporabljajo za upravljanje s svojimi omrežji. [48]
Po navadi v sisteme OSS štejemo sisteme, ki skrbijo za konfiguracijo omrežja in
zagotavljanje storitev (angl. service provisioning). Po drugi strani kot sisteme BSS
označujemo sisteme, ki jih telekomunikacijski operaterji uporabljajo za poslovanje z
uporabniki. [49] V te sisteme štejemo sisteme za upravljanje s produkti, upravljanje naročil,
upravljanje prihodkov in upravljanje strank. Skupaj sistemi OSS in BSS v
telekomunikacijskih podjetjih zagotavljajo storitve »od konca do konca« (angl. end-to-end)
končnim uporabnikom. Zaradi enostavnosti se bomo v praktičnem delu osredotočili na
omejen nabor pretežno sistemov BSS, ki bodo ponazorili koncepte, ki smo jih opisali
oziroma obravnavali v prejšnjih poglavjih.
S t r a n | 38
5.1. Pregled arhitekture
Arhitektura načrtovane rešitve za fiktivnega mobilnega operaterja je predstavljena na
sliki 5.1.
Slika 5.1: Predstavitev arhitekture praktične naloge
Zgornja arhitektura prikazuje možnosti, ki jih ponuja ogrodje BusinessWorks, saj
prikazuje možnosti povezovanja z različnimi sistemi in uporabo različnih tehnologij za
komunikacijo. Zaradi kompleksnosti in nedostopnosti produkcijskih sistemov, ki jih
uporabljajo mobilni operaterji, smo se odločili, da bomo pripravili enostavne kvazi-zaledne
sisteme v različnih tehnologijah, ki bodo komunicirali preko različnih kanalov in na ta način
prikazali zmogljivosti ogrodja TIBCO ActiveMatrix BusinessWorks.
Kot je razvidno iz slike 5.1, BW komunicira z več zalednimi sistemi našega fiktivnega
mobilnega operaterja. Zaledni sistemi so:
‒ podatkovna baza za naročnike, ki uporablja tehnologijo Microsoft SQL Server 2012,
‒ podatkovna baza za predplačnike, ki uporablja tehnologijo MySQL InnoDB 5.0,
‒ sistem enotne prijave za avtorizacijo uporabnikov, ki izpostavlja svoje metode preko
protokola SOAP,
S t r a n | 39
‒ sistem CRM, ki komunicira z BW preko sistema Enterprise Message Service (EMS).
EMS je implementacija standarda Java Message Service s strani podjetja TIBCO.
5.2. Implementacija storitev
Implementirali smo spletno storitev SOAP, ki ponuja naslednje operacije:
‒ CheckSSOAuthorization,
‒ GetAllUsers,
‒ GetCallsForUser,
‒ InsertCustomersUsage.
Poleg omenjene storitve SOAP smo pripravili tudi process ProcessUsageFile, ki se
zažene s spremembo oziroma dodajanjem ustrezne datoteke v predhodno določeno mapo.
Preden smo se lotili implementacije procesov, smo morali najprej definirati sheme XSD
(angl. XML Schema Definition) za podatke, s katerimi bomo operirali znotraj procesov. Za
potrebe praktičnega primera smo razvili dve shemi, Common.xsd, kjer smo definirali
kompleksne tipe, ki jih lahko kasneje uporabimo v drugih shemah, in MobileOperations.xsd,
kjer so definirani dejanski tipi podatkov, ki se uporabljajo kot vhodni ali izhodni tipi podatkov
na aktivnostih oziroma na procesih.
Za potrebe implementacije spletnih storitev smo oblikovali poslovne procese, ki so v
ogrodju TIBCO AMX BW predstavljeni z datotekami tipa .process. Kot primer dobre prakse
smo datoteke razdelili na tri nivoje: javne (public), poslovna logika (business) in podatkovni
procesi (data). Javni procesi so prvi procesi, ki se kličejo pri izvajanju operacij spletnih
storitev in usmerijo izvajanje k procesom s poslovno logiko. Če so javni procesi prvi procesi
pri klicu spletne storitve, sprejmejo na vhod sporočilo SOAP. Namen javnih procesov je tudi,
da če potrebujemo spremembo celotne poslovne logike, spremenimo samo klic poslovnega
procesa. Poslovni procesi vsebujejo dejansko poslovno logiko in operirajo nad podatki, ki
jih praviloma pridobijo iz podatkovnih procesov. Podatkovni procesi skrbijo za pridobitev
podatkov iz različnih zalednih oziroma obstoječih sistemov, njihov namen pa je tudi v
ponovni uporabi, saj lahko klice uporabimo iz različnih drugih procesov. [47]
Operacija CheckSSOAuthorization omogoča avtorizacijo uporabnika. Kot vhodne
podatke sprejme uporabniško ime in geslo, v primeru pozitivne avtorizacije pa vrne tudi
davčno številko uporabnika, kot tudi opombe iz sistema CRM. Poslovni proces
CheckSSOAuthorization je prikazan na sliki 5.2.
S t r a n | 40
Uporabo povezave JMS smo prikazali na primeru procesa GetCRMNotesForUser, in
sicer z uporabo aktivnosti »JMS Queue Requestor«. Podatkovni proces
GetCRMNotesForUser je prikazan na sliki 5.4.
Slika 5.2: Poslovni proces CheckSSOAuthorization
Proces demonstrira uporabo klicev SOAP v ogrodju BW, v primeru podatkovnega
procesa CheckSSOAuthorization. Proces kliče spletno storitev, ki smo jo razvili z uporabo
tehnologije WCF. Isti proces demonstrira tudi uporabo aktivnosti »SendMail«, preko katere
lahko pošljemo elektronsko sporočilo neposredno iz procesa s povezavo na e-poštni
strežnik SMTP. Elektronsko sporočilo pošljemo le v primeru, če pride do napake pri klicu
spletne storitve. Pogoj smo nastavili na povezavi med aktivnostma »SOAPRequestReply«
in »SendMail«. Podatkovni proces CheckSSOAuthorization je prikazan na sliki 5.3.
Slika 5.3: Podatkovni proces CheckSSOAuthorization
S t r a n | 41
Slika 5.4 Podatkovni proces GetCRMNotesForUser
Kar se tiče zalednega sistema za komunikacijo JMS, smo v ta namen pripravili preprosto
konzolno aplikacijo v programskem jeziku C#, ki posluša in odgovarja sporočilom na
strežniku JMS. Kot strežnik JMS smo uporabili TIBCO EMS, kar je implementacija podjetja
TIBCO za standard JMS (Java Messaging Service). Za komunikacijo s strežnikom TIBCO
EMS v okolju .NET smo uporabili knjižnico TIBCO.EMS.dll, ki jo TIBCO EMS ponuja za
razvoj okolju .NET. Izvorna koda konzolne aplikacije je prikazana v izvorni kodi 5.1.
using System; using System.Collections.Generic; using System.Text; using System.Diagnostics; using TIBCO.EMS; namespace TibcoEMSConsoleApp { class TibcoEMSTestApp { static void Main(string[] args) { Console.WriteLine("Test started"); new TibcoEMSTestApp().Run(); Console.ReadLine(); } private void Run() { createReceiver(); } QueueConnection queueConn; QueueSession queueSession; private void createReceiver() { QueueConnectionFactory queueFactory = new TIBCO.EMS.QueueConnectionFactory("localhost"); queueConn = (QueueConnection)queueFactory.CreateConnection("admin", ""); queueConn.Start(); queueSession = queueConn.CreateQueueSession(false, Session.AUTO_ACKNOWLEDGE); Queue userQueue = queueSession.CreateQueue("queue.sample.request"); QueueReceiver queueReceiver = queueSession.CreateReceiver(userQueue, "");
S t r a n | 42
queueReceiver.MessageHandler += new EMSMessageHandler(test_MessageHandler); } private void test_MessageHandler(object sender, EMSMessageEventArgs args) { Queue d = (Queue)args.Message.ReplyTo; queueSession.CreateQueue(d.QueueName); QueueSender queueSender = queueSession.CreateSender(d); TextMessage message = queueSession.CreateTextMessage("No notes for this customer"); queueSender.Send(message); } } }
Za zaledni sistem v primeru klica SOAP oz. kot storitev SSO smo uporabili spletno
storitev WCF (Windows Communication Foundation), napisano v programskem jeziku C#,
ki smo jo implementirali s pomočjo orodja Visual Studio Express for Web 2012. Spletna
storitev ponuja le eno operacijo, to je operacija CheckUserAuthorization. Izvorna koda je
prikazana v izvorni kodi 5.2.
using System; using System.Collections.Generic; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Web; using System.Text; [ServiceContract] public interface IService { [OperationContract] SSOResponse CheckUserAuthorization(string username, string password); } [DataContract] public class SSOResponse { bool authorizationSuccess; string username; string vatNumber; [DataMember] public bool AuthorizationSuccess { get { return authorizationSuccess; } set { authorizationSuccess = value; } } [DataMember]
Izvorna koda 5.1: Preprosta konzolna aplikacija za komunikacijo EMS
S t r a n | 43
public string Username { get { return username; } set { username = value; } } [DataMember] public string VATNumber { get { return vatNumber; } set { vatNumber = value; } } } public class Service : IService { public SSOResponse CheckUserAuthorization(string username, string password) { SSOResponse response = new SSOResponse(); response.Username = username; response.AuthorizationSuccess = true; response.VATNumber = "12345678"; return response; } }
Operacija GetCallsForUser vrne seznam klicev, ki jih je uporabnik opravil, grupirano
po telefonskih številkah. Operacija se začne s klicem javnega procesa GetCallsForUser, ki
ima kot vhodne podatke davčno številko uporabnika, opcijo ali vključiti tudi klice
predplačniških številk, začetni datum obdobja, za katerega naj vrne podatke, kot opcijski
element pa končni datum, do kdaj naj vrne podatke. Javni proces kliče poslovni proces
GetCallsForUser, ki je prikazan na sliki 5.5.
Slika 5.5 Poslovni proces GetCallsForUser
Kot je razvidno na sliki 5.5., najprej pridobimo vse številke MSISDN, ki jih ima
uporabnik z vnešeno davčno številko, nato pa nadaljujemo s pridobivanjem seznama klicev
za vsako številko posebej. Najprej preverimo z iteracijo čez seznam številk MSISDN skozi
Izvorna koda 5.2 Spletna storitev WCF z operacijo CheckUserAuthentication
S t r a n | 44
skupino »Group Postpaid«, kjer kličemo proces GetCallsForMSISDNPostpaid. Po vrnjenem
rezultatu klicev uporabljamo aktivnost za preslikavo, da bi prilagodili obliko rezultata XML,
ki ga dobimo od procesa GetCallsForMSISDNPostpaid. Ko se tisti del procesa izvede, gre
na podlagi vhodnega podatka proces v izvedbo skupine »Group Prepaid« ali v aktivnost
»End«. Izvedba aktivnosti »Group Prepaid« poteka po podobnem vzorcu kot »Group
Postpaid«, le da se v tem primeru kliče proces GetCallsForMSISDNPrepaid.
Proces GetCallsForMSISDNPostpaid prikazuje uporabo aktivnosti JDBC Call
procedure. Kot izhaja iz imena aktivnosti, je le-ta namenjena izvedbi shranjenih procedur
na podatkovnih bazah. Aktivnosti, ki se navezujejo na JDBC, se lahko povezujejo na
različne podatkovne baze. V našem primeru aktivnost »JDBC Call procedure« uporablja
konfiguracijo »JDBCMSSQLConnection«, ki se povezuje na strežnik Microsoft SQL Server
2012 Express. Rezultate shranjene procedure je treba preoblikovati v XML, zato smo
uporabili aktivnost, ki zgradi XML iz besedila, »Parse XML«. V tem procesu smo prikazali
tudi aktivnosti »Catch«, ki lovi napake, »Log«, ki beleži vhodne podatke v dnevniško
datoteko, kot tudi »Rethrow«, ki po beleženju ponovno vrže vlovljeno napako za nadaljnje
procesiranje. Proces je prikazan na sliki 5.6. Proces GetCallsForMSISDNPrepaid je zelo
podoben, le da se povezuje na podatkovno bazo MySQL, kjer hranimo podatke o
predplačniških številkah.
Slika 5.6 Podatkovni proces GetCallsForMSISDNPostpaid
Proces GetMSISDNForUser pa demonstrira uporabo aktivnosti »JDBC Query«, s
pomočjo katerih izvedemo povpraševanje podatkovnih baz. Povpraševanje SQL zapišemo
neposredno v aktivnost. Povpraševanje za naročniške številke se izvede na podatkovni bazi
Microsoft SQLServer, povpraševanje za predplačniške številke pa se izvede na podatkovni
bazi MySQL. V aktivnosti »End« smo preslikali podatke iz obeh prejšnjih aktivnosti, tako da
smo podatke združili. Proces je prikazan na sliki 5.7. Kot je razvidno iz slike, se poizvedbi
na podatkovni bazi izvajata vzporedno, kar skrajša čas izvajanja celotnega procesa.
S t r a n | 45
Paralelno izvajanje procesov v ogrodju BW se sicer konča na aktivnosti, kjer se procesi
združijo. V primeru, da se izvajanje po eni veji procesa izvede pred koncem izvajanja drugih
vej, potem se izvajanje procesa ustavi na aktivnosti, kjer se veje procesa združujejo in se
čaka na zaključek vseh vej.
Slika 5.7 Podatkovni proces GetMSISDNForUser
Implementirali smo tudi operacijo GetAllUsers. Javni proces GetAllUsers kliče
istoimenski poslovni proces, ki pa kasneje kliče podatkovna procesa GetPostpaidUsers in
GetPrepaidUsers. Oba procesa izvedeta povpraševanje SQL po uporabnikih v različnih
podatkovnih bazah, prvi v bazi za naročniške uporabnike, ki je podatkovna baza MS
SQLServer, drugi pa v bazi za predplačniške uporabnike, ki je podatkovna baza MySQL.
Do sedaj opisani procesi so prikazovali sinhrono delovanje procesov po principu
zahtevkov in odgovorov, saj je izvedba procesov klicatelju oziroma iniciatorju procesov
vedno vrnila odgovor po koncu izvajanja procesa. Kot primer asinhronega oziroma
dokumentnega načina delovanja spletnih storitev smo pripravili proces
InsertCustomersUsage, ki se izvaja asinhrono. Javni proces InsertCustomersUsage
asinhrono pokliče poslovni proces InsertCustomersUsage, ne čaka na konec izvajanja
podprocesa in samo nadaljuje izvajanje javnega procesa do konca. Da se proces izvaja v
ločeni niti, lahko takšen način delovanja nastavimo vsakemu procesu, le da v tem primeru
rezultat podprocesov ni na voljo.
Primer enostavnosti ponovne uporabe že pripravljenih procesov smo prikazali na
javnem procesu ProcessUsageFile. Proces se ne začne z aktivnostjo »Start«, temveč z
aktivnostjo »File Poller«, ki zaznava spremembe v datotekah oziroma na novo dodane
datoteke, ki so v določeni mapi. Pot do te mape smo nastavili na aktivnosti File Poller€.
Aktivnost preverja prisotnost sprememb v datotekah ali prisotnost novih datotek v mapi v
S t r a n | 46
skladu z intervalom, ki smo ga nastavili na aktivnosti. Če ugotovi spremembe, izvede
proces. Javni proces ProcessUsageFile je prikazan na sliki 5.8.
Slika 5.8 Javni proces ProcessUsageFile
Kot je razvidno iz slike, javni proces prebere datoteko, kjer je besedilo ločeno z vejicami.
Prebrane podatke preoblikuje aktivnost »Parse Data«, ki jih nato posreduje poslovnemu
procesu InsertCustomersUsage, ki smo ga uporabili tudi pri javnem procesu
InsertCustomersUsage. Nadaljnji potek izvedbe procesa je enak kot pri predhodno
opisanem javnem InsertCustomersUsage procesu.
Podatkovni proces InsertCustomersUsage je prikazan na sliki 5.9. Kot je razvidno iz
slike, proces skrbi za pridobivanje podatkov o tem, katere številke so naročniške in katere
so predplačniške, saj jih je treba zapisati v ločenih sistemih. Nato se podatki preslikajo v
obliko, ki je primerna za nadaljnjo obdelavo ter jih vzporedno zapisujejo. Aktivnost za
zapisovanje v podatkovno bazo je obkrožena z dvema skupinama. Prva skupina je
namenjena iteraciji, druga skupina pa je namenjena transakciji. Vse spremembe, ki so
nastale pri operacijah na podatkovnih bazah znotraj transakcije, se v primeru napake
povrnejo v prvotno stanje. V našem primeru to pomeni, da če pride do napake pri vnosu
enega podatka o porabi, potem nobeden od teh podatkov ne bo zapisan.
Slika 5.9 Podatkovni proces InsertCustomersUsage
S t r a n | 47
Procese, ki smo jih pripravili, je treba omogočiti morebitnim odjemalcem. Odjemalcem
smo omogočili javne procese: CheckSSOAuthorization, GetAllUsers in GetCallsForUsers.
Te procese smo izpostavili kot operacije spletne storitve in pri teh procesih imamo kot
vhodne oziroma izhodne podatke sporočila SOAP. To smo pripravili s pomočjo aktivnosti
»Service«. Za aktivnost je treba predhodno definirati sporočila, ki se bodo uporabljala pri
operacijah. Aktivnost »Service« po nastavitvi pripravi datoteko WSDL za spletno storitev.
Za delovanje spletne storitve seveda potrebujemo tudi končno točko, kjer bo storitev
dosegljiva. To dosežemo s tem, da aktivnosti »Service« določimo končno točko (angl.
endpoint), kjer določimo tudi način transporta, kar je bilo v našem primeru aktivnost »HTTP
Connection«. V primeru HTTP oziroma komunikacije SOAP, TIBCO AMX BW pri zagonu
aplikacije zažene instanco spletnega strežnika Apache Tomcat, ki se potem uporabi za to
komunikacijo. [47] Del dokumenta WSDL je prikazan v izvorni kodi 5.3.
Tudi proces ProcessUsageFile je na voljo uporabnikom, vendar ne v obliki spletne
storitve SOAP. Ta proces se samodejno zažene pri dodajanju ali spremembi ustrezne
datoteke v mapi, ki je nastavljena na aktivnosti »File Poller«.
S t r a n | 48
<?xml version="1.0" encoding="UTF-8"?> <!--Created by TIBCO WSDL--> <wsdl:definitions xmlns:ns="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd" xmlns:tns="http://xmlns.example.com/1452964296656" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="Untitled" targetNamespace="http://xmlns.example.com/1452964296656"> <wsdl:types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="../../Resources/XSD/MobileOperations.xsd"/> </xs:schema> </wsdl:types> <wsdl:service name="MobileService"> <wsdl:port name="MobileServiceEndpoint" binding="tns:MobileServiceEndpointBinding"> <soap:address location="http://localhost:8888/Processes/Service/Service.serviceagent/MobileServiceEndpoint"/> </wsdl:port> </wsdl:service> <wsdl:portType name="PortType"> <wsdl:operation name="GetCallsForUser"> <wsdl:input message="tns:GetCallsForUserRequest"/> <wsdl:output message="tns:GetCallsForUserResponse"/> </wsdl:operation> ....... </wsdl:portType> <wsdl:binding name="MobileServiceEndpointBinding" type="tns:PortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="GetCallsForUser"> <soap:operation style="document" soapAction="/Processes/Service/Service.serviceagent/PortTypeEndpoint1/GetCallsForUser"/> <wsdl:input> <soap:body use="literal" parts="part1"/> </wsdl:input> <wsdl:output> <soap:body use="literal" parts="part1"/> </wsdl:output> </wsdl:operation> ........ </wsdl:binding> <wsdl:message name="GetCallsForUserRequest"> <wsdl:part name="part1" element="ns:GetCallsForUserRequest"/> </wsdl:message> <wsdl:message name="GetCallsForUserResponse"> <wsdl:part name="part1" element="ns:GetCallsForUserResponse"/> </wsdl:message> ........ <wsdl:message name="CheckSSOAuthorizationRequest"> <wsdl:part name="part1" element="ns:CheckUserAuthorizationRequest"/> </wsdl:message> <wsdl:message name="CheckSSOAuthorizationResponse"> <wsdl:part name="part1" element="ns:CheckUserAuthorizationResponse"/> </wsdl:message> </wsdl:definitions>
5.3. Upravljanje varnosti
V velikih in kompleksnih sistemih je zagotavljanje in upravljanje varnosti zelo
pomembno. Ravno v ta namen ogrodje TIBCO AMX BW ponuja možnosti, da se na
komunikacijskih kanalih, kot je HTTP ali JMS, omogoči uporaba SSL (Secure Socket Layer)
oziroma natančneje TLS (Transport Layer Security). Znotraj okolja BW se ta dva izraza
uporabljata z enakim pomenom. [47]
Izvorna koda 5.3: Del WSDL definicije za spletno storitev
S t r a n | 49
Kot primer delovanja protokola HTTPS v okolju BW smo dodali še eno aktivnost tipa
»HTTP Connection«, kjer smo nastavili tudi pot do certifikata, ki ga bo aktivnost uporabljala.
Za uporabo le-tega smo morali dodati še eno končno točko, ki smo jo poimenovali
MobileServiceSecureEndpoint in bo delovala na vratih 8889. Na končni točki smo nastavili
tudi osnovno avtentikacijo HTTP. Za vzpostavitev povezave HTTP bo s tem treba uporabiti
uporabniško ime in geslo. V ogrodju BW se kot uporabniška imena in gesla uporabljajo
uporabniška imena in gesla v domeni BW, ki se uporabljajo in hkrati upravljajo preko orodja
TIBCO Administrator. [50]
Uporabili smo tudi WS-Security. Najprej smo nastavili aktivnost, ki je namenjena
varnostni politiki, to je aktivnost »Security Policy«. S to aktivnostjo lahko natančno
nastavimo, kakšne nastavitve WS-Security bomo imeli, in sicer tako na vhodnih kot na
izhodnih klicih. Pripravili smo aktivnost, ki bo podpirala avtentikacijo, integriteto in zaupnost
na vhodnih klicih. Vsako od teh treh vidikov varnosti smo tudi nastavili. Za avtentikacijo, kot
tudi za integriteto, smo omogočili uporabniško ime in geslo ali varnostni žeton X.509. Tudi
v tem primeru velja, da se uporabljajo uporabniška imena in gesla iz domene TIBCO kot pri
avtentikaciji HTTP. V tem primeru je možno nastaviti, da se uporabljajo uporabniška imena
in gesla, ki so zapisana v datoteki. Za integriteto smo dovolili uporabo SHA1 kot metodo
podpisovanja. Pri zaupnosti pa smo nastavili enkripcijski algoritem AES-256.
Za nastavitev aktivnosti potrebujemo tudi certifikate. V ta namen smo ustvarili testni
certifikat s pomočjo orodja OpenSSL. Za uporabo certifikatov, kot tudi za uporabo
uporabniškega imena in gesla, je treba ustvariti aktivnost »Identity« oziroma identiteto, ki jo
potem lahko uporabimo pri nastavljanju aktivnosti »Security Policy«.
Po definiranju varnostne politike je treba tudi nastaviti, za katere procese naj velja ta
varnostna politika. To smo definirali z uporabo aktivnosti »Security Policy Association«, ki
poveže posamezne procese z določeno vhodno ali izhodno varnostno politiko. Vhodno
varnostno politiko, ki smo jo definirali, smo nastavili vhodni operaciji »GetCallsForUser« na
končni točki MobileServiceSecureEndpoint.
5.4. Namestitev na strežniku
Pripravljeno aplikacijo BW je treba namestiti na strežniku TIBCO. Za nameščanje (angl.
deploy) je treba v projektu pripraviti konfiguracijsko datoteko Enterprise Archive. Enterprise
Archive je format datoteke, ki se uporablja s strani JavaEE za pakiranje modulov v enotno
arhivo, tako da se lahko omogoči simultana namestitev različnih modulov na aplikacijski
strežnik. [51]
S t r a n | 50
V ogrodju BW imamo znotraj datoteke »Enterprise Archive« komponento Process
Archive, ki vsebuje procese, ki smo jih uporabili v projektu, kot tudi Shared Archive, ki
vsebuje vse ostale datoteke, ki so potrebne za delovanje aplikacije (sheme XSD, datoteke
WSDL itn.). Aplikacijo smo namestili na lokalni instanci okolja TIBCO s pomočjo orodja
TIBCO Administrator.
TIBCO Administrator omogoča namestitev aplikacij na več računalnikov znotraj domene
TIBCO. Z namestitvijo aplikacije na več računalnikih skrbimo za skalabilnost in robustnost
delovanja aplikacije, vendar smo zaradi infrastrukturnih omejitev aplikacijo namestili samo
na lokalni instanci okolja TIBCO.
Delovanje spletne storitve smo testirali s pomočjo aplikacije SoapUI, ki omogoča
testiranje delovanja spletnih storitev na ta način, da smo uvozili WSDL in izvedli uspešne
klice za vse operacije. Orodje SoapUI smo izbrali kot simulacijo zunanjega odjemalca, saj
smo na ta način testirali delovanje aplikacije TIBCO s pomočjo zunanjega odjemalca, ki ni
povezan z ogrodjem TIBCO AMX BW.
Primera povpraševanja (angl. request) in odgovora (angl. response) sta prikazana v
izvorni kodi 5.4. in 5.5.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sch="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd"> <soapenv:Header/> <soapenv:Body> <sch:GetCallsForUserRequest> <sch:VAT>12345678</sch:VAT> <sch:IncludePrepaid>true</sch:IncludePrepaid> <sch:PeriodFrom>2015-09-19T01:18:33</sch:PeriodFrom> </sch:GetCallsForUserRequest> </soapenv:Body> </soapenv:Envelope>
Izvorna koda 5.4: Primer povpraševanja
S t r a n | 51
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <ns0:GetCallsForUserResponse xmlns:ns0="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd"> <ns0:CallsForUser> <ns0:MSISDN>38630182225</ns0:MSISDN> <ns0:Type>Postpaid</ns0:Type> <ns0:CallList> <ns0:Call> <ns1:MSISDN xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">38630182225</ns1:MSISDN> <ns1:ConnectedNumber xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">38640177852</ns1:ConnectedNumber> <ns1:Duration xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">122</ns1:Duration> <ns1:CallStartTime xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">2015-12-31T22:03:00+01:00</ns1:CallStartTime> <ns1:Cost xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">0.12</ns1:Cost> </ns0:Call> <ns0:Call> <ns1:MSISDN xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">38630182225</ns1:MSISDN> <ns1:ConnectedNumber xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">38640177852</ns1:ConnectedNumber> <ns1:Duration xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">93</ns1:Duration> <ns1:CallStartTime xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">2015-12-31T23:01:11+01:00</ns1:CallStartTime> <ns1:Cost xmlns:ns1="http://www.tibco.com/schemas/TibcoProject/Resources/XSD/Schema.xsd2">0.0</ns1:Cost> </ns0:Call> </ns0:CallList> </ns0:CallsForUser> </ns0:GetCallsForUserResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Izvorna koda 5.5: Primer odgovora
Po izmenjavi datoteke WSDL, kot tudi lokacije, kjer je dosegljiva spletna storitev, je
spletna storitev dostopna vsem odjemalcem, ki to potrebujejo, če so izpolnjeni pogoji glede
mrežne dostopnosti do končne točke. Na ta način smo zakrili kompleksnost, ki obstaja
znotraj podjetja, in heterogenost programske opreme oziroma infrastrukture, hkrati pa
postavili temelje za nadaljnji razvoj in ponovno uporabo logike, ki obstaja v procesih, ki smo
jih že pripravili.
S t r a n | 52
6. SKLEP
Informacijske tehnologije so že od začetka vpeljave v poslovni svet začele povzročati
revolucijo v hitrosti in učinkovitosti samega poslovanja. Z vedno večjo prisotnostjo
informacijskih tehnologij v različnih vidikih poslovanja so poslovni sistemi postali zelo
kompleksni in raznoliki. Zaradi kompleksnosti, raznolikosti in konstantne potrebe po hitrem
razvoju ter prilagajanju spremembam se je pojavila potreba po tehnologijah in arhitekturah,
ki omogočajo hitrejši razvoj in komunikacijo med sistemi, hkrati pa bodo pregledne in bodo
potekale tudi med sistemi, ki so med seboj neposredno nekompatibilni. Ta potreba je
postala toliko bolj izrazita s pojavom svetovnega spleta in avtomatizacije poslovanja.
V pričujočem delu smo ugotovili, da zgoraj omenjene potrebe niso nove in da obstajajo
različni pristopi k reševanju težav integracije. Predstavili smo različne pristope k integraciji
poslovnih aplikacij, kot tudi razvoj teh pristopov skozi čas. Posebno pozornost smo posvetili
storitveno usmerjeni arhitekturi in storitvenemu vodilu, ki predstavlja sodobni pristop k
integraciji poslovnih aplikacij. Prav tako smo opisali osrednje tehnologije, ki so v uporabi za
razvoj oziroma implementacijo storitveno usmerjene arhitekture.
Nadaljevali smo s predstavitvijo funkcionalnosti ogrodja TIBCO ActiveMatrix
BusinessWorks, kot tudi orodij, ki so del podpornega okolja, kot so TIBCO Administrator,
adapterji TIBCO ter orodje za nadzor in komunikacijo TIBCO Hawk. Predstavili smo tudi del
možnosti, ki jih ogrodje ponuja v namen komunikacije z različnimi sistemi, kot tudi
komponente, ki se uporabljajo pri razvoju in upravljanju aplikacij.
V sklopu diplomskega dela smo pripravili tudi aplikacijo, namenjeno fiktivnemu
mobilnemu operaterju, ki pridobiva informacije iz različnih virov: različni podatkovni bazi,
spletne storitve WCF preko protokola SOAP, kot tudi z drugim zalednim sistemom preko
S t r a n | 53
strežnika JMS. Skozi razvoj aplikacije smo spoznali prednosti, ki jih omogoča TIBCO
ActiveMatrix BusinessWorks: preko grafičnega modeliranja poslovnih procesov dobimo lažji
pregled nad kompleksnimi procesi. Grafični vmesnik za oblikovanje procesov pomeni tudi
korak naprej in višji nivo abstrakcije, s čimer smo se lahko bolj posvetili sami vsebini
procesa, kot pa tehniki, kako to izvesti. Procese smo razvrstili glede na namen na tri tipe:
javne, procese s poslovno logiko in podatkovne procese. Razvoj je potekal zelo hitro, prav
tako pa bi nadaljnji razvoj aplikacije potekal veliko lažje, saj ogrodje BW omogoča
enostavno ponovno uporabo že implementiranih poslovnih procesov. Zaradi kompleksnosti
in nedostopnosti produkcijskih zalednih sistemov mobilnih operaterjev smo razvili tudi
enostavne aplikacije, ki simulirajo realne zaledne sisteme.
Pogosto je varnost ena izmed osrednjih točk pri razvoju aplikacij, še posebej v sistemih,
ki hranijo velike količine uporabniških podatkov, pri čemer so nekateri od teh podatkov tudi
zaupni. Pri razvoju aplikacije smo uporabili komunikacijo HTTPS, kot tudi varnost, ki jo
ponuja WS-Security. Implementacija in nastavitev varnostnih nastavitev s pomočjo
aktivnosti oziroma nastavitev, ki jih ponuja ogrodje BW, je bila hitra, enostavna in pregledna.
Nameščanje aplikacij, ki so razvitie s pomočjo ogrodja BW, je z uporabo orodja TIBCO
Administrator zelo enostavno. TIBCO Administrator omogoča veliko možnosti konfiguracije,
preko katerih lahko aplikacijo prilagodimo svojim potrebam glede virov in skalabilnosti
aplikacije, saj ga lahko namestimo na več računalnikih znotraj domene TIBCO, prav tako
pa lahko nastavimo število niti, znotraj katerih se proces izvaja. Vse te spremembe glede
skalabilnosti potekajo brez spremembe izvorne kode aplikacije. Možnosti, ki jih TIBCO
Administrator glede namestitve aplikacije na različnih računalnikih ponuja, hkrati omogoča
možnosti vzdrževanja aplikacij brez časa izpada (angl. downtime). Če bi želeli obstoječo
aplikacijo razširiti, bi to lahko naredili z razširitvijo aplikacije ali pa z uporabo teh storitev
oziroma procesov znotraj drugih aplikacij, ki bi jih razvili.
Na podlagi lastnih izkušenj lahko povemo, da je učna krivulja za razvijalca programske
opreme, ki je navajen razmišljati v kodi, dokaj strma, saj se mora zaradi visokega nivoja
abstrakcije veliko naučiti glede konceptov ogrodja TIBCO AMX BW. Vendar je ravno ta nivo
abstrakcije, ki ga ponuja TIBCO AMX BW, kasneje tudi osnova za zelo hiter razvoj aplikacij,
ki lahko vsebujejo tudi veliko kompleksne logike. Grafični vmesnik je omogočil, da smo
glavno pozornost posvetili vsebini poslovnih procesov oziroma spletnih storitev, ki smo jih
razvijali, namesto da bi se osredotočali na tehnične podrobnosti programske kode, s katero
bi lahko dosegli enako obnašanje. Grafični prikaz pa tudi olajša komunikacijo z osebami, ki
ne izhajajo iz tehničnega področja, saj poenostavi komunikacijo glede poteka poslovnih
procesov.
S t r a n | 54
Sklenemo lahko, da je ogrodje TIBCO ActiveMatrix BusinessWorks zmogljivo ogrodje
za integracijo poslovnih aplikacij, ki uporabljajo zelo širok spekter tehnologij, preko
implementacije storitveno usmerjene arhitekture.
S t r a n | 55
7. LITERATURA
[1] D. S. Linthicum, Next Generation Application Integration: From Simple Information
To Web Services. Addison Wesley, 2003.
[2] D. S. Linthicum, Enterprise Application Intergration. Addison Wesley, 1999.
[3] W. A. Rugh, F. X. Maginnins, and W. J. Brown, Enterprise Application Integration.
Wiley Computer Publishing, 2001.
[4] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and
Deploying Messaging Solutions. 2003.
[5] “Remote procedure call - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Remote_procedure_call. [Accessed: 30-Apr-2016].
[6] “Message-Oriented Middleware (MOM) (Sun Java System Message Queue 4.3
Technical Overview).” [Online]. Available: https://docs.oracle.com/cd/E19316-
01/820-6424/aeraq/index.html. [Accessed: 02-May-2016].
[7] “Distributed object - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Distributed_object. [Accessed: 02-May-2016].
[8] The Open Group, “What Is SOA?” [Online]. Available:
http://www.opengroup.org/soa/source-book/soa/soa.htm#soa_definition. [Accessed:
17-Jan-2016].
[9] M. Havey, SOA Cookbook. Birmingham: Packt Publishing, 2008.
[10] “Enterprise Service Bus (ESB): Lasting concept or latest buzzword?” [Online].
Available: http://searchsoa.techtarget.com/tip/Enterprise-Service-Bus-ESB-Lasting-
concept-or-latest-buzzword. [Accessed: 17-Jan-2016].
[11] “OASIS SOA Reference Model TC | OASIS.” [Online]. Available: https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=soa-rm. [Accessed: 23-Apr-2016].
[12] “Understanding Service-Oriented Architecture.” [Online]. Available:
https://msdn.microsoft.com/en-us/library/aa480021.aspx#aj1soa_topic2. [Accessed:
23-Apr-2016].
[13] N. M. Josuttis, Soa in practice: the art of distributed system Design. 2007.
[14] “What is interoperability? - Definition from WhatIs.com.” [Online]. Available:
http://searchsoa.techtarget.com/definition/interoperability. [Accessed: 22-Apr-2016].
[15] “Loose coupling - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Loose_coupling. [Accessed: 23-Apr-2016].
[16] E. Arh, “Uvedba storitveno usmerjene arhitekture v procesno usmerjeno podjetje,”
no. december. Univerza v Ljubljani, Ekonomska fakulteta, Ljubljana, 2008.
S t r a n | 56
[17] “Service Oriented Architecture - Wikipedia, the free encyclopedia.” [Online].
Available: https://en.wikipedia.org/wiki/Service-oriented_architecture. [Accessed:
21-Apr-2016].
[18] “Orchestration and Choreography in Web Services | singularity on WordPress.com.”
[Online]. Available: https://endex.wordpress.com/2007/04/01/orchestration-and-
choreography-in-web-services/. [Accessed: 03-May-2016].
[19] “Web Services Glossary.” [Online]. Available: https://www.w3.org/TR/2004/NOTE-
ws-gloss-20040211/#webservice. [Accessed: 18-Apr-2016].
[20] “Extensible Markup Language (XML) 1.0 (Fifth Edition).” [Online]. Available:
https://www.w3.org/TR/REC-xml/#sec-origin-goals. [Accessed: 24-Apr-2016].
[21] “Document type definition - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Document_type_definition. [Accessed: 25-Apr-2016].
[22] “Schema - W3C.” [Online]. Available: https://www.w3.org/standards/xml/schema.
[Accessed: 25-Apr-2016].
[23] W. Roshen, SOA-Based Enterprise Integration, no. 1. New York: McGraw-Hill, 2009.
[24] “Web Services Description Language.” [Online]. Available:
https://en.wikipedia.org/wiki/Web_Services_Description_Language. [Accessed: 23-
Apr-2016].
[25] “Understanding WS-Security.” [Online]. Available: https://msdn.microsoft.com/en-
us/library/ms977327.aspx. [Accessed: 28-Apr-2016].
[26] “XPath.” [Online]. Available: https://en.wikipedia.org/wiki/XPath. [Accessed: 24-Apr-
2016].
[27] “XQuery - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/XQuery. [Accessed: 27-Apr-2016].
[28] “Business Process Execution Language - Wikipedia, the free encyclopedia.” [Online].
Available: https://en.wikipedia.org/wiki/Business_Process_Execution_Language.
[Accessed: 03-May-2016].
[29] “BPEL tutorial.” [Online]. Available: http://searchsoa.techtarget.com/tutorial/BPEL-
tutorial. [Accessed: 03-May-2016].
[30] D. Paler, Zasnova orodja za uporabniško naravnano kompozicijo storitev. Univerza
v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, 2012.
[31] D. Ilešič, STORITVENA VODILA IN ORACLE POVEZOVALNO PROGRAMJE.
Maribor: Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in
informatiko, 2010.
[32] “Enterprise Service Bus - Wikipedia, the free encyclopedia.” [Online]. Available:
S t r a n | 57
https://en.wikipedia.org/wiki/Enterprise_service_bus. [Accessed: 25-Apr-2016].
[33] “Product Index | TIBCO.” [Online]. Available: http://www.tibco.com/products.
[Accessed: 14-Apr-2016].
[34] “Magic Quadrant for On-Premises Application Integration Suites.” [Online]. Available:
http://www.gartner.com/technology/reprints.do?id=1-1YGZ0QT&ct=140730&st=sb.
[Accessed: 16-Jan-2016].
[35] “Market Guide for Integration Platform as a Service.” [Online]. Available:
http://www.gartner.com/document/2884917?ref=solrAll&refval=166745446&qid=65
137dce75689ae82491687b6c67218e. [Accessed: 22-Apr-2016].
[36] “Magic Quadrant for Enterprise Integration Platform as a Service, Worldwide.”
[Online]. Available:
http://www.gartner.com/document/3263719?ref=solrAll&refval=166746141&qid=5d
50241cfaa8928f3fa378fe3cd3a8cb. [Accessed: 22-Apr-2016].
[37] F. Cohen, “Getting The Best Performance From Apps Built With Integration
Platforms.” Appvance, 2013.
[38] “Download Kit – Appvance.” [Online]. Available:
http://www.appvance.com/download-kit/. [Accessed: 13-Apr-2016].
[39] “TIBCO Software.” [Online]. Available:
https://en.wikipedia.org/wiki/TIBCO_Software. [Accessed: 31-Mar-2016].
[40] P. C. Brown, TIBCO ® Architecture Fundamentals. New Jersey: Addison-Wesley,
2011.
[41] “ActiveMatrix BusinessWorksTM 6 Capabilities | TIBCO.” [Online]. Available:
http://www.tibco.com/products/automation/application-integration/activematrix-
businessworks?capabilities. [Accessed: 02-Apr-2016].
[42] TIBCO Software Inc., “TIBCO Runtime Agent TM Release Notes.” 2015.
[43] TIBCO Software Inc., “TIBCO ActiveMatrix BusinessWorks Concepts.” 2014.
[44] TIBCO Software Inc., “TIBCO Adapter TM Concepts.” 2011.
[45] TIBCO Software Inc., “TIBCO Administrator TM User ’ s Guide.” 2015.
[46] TIBCO Software Inc., “TIBCO Hawk Concepts Guide,” no. May. 2014.
[47] TIBCO Software Inc., “TIBCO ActiveMatrix BusinessWorks : Process Design Guide,”
2011. [Online]. Available:
https://docs.tibco.com/pub/activematrix_businessworks/5.9.3_march_2012/pdf/tib_
bw_process_design_guide.pdf. [Accessed: 31-Mar-2016].
[48] “Operations support system - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Operations_support_system. [Accessed: 28-Feb-2016].
S t r a n | 58
[49] “Business support system - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/Business_support_system. [Accessed: 28-Feb-2016].
[50] “TIBCO BusinessWorks Palette Reference.” [Online]. Available:
https://docs.tibco.com/pub/activematrix_businessworks/5.9.3_march_2012/pdf/tib_
bw_palette_reference.pdf. [Accessed: 21-Mar-2016].
[51] “EAR (file format) - Wikipedia, the free encyclopedia.” [Online]. Available:
https://en.wikipedia.org/wiki/EAR_(file_format). [Accessed: 01-Apr-2016].
S t r a n | 59
8. PRILOGE
8.1. Kazalo slik
Slika 2.1 Shema sporočilno usmerjenega povezovalnega programja, prirejeno po [6] ...... 7
Slika 3.1 Stopnje razširjenosti SOA glede na storitve [13] ................................................11
Slika 3.2 Koreografija med trgovci in dobavitelji ...............................................................12
Slika 3.3 Orkestracija med trgovci in dobaviteljem ...........................................................13
Slika 3.4 Glavni elementi sheme XML [23] .......................................................................15
Slika 3.5 Definicija dokumenta WSDL verzije 1.1. in 2.0 [24] ...........................................16
Slika 3.6 Delovanje WS-Security [16] ...............................................................................17
Slika 3.7 Model storitvenega vodila [32] ...........................................................................19
Slika 4.1: Gartnerjev magični kvadrant za ogrodja za integracijo [34] ...............................22
Slika 4.2 Produktna skupina TIBCO ActiveMatrix [40] ......................................................27
Slika 4.3 Arhitektura komunikacije znotraj domene BusinessWorks [43] ..........................28
Slika 4.4: Adapterji TIBCO povezujejo različne sisteme [44] ............................................29
Slika 4.5: Grafični vmesnik komponente TIBCO Administrator .........................................30
Slika 4.6 Arhitektura orodja TIBCO Hawk za monitoriranje. [46] ......................................31
Slika 4.7: Videz orodja TIBCO Designer ..........................................................................32
Slika 4.8: Palete v ogrodju TIBCO AMX BW ....................................................................33
Slika 4.9 Prikaz preslikave podatkov v aktivnost End. ......................................................34
Slika 5.1: Predstavitev arhitekture praktične naloge .........................................................38
Slika 5.2: Poslovni proces CheckSSOAuthorization .........................................................40
Slika 5.3: Podatkovni proces CheckSSOAuthorization .....................................................40
Slika 5.4 Podatkovni proces GetCRMNotesForUser ........................................................41
Slika 5.5 Poslovni proces GetCallsForUser ......................................................................43
Slika 5.6 Podatkovni proces GetCallsForMSISDNPostpaid .............................................44
Slika 5.7 Podatkovni proces GetMSISDNForUser ............................................................45
Slika 5.8 Javni proces ProcessUsageFile ........................................................................46
Slika 5.9 Podatkovni proces InsertCustomersUsage ........................................................46
8.2. Kazalo izvorne kode
Izvorna koda 4.1: Vsebina datoteke GetAllUsers.process ................................................35
S t r a n | 60
Izvorna koda 5.1: Preprosta konzolna aplikacija za komunikacijo EMS ............................42
Izvorna koda 5.2 Spletna storitev WCF z operacijo CheckUserAuthentication .................43
Izvorna koda 5.3: Del WSDL definicije za spletno storitev ................................................48
Izvorna koda 5.4: Primer povpraševanja ..........................................................................50
Izvorna koda 5.5: Primer odgovora ..................................................................................51
8.3. Kazalo tabel
Tabela 4.1 Skupni stroški lastništva za različna integracijska ogrodja [37] .......................25
S t r a n | 61
S t r a n | 62
S t r a n | 63
