PERZISTENCIJA UML OBJEKTNOG PROSTORA U RELACIONIM
BAZAMA PODATAKA ZA VIESLOJNE WEB ARHITEKTURE
UML OBJECT SPACE PERSISTENCE IN RELATIONAL DATABASES FOR
MULTI-LAYER WEB ARCHITECTURES
Nemanja Koji, Dragan Miliev
Elektrotehniki fakultet u Beogradu
Sadraj: Istraivanje opisano u ovom radu se svrstava u
oblast modelom voen razvoj (engl. Model Driven
Development, MDD) objektno orijentisanih informacionih
sistema sa vieslojnim arhitekturama, baziran na
izvrivim UML modelima. Razvoj objektno orijentisanih
sistema na osnovu izvrivih modela je inovativni pristup
efikasnijem razvoju ove vrste softvera. Sistemi dobijeni
navedenim pristupkom manipuliu neposredno objektima
iz UML objektnog prostora ( perzistentnim objektima sa
UML semantikom). Pomenuti objekti, iz praktinih
razloga, perzistiraju u relacionoj bazi podataka, pa je
potrebno razviti efikasan mehanizam za premoavanje
jaza izmeu objektno orijentisane i relacione paradigme.
U ovom radu su izloeni, eksperimentalno potvreni i
analizirani osnovni principi i mehanizmi perzistencije
UML objektnog prostora u relacionim bazama podataka
u kontekstu vieslojnih i skalabilnih veb arhitektura.1
Abstract: This research belongs to the area of Model
Driven Development of multi-layer object-oriented
information systems, based on executable UML models.
Development of the object-oriented information systems
based on executable UML models is an innovative
approach for more efficient development of this kind of
software. The given systems manipulate with objects in
UML object space (the persistent objects with UML
semantics). From the practical reasons, the objects
persist in relational database, and it is necessary to
overcome the gap between object-oriented and relational
paradigm. The main principles and mechanisms for
persistence of UML object space in relational databases,
in the context of multi-layer web architectures, are
defined, described and analyzed in this paper.
1. UVOD
Objektno orijentisani informacioni sistemi, dobijeni na
osnovu izvrivih UML modela manipuliu neposredno
objektima sa UML semantikom. Da bi UML modeli bili
izvrivi neophodno je profilisati sam UML, to znai da
element/koncepti UML-a, koji su od znaaja za
modelovanje informacionih sistema, moraju imati
nedvosmislenu semantiku, i na taj nain mogu da postanu
izvrivi. Za potrebe modelovanja objektno orijentisanih
informacionih sistema, definisan je OOIS UML profil,
detaljno opisan u [1].
Ovaj rad je delimino finansiran od strane Ministarstva prosvete
i nauke Republike Srbije (projekat broj TR32047). Autori
zahvaljuju na finansijskoj podrci.
OOIS UML (www.ooisuml.org) je izvrivi profil UML-a
za brz i efikasan razvoj objektno orijentisanih
informacionih sistema baziran na izvrivim UML
modelima. On se temelji na formalnom i izvrivom
podskupu elemenata UML-a koji omoguava znatno
efikasniji razvoj ove vrste sistema u poreenju sa trenutno
popularnim i iroko korienim tehnologijama. Aplikacije
dobijene na osnovu OOIS UML modela se karakteriu
sledeim detaljima:
a) Korisnik manipulie objektima koji predstavljaju fizike ili konceptualne stvari iz domena
problema.
b) Objekti se nalaze (ive) u potencijalno velikom, inherentno perzistentnom objektnom
prostoru, kojim sistem manipulie.
c) Objekti sadre vrednosti svojih atributa koji su specificirani u modelu.
d) Strukturne veze izmeu objekata se mogu uspostavljati i uklanjati u toku rada aplikacije.
e) Objekti mogu da ispolje ponaanje, koje se moe aktivirati izvan sistema.
Za opisane objekte se jo kae da su to objekti sa OOIS
UML semantikom. OOIS UML, kao metod za modelom
voem razvoj objektno orijentisanih informacionih
sistema, se sastoji od sledeih elemenata: jezika za
modelovanje, biblioteke za modelovanje, izvrnog
okruenja i procesa razvoja.
Na osnovu OOIS UML specifikacije razvijen je radni
okvir, pod nazivom SOLoist (www.soloist4uml.com).
SOLoist omoguava brz razvoj prototipova kao i samih
informacionih sistema, a u isto vreme predstavlja i
izvrno okruenje za ovako dobijene informacione
sisteme. Pogodan je za izgradnju sistema koji se odlikuju
bogatim i obimnim konceptualnim modelom i masovnim
instanciranjem objekata, interaktivnou i inherentnom
perzistencijom objektnog prostora.
Perzistencija OOIS UML objektnog prostora je tema ovog
rada i u narednim poglavljima e ukratko biti definisan
problem, opisano i analizirano reenje koje je ugraeno u
jezgro SOLoist okruenja.
Arhitektura SOLoist-a je prikazana UML modelom na
slici Slika 1. Jezgro SOLoist-a, koje izmeu ostalog,
612
manipulie objektnim prostorom, predstavljeno je
paketom UML.
Sam rad je podeljen na sedam celina: Uvod, Definicija
problema, Pregled postojeih reenja, Opis reenja,
Eksprimentalna potvrda reenje, Preliminaran analiza
reenja i Zakljuak.
Slika 1: Pregled arhitekture SOLoist radnog okvira.
2. DEFINICIJA PROBLEMA
SOLoist je, u skladu sa trendovima koji trenutno vladaju
u informatikom svetu, projektovan i pravljen za razvoj
veb baziranih objektno orijentisanih informacionih
sistema. Veb bazirani sistemi po pravilu moraju da budu
veoma skalabilni u odnosu na optreenje za koje su
predvieni. Tematika ovog rada jeste prouavanje
konkurentnog rada nad OOIS UML objektnim prostorom
i iznalaenje reenja za njegovo unapreenje.
U standardnoj konfiguraciji SOLoist-a, za perzistenciju
OOIS UML objektnog prostora koristi se relaciona baza
podataka. Objekti, vrednosti njihovih atributa i linkovi su
zapisani u vidu relacionih podataka u tabelama. Iako nisu
ba prirodno okruenje za perzistenciju objektnog
prostora, relacione baze podataka su danas nezamenljive
kada je u pitanju perzistencija podataka informacionih
sistema uopte. Imajui u vidu da one nude pouzdane
mehanizme za manipulisanje podacima i da su iroko
prihvaene i koriene, bezuslovno su se nametnule kao
reenje za produkciju. Meutim, SOLoist kroz svoj API
omoguava manipulianje podacima iskljuivo kroz
objekte koji se odlikuju svim karakteristikama objektno
orijentisane paradigme. Da bi se to omoguilo potrebno je
podatke iz relacione baze mapirati u njihove objektno
orijentisane reprezentacije i obratno, objekte i njihove
vrednosti atributa i linkove mapirati u relacionu bazu
podataka. Tu se dolazi do potrebe za postojanjem sloja
softvera koji treba da radi opisani posao objektno-
relacionog mapiranja.
U osnovi, sloj za perzistenciju treba da obezbedi
preslikavanje (mapiranje) objektnog prostora u relacioni
prostor. Sa druge strane, da bi se vreme odziva OOIS
UML akcija koje manipuliu podacima iz objektnog
prostora uinilo razumnim i znaajno smanjio obim
komunikacije sa relacionom bazom, potrebno je osmisliti
i realizovati vieslojnu i proizvoljno skalabilnu
arhitekturu softverskih keeva objektnog prostora, to je i
osnovni cilj ovog rada. Osnovna namena keeva je da
uvaju podatke kojima je u toku izvravanja nekakve
obrade pristupano, jer je po principu temporalne
lokalnosti veoma verovatno da e im biti pristupano
ponovo u bliskom trenutku.
Osnovni ciljevi ovog rada jesu:
f) realizovati objektno-relaciono mapiranje SOLoist objektnog prostora,
g) realizovati keiranje tako da se, redukovanjem komunikacije sa bazom podataka i forsiranjem
grupne (batch) obrade, vreme odziva prilikom
manipulisanja SOLoist objektnim prostorom
pobolja (smanji) i tako povea propusnu mo
sistema kao celine.
3. POSTOJEA REENJA
Od svih poznatih reenja za objektno-relaciono mapiranje,
razmatrana su samo ona koja se veu sa najpopularnije
objektno orijentisane programske jezike (C#, Java). Od
okruenja za objektno-relaciono mapiranje za Java
platformu, meu najvie korienim je Hibernate
(https://www.hibernate.org), Java biblioteka za objektno-
relaciono mapiranje. Od okruenja za objektno-relaciono
mapiranje namenjenih za .NET platformu, najire
koriena i meu najpopularnijim su ADO .NET, LINQ,
NHibernate. U ovom radu, od posebnog interesa je
Hibernate, jer je posluio i kao predmet uporedne analize
sa predloenim reenjem.
Hibernate ini direktan pristup bazi (skoro)
transaprentnim za programere i aplikaciju i omoguava:
(1) Manipulisanje objektima umesto tabelama i kolonama
u bazi podataka; (2) Mapiranje Java klasa u tabele
relacione baze i Java tipova podataka u SQL tipove
podataka; (3) Jednostavno itanje podataka iz relacione
baze kroz specijalizovane upite; (4) Preuzima
odgovornost na sebe da generie SQL upite i na taj nain
oslobaa programera manipulisanja JDBC konceptima
niskog nivoa kao to su konekctije, rezultati, konverzija iz
Object itd; (5) Prua mogunost izdavanja upita nad java
objektima korienjem jezika Hibernate Query Language
(HQL). Uz Hibernate, aplikacija postaje prenosiva na sve
podrane SQL baze podataka. Ta fleksibilnost ipak nije
bitno ugrozila performanse Hibernate-a.
Pored objektno-relacionog mapiranja, Hibernate obavlja i
funkciju keiranja i dohvatanja podataka unapred
(prefetching). Kada je keiranje u pitanju, Hibernate
poseduje dva nivoa keeva: (1) prvi nivo keeva (first
level cache) keira samo one podatke kojima se pristupa
UML
BuiltInDomains
GUIConfiguration
GUIRuntime
GWTGUIServer
613
u toku jedne sesije rada za bazom podataka i (2) drugi
nivo keeva (second level cache), deljeni ke sa za
razliite transakcije na niovu cele aplikacije.
Hibernate je besplatan softver otvorenog koda. Distribuira
se pod GNU LGPL licencom. Trenutna verzija Hibernate-
a je verzija 4.
Budui da Hibernate i sloj perzistencije SOLoist-a dele
dosta problema, ideja i koncepata, on e biti glavni
konkurent prilikom poreenja rada predloenog reenja za
perzistenciju OOIS UML objektnog prostora sa
postojeim reenjima.
4. OPIS REENJA
Sloj za perzistenciju OOIS UML objektnog prostora
prua objektno-relaciono mapiranje i keiranje objekata.
Sloj SOLoist keeva u sistemu ima viestruku ulogu. U
osnovi sadre podskup instanci objektnog prostora
(kojima je skorije pristupano) u brzoj memoriji znatno
manjeg kapaciteta. Sa druge strane, keevi omoguavaju
konkurentni rad nad deljenim objektnim prostorom uz
podran mehanizam transakcione obrade koji je osmiljen
tako da obezbedi to veu konkurentnost i oporavak od
otkaza.
Logiki gledano, keiranje objektnog prostora i objektno-
relaciono mapiranje su dve potpuno razliite
odgovornosti. Razdvajanje ovih odgovornosti u posebne
logike slojeve omoguava njihovu nezavisnu
implementaciju, odnosno mogunost nezavisnog variranja
razliitih pristupa keiranju i mapiranju, uz proizvoljno
kombinovanje tih pristupa (Slika 2).
Application Layer (domain objects)
Database
Object-Relational mapping
Caching
Slika 2: Arhitektura slojeva perzistencije OOIS UML
objektnog prostora. Eksplicitno razdvajanje odgovornosti
keiranja i objektno relacionog mapiranja u dva sloja
softvera (Caching i Object-Relational mapping).
Zbog potpunog izmetanja odgovornosti keiranja
objektne strukture u poseban sloj, sloj za objektno-
relaciono mapiranje ne mora da sadri nikakvu strukturu,
tj. ne uva nikakvo stanje i jedina uloga mu je da
transformie UML akcije u akcije nad bazom podataka.
Kao takav (bez ikakve interne strukture), objektno-
relacioni maper ne zahteva nikavu sinhronizaciju pristupa
za konkurentne niti.
Sa druge strane, zadatak kea je sada da uva podatke
kojima je u toku izvravanja aplikacije skorije pristupano,
za sluaj da se ponovo pojavi potreba za njihovim
itanjem. U ovom sluaju bi se itanje podatka, koji se
nalazi u keu, kompletiralo bez pristupa bazi podataka.
Pored itanja potrebno je reiti krupniji problem, a to je
transakciona obrada u konkurentnom okruenju nad
deljenim objektnim prostorom, prilikom obrade koja
menja njegovo stanje.
Mehanizam transakcione obrade nad OOIS UML
objektnim prostorom karakterie sledee: (1) atominost,
(2) konzistentnost, (3) izolacija, (4) postojanost.
Konzistentnost podrazumeva zadovoljenje svih
ogranienja iz modela za dato stanje UML objektne
strukture. Izolacija podrazumeva da se transakcije
konkurentno izvravaju nad deljenim UML objektnim
prostorom. Postojanje drugih transakcija za svaku
transakciju je transparentno. Svaka transakcija se pie i
izvrava kao da je jedina u sistemu. Meutim, u
konkurentnom radu evidentno moe doi do njihovog
meusobnog sukobljavanja (kolizija). Kolizija nastaje
kada vie transakcija istovremeno pokua da izmeni isti
podatak ili deo objektnog prostora.
Za spreavanje kolizija, koje uvek uslovljavaju prekid
izvravanja transakcija (otkaz), i izlolaciju transakcija
keevi koriste pristup optimistikog zakljuavanja.
Princip optimistikog zakljuavanja se zasniva na
pretpostavci da su kolizije retke, tako da ne koristi
eksplicitno zakljuavanje podataka. Transakcija na
poetku sauva snimi stanje elementa objektnog prostora
kojem pristupa. Kada se transakcija potvruje (commit),
stanje svih elemenata objektnog prostora kojima je
pristupano, treba da bude isto kao to je bilo proitano na
poetku njenog izvravanja da bi se transakcija
kompletirala. Ukoliko taj uslov ne vai, detektuje se
kolizija i radi se oporavak od otkaza (rollback). Za stanje
objekata u keu, koje se ita pri prvom pristupu u
transakciji i proverava prilikom njenog potvrivanja,
koriste se verzije.
Object2RelationalMapper
UML Actions
Database
Shared Cache
ThreadCache ThreadCache. . .
. . .OOIS UML Threads
Slika 3: Sloj za keiranje ine dva tipa keeva: keevi niti
(Thread cache) i ke za deljenu strukturu (Shared Cache).
Pored koncepta optimistikog zakljuavanja,
implementacija transakcione obrada nad deljenim
objektnim prostorom bila je inspirisana jo jednom ve
dobro poznatom tehnikom pod nazivom shadow page,
614
koja je esto primenjena u sistemima za upravljanje
relacionim bazama podataka, ba za reavanje problema
upravljanja transakcijama nad deljenim podacima.
Osnovna ideja ove tehnike je da se izmene tokom
izvravanja transakcije rade nad kopijom podskupa
podataka iz deljenog prostora. Ukoliko se transakcija
uspeno potvrdi, podaci u kopiji (shadow page) postaju
deo deljenog prostora podataka.
Za reavanje transakcione obrade u sloju SOLoist kea,
primenjena je slina ideja. Direktna obrada se ne radi nad
deljenom strukturom u keu, ve iskljuivo nad njenom
kopijom. Odgovornost za primenu ove tehnike dodeljena
je sloju kea koji je oznaen imenom Thread Cache (ke
niti). Kako objektnom prostoru pristupaju niti (threads)
izvravajui transakcije, zamiljeno je da se svakoj niti
pridrui jedna instanca ovog tipa kea. Sa druge strane,
odgovornost za keiranje zajednike (deljene) strukture
objekata je dodeljena sloju koji se naziva Shared Cache
(Slika 3).
Sa slike se moe uoiti da se keevi tipa Thread Cache
nalaze u hijerarhijskom poretku iznad Shared Cache-a i da
komuniciraju iskljuivo sa njim. Niti izvravaju akcije u
okviru transakcija iskljuivo nad sadrajem svog
pridruenog kea (Thread Cache), a ne direktno nad
strukturom deljenog kea (Shared Cache). Ukoliko se desi
da u toku izvravanja transakcije neke informacije
nedostaju u Thread Cache-u, potrebni podaci se uitavaju
iz Shared Cache-a. Ako traenih podataka nema ni u
Shared Cache-u, onda se podaci uitaju u Shared Cache iz
baze podataka (kroz sloj za objektno-relaciono
mapiranje).
Slika 4: Model arhitekture SOLoist keeva. Keevi su
smeteni u prostoru izmeu tankog sloja OOIS UML akcija i
relacione baze podataka, u kojoj SOLoist objektni prostor
fiziki egzistira.
Shared Cache ima jo jednu dodatnu dimenziju, a to je da
se moe proizvoljno mnogo multiplicirati po vertikali. Na
dnu vertikale naslaganih deljenih keeva, uvek treba da se
nalazi baza podataka kojoj se pristupa posredstvom
modula Object2RelationalMapper. Ovakvom postavkom
stvari, deljeni ke (Shared Cache) moe ispod sebe da ima
ili drugi Shared Cache ili Object2RelationalMapper. Da bi
se to omoguilo neophodno je da deljeni ke i
Object2RelationalMapper imaju isti interfejs, jer
konceptualno rade iste akcije. Izjednaavanjem iterfejsa
Shared Cache-a i Object2RelationalMapper-a, proizveden
je jo jedan interesantan efekat. Budui da je interfejs
komponente Object2RelationalMapper osmiljen tako da
bude identian sa interfejsom Shared Cache, to je otvorilo
i mogunost za direktnom komunikacijom izmeu Thread
Cache-a i Object2RelationalMapper-a. Ovo je sloj keeva
uinilo jako fleksibilnim za konfigurisanje i slaganje na
proizvoljno mnogo naina, prilagoavajui tako sistem za
razliite sluajeve korienja u cilju ostvarenja to boljeg
vremena odziva (Slika 4).
Prilikom dohvatanja podataka iz kea nieg nivoa
primenjuju se razliite tehnike kojima moe ili da se
optimizuje zauzee prostora za podatke ili moe da se
optimizuje vreme izvravanje trenutne i narednih akcija.
U ke se mogu dovui ba podaci koji su zahtevani i nita
vie od toga. To daje mogunost pune kontrole sadraja
strukture podataka u keu. Meutim, pored nje, za praksu
i za performanse sistema su mnogo znaajnije politike
uitavanja koje pored traenih podataka dovlae
predikcijom i podatke za koje postoji velika verovatnoa
da e zatrebati u radu rada aplikacije/transakcije.
Uitavanje podataka na osnovu predikcije pristupa
podacima od strane aplikacije se naziva dohvatanje
unapred (prefetching).
5. EKSPERIMENTALNA POTVRDA REENJA
Opisano reenje nalo je svoju primenu u jednom velikom
i uspenom industrijskom projektu, tipinom za razvoj
korienjem SOLoist tehnologije. Kako bi se stekao prvi
utisak o njegovoj veliini (a samim tim se moe rei i
kompleksnosti), ilustrovane su osnovne karakteristike
konceptualnog modela sistema koji je rezultat datog
projekta (Tabela 1).
Metrike modela SOLoist GUI konfiguracije
Broj klasa ~100 Broj asocijacija ~50
Metrike modela domena problema
Broj klasa ~160 Broj asocijacija ~180
Ukupno
klasa ~260
Ukupno
asocijacija ~230
Metrike generisane baze podataka
Broj
tabela ~560
Broj instanci klasa domena
u bazi nakon inicijalizacije ~12200
Tabela 1: Metrike modela sistema u koji su ugraeni keevi.
Imajui u vidu navedene metrike modela i samog sistema,
merena su vremena uitavanja grafikog interfejsa
615
aplikacije (sa i bez keeva). Odabrana je ba aktivnost
uitavanja, a ne neka druga, zbog toga to sama po sebi
ima notu masivnosti (uitava se veliki broj objekata koju
su vezani na razne naine), a sa druge strane ona treba da
bude to efikasnija kako bi sam proces uitavanja
aplikacije, kao prvi kontakt korisnika sa sistemom, bio
veoma dobar. Uitavanje GUI-a aplikacije podrazumeva
uitavanje celog stabla komponenata GUI-a kao
povezanog grafa objekata, prolazak kroz to stablo i
kreiranje struktura podataka koje sadre informacije o
tome kako treba iscrtavati kontrole grafikog interfejsa.
Tabela 2 prikazuje rezultate merenja.
Aktivnost Trajanje (sec)
Uitavanje aplikacije bez keeva ~550
Uitavanje aplikacije sa keevima
(inicijalno) ~100
Uitavanje aplikacije sa keevima
(nakon inicijalnog) ~30
Tabela 2: Rezultati merenja uitavanja aplikacije razvijene
SOLoist tehnologijom sa i bez keeva.
Iz priloenog se moe videti da kada su keevi ukljueni,
vreme uitavanja GUI-a je svedeno na neto manje od
20% vremena uitavanja bez keeva. Dakle, ostvarena
dobit u pogledu vremena odziva je vea od 80%. Drugim
uitavanjem aplikacije dobijen je jo bolji rezultat. Vreme
uitavanja je sad bilo svedeno na 30% inicijalnog
vremena uitavanja sa keevima (dobit od preko 65%).
Kada je aplikacija bila uitavana prvi put, SharedCache je
bio prazan. Kada se on napunio objektima GUI
konfiguracije (uitano stablo GUI konfiguracije iz baze
podataka u brzu memoriju), to je uzrokovalo jo bolji
rezultat uitavanja pri drugom merenju.
6. PRELIMINARNA ANALIZA REENJA
Rezultati dobijeni u praksi korienjem keeva ukazali su
na njihov znaaj i uticaj na opte popravljanje
performansi sistema razvijanih pomou SOLoist
tehnologije. Meutim, reenje je analizirano sa ciljem da
se kritiki ukae na neke njegove dobre i loe strane.
Posebno je bitno detektovati trenutne slabosti reenja, jer
se stie jasna slika i trasira put ka njegovom
unapreivanju.
Preliminarna analiza reenja zasnovana je na poreenju
datog reenja sa Hibernate radnim okvirom. Za ove
potrebe je pronaen ve postojei nezvanini test
perfromansi (benchmark) za Hibernate, na osnovu kojeg
je napravljen identian, samo prilagoen, test za SOLoist
keeve. Ideja je bila da se naprave identini testovi
performansi za Hibernate i SOLoist keeve i
proanaliziraju dobijeni rezultati koji bi trebalo da pokau
na kom se nivou nalaze SOLoist keevi u odnosu na
iroko korieni Hibernate. Testovi su osmiljeni tako da
deluju na razliite aspekte reenja. Osmiljen je i model,
na osnovu kojeg su osmiljeni testovi (Slika 5). Za
testiranje je korieno okruenje JUnit. Testovi se
izvravaju u iteracijama. Svaka iteracija je takva da se u
okviru nje obavlja vea koliina posla nego u prethodnoj,
pa je i njeno vreme izvravanja je due.
Slika 5: Konceptualni model za testiranje performansi sloja
za perzistenciju.
Koraci jedne iteracije testa, prikazani su na sledeem
listingu. Test iteration steps:
Runner r = new Runner();
// set various fields of the runner.
Address a=new Address();
// set various fields of the address
r.address.set(a);
For i:=1 to number_of_runs do
Run r = new Run();
// set various fields of the run
runner.runs.add(r);
End_For
Listing 1: Prikazani su koraci jedne iteracije testa.
Za ilustraciju preliminarne analize bila su odabrana dva
tipa testa: (1) Prvim testom se testira samo kreiranje
instanci klasa i kreiranje linkova izmeu njih (insert
benchmark); (2) Drugi test prvo kreira jedininu
strukturu, a zatim ponavlja operacije izmene podatka nad
objektima u datoj strukturi (update benchmark).
Slika 6: Prikaz INSERT testa performansi. Broj vezanih
objekata predstavlja broj objekata klase Run vezanih za
objekat klase Runner. Rezultati SOLoist keeva su obeleeni
sa (1), a Hibernate-a sa (2).
616
Slika 7: Prikaz UPDATE testa performansi. Broj vezanih
objekata predstavlja broj objekata klase Run vezanih za
objekat klase Runner. Rezultati SOLoist keeva su obeleeni
sa (1), a Hibernate-a sa (2).
Sloj perzistencije SOLoista pokazao se dosta bolje od
Hibernate-a tokom izvravanje testa insert benchmark
(Slika 6). Objanjene lei u manjem broju reijski
operacija koje SOLoist-ov sloj perzistencije izvrava
tokom masovnog kreiranja objekata.
Meutim, Hibernate se pokazao mnogo bolje tokom testa
update benchmark (Slika 7). Objanjene lei u tome da
SOLoist-ov modul za objektno-relaciono mapiranje nije
imao optimizaciju upita, i to posebno u sluaju kada se
vri auriranje vie polja istog objekta.
Opisana preliminarna analiza otkrila je i dobre i
najuticajnije loe strane opisanog reenja keiranja
SOLoist objektnog prostora. Dobre strane bude
optimizam i nastojanje ka daljem poboljanju reenja i
izdavanjem nove verzije. Sa druge strane, slabosti reenja
koje su identifikovane takoe bude optimizam za
unapreenjem ideje jer su i bile oekivane, budui da u
verziji 1 keeva nisu uraene sve optimizacije. Cilj je
prvenstveno bio napraviti ih funkcionalnim i robusnim.
Ono to jo ide u prilog ovoj ideji je to da se pokazana
slabost verzije jedan moe prevazii na jedan relativno
jednostavan nain uvoenjem optimizatora upita, to je
sigurno sledei korak u daljem razvoju keeva.
7. ZAKLJUAK
Predmet ovog istraivanja bio je reavanje problema
perzistencije UML objektnog prostora u relacionoj bazi
podataka za vieslojne i skalabilne veb arhitekture
razvijane pomou SOLoist tehnologije. U tom cilju
implementirano je objektno-relaciono mapiranje SOLoist
objektnog prostora u podatke u relacionoj bazi podataka i
osmiljeni su i implementirani keevi. Implementirane su
dve vrste keeva, Thread Cache i Shared Cache. U cilju
omoguavanja konkurentne obrade nad objektnim
prostorom, implementiran je transakcioni mehanizam sa
optimistikim zakljuavanjem podataka. Keevi su
osmiljeni i implementirani tako da se mogu proizvoljno
slojevito slagati, to daje irok spektar mogunosti
realizacije vieslojnih i skalabilnih arhitektura veb
aplikacija.
Pored implementacije reenja, izvrena je i preliminarna
analiza, njegovo testiranje i poreenje sa postojeim
reenjem Hibernate. Na osnovu tog testa izveden je
zakljuak da su keevi u nekim sluajevima upotrebe
pokazali bolje performanse od Hibernate-a, to je kao
poetni rezultat veoma dobro. Meutim, testovi u kojima
su keevi pokazali slabije performanse, detektovali su
slabosti neoptimizovanih delova implementacije, koji su u
sadanjoj verziji svesno ostavljeni u tom stanju. Opisano
reenje je nalo i praktinu primenu u velikom
komercijalnom projektu koji je uspeno zavren. Glavni
doprinos istraivanja se ogleda u opisu, projektu i
praktinoj potvrdi ideje o perzistenciji SOLoist objektnog
prostora. Dat je i inovativan pristup jednostavnoj
praktinoj realizaciji vieslojnih i skalabilnih veb
arhitektura aplikacija kroz mogunost pravljenja
proizvoljnih piramida keeva. Sa druge strane, prikazan
je i dosta interesantan pristup popravljanju performansi
keiranja realizacijom razliitih politika dohvatanja
unapred. Budui da se ove strategije mogu jo
konfigurisati u vreme izvravanja, to aplikacijama daje
osobinu da se prilagoavaju za optimalan rad u razliitim
sluajevima korienja.
LITERATURA
[1] Miliev, D. Model Driven Development with
Executable UML, Wrox, 2009.
[2] OOIS UML Profile web site, www.ooisuml.org, 2009.
[3] SOLoist web site, www.soloist4uml.com, 2009.
[4] Hibernate official web site, https://www.hibernate.org.
[5] Language Integrated Query (LINQ).
http://msdn.microsoft.com/enus/netframework/aa9045
94.aspx
[6] Bojovi, M. Upravljanje transakcijama, Beograd,
Akademska misao, 2003.
[7] Gamma, Erich, Richard Helm, Ralph Johnson, / John
Vlissides. Design patterns. Addison Wesley, 1994.
[8] Tomaevi, Milo V. Algoritmi i strukture podataka,
Beograd, Akademska misao, 2003.
[8] Keith, Bradford. Hibernate Benchmark
http://code.google.com/p/simple-hibernate-
benchmark/
617