Java Tehnologije Za Pristup Relacionim Bazama Podataka u Web Okruzenju

VIŠA ELEKTROTEHNIČKA ŠKOLA

MILENKOVIĆ Ana JAVA TEHNOLOGIJE ZA PRISTUP RELACIONIM BAZAMA PODATAKA U WEB OKRUŽENJU -diplomski rad-

Beograd, 2007

IZVOD U diplomskom radu opisane su Java tehnologije koje se mogu koristiti za pristup relacionim bazama podataka u Web okruženju. Među njima se nalaze Java Database Connectivity (JDBC), SQL for Java (SQLJ), objektno-relaciono mapiranje (ORM) i Enterprise JavaBeans 3 (EJB). Na primeru izrade projekta za pregled i upravljanje nastavnim planom i programom obrađena je primena komponente EJB specifikacije Java Persistance API (JPA) tehnologije sa implementacijom u Hibernate alatu.

ABSTRACT This work describes Java technologies that can be used for accessing relational databases in Web environment. These include Java Database Connectivity (JDBC), SQL for Java (SQLJ), object-relational mapping and Enterprise JavaBeans 3 (EJB). Usage of Hibernate tool, which is implementation of Java Persistance API (JPA), a part of EJB specification, is covered in sample project of curriculum overview and management.

Sadržaj SADRŽAJ......................................................................................................................I INDEKS SLIKA............................................................................................................II 1. UVOD........................................................................................................................1 2. WEB KAO PLATFORMA ZA APLIKACIJE NAD BAZOM PODATAKA.................2 2.1. ZAHTEVI WEB - DBMS INTEGRACIJE..........................................................................2 2.2. WEB – DBMS ARHITEKTURA....................................................................................2 2.2.1. Tradicionalna dvoslojna klijent-server arhitektura............................................... ..................2 2.2.2. Troslojna arhitektura......................................................................................... ....................3

2.3. PREDNOSTI I MANE WEB - DBMS PRISTUPA.................................................................4 2.3.1. Prednosti .................................................................................................. ...........................4 2.3.2. Nedostaci......................................................................................................................... .....6 2.3.3. Mogući načini integracije Weba i DBMS sistema......................................................... .........8

3. JAVA..........................................................................................................................9 3.1. JAVA ARHITEKTURA...................................................................................................9 3.2. JAVA 2 PLATFORMA................................................................................................10 3.2.1. Java EE tehnologije.............................................................................................. ..............12

4. JAVA DATABASE CONNECTIVITY ......................................................................15 4.1. SASTAVNI DELOVI JDBC-A......................................................................................15 4.1.1. JDBC API....................................................................................................................... .....16 4.1.2. JDBC drajver API........................................................................................................ ........16

4.2. TIPOVI JDBC DRAJVERA........................................................................................17 4.3. VERZIJE..............................................................................................................18 4.3.1. JDBC 1.0...................................................................................................... 4.3.2. JDBC 2.0...................................................................................................... 4.3.3. JDBC 3.0...................................................................................................... 4.3.4. JDBC 4.0......................................................................................................

......................18 ......................19 ......................19 ......................20

4.4. POVEZIVANJE NA BAZU PODATAKA...............................................................................20 4.4.1. JDBC URL adresa....................................................................................... .......................20 4.4.2. Registracija drajvera............................................................................................ ...............21 4.4.3. DataSource interfejs....................................................................................... ....................21

4.5. DEFINISANJE I IZVRŠAVANJE NAREDBI...........................................................................22 4.5.1. Rezultati naredbi......................................................................................................... ........22 4.5.2. Parametrizovane naredbe...................................................................... ............................22 4.5.3. Procedure.......................................................................................................... .................23

4.6. TRANSAKCIJE........................................................................................................23 4.7. IMPLEMENTACIJE JDBC DRAJVERA............................................................................25 4.7.1. Oracle.................................................................................................................. ...............25 4.7.2. MySQL........................................................................................................................... .....26 4.7.3. DataDirect..................................................................................................................... ......26

5. SQLJ.......................................................................................................................27 5.1. POREĐENJE JDBC I SQLJ PRISTUPA.......................................................................28 6. OBJEKTNO ORIJENTISANO PROGRAMIRANJE I RELACIONE BAZE PODATAKA.................................................................................................................29 6.1. ORM ALATI.........................................................................................................32 7. ENTERPRISE JAVABEANS 3................................................................................33 7.1. VRSTE EJB KOMPONENTI........................................................................................34 -I-

7.1.1. EJB komponente orijentisane na poruke....................................................... .....................34 7.1.2. EJB session komponente............................................................................. ......................35

7.2. EJB KONTEJNER...................................................................................................36 7.3. ENTITETI I MENADŽER ENTITETA.................................................................................37 7.3.1. Upravljanje životnim ciklusom entiteta................................................................. ...............38 7.3.2. Sinhronizacija sa bazom podataka.................................................................. ...................39 7.3.3. Pretraga entiteta i izvršavanje upita........................................................................... .........39

7.4. METAPODACI........................................................................................................40 7.4.1. Anotacije............................................................................................................. ................40

7.5. JEDNOSTAVAN PRIMER UPOTREBE EJB I JPA KOMPONENTI..............................................42 8. PRAKTIČNI DEO....................................................................................................44 8.1. RAZMATRANI INFORMACIONI SISTEM............................................................................44 8.2. PRIKAZ FUNKCIONALNOSTI........................................................................................46 8.3. KORIŠĆENI ALATI...................................................................................................52 8.3.1. Hibernate............................................................................................................ ................52 8.3.2. Tapestry............................................................................................................ ..................54 8.3.3. Eclipse................................................................................................................ ................55

9. ZAKLJUČAK...........................................................................................................57 10. INDEKS POJMOVA..............................................................................................58 11. LITERATURA........................................................................................................59

Indeks slika SLIKA 1.TRADICIONALNA DVOSLOJNA KLIJENT-SERVER ARHITEKTURA.......3 SLIKA 2.TROSLOJNA ARHITEKTURA ......................................................................4 SLIKA 3.JAVA PLATFORMA.....................................................................................10 SLIKA 4.UPROŠĆENA Ј2ЕЕ ARHITEKTURA..........................................................12 SLIKA 5.SASTAVNI DELOVI JDBCA........................................................................16 SLIKA 6.OSNOVNE JDBC KLASE I INTERFEJSI I NJIHOVE MEĐUSOBNE VEZE .....................................................................................................................................16 SLIKA 1.JDBC DRAJVERI PRVOG (LEVA GRANA) I DRUGOG TIPA (DESNA GRANA)......................................................................................................................17 SLIKA 2.JDBC DRAJVERI TREĆEG (LEVA GRANA) I ČETVRTOG TIPA (DESNA GRANA)......................................................................................................................18 SLIKA 7.PONIŠTAVANJE PROMENA TRANSAKCIJE DO ŽELJENE MEĐUTAČKE .....................................................................................................................................25 SLIKA 8.TOK IZVRŠAVANJA SQLJ KODA..............................................................28 SLIKA 9.ARHITEKTURE SA I BEZ ORM PODSISTEMA.........................................30 SLIKA 10.ŽIVOTNI CIKLUS MDB KOMPONENTE...................................................34 SLIKA 11.ŽIVOTNI CIKLUS SESSION KOMPONENTE BEZ STANJA....................35 SLIKA 12.ŽIVOTNI CIKLUS SESSION KOMPONENTE SA STANJEM...................36 SLIKA 13.EJB KONTEJNER SA PRIPADAJUĆIM EJB KOMPONENTAMA RAZLIČITIH VRSTA....................................................................................................37 SLIKA 14.TRANZICIJE STANJA ENTITETA.............................................................38 - II -

SLIKA 15.TIPOVI KORISNIKA I NJIHOVA ZADUŽENJA U RAZMATRANOM INFORMACIONOM SISTEMU....................................................................................44 SLIKA 16.DETALJNA ARHITEKTURA......................................................................45 SLIKA 17.STRUKTURA BAZE PODATAKA..............................................................46 SLIKA 18.POČETNA STRANA APLIKACIJE............................................................47 SLIKA 19.DODAVANJE NASTAVNOG PLANA........................................................47 SLIKA 20.PREGLED ŽELJENOG NASTAVNOG PLANA ZA ODABRANI SMER...48 SLIKA 21.PRIKAZ DETALJA O ODABRANOM PREDMETU..................................49 SLIKA 22.IZMENA ODABRANOG PREDMETA........................................................49 SLIKA 23.IZMENA ODABRANE STAVKE NASTAVNOG PLANA............................50 SLIKA 24.SPISAK PROFESORA..............................................................................51 SLIKA 25.OSNOVNI DELOVI HIBERNATE-A...........................................................53 SLIKA 26.ARHITEKTURA ECLIPSE-A.....................................................................55

- III -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju

1. Uvod Korporacijski informacioni sistemi (EIS - Enterprise Information Systems) danas su zastupljeni u mnogim softverskim rešenjima. Ova vrsta aplikacija bavi se kreiranjem, upravljanjem i skladištenjem struktuiranih informacija, koje su raspoložive mnogobrojnim korisnicima na mnogobrojnim fizičkim lokacijama. Skladištenje EIS podataka uključuje masivnu upotrebu SQL-baziranih sistema za upravljanje bazama podataka. Svako preduzeće koristi barem jednu SQL bazu podataka; većina je potpuno zavisna od tehnologije relacionih baza podataka. Rašireno prihvatanje Java programskog jezika tokom proteklih pet godina dovelo je do povećanog uticaja objektno-relacione paradigme na razvoj softvera. Programeri se sada oslanjaju na prednosti objektne orijentacije. Sa druge strane, veći deo poslovanja vezan je dugoročno velikim investicijama u skupe relacione sisteme baza podataka. Pored toga što preduzeća već imaju dugogodišenje iskustvo sa konkretnim softverskim proizvodima, postojeći podaci bi se morali učiniti dostupnim novim, objektno-orijentisanim Web aplikacijama. Tabelarna reprezentacija podataka u relacionom sistema fundamentalno se razlikuje od mreže objekata koji se koriste u objektno-orijentisanim Java aplikacijama. Ova razlika dovela je do takozvane nekompatibilnosti objektne i relacione paradigme (object/relational paradigm mismatch). Važnost ovog problema bila je zanemarena i potcenjena, a alati i standardi za rešavanje istog nerazvijeni. U međuvremenu, Java programeri krivili su relacionu tehnologiju za pomenutu nepodudarnost paradigmi; profesionalci iz oblasti relacionih baza podataka krivili su objektnu tehnologiju. Kada se u Java aplikaciji koristi relaciona baza podataka, Java kod izdaje SQL naredbe bazi posredstvom JDBC APIa (Java DataBase Connectivity). Same SQL naredbe mogu biti napisane ručno i ugnježdene u Java kod, ili se mogu generisati tokom kompilacije. JDBC API se koristi za povezivanje argumenata sa parametrima SQL upita, započinjanje izvršavanja upita, navigaciju kroz rezultujući skup, itd. Navedeni zadaci odnose se na pristup podacima nižeg nivoa, koji karakterišu tehnički detalji. Interesi aplikacionih programera više su usmereni na rešavanje poslovnih problema koji zahtevaju pristup podacima u bazi.

-1-


2. Web kao platforma za aplikacije nad bazom podataka U okviru ovog poglavlja biće razmatran Web kao platforma koja obezbeđuje korisnički interfejs prema jednoj ili više relacionih baza podataka. Nakon kraćeg pregleda preduslova Web - DBMS integracije, predstavljena je arhitektura koja se može koristiti u cilju omogućavanja ovog oblika integracije. Na kraju poglavlja razmatrane su prednosti i mane integracije Weba i DBMS sistema.

2.1.Zahtevi Web - DBMS integracije Dok mnogi DBMS proizvođači rade na razvoju rešenja za povezivanje na bazu podataka putem Weba, većina organizacija zahteva opštije rešenje koje će ih osloboditi vezanosti za isključivo jednu tehnologiju. Najvažniji zahtevi kada je u pitanju integracija sistema za upravljanje bazom podataka i Weba, prikazani ispod, predstavljaju ideal koji još uvek nije u potpunosti dostignut. Pritom, u cilju ostvarenja nekih od navedenih zahteva potrebno je smanjiti stepen ispunjenja drugih. − − − − −

− − − − − −

Zahtevi su sledeći: Mogućnost pristupa važnim podacima na siguran način. Povezivanje koje karakteriše nezavisnost od tipova podataka i proizvođača koje bi omogućilo slobodu izbora DBMSa, danas kao i u budućnosti. Sposobnost pristupa bazi podataka nezavisno od bilo kog proizvođačkog Web čitača (browser), Web servera ili aplikacionog servera. Realizacija povezivanja koja će u potpunosti iskoristiti sve osobine konkretnog DBMSa. Pristup na bazi otvorene arhitekture koji bi omogućio interoperabilnost sa različitim sistemima i tehnologijama; na primer, podrška za: o različite Web/aplikacione servere; o DCOM/COM (Distributed/Common Object Model – Microsoft); o CORBA/IIOP (Internet Inter-ORB Protocol); o Java/RMI (Remote Method Invocation). Efikasno rešenje koje će odgovorite na potrebe skaliranja, rasta i promena u strategijskom smislu, i pomoći u smanjenju troškova razvoja i održavanja aplikacija. Podrška transakcijama. Podrška za autentifikaciju sesije i aplikacije. Prihvatljive performanse. Minimalno integraciono premašenje (overhead). Skup alata visokog nivoa produktivnosti koji bi omogućio relativno lako i brzo razvijanje, testiranje, isporuku i održavanje aplikacija.

2.2.Web – DBMS arhitektura U ovom odeljku razmatrana je tradicionalna dvoslojna klijent-server arhitektura u sprezi sa modernim DBMS sistemima. Zatim, prikazana je pogodnija arhitektura za Web okruženje.

2.2.1.Tradicionalna dvoslojna klijent-server arhitektura Poslovne aplikacije nad bazom podataka sastoje se iz četiri glavne komponente: baza podataka, transakciona logika, aplikativna logika i korisnički interfejs. U centralizovanom, MF (mainframe) baziranom sistemu, ove četiri celine se nalaze na jednom mestu. Klijent-server model razvijen je upravo zbog pojave sve većeg broja decentralizovanih poslovnih okruženja. Tradicionalna dvoslojna klijent-server arhitektura obezbeđuje osnovnu podelu zadataka. Primarna odgovornost klijenta (prvi sloj) je prezentacija podataka korisniku, dok je glavna odgovornost servera (drugi sloj) obezbeđivanje servisa podataka klijentu. -2-


Servisi prezentacije upravljaju glavnom poslovnom logikom aplikacije i obrađuju akcije korisničkog interfejsa. Servisi podataka podržavaju ograničenu poslovnu logiku aplikacije (obično validacija koju klijent ne može da obavi zbog nedostatka informacija), i obezbeđuju pristup zahtevanim podacima, nezavisno od njihove lokacije. Podaci se mogu potraživati od relacionih, objektno-relacionih i objektno-orijentisanih DBMS sistema, nasleđenih DBMS-ova ili proizvođačkih sistema za pristup podacima . U većini slučajeva, klijent predstavlja desktop računar krajnjeg korisnika u interakciji sa centralnim serverom baze podataka posredstvom mreže.

slika 1.

Tradicionalna dvoslojna klijent-server arhitektura

2.2.2.Troslojna arhitektura Sredinom devedesetih godina, kada su aplikacije u preduzećima postajale sve složenije i izvršavale se na računarima stotina ili hiljada krajnjih korisnika, klijentska strana u tradicionalnom dvoslojnom klijent-server modelu predstavljala je problem koji je sprečavao skalabilnost, iz više razloga: − Fat tip klijenta, koji zahteva znatnu količinu resursa na klijentskoj mašini kako bi se aplikacija efikasno izvršavala, uključujući procesorsku snagu, prostor na disku i RAM memoriju. − Poslovna logika je distribuirana između servera i klijentskih mašina što otežava ažuriranje aplikacije. − Značajni administrativni overhead na klijentskoj strani. Varijacija dvoslojnog klijent-server modela koja je rešila problem skalabilnosti u velikim preduzećima pojavila se 1995. godine. Nova arhitektura sastojala se iz tri sloja, od kojih se svaki mogao nalaziti na drugoj platformi: 1. Sloj korisničkog interfejsa, koji je smešten na računaru krajnjeg korisnika – klijent. 2. Sloj poslovne logike i obrade podataka. Ovaj srednji sloj se nalazi na serveru i često se naziva aplikacioni server. 3. DBMS, smešten na serveru baze podataka, koji upravlja i skladišti podatke koje u ime klijenta potražuje i obrađuju aplikacije na srednjem sloju. Prema modelu troslojne arhitekture, klijent je odgovoran samo za korisnički interfejs aplikacije uz eventualni dodatak jednostavne logike obrade, kao što je validacija. U skladu sa ovim osobinama, prvi sloj predstavlja thin klijenta. Jezgro poslovne logike sada je izmešteno na poseban sloj, fizički povezan sa klijentom putem Interneta i serverom baze podataka putem lokalne računarske mreže (LAN – Local Area Network) ili računarske mreže šireg područja (WAN – Wide Area Network). Aplikacioni serveri su projektovani tako da uspešno opslužuju višestruke klijente.

-3-


Prednosti troslojne arhitekture nad tradicionalnim dvoslojnim modelom ili modelom sa jednim slojem su brojne, uključujući: − Smanjenje troškova vezano za hardver klijentskih mašina, budući da je u pitanju thin tip klijenta. − Sa izdvajanjem poslovne logike koja se odražava na brojne krajnje korisnike na zaseban sloj u vidu aplikativnog servera, ažuriranje i održavanje aplikacije je centralizovano. Ovim se eliminiše problem distribucije softvera, koji je bio prisutan u dvoslojnom klijent-server modelu. − Sa dobijenom modularnošću moguće je lako izmeniti ili zameniti neki od slojeva bez uticaja na ostale. − Balansiranje opterećenja je znatno lakše usled razdvajanja poslovne logike od servisa baze podataka. Dodatnu prednost predstavlja sposobnost troslojne arhitekture da se potpuno prirodno uklopi u Web okruženje, gde bi Web čitač predstavljao thin klijenta, a aplikacioni server sa poslovnom logikom bi zamenio Web server. Troslojna arhitektura se može proširiti na višeslojnu, pri čemu bi dodati slojevi obezbedili još veću fleksibilnost i bolju skalabilnost. Na primer, srednji sloj u troslojnoj arhitekturu može se podeliti na dva, sa jednim slojem koji bi služio kao Web server i drugim kao aplikacionim serverom.

slika 2.

Troslojna arhitektura

2.3.Prednosti i mane Web - DBMS pristupa Web kao platforma za sisteme nad bazom podataka može doneti novine u rešenjima kako unutrašnjih tako i spoljašnjih problema poslovnih aplikacija. Međutim, prisutni su i nedostaci vezani za ovakav pristup. U ovom odeljku prikazane su prednosti i mane integracije Weba i DBMSa.

2.3.1.Prednosti Pregled prednosti Web – DBMS pristupa prikazan je u tabeli 1:

-4-


