Aleksander Žagar PRIMERJAVA ODPRTOKODNIH IMPLEMENTACIJ STORITVENE KOMPONENTNE ARHITEKTURE Diplomsko delo Celje, julij 2011

Transkripcija

1 Aleksander Žagar PRIMERJAVA ODPRTOKODNIH IMPLEMENTACIJ STORITVENE KOMPONENTNE ARHITEKTURE Diplomsko delo Celje, julij 2011

2

3 I Diplomsko delo univerzitetnega študijskega programa PRIMERJAVA ODPRTOKODNIH IMPLEMENTACIJ STORITVENE KOMPONETNE ARHITEKTURE Študent: Študijski program: Smer: Mentor: Lektorica: Aleksander Ţagar UN, Računalništvo in informatika Informatika izr. prof. dr. Ţivkovič Aleš Jasmina Vajda Vrhunec Celje, julij 2011

4 II

5 III ZAHVALA Zahvaljujem se mentorju izr. prof. dr. Alešu Ţivkoviču za pomoč in vodenje pri pisanju diplomskega dela. Posebna zahvala velja staršem, ki so mi omogočili študij.

6 IV PRIMERJAVA ODPRTOKODNIH IMPLEMENTACIJ STORITVENE KOMPONENTNE ARHITEKTURE Ključne besede: SCA, SOA, Apache Tuscany, Fabric3, frascati, OSOA, storitvena arhitektura, odprta koda UDK: (043.2) Povzetek Aplikacije iz leta v leto opravljajo bolj kompleksne naloge. Skupaj s kompleksnostjo teh nalog pa raste tudi kompleksnost aplikacij, kar ogroža uspešnost projektov, v okviru katerih se takšne aplikacije razvijajo. Z leti so se razvile razne metode in tehnologije v pomoč pri boju s tem problemom. Ena izmed takšnih tehnologij, hkrati pa glavna tema tega dela, je SCA. Predstavili smo njene osnovne koncepte, in sicer skupaj z njihovimi značilnostmi. Poleg tega smo opravili pregled odprtokodnih implementacij tehnologije, pri čemer smo se osredotočili na njihovo zmogljivost in skladnost s specifikacijam SCA.

7 V COMPARISON OF OPEN-SOURCE IMPLEMENTATIONS OF SERVICE COMPONENT ARHITECTURE Key words: SCA, SOA, Apache Tuscany, Fabric3, frascati, OSOA, service arhitecture, open source UDK: (043.2) Abstract With every year, applications are solving more and more complex tasks. As this complexity rises, the success of projects, incorporating these applications, becomes even more endangered. Over the years, various methods and technologies were developed to battle this problem. One of these technologies, and our primary concern in this work, is SCA. We have introduced its base concepts along with their characteristics. In addition to that, we have also examined the state of open source implementations currently avaliable, with the focus on thier preformance and compliance with the SCA specifications.

8 VI VSEBINA 1 Uvod Poslovne aplikacije skozi čas Cilji in struktura diplomskega dela Referenčni model in arhitektura programske opreme Arhitekturni stili Storitveno orientirana arhitektura Prednosti storitveno orientirane arhitekture Pregled konceptov in njihovih medsebojnih povezav Koncepti, neposredno povezani s storitvami Dinamika interakcije med ponudniki in porabniki storitev SCA Zgodovina Pregled osnovnih konceptov tehnologije SCA Pregled odprtokodnih implementacij tehnologije SCA Izvajalno okolje Apache Tuscany SCA Izvajalno okolje Fabric Izvajalno okolje FraSCAti Odprtokodno orodje za razvoj aplikacij SCA SCA Tools Primerjava predstavljenih izvajalnih okolij Predstavitev osnovnih karakteristik merjenja zmogljivosti Predstavitev testne aplikacije Podrobna predstavitev testne aplikacije Testiranje Rezultati testiranja Rezultati testiranja izvajalnega okolja Apache Tuscany... 62

9 VII 7.2 Rezultati testiranja izvajalnega okolja frascati Rezultati testiranja izvajalnega okolja Fabric Analiza testiranja Sklep Viri Priloge Naslov študenta Seznam slik Seznam primerov Seznam preglednic... 95

10 VIII UPORABLJENE KRATICE API - Application Programming Interface CORBA - Common Object Request Broker Architecture DBMS - Database management system DDOS - Distributed Denial-Of-Service GMF - Graphical Modeling Framework HTTP - Hypertext Transfer Protocol Java EE - Java Platform, Enterprise Edition JNA - Java Native Access JSON - JavaScript Object Notation JSP - JavaServer Pages JVM - Java Virtual Machine OASIS - Organization for the Advancement of Structured Information Standards OSGi - Open Services Gateway initiative OSOA - Open SOA PB - Podatkovna Baza POJO - Plain Old Java Object Pub/sub - Publisher/Subscriber QoS - Quality of Service RMI - Remote Method Invocation RSS - Really Simple Syndication SCA - Service Component Architecture SCDL - Service Component Definition Language SOA - Service Oriented Architecture XML - extensible Markup Language

11 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 1 1 Uvod Poslovne aplikacije skozi čas Programske rešitve, namenjene poslovni rabi, so se od svojih relativno skromnih začetkov v 60. in 70. letih prejšnjega stoletja ko so se uporabljale predvsem za naloge avtomatizacije procesa plač, knjiţenja in podobno v izključno velikih podjetjih, ki so lahko racionalizirala izdatke, ki jih je predstavljal tako razvoj kot tudi nakup potrebne strojne opreme skozi naslednja desetletja razširile v praktično vsa poslovna okolja. Skupaj s to širitvijo so s časoma začele izpolnjevati tudi vedno bolj pomembne naloge. Tako se danes nahajamo na točki, ko si podjetja brez kakršnih koli informacijskih rešitev ne znamo več predstavljati. Ko so takšne poslovne rešitve skozi čas prevzemale izvajanje vedno večjega števila opravil, se je sorazmerno s tem večala tudi kompleksnost njih samih, zaradi česar je tudi razvoj postajal vedno kompleksnejši. Prav tako pa je zaradi vlog, ki so jo jih prevzemale, postajalo vedno bolj pomembno, da so bili končni produkti zanesljivi. Če k temu prištejemo še realnost poslovnega sveta, kjer se od podjetij pričakuje, da se nenehno prilagajajo trenutnim poslovnim situacijam, dobimo še dodatno zahtevo, da morajo biti programske rešitve, ki jih uporabljajo takšna podjetja, v vsakem trenutku pripravljene na nadaljnje razširitve oziroma prilagoditve, ki se pojavijo v sklopu poslovnih procesov podjetja, pri čemer je kritičen tudi čas, v katerem so te pripravljene za uporabo. V pregledu smo našteli nekaj izključujočih se zahtev, ki so pričakovane od sodobnih programskih rešitev v poslovnem okolju. Če pogledamo, imamo na eni strani vedno kompleksnejše aplikacije, na drugi strani pa zahtevo, da so zaradi tega, ker prevzemajo vedno bolj kritične naloge, tudi zanesljive. Po drugi strani pa se zaradi dinamičnosti sodobnega poslovnega sveta od njih pričakuje, da bodo kar najbolj agilne, se pravi, da bodo omogočale hitro in učinkovito prilagajanje poslovnim spremembam organizacij, na primer v obliki spremenjenega poslovnega procesa. Nato je tukaj vseprisotna ţelja, da se deli rešitve, ki niso nujno tesno povezani z domeno, ki jo ta naslavlja, nadalje uporabni v ostalih aplikacijah, ki jih ima podjetje, kljub temu da te niso nujno medsebojno logično sklopljene. Ko na koncu k vsemu temu dodamo še finančni vidik, si lahko predstavljamo, zakaj je odstotek uspešnosti IT projektov tako uboren. Če se opremo samo na Chaos Summary Report organizacije Standish Group iz leta 2009, je le-ta na vzorcu 400

12 Stran 2 Aleksander Ţagar, Diplomsko delo organizacij prišla do naslednjih rezultatov: 24 odstotkov vseh projektov je bilo označenih za polom, saj niso nikoli bili zaključeni ali pa so bili dostavljeni, a niso prišli v operativno uporabo. 44 odstotkov projektov je bilo označenih kot delno uspešnih, takšni so sicer prišli v operativno uporabo, ampak so pri tem presegli načrtovan proračun ali časovni obseg oziroma niso dostavili vseh načrtovanih funkcionalnosti. Samo 33 odstotkov projektov pa je ustrezalo pogojem, ki določajo uspešen projekt[34]. Prav z razlogom obvladovanja teh vedno obseţnejših sistemov pa smo lahko priča nenehnim inovacijam, najprej na tehnološkem področju, in sicer v obliki programskih knjiţnic, raznih programskih ogrodij, ki se trudijo razvijalce razbremeniti s tem, da vključujejo pester nabor generičnih funkcionalnosti, ki jih je mogoče nadalje razširiti in prilagoditi točno določenim potrebam. Na nekoliko višjem nivoju so nato zbirke dobrih praks oziroma vzorcev. Še stopničko višje imamo različne stile programskih arhitektur, ki jih lahko uporabimo kot osnovo pri načrtovanju rešitve. Nato so tukaj še različne metodologije razvoja programske opreme, skupaj s kopico orodij in diagramskih tehnik, ki so na voljo na različnih stopnjah razvoja rešitev. Tej pisani mnoţici lahko priključimo tudi SCA Service Component Arhitecture, ki je v osnovi definiran z mnoţico specifikacij, ki opisujejo model za gradnjo aplikacij, ki sledijo principom SOA Service Oriented Arhitecture[14] in ga obravnavamo v tem diplomskem delu. 1.1 Cilji in struktura diplomskega dela V prvem delu diplomskega dela smo definirali, kaj je arhitektura programske opreme, ter naredili krajši pregled različnih aktualnih arhitekturnih stilov. V nadaljevanju smo predstavili storitveno orientirano arhitekturo, kateri sledijo aplikacije, grajene s pomočjo tehnologije SCA. Zatem smo najprej umestili tehnologijo SCA, izluščili pomembnejše koncepte, ki jo sestavljajo, in vse to povezali v zaokroţeno celoto. V zadnjem delu diplomskega dela pa sledi še pregled trenutnega stanja odprtokodnih implementacij tehnologije SCA, kaj te nudijo in kako se med seboj razlikujejo. Pri primerjavi različnih odprtokodnih implementacij tehnologije SCA smo se osredotočili predvsem na to, kakšna je podpora posameznim tipom storitev, ki jih določajo specifikacije SCA, pri čemer smo preverili tudi,

13 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 3 kakšne so zmogljivosti pri uporabi le-teh. Kot osnovo za to primerjavo smo uporabili namensko razvito testno aplikacijo SCA. 2 Referenčni model in arhitektura programske opreme Kot protiuteţ vedno večji kompleksnosti programskih rešitev so se skozi leta uveljavili različni prijemi, kako se spopasti z njo. Med te prijeme štejemo tudi referenčne modele, ki navadno predstavljajo temelj pri načrtovanju arhitekture programske opreme. Podajmo nekaj definicij referenčnega modela:»referenčni model pri razvoju programskih rešitev je model nečesa, kar predstavlja osnovne cilje oziroma idejo nečesa in na kar lahko gledamo kot na referenco, uporabno za različne namene.«[12]»referenčni model predstavlja abstraktno ogrodje za razumevanje razmerij med pomembnejšimi entitetami nekega okolja. Kot tak z definiranjem konsistentnih standardov oziroma specifikacij nekega okolja predstavlja podlago za bolj specifične referenčne modele ali konkretne arhitekture. Referenčni model je sestavljen iz minimalnega skupka konceptov, aksiomov in povezav znotraj določene problemske domene in je neodvisen od specifičnih standardov tehnologij, implementacij in ostalih konkretnih detajlov.«[7] Kot lahko razberemo iz zgornjih definicij, nam referenčni model predstavlja visokonivojski skupek konceptov in razmerij med njimi, namenjenih za opis nekega okolja oziroma problemske domene. Prav zaradi teh lastnosti je uporabnost takšnih modelov zelo široka, saj se model lahko uporabi na več načinov, na primer za izobraţevanje kadrov o problemski domeni, kot osnovna za primerjavo, za določanje nalog in odgovornosti, kot temelj pri načrtovanju arhitekture programske rešitve, ki rešuje probleme iz iste domene, nikakor pa sam po sebi ni povezan s konkretnimi tehnološkimi rešitvami[7]. Referenčni model lahko predstavlja osnovo pri načrtovanju programske arhitekture. Če pogledamo pojem arhitekture bolj na splošno, ugotovimo, da gre za zelo širok pojem, ki ga najverjetneje najprej poveţemo s stavbno arhitekturo. Ţe samo znotraj IT stroke bomo naleteli na različne arhitekture, pri čemer nas zanima predvsem arhitektura programske opreme.

14 Stran 4 Aleksander Ţagar, Diplomsko delo Vsaka programska rešitev ima neko svojo arhitekturo, četudi ni nujno, da je ta bila vnaprej formalno definirana in dokumentirana, ter tako predstavljala osnovo pri gradnji rešitve. V tem primeru lahko zagotovo trdimo, da če gre za obseţno in kompleksno aplikacijo, je le-ta vse prej kot optimalna ter je inherentno veliko teţavnejša za razumevanje in s tem tudi za kasnejši nadaljnji razvoj. Poglejmo skozi definiciji, kaj nam predstavlja programska arhitektura[11][15]:»programska arhitektura sistema je skupek struktur, potrebnih za razumevanje sistema, in je sestavljena iz programskih elementov, relacij med njimi in njihovimi lastnostmi.«[15]»arhitektura je osnovna organizacija sistema, sestavljena iz njegovih komponent, razmerij med temi in okoljem ter principov, ki usmerjajo načrt sistema in njegovo evolucijo.«[11] Ko nadalje razdelamo pojem programske arhitekture, je njen osnovni namen zadovoljitev zahtev, ki naj bi jih vključevala končna aplikacija, grajena glede na takšno arhitekturo. Arhitektura naj bi nam definirala strukturo aplikacije skozi predstavitev strukturnih elementov kot tudi obnašanje takšne aplikacije skozi definicijo interakcij med posameznimi elementi. Programska arhitektura naj bi se nadalje osredotočala le na elemente, ki pri strukturi igrajo pomembno vlogo, sluţijo ţelenemu obnašanju ter pomembnejšim faktorjem, ki naj bi jih končen sistem, grajen na takšni arhitekturi, dosegal. To so na primer zanesljivost, skalabilnost in varnost. Prav tako je pomembno, da se na arhitekturo gleda v kontekstu okolja, v katerem bo končna rešitev delovala. Faktorji, ki spadajo sem, so: poslovni namen aplikacije, kdo bo v neposrednem in posrednem stiku z njo, tako zunanje kot notranje tehnične omejitve, tako na strojni kot na programski strani[11][16].

15 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 5 Slika 1: Ponazorjene odvisnosti od referenčnega modela do končne implementacije[7] 2.1 Arhitekturni stili Razen referenčnih modelov in konkretnih arhitektur pa obstaja še en abstrakcijski nivo, ki je zasidran med omenjenima to so referenčne arhitekture oziroma arhitekturni stili. Na njih lahko gledamo kot na prečiščeno abstraktno ogrodje, ki s podajanjem osnove rešuje ponavljajoče se probleme, ki so se v preteklosti pojavljali pri gradnji podobnih tipov aplikacij, oziroma predstavlja najboljše prakse določene problemske domene. Arhitekturni stili so lahko med seboj zelo raznoliki in naslavljajo vrsto različnih problemskih domen, kar pomeni, da med seboj niso nujno izključujoči in jih navadno lahko uporabljamo v kombinaciji, ki kar najbolje ustreza našim potrebam. S tem ko za osnovo uporabimo določen arhitekturni stil, v arhitekturo neposredno vpeljemo njegove strukturne in značajske značilnosti, ki postanejo temelj pri nadaljnji gradnji arhitekture. Formalno so arhitekturni stili definirani kot:»arhitekturni stil definira druţino sistemov na osnovi vzorcev organizacijske strukture. Bolj specifično, arhitekturni stil definira besednjak komponent, tipov povezav med njimi in skupka omejitev, ki sestavljajo celoto.«[11][16][7]

16 Stran 6 Aleksander Ţagar, Diplomsko delo Študije na tem področju so se še posebej razmahnile v 90. letih prejšnjega stoletja[15], tako smo danes priča pisani mnoţici različnih arhitekturnih stilov, ki so namenjeni različnim problemskim domenam. Področje je še vedno zelo aktivno, saj so arhitekturni stili neposredno povezani s tehnološkim razvojem celotne IT sfere, se pravi tako novih programskih kot tudi strojnih platform. S tem prihaja do reciklaţe starih arhitekturnih stilov oziroma do prilagajanja le-teh novi realnosti, in sicer skupaj z elementi drugih arhitekturnih stilov, ki so se v preteklosti izkazali kot uspešni. Prav storitveno orientirano arhitekturo, ki se ji bomo v nadaljevanju nekoliko bolj podrobno posvetili, bi lahko označili za takšno akumulacijo različnih predhodnih idej, ki se je pojavila kot posledica tehnološkega razvoja. V nadaljevanju je podan grob pregled nekaterih trenutno aktualnih arhitekturnih stilov, ki vključuje opis njihovih glavnih značilnosti[16] Odjemalec/strežnik (Client/Server) Opisuje sisteme, razdeljene na dva osnovna tipa komponent: na eni strani odjemalca, na drugi streţnika. Del programske opreme v vlogi odjemalca pošilja poizvedbe streţniku, ki je odgovoren za akcije v skladu s povpraševanjem in vračanje odgovorov[16] Arhitektura, zasnovana na komponentah (Component-Based Architecture) Razdeli zasnovo aplikacije na komponente, pri čemer vsaka komponenta ogradi skupek logično povezanih funkcionalnosti. Komunikacija poteka z uporabo dobro definiranih vmesnikov[16] Domensko gnan dizajn (Domain Driven Design) Domensko gnan dizajn je objektno orientiran pristop, ki gradi na modeliranju poslovnih objektov, ki temeljijo na entitetah, le-te pa sestavljajo določeno poslovno domeno[16] Večplastna arhitektura (Layered Architecture) Gradi na načelu particioniranja aplikacije v plasti in nadaljnjega zlaganja le-teh. Vsaka plast je semantično zaokroţena in povezana z določeno vlogo oziroma odgovornostjo. Plasti se nato vertikalno»nalagajo«ena na drugo, pri čemer so kar se da šibko sklopljene; na ta način se zagotavlja moţnost zamenjave določene plasti, brez da bi pri tem morali posebej prilagajati druge neposredno povezane[16].

