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