tabela 1.Prednosti Web – DBMS pristupa Prednosti dobijene upotrebom DBMS sistema Jednostavnost Platformska nezavisnost Grafički korisnički interfejs Standardizacija Transparentan mrežni pristup Skalabilan razvoj Inovativnost 1. Prednosti dobijene upotrebom DBMS sistema Ne treba posebno naglašavati prednosti koje je doneo razvoj sistema za upravljanje bazama podataka, u odnosu na fajlovski baziran model, gde je svaki dokument uskladišten u okviru zasebnog fajla. Nedostaci tradicionalnih, fajlovski baziranih sistema su brojni, što je i uslovilo razvoj praktičnijeg i naprednijeg rešenja za upravljanje podacima. Navedeni su neki od nedostataka fajlovski baziranih sistema: izolacija podataka, redudansa podataka, nekompatibilnost formata fajlova, nepostojanje kontrole nad pristupom i upravljanjem podacima, osim one definisane u aplikaciji, itd. Novina u DBMS pristupu ogleda se u razdvajanju definicija podataka od aplikacije, koje se sada samostalno čuvaju u okviru baze podataka (metapodaci). DBMS predstavlja softver koji posreduje između korisnika i baze podataka, omogućavajući korisniku da definiše, kreira, održava i kontroliše pristup bazi podataka. U pogledu Weba, jedan od problema koji se rešava njegovom integracijom sa DBMS sistemom jeste problem sinhronizacije informacija između HTML fajlova i baze podataka, budući da se HTML stranice mogu dinamički generisati na osnovu podataka iz baze. 2. Jednostavnost U svom inicijalnom obliku, HTML jezik bio je jednostavan za učenje i korišćenje kako programerima tako i krajnjim korisnicima. Do jednog nivoa, ova činjenica i danas važi obzirom da HTML stranice ne odlikuje previše kompleksna funkcionalnost. Međutim, HTML specifikacija se neprekidno dopunjuje novim i naprednijim funkcijama, i uz mogućnost ugnježdavanja skript jezika unutar HTMLa, originalna jednostavnost iščezava. 3. Platformska nezavisnost Znatan uticaj na odluku o razvoju Web-bazirane verzije aplikacija nad bazom podataka imala je činjenica da su Web klijenti (čitači) danas uglavnom platformski nezavisni. Budući da postoje čitači za sve glavne računarske platforme, i uz korišćenje HTML/Java standarda, aplikacije se ne moraju menjati kako bi funkcionisale na različitim operativnim sistema. Sa druge strane, tradicionalni klijenti baza podataka zahtevaju značajne modifikacije ili čak potpuno redizajniranje, u cilju prevazilaženja platformskih razlika. Nažalost, neki proizvođači Web čitača, kao što su Microsoft i Netscape, nude i specifične proizvođačke usluge u okviru svojih čitača, čime se gubi dobit koju bi donela ova prednost. 4. Grafički korisnički interfejs Osnovni problem pri korišćenju baze podataka predstavlja pristup podacima. Dobar grafički korisnički interfejs (GUI – Graphical User Interface) trebalo bi da pojednostavi i poboljša pristup podacima. Nažalost, grafički korisnički interfejsi zahtevaju veoma složeno programiranje, uglavnom su platformski zavisni, i u mnogim slučajevima ih karekteriše specifičnost proizvođača. Međutim, Web čitači obezbeđuju jednostavan grafički korisnički interfejs koji je lak za korišćenje i putem kog se može pristupati raznim izvorima informacija, uključujući i baze podataka. Postojanje standardnog interfejsa takođe smanjuje troškove obuke krajnjih korisnika. -5-


5. Standardizacija HTML predstavlja de facto standard koji prate svi Web čitači, omogućavajući tako HTML dokumentu koji se nalazi na jednom računaru da bude pročitan od strane korisnika na bilo kojoj računarskoj mašini u svetu koja poseduje Internet konekciju i Web čitač. Korišćenjem HTML standarda, programeri treba da se obuče za samo jedan jezik, a krajnji korisnici koriste jedinstven grafički korisnički interfejs. Ipak, kao što je pomenuto, proizvođači danas nude specifične usluge koje u opštem slučaju nisu dostupne. 6. Transparentan mrežni pristup Najveću prednost Weba predstavlja potpuna transparentnost mrežnog pristupa iz ugla krajnjeg korisnika, budući da se mrežni pristup, izuzev specificiranja URL adrese, u potpunosti odvija pod nadležnošću Web čitača i Web servera. Ugrađena podrška mrežnoj komunikaciji znatno pojednostavljuje pristup bazi podataka, eliminišući ujedno potrebu za skupim mrežnim softverom i složenost postizanja komunikacije između različitih platformi. 7. Skalabilan razvoj Produkti tradicionalne dvoslojne klijent-server arhitekture su fat klijenti koji neefikasno obrađuju procese vezane za korisnički interfejs i aplikativnu logiku. Nasuprot tome, Webbazirano rešenje ima tendenciju ka prirodnijoj troslojnoj arhitekturi koja čini osnovu skalabilnosti. Smeštanjem aplikacije na odvojen server umesto na klijenta, Web eliminiše utrošak vremena i sredstava potrebnih za razvoj aplikacije. Takođe pojednostavljuje upravljanje nadogradnjom aplikacije i prevazilaženje platformskih razlika. Danas, korišćenjem aplikativnog servera, aplikaciji se može pristupiti sa bilo kog Web sajta na svetu. 8. Inovativnost Kao platforma za Internet, Web omogućava organizacijama da predstave nove servise i dopru do novih korisnika putem aplikacija koje su dostupne na globalnom nivou. Sa hostbaziranim ili tradicionalnim klijent-server aplikacijama, ova mogućnost nije postojala.

2.3.2.Nedostaci Nedostaci Web – DBMS pristupa takođe postoje i oni su prikazani su u tabeli 2: tabela 2.Nedostaci Web – DBMS pristupa Pouzdanost Sigurnost Troškovi Skalabilnost Ograničena funkcionalnost HTMLa Nepostojanje uspostave stanja Propusni opseg Performanse Nezrelost razvojnih alata 1. Pouzdanost Internet je trenutno nepouzdan i spor komunikacioni medijum – ne postoje prave garancije da će zahtev koji se prenosi putem Interneta biti isporučen (na primer, uvek postoji mogućnost da je server van funkcije). Poteškoće rastu kada korisnici pokušavaju da pristupe informacijama na serveru u periodu najveće potražnje (peak time) kada je server značajno preopterećen ili je mreža u upotrebi spora. Pozdanost Interneta predstavlja problem za koji je potrebno vreme kako bi se razrešio. U sprezi sa sigurnošću, pouzdanost je jedan od glavnih razloga zbog kog organizacije i preduzeća radije nastavljaju sa korišćenjem sopstvenih intranet mreža umesto Interneta, kada su u pitanju kritične aplikacije. Privatnu intranet mrežu

-6-


kontroliše sama organizacija, održavajući je i unapređujući onda kada smatra da je to potrebno. 2. Sigurnost Veliku zabrinutost jedne organizacije koja svoju bazu podataka treba da učini dostupnom putem Weba predstavlja upravo sigurnost. Autentifikacija korisnika i siguran prenos podataka su od izuzetne važnosti, zbog velikog broja potencijalnih anonimnih korisnika. 3. Troškovi Suprotno uvreženom mišljenju, upotreba Interneta može biti skupa, naročito sa rastućim zahtevima i očekivanjima korisnika. Na primer, Forrester Research izveštaj navodi da troškovi komercijalnog Web sajta variraju između 300.000 i 3.4 miliona dolara, zavisno od ciljeva koje organizacija želi da postigne konkretnim sajtom, uz predviđanje da će troškovi porasti za 20% ili 50% u narednih nekoliko godina. Na vrhu skale nalaze se sajtovi koji prodaju proizvode ili vrše isporuke, gde 20% troškova odlazi na hardver i softver, 28% na marketing samog sajta, a preostalih 56% se utroši na razvijanje sadržaja sajta. Jasno je da malo toga može da se uradi po pitanju smanjenja troškova kreativnog razvoja Web materijala; međutim, sa unapređenim alatima i komunikacionim servisima srednjeg sloja, moguće je značajno redukovati troškove tehničkog razvoja. 4. Skalabilnost Web aplikacije mogu biti suočene sa nepredvidivim i potencijalno ogromnim naletom zahteva u kratkom vremenskom intervalu (peak loads). Ovaj problem zahteva razvoj serverske arhitekture visokih performansi koju ujedno odlikuje i dobra skalabilnost. Sa ciljem poboljšanja skalabilnosti, uveden je model Web farmi gde dva ili više servera opslužuju isti sajt. HTTP zahtevi se obično rutiraju do svakog servera unutar farme po principu RoundRobin mehanizma, kako bi se distribuiralo opterećenje i omogućilo opsluživanje višestrukih zahteva. Ipak, održavanje koherentnosti podataka na više servera unutar farme može postati veoma kompleksno. 5. Ograničena funkcionalnost HTMLa Iako HTML obezbeđuje zajednički interfejs koji je lak za korišćenje, njegova jednostavnost implicira da se neke aplikacija nad bazom podataka koje imaju visok nivo interaktivnosti, ne mogu lako konvertovati u Web-bazirane aplikacije, uz zadržavanje istog stepena komfora za krajnje korisnike. Moguće je implementirati dodatnu funkcionalnost unutar Web strana korišćenjem skript jezika kao što je JavaScript ili VBScript, kao i upotrebom Java ili ActiveX komponenti. Međutim, većina prethodno pomenutih pristupa je previše kompleksna za neiskusne krajnje korisnike. Dodatno, postoji problem sa pogoršanjem performansi do kog dolazi prilikom preuzimanja i izvršavanja koda pomenutih skript jezika. 6. Nepostojanje uspostave stanja Trenutno nepostojanje uspostave stanja u Web okruženju otežava upravljanje konekcijama baze podataka i korisničkim transakcijama, usled čega aplikacija mora da vodi računa o dodatnim informacijama. 7. Propusni opseg Sa današnjom praksom, jedan paket putuje LAN mrežom pri maksimalnoj brzini od 10 miliona bitova u sekundi (bps) u slučaju Eternet mreže, a 2500 miliona bps u slučaju ATM mreže. Nasuprot tome, na najbržim delovima Interneta, paket se prenosi brzinom od samo 1,544 miliona bps. Navedene činjenice jasno impliciraju da je propusni opseg resurs koji predstavlja problem u slučaju Web okruženja. Samim tim, oslanjanje na pozive serveru zbog izvršenja i najjednostavnijih zadataka (uključujući i obradu forme), a imajući na umu da pozivi putuju Internetom, predstavlja rizik. -7-


8. Performanse Mnogi delovi složenih Web-baziranih klijenata baze podataka okupljaju se oko interpretiranih jezika, što ih čini sporijim od tradicionalnih klijenata baze podataka koje karakteriše nativna kompilacija. Na primer, HTML se mora interpretirati i renderovati unutar Web čitača; JavaScript i VBScript predstavljaju interpretirane skript jezike koji proširuju HTML programskim konstruktorima; Java aplet je kompajliran u bajtkod, i upravo taj bajtkod biva preuziman i interpretiran od strane Web čitača. Za aplikacije kojima je vreme izvršavanja od izuzetne važnosti, produženje usled interpretacije jezika može značitii preveliko usporenje. Sa druge strane, postoji mnogo više aplikacija kojima vreme izvršavanja ne predstavlja kritičan faktor. 9. Nezrelost razvojnih alata Programeri koji su razvijali Web aplikacije nad bazom podataka brzo su došli do zaključka da su razvojni alati koji su trenutno dostupni nedovoljno zreli da bi se koristili za složenije projekte. Sve do nedavno, veći deo Internet razvoja bio je zasnovan na programskim jezicima prve generacije, uz razvojna okruženja koja su uključivala tek nešto više od tekst editora. Ova činjenica predstavlja značajnu prepreku za brži razvoj Interneta, naročito imajući u vidu da danas aplikativni programeri očekuju ozbiljna, grafička razvojna okruženja. Web tehnologija je još relativno nerazvijena, i bolja razvojna okruženja se i dalje očekuju da preuzmu deo tereta koji nose aplikativni programeri. Postoji mnogo konkurentnih tehnologija i još uvek se ne može predvideti da li će ove tehnologije u potpunosti iskoristiti svoj potencijal. Takođe ne postoje vodeći principi kojima se treba rukovoditi prilikom odabira prave tehnologije za konkretnu aplikaciju. Još uvek ne postoji dovoljan nivo iskustva sa Web aplikacijama nad bazom podataka, kao što je to slučaj sa tradicionalnijim pristupom, koji nije Web-baziran. Vremenom, ovaj nedostatak će nestati. Mnoge prednosti i mane koje su navedene su privremenog karaktera. Neke prednosti će se vremenom izgubiti, na primer, sa povećanjem složenosti HTMLa. Slično, neki nedostaci će takođe nestati, imajući u vidu da je sazrevanje Web tehnologija, kao i njihovo bolje shvatanje, sasvim očekivano nakon izvesnog vremena. Bitno je istaći da su stalne promene radnog okruženja izvesne kada je reč o razvoju Web aplikacija nad bazom podataka.

2.3.3.Mogući načini integracije Weba i DBMS sistema Nabrojane su neke od mogućih komponenti integracije baza podataka sa Web okruženjem, u ovom trenutku: − skript jezici, kao što su JavaScript i VBScript; − serverski skript jezici PHP, Perl; − CGI – Common Gateway Interface, jedna od prvih, i moguće najrasprostanjenijih tehnika; − HTTP kolačići (cookies); − proširenja Web servera, kao što su NSAPI (Netscape API) i ISAPI (Microsoft Internet Information Server API); − Java i JDBC, SQLJ, servleti i JSP (JavaServer Pages); − ORM (Object Relational Mapping) alati, EJB (Enterprise JavaBeans); − Microsoft produkti ASP (Active Server Pages) i ADO (ActiveX Data Objects); − Oracle Internet platforma. Navedeni načini integracije sigurno ne iscrpljuju listu mogućih pristupa koji se mogu koristiti. U okviru ovog rada biće razmatrane pre svega mogućnosti pristupa relacionim bazama podataka pomoću tehnologija baziranih na Java jeziku.

-8-


3. Java Java predstavlja programski jezik razvijen od strane Sun Microsystems, sa ciljem razvoja aplikacija koje se izvršavaju u heterogenim, mrežnim i distribuiranim okruženjima. Najveći izazov u tom poduhvatu predstavljala je sigurna isporuka aplikacija koje zahtevaju minimalne resurse, mogu se izvršavati na bilo kom hardveru i bilo kojoj softverskoj platformi, i dinamički su proširive. Programski jezik Java potiče iz projekta čija je namena bila razvoj naprednog softvera za brojne mrežne uređaje i ugnježdene (embeded) sisteme. Cilj je bio razviti pouzdanu, portabilnu, distribuiranu operativnu platformu koja radi u realnom vremenu. Na početku projekta, u tu svrhu odabran je programski jezik C++. Međutim, tokom rada ustanovljeno je da su problemi i teškoće pri radu sa C++ jezikom došli do tačke kada je najbolje rešenje bilo razviti potpuno novu jezičku platformu. Odluke vezane za dizajn i arhitekturu bazirane su na jezicima kao što su Eiffel, Smaltalk, Object C. Rezultat predstavlja jezička platforma koja se pokazala idealnom za razvoj sigurnih, distribuiranih, mrežno-baziranih korisničkih aplikacija koje rade u različitim okruženjima, od mrežnih uređaja i ugnježdenih sistema do Weba i desktop računara. Java nije u potpunosti ispunila svoj potencijal sve do porasta popularnosti Interneta i Weba. Danas, Java brzo postaje de facto standard za Web programiranje. Značaj Java jezika i tehnologija je u naglom porastu proteklih nekoliko godina. Java je objektno orijentisani jezik koji je interesantan zbog svojih potencijala u pogledu razvoja Web aplikacija (apleti) i serverskih aplikacija (servleti). Mnoge organizacije odabrale su da koriste Java jezik zbog sve većeg interesovanja za isti, njegove sličnosti sa C i C++ jezicima i industrijske podrške. Java je “jednostavan, objektno orijentisan, distribuiran, interpretiran, robustan, siguran, arhitekturalno nezavisan, portabilan, visoko performatan, višenitni i dinamički jezik“ (Sun, 1997).

3.1.Java arhitektura Java je posebno značajna zbog njene platformski nezavisne arhitekture, Java virtuelne mašine (JVM – Java Virtual Machine). Iz ovog razloga, za Java jezik se često navodi karakteristika “napiši jednom, pokreni bilo gde”1. Java okruženje prikazano je na slici 11. Java kompajler prihvata .java fajl i generiše .class fajl, koji sadrži bajtkod koji nije zavisan ni od jedne računarske arhitekture. Bajtkod predstavljaju binarnu reprezentaciju Java programa i dizajniran je za izvršavanje od strane virtuelne mašine umesto hardvera. Ujedno je jednostavan za interpretaciju na svakoj platformi kao i za prevođenje u nativne metode. JVM može interpretirati i izvršiti Java bajtkod direktno na svakoj platformi na koju su portovani interpreter i sistem za izvršavanje. Pošto su skoro svi proizvođači Web čitača ugradili podršku za JVM, Java aplikacije sada se mogu izvršavati na većini platformi krajnjih korisnika. Java aplikacija se pre izvršavanja mora učitati u memoriju, o čemu se brine učitavač klasa (Class Loader). On prihvata .class fajlove koji sadrže bajtkod i smešta ih u memoriju. Class fajl se može učitati sa lokalnog diska ili preuzeti sa mreže. Takođe, bajtkod se mora verifikovati kako bi se proverila njegova validnost i utvrdila usklađenost sa Java sigurnosnim zahtevima. Slobodno govoreći, Java predstavlja bezbedan C++. Njena bezbednost ogleda se u jakoj statičkoj proveri tipova, implicitnom upravljanju memorijom kroz automatske “sakupljače smeća” (garbage collector) u cilju rukovanja dealokacijom dinamički alocirane memorije, kao i u potpunom odsustvu pokazivača. Kombinacija ovih osobina čini Java jezik bezbednim od grešaka usled nepravilne upotrebe tipova pokazivača, a koje su upravo bile čest slučaj u C/C++ programima. Ova sigurnosna svojstva su veoma značajna, imajući na umu osnovni cilj projektanata Java jezika - mogućnost bezbednog prenošenja Java koda putem Interneta. 1

Sun - “write once, run anywhere“ -9-


slika 3.

Java platforma

3.2.Java 2 platforma Platforma predstavlja hardversko ili softversko okruženje za izvršavanje programa. Hardverske platforme (platforme prvog nivoa) su danas većinski zamenjene operativnim sistemima (platformama drugog nivoa), koji predstavljaju softversko okruženje i nude apstrakciju hardvera. Analogno, virtuelne mašine (platforme trećeg nivoa) omogućavaju apstrakciju operativnog sistema u upotrebi. Danas postoje dve implementacije virtuelne mašine – JVM i .NET Framework od kojih, za sada, samo JVM realno omogućava portabilnost. Sa prevazilaženjem okvira istraživačkog projekta, Sun je odlučio da razvije Java Development Kit – JDK, u koji je uključen kompajler i sistem za izvršavanje, raspoloživ na Internetu i besplatan za preuzimanje. JDK 1.0 objavljen je početkom 1996. godine, a JDK 1.1 bio je javno dostupan u februaru 1997. Ubrzo, Sun je najavio inicijativu razvoja Java korporativne platforme – JPE (Java Platform for the Eterprise), koja se sastojala iz standardnih Java proširenja poznatih kao Enterprise Java API. Cilj JPE bio je da svi proizvođači produkata srednjeg sloja implementiraju standardno izvršno okruženje za distribuirane aplikacije, bilo kao deo novih proizvoda ili iznad postojećih rešenja vezanih za srednji sloj. Takav pristup bi omogućio programerima da razvijaju platformski i proizvođački nezavisna rešenja. Ipak, brojni problemi vezani za JPE bili su prisutni; na primer, nije postojao način provere da li je serverska platforma kompatibilna sa JPE, a interfejsi su se razvijali odvojeno. Sredinom 1999. godine, Sun je objavio planove za razvoj tri jasno profilisane Java Enterprise platforme, te je došlo do sledeće podele: − J2ME: Mikro Java 2 platforma (Java 2 Micro Edition), namenjena ugnježdenim i elektronskim sistemima (bežični uređaji, mobilni telefoni, navigacioni uređaji u automobilima itd). J2ME sadrži samo interfejse koji su neophodni za ugnježdene aplikacije. − J2SE: Standardna Java 2 platforma (Java 2 Standard Edition), tipično namenjena desktop okruženjima i suštinski se poistovećuje sa Java 2 platformom ( odnosno, JDK 2). − J2EE: Enterprise Java 2 platforma (Java 2 Enetrprise Edition) namenjena je robusnim, skalabilnim, višekorisničkim i sigurnim korporacijskim aplikacijama.

- 10 -