17 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Arhitektura sporočilnega vodila (Message Bus Architectural Style) Stil, ki temelji na uporabi vmesne programske opreme (middleware), ki sprejema in pošilja sporočila z uporabo več komunikacijskih kanalov, kar predstavlja osnovo za interakcijo med aplikacijami, brez da bi le-te morale vedeti za posebnosti ena druge[16] N-stopenjska arhitektura (N-Tier Architecture) Temelji na ločevanju funkcionalnosti v ločene segmente stopnje, pri čemer je vsak takšen segment odgovoren za specifično funkcionalnost, operirajo pa fizično ločeni eden od drugega[16] Objektno orientirana arhitektura (Object-Oriented Architecture) Gradi na deljenju aplikacije oziroma njenih odgovornosti v diskretne, neodvisne in medsebojno šibko povezane objekte. Posamezni objekti vključujejo podatke, skupaj z akcijami, ki se potrebujejo v sklopu takšnega objekta[16] Storitveno orientirana arhitektura (Service Oriented Arhitecture SOA) V grobem označuje aplikacije, ki operirajo na osnovi storitev in sporočil, ki potekajo med njimi[16]. 3 Storitveno orientirana arhitektura Glede na to, da se v tem diplomskem delu podrobneje posvečamo tehnologiji SCA ter da le-ta vzpostavlja skupek specifikacij, ki opisujejo model za gradnjo aplikacij, ki sledijo principom SOA, bomo v nadaljevanju najprej podrobneje predstavili koncepte, ki zaokroţujejo SOA. Pri tem bomo uporabili referenčni model SOA OASIS[14][4]. 3.1 Prednosti storitveno orientirane arhitekture Storitveno orientirana arhitektura je paradigma za organizacijo in uporabo distribuiranih virov, ki so lahko pod nadzorom različnih lastniških domen. Tako je sredstvo za organizacijo programskih rešitev, ki promovira ponovno uporabo, rast in interoperabilnost[7].

18 Stran 8 Aleksander Ţagar, Diplomsko delo Pojem storitveno orientirano lahko hitro vzamemo iz konteksta storitveno orientirane arhitekture in ga apliciramo na realen svet. Tam najdemo na eni strani poslovne entitete, ki nudijo storitve, ter na drugi strani druge poslovne entitete oziroma posameznike, ki jih zanimajo učinki teh storitev. Za delovanje takšnega sistema je pomembnih več faktorjev: najprej mora obstajati način, kako se»uporabniki«in»ponudniki«sploh lahko najdejo, nato mora obstajati moţnost interakcije med njimi ter ne nazadnje, najverjetneje najbolj pomembno, ob interakciji mora priti do nekega učinka[7][5]. Tako referenčni model SOA OASIS identificira štiri ključne koncepte za opis paradigme SOA[7]: 1. vidnost (Visibility), 2. interakcija (Interaction), 3. učinek (Effect), 4. storitev (Service). Izmed teh je glavni koncept, ki zaokroţuje rešitve SOA, storitev, ki kot mehanizem na eni strani zdruţuje zmoţnosti ponudnika storitev, na drugi strani pa potrebe uporabnikov. Storitve so v osnovi samostojne logične enote, ob proţenju katerih pride do nekega učinka. S takšnimi avtonomnimi logičnimi enotami je nato omogočena interakcija skozi dobro definirane vmesnike, ki skupaj z opisom zmoţnosti storitve predstavljajo nespremenljivo točko dostopa do storitve in sestavljajo koncept vidnosti storitve. Za medsebojno komunikacijo med ponudniki storitev in njihovimi uporabniki so navadno uporabljena sporočila, ki so prav tako avtonomna enota, ki lahko med ostalim vsebuje tudi informacije o stanju[7]. Sistemi, zasnovani na storitveno orientirani arhitekturi, pridobijo več pozitivnih lastnosti. V takšnem sistemu so vmesniki, skupaj z opisi, edine fiksno določene točke, ki naj bi tudi skozi evolucijo storitve ostale kar se da nespremenjene oziroma kompatibilne. Prav zaradi tega dejstva jim je treba pri načrtovanju posvetiti še posebej veliko pozornost; dejanska implementacija funkcionalnosti storitve se namreč lahko s časom brez teţav spreminja, edini pogoj pri tem je, da ostane v skladu z vmesnikom in opisom storitve ter da nudi enake učinke. Ker takšen vmesnik storitve, skupaj z opisom in določenimi učinki, enoznačno določa njene lastnosti skozi oči končnega uporabnika, imajo uporabniki prav

19 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 9 tako moţnost brez večjih teţav zamenjati ponudnika storitve, seveda pod pogojem, da nov ponudnik nudi kompatibilno storitev. Z uporabo takšne arhitekture se poenostavi tudi dograjevanje sistema oziroma širitev njegovih funkcionalnosti, se pravi naknadno dodajanje novih storitev, saj so le-te implementirane kot avtonomni in šibko sklopljeni deli. Ta avtonomnost nam prav tako zagotavlja, da je pravilno grajen sistem skalabilen, saj lahko po potrebi brez večjih teţav dodajamo večje strojne zmogljivosti, na katerih nato nadalje delujejo obstoječe ter nove storitve. Prav tako je zaradi narave storitev moţno, da v takšnem sistemu ţivi več instanc ene storitve in podobno[7]. Osnovni principi, ki naj bi definirali storitveno orientirano arhitekturo, so tako naslednji[5]: šibka sklopljenost, pogodba storitve, avtonomija, abstrakcija, ponovna uporabnost, moţnost sestavljanja, nevsebovanja stanja pri interakciji, vidnost.

20 Stran 10 Aleksander Ţagar, Diplomsko delo 3.2 Pregled konceptov in njihovih medsebojnih povezav V nadaljevanju bomo naredili podrobnejši pregled storitveno orientirane arhitekture skozi predstavitev osnovnih konceptov, ki so predstavljeni v referenčnemu modelu SOA OASIS. Osnovni koncept referenčnega modela SOA predstavlja storitev sama, okrog katere so nato zbrani ostali koncepti, pri čemer jih lahko razdelimo v dve skupini. Kontekst izvrševanja, opis storitve ter politika in pogodbe so koncepti, ki so neposredno povezani s storitvami. Medtem se na drugi strani učinki, interakcija in vidnost nanašajo na dinamiko interakcije med ponudniki in uporabniki storitev. Kot vidimo, je v ospredju delitev na zmoţnosti v obliki implementiranih funkcionalnosti, ki zadovoljujejo neke potrebe, ter na drugi strani točke dostopa do le-teh[7]. Storitve izgotovijo entitete, ki jih v referenčnem modelu imenujejo ponudniki storitev, naloga le-teh pa je vzpostavitev vseh mehanizmov, ki omogočajo dostop do storitev ter implementacijo funkcionalnosti, ki jih le-te nudijo, ter pri tem poskrbeti, da so skladne s koncepti, ki jih bomo naslovili v nadaljevanju. Na drugi strani imamo uporabnike storitev, ki prek vmesnika in s pomočjo opisa storitve dostopajo do ţelenih funkcionalnosti, ki jih storitve nudijo. Le-teh ne zanima oziroma niti nimajo dostopa do implementacijskih podrobnosti storitve. Na drugi strani pa ponudniki storitev ne poznajo namenov oziroma načina uporabe njihovih storitev. Razlog za interakcijo uporabnika z določeno storitvijo predstavljajo učinki, ki jih lahko razdelimo v tri osnovne skupine[7]: 1. vrnjena informacija v skladu s podano zahtevo; 2. sprememba skupnega stanja (shared state), pri čemer to predstavlja stanje, ki si ga delita tako uporabnik kot ponudnik storitve, in sicer v okviru njunega izvajalnega konteksta; 3. zgoraj našteta v kombinaciji.

21 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Koncepti, neposredno povezani s storitvami V nadaljevanju sledi predstavitev tistih konceptov referenčnega modela, ki so neposredno povezani s storitvami Opis storitve Uporabniki storitve vedno nanjo gledajo kot na škatlo, katere notranji detajli jim niso znani, pri čemer jim le-ta omogoča proţenje nekih operacij, katerih posledica so vnaprej formalizirani učinki. Znotraj takšne škatle se torej proţijo neke privatne akcije, ki niso znane uporabnikom. Poleg teh pa obstajajo še javne akcije, ki predstavljajo točko interakcije z uporabnikom in morajo imeti natančno definirane vmesnike za uporabo, skupaj z opisi, ter opcijsko, če te obstajajo, politike in pogodbe. Opis storitve je bistven skupek informacij, ki so potrebne za uporabo določene storitve, in so»enabler«, da lahko uporabniki sploh uporabljajo storitev oziroma omogočijo kreiranje alternativ ţe obstoječim storitvam. Informacije, ki jih mora zagotavljati takšen opis storitve, vključujejo: informacijo o obstoju in dosegljivosti storitve, katere so funkcionalnosti, do katerih je omogočen dostop skozi storitev, kakšni so pogoji, pod katerimi je mogoče dostopati do teh funkcionalnosti, se pravi njihove politike in pogodbe, kakšen je potek interakcije s storitvijo, skupaj s formatom in vsebino potrebnih informacij, ter če je treba tudi natančno določeno zaporedje takšnih izmenjav. Opis funkcionalnosti mora biti nedvoumen, skupaj z dobro definiranimi rezultati, ki jih lahko uporabniki pričakujejo, ter z vsemi logičnimi omejitvami, na katerih je storitev osnovana. V primeru, ko so s storitvijo povezane določene politike, mora ta vsebovati tudi informacije o le-teh. Pomemben del opisa storitve prav tako predstavlja vmesnik storitve kot točka dostopa do funkcionalnosti storitve in vključuje podrobne informacije o protokolih, ukazih in izmenjavi informacij[7].

22 Stran 12 Aleksander Ţagar, Diplomsko delo Politike in pogodbe Politike znotraj SOA arhitekture, predstavljajo vnaprej definirane omejitve oziroma pogoje uporabe določene storitve. Vsaka takšna politika ima tri vidike: trditev (assertion), lastnika politike (policy owner) ter uveljavljanja trditev (policy enforcement). Primer takšne trditve je na primer:»vsa sporočila so šifrirana«. Pogoj za takšne trditve je, da so merljive, saj je le tako lahko zagotovljeno njihovo upoštevanje (primer»vsa sporočila so šifrirana«predstavlja takšno merljivo trditev, saj jo je moţno ovrednotiti kot resnično ali neresnično). Lastnik politike je lahko na primer ponudnik določene storitve, zagotavljanje takšnih trditev pa je izvedeno z različnimi tehnološkimi prijemi, odvisno glede na naravo politike. Pogodbe so na drugi strani manj toge kot politike, na njih pa lahko gledamo kot na enostranska določila, namenjena ostalim udeleţencem interakcije, in so rezultat nekega dogovora med dvema sodelujočima stranema. Tako pogodbe kot politike se lahko navezujejo na mnogo aspektov storitev, na primer varnost, zasebnost, kakovost storitve (QoS Quality of Service), ure delovanja itd.[7] Kontekst izvajanja Kontekst izvajanja zajema skupek vseh elementov, ki sestavljajo interakcijo med določenim ponudnikom storitve, uporabnikom te storitve in vsemi infrastrukturnimi elementi med njima. Kontekst izvajanja tako označuje točno določeno aktivno povezavo, sestavljeno iz infrastrukturnih elementov, s čimer omogoča diferenciacijo med več instancami iste storitve, saj so le-te medsebojno ločene z različnimi izvajalnimi konteksti. Takšen izvajalni kontekst lahko sluţi kot odločitvena točka pri izvrševanju politik ter opravlja naloge mediacije v primeru, ko je potrebna dodatna interpretacija izmenjanih podatkov med storitvijo in njenimi uporabniki[7]. Če pregledamo zgornje tri koncepte in kako le-ti vplivajo na storitveno orientirano arhitekturo, je gotovo treba najprej posvetiti posebno pozornost opisu storitev, ki ga sestavlja tudi vmesnik, ter jih natančno definirati. Prav ta del naj bi predstavljal neko stalnico oziroma nespremenljiv temelj, na katerem operirajo na eni strani storitve, na drugi strani pa uporabniki takšnih storitev. Kljub temu da je SOA zelo fleksibilna, pa je potrebno, da obstajajo elementi, ki zagotavljajo neko stalnost, na kateri je nato mogoče nadalje graditi. V primeru, da je opis,

23 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 13 skupaj z vmesnikom in ostalimi koncepti, ki ga določajo ţe v fazi načrtovanja, dobro definiran, imamo nato z implementacijskimi podrobnostmi za takšnim vmesnikom povsem proste roke. Implementacija storitve je tako povsem odprta oziroma jo lahko v prihodnosti še dodatno optimiziramo in dograjujemo. Uporabniki storitev pa s tem pridobijo moţnost poljubne uporabe alternativnih storitev, ki so skladno definirane, predpogoj za vse to pa dobro definirana, stabilna osnova. V primeru, če pride do potrebe po»novi verziji«storitve, ki je inherentno nezdruţljiva s staro, je treba ali poskrbeti za dostop do starejše verzije ali pa sestaviti vmesnik nove na takšen način, da ostane komunikacija za vse obstoječe uporabnike nespremenjena. Politike in pogodbe na drugi strani so ţe v osnovi po svoji naravi opcijske, in veliko bolj fleksibilne[7][5]. Slika 2: Grafična predstavitev razmerij predstavljenih konceptov[7]

24 Stran 14 Aleksander Ţagar, Diplomsko delo 3.4 Dinamika interakcije med ponudniki in porabniki storitev Poleg ţe predstavljenih konceptov, ki so neposredno povezani s storitvami, pa so znotraj referenčnega modela SOA definirani še koncepti, ki določajo dinamiko interakcije med ponudniki in uporabniki storitev. Navajamo jih v nadaljevanju besedila Vidnost Vidnost predstavlja razmerje med ponudnikom storitev in njihovimi uporabniki in je predpogoj za kakršno koli interakcijo med njimi. V sklopu vidnosti je zajetih več pogojev, ki morajo biti izpolnjeni, preden lahko pride do interakcije. Prvi med njimi je zavedanje (awareness). Zavedanje preprosto pomeni, da je na eni strani za interakcijo potrebno zavedanje uporabnika storitve o njenem obstoju, na drugi strani pa ponudnika storitve o uporabniku. Referenčni model SOA ne predpisuje tehničnih podrobnosti, kako obe strani pridobita te informacije; uporabnik lahko na primer pridobi znanje o obstoju storitve skozi repozitorij, ki vsebuje opise storitev skupaj z njihovimi politikami ali pa storitev sama oglašuje svoje funkcionalnosti vsem potencialnim uporabnikom. Vlogi pa sta lahko tudi zamenjani v tem primeru uporabnik oglašuje svoje potrebe in upa, da se bo odzvala storitev, ki jih izpolnjuje. Storitev v večini primerov lahko pridobi potrebne podatke o uporabniku ţe s tem, ko jo ta kontaktira, s čimer pridobi vse potrebne podatke za nadaljnjo interakcijo. Za uporabnike storitve pa osnovo, skozi katero se zavedajo obstoja storitev in njihovih zmoţnosti, predstavljajo opisi storitev in njihovih politik, katerih vsebinske zahteve smo ţe naslovili. Poleg zavedanja je prav tako pomembno, da je storitev pripravljena sodelovati z uporabnikom (willingness), ki jo je kontaktiral. V primeru, da ta zaradi takšnih ali drugačnih razlogov ni pripravljena na sodelovanje z določenim uporabnikom, interakcija ne more steči. Sama pripravljenost storitve za sodelovanje je lahko povezana s politikami, katerih se morajo drţati potencialni uporabniki v primeru, ko ţelijo komunicirati s storitvijo. Tako na primer lahko storitev, če zaradi okoliščin pride do sklepa, da je prišlo do namernega ali nenamernega napada DDOS (Distributed Denial of Service), zavrača zahteve uporabnikov oziroma se na njih sploh ne odziva. Kot zadnji izmed konceptov, povezanih z vidnostjo, je tukaj še dosegljivost (reachability). Dosegljivost predstavlja zadnjega izmed temeljev, na katerih temelji vidnost. Namreč tudi

25 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 15 če ima uporabnik vse potrebne podatke, se pravi opis, skupaj s politikami in vmesnikom itd., ter na podlagi le-teh poizkuša komunicirati s storitvijo, je lahko interakcija neuspešna v primeru, ko storitev zaradi tehničnih razlogov ni dosegljiva. Razlogi za to so lahko raznovrstni, vse od tega, da je določena storitev nedosegljiva zaradi tehničnih teţav, do na primer tega, da je dosegljiva samo znotraj določenega omreţja, katerega del potencialni uporabnik ni[7] Interakcija s storitvami Interakcija s storitvami predstavlja naslednjega izmed temeljnih konceptov referenčnega modela SOA. Interakcija s storitvami je namreč osnovni razlog, čemu storitve sploh obstajajo, in ji je zato med načrtovanjem rešitve, ki temelji na arhitekturi SOA, treba posvetiti še posebno pozornost. Interakcija s storitvami je formalno definirana kot proţenje ţelenih akcij, ki nudijo storitve. Sicer takšen način interakcije v referenčnem modelu ni natančno definiran in pušča odprte tehnične podrobnosti, vendar v večini primerov temelji na osnovi sporočil. Le-ta so zaradi ţelje po kar se da visoki splošnosti storitev in s tem omejenega hranjenja stanj interakcij praktično samostojna entiteta, ki mora hraniti vse potrebne vsebine pri interakciji kar sama. Za karakterizacijo informacij, na katerih je osnovana interakcija, je v referenčnem modelu definiran informacijski model storitve. Le-ta je omejen samo na podatke in informacije, ki se bodo izmenjevale v okviru interakcije, in se ne ukvarja s podrobnostmi implementacije storitve ter kako je rešen njen notranji podatkovni model, čeprav je na nek način njegov posredni derivat. Informacijski model je v grobem razdeljen na dva dela: sintaktičnega, katerega naloga je predstavitev tehničnih podrobnosti o informacijah, ki se bodo izmenjevale v okviru interakcije. Le-ta na primer določa, da morajo obstajati natančno določene informacije, in sicer vse od uporabljenega enkodiranja pri zapisu znakov, prek formata, v katerem bodo informacije posredovane, do njihovih podatkovnih tipov. S temi podatki informacijski model pridobi predvsem podatke o obliki sporočil, vendar pa le-ti ne zadostujejo za pravilno interpretacijo podatkov; zato so potrebne še dodatne vsebinske informacije, ki naj bi jih zagotavljal semantični del.

26 Stran 16 Aleksander Ţagar, Diplomsko delo Če vzamemo izmenjavo sporočil kot osnovo interakcije, je poleg strukture in ostalih tehničnih podrobnosti najpomembnejši del enaka interpretacija vsebovanih informacij tako na strani uporabnika kot ponudnika. Drugače rečeno: tako ponudnik storitve, kot tisti, ki jo koristi, si morata enako razlagati, kaj predstavlja vsebina, vključena v sporočilih. Zato je potreben formalen opis vseh izrazov, vključenih v takšnih sporočilih, in to skupaj z njihovimi razmerji, s pomočjo katerih je nato mogoča nedvoumna interpretacija sporočil. Poleg naštetega je v okviru modela obnašanja potrebna še karakterizacija vseh akcij, ki jih določena storitev nudi. Pri tem ne igra vloge del obnašanja, ki je privaten, temveč»javni«učinki določene storitve. Poleg tega je treba potencialnemu uporabniku predstaviti proces interakcije z določeno storitvijo, skupaj z njegovimi začasnimi vidiki, katerih primer je, da storitev zahteva avtentikacijo pred določenimi akcijami itd.[7] Dejanski učinki Vsak uporabnik določene storitve skozi interakcijo z njo proţi akcijo, ki nato skozi privatno logiko rezultira v določenih učinkih, le-ti pa predstavljajo namen, čemu je uporabnik sploh proţil storitev. Drugače rečeno: uporabniku storitve interakcija predstavlja način, kako priti do ţelenega rezultata[7]. Ta rezultat je v referenčnem modelu definiran kot dejanski učinek določene storitve (real world effect). Dejanski učinek je lahko v treh oblikah: kot neposreden odgovor uporabniku storitve v obliki informacij, v obliki spremembe skupnega stanja, kot kombinacija obeh skupaj.

27 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 17 Slika 3: Grafična predstavitev razmerij predstavljenih konceptov[7]

28 Stran 18 Aleksander Ţagar, Diplomsko delo 4 SCA V tem poglavju bomo predstavili zgodovino tehnologije SCA, nato opravili pregled vseh konceptov, ki jih zaokroţuje, in nanizali povezave med njimi. Ko bomo vzpostavili osnove za razumevanje tehnologije, pa sledi še podrobnejši pregled vsakega izmed njih, in sicer skupaj z nekaterimi glavnimi lastnostmi. 4.1 Zgodovina Kljub temu da je tehnologija SCA dobila znotraj IT sveta res pravi zagon šele v zadnjih nekaj letih, je njena pot krepko razpotegnjena skozi preteklo desetletje, začenši z letom Skozi to desetletje je ubrala nekoliko drugačno pot razvoja, kot smo je drugače vajeni v primeru tehnologij, namenjenih razvoju aplikacij poslovnega sveta, če za primer vzamemo CORBA, Java EE in ostale, ki so jih oblikovali uradni specifikacijski odbori. Da danes poznamo SCA v takšni obliki, je bilo potrebno, da se je poklopilo več dejavnikov. Skozi leta so namreč tehnološki vlečni konji IT industrije, kot so IBM, SAP, Oracle in drugi, ugotovili, da zaprte lastniške tehnologije, pri katerih ni toliko poudarka na standardizaciji kot na omogočanju inovativnih funkcionalnosti, ki bi predstavljale glavni razlog za širšo sprejetost, niso nujno najboljša pot oziroma pot, ki bi tehnologiji zagotovila svetlo prihodnost[7]. Začetki tehnologije SCA, kot jo poznamo danes, tako segajo v leto 2003, ko sta IBM in BEA začela sodelovati na projektu, ki ga danes poznamo pod imenom SCA. Pri tem je osnova temeljila na izkušnjah oziroma tehnologijah, ki so ţe bile izgotovljene v okviru predhodnih, tako internih kot sodelujočih, projektih obeh podjetij[7]. K njima so se v letu 2005 priključili še Oracle, SAP, IONA in Sybase, s katerimi so nato skupaj izoblikovali iniciativo Open SOA oziroma krajše OSOA. Nad tehnologijo SCA torej ni bdelo nobeno standardizacijsko telo oziroma organizacija. Ta bolj»ad hoch«pristop k razvoju tehnologiji je pomenil veliko večjo dinamičnost pri spremembah specifikacij, ki so se dogajale skozi čas, kar je vsekakor veliko pripomoglo k hitremu»odraščanju«tehnologije. Standardizacijske organizacije sicer po eni strani s svojo prisotnostjo prinesejo neko stalnost in dobro definirano organizacijsko strukturo, ki je nato osnova pri nadaljnjih revizijah specifikacij in s tem pri razvoju tehnologije. Vsak predlog

29 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 19 oziroma nova funkcionalnost, ki naj bi bila dodana v prihajajoči verziji, mora tako iti skozi zapletene postopke, ki zagotovijo, da bo nova verzija specifikacij kar se da konsistentna s trenutno aktualno, in podobno, pri čemer gre takšna delovna verzija specifikacij skozi mnogo različnih osnutkov in revizij. To je seveda zaţeleno, ko govorimo o ţe uveljavljenih tehnologijah s široko prisotnostjo na trţišču, saj specifikacije same predstavljajo nekakšno vez med ogromno različnimi entitetami. Vendar po drugi strani s svojo birokratizacijo in procesi v okviru te zelo upočasnijo razvoj, kar vsekakor ni idealno v primeru»mladih«tehnologij, ki so šele v svojih prvih razvojnih stopnjah. Podjetja, ki so sodelovala pri razvoju tehnologije SCA, so ravno zaradi bolj»sproščenega«pristopa imela povsem proste roke nad njenim odraščanjem. Tako so si sledile hitre spremembe specifikacij, ki so lahko bile v nasprotju z določenimi deli prejšnje verzije in podobno. Prav to obdobje med leti 2003 in 2005 oziroma 2007 je najverjetneje najbolj zaznamovalo in definiralo SCA ter prav ta neformalnem postopek razvoja je najbolj pripomogel, da je danes tehnologija SCA enakovredna alternativa ţe bolj uveljavljenim tehnologijam na trgu in z vsakim letom pridobiva na konkurenčnosti[2]. Z marcem 2007, ko so specifikacije SCA prišle do različice 1.0, pa so podjetja v okviru iniciative OSOA predala nadaljnje delo razvoja specifikacij SCA organizaciji OASIS[17]. Pomembnejše zgodovinske ločnice v razvoju tehnologije SCA[18]: december, 2003: BEA in IBM začneta skupaj z delom na SCA; november, 2005: izdana različica 0.9 specifikacij, priključijo se še Oracle, SAP, IONA in Sybase; julij, 2006: izdane specifikacije 0.95, priključijo se Cape Clear, Interface21, Primeton Technologies, Progress Software, Red Hat, Rogue Wave, Siemens AG, Software AG, Sun in TIBCO; marec 2007: izdaja specifikacij 1.0; april 2007: OASIS oblikuje»open CSA Member Section«; september 2007: začetek formalne standardizacije znotraj OASIS Open CSA; julij 2008: izdan prvi osnutek specifikacij verzije 1.1; februar 2011: izdan trenutno aktualni sedmi osnutek specifikacij verzije 1.1.

30 Stran 20 Aleksander Ţagar, Diplomsko delo 4.2 Pregled osnovnih konceptov tehnologije SCA Na sodobne aplikacije lahko gledamo kot na skupke programskih komponent, ki so fizično ali logično ločeni oziroma lahko tudi oboje. Vse te komponente so lahko grajene z uporabo različnih tehnologij, ki najbolje ustrezajo potrebam pri določenem projektu oziroma problemski domeni. Takšne aplikacije morajo izpolnjevati predvsem dva pogoja: najprej mora obstajati način kreiranja komponent, poleg tega pa je potreben še mehanizem za opis, kako te delujejo kot celota. Prav SCA definira splošen pristop, ki zadovoljuje obe predstavljeni zahtevi. Skozi svoje specifikacije namreč definira, kako kreirati komponente, ter jih nadalje povezati v semantično zaokroţene skupke. Prav to sestavljanje oziroma»assembly«predstavlja osnovno tehnologijo SCA. Osnova specifikacij SCA je namreč SCA Assembly Model, poleg tega specifikacije SCA sestavljajo še Component Implementation Specification, Binding Specification ter Policy Framework. Kot bomo v nadaljevanju predstavili, je tehnologija SCA zelo odprta in ni vezana na določen programski model, niti ne vključuje obširnih nizkonivojskih implementacijskih podrobnosti, ki bi na primer določale oziroma opisovale tehnološko rešitev za komunikacijo med komponentami, kar ima, kot bomo ugotovili, tako svoje prednosti kot slabosti[3]. OSOA definira SCA kot:»storitveno komponentna arhitektura je skupek specifikacij, ki opisuje model za gradnjo aplikacij in sistemov z uporabo storitveno orientirane arhitekture. Storitveno komponentna arhitektura razširja in dopolnjuje predhodne pristope k implementaciji storitev ter pri tem gradi na odprtih standardih.«[ 17] Preden se bolj podrobno spustimo v pregled, kaj vse prinaša SCA, je najbolje, da naprej naredimo pregled osnovnih konceptov, ki jih prinaša, in predstavimo, kako so ti medsebojno povezani, tako da dobimo nek višji vpogled na celoto, ki jo okvirja SCA. SCA v osnovi sestavljajo 4 osnovni koncepti, ti so[2]: storitve, komponente, kompozicije, domene.

31 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 21 Za oporo pri naši nadaljnji predstavitvi nam bo naslednji diagram, ki predstavlja abstrakten primer aplikacije, grajene s pomočjo tehnologije SCA: Slika 4: Abstrakten primer aplikacije SCA[3] Če začnemo s komponento kot najmanjšo zaokroţeno celoto, ta predstavlja osnovni sestavni del aplikacije SCA. Komponente nudijo storitve in lahko za svoje pravilno delovanje temeljijo na referencah na storitve drugih komponent. Implementacija takšnih komponent je znotraj SCA povsem tehnološko odprta in je večinoma omejena s tem, kakšne vsebnike (containers) omogoča določena implementacija tehnologije SCA, ki smo jo izbrali. V teoriji to pomeni, da so takšne komponente lahko implementirane v Javi, in sicer s pomočjo ogrodja Spring, v BPEL, C++, C, COBOL, katerih uporabo natančno specificirajo specifikacije. Vendar pa te ne izključujejo uporabe drugih tehnologij: na primer implementacija Tuscany SCA omogoča implementacijo komponent s pomočjo raznolike moţice skriptnih jezikov, kot na primer Python, Fabric3 definira svoje implementacijske tipe, kot na primer Timer, implementacija frascati na drugi strani omogoča implementacijo s pomočjo fraktalov poseben komponentni model, razvit v okviru OW2 konzorcija. Prav vsi pa nudijo tudi moţnost definiranja oziroma razširitve

32 Stran 22 Aleksander Ţagar, Diplomsko delo izvajalnega okolja s poljubnimi implementacijskimi tipi. Če pogledamo ta pester skupek tehnologij, vsekakor govori v prid raznolikosti in odprtosti tehnologije SCA. V nadaljevanju se takšne komponente zdruţujejo v višje enote, ki se imenujejo kompoziti. Kompoziti so tako stopničko višje kot komponente in predstavljajo konfiguracijsko enoto skupka določenih komponent. Za opis takšnih kompozitov se uporablja na XML grajen jezik, imenovan Service Component Definition Language (SCDL izgovorjeno SKID-EL). Na koncu imamo še domene. Domena je preprosto skupek izvajalnih okolij (runtime enviroments) določenega proizvajalca, v katerih bodo na koncu nameščeni zgoraj predstavljeni kompoziti. Če povzamemo, imamo najprej domeno SCA, domena nato vsebuje več kompozitov, ki jih sestavljajo komponente, ki se izvajajo v enem ali več procesih, ki tečejo na enem ali več sistemih. Kot smo ţe omenili v začetku, so specifikacije SCA, kar se tehničnih podrobnosti implementacije takšnih izvajalnih okolij tiče, zelo odprte, iz česar sledi, da bodo različni ponudniki na različne oziroma njim lastne načine rešili, na primer, komunikacijo znotraj elementov, ki jih vključuje domena. Kar pa ne pomeni, da elementi znotraj domene niso zmoţni komunikacije z»zunanjim svetom«, saj je ta še vedno mogoča skozi, na primer, uporabo spletnih storitev oziroma podobnih tehnološko dobro definiranih in široko sprejetih tehnologij, katerih uporaba se»predpiše«s pomočjo eksplicitnih vezav. Ta ureditev ima svoje dobre in tudi slabe plati; na eni strani omogoča diferenciacijo izdelkov različnih proizvajalcev na trţišču, saj lahko vsak izmed njih implementira optimizacije, ki se njemu zdijo smiselne, in s tem pridobi konkurenčno prednost pred ostalimi. Po drugi strani pa na nek način s strani podjetja, ki uporablja takšne izdelke, izbira določenega proizvajalca njih priklene nanj, saj so domene lahko sestavljene le iz izdelkov istega proizvajalca in komunikacija z domeno, sestavljeno iz drugega proizvajalca, ni neposredno mogoča. Če naredimo pregled zgoraj podanega, je tehnologija SCA sestavljena iz skupka specifikacij. Te specifikacije so[19]: Assembly Model namenjen definiciji strukture kompozitnih aplikacij;

33 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 23 Component implementation specification podaja osnovne implementacijske podrobnosti za implementacijo komponent z uporabo različnih tehnologij; Binding specification definira moţnosti za sklopljenost med posameznimi deli aplikacij SCA; Policy framework operiranje s politikami, kot na primer varnost, transakcije, zagotovljeno dostavljanje itd. Glavne značilnosti, ki jih prinaša tehnologija SCA so[19]: šibka sklopljenost, fleksibilnost, preprosto je tako sinhrono kot asinhrono proţenje storitev, končna rešitev je zgrajena v obliki kompozicije manjših delov, povečana produktivnost skozi preprostejšo integracijo komponent Komponente (Components) Komponente predstavljajo najmanjši osnovni gradnik pri gradnji aplikacij SCA. Ti osnovni gradniki naj bi omogočali funkcionalnosti, ki so nato izpostavljene skozi storitve. Dosegljivost takšne komponente, se pravi dostop do njene storitve, je nato predvsem odvisna od konfiguracije komponente oziroma kompozita, v katerega je vključena. Tako lahko omogočimo dostop do določene komponente skozi njeno storitev ostalim komponentam znotraj domene SCA, v kateri je kompozit, katerega del je komponenta. Lahko pa poskrbimo, da je takšna storitev komponente dosegljiva tudi zunaj domene SCA, in sicer z uporabo tehnologije, kot so na primer spletne storitve, RMI (Remote Method Invocation) in podobno. Za medsebojno povezovanje komponent in kompozitov se nadalje uporabljajo reference. Če na primer na določeno komponento veţemo referenco, to pomeni, da implementacija takšne komponente za svoje delovanje potrebuje neko storitev, ki je lahko izgotovljena v okviru druge komponente, ki jo izpostavlja kot storitev. Prav tako pa jih lahko poveţemo s storitvami, ki jih nudijo drugi sistemi zunaj domene SCA. Reference torej predstavljajo pogodbo, ki jo mora izpolnjevati storitev, katere funkcionalnost je potrebna za izvajanje.