Danas, nakon deset godina postojanja, Java tehnologija postala je kompletan softverski “ekosistem” koji obezbeđuje različite vrste funkcionalnosti za različite tipove potrošača i poslovnih korisnika. J2EE dizajnirana je sa namerom da pojednostavi složene probleme vezane za razvoj i upravljanje višeslojnim korporacijskim aplikacijama. Shodno tome, J2EE platforma koristi višeslojni distribuirani aplikacioni model. Aplikativna logika podeljena je na komponente različite funkcionalnosti, i različite aplikacione komponente koje čine J2EE aplikaciju distribuiraju se na različite mašine u skladu sa slojem kojem određena komponenta pripada. J2EE predstavlja industrijski standard otvorenog tipa, vođen od strane Sun Microsystems u saradnji sa nekolicinom proizvođača kao što su IBM, Oracle i BEA Systems. Kamen temeljac J2EE platforme predstavlja EJB, standard za kreiranje serverskih komponenti na sloju poslovne logike. Na slici 12 su prikazane tri višeslojne J2EE aplikacije koje su podeljene u slojeve definisane sledećom listom: − Prezentacioni sloj - klijent: Postoje brojne alternative vezano za sloj prezentacije, uključujući Web-bazirane klijente, Java aplete, Java aplikacije i CORBA-bazirane klijente. o Web klijenti sastoje se iz dve celine – Web strana (XML, HTML) koje se dinamički generišu od strane J2EE komponente koja je smeštena na Web sloju, i Web čitača koji obrađuje stranice dobijene od servera. J2EE klijenti su thin tipa, a kompleksne operacije poput interakcije sa bazom podataka i primene poslovnih pravila odvijaju se posredstvom EJB komponenti (Enterprise JavaBeans) koje se izvršavaju na J2EE serveru. o Apleti predstavlja male klijentske aplikacije pisane u Java jeziku koje se izvršavaju unutar Web čitača pomoću Java virtuelne mašine. o Java aplikacije koje se izvršavaju na klijentskoj mašini omogućavaju korisnicima obavljanje zadataka koji zahtevaju bogatiji korisnički interfejs u odnosu na HTML. J2EE aplikacije direktno koriste EJB komponente koje se nalaze na sloju poslovne logike. Takođe, ukoliko je to neophodno, aplikacija može otvoriti HTTP konekciju i ostvariti komunikaciju sa servletima na Web sloju. o CORBA-bazirani klijenti koriste CORBA servise imena kako bi locirali komponente na sloju poslovne logike, nakon čega upotrebom CORBA/IIOP protokola ostvaruju pozivanje metoda ovih komponenti. Pored nabrojanih, postoje i klijenti koji koriste JNDI servise kako bi pronašli odgovarajuće komponente na sloju poslovne logike, nakon čega se pozivanje njihovih metoda unutar Java virtuelne mašine obavlja posredstvom RMI/IIOP protokola (Java Remote Method Invocation over Internet Inter-ORB Protokol). Alternativno, moguće je i asinhrono slanje poruka korišćenjem Java servisa poruka – JMS (Java Message Service). Klijentski sloj opcionalno može sadržati i JavaBean komponente koje upravljaju tokovima podataka između klijentske aplikacije ili apleta i komponenata koje se nalaze na J2EE serveru.

- 11 -


slika 4.

−

−

Uprošćena Ј2ЕЕ arhitektura

Srednji sloj – J2EE aplikacioni server: Srednji sloj se sastoji iz Web sloja i sloja poslovne logike. o Web komponente mogu biti servleti ili JSP (Java Server Pages) stranice. Servleti predstavljaju Java klase koje dinamički procesiraju zahteve i na osnovu istih generišu odgovore, tipično u HTML ili XML formi. JSP stranice su specijalan tip servleta koji omogućava kombinovanje statičkog HTML sadržaja sa dinamički generisanim. Kao i u slučaju klijentskog sloja, Web sloj može sadržati JavaBean komponente koje upravljaju ispostavom korisnički unetih podataka do EJB komponenti na sloju poslovne logike, gde se dalje odvija obrada podataka. o Sloj poslovne logike razrešava specifične potrebe iz oblasti konkretnog poslovnog domena, kao što su bankarstvo, trgovina ili finansije posredstvom EJB komponenti, o kojima će kasnije biti više reči. Sloj podataka može biti realizovan kao server baze podataka, ERP sistem (Enterprise Recource Planning), ili može biti u pitanju neki od nasleđenih informacionih sistema korporacije.

3.2.1.Java EE tehnologije U cilju boljeg razumevanja stvarne vrednosti Java EE platforme, navedene su neke od najvažnijih tehnologija i API specifikacija koje su podržane u okviru Java EE 5.0. EJB (Enterprise JavaBeans). EJB definiše način razvijanja serverskih komponenti i predstavlja standardan način interakcije komponenti i aplikacionih servera. Sa tim na umu, za EJB se obično kaže da je kamen temeljac Java EE platforme. JAX-WS (Java API for Web Services). Ranije poznat kao JAX-RPC, JAX-WS predstavlja glavnu tehnologiju koaj obezbeđuje podršku Web servisima u okviru Java EE platforme. Definiše dva moguća krajnja modela – jedan baziran na tehnologiji servleta i drugi baziran na EJB komponentama. - 12 -


RMI i RMI/IIOP. RMI je nativni način Java jezika za komunikaciju između distribuiranih objekata, kao što su dva različita objekta koja se izvršavaju na različitim mašinama. RMI/IIOP predstavlja proširenje koje omogućava CORBA integraciju. Zvaničan API koji se koristi u okviru Java EE je RMI/IIOP. JNDI (Java Naming and Directory Interface). JNDI se koristi za pristup imenovanim i direktorijumskim sistemima. U okviru aplikacije JNDI se može koristiti u različite svrhe, kao što je povezivanje sa EJB komponentama ili drugim drugim izvorima na mreži, ili radi pristupa podacima na mreži definisanih servisom imena. JDBC (Java DataBase Connectivity). JDBC definiše skup interfejsa za pristup podacima u relacionim bazama podataka. Ključna vrednost JDBCa ogleda su u mogućnosti pristupa gotovo svakoj relacionoj bazi podataka korišćenjem istog interfejsa. JTA (Java Transaction API) i JTS (Java Transaction Service). JTA je API višeg nivoa koji omogućava aplikacijama i aplikacionim serverima da pristupaju transakcijama. JTA definiše specifikaciju za upravljanje transakcijama namenjenu menadžerima resursa i transakcionim aplikacijama u distribuiranim transakcionim sistemima. JTS predstavlja implementaciju transakcionog menadžera, koji podržava JTA i implementira Java mapiranje za OMG OTS 1.1 (ObjectTransaction Service) specifikaciju, na nivou ispod JTA interfejsa. JMS (Java Messaging Service). JMS omogućava komunikaciju zasnovanu na poruka, kako u okviru tako i izvan Java EE sistema u upotrebi. Na primer, moguće je povezivanje na postojeće sisteme koji su bazirani na porukama (MOM – Message Oriented Middleware), kao što je IBM MQSeries ili Microsoft Message Queue (MSQM). Razmena poruka predstavlja alternativnu paradigmu za RMI/IIOP, sa svojim prednostima i nedostacima. Java servleti. Servleti predstavljaju mrežne komponente koje se koriste u cilju proširivanja funkcionalnosti Web servera. Servlete karakteriše zahtev/odgovor paradigma, na taj način da od klijenata (na primer Web čitača) primaju zahteve a šalju im odgovore. JSP (Java Server Pages). JSP tehnologija je veoma slična servletima. Zapravo, JSP skripti se kompajliraju u servlete. Najveća razlika između JSP skripta i servleta jeste da JSP skript nije u potpunosti pisan u Java jeziku. JSF (Java Server Faces). JSF predstavlja radni okvir koji pojednostavljuje kreiranje korisničkog interfejsa za Java EE aplikacije. JSF komponente korisničkog interfejsa mogu se koristiti u okviru JSF stranica (koje su zapravo JSP stranice sa JSF tagovima) kao drag-anddrop komponente. JSF podržava skup interfejsa za prikaz komponenata korisničkog interfejsa, praćenje njihovog stanja, opsluživanje događaja, validaciju ulaznih podataka, navigaciju stranica. JCA (Java EE Connector Architecture). Konektori omogućavaju pristup postojećim EIS (Enterprise Information System) sistemima ili aplikacionim serverima iz Java EE aplikacije. Ovo uključuje i sisteme sa transakcionim monitorima (CICS, Tuxedo), ERP sisteme ili postojeće informacione sisteme konkretne kompanije. Konektori su korisni jer automatski upravljaju detaljima integracije proizvoda srednjeg sloja u upotrebi sa postojećim sistemom (upravljanje transakcijama, sigurnosni domeni, upravljanje nitima itd). Kada se konektor za povezivanje na željeni sistem jednom konfiguriše, može se upotrebljavati i prenositi na bilo koji Java EE kompatibilan server. JAXP (The Java API for XML Parsing). JAXP omogućava aplikaciji da samostalno validira, parsira i transformiše XML dokumenate putem nekoliko različitih interfejsa. Dva glavna interfejsa za parsiranje su DOM (Document Object Model) i SAX (Simple API for XML), a JAXP takođe uključuje i XSLT interfejs za transformaciju XML dokumenata. JAXB (The Java API for XML Binding). JAXB specificira vezivanje XML dokumenata sa JavaBean objektima, koje je bazirano na XML šemi samog dokumenta. - 13 -


JAAS (The Java Authentication and Authorization Service). JAAS je standardan interfejs za izvođenje sigurnosnih operacija u okviru Java EE. Konceptualno, JAAS omogućava umetanje autentifikacionih i autorizacionih mehanizama unutar Java EE servera.

- 14 -


4. Java DataBase Connectivity JDBC (Java DataBase Connectivity) predstavlja API specifikaciju razvijenu od strane Sun Microsystems koja definiše uniforman skup interfejsa za pristup heterogenim relacionim bazama podataka, kao i drugim tabelarnim izvorima podataka korišćenjem Java programskog jezika. Usled konfuzije nastale proliferacijom proizvođačkih API interfejsa, ideja univerzalnog interfejsa za pristup bazama podataka nije nova. Zapravo, JDBC je razvijan upravo imajući u vidu jedan takav interfejs – ODBC (Open DataBase Connectivity). ODBC je razvijen kao jedinstven standard za pristup bazama podataka u Windows okruženju a pisan je na C programskom jeziku. Kao takav, nije platformski nezavisan. JDBC je takođe zasnovan na X/OPEN SQL CLI (Call Level Interface) standardu. CLI interfejsi ne zahtevaju prekompilaciju kao u slučaju ugnježdenog SQL-a (Embeded SQL), korak u kom se ugrađeni SQL kod konvertuje u kod host jezika. Iznad JDBCa, moguća je nadogradnja putem interfejsa višeg nivoa: Ugnježdeni SQL za Javu – u okviru ovog pristupa, SQL naredbe se ne prosleđuju kao string atributi Java metodama. Pretprocesor ugrađenih SQL upita omogućava programeru da kombinuje SQL iskaze direktno sa Java jezikom; na primer, Java promenljiva može se koristiti u SQL iskazu za primanje ili isporuku SQL vrednosti. Zatim pretprocesor ugrađenih SQL iskaza prevodi ovaj Java/SQL kod u Java jezik sa JDBC pozivima. Konzorcijum čiji su učesnici Oracle, IBM i Sun definisali su SQLJ (SQL for Java) specifikaciju koja se bavi ovim pristupom, o kojoj će biti reči kasnije. − Direktno mapiranje tabela relacionih baza podatka u Java klase – prilikom objektnorelacionog mapiranja , svaki red tabela postaje jedna instanca odgovarajuće klase, dok svaka vrednost kolone postaje jedan atribut te instance. Programeri zatim mogu direktno manipulisati Java objektima, pri čemu se SQL kod potreban za dobijanje i skladištenje podataka automatski generiše. Takođe postoje i sofisticirane metode mapiranja, na primer, kombinovanje redova iz više tabela u Java klasu. Postoje brojni alati raznih proizvođača koji obezbeđuju ovaj tip funkcionalnosti, koji će biti posebno obrađeni. −

4.1.Sastavni delovi JDBC-a JDBC se sastoji od dva glavna interfejsa: JDBC API, namenjen aplikativnim programerima, koji definiše komunikaciju na relaciji aplikacija – JDBC menadžer, − JDBC drajver API, interfejs nižeg nivoa namenjen programerima drajvera, koji definiše način komunikacije na relaciji JDBC menadžer –drajver konkretnog DBMSa −

- 15 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju slika 5.

Sastavni delovi JDBCa

4.1.1.JDBC API JDBC API u sprezi sa drajverima omogućava Java aplikaciji, apletu ili servletu ostvarivanje konekcije sa konkretnim izvorom podataka, slanje upita i ažuriranje podataka, kao i obrađivanje dobijenih podataka, korišćenjem JDBC interfejsa. −

− − −

Najvažniji interfejsi i klase su: Klasa java.sql.DriverManager koja upravlja učitavanjem drajvera i obezbeđuje podršku za otvaranje konekcija ka bazi podataka. Njegova osnovna funkcija je održavanje liste dostupnih drajvera i učitavanje odgovarajućeg drajvera na osnovu informacija iz URL adrese. Interfejs java.sql.Connection koji predstavlja konkretnu konekciju sa bazom podataka kroz koju se šalju SQL iskazi. Interfejs java.sql.Statement koji se ponaša kao kontejner za izvršavanje SQL upita kroz datu konekciju. Interfejs java.sql.ResultSet koji kontroliše pristup redovima dobijenim kao rezultat SQL upita.

Dva veoma važna podtipa java.sql.Statement interfejsa su PreparedStatement za izvršavanje prekompajliranih SQL iskaza i CallableStatement za izvršavanje poziva procedura iz baze podataka.

slika 6.

Osnovne JDBC klase i interfejsi i njihove međusobne veze

4.1.2.JDBC drajver API JDBC drajver API predstavlja API nižeg nivoa koji interaguje sa mnogobrojnim proizvođačkim drajverima. Drajveri moraju da implementiraju interfejse koje obezbeđuje JDBC drajver API. Konkretno, svaki drajver mora obezbediti implementaciju java.sql.Connection, java.sql.Statement, java.sql.PreparedStatement, java.sql.CallableStatement i java.sql.ResultSet. Dodatno, svaki proizvođački drajver baze podataka treba da obezbedi klasu koja implementira java.sql.Driver interfejs, koji se koristi od strane java.sql.DriverManager klase u procesu pronalaženja odgovarajućeg drajvera za bazu podataka iz konkretne URL adrese, prilikom uspostavljanja konekcije.

- 16 -


4.2.Tipovi JDBC drajvera Danas postoji četiri tipa JDBC drajvera u upotrebi: Tip 1: JDBC – ODBC most JDBC – ODBC most, razvijen sredinom 1996. godine od strane Sun-a i Intersolv-a, prevodi sve JDBC pozive u odgovarajuće ODBC pozive i prosleđuje ih ODBC drajveru koji zatim obavlja povezivanje na traženu bazu podataka. Drajver tipa JDBC-ODBC mosta omogućava pristup gotovo svakoj relacionoj bazi podataka, obzirom da ODBC drajveri već postoje, te je koristan u kompanijama koje već imaju instalirane ODBC drajvere na klijentskim računarima. ODBC drajver se u ovom slučaju ponaša kao posrednik između JDBCa i nativnih biblioteka proizvođača DBMSa. JDBC - ODBC most drajver je obezbeđen od strane Sun-a, u okviru J2SE. Ovakav tip drajvera je platformski zavisan, obzirom da koristi ODBC interfejs koji je po svojoj prirodi namenjen Windows okruženju. Loša strana ovakvog rešenja jeste degradacija performansi, obzirom da JDBC pozivi prolaze kroz most do ODBC drajvera a zatim do nativnog interfejsa za povezivanje sa bazom. Rezultati se vraćaju obrnutim redosledom. Imajući na umu problem performansi, drajveri tipa 1 nisu pogodni za aplikacije koje moraju dobro skalirati. Ovakva rešenja generalno zahtevaju instalaciju dodatnog softvera na klijentskoj strani, uključujući ODBC drajver i nativni interfejs, što ograničava upotrebljivost JDBC-ODBC most drajvera u Internet okruženju. Takođe, nisu podržane sve mogućnosti Java jezika i programer je ograničen funkcionalnošću ODBC drajvera u upotrebi. Tip 2: Nativni API / delimično Java-baziran drajver JDBC drajver drugog tipa konvertuje JDBC pozive u pozive specifične za određeni DBMS (npr. SQL Server, Oracle ili Sybase). Performanse su znatno bolje nego kod JDBC – ODBC mosta usled korišćenja nativnih biblioteka, čime je izbegnut dodatni overhead koji je prisutan u slučaju prevođenja između JDBC i ODBC poziva. Kao i kod prvog tipa, slika 1. JDBC drajveri prvog (leva grana) nedostatak je što na klijentskoj strani mora biti i drugog tipa (desna grana) instaliran dodatni softver u cilju direktne komunikacije klijnta sa serverom baze podataka, što ograničava upotrebljivost ovog tipa drajvera u Internet okruženju. Ovaj tip drajvera je sporiji od drajvera trećeg i četvrtog tipa.

- 17 -


Tip 3: Mrežni protokol / potpuno Java-baziran drajver JDBC drajver trećeg tipa koristi troslojnu arhitekturu gde JDBC pozivi putuju mrežom do servera srednjeg sloja, putem nezavisnog mrežnog protokola, koji ih zatim, direktno ili indirektno, prevodi u nativne pozive servera baze podataka. Ukoliko je server srednjeg sloja pisan u Javi, tada se u svrhe prevođenja može koristiti JDBC drajver prvog ili drugog tipa. Pošto je ovaj tip drajvera server-baziran, nema potrebe za dodatnim kodom na klijentskoj strani. Isti JDBC drajver se može koristiti za više različitih relacionih baza podataka, a njihov broj zavisi od broja podržanih drajvera od strane servera srednjeg sloja (najčešće je u pitanju aplikacioni server). Drajveri trećeg tipa su u većini slučajeva platformski nezavisni, obzirom da se platformske razlike mogu prevazići na srednjem sloju. Tipično su podržani različiti načini optimizacije performansi, na primer keširanje i balansiranje opterećenja, kao i sigurnosni servisi - autentifikacija i praćenje događaja, koji su nepohodni za upotrebu ovog tipa rešenja preko Interneta. Heterogenost DBMSova se prevazilazi na srednjem sloju, što znači da konkretan server srednjeg sloja mora implementirati drajvere za svaki podržani DBMS. Upotreba trećeg tipa JDBC drajvera je pogodna u okruženju koje treba da omogući povezivanje na relacione baze podataka različitih proizvođača, kao i efikasno konkurentno korišćenje od strane velikog broja korisnika. Tip 4: Nativni protokol / potpuno Java-baziran drajver Drajver ovog tipa konvertuje JDBC pozive u DBMS-specifične pozive omogućavajući na taj način klijentskoj aplikaciji da direktno komunicira sa serverom baze podataka. Ovaj tip drajvera je slika 2. JDBC drajveri trećeg (leva platformski nezavisan, obzirom da je potpuno napisan grana) i četvrtog tipa (desna u Javi, a instalira se unutar Java virtualne mašine na grana) klijentskoj strani. Upravo četvrti tip JDBC drajvera je danas najpopularniji, jer koristi JIT (Just-In-Time) kompilaciju, te se njihove performanse mogu meriti sa performansama drugog tipa drajvera, koji koristi nativne biblioteke. Ovo je najbrži i najefikasniji tip drajvera, ali zahteva da proizvođači DBMSova obezbede implementaciju JDBC APIa.

4.3.Verzije JDBC predstavlja jedan od osnovnih Java API interfejsa, koji se uglavnom koristi za razvoj višeslojnih klijent-server, kao i Web orijentisanih aplikacija nad relacionim bazama podataka. Danas se razvija pod vođstvom JCP2 (Java Community Process) organizacije, u koju su uključeni mnogi proizvođači RDBMS sistema.

4.3.1.JDBC 1.0 Sun je objavio JDBC 1.0 API specifikaciju u februaru 1996. godine, kao deo JDK 1.1. U ovoj inicijalnoj verziji podržani su interfejsi potrebni za kreiranje instance drajvera u okviru Java aplikacije, definisanje SQL iskaza i prihvatanje rezultata putem ResultSet objekta. JDBC 1.0 je usklađen sa ANSI SQL2 standardom.

2

JCP – http://www.jcp.org - 18 -


Sa porastom broja Java aplikacija, pokazali su se i nedostaci prve verzije JDBCa. Na primer, prilikom pregleda zapisa dobijenih kao rezultat upita, jedini podržan smer navigacije bio je unapred.