34 Stran 24 Aleksander Ţagar, Diplomsko delo Komponente so drugače nastavljeni primerki instance določene implementacije, pri čemer je lahko več komponent vezanih na eno implementacijo in ima pri tem povsem drugačne konfiguracijske nastavitve.»understanding SCA«jih definira kot:»znotraj tehnologije SCA komponenta predstavlja nastavljeno programsko kodo, ki omogoča eno ali več storitev. Odjemalec se lahko poveţe s takšno storitvijo in proţi operacije, ki jih storitev izpostavlja.«[2] Kreiranje komponent je, kot je razvidno iz zgoraj podane definicije, sestavljeno iz dejanske implementacije takšne storitve, pri čemer implementacija ni vezana na točno določeno tehnološko platformo, ampak je omogočen širok spekter tehnologij, s katerimi lahko komponente implementiramo, ter konfiguracije takšne implementacije s pomočjo XML besednjaka SCDL, kjer se definira interakcija komponente, njene lastnosti in ostalo. S komponentami so neposredno povezane storitve in reference, poleg teh pa imajo lahko komponente tudi lastnosti. Lastnosti komponente predstavljajo vrednosti, določene znotraj konfiguracije SCDL, do katerih lahko implementacija komponente dostopa med svojim delovanjem. Storitve, reference in lastnosti skupaj sestavljajo koncept, ki se znotraj tehnologije SCA imenuje implementacijski komponentni tip.

35 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 25 Slika 5: Grafična predstavitev komponente z njenimi referencami, storitvami in lastnostmi[19] Takšna delitev komponent na več posameznih sestavnih delov, se pravi na implementacijo, storitve, ki jih nudi, reference, ki jih potrebuje za svoje delovanje, in lastnosti, ki jih pri tem uporablja, je lahko v veliko pomoč pri dojemanju sistema, zgrajenega iz kompozicije takšnih komponent. Tako je namreč preprosto razbrati odvisnosti, ki se pojavljajo znotraj sistema, ter prilagoditi njegovo delovanje z uporabo lastnosti, ki so vezane na posamezne komponente, kompozite in podobno. Vse to, brez da bi bilo treba poznati kakršne koli implementacijske podrobnosti. Na drugi strani so prav tako razvijalci veliko bolj svobodni, kar se tiče izbire tehnologije, ki jo bodo uporabili pri razvoju, pri čemer jim ni treba podrobno spoznavati novih API-jev (Application Programming Interface), ki bi bili povezani z uporabo določenih funkcionalnosti tehnologije same, saj je večina teh odgovornosti delegiranih na izvajalno okolje SCA[13][4][3][2] Implementacija komponent Razvijalci imajo pri implementaciji komponent relativno široko izbiro različnih alternativ, vsaj napram ostalim primerljivim tehnologijam, ki so navadno vezane na en programski model. Sicer je dejanska izbira vezana predvsem na to, kakšna je podpora za posamezne

36 Stran 26 Aleksander Ţagar, Diplomsko delo tehnologije znotraj določene implementacije tehnologije SCA, ki jo nameravamo uporabljati, ampak kljub temu imamo navadno moţnost izbire med več tehnologijami, pri čemer jih lahko tudi medsebojno kombiniramo. Znotraj domene SCA lahko domujejo in komunicirajo komponente, ki so implementirane s pomočjo različnih tehnologij, tako lahko brez kakršnih koli dodatnih naporov sodelujeta na eni strani komponenta, implementirana v programskem jeziku C++, in na drugi strani druga komponenta, implementirana v jeziku BPEL. Pri tem se programski modeli, ki jih specificira SCA, trudijo nuditi način implementacije, pri katerem je v glavni vlogi predvsem osredotočenost na poslovno logiko, ki naj bi jo določena implementacija zagotavljala, in ne razne tehnološke podrobnosti, ki so na primer povezane s tem, kako vzpostaviti in nato nadalje uporabljati komunikacijo z neko drugo komponento in podobno. Tako delno odpade uporaba zapletenih API-jev, upravljanje, s katerimi s seboj ne prinaša samo zahteve po podrobnem poznavanju uporabe le-teh, temveč tudi omejuje splošnost rešitve, saj bi bilo treba v primeru kakršnih koli sprememb, ki se tičejo dela, definiranega na takšen način, ponovno poseči v programsko kodo in jo prilagoditi. Programski modeli SCA rešujejo to z uporabo dodatnih anotacij, na podlagi katerih nato izvajalno okolje skupaj s podano konfiguracijo komponente lahko izvede ţeleno. S tem dobimo veliko bolj»čisto«programsko kodo, ki je osredotočena na bistvo problema, ki ga rešuje. Poleg tega pa je takšna rešitev zelo prilagodljiva, saj so konfiguracijski aspekti preneseni na konfiguracijo komponent, s pomočjo katerih je moţno njihovo obnašanje prilagoditi, brez da bi zato morali poseči v implementacijo, kar je navadno znotraj velikih poslovnih okolij še posebej kompleksna procedura. Na splošno pa pri implementaciji komponent predstavljajo prej omenjene storitve, reference in lastnosti konfiguracijske vidike implementacije in jih znotraj assembly modela naslavlja komponentni tip (component type), ki formalno definira razmerje med implementacijo in definicijo storitve[13][4]. Pri uporabi programskega modela Java informacije, ki jih zajema component type, izvajalno okolje SCA dejansko pridobi s preverjanjem uporabljenih anotacij znotraj implementacije, saj je celotna procedura agregacije takšnih informacij avtomatizirana. Mogoče pa je tudi, da so te informacije podane eksplicitno v obliki datoteke component type, kjer natančno definiramo vse potrebne informacije s pomočjo datoteke XML. Takšna

37 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 27 component type datoteka je v primeru uporabe implementacijske tehnologije, ki omogoča uporabo anotacij, sicer poljubna, vendar pa jo je treba dodati v primeru uporabe tehnologije, ki ne omogoča takšne predstavitve potrebnih informacij, na primer BPEL[13][4]. Zelo pomembno vlogo pri implementaciji igrajo vmesniki, katerih namen je definicija funkcionalnosti, ki nudijo storitve oziroma se na njih sklicujejo reference. Vsak takšen vmesnik definira vse potrebne informacije. Poleg ţe omenjenih funkcionalnosti, ki naj bi jih storitev nudila, so tukaj še potrebni podatki o sporočilih, ki se uporabljajo v primeru povpraševanja in vračanja rezultata ob povpraševanju in podobno. SCA v trenutno aktualni verziji 1.0 podpira vmesnike, podane v obliki Javanskih vmesnikov, in vmesnike, definirane s pomočjo besednjaka WSDL 1.1 oziroma z novejšim WSDL 2.0. Pri tem je treba omeniti omejitev pri definiranju vmesnikov v obliki vmesnikov Java, kjer je pogoj, da morajo biti le-ti napisani tako, da je mogoče te izraziti tudi z jezikom WSDL. Verzija specifikacij SCA 1.1, ki je trenutno v delu, ne narekuje več podpore vmesnikom WSDL 2.0, vendar pa to ne bi smelo povzročati prevelikih teţav, saj izvajalna okolja SCA omogočajo definiranje lastnih načinov definicij vmesnikov. To baziranje na vmesnikih omogoča različne pristope k implementaciji funkcionalnosti, ki jih določajo vmesniki. Tako se lahko razvijalci odločijo za»top down«pristop, pri katerem se najprej definira vmesnik v obliki WDSL, na podlagi katerega je kasneje izgotovljena sama funkcionalnost, ki jo opisuje. Lahko je vrstni red tudi obrnjen, pri čemer se najprej implementirajo funkcionalnosti, na podlagi katerih se kasneje izgotovi WDSL opis, ki jim ustreza[2]. Zgodba z vmesniki tukaj še ni zaključena, saj imajo le-ti več pomembnih lastnosti, ki neposredno vplivajo na obnašanje aplikacij SCA. Tako pridemo do delitve na več tipov vmesnikov. Če naštejemo samo pomembnejše[13][4]: Local interfaces lokalni vmesniki, Remotable interfaces oddaljeni vmesniki, Bidirectional interfaces obojestranski vmesniki, Conversational interfaces pogovorni vmesniki.

38 Stran 28 Aleksander Ţagar, Diplomsko delo Lokalni in oddaljeni vmesniki (Local and remote interfaces) Prilagodljivost tehnologije SCA s seboj prinaša tudi določene omejitve, ki jih morajo razvijalci upoštevati pri implementaciji komponent. Tako delimo uporabnike oziroma odjemalce storitev na lokalne in oddaljene, pri čemer so za oddaljene označeni vsi, ki se ne izvajajo v istem procesu kot storitev sama, se pravi, da v to kategorijo spada vse od procesov, ki tečejo v okviru istega operacijskega sistema, odjemalcev, ki se izvajajo v okviru domene SCA na fizično ločenih enotah, pa tudi odjemalcev, ki se izvajajo zunaj domene SCA. Medtem ko so lokalni»odjemalci«tisti, ki se izvajajo v okviru istega procesa kot storitev, na primer ko znotraj istega navideznega stroja Java (JVM) tečeta tako odjemalec kot tudi storitev. Bistvena razlika, do katere pride med tema dvema situacijama, je predvsem v posledicah, ki so povezane z njima. Oddaljene storitve imajo namreč ţe inherentno določene lastnosti, ki jih je treba upoštevati, preden jih uporabimo, kot na primer, da bodo vsi parametri posredovani po vrednosti»by value«, se pravi, da bo storitev dejansko operirala nad kopijo posredovanih podatkov in da bo moralo izvajalno okolje poskrbeti za pretvorbo in posredovanje le-teh. Zaradi narave komunikacijskega kanala ne moremo poznati časa, potrebnega za komunikacijo s takšno storitvijo. Vse te lastnosti se odraţajo pri grajenju oziroma implementaciji storitev oziroma odjemalcev, ki bodo uporabljali takšne storitve. Prav zato so ustvarjalci tehnologije SCA upoštevali, da ni vedno nujno, da obravnavamo vse storitve kot oddaljene in da lahko v primerih, ko vemo vnaprej, da bosta tako odjemalec kot storitev tekla znotraj istega procesa, to tudi izkoristimo. Zato imamo pri kreiranju vmesnikov moţnost opredeliti le-te kot lokalne oziroma oddaljene. To je mogoče storiti na več načinov: na primer v primeru uporabe Javanskih vmesnikov so vsi, ki eksplicitno ne uporabljajo lokalni, na drugi strani pa so vsi vmesniki, definirani z jezikom WSDL, lahko samo in izključno public interface javainterface { int test(); } Primer 1: Primer oddaljenega vmesnika v Javi

39 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 29 class cppinterface { public: virtual int test(); } Primer 2: Primer enakega vmesnika v C++ <service name="cppinterface"> <interface.cpp header="cppinterface.h" remotable="true"/> </service> Primer 3: Definicija Component type za zgornji primer, katerega eksplicitna definicija ni potreba, saj lahko izvajalno okolje pridobi potrebne informacije iz anotacij Obojestranski vmesniki (Bidirectional interfaces) Pri običajnih operacijah, ki jih nudijo storitve, je treba omeniti, da gre za t. i.»blocking calls«. Proţilec določene operacije mora torej počakati, da se le-ta izvede in mu vrne rezultat, šele nato lahko nadaljuje s svojim delom. Takšna lastnost lahko predstavlja teţavo v primerih, ko imajo operacije, ki jih proţimo, relativno dolge čase izvajanja oziroma so le-ti nepredvidljivi. Če njihov rezultat ni nujno potreben za nadaljnje delovanje odjemalca, je na operacijah vmesnika komponente mogoča uporaba pri metodah, ki vračajo tip void, s čimer postane operacija»non-blocking«. Vendar pa v določenih primerih ţelimo, da po proţenju storitve lahko normalno nadaljujemo z delom, saj ta ne predstavlja posebnega vpliva na naše nadaljnje delo, vendar pa bi vseeno ţeleli biti obveščeni o rezultatu zahtevane operacije; tukaj pa nastopi moţnost uporabe obojestranskih vmesnikov. V zgoraj opisanem primeru je teţavo mogoče rešiti s tem, da se definirata dva vmesnika. Na eni strani imamo običajen vmesnik, ki definira operacije, ki jih nudi določena komponenta, poleg tega pa v primeru obojestranskih vmesnikov uporabljamo še en vmesnik, ki ga mora implementirati odjemalec, ki kliče takšno storitev. Ta definira operacije, ki jih proţi storitev po končanem procesiranju zahteve. Na ta način pridobimo moţnost»non-blocking«klicev skupaj z odloţenim procesiranjem rezultatov[13][3][4][3].

40 Stran 30 Aleksander Ţagar, Diplomsko delo Pogovorni vmesniki (Conversational interfaces) Pogovorni vmesniki naslavljajo še enega izmed potencialnih primerov uporabe oziroma načinov obnašanja pri interakciji med storitvami in njihovimi odjemalci. Komponente, ki smo jih do sedaj opisovali, so namreč po naravi»stateless«, se pravi, da ne hranijo stanja med komunikacijo z določeno storitvijo in njenim odjemalcem. Kar pa v nekaterih primerih ni nujno ţeleno, če za primer vzamemo komponento, pri kateri bi ţeleli, da pred začetkom nudenja določenih operacij zahteva avtentikacijo in avtorizacijo. V tem primeru bo operiranje s takšno storitvijo sestavljeno iz več vnaprej določenih klicev različnih operacij storitve, pri čemer bodo obstajale določene omejitve. V takšnem primeru bi ţeleli, da odjemalec po opravljeni avtentikaciji in avtorizaciji lahko normalno dostopa do operacij, ki jih nudi storitev. Tako pridemo do točke, ko je treba»obdrţati«neko vzpostavljeno stanje za obdobje določene komunikacije, ki bo sestavljena iz več klicev. Tukaj nastopi moţnost uporabe pogovornih vmesnikov, ki jih je znotraj programskega modela Java mogoče določiti z dodatnimi Takšni pogovorni vmesniki so sicer določeni znotraj trenutno aktualnih Assembly Specification 1.0, vendar pa je njihova prihodnost pod vprašajem, saj so izvzeti iz najnovejših predlog specifikacij 1.1, in to predvsem zaradi pomanjkanja standardizacije znotraj industrije na tem področju[13][4][3][2] Storitve (Services) SCA Assembly Model definira storitve kot»naslovljive vmesnike implementacije«. Storitve kot take predstavljajo komunikacijsko točko znotraj domene SCA in glede na konfiguracijo lahko tudi zunaj le-te. Se pravi, da je primaren namen storitev nudenje določenih funkcionalnosti neke implementacije komponente[4]. Vsaka storitev ima svoje ime, katerega namen je ločevanje znotraj določenega konteksta, vmesnik storitve pa določa vse ostale lastnosti, povezane s takšno storitvijo, njene vhode, izhode, operacije itd. Storitve bi lahko nadalje tipizirali na več načinov; najprej glede na to, ali so definirane na nivoju komponente ali kompozita. Pri tem storitve na nivoju komponente neposredno izpostavljajo funkcionalnosti, ki jih nudi implementacija takšne komponente. Storitve na

41 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 31 nivoju kompozita pa na drugi strani samo»izpostavljajo«obstoječe storitve določene komponente, ki se nahaja znotraj kompozita. Po drugi strani bi jih lahko delili glede na vmesnike, s katerimi so definirane njihove implementacije, in tako bi lahko govorili o delitvi na lokalne oziroma globalne storitve[4]. Storitve, ki jih zagotavlja določena komponenta, so definirane s samo implementacijo komponente, zaradi te tesne sklopljenosti z implementacijo pa se razlikujejo tudi načini, kako so storitve definirane glede na uporabljen implementacijski tip komponente[13][4][3][2] Reference (References) Reference komponent in kompozitov si lahko predstavljamo kot koncept storitve komponente ali kompozita, obrnjen na glavo. Se pravi ne samo, da lahko določena komponenta drugim nudi neke storitve, tudi sama lahko za svoje delovanje temelji na uporabi določenih funkcionalnosti, ki jih ne implementira sama, ampak so del neke druge komponente, ki jih izpostavlja kot storitve. Komponenta lahko to doseţe z uporabo referenc. Definicija reference je zaradi močne sklopljenosti z implementacijo, ta je namreč tista, ki za svoje delovanje potrebuje»zunanje vire«, spet odvisna predvsem od tega, kakšen implementacijski tip uporablja komponenta[13]. Ta princip eksplicitnega izraţanja zahtev pri povezavi različnih komponent na osnovi storitev in reference prinaša številne pozitivne lastnosti. Na ta način ne pridobimo samo jasno izraţene strukture aplikacije, kjer ţe samo površen pregled njenih povezav obeleţi soodvisnosti med različnimi deli aplikacije, Ampak s seboj prinaša tudi t. i.»dependency injection«, kar v praksi pomeni, da lahko razvijalci vse povezovalne podrobnosti prenesejo iz kode na izvajalno okolje SCA tako, da programska koda bolj ali manj vsebuje samo zadeve, ki se neposredno tičejo problema, ki ga rešuje. Prav tako se zaradi načina, kako so takšne povezave definirane znotraj tehnologije SCA, poenostavijo nadaljnje»prevezave«komponent, brez da bi se sploh kakor koli morali dotikati ali poznati implementacijo komponente. Pri referencah je treba omeniti še eno lastnost, ki je neposredno povezana z njimi. SCA namreč določa moţnost, s katero lahko referenco poveţemo s poljubno mnogo storitvami,

42 Stran 32 Aleksander Ţagar, Diplomsko delo kjer je edini pogoj ta, da morajo storitve implementirati isti vmesnik, kot ga zahteva referenca sama[13][4][3][2] Lastnosti (Properties) Komponenta SCA ima lahko definirane tudi svoje lastnosti, ki omogočajo konfiguracijo njene implementacije. Na ta način obstaja moţnost enostavnega in centraliziranega načina vplivanja na izvajanje implementacije, brez da bi zato bile potrebne kakršne koli spremembe v programski kodi. Uporaba takšnih lastnosti je odvisna od tega, za kakšen implementacijski tip se odločimo pri implementaciji komponente[13][4][3][2] Žice (Wires) Povezave med določeno storitvijo in referenco znotraj tehnologije SCA označujejo oziroma definirajo»ţice«. Načinov definiranja povezav je več, vse pa v osnovi temeljijo na konfiguraciji z uporabo datotek SCDL. Ţice lahko preprosto določimo z uporabo elementa <reference> na določeni komponenti znotraj kompozita, pri čemer se sklicujemo na drugo komponento, čemur bi lahko rekli implicitna ţica. Poleg te imamo moţnost uporabe samostojnega elementa <wire> znotraj kompozita, ki definira obe strani ţice, se pravi znotraj takšnega elementa eksplicitno določimo obe komponenti, ki nato komunicirata prek takšne»ţice«; zaradi te lastnosti bi lahko rekli, da gre za eksplicitno deklaracijo ţice. Pri avtowire tipu povezave komponent znotraj določenega kompozita celotno proceduro povezovanja prepustimo izvajalnemu okolju. Znotraj določenega kompozita definiramo njegove komponente in nato izvajalno okolje na podlagi storitev, ki jih izpostavljajo komponente na eni strani, in referenc, ki jih potrebujejo na drugi strani, izpelje potrebne povezave, se pravi kreacije ţic. V tem primeru so»pravila«, ki jih postavljajo specifikacije, zelo ohlapna in večinoma so vse podrobnosti, kot na primer, kaj bi se zgodilo v primeru, ko je znotraj kompozita več storitev, ki ustrezajo določeni referenci, prepuščena proizvajalcu, ki je implementiral izvajalno okolje SCA[13][4][3][2].

43 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Vezave (Bindings) Vezave so koncept, vezan na storitve in reference; SCA namreč podpira pisano mnoţico različnih protokolov, namenjenih komunikaciji, in prav tako nudi moţnost eksplicitne vezave določene storitve oziroma reference na točno določenega izmed njih oziroma na več izmed teh. Definicija vezave na referencah oziroma storitvah sicer ni zahtevana, v takšnem primeru se kot privzeti tip privzame binding.sca, pri čemer je dejanska implementacija takšnega tipa povsem odvisna od tega, kaj se je posameznim proizvajalcem, ki nudijo implementacije tehnologije SCA, zdelo najbolj primerno oziroma učinkovito. Tako bi lahko proizvajalci zaradi ţelje po čim večji učinkovitosti posegli po lastniških binarnih protokolih, kar je eden izmed razlogov, zakaj se lahko v posamezne domene SCA vključujejo samo izvajalna okolja enega proizvajalca[13]. Poleg tipa binding.sca pa SCA podpira še mnoţico drugih tipov. Če jih naštejmo nekaj, ki so podani znotraj SCA Assembly Model[14]: SCA service, Web service, stateless session EJB, database stored procedure, EIS service. Ni pa izključena moţnosti uporabe drugačnih tipov, saj implementacije vključujejo mehanizme, s pomočjo katerih je mogoče izvajalnim okoljem dodati nove tipe vezav. Pri vezavah je treba omeniti način, kako se definirajo, vezave namreč spet predstavljajo konfiguracijske podrobnosti in so tako določene znotraj datoteke SCDL določenega kompozita. To pomeni, da je dejanska programska koda»očiščena«implementacijskih podrobnosti, povezanih s takšnimi povezavami. S tem pa v prihodnosti pridobimo moţnost zamenjave protokolov brez kakršnih koli sprememb programske kode. Poleg tega SCA omogoča, da ima določena storitev ali referenca definiranih več tipov povezav, s čimer razširimo moţnosti komunikacije, ki jih ima ena komponenta[3]. Uporaba eksplicitnih vezav sluţi tudi temu, da se v domeni SCA ustvarijo vhodne točke, prek katerih lahko tudi

44 Stran 34 Aleksander Ţagar, Diplomsko delo odjemalci, ki niso del domene, dostopajo do funkcionalnosti storitev, na katere so vezane. Na drugi strani pa imajo komponente znotraj SCA domene moţnost povezave s storitvami, ki niso znotraj iste domene ali pa sploh niso ustvarjene s pomočjo tehnologije SCA Kompoziti (Composites) Kompoziti SCA predstavljajo enoto logične sklopljenosti določenih komponent skupaj z njihovimi konfiguracijami znotraj izvajalnega okolja SCA, za definicijo katerih se uporabljajo SCDL datoteke s svojim XML besednjakom. Kompozit SCA vsebuje več konfiguriranih komponent, ki nudijo storitve, uporabljajo določene reference, so povezane z ţicami in imajo komunikacijske protokole eksplicitno določene z»vezavami«ter omogočajo določene nastavitve skozi uporabo lastnosti. Kompoziti prav tako nudijo nekatere bolj kompleksne funkcionalnosti. Prva takšna zanimiva funkcionalnost, ki jo omogočajo, je promocija (promotion). Kompoziti namreč omogočajo promovirati določene storitve in reference takšnih komponent, kar pomeni, da preloţimo le-te na sam kompozit, s čimer postanejo»vidne«kot storitve oziroma reference kompozita. Kompozite lahko nato uporabljamo na več načinov: lahko znotraj določenega kompozita uporabimo prej omenjeni kompozit, ki promovira določene storitve in reference kot implementacijo neke komponente, pri čemer za implementacijski tip uporabimo implementation.composite; to pa ni edini moţen način dodajanja nekega kompozita v nek drug kompozit. Obstaja namreč še druga moţnost dodajanja, t. i. vključenost, (inclusion) pri čemer vsa vsebina določenega kompozita postane tudi vsebina drugega kompozita. Poleg tega lahko kompoziti vsebujejo svoje lastnosti, ki jih je mogoče nato vezati na same komponente znotraj takšnega kompozita in podobno[4][13][3][2].

45 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 35 Slika 6: Primer kompozita z dvema komponentama <csa:composite xmlns:csa=" name="kompozit" targetnamespace=" stuff/test"> <csa:component name="komponenta 1"> <csa:reference name="referenca 1"/> <csa:reference name="referenca 2"/> <csa:service name="storitev 1"/> </csa:component> <csa:component name="komponenta 2"> <csa:service name="storitev 2"/> <csa:reference name="referenca 3"/> </csa:component> <csa:wire source="komponenta 1/Referenca 2" target="komponenta 2/Storitev 2" source2="#komponenta 1/Referenca 2" target2="#komponenta 2/Storitev 2"/> <csa:reference name="referenca 3" promote="komponenta 2/Referenca 3"/> <csa:reference name="referenca 1" promote="komponenta 1/Referenca 1"/> <csa:service name="storitev 1" promote="komponenta 1/Storitev 1"/> </csa:composite> Primer 4: Primer dejanske datoteke SCDL, ki definira zgornji primer kompozita

46 Stran 36 Aleksander Ţagar, Diplomsko delo Slika 7: Vizualizacija skupka predstavljenih konceptov in njihovih medsebojnih povezav[19] Prispevki (Contributions) Prispevki znotraj tehnologije SCA predstavljajo skupek vseh potrebnih elementov, ki na primer sestavljajo določeno aplikacijo SCA, ki se bo izvajala znotraj izvajalnega okolja SCA; oziroma bolj splošno: skupke nekih datotek, ki bi jih radi namestili znotraj določenega izvajalnega okolja SCA. Takšni prispevki sicer niso nič drugega kot zapakirane datoteke v formatu ZIP, ki vsebujejo vse potrebne datoteke, ki bi jih radi namestili znotraj nekega izvajalnega okolja. Poleg vseh zadev, ki so neposredno povezane s SCA kot definicije kompozitov in njihovih komponent znotraj datotek SCDL, sem spadajo še dejanske implementacijske datoteke, definicije vmesnikov itd. Prispevki omogočajo tudi razne naprednejše moţnosti, kot je izvoz določenih vsebin iz posameznega prispevka in uvoz v drugega, s čimer se prepreči podvajanje določenih datotek na več mestih znotraj ene domene; tako lahko več komponent iz različnih kompozitov uporablja dejansko eno implementacijsko datoteko in podobno[4][13].

47 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Ogrodje politik (Policy Framework) Obnašanje delovanja komponent znotraj okolja SCA lahko postane zelo kompleksno, pri čemer pa so še vedno ţeleli ohraniti agilnost same tehnologije. S tem razlogom vključuje SCA tudi SCA policy framework. S tem je mogoče znotraj datoteke SCDL za posamezne storitve določiti t. i. trditve politike delovanja (policy assertion) oziroma v primeru nekaterih programskih modelov lahko za to uporabimo tudi anotacije. Takšne politike nato specificirajo, da mora določena komponenta teči znotraj okvira transakcije, da mora biti dostava določenega sporočila zagotovljena in podobno. Dejanska implementacija politik predstavljajo povsem ločeno enoto, izvajalna okolja pa prav tako navadno ţe vsebujejo nekatere bolj običajne politike in omogočajo moţnost razširitve z lastnimi[4][3] Domene (Domains) Domena predstavlja še zadnjega izmed gradnikov tehnologije SCA in z vidika uporabnikov tehnologije prav gotovo tudi najpomembnejšega. Koncept domene je znotraj tehnologije SCA določen kot skupek konfiguriranih izvajalnih okolij določenega proizvajalca, ki med seboj sodelujejo. Takšna domena je lahko poljubno velika, pri čemer omogoča tudi nadaljnjo razširljivost v primeru, če se izkaţe, da je trenutna konfiguracija»podhranjena«. Domene torej predstavljajo repozitorij, v katerem»ţivijo«aplikacije SCA in so hkrati tudi njihovo izvajalno okolje znotraj katerega tečejo. Za nameščanje aplikacij SCA v domene se uporabljajo prispevki, ki vsebujejo kompozite skupaj z vsemi njihovimi potrebnimi datotekami. Same implementacijske podrobnosti izvajalnih okolij, ki sestavljajo domene, so sicer specifične glede na različne proizvajalce, v osnovi pa je vsem skupno, da zagotavljajo naslednje zmoţnosti[2]: upravljavske kapacitete (management), ogrodje za definiranje politik (policy framework), osnovo za deljenje virov (resource and artifact sharing), komunikacijsko infrastrukturo (common communication infrastructure), razširljivost (extensibility).

48 Stran 38 Aleksander Ţagar, Diplomsko delo 5 Pregled odprtokodnih implementacij tehnologije SCA Poleg komercialnih implementacij tehnologije SCA, ki jih nudijo podjetja, kot so IBM, Oracle itn., je na voljo tudi več odprtokodnih implementacij, ki sledijo trenutno aktualnim specifikacijam verzije 1.0 ter posamično v nekaterih primerih tudi ţe specifikacijam verzije 1.1. Prav na tri izmed teh se bomo osredotočili v nadaljevanju diplomskega dela. 5.1 Izvajalno okolje Apache Tuscany SCA Tuscany SCA je najstarejša med odprtokodnimi implementacijami tehnologije SCA. Razvija se v sklopu Apache Software Fundation in je izdano pod licenco Apache 2.0. Delo na projektu se je začelo ţe decembra leta 2005, se pravi ţe kar dve leti prej, preden je bila izdana prva»stabilna«verzija specifikacij, ko sta podjetji IBM in BEA Systems odprli oziroma predali do tedaj interno razvito programsko kodo. Prva stabilna različica 1.0, ki je implementirala specifikacije SCA 1.0, je nato izšla septembra 2007, samo slabega pol leta za tem, ko so bile izdane specifikacije same. Zasnovano je kot»lahko«in prilagodljivo izvajalno okolje, ki omogoča konfiguracijo tako samostojne kot tudi porazdeljene domene. Njegova modularna zasnova omogoča končnim uporabnikom, da sami izberejo module, ki ustrezajo njihovim zahtevam, ter da po ţelji tudi sami spišejo svoje in tako razširijo ter prilagodijo delovanje svojim potrebam[21][23][24]. Sam projekt Tuscany SCA je sestavljen iz več raznolikih izvajalnih okolij. Tako so na voljo: 1. Tuscany SCA Java obe veji, ki sta implementirani v Javi, omogočata poleg samih specifikacij še širok nabor funkcionalnosti izven spektra specifikacij ter sta redno posodobljeni: a. Tuscany SCA Java 1.X, b. Tuscany SCA Java 2.X; 2. Tuscany SCA Native je implementiran v jeziku C++ in trenutno ni v aktivnem razvoju.

49 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 39 Tuscany SCA Java 1.X je implementirano v Javi, zadnja verzija je bila izdana aprila 2011 in implementira naslednje dele specifikacij SCA[24]: SCA Assembly Model V1.0, SCA Policy Framework V1.0, SCA Java Common Annotations and APIs V1.0, SCA Java Component Implementation V1.0, SCA Spring Component Implementation V1.0, SCA BPEL Client and Implementation V1.0, SCA Web Services Binding V1.0, SCA EJB Session Bean Binding V1.0. Poleg tega izven okvira specifikacij SCA omogoča naslednje: - vezave po meri: Direct Web Remoting, RSS and ATOM Feeds, HTTP resources, JSON-RPC, PUB/SUB Notifications, RMI; - implementacijski tipi po meri: OSGI, XQuery, Groovy, Javascript, Python, Ruby.

50 Stran 40 Aleksander Ţagar, Diplomsko delo Tuscany SCA Java 2.X je prav tako implementiran v Javi, ampak z razliko od veje 1.X ţe implementira specifikacije SCA verzije 1.1, ki so še v postopkih obdelave. V času pisanja tega besedila je zadnji izdan osnutek le-teh iz januarja 2011, zadnja 2.0 beta 2 verzija izvajalnega okolja, izdana februarja 2011, pa podpira naslednje dele 1.1 specifikacij SCA [25]: SCA Assembly Model V1.1, SCA Policy Framework V1.1, SCA Java Common Annotations and APIs V1.1, SCA Java Component Implementation V1.1, SCA Web Services Binding V1.1, SCA JMS Binding V1.1, SCA Spring Client and Implementation V1.1, SCA WS-BPEL Client and Implementation V1.1, SCA JEE Integration V1.1 (delno). Izven okvira specifikacij SCA omogoča naslednje: - vezave po meri: RMI, HTTP, JSON-RPC, ATO. Tuscany SCA Native je povsem ločena veja, ki je implementirana v programskem jeziku C++, zadnja izdana verzija je M3 iz meseca maja leta Ta veja projekta implementira naslednje dele specifikacij SCA[26][27]: SCA Assembly Model V0.96, SCA C&C++ Component Implementation V0.95.

51 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 41 Izven specifikacij SCA nudi: - implementacijski tipi po meri: Python, Ruby. 5.2 Izvajalno okolje Fabric3 Fabric3 je odprtokodna implementacija tehnologije SCA, ki se razvija pod okriljem podjetja Metaform Systems. Izdana je pod GNU GPL licenco, z GNU Classpath Exception klavzulo. Je prva implementacija SCA, ki je implementirala verzijo specifikacij 1.1. Kot pri ţe predstavljenem Tuscany SCA je ena izmed njenih prednosti s strani končnih uporabnikov razširljiva modularna zasnova. Tudi Fabric3 omogoča izvajanje v obliki samostojne in distribuirane domene. V trenutno zadnji izdani verziji 1.8, ki je bila izdana maja 2011, implementira naslednje dele specifikacij SCA[28][29]: SCA Assembly Model V1.1, SCA Policy Framework V1.1, SCA Java Common Annotations and APIs V1.1, SCA Java Component Implementation V1.1, SCA Web Services Binding V1.1, SCA JMS Binding V1.1, SCA Spring Client and Implementation V1.1. Osnovne funkcionalnosti osnovnih specifikacij razširja z: - vezave po meri: Web, FTP; - implementacijski tipi po meri: Timer,

52 Stran 42 Aleksander Ţagar, Diplomsko delo Web. 5.3 Izvajalno okolje FraSCAti FraSCAti je še zadnja odprtokodna implementacija SCA in smo se ji v tem diplomskem delu podrobneje posvetili. Cilja pri njenem razvoju sta bili predvsem kompaktnost in učinkovitost. Najbolj opazna razlika v primerjavi z ţe predstavljenima Fabric3 in Tuscany je, da ne podpira koncepta distribuirane domene. Implementacija je izdana pod GNU GPL licenco in v trenutno aktualni različici 1.3, izdani avgusta 2010, implementira naslednje dele specifikacij SCA[30][31]: SCA Assembly Model (v1.0), SCA Policy Framework (v1.0) (delno), SCA Transaction Policy (v1.0), SCA Java Common Annotations & APIs (v1.0), SCA Java Component Implementation (v1.0), SCA Web Services Binding (v1.0), SCA Spring Component Implementation v1.0) (delno). Omogoča dodatne funkcionalnosti izven okvira specifikacij: - implementacijski tipi po meri: Fractal, OSGI, Scala; - vezave po meri: RMI, JNA, UPnP.