4.3.2.JDBC 2.0 Objavljivanje JDBC 2.0 API specifikacije usledilo je 1998. godine, od strane partnerske kompanije Sun-a, pod nazivom JavaSoft. Sama specifikacije razdvojena je na dva dela: JDBC 2.0 Core API (definisan u okviru paketa java.sql) i JDBC 2.0 Standard Extension API (definisan u okviru paketa javax.sql). Verzija JDBC 2.0 je kompatibilna sa prethodnom verzijom JDBC APIa. JDBC 2.0 Core API se nalazi u sastavu JDK 1.2, i u pogledu novih mogućnosti koje pruža, najvažnije su: − Pomerajući kursor (scrollable) - moguća je navigacija unapred i unazad kroz skup zapisa, kao i apsolutno i relativno pozicioniranje u odnosu na tekući zapis; − Ažuriranje zapisa pomoću ResultSet metoda za ažuriranje (u verziji JDBC 1.0 ažuriranje se obavljalo definisanjem odgovarajućeg SQL iskaza); − Podrška naprednim tipovima podataka u skladu sa ANSI SQL3 standardom (BLOB Binary Large OBject, CLOB - Character Large OBject, ARRAY, STRUCT, REF); − Grupno ažuriranje (batch updates) - aplikaciji je omogućeno višestruko ažuriranje (insert, update, delete) putem jednog zahteva bazi podataka, pomoću metoda Statement.addBatch(), Statement.executeBatch(), Statement.clearBatch(). Grupnim ažuriranjem se znatno poboljšavaju performanse. JDBC 2.0 Standard Extension API dodatno uvodi: − DataSource interfejs kao jednostavan način povezivanja na bazu podataka putem imena objekta koji predstavlja konkretan izvor podataka. JNDI servis (Java Naming and Directory Interface) se koristi za registrovanje DataSource objekta sa servisom imena; − Skladištenje konekcija (connection pooling); − Podršku distribuiranim transakcijama korišćenjem standardnog 2PC (2-Phase Commit) transakcionog protokola, putem XADataSource interfejsa.

4.3.3.JDBC 3.0 Aktuelna verzija JDBC specifikacije objavljena je 2002. godine. Oba paketa, java.sql i javax.sql uključena su u Java 1.4 platformu. Zadržana je kompatibilnost sa aplikacijama i drajverima koji su pisani oslanjajući se na prethodne verzije JDBCa. Sa rastućom popularnošću J2EE, težnja je usmerena na povećanje skalabilnosti JDBCa, koja se ogleda u unapređenju skladištenja konekcija i iskaza. Tokom razvoja JDBC 2.0 specifikacije, SQL3 standard još uvek nije bio u potpunosti konkretizovan. Do momenta objavljivanja JDBC 3.0 verzije, standard SQL3 je završen, te je u potpunosti implementiran u okviru JDBC 3.0. Neke od dodatih mogućnosti JDBC 3.0 APIa su sledeće: Međutačke unutar transakcije (savepoints) - Savepoint interfejs obezbeđuje bolju kontrolu izvršenja transakcije, uvodeći pojam međutačaka kojima je moguće transakciju podeliti na logičke celine. U slučaju potrebe za odbacivanjem promena koje je izvršila transakcija, moguće je definisati do koje međutačke treba izvesti poništavanje, umesto odbacivanja cele transakcije; − Automatski generisani ključevi - većina relacionih baza podataka obezbeđuje funkciju automatsko generisanih vrednosti ključeva za željene kolone. JDBC 3.0 obezbeđuje metode za pristupanje ovim vrednostima; − Unapređenje podrške SQL3 tipovima podataka - dodata su dva nova tipa DataLink i Boolean. Takođe, omogućeno je ažuriranje SQL3 tipova podataka direktno iz zapisa dobijenih kao rezultat upita. −

- 19 -


4.3.4.JDBC 4.0 Najnovija verzija JDBC specifikacije trenutno je u formi ranog nacrta definisanog dokumentom JSR 2213. Osnovni prioritet nove verzije jeste lakše i jednostavnije korišćenje JDBC APIa, što znači povratak na osnovne principe prve JDBC specifikacije – obezbeđivanje skupa jednostavnih apstrakcija za programere koji rade sa relacionim bazam podataka. Takođe, verzija 4 pruža podršku SQL3 tipovima podataka, uključujući Java-specifično mapiranje za nove XML SQL tipove. Novi standard uključuje i podršku za nacionalne karakter-setove, i teži ka poboljšanju performansi JDBC implementacija dajući alatima više informacija o stanju konekcija na bazu podataka i SQL iskazima.

4.4.Povezivanje na bazu podataka U sklopu JDBCa, postoje dva načina ostvarivanja konekcije, od kojih prvi pristup koristi Driver interfejs. Kada se pristupa bazi podataka, koristi se objekat tipa java.sql.Connection pomoću java.sql.DriverManager.getConnection() metode, u

okviru JDBC menadžment sloja. Metoda java.sql.DriverManager.getConnection() uzima URL (Uniform Resource Locator) adresu kao string argument. JDBC menadžment sloj će tada pokušati da locira odgovarajući drajver kako bi omogućio povezivanje na bazu iz URL adrese, prozivajući jedan po jedan drajver. Drajver proverava da li je u URL adresi naveden podprotokol koji on podržava i ako je to slučaj, pokušava da se poveže na bazu. Kada uspostavi konekciju, drajver vraća odgovarajući java.sql.Connection objekat. U slučaju da je povezivanje na određenu bazu moguće izvesti pomoću više drajvera, JDBC će odabrati prvi u listi drajvera koji ispunjava potrebne uslove. Takođe, moguće je i ručno specificirati drajver koji će se koristiti. Kada se otvara konekcija sa bazom, moguće je ručno proslediti parametre konekcije kao što su na primer korisničko ime i šifra. Parametri se mogu definisati i u java.util.Properties objektu, što je prikazano u sledećem primeru: java.util.Properties props = new java.util.Properties(); props.put("user","scott"); props.put("password","tiger"); props.put("defaultRowPrefetch","30"); Connection con=DriverManger.getConnection("jdbc:oracle:thin: @host",props);

Primer konektovanja na bazu Fred pomoću JDBC-ODBC most drajvera: String url = "jdbc:odbc:Fred"; Connection con = DriverManager.getConnection(url, Login", "Password");

Metoda DriverManager.getConnection() vraća otvorenu konekciju u objekat con, koji se dalje koristi za kreiranje JDBC iskaza kroz koje putuju SQL upiti do DBMSa.

4.4.1.JDBC URL adresa Struktura JDBC URL adrese je sledeća: jdbc::, gde podprotokol predstavlja konkretan mehanizam povezivanja na određenu bazu podataka, a koji može biti podržan od strane više drajvera. Komponente i sintaksa imena baze zavise od vrste podprotokola u upotrebi.

3

Java Specification Requests 221: JDBC 4.0 API - http://www.jcp.org/en/jsr/detail?id=221 - 20 -


Baza podataka ODBC izvor podataka MySQL Oracle

tabela 3.Primeri JDBC URL adresa JDBC URL jdbc:odbc:DATA_SOURCE_NAME jdbc:mysql://SERVER[:PORT]/DATABASE_NAME jdbc:oracle:thin:@SERVER:PORT:INSTANCE_NAME

4.4.2.Registracija drajvera JDBC menadžment sloj mora znati koji su drajveri na raspolaganju, a registracija drajvera može se izvesti na dva načina. Prvo, JDBC java.sql.DriverManager klasa će u toku inicijalizacije pokušati da pristupi sql.drivers svojstvu. Ukoliko postoji, sql.drivers treba da sadrži listu klasa svakog od dostupnih drajvera, a svaka od njih treba da implementira java.sql.Driver interfejs. DriverManager će zatim pokušati da učita navedene drajvere. Drugi način jeste ručno učitavanje od strane programera eksplicitnim navođenjem imena klase željenog drajvera, pomoću standardne Class.forName() metode. Većina drajvera se automatski registruje prilikom učitavanja neke njihove klase. Na primer, registracija JDBC-ODBC most drajvera može se izvesti na sledeći način: Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

4.4.3.DataSource interfejs Sa JDBC 2.0 verzijom, uveden je interfejs DataSource kao još jedan način ostvarivanja konekcije sa bazom, a u verziji 3.0 deo je standardnog paketa. JDBC drajver koji implementira DataSource interfejs vraća konekciju koja implementira identični interfejs – Connection, kao i onaj koji vraća DriverManager korišćenjem Driver interfejsa. Korišćenje DataSource interfejsa je preferirani način konektovanja na bazu, obzirom da povećava portabilnost aplikacije tako što samoj aplikaciji omogućava da koristi logičko ime za izvor podataka umesto navođenja informacija specifičnih za drajver određene baze. Logičko ime se mapira u DataSource objektu pomoću servisa imena koji koristi JNDI. Objekat DataSource reprezentuje fizički izvor podataka i obezbeđuje konekcije ka istom. JNDI servis oslobađa programera potrebe da unosi kompletnu URL adresu prilikom povezivanja na bazu, kao i obaveze da ručno menja URL string na svakom mestu u aplikaciji gde se radi sa bazom. Interfejs DataSource pruža i dodatne prednosti: povećana efikasnost i bolja skalabilnost korišćenjem ConnectionPoolDataSource objekta, − podrška distribuiranim transakcijama kroz XADataSource interfejs. −

Implementaciju DataSource interfejsa obavlja proizvođač tako što kreira klasu koja implementira ovaj interfejs, a zatim je poveže na JNDI stablo, što pokazuje sledeći primer: DataSourceImpl dsi = new DataSourceImpl(); dsi.setServerName("oracle10g"); dsi.setDatabaseName("Demo"); Context ctx = new InitialContext(); ctx.bind("jdbc/demoDB", dsi);

Zatim programer može jednostavno pronaći odgovarajući DataSource objekat, bez poznavanja tehnologije koja se krije iza njega: Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("jdbc/demoDB"); Connection con = ds.getConnection(); - 21 -


4.5.Definisanje i izvršavanje naredbi Objekat Statement šalje SQL naredbe do DBMSa. Nakon kreiranja samog objekta, potrebno je izvršiti ga, odgovarajućom metodom u skladu sa SQL naredbom. U slučaju SELECT upita, odgovarajuća metoda je executeQuery() koja kao rezultat vraća objekat ResultSet, dok je u slučaju SQL naredbi koje kreiraju, ažuriraju ili brišu tabele, odgovarajuća metoda executeUpdate(). Da bi se kreirao Statement objekat potrebna je jedna instanca aktivne konekcije. Sledećim kodom predstavljeno je kreiranje objekta stmt korišćenjem Connection objekta con: Statement stmt = con.createStatement();

Dalje je potrebno snabdeti metodu koja će izvršiti objekat stmt potrebnim SQL kodom: stmt.executeUpdate("DELETE * FROM RADNIK WHERE IME="MILENA" ");

4.5.1.Rezultati naredbi JDBC rezultat izvršavanja SELECT naredbe koji predstavlja set redova smešta u ResultSet objekat. Neophodno ga je najpre kreirati kao instancu istoimene klase. ResultSet rs = stmt.executeQuery("SELECT * FROM RADNIK");

Metode ResultSet.next() i ResultSet.previous() omogućavaju kretanje kroz set redova, odnosno pomeranje kursora. Sa JDBC API 2.0 verzijom postoji i mogućnost definisanja “pomerajućeg” kursora (scrollable), što omogućava direktan pristup bilo kom redu, na primer: rs.absolute(3); rs.relative(2); rs.relative(-3);

// pomera na treći red // pomera za dva reda unapred (peti red) // pomera za tri reda unazad (drugi red)

Klasa ResultSet obezbeđuje i nekoliko korisnih metoda za utvrđivanje pozicije: isFirst(), isLast(), isBeforeFirst(), isAfterLast() i getRow(). Takođe, moguće je odabrati da li će se kursor koristiti samo u režimu čitanja ili će imati mogućnost ažuriranja, pomoću opcija CONCUR_READ_ONLY i CONCUR_UPDATABLE. Interfejs ResultSet obezbeđuje brojne metode za ažuriranje (results.updateXXX), nakon čijeg poziva je potrebno potvrditi ili poništiti promene pomoću updateRow(), odnosno cancelRowUpdates() metode. Pristupanje kolonama moguće je preko indeksa kolone, što predstavlja efikasniji način, kao i pomoću imena kolone. Postoji niz “get” metoda pomoću kojih se pristupa određenim kolonama iz reda. Metode ResultSet.getXXX() će pokušati da konvertuju tip podatka dobijenog kao rezultat SQL naredbe, u odgovarajući Java tip podatka. Konverzija tipova podataka se vrši na osnovu definisanog prevođenja između SQL i Java podataka. U slučaju da konverzija nije uspešna (npr. pokušaj dobijanja podatka SQL tipa VARCHAR metodom getInt()), javiće se SQL poruka o grešci (SQLException).

4.5.2.Parametrizovane naredbe Ukoliko je neki Statement objekat potrebno izvršavati više puta, pogodno je umesto njega koristiti PreparedStatement objekat čime se smanjuje vreme izvršavanja upita. Osnovna osobina PreparedStatement objekta je što je njemu, za razliku od Statement objekta, SQL kod dodeljen u procesu kreiranja. U većini slučajeva SQL kod se odmah šalje DBMSu gde se kompajlira. Kao rezultat, objekat sadrži ne samo SQL kod, već - 22 -


prekompajliran SQL iskaz, odnosno SQL iskaz u izvršnom obliku. Na ovaj način, u trenutku kada je potrebno izvršiti određeni objekat ovog tipa, DBMS ne mora da ga kompajlira, već samo da ga pokrene. Iako se PreparedStatement objekti mogu koristiti i za SQL iskaze koji ne primaju parametre, njihova glavna upotreba jeste upravo za parametarske SQL iskaze. Kreiranje objekata identično je kao i kod Statement objekata. Pre izvršavanja objekta, potrebno je postaviti parametre, pozivanjem neke od setXXX() metoda definisanih u klasi PreparedStatement. Prednost parametarskih SQL naredbi jeste upravo u tome što se isti SQL kod može koristiti više puta, uz postavljanje novih vrednosti parametara. Primer korišćenja parametrizovanih naredbi: PreparedStatement updateSales = con.prepareStatement( "UPDATE RADNIK SET PLATA = ? WHERE IME LIKE ? "); updateSales.setInt(1, 30000); updateSales.setString(2, "Vlada"); int n = updateSales.executeUpdate(); // n - broj ažuriranih redova

4.5.3.Procedure Grupa SQL iskaza koji formiraju logičku celinu i izvršavaju određeni zadatak čini proceduru. Procedure se koriste u cilju enkapsulacije skupa operacija ili upita koje je potrebno izvršiti na serveru baze podataka i mogu vraćati jednu ili više vrednosti. Primer Oracle PL/SQL procedure koja prima dva ulazna parametra, šifre radnika i plate, vraća ažuriranu platu za datog radnika: CREATE OR REPLACE PROCEDURE sp_plata (id IN INTEGER p_plata IN OUT FLOAT) IS BEGIN SELECT plata INTO p_plata FROM radnik WHERE radnik_id = id; p_plata := p_plata * 1.3; UPDATE radnik SET plata = p_plata WHERE radnik_id = id; END;

JDBC interfejs koji podržava procedure zove se CallableStatement. Klasa Connection obezbeđuje metodu PrepareCall(), slično prepareStatement() metodi koju koristimo kada kreiramo PreparedStatement objekat. Obzirom da svaka baza podataka poseduje sopstvenu specifičnu sintaksu za pristupanje procedurama, JDBC definiše standardnu sintaksu pomoću interfejsa CallableStatement, dok JDBC drajver upravlja prevođenjem sintakse. Primer pozivanja procedure sp_plata: CallableStatment cstmt = con.prepareCall("{call sp_plata(?,?)}"); cstmt.registerOutParameter(2, Types.FLOAT); cstmt.setInt(1, radnik_id); cstmt.setFloat(2, 20000); cstmt.execute(); out.println("Nova plata:" + cstmt.getFloat(2));

4.6.Transakcije Transakcija predstavlja grupu SQL instrukcija i obezbeđuje njihovo izvršavanje kao da se radi o jednoj nedeljivoj operaciji. Rad sa transakcijama uključuje sledeće korake: - 23 -


započinjanje transakcije, izvođenje njenih operacija, a zatim potvrđivanje transakcije ako su se sve njene operacije uspešno izvršile, ili povratak na prethodno stanje, ako je makar jedna operacija transakcije izvršena neuspešno. Objekat Connection je odgovoran za upravljanje transakcijama. Sa JDBCom, transakcije su uvek u upotrebi, na neki način. Svaka nova konekcija se kreira sa podrazumevanim auto-commit načinom rada, što znači da će se svaka SQL instrukcija izvršavati kao individualna transakcija koja se automatski potvrđuje. Da biste izvršili transakciju koja se sastoji iz više SQL instrukcija, potrebno je pozvati setAutoCommit() metodu i proslediti joj argument false. Zatim, nakon izvršenja transakcije, potrebno je pozvati commit()ili rollback() metodu, za potvrdu, odnosno

poništenje rezultata transakcije. JDBC podržava nekoliko nivoa izolacije koji omogućavaju kontrolu pristupa podacima od interesa tokom izvršavanja transakcije. Više nivoe izolacije karakteriše veća sigurnost, ali i slabije performanse. Interfejs Connection nudi pet standardnih nivoa izolacije: − TRANSACTION_NONE – Transakcije nisu podržane ili su isključene. − TRANSACTION_READ_UNCOMMITTED – Tokom obrade, podaci su vidljivi drugim transakcijama, pre potvrde same transakcije. U slučaju poništavanja transakcije, druge transakcije mogu imati problem poznat kao “nečista čitanja” (dirty read), jer su pristupale podacima nad kojima je prvo izvršena, a zatim poništena promena. − TRANSACTION_READ_COMMITTED – Nije dozvoljeno čitanje podataka nad kojima još nisu potvrđene promene koje je izvela transakcija. − TRANSACTION_REPEATABLE_READ – Pretpostavimo da jedna transakcija pročita red koji nakon toga promeni i potvrdi druga transakcija. Ukoliko prva transakcija ponovo pročita isti red, neće videti promenu koju je izvela druga transakcija. Novi podatak će biti vidljiv prvoj transakciji tek nakon što potvrdi svoje promene, čime se rešava problem poznat kao “neponovljiva čitanja” (nonrepeatable read). − TRANSACTION_SERIALIZABLE – Obezbeđene su sve osobine prethodnog nivoa, uz dodatu zaštitu od tzv. “fantomskih redova” (fantoms). Recimo da jedna transakcija pročita set redova, a zatim druga transakcija doda jedan red tom setu. Ukoliko prva transakcija ponovo pročita isti set redova, neće videti novi red. Ovo je najrestriktivniji nivo izolacije koji onemogućava konkurentno izvršavanje transakcija. Nivo izolacije transakcija podešava se pomoću metode setTransactionIsolation(). Na primer: con.setTransactionIsolation(TRANSACTION_READ_COMMITTED);

Za utvrđivanje transakcione podrške baze u upotrebi, u okviru DatabaseMetaData interfejsa obezbeđene su metode: − getDefaultTransaction-Isolation(), koja kao rezultat vraća celobrojnu vrednost koja predstavlja podrazumevani nivo izolacije u konkretnoj bazi podataka; − supportsTransactions(), koja vraća vrednost true ili false, u slučaju da baza podržava, odnosno ne podržava transakcije; − supportsTransactionIsolationLevel() je metoda čiji parametar predstavlja izolacioni nivo čija se podrška ispituje, povratna vrednost true znači da je navedeni nivo podržan, false da nije. JDBC 3.0 API uvodi pojam međutačaka unutar transakcije. Kada se jednom postavi međutačka (savepoint), transakcija se može poništiti do te tačke bez uticaja na rad koji joj je prethodio, odnosno, metoda rollback() će sačuvati sve akcije transakcije do međutačke, i poništiti sve akcije posle međutačke. Metoda za postavljanje međutačaka je con.setSavepoint(). Moguće je postaviti više međutačaka, kao i uklanjati ih metodom con.releaseSavepoint(), kojoj se kao argument prosleđuje ime željene međutačke. - 24 -


slika 7.

Poništavanje promena transakcije do željene međutačke

4.7.Implementacije JDBC drajvera Postoji preko 200 JDBC drajvera za komercijalne i otvorene DBMS produkte. Implementaciju JDBC specifikacije sprovode. kako proizvođači DBMS sistema, tako i nezavisni proizvođači JDBC drajvera. Prva odluka koju treba doneti prilikom odabira odgovarajućeg JDBC drajvera vezana je za tip drajvera, u skladu sa konkretnim okruženjem u upotrebi. Dalje, potrebno je ustanoviti nivo usklađenosti sa aktuelnom verzijom JDBC specifikacije, kao i kompatibilnost sa J2EE platformom, ukoliko je to od značaja. Pregled dostupnih JDBC drajvera može se naći na sajtu Sun-a4, a neki od njih su navedeni u nastavku.

4.7.1.Oracle Sa Oracle 10.1.0 verzijom, Oracle JDBC drajveri u potpunosti implementiraju JDBC 3.0 specifikaciju, sa izuzetkom automatski generisanih ključeva, i vraćanja višestrukih skupova redova. Oracle obezbeđuje četiri različita tipa JDBC drajvera5: 1. Klijentski JDBC OCI drajver – pripada drugom tipu JDBC drajvera i koristi Java nativne metode za pozive C biblioteci. Dotična C biblioteka naziva se OCI (Oracle Call Interface) i služi za interakciju sa Oracle bazom podataka. JDBC OCI drajver zahteva instalaciju na klijentskoj strani. Upotreba nativnih metoda čini JDBC OCI drajver platformski specifičnim. Oracle podržava Solaris, Windows i mnoge druge platforme. Ipak, ovaj drajver nije pogodan za Java aplete, obzirom da se oslanja na C biblioteku. 2. Klijentski JDBC Thin drajver – pripada četvrtom tipu JDBC drajvera koji potpuno napisan u Java jeziku i direktno komunicira sa Oracle bazom podataka. On implementira Net8 i TTC adaptere koristeći sopstvenu, TCP/IP baziranu implementaciju Java soketa. Sa JDBC Thin drajverom nije potrebna instalacija na klijentu, ali je neophodno da server bude konfigurisan sa TCP/IP osluškivačem (listener). Pošto je potpuno implementiran u Java jeziku, ovaj drajver je platformski nezavisan. JDBC Thin drajver može biti preuzet od strane bilo kog Web čitača, kao deo Java aplikacije, i jedini je pogodan Oracle drajver za Java aplete. 3. Serverski JDBC Thin drajver – još jedan drajver četvrtog tipa koji se direktno povezuje na Oracle bazu podataka i koristi se interno od strane baze. Ovaj drajver nudi istu funkcionalnost kao i klijentski JDBC Thin drajver, ali se izvršava u okviru Oracle baze i koristi se za komunikaciju sa udaljenim bazama podataka. 4. Serverski JDBC interni drajver – predstavlja drugi tip JDBC drajvera koji koristi C biblioteku. C biblioteka je deo Oracle serverskog procesa i komunicira direktno sa bazom. Drajver pristupa bazi korišćenjem internih funkcijskih poziva, čime je izbegnut svaki mrežni saobraćaj. Ovim je omogućeno java programu, koji se izvršava na serveru, da pristupa bazi podataka na najbrži mogući način. Usled upotrebe nativnih metoda, serverski JDBC Thin drajver je platformski zavisan.

4 5

Pregled dostupnih JDBC drajvera - http://developers.sun.com/product/jdbc/drivers Oracle JDBC drajveri - http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm - 25 -


4.7.2.MySQL MySQL omogućava povezivanje klijentskih Java aplikacija putem JDBC drajvera, koji se zove MySQL Connector/J 6. Ovaj drajver pripada četvrtom tipu JDBC drajvera i implementira verziju 3.0 JDBC specifikacije, komunicirajući direktno sa MySQL serverom korišćenjem MySQL protokola. Postoje tri verzije MySQL Connector/J drajvera, od kojih je najnovija Connector/J 5.0. Ova verzija u potpunosti podržava funkcionalnost MySQL 5.0, a od prethodne verzije se razlikuje po tome što implementira interfejs za podršku distribuiranim transakcijama (XA).

4.7.3.DataDirect DataDirect je nezavisan proizvođač JDBC drajvera (većinom četvrtog tipa) za različite relacione baze podataka, uključujući DB2, Sybase, Informix, Oracle i Microsoft SQL Server. DataDirect Connect for JDBC7 drajveri u potpunosti implementiraju JDBC 3.0 specifikaciju i kompatibilni su sa J2EE platformom. Pored JDBC drajvera četvrtog tipa, DataDirect nudi i drajver trećeg tipa, DataDirect SequeLink.

6 7

MySQL Connector/J - http://dev.mysql.com/doc/refman/5.0/en/connector-j.html DataDirect JDBC drajveri - http://www.datadirect.com/products/jdbc/index.ssp?se=javasun - 26 -


5. SQLJ Konzorcijum više organizacija (Oracle, IBM i Sun) predstavio je 1997. godine sprecifikaciju pod nazivom SQLJ (SQL for Java), koja predstavlja produžetak ISO/ANSI standarda za ugrađeni SQL (Embeded SQL), pošto je isti do tada pružao podršku za jezike C, Fortran, COBOL, ADA, Pascal. SQLJ je razvijen kako bi dopunio dinamički JDBC SQL model statičkim SQL modelom. Kombinovanje naredbi jezika treće generacije i SQL-a omogućava, s jedne strane korišćenje proceduralnih karakteristika jezika treće generacije (sekvenca, iteracija, procedura, podprogram), a sa druge strane pristup podacima u bazi podataka pomoću SQLa. Pošto ugrađeni SQL čini mešavinu SQL naredbi i naredbi host jezika, neophodan je pretprocesor koji iz aplikacionog programa “izvlači“ SQL naredbe i prevodi u pozive funkcija. Kao rezultat pretprocesora dobija se kod u izvornom programskom jeziku koji se kompajlira i linkuje sa SQL bibliotekom koja sadrži implementaciju pozvanih funkcija. Pretprocesor vrši proveru sintakse za SQL naredbe, proveru tipova u odnosu na bazu da bi se osigurala kompatibilnost podataka koji se razmenjuju između host jezika i SQL-a. Zbog toga što su SQL naredbe poznate u vreme pretprocesiranja može se vršiti i parsiranje naredbi pa se ovakav način korišćenja SQL-a naziva statički SQL. SQLJ specifikacija sastoji se iz tri dela: Ugrađeni SQL – podrška statičkom SQL kodu unutar Java programa. Dinamički SQL kod nije podržan, i ukoliko je potreban, JDBC upravlja njegovim izvršavanjem. Prvim delom definisano je kombinovanje ugrađenih statičkih SQL iskaza sa JDBC iskazima. Mapiranje Java i SQL tipova podataka je identično kao u JDBC specifikaciji. 2. SQL rutine – omogućeno je pozivanje Java metoda iz SQL koda. Java metode obezbeđuju implementaciju SQL procedura. U cilju podrške ovog dela SQLJ specifikacije, DBMS mora biti povezan sa Java virtuelnom mašinom (JVM). Drugi deo bavi se iskljičivo statičkim SQL iskazima. Kako bi se Java metode i SQL funkcije mogle povezati, mora biti moguće odgovarajuće mapiranje između svakog SQL i Java parametra, kao i između SQL i Java povratnih podataka. 3. SQL tipovi – definisane su SQL ekstenzije za korišćenje Java klasa kao SQL tipova podataka. Omogućeno je mapiranje SQL3 UDT (User Defined Types) tipova podataka u Java klase. Struktuirani tipovi podataka su pridruženi klasama, atributi poljima, a inicijalizatori konstruktorima. Deo ili celokupna hijerarhija SQL tipova podataka može se predstaviti hijerarhijom Java klasa. 1.

Mnoge aplikacije koriste SQL iskaze koji su fiksni , tj. statički. Sa statičkim SQL programiranjem, svi SQL iskazi su prisutni pre izvršavanja koda, što znači da su imena kolona, tabela, broj kolona u tabeli - unapred poznati. SQLJ predstavlja jezik koji omogućava umetanje statičkog SQL koda unutar Java aplikacija direktno, bez korišćenja string objekata. SQLJ pruža dodatne prednosti, time što proverava SQL sintaksu pre nego što počne izvršavanje samog programa. Zatim, SQLJ prevodilac (pretprocesor) konvertuje SQLJ program u standardan Java program tako što zamenjuje ugrađeni SQL kod pozivima SQLJ izvršnoj biblioteci. Generisani Java kod je tada spreman za kompajliranje bilo kojim standardnim Java kompajlerom, nakon čega može komunicirati sa bazom podataka. SQLJ okruženje sastoji se od thin SQLJ izvršne biblioteke (bez overhead-a) koja je potpuno implementirana u Java jeziku i koja prosleđuje pozive odgovarajućem JDBC drajveru. − − −

Funkcije SQLJ prevodioca su: provera sintakse ugnježdenog SQL koda; provera Java i SQL tipova podataka; provera relacione šeme.

- 27 -


slika 8.

Tok izvršavanja SQLJ koda

5.1.Poređenje JDBC i SQLJ pristupa SQLJ je baziran na statičkom ugnježdenom SQLu, dok JDBC koristi dinamički SQL. Stoga, SQLJ pruža statičku analizu za proveru sintakse, proveru šeme i proveru tipova, što pomaže u razvoju pouzdanijih programa uz gubitak nešto funkcionalnosti i fleksibilnosti. Takođe, moguće je dozvoliti DBMSu da generiše strategiju izvršavanja upita, čime se poboljšava performantnost upita. JDBC, budući da je baziran na dinamičkom SQLu, dozvoljava pozivajućem programu da obrazuje SQL kod u vreme izvršavanja. Za razliku od JDBCa koji predstavlja API specifikaciju, SQLJ je zapravo proširenje SQL jezika. SQLJ programi se moraju izvršavati kroz pretprocesor (SQLJ prevodilac) pre kompajliranja. JDBC u suštini prestavlja srednji sloj nižeg nivoa koji pruža osnovnu funkcionalnost vezano za pristup Java aplikacija relacionim bazama podataka. Korišćenjem JDBCa, programeri treba da izrade nacrt relacione šeme u koju će prevoditi Java objekte. Zatim, kako bi upisali Java objekte u bazu podataka, moraju da napišu kod kojim će povezati Java objekte sa odgovarajućim redovima odgovarajućih relacija. Slična procedura prisutna je u obrnutom smeru prilikom čitanja Java objekata iz baze podataka. Ovakav način pristupa sadrži dobro poznate probleme programera: − neophodna svest o dve različite paradigme (objektna i relaciona); − neophodan nacrt relacione šeme kako bi se ista uklopila u objektni dizajn; − neophodnost pisanja koda koji će povezivati ove dve paradigme, koji izaziva usporenje aplikacije, sklon je greškama, i težak za održavanje tokom evolucije sistema. tabela 4.Pregled JDBC i SQLJ razlika JDBC Dinamički SQL CLI interfejs (API) Prekompajliranje i vezivanje nisu potrebni Provera sintakse prilikom izvršavanja Provera autorizacije prilikom izvršavanja Autorizacioni model baziran na korisniku Standardan deo Java platforme

SQLJ Statički SQL Ugnježdeni SQL (jezička ekstenzija) Prekompajliranje neophodno; vezivanje preporučljivo Provera sintakse prilikom prekompilacije Provera autorizacije prilikom vezivanja Autorizacioni model baziran na aplikaciji Nije deo Java platforme, ali je ISO standard

- 28 -


6. Objektno orijentisano programiranje i relacione baze podataka Obzirom da je Java objektno orijentisani programski jezik, podatke ne tretira na isti način kao što to rade relacione baze podataka. Podaci su predstavljeni kao objekti sa svojim atributima, odnosno detaljima o samom objektu. Dok objekat poseduje identitet, stanje i ponašanje pored samih podataka, RDBMS skladišti isključivo podatke. Iz perspektive objektnog dizajna, objekat nije sačuvan – on perzistira. Perzistencija jednog objekta ogleda se u prevođenju objekta u formu pogodnu za skladištenje, pri čemu ostaju sačuvani svi atributi tog objekta i njegove veze sa ostalim objektima, tako da se on može ponovo koristiti na “objektni” način pozivanjem od strane aplikacije. Dakle, perzistencija predstavlja svojstvo objekta koje mu omogućava da “preživi” i nakon zatvaranja procesa, kako bi na transparentan način zadržao iste osobine u slučaju ponovnog pokretanja procesa. Za razliku od objektno orijentisanog modela, relacioni model predstavljaju podatke tabelama i relacijama dok za manipulaciju podacima koriste neproceduralni jezik – SQL. U skladu sa ovim različitostima, postoji očigledno nepodudaranje između objektnog modela Jave i relacionog modela baza podataka. Korišćenje JDBC APIa za premošćavanje ovih razlika može biti dobro rešenje u slučaju manjih projekata, međutim, budući da je JDBC API interfejs nižeg nivoa, on ne pruža dovoljan nivo apstrakcije relacionog modela kada su u pitanju veliki i kompleksni projekti. Sa JDBCom, programer je obavezan da piše kod kojim će prevesti podatke relacionog modela u objektni model, odnosno polja u tabelama u atribute objekata, svaki put kada aplikacija zahteva interakciju sa bazom podataka. U slučaju izmena u tabeli ili samoj bazi podataka, neophodno je izmeniti svaku liniju koda aplikacije koja je u vezi sa izmenama. Takođe, programer je dužan da skup redova, JDBCom dobijenih kao rezultat upita, ručno tumači, imajući na umu njihov tip i vodeći računa o konverziji SQL i Java tipova podataka. Praktičnije i efikasnije rešenje koje se nameće jeste okvir koji će se ponašati kao posrednik između objektnog i relacionog sveta. Proces transformacije relacione paradigme u objektnu poznat je kao objektno-relaciono mapiranje – ORM (Object Relational Mapping). ORM alati vrše automatsko mapiranje na osnovu konfiguracionih fajlova – najčešće XML dokumenata. Konfiguracija mapiranja se vrši samo na jednom mestu, a u slučaju eventualnih izmena – menja se samo konfiguracioni fajl. Kada je potrebno perzistirati neki Java objekat, ORM alat će generisati potreban SQL kod u pozadini na osnovu mapiranja. ORM komponenta sistema se, u cilju većeg nivoa apstrakcije, postavlja iznad JDBC APIa, oslobađajući na taj način programera detalja vezanih za konekciju i tumačenje relacionih podataka. Konfiguracioni parametri se unose jednom, a zatim ORM alat vrši automatsko povezivanje i mapiranje kada je potrebna ineterakcija sa bazom, isporučujući programeru uvek čiste Java objekte. ORM podsistem se tipično sastoji iz tri glavna sloja – objektnog i sloja za pristup podacima, kao i međusloja za mapiranje. Objektni sloj ima interfejse slične kao u slučaju objektno orijentisanih baza podataka, u cilju veće udobnosti i prirodnijeg korišćenja objektno orijentisanih jezika za manipulaciju i čuvanje podataka. U cilju enkapsulacije objektnog koncepta, funkcije objektnog sloja su sledeće: kompleksni objekti, identitet objekta, enkapsulacija, tipovi i klase, hijerarhija klasa i tipova, kasno povezivanje i upitni interfejs. Objektni sloj koristi sloj za pristup podacima kao interfejs ka relacionoj bazi podataka ili XML dokumentima. Funkcije sloja za pristup podacima su: perzistencija podataka, konkurentnost, upitni interfejs, oporavak od grešaka. Na ovom sloju, apstrakcije poput kompleksnih tipova podataka (na primer, grupisanje logički povezanih podataka), nasleđivanja i veza su nevidljive, i one moraju biti implementirane od strane objektnog sloja. Sloj za pristup podacima šalje ili prihvata podatke do, odnosno od RDBMS-a (najčešće - 29 -


posredstvom JDBC APIa, kao industrijskog i opšte prihvaćenog standarda) ili XML dokumenata (putem DOM APIa8). Međusloj za mapiranje na osnovu parametara iz konfiguracionog fajla omogućava prevođenje podataka između relacionog ili hijerarhijskog modela i objektnog. Na slici 13 prikazana su rešenja sa i bez ORM podsistema. Simbolički je prikazano kako ORM sloj programeru pruža viši nivo apstrakcije, oslobađajući ga tako potrebe da tokom pisanja koda uvek vodi računa o različitim paradigmama. Obzirom da Java jezik po svojoj prirodi pripada objektnom domenu, korišćenjem ORMa gubi se neophodnost prevođenja jer se, sa stanovišta programera, ostaje u istom modelu.

slika 9.

Arhitekture sa i bez ORM podsistema

Na sledećim primerima upotrebe osnovnih operacija za rad sa podacima mogu se uočiti prednosti i mane korišćenja JDBC interfejsa i ORM alata kakav je Hibernate. Inicijalizacija konekcije korišćenjem JDBCa: String url = "jdbc:odbc:" + dbName; List radnikList = new ArrayList(); /* učitavanje JDBC-ODBC most drajvera */ class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); /* Otvaranje konekcije sa bazom */ Connection con = DriverManager.getConnection(url);

Inicijalizacija sesije korišćenjem Hibernate-a: /* Učitavanje hibernate konfiguracionog fajla */ Configuration cfg = new Configuration(); cfg.configure("hibernate-configuration.xml");

/* Kreiranje sesije */ SessionFactory sessionFactory = cfg.buildSessionFactory();

/* Otvaranje sesije */ Session session = sessionFactory.openSession();

Dobijanje spiska radnika iz tabele Radnici korišćenjem JDBCa: 8

Document Object Model API - http://www.w3.org/DOM/ - 30 -


/* kreiranje Statement objekta */ Statement stmt = con.createStatement(); /* izvršavanje naredbe */ ResultSet rs = stmt.executeQuery("SELECT * FROM Radnik"); while ( rs.next() ) { Radnik eb = new Radnik (); eb.setIme(rs.getString("ime")); eb.setAdresa(rs.getString("adresa")); eb.setPlata(rs.getFloat("plata")); eb.setRacun(rs.getFloat("racun")); radnikList.add(eb); }

Dobijanje spiska radnika iz tabele Radnik korišćenjem Hibernate-a: /* kreiranje upita */ Query query = session.createQuery("from Radnik");

/* izvršavanje upita i preuzimanje rezultata u formi Java objekata */ List finalList = query.list();

Primer konfiguracionog fajla Radnik.hbm.xml:

U JDBC pristupu primećuje se da je neophodno poznavanje imena kolona i njihovih tipova u momentu pisanja koda. Takođe, te informacije (na primer, getFloat ("plata")) moraju se navoditi na svim mestima gde se pristupa određenom podatku. U slučaju da je došlo do greške u imenu ili tipu kolone, za nju bi se saznalo tek tokom izvršavanja aplikacije. Pri upotrebi ORM rešenja, entiteti iz relacionog modela se predstavljaju klasama, odnosno objektima pomoću mapiranja iz konfiguracionog fajla. Ovakav pristup omogućava nezavisnost koda od imena kolona, kao i detektovanje pogrešne upotrebe tipova prilikom kompajliranja. Evidentna je razlika u opterećenju programera u pogledu dužine koda, kao i razlika u jasnoći i čitljivosti istog. - 31 -