53 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Odprtokodno orodje za razvoj aplikacij SCA SCA Tools V pomoč pri razvoju aplikacij SCA je, kar se odprtokodnih orodij tiče, trenutno v okviru Eclipse SOA Tools Platform na voljo SCA Tools, pri katerem gre za razširitev ogrodja Eclipse, ki razvijalcem aplikacij SCA prinaša naslednje funkcionalnosti[32][33]: SCA Composite Designer t. i. GMF Graphical Modeling Framework omogoča konstrukcijo kompozitnih aplikacij skozi preprost grafični uporabniški vmesnik; SCA XML Editor urejevalnik datotek XML, primarno namenjen operiranju z datotekami SCDL; SCA Form Editor urejevalnik form; SCA Builder namenjen validaciji artefaktov SCA: SCA Launcher v pomoč pri poganjanju in razhroščevanju SCA Java projektov, ki tečejo na podprtih platformah SCA kar znotraj okolja Eclipse; SCA Composite to Java Generator za generiranje ogrodja programske kode v programskem jeziku Java na podlagi podanih kompozitov SCA; SCA Composite Introspection tool v pomoč pri izgradnji datotek SCA assembly, z uporabo t. i. od spodaj navzgor pristopa, in sicer na podlagi obstoječih POJO in komponentnih tipov; SCA Samples skupek vnaprej pripravljenih projektov SCA, namenjenih spoznavanju tehnologije ter orodja; trenutno podpira izvajalna okolja Tuscany, FraSCAti in Fabric3.

54 Stran 44 Aleksander Ţagar, Diplomsko delo Slika 8: Grafični oblikovalnik kompozitov SCA[20] Slika 9: Urejevalnik datotek SCDL[20]

55 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 45 6 Primerjava predstavljenih izvajalnih okolij Pri primerjavi izvajalnih okolij smo preverili podporo osnovnim tipom storitev, ki sestavljajo specifikacije SCA, in izmerili, kakšne so zmogljivosti posameznih izvajalnih okolij pri njihovi uporabi. Za izvedbo testa smo implementirali namensko aplikacijo SCA, ki je vključevala vse tipe storitev, ki so zajeti v sklopu specifikacij SCA Assembly Model 1.0. Pri tem smo testno aplikacijo ţe v osnovi razdelili na več sodelujočih kompozitov z namenom, da se bodo ti izvajali v okviru porazdeljene domene, vsak znotraj svojega izvajalnega okolja. Za povezavo komponent (t. i. ţice wires) znotraj domene smo v vseh primerih uporabili tip binding.sca, ki naj bi sluţil prav namenu povezav med različnimi komponentami znotraj domene. Ker specifikacije glede implementacijskih podrobnosti takšnega tipa vezave puščajo povsem proste roke razvijalcem izvajalnih okolij, se nam je na tej točki zdelo še posebej zanimivo preveriti, kakšne so posledice tega pri zmogljivostih med različnimi izvajalnimi okolji. Zanimalo nas je tudi, kakšni so odzivni časi pri uporabi testne aplikacije v idealnih okoliščinah in na drugi strani v primeru večjega števila hkratnih zahtev. V sklopu teh testov smo vseskozi tudi spremljali porabo procesorskega časa in pomnilnika. 6.1 Predstavitev osnovnih karakteristik merjenja zmogljivosti Osnovne karakteristike, na katerih smo gradili našo primerjavo posameznih izvajalnih okolij, so bile naslednje: - Ali izvajalno okolje podpira vse osnovne tipe storitev iz specifikacij SCA verzije 1.0? - Ali izvajalno okolje podpira koncept porazdeljene domene (katerega specifikacije sicer ne zahtevajo, ga pa omenjajo kot moţnost)? - Kakšne so obremenitve procesorja in pomnilnika v primeru, ko je testna aplikacija v stanju mirovanja (ne streţe nobenim zahtevam)?

56 Stran 46 Aleksander Ţagar, Diplomsko delo - Kakšne so strojne obremenitve, če simuliramo streţenje več hkratnim zahtevkom? - Kolikšno količino zahtevkov lahko opravi v določeni časovni periodi, ob polni obremenitvi, ko zahtevke hkrati pošilja večje število odjemalcev? - Kakšne so zakasnitve pri komunikaciji med različnimi tipi storitev, ki tečejo v fizično ločenih instancah znotraj iste domene? - Kakšne so zakasnitve pri komunikaciji med različnimi tipi storitev, ki tečejo znotraj iste instance izvajalnega okolja? 6.2 Predstavitev testne aplikacije Testna aplikacija je bila implementirana v skladu s trenutno aktualnimi specifikacijami SCA verzije 1.0. Pri čemer smo komponente razdelili v več kompozitov ter vse skupaj zapakirali znotraj enega prispevka. Na ta način smo lahko pri testiranju z lahkoto premeščali posamezne kompozite znotraj domene ter tako preizkušali različne scenarije in posledice, ki so jih le-ti imeli na delovanje in zmogljivost aplikacije. Vse komponente smo implementirali v Javi, in sicer predvsem zaradi tega, ker je najbolje podprt implementacijski tip v vseh treh preizkušenih izvajalnih okoljih. Na ta način smo lahko testno aplikacijo brez večjih prirejanj izvajali v povsem enakih okoliščinah znotraj vseh treh izvajalnih okolij in tako pridobili primerljive rezultate, na katerih so nato bazirale naše ugotovitve. Pri implementaciji testne aplikacije smo implementirali naslednje vrste storitev: - tipi lokalnih storitev (local services): i) brez stanja (Stateless), ii) kompozitna (Composite), iii) s povratnim klicem (Callback), iv) pogovorna (Conversational), v) enosmerna (OneWay);

57 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 47 - tipi oddaljenih storitev (remotable services): i) brez stanja (Stateless), ii) kompozitna (Composite), iii) s povratnim klicem (Callback), iv) pogovorna (Conversational), v) enosmerna (OneWay). Zgoraj opisane tipe storitev smo razporedili v enajst komponent, te pa nato nadalje v tri kompozite, ki so nam predstavljali osnovno enoto pri namestitvi.»vstopno točko«testne aplikacije je predstavljala storitev, izpostavljena v obliki spletne storitve, s katero smo vseskozi operirali testiranje. Za povezave vseh potrebnih komponent znotraj testne aplikacije pa smo uporabili privzeti tip binding.sca.

58 Stran 48 Aleksander Ţagar, Diplomsko delo Slika 10: Grafični prikaz delne strukture testne aplikacije

59 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Podrobna predstavitev testne aplikacije V nadaljevanju sledi predstavitev glavnih delov aplikacije, uporabljene pri testiranju, razgrajena po komponentah, ki so jo sestavljale Komponenta entry_component Izpostavlja storitve, dosegljive znotraj domene: - service1, tip: stateless + remotable Izpostavlja storitve, dosegljive zunaj domene: - service1, tip: stateless + remotable, dosegljiva, kot spletna storitev Vsebuje reference na naslednje storitve: - hub_component /service2 Definirana znotraj: Composite1 Entry_component je preprosta komponenta SCA, ki ima eno storitev in eno referenco. Implementirana je v Javi ter skozi service1 storitev sluţi kot vhodna točka za»zunanji svet«v testno aplikacijo. Tej storitvi smo namreč eksplicitno določili binding.ws, in jo tako izpostavili na naslovu v obliki spletne storitve. Poleg le-te komponenta vsebuje še referenco na storitev iz komponente hub_component, katere naloga je nadaljnje delegiranje oziroma klicanje različnih tipov storitev znotraj testne aplikacije, in to skupaj z agregiranjem podatkov, ki ob tem nastanejo. Tako se ob proţenju storitve service1 znotraj entry_component najprej vzpostavijo osnovna stanja objektov, ki jih nadalje uporabljamo pri merjenju posamičnih karakteristik različnih storitev ter se pošljejo storitvi service2 iz komponente hub_component, ki je zadolţena za izračun ter zapis pridobljenih informacij.

60 Stran 50 Aleksander Ţagar, Diplomsko delo <service name="service1"> </service> <interface.java interface="test.service1" /> <binding.ws uri=" Primer 5: Deklariranje storitve komponente skupaj z eksplicitno izraženo vezavo znotraj datoteke SCDL kompozita composite Komponenta hub_component Izpostavlja storitve, dosegljive znotraj domene: - service2, tip: stateless + remotable Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: - test_local_callback /service4_1 - test_local_conversational /service4_2 - test_local_composite /service4_3 - test_remotable_callback /service5_1 - test_remotable_conversational /service5_2 - test_remotable_composite /service5_3 - test_remotable_stateless /service5_4 Definirana znotraj: Composite2 Hub_component komponenta ima eno storitev in sedem referenc ter je predstavljala glavno»stičišče«testne aplikacije. Prav njena storitev service2, ki jo proţi komponenta entry_component, je namreč zadolţena za klice vseh raznolikih storitev, ki sestavljajo testno aplikacijo ter merjenje zakasnitev, ki so se pri tem pojavile.

61 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 51 Pri tej nalogi sta ji v pomoč dva povsem običajna razreda POJO (Plain Old Java Object), to sta resultagregator ter timingstuff, od katerih je prvi samo vsebnik več objektov drugega, drugi pa vsebuje logiko, ki smo jo potrebovali za merjenje zakasnitev, do katerih prihaja znotraj aplikacije pri uporabi različnih tipov storitev, in na koncu za zapisovanje rezultatov na datotečni sistem. package test; import org.osoa.sca.annotations.*; public class service2impl implements service2, service4_1callback, service5_1callback{ //local, stateless same protected service3_1 service3_1ref; //remote, stateless same protected service3_2 service3_2ref; //local, protected service4_1 service4_1ref; //local, protected service4_2 service4_2ref; //local, protected service4_3 service4_3ref; //remote, protected service5_1 service5_1ref; //remote, protected service5_2 service5_2ref; //remote, protected service5_3 service5_3ref; protected service5_4 service5_4ref; public service2impl() {

62 Stran 52 Aleksander Ţagar, Diplomsko delo } public void dotest(resultagregator ra, byte[] barr) { System.out.println("service2Impl - dotest"); ra.invokelocalsamevm.start(); service3_1ref.invokelocalsamevm(barr); ra.invokelocalsamevm.stop(); ra.invokeremotesamevm.start(); service3_2ref.invokeremotesamevm(barr); ra.invokeremotesamevm.stop(); ra.invokeremote.start(); service5_4ref.invokeremote(barr); ra.invokeremote.stop(); ra.invokecallbackservice.start(); service4_1ref.invokecallbackservice(ra, barr); ra.invokeconversationalservice.start(); service4_2ref.invokeconversationalservice(barr); service4_2ref.endconversation(); ra.invokeconversationalservice.stop(); ra.invokecompositeservice.start(); service4_3ref.invokecompositeservice(barr); ra.invokecompositeservice.stop(); ra.invokecallbackserviceremote.start(); service5_1ref.invokecallbackservice(ra, barr); ra.invokeconversationalserviceremote.start(); service5_2ref.invokeconversationalservice(barr); service5_2ref.endconversation(); ra.invokeconversationalserviceremote.stop(); ra.invokecompositeserviceremote.start(); service5_3ref.invokecompositeservice(barr); ra.invokecompositeserviceremote.stop(); } public void callbackmethod(resultagregator ra, byte[] barr) {

63 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 53 } System.out.println("service2Impl - callbackmethod"); ra.invokecallbackservice.stop(); public void callbackmethodremote(resultagregator ra, byte[] barr) { System.out.println("service2Impl - callbackmethodremote"); ra.invokecallbackserviceremote.stop(); } } Primer 6: Implementacija razreda storitve service2, ki jo izpostavlja komponenta hub_component Komponenta test_local_stateless Izpostavlja storitve, dosegljive znotraj domene: - service3_1, tip: stateless + local Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite2 Komponenta test_local_stateless izpostavlja samo eno storitev, ki je tipov stateless in local. Se pravi, da je dosegljiva samo ostalim komponentam, ki se izvajajo znotraj istega navideznega stroja Java. Iz tega, da je stateless, pa sledi, da zadeva ne hrani nikakršnega stanja. Izvajalno okolje za vsako zahtevo po takšnem tipu storitve ustvari novo instanco, katere ţivljenjska doba je enaka trajanju streţenja zahteve. V testni aplikaciji je bila namenjena ugotavljanju zakasnitev pri uporabi storitve local + stateless, in sicer pri scenariju, kjer se tako odjemalec kot ponudnik izvajata znotraj istega izvajalnega okolja.

64 Stran 54 Aleksander Ţagar, Diplomsko delo Komponenta test_remotable_stateless_same_rt Izpostavlja storitve, dosegljive znotraj domene: - service3_2, tip: remotable + stateless Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite2 Komponenta test_remotable_stateless_same_rt daje na voljo eno storitev tipov remotable ter stateless. Kot smo ţe omenili, storitve tipa remotable omogočajo oddaljeno proţenje. Tako jih lahko brez kakršnih koli posebnih nastavitev uporabljajo vse komponente, ki se izvajajo znotraj iste izvajalne domene. Se pravi, da jih lahko proţijo tudi tiste komponente, ki se fizično izvajajo znotraj ločenega izvajalnega okolja, ki pa je del enake domene. Če nadalje takšnim storitvam določimo kakšno eksplicitno vezavo, pa lahko poskrbimo, da so hkrati dosegljive tudi izven domene. V testni aplikaciji je bila storitev service3_2 namenjena testiranju zakasnitev, do katerih pride, če kličemo storitve tipa remotable + stateless znotraj istega kompozita. Se pravi tako odjemalec kot ponudnik storitve sta se nahajala znotraj istega izvajalnega okolja. Tako smo tudi dobili vpogled v to, kako je takšna storitev primerljiva s storitvijo tipa stateless in kakšen je padec zmogljivosti zaradi različnega operiranja s parametri, o čemer smo ţe pisali pri opisu tehnologije SCA.

65 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Komponenta test_local_callback Izpostavlja storitve, dosegljive znotraj domene: - service4_1, tip: local + callback + oneway Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite2 Komponenta Test_local_callback izpostavlja eno storitev, tokrat tipov local in callback. Kot smo ţe pri opisu tehnologije SCA omenili, takšen tip storitve omogoča»nonblocking«klice, pri čemer se rezultati naknadno posredujejo odjemalcu, ki je storitev proţil. V našem primeru smo komponento test_local_callback uporabili za pridobitev podatkov o tem, kakšne zakasnitve lahko pričakujemo pri tem tipu storitve, ko gre za klic znotraj istega JVM. Pri klicu metode callback smo uporabili še tip oneway, ki je poskrbel za»nonblocking«klic metode, ki smo jo znotraj vmesnika»callback«v datoteki SCDL zadolţili za procesiranje rezultatov Komponenta test_local_conversational Izpostavlja storitve, dosegljive znotraj domene: - service4_2, tip: local + conversational Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite2 Komponenta test_local_conversational izpostavlja lokalno storitev tipa conversational, z njeno pomočjo pa smo pridobili podatke o tem, kakšne zakasnitve lahko pričakujemo v

66 Stran 56 Aleksander Ţagar, Diplomsko delo primeru uporabe takšnega tipa storitve, in sicer v primeru njenega klica znotraj istega izvajalnega okolja Komponenta test_local_composite Izpostavlja storitve, dosegljive znotraj domene: - service4_3, tip: local + composite Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite2 Komponenta test_local_composite se nahaja znotraj kompozita Composite2 in izpostavlja lokalno storitev tipa composite. Pri storitvah tega tipa v izvajalnem okolju obstaja natanko ena instanca storitve, v nasprotju s stateless, kjer se ob vsakem povpraševanju kreira nova. Komponento smo uporabili za testiranje zakasnitev pri klicih takšnega tipa storitve, ki se proţijo znotraj istega izvajalnega okolja Komponenta test_remotable_callback Izpostavlja storitve, dosegljive znotraj domene: - service5_1, tip: remotable + callback Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite3

67 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 57 Komponenta test_remotable_callback se nahaja znotraj kompozita Composite3 in daje na razpolago eno storitev tipov remotable in callback. Uporabili smo jo za pridobivanje podatkov o tem, do kakšnih zakasnitev prihaja pri uporabi tega tipa storitve, ko gre za oddaljene klice, se pravi, ko klient in ponudnik storitve ne tečeta znotraj istega izvajalnega okolja, ampak iz drugega, ki se nahaja znotraj iste domene. <component name="component5_1"> <implementation.java class="test.service5_1impl"/> <service name="service5_1"> <interface.java interface="test.service5_1" callbackinterface="test.service5_1callback"/> </service> </component> Primer 7: Deklaracija predstavljene komponente Komponenta test_remotable_conversational Izpostavlja storitve, dosegljive znotraj domene: - service5_2, tip: remotable + conversational Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite3 Komponenta test_remotable_conversational je bila uporabljena za pridobitev podatkov o zakasnitvah, ki jih lahko pričakujemo pri storitvah tipov remotable in conversational, in sicer v primeru oddaljenega proţenja znotraj iste domene.