6.1.ORM alati Danas postoji veliki broj ORM alata, uključujući besplatne i komercijalne, Java ili .NET orijentisane. Najpoznatiji od njih su: − Oracle TopLink9– Alat koji obezbeđuje efikasan mehanizam za skladištenje Java objekata i EJB komponenti u relacionim bazama podataka, kao i mehanizam za konverziju između Java objekata i XML dokumenata (JAXB - Java Architecture for XML Binding ). TopLink je originalno razvijen 1990.godine od strane The Object People, a 2002. godine ga je preuzeo Oracle. Aktuelna verzija je Oracle TopLink 10g i besplatna je za preuzimanje. − Hibernate10 – Hibernate predstavlja ORM alat koji obezbeđuje servis za objektno/relacionu perzistenciju, kao i upitne servise. Omogućava programerima da razvijaju perzistentne klase prateći OO paradigmu – uključujući asocijacije, nasleđivanje, polimorfizam, kolekcije. Takođe, Hibernate omogućava definisanje upita putem sopstvenog, portabilnog HQL jezika (Hibernate Query Language), kao i putem nativnog SQL-a. Na taj način, za razliku od mnogih ORM rešenja, Hibernate ne skriva SQL kod od programera, omogućujući mu da bira da li i u kojoj situaciji će koristiti isti. Za pristup relacionim bazama podataka koristi JDBC, te može raditi nad bilo kojom bazom za koju postoji odgovarajući JDBC drajver. Hibernate je razvijen od strane JBoss-a, predstavlja projekat otvorenog koda (open source) i besplatan je za korišćenje. Aktuelna verzija je Hibernate 3.2.2 , a postoji i verzija NHibernate, za .NET Framework - NHibernate 1.0.4. − iBATIS11 – iBATIS je okvir za mapiranje podataka koji olakšava korišćenje relacionih baza podataka od strane Java i .NET aplikacija, korišćenjem XML deskriptora. Razvijen je od strane Apache organizacije. Najnovije verzije su iBATIS Java 2.1.7 i iBATIS .NET DataMapper 1.5.1. − JDO API12 – JDO (Java Data Objects) predstavlja prvu specifikaciju za perzistenciju Java objekata razvijenu od strane Sun Microsystems-a 2002. godine, verzija JDO 1. Mnoga rešenja iz ove oblasti su odabrala da podrže JDO API kao industrijski standard na osnovu čega se može porediti sa ulogom koju igra JDBC API u svom domenu. Verzija JDO 2 objavljena je 2004. godine. Postoje brojne implementacije JDO specifikacije, uključujući otvorena i komercijalna rešenja. Neke od njih su: o JPOX13 – JDO 2 implementacija otvorenog koda; o Eclipse JSR 22014 ORM alat – implementacija EJB 3 i JDO 2 standarda; o Signsoft – intelliBO15 ; o BEA – Kodo JDO16. Naslednik JDO APIa je specifikacija skorijeg datuma pod imenom JPA (Java Persistance API) i deo je trenutno aktuelnog rešenja za distribuirano programiranje u Java okruženju zvanom EJB 3 (Enterprise JavaBeans version 3). JPA je zasnovan na idejama koje su doneli pomenuti projekti TopLink, Hibernate, iBATIS i sam JDO.

9

Oracle Toplink - http://www.oracle.com/technology/products/ias/toplink/index.html Hibernate - http://www.hibernate.org 11 iBATIS - http://ibatis.apache.org 12 JDO API - http://java.sun.com/products/jdo/ 13 JPOX - http://www.jpox.org/index.jsp 14 Eclipse JSR220 ORM - http://www.eclipse.org/jsr220orm/ 15 intelliBO - http://www.signsoft.de/signsoft/en/intelliBO/ 16 BEA Kodo - http://www.bea.com/kodo/ 10

- 32 -


7. Enterprise JavaBeans 3 EJB predstavlja jednu od nekoliko Java API specifikacija za Java EE platformu. EJB standard definiše model serverskih komponenti koje enkapsuliraju poslovnu logiku i koriste se za modularan razvoj višeslojnih arhitektura sa distribuiranim objektima. EJB specifikaciju originalno je razvio 1997. godine IBM, da bi njen dalji razvoj preuzeo Sun Mycrosistems (EJB 1.0 i 1.1). Kasnije verzije EJB specifikacije razvijane su kroz JCP (Java Community Process) i definisane su odgovarajućim JSR dokumentima (EJB 2.0 – JSR 19, EJB 2.1 – JSR 153, EJB 3.0 – JSR 220). Aktuelna verzija, EJB 3.0, kompletirana je 2006.godine a na njenom razvoju radila je ekspertska grupa koju čine Sun, IBM, Apache, BEA Systems, Oracle, Sybase i drugi. EJB 3.0 specifikacija podeljena je u tri dela: EJB osnovni zahtevi – dokument koji definiše interfejse isporučioca servisa (SPI – Service Provider Interface) između instance bean-a i kontejnera, protokole, veze kontejnera i komponenata, razne servise koje kontejner treba da obezbedi bean-u, i druge detalje vezano za razvoj i pakovanje svih vrsta EJB komponenti. 2. EJB 3.0 pojednostavljen API – dokument koji predstavlja priručnik za upoznavanje sa onim delovima prethodnih verzija EJB specifikacije koji su znatno uprošćeni u cilju lakšeg razvoja i korišćenja EJB komponenti. 3. JPA (Java Persistence API) – dokument koji specificira razvijanje i manipulisanje perzistentnim entitetima koje karakteriše POJO (Plain Old Java Objects) stil. Iako je JPA sastavni deo EJB specifikacije, izvesno je da će se njen dalji razvoj u budućnosti odvijati nezavisno, obzirom da se perzistentni entiteti mogu koristiti u bilo kojoj vrsti Java aplikacija, ne samo u EJB aplikacijama. 1.

Kako je EJB rezultat sporazumnog razvoja standardnog načina kreiranja i korišćenja serverskih distribuiranih komponenti, u kom su učestvovali i brojni proizvođači aplikacionih servera, EJB komponente se mogu izvršavati na gotovo bilo kom aplikacionom serveru. Drugim rečima, proizvođači aplikacionih servera su implementiranjem EJB specifikacije odabrali da osiguraju svoje poslovanje pružajući viši nivo kvaliteta, umesto “vezivanja“ korisnika za svoje proizvode nestandardnim, proizvođačkim servisima komponenti. EJB specifikacija definiše arhitekturu serverskih komponenti za sloj poslovne logike. Komponenta se u ovom kontekstu može opisati kao zatvoren entitet koji se može uvek iznova koristiti od strane iste, ili potpuno druge aplikacije, sve dok su zadovoljena pravila semantike. Komponenta mora biti spakovana zajedno sa svim potrebnim informacijama kako bi mogla da pruži nezavisnu postojanost izvan okvira originalne aplikacije, sa mogućnošću višestruke upotrebe. Poslovna ili sistemska aplikacija se zatim može realizovati tako da sadrži brojne softverske kompenente koje su portabilne, mogu se koristiti više puta i od kojih je svaka zadužena za obezbeđivanje određene funkcionalnosti. EJB komponente su serverski orijentisane, namenjene za izvršavanje složenih algoritama ili sigurno izvođenje transakcionih operacija. Serverske komponente se izvršavaju u okruženjima koja moraju biti raspoloživa (24x7), otporna na greške, transakciona, višekorisnička i sigurna. Aplikacioni serveri obezbeđuju takvo okruženje za EJB komponente, kao i servise potrebne za njihovo funkcionisanje. Korišćenje EJB komponenti na više načina pojednostavljuje razvoj velikih, distribuiranih aplikacija. Na prvom mestu, obzirom da EJB kontejner obezbeđuje servise sistemskog nivoa bean-u (kao što su upravljanje transakcijama i sigurnosni servisi), programer može da se fokusira na rešavanje problema vezanih za poslovnu logiku. Kao drugo, pošto bean-ovi sadrže pravila poslovne logike, a ne klijenti, programer klijentske aplikacije može da se usredsredi na prezentacioni aspekt. Kao rezultat, klijent je veoma rasterećen što je veoma bitno za klijentske aplikacije koje su ugrađene u razne vrste uređaja sa ograničenim resursima (npr. mobilni telefon, palm top). Najzad, budući da su EJB komponente prenosive, - 33 -


nove aplikacije mogu koristiti postojeće bean-ove. Ove aplikacije se mogu izvršavati na bilo kom Java EE-kompatibilnom serveru koji implementira standardne API specifikacije. Tipično, EJB komponente izvršavaju sledeće zadatke: Implementacija poslovne logike – na primer, slanje konfirmacionog mejla prilikom potvrde narudžbine, putem JavaMail APIa; izračunavanje troškova u online kupovnoj listi; utvrđivanje privilegija menadžera pri pokušaju odobravanja narudžbine. − Pristup bazi podataka – na primer prilikom poručivanja knjiga, transfera novca između dva bankovna računa, ili pozivanja memorisane procedure. Jedan od mnogih načina pristupanja bazi podataka posredstvom EJB komponenti je i korišćenje JDBC interfejsa. − Integracija sa drugim sistemima – na primer pozivanje transakcionog CICS sistema (Customer Information Control System) pisanog u C jeziku za utvrđivanje izloženosti riziku novom korisniku osiguranja. −

7.1.Vrste EJB komponenti Postoje dve vrste EJB komponenti - session i message-driven, dok je treća vrsta koja je bila definisana u okviru ranijih verzija EJB specifikacije kao EJB entity komponente, danas opisana JPA specifikacijom kao izdvojena celina pod jednostavnim imenom - entiteti. Definisanje neke komponente na jedan od ovih načina je deklarativno – dovoljno je u konfiguraciji komponente napisati kojoj vrsti pripada. U nastavku teksta na početku je dat kratak opis EJB komponenti koje su orijentisane na poruke, a detaljnije se opisane session komponente i entiteti.

7.1.1.EJB komponente orijentisane na poruke Komunikacija putem poruka predstavlja alternativu RMI protokolu. Razmena poruka se vrši preko dodatnog međusloja (MOM - Message Oriented Middleware) između pošiljaoca i primaoca poruka. Pošiljaoc je nakon slanja poruke slobodan da nastavi sa drugim zadacima, dok se srednji sloj brine o samoj isporuci poruke primaocu. Na primer, prilikom online kupovine knjiga, moguće je nastaviti sa pretraživanjem sajta tokom procesa autorizacije kreditne kartice. Ukoliko se proces završi regularno, kupac će biti obavešten o uspešnoj narudžbini konfirmacionim mejlom. Vrsta EJB komponenti koja je orijentisana na poruke (MDB – Message-Driven Beans) kombinuje funkcionalnost session komponenti sa JMS (Java Messaging Service) osluškivačem, omogućavajući na taj način asinhronu razmenu poruka između EJB komponenti. Klijentima nije omogućen pristup MDB bean-ovima putem poslovnog interfejsa, zapravo, ne postoji način da klijent uopšte identifikuje MDB bean i ostvari komunikaciju sa njim. Jedini način interakcije klijenta sa bean-om jeste kroz srednji sloj baziran na porukama, kao što je JMS. Zalihama MDB instanci upravlja EJB kontejner, koji prima poruke od srednjeg sloja i dodeljuje ih slobodnim bean-ovima.

slika 10.

Životni ciklus MDB komponente

- 34 -


Životni ciklus MDB instance uključuje dva stanja: stanje kada instanca još ne postoji (Does Not Exists) i stanje kada se instanca nalazi u zalihama i spremna je za korišćenje (Ready). Kontejner može odlučiti da, u cilju uštede resursa, ukloni neki bean iz zaliha pozivanjem metode remove().

7.1.2.EJB session komponente Session komponente generalno reprezentuju akcije u poslovnom procesu. One predstavljaju privremenu komunikaciju sa klijentom, i implementiraju pravila poslovne logike, na primer u slučaju bankarskih transakcija, narudžbina, kontrole zaliha ili operacija nad bazom podataka. Mogu se koristiti samo od strane jednog klijenta u istom trenutku, a po završetku sesije, session bean sa svim svojim podacima nestaje. Session komponente mogu biti realizovane na dva načina: session komponente bez stanja i session komponente sa stanjem. Session komponente bez stanja (Stateless Session Bean) predstavljaju distribuirane objekte koji nemaju pridružene podatke o stanju, stoga dozvoljavaju konkurentan pristup. Očuvanje vrednosti atributa u okviru jedne instance nije garantovano, ali je memorijsko premašenje tokom održavanja veze sa pozivajućom aplikacijom znatno manje u odnosu na session komponente sa stanjem. Na primer, prilikom verifikacije kreditne kartice, bean zadužen za verifikaciju će prvo uzeti podatke o broju kartice, roku važenja kartice, nosiocu kartice i iznosu na kartici. Zatim će nakon provere, bean vratiti da/ne odgovor, zavisno od validnosti kreditne kartice. Po okončanju ovog zadatka, bean je slobodan da usluži narednog klijenta i nema više nikakve podatke o prethodnom. Obzirom da nijedan atribut instance ne čuva klijent-specifične podatke, EJB kontejneru je omogućeno da kreira zalihu (pool) session bean-ova. Zbog ove osobine, session komponente bez stanja su izuzetno skalabilne u slučaju velikog broja korisnika, a takođe obezbeđuju i dobre performanse pošto ne postoji potreba da kontejner pomera bean iz memorije i skladišti podatke na disku. Životnim ciklusom session bean-ova upravlja kontejner, a na slici 14 je prikazan životni ciklus jedne session komponente bez stanja.

slika 11.

Životni ciklus session komponente bez stanja

Postoje samo dva stanja u slučaju session komponente bez stanja: stanje kada instanca ne postoji (Does Not Exists) i stanje kada je instanca spremna za korišćenje (Ready). Nakon što kontejner kreira novi bean pomoću metode newInstance(), on poziva metode za postavljanje okruženja unutar bean-a setSessionContext(). Time je omogućena tranzicija u drugo stanje, kada je bean spreman za korišćenje. Klijent onda može koristiti poslovne metode bean-a. Kontejner poziva preDestroy() metodu kada instanca - 35 -


više nije potrebna, što ima za posledicu povratak bean-a u početno stanje (radi jasnije analize životnog ciklusa, uloga pool-a biće zanemarena). Session komponente sa stanjem (Stateful Session Bean) sadrže i podatke o stanju, odnosno prate sa kojom aplikacijom interaguju tokom sesije i pamte svoje stanje između poziva od strane istog klijenta. Kontejner skladišti i obnavlja session komponente sa uspostavom stanja prilikom pomeranja iz radne u dugotrajnu memoriju. Zbog ovih osobina, EJB komponente sa stanjem unose veće premašenje u sistem i manje su skalabilne od stateless bean-ova. Tipična primena ovog tipa session komponenti je prilikom online kupovine, gde svaki kupac ima svoj nalog i pri svakom prijavljivanju, detalji o njegovoj “korpi“ za kupovinu se od strane bean-a povlače iz baze.

slika 12.

Životni ciklus session komponente sa stanjem

Sa slike 15 se vidi da ova vrsta session komponenti ima i treće stanje – stanje kada je bean pasivan (Passive). Tranzicija iz stanja Ready u stanje Passive dešava se kada kontejner perzistira podatke iz bean-a u sekundarnu memoriju a sam bean smesti u pool, pozivanjem metode prePassivate(), u cilju oslobađanja resursa. Kada klijent ponovo pozove neku od poslovnih metoda tog bean-a, kontejner obnavlja sadržaj bean-a a zatim ga, pozivanjem metode preActivate()“budi“ iz pasivnog stanja i bean je ponovo spreman da opsluži zahteve klijenta.

7.2.EJB kontejner EJB komponente smeštene su unutar kontejnera na aplikacionom serveru. Specifikacijom je definisan način na koji se obavlja interakcija između EJB komponente i njenog kontejnera, kao i interakcija klijentskog koda sa kontejnerom. Najvažnija funkcija kontejnera jeste da obezbedi sigurno, distribuirano, transakciono okruženje koje je kao takvo pogodno za egzistenciju EJB komponente unutar njega. EJB kontejner se ponaša kao posrednik između klijenta i bean-a. Zahvaljujući kontejneru, bean je potpuno izolovan u odnosu na klijenta i ne može mu se direktno pristupiti. Kada klijentska aplikacija pozove udaljenu metodu EJB komponente, kontejner je prvo presreće kako bi utvrdio da su pravila vezana za perzistenciju, transakcije i sigurnost adekvatno primenjena na svaku operaciju koju klijent želi da izvrši. Kontejner vodi računa o više bean-ova istovremeno, na sličan način kao što Web server opslužuje više servleta. Kada bean nije u upotrebi, kontejner ga smešta u pool kako bi mogao da ga koristi novi klijent. EJB komponenta u potpunosti zavisi od kontejnera; na - 36 -


primer, ukoliko joj je potrebna JDBC konekcija ili servis koji pruža druga EJB komponenta, kontejner će joj to obezbediti. EJB komponenta komunicira sa kontejnerom na tri načina: pozivanjem callback metoda, pomoću EJBContext interfejsa, ili JNDI interfejsa. − Callback metode. Svaki session bean može da implementira EnterpriseBean interfejs koji definiše razne callback metode. Svaka od ovih metoda obaveštava bean u trenucima kada dolazi do promena stanja u njegovom životnom ciklusu, a kontejner ih poziva kako bi obavestio bean da se sprema da ga aktivira, perzistira njegovo stanje u bazi podataka, završi transakciju, ukloni ga iz memorije. Callback metode omogućavaju bean-u da završi poslove koji su u toku, pre ili nakon događaja koji sledi. − EJBContext. Svakom bean-u se pridružuje EJBContext objekat, koji predstavlja njegovu direktnu vezu sa kontejnerom. Interfejs EJBContext obezbeđuje metode za interakciju sa kontejnerom tako da bean može putem njih zahtevati informacije o svom okruženju, na primer informacije o klijentu, ili status transakcije. − JNDI interfejs predstavlja standardno proširenje Java platforme za pristup imenovanim servisima kao što su LDAP, NetWare, sistemi datoteka itd. Svaki bean automatski ima pristup specijalnom imenovanom sitemu ENC (Environment Naming Context). ENC sistemom upravlja kontejner a bean mu pristupa putem JNDI interfejsa. JNDI ENC omogućava bean-u da pristupa resursima kao što su JDBC konekcije, druge EJB komponente, i specijalna svojstva i servisi koje pružaju te komponente.

slika 13.

EJB kontejner sa pripadajućim EJB komponentama različitih vrsta

Poslovni (business) interfejs navodi metode koje nudi EJB komponenta, kako bi one bile vidljive klijentima. Zavisno od lokacije klijenta, business intefejs se dalje može podeliti na lokalni i udaljeni.

7.3.Entiteti i menadžer entiteta Entiteti predstavljaju perzistentne objekte koji ne nestaju po završetku komunikacije sa klijentom, i više klijenata može istovremeno deliti jedan entitet. Životni vek im je vezan za životni vek podataka koji predstavljaju, a ne aplikacije koja ih koristi. Njima su tipično predstavljeni podaci uskladišteni u jednom redu tabele u bazi podataka. Takođe, entiteti imaju atribute za potrebe identifikacije (koji odgovaraju primarnim ključevima u tabeli) koji mogu biti prosti ili složeni, a mogu imati i definisane veze sa drugim entitetima. Poslovna logika implementirana kroz session komponente, a uz pomoć servisa za perzistenciju, vodi računa da podaci iz entiteta budu trajno sačuvani. - 37 -


U okviru JPA dela EJB 3 specifikacije koji se bavi entitetima i načinom njihove perzistencije, definisani su interfejsi neophodni za izvođenje operacija nad entitetima. Entiteti se razlikuju od EJB komponenti po tome što reprezentuju podatke koji se skladište u bazi. Takođe, entiteti se mogu koristiti i u J2SE aplikacijama, za razliku od session ili MDB beanova. Menadžeru entiteta, koji implementira potrebne interfejse za perzistenciju definisane JPA specifikacijom, delegirani su svi zadaci vezani za kreiranje, čitanje, izmenu i brisanje entiteta. Bez menadžera, entitet nije ništa drugo do regularan, plain old, Java objekat (POJO), dok sam menadžer predstavlja instancu klase EntityManager. Kada menadžer entiteta referencira jedan entitet, za taj objekat se kaže da je upravljan (managed) od strane menadžera. Set upravljanih instanci entiteta pod nadležnošću jednog menadžera u datom trenutku predstavlja kontekst perzistencije (persistence context). U jednom vremenskom trenutku samo jedna Java instanca sa istim identifikatorom može postojati u okviru konteksta perzistencije. Interfejs EntityManager obezbeđuje metode za tri tipa opracija: − upravljanje životnim ciklusom entiteta, − sinhronizacija sa bazom podataka, − pretraga entiteta i izvršavanje upita.

7.3.1.Upravljanje životnim ciklusom entiteta Životni ciklus jedne instance entiteta određen je sa dva glavna aspekta koji se odnose na vezu instance sa specifičnim kontekstom perzistencije, i sinhronizaciju stanja instance sa stanjem u bazi podataka. Menadžer entiteta razlikuje četiri stanja u životnom ciklusu entiteta: − Nova instanca (New). Instanca entiteta je kreirana u memoriji ali joj još uvek nije dodeljen identifikator ili kontekst perzistencije. U ovom trenutku stanje entiteta još uvek nije sinhronizovano sa stanjem u bazi i menadžer ne zna za postojanje novog entiteta. − Upravljana instanca (Managed). Entitet poseduje identifikator i kontekst perzistencije. Promene na entitetu će biti sinhronizovane sa bazom kada se transakcija uspešno izvrši (commited) ili u slučaju eksplicitno zahtevane sinhronizacije pomoću flush() operacije. Entitet dolazi u upravljano stanje na mnogo načina: pozivima persist(), merge() ili refresh() metoda, kao i u slučaju da je entitet rezultat pretrage ili upita. − Neupravljana instanca (Detached). Entitet i dalje poseduje identifikator ali nije više asociran sa kontekstom perzistencije i menadžer više njim ne upravlja. − Uklonjena instanca (Removed). Entitet je još uvek vezan za kontekst perzistencije ali je raspoređen za uklanjanje iz baze podataka.

slika 14.

Tranzicije stanja entiteta

- 38 -


Operacijom remove() mogu se rasporediti za uklanjanje iz baze podataka jedino entiteti koji se nalaze u upravljanom stanju. Pomoću ove operacije podaci u bazi se raspoređuju za uklanjanje, što će se zaista i desiti kada se transakcija uspešno izvrši, ili kada se pozove operacija flush(). Pomoću operacije merge() moguće je neupravljanim entitetima ponovo dodeliti kontekst perzistencije. Entitet dolazi u Detached stanje po prestanku postojanja konteksta perzistencije ili kada se isporuči klijentu kao serijalizovan objekat.

7.3.2.Sinhronizacija sa bazom podataka Izmene na lokalnim entitetima se obično sinhronizuju sa bazom podataka u vreme potvrđivanja transakcije (commit). Međutim, ponekad je važno izvršiti sinhronizaciju pre potvrđivanja operacija transakcije. Na primer, izmene entiteta mogu uticati na rezultate upita u okviru iste transakcije. U tom slučaju, neophodno je obaviti sinhronizaciju pre izvršavanja upita. Izvršavanje prevremene sinhronizacije kontroliše se postavljanjem flush režima rada za željene metode korišćenjem anotacija, ili globalno za kontekst perzistencije pomoću setFlushMode() operacije. Dostupne opcije vezane za flush režim rada uključuju COMMIT za sinhronizaciju samo u vreme potvrđivanja transakcije, i AUTO za sinhronizaciju stanja entiteta i u vreme potvrđivanja transakcije i pre izvršavanja upita. Operacija flush() obavlja sinhronizaciju stanja svih entiteta u okviru konteksta perzistencije sa entitetima u bazi ali ne uključuje i ažuriranje lokalnih entiteta na osnovu njihovog stanja u bazi. Za potrebe ažuriranja, mora se eksplicitno pozvati operacija refresh().

7.3.3.Pretraga entiteta i izvršavanje upita U cilju identifikacije entiteta koje prethodi referenciranju instance istog, potrebno je ili direktno adresirati individualan entitet korišćenjem primarnog ključa, ili izvršiti upit koji će kao rezultat vratiti set entiteta na osnovu zadatih uslova. Menadžer entiteta obezbeđuje metodu find() za potrebe adresiranja entiteta na osnovu primarnog ključa. Ova metoda će kao rezultat vratiti upravljan entitet odgovarajuće klase u slučaju ispravno navedenog identifikatora, u suprotnom, rezultat će biti null vrednost. U većini slučajeva identifikator entiteta nam je nepoznat, ili nam je potrebno više od jednog rezultata, ili je neophodno postaviti jedan ili više uslova za pronalaženje entiteta; odnosno, potrebno je formulisati upit. Postoje brojni način za definisanje pretrage koje nudi interfejs EntityManager, ali su generalni koraci pri tom uvek isti: − pravljenje nove javax.persistance.Query instance od strane menadžera, − postavljanje parametara upita i gornju granicu veličine rezultujećeg seta (ako je potrebno), − izvršavanje upita. Prvi korak obavlja menadžer entiteta, dok druga dva koriste Query interfejs. Moguće je odabrati korišćenje upita pisane u EJB-QL (EJB Query Language) jeziku ili nativnom SQL-u. EJB-QL je objektni upitni jezik koji je po sintaksi veoma sličan SQL-u. Osnovna razlika između EJB-QL i SQL jezika jeste u tome što EJB-QL koristi entitete za model podataka i garantuje kompletnu portabilnost između heterogenih baza podataka. SQL, i pored toga što predstavlja ISO standard, često ne ispunjava zahteve portabilnosti usled velikog broja različitih proizvođačkih dodataka i SQL dijalekata koji postoje. Postoje dve vrste EJB-QL upita koje se mogu koristiti – dinamički i statički. Metoda createQuery() koristi se za kreiranje dinamičkih upita, odnosno upita koji su definisani u - 39 -


okviru koda koji implementira poslovnu logiku aplikacije. Metoda createNamedQuery() služi za upotrebu statičkih, ili imenovanih upita, koji se definišu pomoću @NamedQuery anotacije i mogu se pozivati više puta pomoću imena upita. Naveden je primer korišćenja ove dve metode za dobijanje spiska svih radnika: /* kreiranje dinamičkog upita */ Query query = manager.createQuery("SELECT r FROM Radnik r");

/* kreiranje imenovanog upita */ @NamedQuery( name="sviRadnici", query="SELECT r FROM Radnik r"); /*pozivanje imenovanog upita*/ radnici = manager.createNamedQuery("sviRadnici");

7.4.Metapodaci Svakom entitetu su pridruženi metapodaci u određenoj količini koji ga opisuju. Ovi metapodaci omogućuju sloju za perzistenciju da prepozna, interpretira i upravlja na odgovarajući način entitetom od učitavanja, preko izvršavanja do uklanjanja. Količina metapodataka koji su zaista neophodni da bi se opisao entitet je zapravo mala, međutim, kao i u svim sofisticiranim tehnologijama metapodacima je moguće specificirati sve relevantne detalje. Metapodaci entiteta mogu biti specificirani na jedan od tri načina – pomoću XML deskriptora, XDoclet komentara ili pomoću anotacija. Uprkos razlikama u sintaksi moguće je svakim od navedenih pristupa postići isti nivo konfiguracije.

7.4.1.Anotacije Anotacije predstavljaju osobinu programskog jezika koja omogućava struktuiranim i tipiziranim metapodacima da budu deo izvornog koda. Pojam anotacija uveden je u Java SE 5, i predstavlja ključni deo EJB 3.0 i Java EE 5 specifikacija. One se mogu koristiti kao alternativa standardnim XML deskriptor fajlovima, ili u kombinaciji sa njima. Definicije metapodatka unutar Java koda upotrebljavaju se, u različitim oblicima, od samog nastanka Java jezika. Prvi primer bili su Javadoc tagovi u okviru komentara koji su se koristili za generisanje API dokumentacije u HTML formatu. Ideja je bila da se metapodaci nalaze u specijalnom obliku komentara unutar koda, koje zatim posebni kompajleri ili nezavisni alati obrađuju i upravljaju dobijenim informacijama. Najistaknutiji predstavnik ove tehnike jeste popularni XDoclet alat, koji je zapravo pretprocesor izvornog koda. Bitno je istaći da su u okviru Javadoc/XDoclet pristupa metapodaci smešteni unutar komentara, što znači da ih ne obrađuje Java kompajler. Metapodaci se ne kompajliraju u regularnu klasu i dostupni su samo u vreme kompajliranja. Sintaksa i semantika metapodataka se ne proverava od strane kompajlera, što može uzrokovati kasno otkrivanje grešaka. Za razliku od starog načina definisanja metapodatka unutar koda aplikacije, anotacije su sada deo Java jezika, a proveru sinrtakse i semantike, kao i kompajliranje obavlja standardni Java kompajler. Anotacije se razlikuju od ostatka programskog koda time što ispred same anotacije postoji znak “@“. Postoji veliki broj anotacija definisanih specifikacijom, a navedene su samo neke koje se često koriste u radu sa EJB komponentama: − @Stateless, @Stateful, @Entity, @MessageDriven – specificiranje tipa klase, − @Local, @Remote – specificiranje tipa interfejsa, − @Interceptors – definisanje svih callback klasa koje će se primenjivati nad beanom, - 40 -


− − − − − − −

@PrePassivate, @PostActivate,... – označavanje callback metode pri prelasku iz

jednog stanja u drugo, @PersistenceContext – ukazuje na zavisnost od konteksta perzistencije, @Table – navođenje primarne tabele entiteta; dodatne tabele se mogu specificirati pomoću @SecondaryTable ili @SecondaryTables anotacija, @Column – specificiranje mapirane kolone za perzistentan atribut entiteta; moguće je dodatno definisati i ograničenja kolone (constraints), dozvolu null vrednosti kolone,

dužinu kolone itd, @Id – specificiranje atributa koji predstavlja primarni ključ, @JoinTable – definisanje vezivne tabele u relacijama tipa više-više, @ManyToOne, @OneToOne, @OneToMany, @ManyToMany – definisanje relacija, uz moguće navođenje dodatnih opcija kao što je na primer kaskadno brisanje.

Prednosti anotacija se mogu videti i iz koda koji predstavlja iste metapodatke, na tri načina i to konfigurisanjem pomoću XML deskriptora, info.komisura.Count info.komisura.Count info.komisura.CountBean Stateful info.komisura.CountCallbacks

XDoclet-a, /** * @ejb.bean * type=”Stateful” * name=”Count” * view-type=”remote” */ public class CountBean { public int count() {...} }

anotacija: @Stateful @Remote (Count.class) @Interceptors (CountCallbacks.class) public class CountBean implements Count { public int count() {...} }

Navedeni metapodaci opisuju session bean sa stanjem i njegov pripadajući udaljeni interfejs definisan u klasi Count i callback metode definisane u klasi CountCallbacks. Iz primera se može uočiti da, pored prednosti provere metapodataka prilikom kompajliranja, anotacije poseduju i prednost u pogledu dužine koda i jednostavnosti sintakse. Za razliku od anotacija, upotreba XML deskriptora ima za posledicu postojanje dva fajla (sam deskriptor .xml i .java izvorni fajl), kompleksniju i dužu sintaksu, a isto tako ne pruža mogućnost semantičke provere pri kompajliranju.

- 41 -


7.5.Jednostavan primer upotrebe EJB i JPA komponenti Na primeru prikaza izveštaja stanja bankovnog računa demonstrirana je upotreba EJB i JPA komponenti u distribuiranom okruženju. Pokriveni su slojevi od klijentskog, preko sloja poslovne logike i sloja za perzistenciju, do sloja podataka. Kao što je prikazano na slici 13, centralni deo sistema predstavlja poslovni interfejs koji klijentima navodi raspoložive metode session bean-ova. Nakon što se u projektu definišu poslovni interfejsi, klijentski i sloj poslovne logike mogu dalje da se nezavisno razvijaju. Kodom koji sledi definisan je javni interfejs Account, sa navedenom metodom getPayments() koja kao ulazni parametar prima broj bankovnog računa sa kojeg se žele preuzeti uplate, odnosno isplate. package info.komisura.demo; import java.util.*; public interface Account { List getPayments(String accountId); }

Sledeći korak može biti izrada klijentskog koda za generisanje izveštaja o uplatama i isplatama sa bankovnog računa. Dobijanje podataka o plaćanjima na računu je omogućeno pozivanjem odgovarajuće udaljene metode preko RMI/IIOP protokola, putem vezivnog (stub) objekta koji se generiše JNDI lookup pozivom. Od svega ovog, klijent treba da zna samo JNDI ime željene EJB komponente i da joj pristupa preko odgovarajućeg interfejsa. package info.komisura.demo; import javax.naming.*; import javax.util.*; public class AccountClient { public static void main (String[] args) { String accountId = args[0]; Context ctx = new InitialContext(System.getProperties()); Account account = (Account) ctx.lookup(Account.class.getName()); List payments = account.getPayments(accountId); double balance = 0; for (Payment payment : payments) { double amount = payment.getAmount(); if (amount > 0) { System.out.println(”Uplata: ” + amount); } else { System.out.println(”Isplata: ” + ((-1)*amount)); } balance += amount; } System.out.println(”Stanje: ” + balance); } }

Na sloju poslovne logike potrebno je napisati implementaciju zadatog interfejsa u obliku session bean-a (za dati scenario dovoljan je stateless tip). U ovom slučaju, metoda za pronalaženje plaćanja za određeni račun podatke dobija iz baze preko menadžera entiteta. Dinamičkim upitom se na osnovu imenovanog parametra accountId dobija lista entiteta koja se kao povratna vrednost prosleđuje klijentskoj strani. package info.komisura.demo; import java.util.*; import java.ejb.*; import java.persistence.*;

- 42 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju @Stateless @Remote(Account.class) public class AccountBean implements Account { @PersistenceContext private EntityManager manager; public List getPayments(String accountId) { Query query = manager.createQuery( ”SELECT p FROM Payment p WHERE p.accountId = :accountId”); query.setParameter(”accountId”, accountId); return query.listResults(); } }

U okviru sloja za perzistenciju definisan je entitet koji predstavlja pandam tabeli u objektnom modelu. Takođe, usled činjenice da entiteti tokom svog životnog ciklusa mogu putovati do udaljenih Java virtuelnih mašina, neophodno je implementirati podršku za serijalizaciju i deserijalizaciju entiteta. Naravno, potrebno je atribute entiteta mapirati na odgovarajuće kolone, pri čemu su preslikavanja automatska ukoliko su parovi imena atributa i kolona identični. package info.komisura.demo; import java.io.Serializable; import javax.persistence.*; @Entity @Table (name = ”PAYMENTS”) public class Payment implements Serializable { @Id public int id; @Column (name = ”PMT_ACCOUNT_ID”) public String accountId; @Column (name = ”PMT_AMOUNT”) public double amount; }

Skript za kreiranje odgovarajuće tabele prikazan je u sledećem isečku: CREATE TABLE PAYMENTS ( ID INTEGER PRIMARY KEY, PMT_ACCOUNT_ID VARCHAR(13), PMT_AMOUNT DECIMAL (10,2) )

- 43 -


8. Praktični deo Na osnovu analize informacionog sistema visokoškolske ustanove za potrebe praktičnog dela diplomskog rada za realizaciju je odabran modul koji omogućava pregled i upravljanje nastavnim planoma i programom. U nastavku je obrađena funkcionalnost rešenja, njegova arhitektura i implementacija kao i pregled korišćenih alata.

8.1.Razmatrani informacioni sistem Razmatrani informacioni sistem jedne visokoškolske ustanove bavi se razrešavanjem svakodnevnih operacija u interakciji student – ustanova, uključujući objavljivanje obaveštenja, rasporeda časova, rasporeda ispitnog roka, rezultata ispita, anketa, nastavnog plana i programa, i komentara. Ove operacije, zavisno od pristupnih prava, mogu izvršavati tri tipa korisnika: profesor, službenik (studentska služba, administrator, sekretar, direktor) ili student. Pristupna prava se utvrđuju prijavljivanjem na sistem pomoću korisničkog imena i lozinke, nakon čega određeni korisnici mogu izvršavati operacije dodavanja, izmene ili brisanja sadržaja koji je u njihovoj nadležnosti. Na slici 17 su prikazani tipovi korisnika i njihova zaduženja.

slika 15.

Tipovi korisnika i njihova zaduženja u razmatranom informacionom sistemu

U okviru praktičnog dela diplomskog rada obrađen je deo informacionog sistema koji se bavi nastavnim planom i programom. − − − − − −

Na slici 18 prikazana je arhitektura Web aplikacije koja omogućuje: odabir nastavnog plana (za željeni smer), prikaz nastavnog plana sa podacima o nazivu predmeta, fondu časova, ESPB bodovima, izbornosti i semestru, prikaz programa željenog predmeta sa detaljima o predmetnom profesoru, literaturi, dodavanje novih predmeta i njihovih programa, dodavanje profesora, izmena postojećih nastavnih planova i predmetnih programa.

Funkcionalno, arhitektura se sastoji iz pet slojeva: sloja podataka, sloja za pristup podacima, prezentacionog sloja, sloja poslovne logike i klijentskog sloja. Fizički, ona može realizovana na tri odvojena sloja, gde bi sloj podataka bio smešten na serveru baze podataka, sloj za pristup podacima, prezentacioni sloj i sloj poslovne logike na aplikacionom serveru, a klijentska aplikacija, odnosno Web čitač je na korisničkoj strani.

- 44 -


Postojeći plan i program Vetš-a smešten je u MySQL bazu podataka. Struktura baze sastoji se iz: spiska institucija (u slučaju eventualne podrške za upravljanje planovima više institucija), spiska planova, spiska smerova, spiska predmeta, literature i profesora. Struktura baze sa tabelama, kolonama i vezama nalazi se na slici 19.

slika 16.

Detaljna arhitektura

Sloj za pristup podacima realizovan je pomoću Hibernate ORM alata (verzija 3.2.2). Hibernate komunicira sa bazom podataka putem JDBC poziva a na osnovu informacija o objektno-relacionom mapiranju iz konfiguracionog fajla. Posledica ovog procesa je generisanje entity bean-ova, jednostavnih Java objekata koji predstavljaju određene entitete iz baze podataka. Ovakvom organizacijom Hibernate pruža programeru potpunu apstrakciju relacionog modela. Za potrebe komunikacije sa bazom korišćen je MySQL Connector/J JDBC drajver (verzija 5.0.4). Prezentacioni i poslovni sloj su realizovani pomoću Tapestry framework-a (verzija 4.0.2), odnosno template engine-a koji služi za upravljanje dinamičkim sadržajem. Svaka stranica aplikacije poseduje triplet fajlova: .html, .page i .java (uz eventualni dodatak .script fajla za stranice koje koriste Javascript). Dinamičke delove template-a (.html fajl) popunjava Tapestry pomoću podataka iz Java klase i na osnovu dodatne konfiguracije (.page fajl). Komunikacija između Tapestry klasa i entity bean-ova na sloju za pristup podacima odvija se pomoću regularnih Java poziva. Hibernate konvertuje podatke iz baze u objekte, odnosno entity bean-ove, koje dalje koristi poslovna logika iz Tapestry klase kako bi od template-a, zamenom dinamičkih delova, bio generisan izlazni HTML fajl koji se prosleđuje Web čitaču.

- 45 -


slika 17.

Struktura baze podataka

8.2.Prikaz funkcionalnosti Predloženo rešenje nudi mogućnosti prikaza, izmene i dodavanja nastavnih planova zajedno sa podacima o smerovima, predmetima, profesorima i literaturi. Na slici 20 prikazana je početna strana aplikacije sa listom nastavnih planova i pripadajućim smerovima koji se mogu odabrati za detaljniji prikaz. Takođe, sa ove stranice moguće je izmeniti postojeći ili dodati nov nastavni plan, izmeniti informacije o smeru ili isti obrisati. Tokom generisanja stranice aplikacije, spoljnom for petljom prolazi se kroz sve zapise tabele Plan, a unutrašnjom kroz sve zapise tabele Smer gde je vrednost polja plan_id u skladu sa tekućim planom spoljne petlje. Sledeći kod obezbeđuje listu planova koja se koristi za spoljnu for petlju: session = HibernateUtil.getSession(); plans = session.createQuery("from PlanBean desc").list();

plan

order

by

plan.year

Obzirom da je veza između tabela plan i smer tipa “1-više”, listi smerova tekućeg plana potrebnoj za unutrašnju for petlju pristupa se kao atributu bean-a plan pomoću metode getPlan.getCourses(). U prikazu ove stranice učestvuje i .script fajl koji kao deo Tapestry arhitekture sa svojim JavaScript kodom omogućava dodavanje dinamičkog aspekta. Na ovoj stranici su tako omogućena dva moda prikaza - prošireni i skupljeni (+ i -).

- 46 -


slika 18.

Početna strana aplikacije

Slika 21 prikazuje formu za dodavanje novog nastavnog plana. Podaci iz polja forme se, pomoću mapiranja definisanih u bean-u PlanBean, perzistiraju u odgovarajuće kolone novog reda tabele Plan, dok se primarni ključ automatski generiše (auto increment). U slučaju izmene podataka o nastavnom planu, vrši se ažuriranje odgovarajućeg reda.

slika 19.

Dodavanje nastavnog plana

Na slici 22 prikazan je pregled nastavnog plana za odabrani smer (u ovom slučaju u pitanju je smer Automatika, koji se nalazi u raširenom modu prikaza). Sa date stranice moguće je dodati nov smer, kreirati nov predmet, odabrati pregled stavke (klikom na naziv predmeta), izmenu stavke ili brisanje stavke, kao i dodavanje nove stavke nastavnog plana. U svakom redu nastavnog plana na slici predstavljeni su podaci iz vezivne tabele Stavka, koja sadrži spoljne ključeve ka tabelama Plan, Smer i Predmet. Na osnovu ovih relacija, pristupa se zapisima od interesa u navedenim tabelama, te se isti koriste tokom prikaza (naziv predmeta, fond časova i broj ESPB bodova iz tabele Predmet, kao i naziv i sajt smera iz tabele Smer).