68 Stran 58 Aleksander Ţagar, Diplomsko delo Komponenta test_remotable_composite Izpostavlja storitve, dosegljive znotraj domene: - service5_3, tip: remotable + composite Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite3 Komponenta test_remotable_composite vsebuje eno storitev tipov remotable in composite in je sluţila za pridobitev podatkov o tem, kakšne so zakasnitve pri proţenju takšnega tipa storitve, ko se odjemalec in ponudnik nahajata v različnih izvajalnih okoljih znotraj iste domene Komponenta test_remotable_stateless Izpostavlja storitve, dosegljive znotraj domene: - service5_4, tip: remotable + stateless Izpostavlja storitve, dosegljive zunaj domene: / Vsebuje reference na naslednje storitve: / Definirana znotraj: Composite3 Zadnja komponenta, tj. komponenta test_remotable_stateless, je vsebovala preprosto storitev tipov remotable in stateless, uporabili pa smo jo za pridobitev podatkov o tem, kakšne so zakasnitve pri tem tipu storitve, ko gre za oddaljen klic v isti domeni.

69 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Testiranje Za pridobitev informacij o zakasnitvenih časih pri uporabi različnih tipov storitev smo implementirali razreda resultagregator in TimingStuff. Pri tem je resultagregator vseboval en primerek razreda TimingStuff za vsak posamezen tip storitve, ki smo jih testirali. Razred TimingStuff je nato skozi javno dosegljive metode nudil moţnosti začetka meritve časa, konca ter zapisa pridobljenih vrednosti v datoteko. Zaradi ţelje po čim bolj relevantnih podatkih smo za naloge obremenitve komunikacijskega kanala med posameznimi storitvami pošiljali polje bajtov velikosti 1024 enot. Storitev service1 je bila izpostavljena kot spletna storitev, zaradi česar jo je bilo moţno proţiti tudi izven domene SCA, in je imela nalogo kreirati objekt tipa resultagregator in polje bajtov. Za tem pa je to vsebino posredovala storitvi service2, ki je sluţila kot glavni hub, od koder se je izvajalo avtomatizirano zbiranje podatkov, ki so nam sluţili kot osnova pri primerjavi zakasnitev med različnimi izvajalnimi okolji Uporabljena orodja Kot pomoč pri razvoju in nato testiranju smo uporabili več različnih orodij. Pomembnejša izmed teh so bila: Oracle VirtualBox Odprtokodno orodje, namenjeno virtualizaciji, ki ga razvija podjetje Oracle. Notepad++ Vključeval je vse osnove funkcionalnosti, ki smo jih potrebovali pri implementaciji komponent v programskem jeziku Java, kreiranju in urejanju njihovih konfiguracijskih datotek ter za urejanje konfiguracijskih datotek, potrebnih za vzpostavitev in nastavitve izvajalnih okolij. Apache JMeter Na vseh nivojih testiranja smo uporabili odprtokodno orodje Apache JMeter, skozi uporabo katerega smo pridobili raznolike načine izvajanja poizvedb in zbiranja podatkov v okviru teh.

70 Stran 60 Aleksander Ţagar, Diplomsko delo YourKit V primerih, ko smo zaradi nepričakovanega obnašanja potrebovali moţnost nekoliko naprednejšega profiliranja, smo uporabili sicer komercialno orodje YourKit, pri čemer smo izkoristili moţnost 15-dnevnega brezplačnega preizkusa. Microsoft Preformance Monitor Za spremljanje in zbiranje podatkov o porabi procesorskega časa, pomnilnika in podobno, od procesov, ki so sestavljali porazdeljeno domeno, v kateri je tekla testna aplikacija, smo uporabili Microsoftovo orodje Preformance Monitor. Slika 11: Posnetek zaslona orodja Apache JMonitor Opis testiranja Vsaka porazdeljena domena, v katero smo namestili testno aplikacijo, je tekla na povsem sveţe nameščenem operacijskem sistemu Windows Server 2003 R2 znotraj virtualnega sistema, postavljenega s pomočjo orodja Oracle VirtualBox verzije 4. Temu sistemu je bil dodeljen en procesor Intel Core2 Duo, ki je tekel pri 2,3 GHz skupaj z 1,5 GB pomnilnika, na sistemu je poleg tega bila še nameščena Java update 25 in orodja, ki smo jih potrebovali za zbiranje podatkov, na katerih smo nadalje osnovali primerjavo. Pri izvajalnih okoljih, ki so sestavljala porazdeljeno domeno, nismo opravili nobenih omembe vrednih optimizacij, tako da podani rezultati ne predstavljajo absolutne zmogljivosti posameznih izvajalnih okolij, temveč bolj stanje, kot je»out of the box«.

71 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 61 Testiranje je bilo sestavljeno iz več delov: 1. Najprej smo vzpostavili ter skonfigurirali porazdeljeno domeno in nanjo namestili testno aplikacijo. Domena je bila razdeljena v tri ločena izvajalna okolja, vsako izmed njih pa je bilo zadolţeno za izvajanje vseh komponent iz enega od treh kompozitov, ki so sestavljali testno aplikacijo. Za tem smo zagnali Microsoft Process Monitor ter ga skonfiguirali za spremljanje procesov, ki so sestavljali porazdeljeno domeno. Za tem smo 10 minut spremljali porabo pomnilnika in procesorskega časa. 2. Sledilo je testiranje zakasnitvenih časov, povezanih z uporabo različnih tipov storitev znotraj testne aplikacije. V ta namen smo si pomagali z orodjem Apache JMonitor, s pomočjo katerega smo naredili 1000 klicev izpostavljene spletne storitve, razporejenih na 3-sekundnem intervalu. Testna aplikacija je za vsak tip storitve na datotečni sistem zapisala izmerjene časovne rezultate v mikrosekundah. 3. Pri stresnem testu smo s pomočjo orodja Apache JMonitor 10 minut spremljali obnašanje testne aplikacije pri scenariju, v katerem je 30 odjemalcev nenehno hkrati pošiljajo zahteve. Pri tem nas je zanimalo več rezultatov: koliko je bilo uspešno izvedenih zahtevkov, obremenitev procesorja in poraba pomnilnika. 7 Rezultati testiranja Pridobljene podatki so v nadaljevanju predstavljeni v obliki grafov in ostalih informacij, razporejenih po posameznih izvajalnih okoljih. V primeru predstavitve porabe procesorskega časa je ta predstavljena na osi y v obliki odstotkov, poraba pomnilnika je izraţena v bajtih, v obeh primerih pa so rezultati razporejeni na sekundnem intervalu, predstavljenem na osi x. Zakasnitve, povezane z uporabo različnih tipov storitev, so na grafih predstavljene na osi y, pri čemer je časovni interval mikrosekunda, medtem ko so odzivni časi porazdeljene testne aplikacije kot celote s stališča zunanjega sveta predstavljeni v milisekundah. Os x pa v obeh primerih predstavlja posamezna povpraševanja.

72 Stran 62 Aleksander Ţagar, Diplomsko delo 7.1 Rezultati testiranja izvajalnega okolja Apache Tuscany Za testiranje izvajalnega okolja Apache Tuscany smo uporabili zadnjo izdano verzijo Se pravi, da smo uporabili vejo, ki implementira specifikacije SCA verzije 1.0. Nato smo skonfigurirali distribuirano domeno, ki je tekla znotraj istega operacijskega sistema. Testna domena je bila sestavljena iz treh običajnih vozlišč, na katerih je tekla testna aplikacija (nodes), in upravitelja domene (domain manager), katerega naloga je bila povezava vseh vozlišč, ki so sestavljala domeno v celoto. Konfiguracija je v primeru Tuscany izvajalnega okolja sestavljena iz več datotek XML, skozi katere lahko upravljamo vse aspekte domene. Workspace.xml vsebuje prispevke, domain.composite vsebuje vse kompozite, ki so nameščeni v domeni, cloud.composite pa konfiguracijo posameznih vozlišč domene. Pri namestitvi aplikacije nismo naleteli na kakšne omembe vredne teţave, z izjemo tega, da je bila potrebna manjša dodelava aplikacije. Tuscany namreč trenutno v primeru vezave binding.sca uporablja protokol SOAP ter se pri tem zanaša na Java JAXB za mapiranje razredov v in iz formata XML. Razredi, ki so podvrţeni takšnim operacijam, morajo ustrezati določenim dogovorom, zaradi česar so bile v tem primeru potrebne manjše dodelave. Slika 12: Poleg ročnega urejanja datotek XML Apache Tuscany omogoča tudi nekoliko omejeno konfiguracijo porazdeljene domene skozi grafični uporabniški vmesnik.

73 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 63 Strojna zahtevnost mirovanje Predstavitev strojne zahtevnosti porazdeljene domene SCA izvajalnega okolja Apache Tuscany v primeru mirovanja. Upravitelj domene Graf 1: Poraba procesorskega časa Graf 2: Poraba pomnilnika Vozlišče 1 Graf 3: Poraba procesorskega časa Graf 4: Poraba pomnilnika

74 Stran 64 Aleksander Ţagar, Diplomsko delo Vozlišče 2 Graf 5: Poraba procesorskega časa Graf 6: Poraba pomnilnika Vozlišče 3 Graf 7: Poraba procesorskega časa Graf 8: Poraba pomnilnika

75 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 65 Strojna zahtevnost polna obremenitev Predstavitev strojne zahtevnosti porazdeljene domene SCA izvajalnega okolja Apache Tuscany v primeru polne obremenitve. Upravitelj domene Graf 9: Poraba procesorskega časa Graf 10: Poraba pomnilnika Vozlišče 1 Graf 11: Poraba procesorskega časa Graf 12: Poraba pomnilnika

76 Stran 66 Aleksander Ţagar, Diplomsko delo Vozlišče 2 Graf 13: Poraba procesorskega časa Graf 14: Poraba pomnilnika Vozlišče 3 Graf 15: Poraba procesorskega časa Graf 16: Poraba pomnilnika

77 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 67 Pregled zakasnitev V nadaljevanju sledi pregled zakasnitev, do katerih smo prišli z uporabo posebej razvite testne aplikacije, in sicer v primeru uporabe izvajalnega okolja Apache Tuscany. Graf 17: Klic storitve local iz istega izvajalnega okolja Graf 18: Klic storitve remotable, tako odjemalec kot ponudnik sta v istem izvajalnem okolju Graf 19: Klic storitve remotable, ponudnik in odjemalec sta iz različnih vozlišč Graf 20: Klic storitve callback, ponudnik in odjemalec se izvajata v istem vozlišču

78 Stran 68 Aleksander Ţagar, Diplomsko delo Graf 21: Klic storitve callback, ponudnik in odjemalec storitve sta v različnih vozliščih Graf 22: Proženje storitve composite, ponudnik in odjemalec sta v istem vozlišču Graf 23: Proženje storitve composite, ponudnik in odjemalec sta v ločenih vozliščih Graf 24: Proženje storitve conversational znotraj istega vozlišča

79 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 69 Graf 25: Proženje storitve conversational, ponudnik in porabnik sta iz različnih vozlišč Odzivni čas celotne testne aplikacije zunaj domene Graf 26: Odzivni čas aplikacije kot celote glede na uporabnika izven domene, podan v milisekundah, v 10 minutah uporabe je bilo obdelanih 6372 zahtevkov.

80 Stran 70 Aleksander Ţagar, Diplomsko delo 7.2 Rezultati testiranja izvajalnega okolja frascati V primeru izvajalnega okolja FraSCAti smo morali, če smo ţeleli priti do vsaj pribliţno primerljivih rezultatov, nekoliko bolj konkretno spremeniti testno proceduro in z njo tudi testno aplikacijo. Glavno teţavo je predstavljalo dejstvo, da izvajalno okolje FraSCAti ne omogoča koncepta porazdeljene domene, kot to omogočata Tuscany in Fabric3. Zato smo se zaradi ţelje po porazdeljenem izvajanju testne aplikacije, kjer vsak kompozit teče znotraj svojega izvajalnega okolja ter komunicira z ostalimi, odločili to nekoliko prilagoditi. Tako smo vse tri kompozite testne aplikacije zapakirali v svoj prispevek, pognali tri instance izvajalnega okolja ter namestili vsakega znotraj njemu lastne domene. Na delih, kjer je prihajalo do komunikacije med različnimi izvajalnimi okolji, pa smo se odločili za uporabo eksplicitne vezave tipa RMI, saj se nam je med tistimi, ki smo jih imeli na razpolago, zdela še najbolj optimalna glede na nalogo, za katero smo jo potrebovali. Tako smo vzpostavili podobne okoliščine, pod katerimi je tekla testna aplikacija tudi pri ostalih dveh izvajalnih okoljih, ter s tem pridobili pribliţno primerljive rezultate. Ţal zaradi narave takšne postavitve nismo mogli izvesti testiranja storitve tipa remotable + callback. <service name="service5_4"> <interface.java interface="test.service5_4" /> <frascati:binding.rmi host="localhost" servicename="rmiservice5_4" port="1093"/> </service> Primer 8: Primer eksplicitno izpostavljene storitve java -classpath "C:\frascati-runtime-1.3\conf";"C:\frascati-runtime-1.3\lib\fras cati-runtime-1.3.jar" org.ow2.frascati.launcher org.ow2.frascati.factory.factory CommandLine -lib "C:\frascati-runtime-1.3\lib" composite3 -libpath C:\frascati-ru ntime-1.3\testapp\node3_contribution\node3.jar Primer 9: Primer ukaza, uporabljenega pri zagonu enega izmed ločenih izvajalnih okolij

81 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 71 Strojna zahtevnost - mirovanje Predstavitev strojne zahtevnosti simulirane porazdeljene domene SCA z uporabo frascati izvajalnega okolja v primeru mirovanja. Vozlišče 1 Graf 27: Poraba procesorskega časa Graf 28: Poraba pomnilnika Vozlišče 2 Graf 29: Poraba procesorskega časa Graf 30: Poraba pomnilnika

82 Stran 72 Aleksander Ţagar, Diplomsko delo Vozlišče 3 Graf 31: Poraba procesorskega časa Graf 32: Poraba pomnilnika Strojna zahtevnost polna obremenitev Predstavitev strojne zahtevnosti pri uporabi simulirane porazdeljene domene SCA z uporabo izvajalnega okolja frascati, in sicer pri polni obremenitvi. Vozlišče 1 Graf 33: Poraba procesorskega časa Graf 34: Poraba pomnilnika

83 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 73 Vozlišče 2 Graf 35: Poraba procesorskega časa Graf 36: Poraba pomnilnika Vozlišče 3 Graf 37: Poraba procesorskega časa Graf 38: Poraba pomnilnika

84 Stran 74 Aleksander Ţagar, Diplomsko delo Pregled zakasnitev V nadaljevanju sledi pregled zakasnitev pri uporabi različnih tipov storitev, do katerih smo prišli z uporabo testne aplikacije, ki je tekla v izvajalnem okolju frascati. V vseh primerih so vrednosti podane v mikrosekundah. Graf 39: Klic lokalne storitve Graf 40: Lokalni klic storitve remotable Graf 41: Oddaljeni klic storitve remotable znotraj iste domene Graf 42: Lokalni klic storitve callback

85 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 75 Graf 43: Lokalni klic storitve composite Graf 44: Oddaljeni klic storitve composite Graf 45: Lokalni klic storitve conversational Graf 46: Oddaljeni klic storitve conversational

86 Stran 76 Aleksander Ţagar, Diplomsko delo Odzivni čas celotne testne aplikacije zunaj domene Graf 47: Odzivni čas aplikacije kot celote glede na uporabnika izven domene, podan v milisekundah, v 10 minutah uporabe je bilo obdelanih zahtevkov. 7.3 Rezultati testiranja izvajalnega okolja Fabric3 Za testiranje izvajalnega okolja Fabric3 smo najprej uporabili zadnjo izdano stabilno različico 1.8. Izvajalno okolje Fabric3 omogoča vzpostavitev porazdeljene domene tako, da tokrat nismo bili prisiljeni v»simuliranje«porazdeljene domene. Smo pa morali odstraniti uporabo oddaljene pogovorne storitve, saj jih izvajalno okolje trenutno ne podpira. Presenetljivo smo pri uporabi tega izvajalnega okolja naleteli na nenavadno visoko strojno zahtevnost v primeru, ko gre za vzpostavitev v obliki porazdeljene domene, za katero smo po profiliranju vzpostavili, da je»odgovorna«middleware rešitev ActiveMq, ki se uporablja za komunikacijo med različnimi vozlišči v primeru porazdeljene domene pri uporabi vezave binding.sca. Ta strojna zahtevnost je še posebej prišla do izraza zaradi narave naše testne konfiguracije, kjer je celotna porazdeljena domena domovala znotraj enega sistema, kar se je odraţalo tudi na rezultatih testov.

87 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 77 Med našim postopkom testiranja pa so razvijalci izvajalnega okolja ţe identificirali teţave, na katere smo naleteli, kot hrošč. Odločili smo se za prestop na uporabo verzije 1.8.1, ki sicer še ni bila pripravljena za izdajo ter je bila v stadiju razvoja, vendar pri njeni uporabi nismo naleteli na nobene večje teţave. Domena je tokrat bila sestavljena iz centralnega vozlišča v Fabric3, imenovanega imenovanega controller, in treh vozlišč, na katerih so se dejansko izvajale komponente posameznih kompozitov, imenovanih participants. Vzpostavitev domene je zaradi naprednih funkcionalnosti nekoliko preprostejša kot v primeru izvajalnega okolja Tuscany. Potreben je le manjši poseg v konfiguracijske datoteke izvajalnih okolij, ki bodo sestavljala domeno. Skozi le-te se jim določi vloge in njihova imena, na katera se nato sklicuje pri določanju odgovornosti za izvajanje delov porazdeljene aplikacije. V prispevek je treba nato vključiti le še datoteki plan.xml in sca-contribution.xml, s pomočjo katerih vozlišče controller porazdeli dele aplikacije med različna izvajalna okolja, ki sestavljajo domeno. <?xml version="1.0" encoding="ascii"?> <plan xmlns="urn:fabric3.org" xmlns:t=" name="compositeplan"> <mappings> <mapping deployable="t:composite1" zone="node1"/> <mapping deployable="t:composite2" zone="node2"/> <mapping deployable="t:composite3" zone="node3"/> </mappings> </plan> Primer 10: Vsebina datoteke plan.xml

88 Stran 78 Aleksander Ţagar, Diplomsko delo Strojna zahtevnost mirovanje Predstavitev strojne zahtevnosti porazdeljene domene SCA izvajalnega okolja Fabric3 med mirovanjem. Kontroler Graf 48: Poraba procesorskega časa Graf 49: Poraba pomnilnika Vozlišče 1 Graf 50: Poraba procesorskega časa Graf 51: Poraba pomnilnika

89 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 79 Vozlišče 2 Graf 52: Poraba procesorskega časa Graf 53: Poraba pomnilnika Vozlišče 3 Graf 54: Poraba procesorskega časa Graf 55: Poraba pomnilnika

90 Stran 80 Aleksander Ţagar, Diplomsko delo Strojna zahtevnost polna obremenitev Predstavitev strojne zahtevnosti porazdeljene domene SCA izvajalnega okolja Fabric3 ob polni obremenitvi. Kontroler Graf 56: Poraba procesorskega časa Graf 57: Poraba pomnilnika Vozlišče 1 Graf 58: Poraba procesorskega časa Graf 59: Poraba pomnilnika

91 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 81 Vozlišče 2 Graf 60: Poraba procesorskega časa v % Graf 61: Poraba pomnilnika v bajtih Vozlišče 3 Graf 62: Poraba procesorskega časa v % Graf 63: Poraba pomnilnika v bajtih

92 Stran 82 Aleksander Ţagar, Diplomsko delo Pregled zakasnitev V nadaljevanju sledi predstavitev zakasnitev, do katerih smo prišli z uporabo testne aplikacije pri uporabi različnih tipov storitev. V vseh primerih so vrednosti podane v mikrosekundah. Graf 64: Proženje lokalne storitve Graf 65: Lokalni klic storitve remotable Graf 66: Oddaljeni klic storitve remotable Graf 67: Lokalni klic storitve callback

93 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 83 Graf 68: Oddaljeni klic storitve callback Graf 69: Lokalni klic storitve composite Graf 70: Oddaljeni klic storitve composite Graf 71: Lokalni klic storitve conversational

94 Stran 84 Aleksander Ţagar, Diplomsko delo Odzivni čas celotne testne aplikacije zunaj domene Graf 72: Odzivni čas aplikacije kot celote glede na uporabnika izven domene, podan v milisekundah, v 10 minutah uporabe, pri čemer je aplikacija postregla 3973 zahtevam.

95 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Analiza testiranja Predstavljeni rezultati nam ponujajo zelo zanimiv vpogled v zmogljivosti posameznih testiranih izvajalnih okolij. Če najprej začnemo s strojno zahtevnostjo tako v stanju mirovanja kot polne obremenitve, se kot celota najbolje odreţe frascati. To je bilo pričakovano, saj v primerjavi z ostalima ponuja precej manj funkcionalnosti izven okvira specifikacij SCA. Poleg tega smo zaradi tega, ker ne nudi moţnosti vzpostavitve porazdeljene domene, bili prisiljeni nekoliko prirediti testno aplikacijo, zaradi česar se je efektivno izvajala znotraj treh ločenih domen SCA, katerih komponente so bile eksplicitno povezane skozi povezavo RMI, s čimer smo precej popreprostili delo izvajalnemu okolju. Nekoliko slabše od tega pa sta se nato odrezala Apache Tuscany in Fabric3, pri čemer je treba omeniti, da smo bili primorani v primeru izvajalnega okolja Fabric3 uporabiti verzijo 1.8.1, ki je bila v času testiranja še v aktivnem razvoju. UPRAVLJAVEC DOMENE VOZLIŠČE 1 VOZLIŠČE 2 VOZLIŠČE 3 TUSCANY 0, , FRASCATI n/a 0, , , FABRIC3 0, , , , Tabela 1: Povprečna poraba procesorskega časa v % ob stanju mirovanja UPRAVLJAVEC DOMENE VOZLIŠČE 1 VOZLIŠČE 2 VOZLIŠČE 3 TUSCANY FRASCATI n/a FABRIC , , Tabela 2: Povprečna poraba pomnilnika v bajtih ob stanju mirovanja

96 Stran 86 Aleksander Ţagar, Diplomsko delo UPRAVLJAVEC DOMENE VOZLIŠČE 1 VOZLIŠČE 2 VOZLIŠČE 3 TUSCANY 0, , , ,63258 FRASCATI n/a 10, , , FABRIC3 0, , , ,80402 Tabela 3: Povprečna poraba procesorskega časa v % ob polni obremenitvi UPRAVLJAVEC DOMENE VOZLIŠČE 1 VOZLIŠČE 2 VOZLIŠČE 3 TUSCANY FRASCATI n/a FABRIC , , ,4 Tabela 4: Povprečna poraba pomnilnika v bajtih ob polni obremenitvi Rezultati testiranja zakasnitev so spet v okviru pričakovanj. Sicer tokrat ni prišlo do stanja, pri katerem bi katero izmed izvajalnih okolij posebej dominiralo pri vseh izvedenih testih, vendar pa kljub temu lahko opazimo določene vzorce. Če se osredotočimo na oddaljene klice vseskozi dominira izvajalno okolje frascati, kar lahko spet pripišemo načinu, na katerega smo vzpostavili porazdeljeno domeno. Tako se je izmed vseh različnih tehnoloških rešitev, ki jih uporabljajo izvajalna okolja za vzpostavitev porazdeljene domene, kot najbolj zmogljiva izkazala kombinacija RMI + JRMP, saj je imela v primerjavi s kombinacijo JAXB + SOAP izvajalnega okolja Tuscany in vmesno rešitvijo JMS ActiveMQ izvajalnega okolja Fabric3 najmanj reţijskih stroškov in najbolj optimalen komunikacijski protokol. Nadalje je zanimiv še rezultat, ki smo ga dobili pri uporabi oddaljenega in lokalnega klica storitve tipa callback, kjer je tokrat vseskozi bil pri vrhu z očitno prednostjo Fabric3, kar očitno kaţe na to, da so izgotovili najbolj optimalno implementacijo takšnega tipa storitve. Kar se ostalih storitev tiče, so rezultati precej medsebojno poravnani, tako da je teţko govoriti o kakšnih izjemnih prednostih oziroma slabostih.

97 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 87 TUSCANY FRASCATI FABRIC3 Oddaljeni klic storitve remotable 5668, , ,06 Standardni odklon Min Max. Lokalni klic storitve remotable 613, , ,013 Standardni odklon Min Max. Proženje lokalne storitve 382, , ,472 Standardni odklon Min Max. Lokalni klic storitve callback 14197, , ,297 Standardni odklon Min Max. Oddaljeni klic storitve callback 13695,1 n/a 50868,41 Standardni odklon n/a 5668 Min.

98 Stran 88 Aleksander Ţagar, Diplomsko delo n/a Max. Lokalni klic storitve composite 311, , ,8819 Standardni odklon Min Max. Oddaljeni klic storitve composite 3852, , ,56 Standardni odklon Min Max. Lokalni klic storitve conversational 913, , ,146 Standardni odklon Min Max. Oddaljeni klic storitve conversational 8742, , n/a Standardni odklon n/a Min n/a Max. Tabela 5: Tabelarična predstavitev zbranih rezultatov o zakasnitvah pri uporabi posameznih tipov storitev, vrednosti so podane v µs.

99 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 89 Na koncu smo testirali še obnašanje izvajalnih okolij s stališča zunanje aplikacije, pri čemer je 30 uporabnikov hkrati 10 minut pošiljalo poizvedbe. Zanimalo nas je, koliko zahtevkov je bilo uspešno izvedenih skupaj z njihovimi odzivnimi časi. Tudi pri tem testu je prednjačil frascati, k čemer je zagotovo spet pripomogla majhna strojna zahtevnost in dejstvo, da ni tekel v»pravi«porazdeljeni domeni. Sledil mu je Apache Tuscany, najslabši rezultat pa smo dosegli pri uporabi izvajalnega okolja Fabric3. Graf 73: Primerjava števila opravljenih zahtevkov ob polni obremenitvi na 10-minutnem intervalu Fabric3 izvajalno okolje sicer namerava v naslednji verziji preiti iz rešitve ActiveMQ za tip binding.sca na ZeroMQ, s čimer se razvijalci nadejajo veliko boljših zmogljivosti. Tako bi bilo zanimivo ob prihodu naslednje stabilne verzije izvajalnega okolja Fabric3 test ponoviti ter primerjati dobljene rezultate.

100 Stran 90 Aleksander Ţagar, Diplomsko delo Fabric Apache Tuscany FraSCAti 1.3 Implementira specifikacije Podpora porazdeljeni domeni DA DA NE Storitve brez stanja DA DA DA Kompozitne storitve Storitve povratnim klicem s DA DA DA DA DA DELNO Pogovorne storitve DELNO DA DA Enosmerne storitve DA DA DA Tabela 6: Primerjava funkcionalnosti testiranih izvajalnih okolij 8 Sklep Kot smo lahko spoznali, je tehnologija SCA v zadnjih letih naredila nekaj ogromnih korakov, tako da je danes primerna za uporabo v praktično vseh okoljih, ko gre za ţeljo po izgradnji aplikacij, ki sledijo principom SOA. Delo na specifikacijah je še vedno precej aktivno, tako da se je morda bolje izogniti določenim osnovnim konceptom, ki še niso povsem dorečeni, kot na primer pogovornim storitvam, saj je njihova prihodnost trenutno negotova. V primerih, ko se pojavi potreba po takšnih funkcionalnosti, se je tako trenutno bolje ozreti po rešitvah vmesnega sloja ter jih vkomponirati v aplikacijo, kar je zaradi razširljivosti tehnologije SCA vsekakor mogoče. Prav razširljivost je gotovo tudi eden izmed razlogov, čemu je vredno poseči po tehnologiji SCA, saj je fleksibilnost eden izmed temeljnih principov, na katerih je grajena.

101 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 91 Kar se tiče odprtokodnih implementacij, so le-te rasle skupaj s tehnologijo SCA. Če je v njenih začetkih bila izbira omejena le na izvajalno okolje Tuscany, smo skozi leta pridobili raznoliko mnoţico rešitev. Ţe v primeru izvajalnega okolja Tuscany je to danes dosegljivo v treh različnih oblikah, katere eni smo se v tem delu podrobneje posvetili. Poleg tega pa sta na voljo še Fabric3 ter FraSCAti, ki sta se, kljub temu da gre za nekoliko mlajši implementaciji, izkazali kot povsem enakovredni alternativi izvajalnemu okolju Apache Tuscany. Med testiranjem različnih izvajalnih okolij smo prišli do zanimivih rezultatov, nobeno izmed njih pa ni posebej dominiralo v vseh preizkušenih testih. Po končanem testiranju in analizi našega pristopa smo našli tudi precej moţnosti za izboljšave. Tako bi bilo bolje, če bi vzpostavili večje število fizično ločenih sistemov, na katerih bi tekla izvajalna okolja. Tako bi bil naš test bolj ţivljenjski in s tem bolj relevanten. Poleg tega bi vsekakor potrebovali nekoliko močnejšo strojno opremo, saj smo pri testiranju izvajalnih okolij velikokrat predvsem omejeni s to in nismo mogli razviti potenciala, ki ga je nudila tehnologija. Prav tako bi najverjetneje lahko prišli do boljših rezultatov, če bi se podrobneje spoznali z celotnimi rešitvami, ki sestavljajo takšna izvajalna okolja, in to znanje nato vključili pri postavitvah domen. Pri izvedbi testa smo bili omejeni z opremo, ki smo jo imeli na razpolago, poleg tega pa smo zaradi narave odprtokodnih sistemov naleteli še na, v večini primerov, pomanjkljivo dokumentacijo. Glede na preizkušeno lahko napovemo tehnologiji SCA svetlo prihodnost, saj zaradi svoje odprtosti in raznolikosti različnih izvajalnih okolji, ki pride s tem, vsekakor postaja iz dneva v dan bolj privlačna opcija pri razvoju različnih programskih rešitev.

102 Stran 92 Aleksander Ţagar, Diplomsko delo 9 Viri 1. Service component architecture (zadnjič obiskano ) 2. Jim Marino, Michael Rowley, Understanding SCA, David Chappell, Introducing SCA, SCA Specification Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Service-oriented architecture (zadnjič obiskano ) 7. OASIS Reference Model for Service Oriented Architecture 1.0, Fabric3 documentation (zadnjič obiskano ) 9. Apache Tuscany documentation (zadnjič obiskano ) frascati documentation (zadnjič obiskano ) 11. Peter Eeles, What is a software architecture?, (zadnjič obiskano ) 12. Reference model, (zadnjič obiskano ) 13. Simon Laws, Mark Combellack, Raymond Feng, Haleh Mahbod, Simon Nash, Tuscany SCA in Action, Service Component Architecture (zadnjič obiskano )

103 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Software architecture (zadnjič obiskano ) Software Architecture and Design (zadnjič obiskano ) Service Component Architecture Home (zadnjič obiskano ) 18. Jean-Sebastien Delfino, Open Source SOA with Service Component Architecture and Apache Tuscany, Service Component Architecture (SCA) Tutorial: Part 1, SCA Tools (zadnjič obiskano ) Tuscany SCA Java (zadnjič obiskano ) 22. Jean-Sebastien Delfino, Open Source SCA - The Apache Tuscany Project, Open Source SOA with Service Component Architecture and Apache Tuscany (zadnjič obiskano ) 24. Apache Tuscany SCA Release Notes, April Apache Tuscany SCA 2.0-Beta2 Release Notes, January Apache Tuscany SCA Runtime (zadnjič obiskano ) Tuscany native M3 (zadnjič obiskano ) 28. Jim Marino, Fabric3 intro, Fabric3 Documentation (zadnič obiskano ) 30. Lionel Seinturier, FraSCAti «Open SCA Platform», P. Merle, Lionel Seinturier, FraSCAti: An Open SCA Platform, Stéphane Drapeau, SCA Tools (Helios) Release Review, Obeo, SCA Tools project Creation Review, 2008

104 Stran 94 Aleksander Ţagar, Diplomsko delo Rates,_ Recession Causes Rising IT Project Failure Rates (zadnjič obiskano ) 10 Priloge 10.1 Naslov študenta Aleksander Ţagar Podjavorškova ulica , Celje 10.2 Seznam slik Slika 1: Ponazorjene odvisnosti od referenčnega modela do končne implementacije[7].. 5 Slika 2: Grafična predstavitev razmerij predstavljenih konceptov[7] Slika 3: Grafična predstavitev razmerij predstavljenih konceptov[7] Slika 4: Abstrakten primer aplikacije SCA[3] Slika 5: Grafična predstavitev komponente z njenimi referencami, storitvami in lastnostmi[19] Slika 6: Primer kompozita z dvema komponentama Slika 7: Vizualizacija skupka predstavljenih konceptov in njihovih medsebojnih povezav[19] Slika 8: Grafični oblikovalnik kompozitov SCA[20] Slika 9: Urejevalnik datotek SCDL[20] Slika 10: Grafični prikaz delne strukture testne aplikacije Slika 11: Posnetek zaslona orodja Apache JMonitor Slika 12: Poleg ročnega urejanja datotek XML Apache Tuscany omogoča tudi nekoliko omejeno konfiguracijo porazdeljene domene skozi grafični uporabniški vmesnik

105 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran Seznam primerov Primer 1: Primer oddaljenega vmesnika v Javi Primer 2: Primer enakega vmesnika v C Primer 3: Definicija Component type za zgornji primer, katerega eksplicitna definicija ni potreba, saj lahko izvajalno okolje pridobi potrebne informacije iz anotacij Primer 4: Primer dejanske datoteke SCDL, ki definira zgornji primer kompozita Primer 5: Deklariranje storitve komponente skupaj z eksplicitno izraţeno vezavo znotraj datoteke SCDL kompozita composite Primer 6: Implementacija razreda storitve service2, ki jo izpostavlja komponenta hub_component Primer 7: Deklaracija predstavljene komponente Primer 8: Primer eksplicitno izpostavljene storitve Primer 9: Primer ukaza, uporabljenega pri zagonu enega izmed ločenih izvajalnih okolij 70 Primer 10: Vsebina datoteke plan.xml Seznam preglednic Tabela 1: Povprečna poraba procesorskega časa v % ob stanju mirovanja Tabela 2: Povprečna poraba pomnilnika v bajtih ob stanju mirovanja Tabela 3: Povprečna poraba procesorskega časa v % ob polni obremenitvi Tabela 4: Povprečna poraba pomnilnika v bajtih ob polni obremenitvi Tabela 5: Tabelarična predstavitev zbranih rezultatov o zakasnitvah pri uporabi posameznih tipov storitev, vrednosti so podane v µs Tabela 6: Primerjava funkcionalnosti testiranih izvajalnih okolij... 90

106 Stran 96 Aleksander Ţagar, Diplomsko delo

107 Primerjava odprtokodnih implementacij storitvene komponentne arhitekture Stran 97

108 Stran 98 Aleksander Ţagar, Diplomsko delo