- 47 -


slika 20.

Pregled željenog nastavnog plana za odabrani smer

Odabirom predmeta sa slike 22 otvara se prikaz detalja o predmetu iz stavke plana. Struktura fonda časova uskladištena je u zasebnim kolonama u cilju preciznije naknadne obrade. Na osnovu mapiranja se može doći i do spiska profesora, što je i priikazano.

- 48 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju slika 21.

Prikaz detalja o odabranom predmetu

Slika 24 prikazuje formu za izmenu odabranog predmeta. Prikazana forma otvara se klikom na dugme “Izmeni” sa prethodne slike. Pored izmene detalja vezanih sa sam predmet, kao što su naziv predmeta, fond časova i drugi, moguće je i dodavanje, izmena ili brisanje literature za odabrani predmet.

slika 22.

Izmena odabranog predmeta

Klikom na ikonicu za izmenu stavke plana sa slike 22 otvara se prozor aplikacije prikazan na slici 23. Tabela Stavka povezana je sa tabelom Profesor pomoću vezivne tabele Stavka_profesor, (iste veze su pomoću mapiranja definisane i u odgovarajućim Java klasama ItemBean i ProfessorBean), te se odabranoj stavci može dodeliti jedan ili više predmetnih profesora.

- 49 -


slika 23.

−

Izmena odabrane stavke nastavnog plana

Sledećim isečkom koda iz Java klase ItemEdit predstavljeno je: Kreiranje modela za prikaz padajuće liste profesora sa slike 25. Lista profesora se popunjava rezultatom upita koji učitava profesore do sada nedodeljene predmetu u pitanju. Vrednost primarnog ključa stavke za koju se kreira lista profesora se poredi sa prosleđenim parametrom, identifikatorom odabrane stavke.

public ProfessorSelectionModel getProfessorModel() { List professors = session .createQuery( "from ProfessorBean as professor " + " where professor.id not in (" + " select professor.id " + " from ProfessorBean as professor " + " join professor.items as item " + " with item.id = ? " + ")" ) .setInteger(0, item.getId()) .list(); return new ProfessorSelectionModel(professors); }

−

Funkcija doAsignProfessor() koju poziva osluškivač (listener) kada se klikne na dugme “Dodeli” (slika 25). Zahvaljući mapiranjima u odgovarajućoj Java klasi i obzirom da je veza između stavke i profesora tipa “više-više”, moguće je pristupiti listi profesora koji predaju predmet definisan stavkom plana kao atributu same stavke (item.getProfessors()), a zatim dodati novi element liste – još jednog profesora (add(professor)). Atributi objekta professor popunjeni su na osnovu podataka iz selektovanog elementa modela za odabir profesora. Posledica ove akcije biće nov zapis u vezivnoj tabeli Stavka_profesor.

public void doAssignProfessor() { Transaction tr = session.beginTransaction(); item.getProfessors().add(professor); tr.commit(); }

−

Funkcija doSubmit() koju poziva osluškivač kada se klikne na dugme “Sačuvaj”. Tada se vrši perzistiranje ili ažuriranje objekta item (koji je mapiran na tabelu Stavka) pomoću funkcije saveOrUpdate(). - 50 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju public void doSubmit() { Transaction tr = session.beginTransaction(); session.saveOrUpdate(item); tr.commit(); }

Pored pregleda planova, druga osnovna strana je pregled profesora i prikazana je na slici 26. Sa ove stranice je omogućena neposredna izmena, dodavanje i brisanje profesora.

slika 24.

Spisak profesora

Na primeru tabele Profesor, sledećim kodom predstavljena su mapiranja pomoću anotacija @Id za definisanje primarnog ključa i @Column za mapiranje ostalih kolona. Takođe, anotacijom @ManyToMany mapirana je relacija između tabele Profesor i tabele Stavka. Pomoću get() i set() metoda kreiranog bean-a ProfessorBean moguće je pristupati potrebnim atributima, odnosno postavljati njihove vrednosti iz svih delova aplikacije. @Entity @Table (name = "professor") public class ProfessorBean implements Serializable { private int id; private String name; private String resume; private List items; public ProfessorBean() {} public ProfessorBean(int id) { this.id = id; } @Id public int getId() { return id; } public void setId(int id) { this.id = id; } @Column public String getName() { return name; } public void setName(String name) { this.name = name; } @Column public String getResume() { return resume; } - 51 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju public void setResume(String resume) { this.resume = resume; } @ManyToMany @JoinTable (name = "pitem_prof", joinColumns = @JoinColumn (name="professor_id"), inverseJoinColumns = @JoinColumn (name="pitem_id")) public List getItems() { return items; } public void setItems(List items) { this.items = items; } }

Pored prikazanih, dostupne su i stranice za dodavanje i izmenu smera, profesora i literature koje su izostavljene usled sličnosti sa već prikazanim stranicama koje se bave dodavanjem i izmenama.

8.3.Korišćeni alati Predloženo rešenje od softverskih alata zahteva bazu podataka koja poseduje JDBC drajver, aplikacioni server sa podrškom za Java servlete kao i Hibernate i Tapestry framework. Zahvaljujući standardima kao što su Java servleti i JDBC omogućen je slobodan izbor komponenti, pri čemu je u ovom konkretnom slučaju korišćen MySQL server baze podataka (verzija 5.0.27) i Tomcat aplikacioni server (verzija 5.5). Takođe je moguće u momentu isporuke rešenja preći na upotrebu baze podataka napisane u potpunosti u Java jeziku (npr. Java DB, Sun), čime bi se omogućila apsolutna portabilnost. Takođe treba napomenuti da je sam projekat rađen u Eclipse razvojnom okruženju (verzija 3.2.1) čiji je pregled, zajedno sa pregledom drugih pomenutih alata, dat u nastavku.

8.3.1.Hibernate Hibernate framework predstavlja alat za objektno-relaciono mapiranje koji nudi servise za perzistenciju i izvršavanje upita. Generisanje SQL iskaza obavlja se automatski, ne postoji potreba za ručnim upravljanjem rezultujućim skupovima dobijenim kroz JDBC i konverzijom tipova podataka, dok se sama aplikacija može lako preneti na drugu relacionu bazu podataka. Hibernate nudi sofisticirane upitne metode, uz mogućnost pisanja čistog SQLa ili korišćenje objektno-orijentisanog HQLa (Hibernate Query Language). Takođe, moguća je optimizacija učitavanja objekata kroz celu aplikaciju, sa različitim fetch opcijama i opcijama za keširanje. Hibernate implementira JPA specifikaciju kroz Hibernate menadžera entiteta i anotacije, i predstavlja sertifikovani Java Persistence provider. Kao i svi ORM alati, Hibernate zahteva metapodatke koji rukovode transformacijom podataka iz relacione predstave u objektnu, i obrnuto. Zahvaljujući podršci JPA standardu, u svrhe objektno-relacionog mapiranja mogu se koristiti JDK 5.0 anotacije. Hibernate-ov menadžer entiteta implementira standardne interfejse za: upravljenje perzistencijom, upitni jezik, pravila životnog ciklusa objekata i konfiguraciju i pakovanje fajlova. 8.3.1.1.Osnovna konfiguracija Na slici 20 svetlo sivom bojom označene su klase koje se najčešće koriste u kodu aplikacije. Tamno sivom bojom predstavljeni su konfiguracioni fajlovi koje koristi Configuration klasa za kreiranje proizvođača sesije (SessionFactory), koji zauzvrat kreira instance sesije (Session). Session instanca predstavlja osnovni interfejs ka perzistentnim servisima Hibernate-a.

- 52 -


slika 25.

Osnovni delovi Hibernate-a

Pre konfigurisanja Hibernate-a, neophodno je utvrditi način na koji servis dobija konekcije na bazu podataka. Konekcije na bazu mogu biti obezbeđene kroz Hibernate framework putem JDBC APIa, ili kroz JNDI DataSource interfejs. Hibernate konfiguracioni fajl: com.mysql.jdbc.Driver jdbc:mysql://localhost/curriculum root root 5 org.hibernate.dialect.MySQL5InnoDBDialect thread org.hibernate.cache.NoCacheProvider

-->

true
class="info.komisura.curriculum.beans.InstitutionBean" /> class="info.komisura.curriculum.beans.PlanBean" /> class="info.komisura.curriculum.beans.CourseBean" /> class="info.komisura.curriculum.beans.ItemBean" /> class="info.komisura.curriculum.beans.SubjectBean" /> class="info.komisura.curriculum.beans.LiteratureBean" /> class="info.komisura.curriculum.beans.ProfessorBean" />

- 53 -


Svojstvo dialect Hibernate-u govori koji SQL dijalekt da koristi. Iako nije obavezno, poželjno je definisati ovo svojstvo kako bi se osigurala ispravna transformacija HQL iskaza u odgovarajući SQL dijalekt konkretne baze u upotrebi. Svojstvo dialect obezbeđuje informacije o tome da li baza u upotrebi podržava identifikacione kolone, izmenu relacionih tabela, jedinstvene indekse i druge detalje specifične za konkretnu bazu podataka. Hibernate nudi više od dvadeset SQL dijalekata, podržavajući sve veće proizvođače relacionih baza podataka - Oracle, DB2, MySQL, PostgreSQL itd. Hibernate-u su takođe potrebne informacije o lokaciji i imenima fajlova sa podacima za mapiranje, kojima su opisane perzistentne klase. Element mapping definiše ime svakog fajla koji se koristi u mapiranjima kao i njegovu lokaciju koja je relativna u odnosu na putanju aplikacije. Na ovaj način definišemo koje klase želimo da budu perzistentne.

8.3.2.Tapestry Tapestry17 predstavlja framework otvorenog koda za kreiranje dinamičkih, skalabilnih Web aplikacija pisanih u Java jeziku. U borbi za prvi izbor među mnogima, prezentacioni framework Tapestry se nalazi u konkurenciji sa Struts, Velocity, WebWork i Turbine proizvodima. Razvio ga je Howard Lewis Ship kao deo Jakarta projekta u okviru Apache Software Foundation, organizacije za promociju rešenja otvorenog koda sa Apache licencom18 pogodnom za komercijalne proizvode. Tapestry funkcioniše iznad standardnog Java Servlet APIa, te se može izvršavati u bilo kom servlet-kontejneru ili aplikacionom serveru. Korišćenjem Tapestry-a, Web aplikacija se deli u skup stranica, od kojih se svaka konstruiše na osnovu definisanih komponenti. Organizacija Tapestry-a kroz stranice i komponente omogućava automatsko generisanje parametara za konstrukciju URL adresa, perzistenciju podataka na klijentu ili na serveru, validaciju korisnički unetih podataka, internacionalizaciju, izveštavanje o greškama, a na osnovu konteksta u kom se pozivaju navedene akcije. Razvijanje Tapestry aplikacije uključuje kreiranje HTML template-a (XML kompatibilnog, odnosno XHTML template-a) pomoću čistog HTML koda, i kombinovanje istog sa malom količinom Java koda korišćenjem (opciono) XML deskriptor fajlova. Sa Tapestry-em, razvoj aplikacije odvija se u objektnoorijentisanom maniru, korišćenjem objekata kao i metoda i atributa ovih objekata. Distribucija Tapestry-a uključuje preko pedeset gotovih komponenti, a kreiranje novih koje odgovaraju potrebama konkretne aplikacije veoma je jednostavno. Sam framework obavlja znatan deo posla “iza scene”, oslobađajući na taj način programera obaveza vezanih za stanje sesije, pozive osluškivača (listener), renderovanje stranica, upravljanje zalihama objekata (pool), itd. Tapestry komponente ugnježdene su unutar regularnih HTML tagova, kao što je prikazano u sledećem primeru: Naziv predmeta:

Atribut jwcid (Java Web Component ID) identifikuje određenu Web komponentu. U primeru je upotrebljena komponenta Insert, koja ispisuje podatak dobijen iz svojstava odgovarajuće Java klase. Atribut value ukazuje na lokaciju traženog dinamičkog podatka. Prefiks ognl ukazuje na upotrebu OGNL19 (Object Graph Navigation Language) jezika pomoću kojeg se na jednostavan način identifikuju svojstva Java objekata (tj. odgovarajuće 17

Tapestry - http://tapestry.apache.org/ Apache licence 2.0 - http://apache.org/licenses/LICENSE-2.0.html 19 OGNL - http://www.ognl.org/ 18

- 54 -

Milenković Ana - Java tehnologije za pristup relacionim bazama podataka u Web okruženju get() i set() metode). U ovom primeru, pristupa se svojstvu name koje je ugnježdeno unutar svojstva subject iz Java klase. U trenutku izvršavanja koda, dinamički će biti lociran

odgovarajući tekst koji će se ispisati na datoj stranici.

8.3.3.Eclipse Eclipse20 predstavlja razvojno okruženje otvorenog koda (IDE – Integrated Development Environment), čijim razvojem rukovodi Eclipse.org konzorcijum. U sastavu ovog konzorcijuma nalaze se IBM (koji je originalno razvio Eclipse), Borland, Rational Software, Red Hat, SuSE, Oracle i Sybase. Eclipse platforma obezbeđuje servise neophodne za integraciju alata za razvoj softvera koji su implementirani kroz Eclipse plug-in komponente. Osnovne komponente koje su uključene u distribuciju Eclips-a jesu JDT (Java Development Toolkit) za pisanje Java programa i otkrivanje grešaka i PDE (Plug-In Development Environment) za proširivanje Eclips-a novim komponentama. Ukoliko se Eclipse koristi za pisanje programa na primer u C/C++ jeziku, sve što je potrebno jeste dodavanje CDT (C Development Toolkit) plug-in komponente. Dizajn zasnovan na dodacima čini Eclipse proširivim i fleksibilnim. Takođe, platforma veoma dobro definiše način na koji različite plug-in komponente funkcionišu zajedno, u okviru jednog projekta. Uprkos činjenici da je sam Eclipse napisan u Java jeziku i da je njegov najpopularniji oblik korišćenja upravo kao Java IDE, on je jezički neutralan. Kao što je podrška Java jeziku obezbeđena kroz odgovarajuće plug-in komponente, tako postoje i komponente za podršku drugim jezicima kao što su C/C++, Cobol, C# i drugi. Platformska nezavisnost Eclipse-a ogleda se u korišćenju nativnog grafičkog interfejsa operativnog sistema u upotrebi. Eclipse je dostupan na platformama koje podržavaju SWT (Standard Widget Toolkit), što uključuje sve važnije operativne sisteme kao što su Windows, Linux, Solaris, Mac OS, QNX, HP-UX i drugi. 8.3.3.1.Arhitektura Arhitektura Eclipse platforme sastoji se iz nekoliko delova: jezgra platforme, radnog prostora (workspace), radnog okruženja (workbench), komponente za podršku timskom radu, i komponente za pružanje pomoći.

slika 26.

Arhitektura Eclipse-a

Osnovna namena jezgra jeste da ustanovi koje su plug-in komponente dostupne u za to predviđenom direktorijumu. Pošto njihov broj može biti izuzetno velik, sama komponenta se učitava tek onda kada je potrebna. Radni prostor je odgovoran za upravljanje korisničkim resursima, koji su organizovani u jedan ili više projekata. Radni prostor takođe hronološki čuva podatke o izmenama na svakom projektu, čime je omogućen povratak na poslednju sačuvanu verziju projekta. 20

Eclipse - http://www.eclipse.org - 55 -


Radno okruženje predstavlja grafički korisnički interfejs Eclipse-a. U cilju prikazivanja srodnih alatki i opcija, organizovan je u perspektive koje sadrže poglede i editore. Za razliku od drugih Java aplikacija, značajna karakteristika radnog okruženja Eclipse-a jeste da izgleda i ponaša se kao nativna aplikacija. Ovo je moguće zahvaljujući korišćenju SWT i JFace-a, skupa alata korisničkog interfejsa koji je smešten povrh SWT-a. U odnosu na standardne Java grafičke interfejse (AWT i Swing), koji emuliraju nativni grafički skup alata, SWT se direktno mapira na nativni grafički interfejs operativnog sistema u upotrebi, obezbeđujući izgled karakterističan za aplikacije tog operativnog sistema. Komponenta za podršku timskom radu obezbeđuje sistem za kontrolu verzija. Ova komponenta Eclipse platforme ponaša se kao CVS (Concurrent Versions System) klijent.

- 56 -


9. Zaključak Javu kao platformu karakteriše dinamičan razvoj, kako u matičnoj kući (Sun) tako i u okviru mnogobrojnih nezavisnih projekata. Početna inicijativa za standardizovanje pristupa podacima u relacionim bazama podataka, kao osnovnim komponentama u aplikaciji, potekla je od strane Sun-a u obliku JDBC specifikacije. Nakon što je JDBC postao opšteprihvaćen industrijski standard u njegov dalji razvoj su se uključile i druge velike kompanije u zajedničkom poduhvatu organizovanom kroz JCP (Java Community Process). Uz sve mogućnosti koje je JDBC doneo, javila se opravdana potreba za pojednostavljenim pristupom čestim operacijama pri obradi podataka. Došlo je do razvoja raznih nezavisnih rešenja koja višim nivoom apstrakcije omogućuju drastično ubrzanje razvoja aplikacije. Ova rešenja se zajedničkim imenom nazivaju alati za perzistenciju višeg nivoa, koje karakteriše prevođenje podataka iz relacionog modela u objektni model Java jezika. Pošto su pomenuta rešenja naišla na pozitivan odziv, došlo je do novih zahteva za standardizacijom ove oblasti, što je i ostvareno EJB specifikacijom. Opisani trend razvoja tehnologija za pristup podacima sa jedne strane karakterišu nešto slabije performanse usled većeg overhead-a i zahteva za resursima. Međutim, programiranje je prirodnije i jednostavnije, postignut je visok nivo transparentnosti razvoja sistema u distribuiranom okruženju, podržano je više tipova izvora podataka (XML, baze podataka), a u radu se koriste podaci uskladišteni u objektima koji su jasno tipizirani. Logično, kompromisna rešenja koja su dovoljna fleksibilna i omogućavaju izbor nivoa apstrakcije u skladu sa potrebama konkretnog projekta, daju najbolje rezultate.

- 57 -


10.Indeks pojmova A

N

aplet 11,25

nivoi izolacije 24

B

O

bajtkod 9

ODBC 15,17

C

P

CLI interfejs 15 callback metode 37,41

platforma 10 perzistencija 29

E

S

entitet 34,37

servlet 12,13 SQLJ prevodilac 27,28

J

T

JSP 12,13 JPA specifikacija 32,33,38 JNDI interfejs 13,19,21,27

thin klijent 3,4

U

K kontekst perzistencije 38

učitavač klasa 9 URL adresa 20,21

M

F

međutačke transakcije 19,24

fat klijent 3,6

- 58 -

11.Literatura 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

G.Reese: “Database Programming with JDBC and Java”, O’Reilly, 2001. J.Ellis, L.Ho: “JDBC 3.0 Specification”, Sun Microsystems Inc, 2001. R.P.Sriganesh, G.Brose, M.Silverman: “Mastering Enterprise JavaBeans 3.0”, Wiley Publishing Inc, 2006. D.Panda, R.Rahman, D.Lane: “EJB 3 in Action”, Manning Publications, 2006. M.Keith, M.Schincariol: “Pro EJB 3: Java Persistance API”, Apress, 2006. C.Bauer, G.King: “Hibernate in Action”, Manning Publications, 2005. P.Peak, N.Heudecker, “Hibernate Quickly”, Manning Publications, 2006. N.Ford: “Art of Java Web Development”, Manning Publications, 2004. H.L.Ship: “Tapestry in Action”, Manning Publications, 2004. D.Gallardo, E.Burnette, R.McGovern: “Eclipse in Action”, Manning Publications, 2003. http://java.sun.com/javaee/5/docs/tutorial/doc/ http://java.sun.com/docs/books/tutorial/jdbc/basics/index.html http://www.jdocentral.com

Java Tehnologije Za Pristup Relacionim Bazama Podataka u Web Okruzenju

Recommend Documents