dragan bobic komparativna analiza rmi i ejb3.0 tehnologije
DESCRIPTION
dragan-Bobic-Komparativna-analiza-RMI-i-EJB3.0-tehnologijeTRANSCRIPT
UNIVERZITET U BEOGRADU
FAKULTET ORGANIZACIONIH NAUKA
ZAVRŠNI(MASTER) RADKomparativna analiza RMI i EJB 3.0 tehnologije
Ime i prezime studentaDragan Bobić 109/2007
BeogradOktobar, 2009.
i
Komisija koja je pregledala rad i odobrila odbranu:
Mentor: dr Siniša Vlajić, docent
_________________________________________
Član: dr Velimir Štavljanin, redovni profesor
_________________________________________
Član: dr Jelena Jovanović, redovni profesor
_________________________________________
ii
Apstrakt rada
U prvom delu rada će biti predstavljene RMI i EJB 3.0 tehnologije koje se koriste za razvoj distribuiranih aplikacija. Nakon toga će biti prikazani alati za dinamičku analizu softverskih sistema u Netbeans okruženju. Kao ilustracija i praktičan primer korišćenja navedenih tehnologija navodi se studija slučaja „Evidencija radnih naloga“. Studija slučaja će biti realizovana prvo korišćenjem RMI tehnologije, a zatim i korišćenjem EJB 3.0 tehnologije. Zatim sledi prikaz analize dve realizacije studijskog slučaja korišćenjem tehnologija za dinamičku analizu programa u NetBeans okruženju, kao i komparativna analiza dobijenih rezultata.
Ključne reči : distribuirane aplikacije, RMI tehnologija, EJB 3.0 tehnologija, komparativna analiza
Abstract
In first part of this paper I will introduce RMI and EJB 3.0 technologies which are used for distributed application development. After that I will show tools for profiling software systems in NetBeans enviroment. As illustration and example of using these technologies I realize case study „Work Orders Record“ which will be realized using RMI and EJB 3.0 technologies. Next, I will show profiling results for two case study realizations using technologies for software profiling in NetBeans enviroment, and comparative analysis of profiling results.
Keywords : distributed applications, RMI technology, EJB 3.0 technology, comparative analisys
iii
CURRICULUM VITAE
Ime i prezime: Dragan Bobić
E-mail: [email protected]
Državljanstvo: SR Srbija
Datum rođenja: 16. novembar 1982.
Mesto rođenja: Beograd, Srbija
OBRAZOVANJE
Period 2001-2007.Institucija Fakultet Organizacionih Nauka, Univerzitet u Beogradu, Odsek za
informacione sisteme i tehnologijeZvanje Diplomirani inženjer organizacionih nauka, smer za informacione sistemeNaziv diplomskog rada
Veb aplikacija za javne prihode grada Beograda u PHP okuženju
Srednja ocena 7.58
PROFESIONALNI ANGAŽMAN
Period 2009-.
Poslodavac Software ProductPozicija Programer
STRANI JEZICI
Jezik Čitanje Govor PisanjeEngleski Odlično Vrlo dobro OdličnoNemački Srednje Srednje Srednje
VEŠTINE NA KOMPJUTERU
MS Office, OpenOffice, Windows, Linux, PostgreSQL, JAVA, PHP
LIČNI PROFIL
Iskren i otvoren, marljiv, precizan, timski orijentisan, spreman za dalje usavršavanje
OSTALE INFORMACIJE
Vojna obaveza: Regulisana
iv
Sadržaj1.Uvod........................................................................................................................................................12. Poziv udaljenih metoda (Remote Method Invoke)................................................................................4
2.1. RMI osnove....................................................................................................................................42.1.1. Ulazno-izlazni tokovi podataka..............................................................................................42.1.2.Serijalizacija objekata .............................................................................................................62.1.3. Soketi......................................................................................................................................7
2.2.RMI programiranje .........................................................................................................................82.2.1.Komunikacija klijentskog i serverskog objekta .....................................................................82.2.2.Realizacija RMI aplikacije....................................................................................................10
2.2.2.1.Kreiranje serverskog programa ..................................................................................102.2.2.2. Kreiranje klijentskog programa ...................................................................................112.2.2.3.Pokretanje RMI aplikacije.............................................................................................12
2.3. RMI tehnologija...........................................................................................................................132.3.1.Osnovni/Kostur sloj (Stub/Skeletons)...................................................................................142.3.2.Nivo udaljene reference (Remote Reference Layer - RRL) .................................................142.3.3.Transportni sloj......................................................................................................................14
2.4.Rezime poglavlja...........................................................................................................................143.Enterprise Java Beans 3.0.....................................................................................................................15
3.1.Java Enterprise Edition 5...............................................................................................................153.1.1.Komponente JEE arhitekture ................................................................................................163.1.2.EJB izvršno okruženje...........................................................................................................17
3.2.Tipovi enetrprise bean-ova............................................................................................................183.2.1.Session beans.........................................................................................................................18
3.2.1.1.Session Bean program...................................................................................................183.2.1.2.Životni ciklus stateless session bean-a ..........................................................................203.2.1.3.Životni ciklus stateful session bean-a ..........................................................................21
3.2.2.Message Driven Bean(MDB)................................................................................................223.2.2.1.Životni ciklus message driven bean-a ...........................................................................23
3.3.Java Persistence API (JPA)............................................................................................................243.3.1.Entiteti...................................................................................................................................243.3.2.Veze između entiteta .............................................................................................................253.3.3.Upravljanje entitetima...........................................................................................................26
3.3.3.1.Životni ciklus entiteta....................................................................................................263.3.3.2.Kreiranje EntityManager-a............................................................................................27
3.3.4.Upitni jezik............................................................................................................................273.3.4.1.SELECT upiti................................................................................................................273.3.4.2.UPDATE i DELETE upiti..............................................................................................27
3.4.EJB Tehnologija............................................................................................................................283.4.1.JNDI API...............................................................................................................................28
3.4.1.1.JNDI arhitektura............................................................................................................283.4.2.RMI/IIOP...............................................................................................................................29
3.4.2.1.RMI/IIOP arhitektura ....................................................................................................293.4.2.1.1.Stub/Tie sloj ..........................................................................................................293.4.2.1.2.Object Request Brocker - ORB sloj .....................................................................30
v
3.4.3.EJB arhitektura......................................................................................................................303.5.Rezime poglavlja...........................................................................................................................32
4.Larmanova metoda razvoja softverskog sistema..................................................................................334.1.Prikupljanje zahteva od korisnika.................................................................................................33
4.1.1.Predstavljanje slučaja korišćenja...........................................................................................344.2. Analiza..........................................................................................................................................40
4.2.1.Ponašanje softverskog sistema – sistemski dijagram sekvenci.............................................404.2.2.Definisanje ugovora o sistemskim operacijama....................................................................464.2.3.Struktura softverskog sistema-Konceptualni model..............................................................47
4.3.Projektovanje.................................................................................................................................48Slika 18. Arhitektura softverskog sistema......................................................................................484.3.1.Aplikaciona logika RMI realizacije studije slučaja...............................................................48
4.3.1.1.Aplikaciona logika RMI realizacije studije slučaja-Kontroler......................................494.3.1.2.Aplikaciona logika RMI realizacije studije slučaja-Poslovna logika ...........................504.3.1.3.Aplikaciona logika RMI realizacije studije slučaja-Database Broker(DBBR).............58
4.3.2.Aplikaciona logika EJB realizacije studije slučaja................................................................584.3.3.Projektovanje skladišta podatala...........................................................................................654.3.4.Konačan izgled arhitektura RMI i EJB 3.0 realizacije studije slučaja..................................684.3.5.Projektovanje korisničkog interfejsa.....................................................................................70
4.4.Implementacija..............................................................................................................................784.5.Testiranje.......................................................................................................................................784.6.Rezime poglavlja...........................................................................................................................78
5.Dinamička analiza RMI i EJB 3.0 tehnologija.....................................................................................795.1.Monitoring ....................................................................................................................................79
5.1.1.Monitoring RMI realizacije studije slučaja ..........................................................................805.1.2.Monitoring EJB realizacije studije slučaja............................................................................82
5.2.Analiza performansi centralnog procesora....................................................................................845.3.Zaključak dinamičke analize ........................................................................................................87
6.Zaključak...............................................................................................................................................887. Literatura..............................................................................................................................................90
vi
Popis slika:
Slika 1. Konceptualni dijagram..................................................................................................................1Slika 2. Organizacija istraživanja...............................................................................................................3Slika 3. Klase koje reprezentuju ulazno/izlazne tokove bajtova................................................................5Slika 4. Klase koje reprezentuju ulazno/izlazne tokove karaktera.............................................................6Slika 5. Komunikacija klijentskog i serverskog objekta...........................................................................9Slika 6. RMI implementacija...................................................................................................................13Slika 7. Arhitektura JEE aplikacija..........................................................................................................16Slika 8. Životni ciklus stateless session bean-a.......................................................................................21Slika 9. Životni ciklus stateful session bean-a.........................................................................................22Slika 10. MOM(Message Oriented Middleware) arhitektura..................................................................22Slika 11. Životni ciklus Message bean-a..................................................................................................23Slika 12. Životni ciklus entiteta...............................................................................................................26Slika 13. JNDI ahitektura.........................................................................................................................28Slika 14. RMI/IIOP arhitektura................................................................................................................29Slika 15. Session Beans arhitektura.........................................................................................................31Slika 16. Message-Driven Beans arhitekura............................................................................................32Slika 17: Softverski sistem.......................................................................................................................33Slika 18: Arhitektura softverskog sistema...............................................................................................48Slika 19. Aplikaciona logika RMI realizacije studije slučaja..................................................................48Slika 20. Aplikaciona logika EJB realizacije studije slučaja...................................................................58Slika 21. Konačan izgled arhitekture RMI studije slučaja.......................................................................68Slika 22. Konačan izgled arhitekture EJB studije slučaja........................................................................69Slika 23. Ekranske forme.........................................................................................................................70Slika 24. Upotreba dinamičke memorije RMI realizacije studije slučaja................................................80Slika 25. Podaci o sakupljaču smeća RMI realizacije studije slučaja......................................................80Slika 26. Broj aktivnih niti i učitanih klasa RMI realizacije studije slučaja............................................81Slika 27. Upotreba dinamičke memorije EJB realizacije studije slučaja.................................................82Slika 28. Podaci o sakupljaču smeća EJB realizacije studije slučaja.......................................................82Slika 29. Broj aktivnih niti i učitanih klasa EJB realizacije studije slučaja.............................................83Slika 30. Performanse pozivanja udaljenih metoda za RMI i EJB realizacije studije slučaja ................85Slika 31. Performanse pozivanja udaljenih metoda u zavisnosti od broja stavki prodatog materijal koje se u okviru radnog naloga prenose kroz mrežu.......................................................................................86Slika 32.Performanse pozivanja udaljenih metoda u zavisnosti od broja klijenata koji istovremeno pozivaju metodu.......................................................................................................................................86
vii
Popis tabela:
Tabela 1. JPA tipovi veza.........................................................................................................................25Tabela 2. Skladište podataka....................................................................................................................66Tabela 3. Rezultati monitoringa...............................................................................................................83Tabela 4. Performanse pozivanja udaljenih metoda za RMI i EJB realizacije studije slučaja ...............84Tabela 5. Performanse pozivanja udaljenih metoda u zavisnosti od broja stavki prodatog materijala koje se u okviru radnog naloga prenose kroz mrežu................................................................................85Tabela 6. Performanse pozivanja udaljenih metoda u zavisnosti od broja klijenata koji istovremeno pozivaju metodu.......................................................................................................................................86
viii
1. Uvod
Činjenica je da softverski sistemi postaju sve složeniji, a da se softverski inženjeri suočavaju sa sve težim zahtevima i izazovima. Jedan od većih izazova je programiranje distribuiranih softverskih sistema tj. softverskih sistema čije se komponente izvršavaju na udaljenim računarima. Područje istraživanja master rada je razvoj i implementacija distribuiranih informacionih sistema (IS) korišćenjem Java tehnologija. U okviru područja istraživanja konkretan problem koji se istražuje je komparativna analiza RMI i EJB 3.0 tehnologija.
Analizom problema istraživanja dobijamo osnovne koncepte i asocijacije između koncepata koji će biti detaljno razmatrani u radu (slika 1).
Slika 1. Konceptualni dijagram
Komparativna analiza EJB 3.0 i RMI tehnologija će se vršiti na osnovu dinamičke analize1 RMI i EJB 3.0 aplikacija. RMI aplikacija se sastoji od klijentskog i serverskog programa. U osnovi RMI programa se nalazi RMI/JRMP tehnologija (JRMP je standardni protokol pomoću koga komuniciraju udaljeni objekti). Klijentski program poziva metode objekata serverskog programa preko servisa imenovanja(Naming Service). EJB aplikacija se izvršava u okviru EJB kontejnera i realizovana je EJB tehnologijom koja obuhvata Session beans(Stateless i Stateful), Message Driven Beans(MDB), i Java Persistence API2 tehnologije. EJB aplikacija se sastoji od aplikacionog klijenta i EJB modula. Aplikacioni klijent realizuje korisnički interfejs i izvršava se u okviru aplikacionog kontejnera dok EJB modul realizuje poslovnu logiku aplikacije i izvršava se u okviru EJB kontejnera. Prilikom raspoređivanja(deploy) EJB modula kontejner registruje klase za pristup EJB komponentama(Stub) u servisu preslikavanja. Aplikacioni
1 dinamička analiza je praćenje performansi softverskog sistema korišćenjem odgovarajućih softverskih paketa2 Application Programming Interface – API je interfejs koji definiše način na koji aplikacioni program zahteva usluge od
programerske biblioteke i/ili operativnog sistema[Orenstein].
1
klijent preuzima stub klasu pomoću JNDI programerskog interfejsa i poziva metode bean-a. Aplikacioni klijent koristi Java Message Servis(JMS) tehnologiju za pristup MDB-u. Motiv za prijavu ovog rada je interesovanje za Java tehnologiju i razvoj distribuiranih informacionih sistema. Pitanja koja su bila motivacija za izbor teme „komparativna analiza RMI i EJB 3.0 tehnologija“ su :
1) Koja tehnologija omogućava bolje performanse distribuirane aplikacije?2) Koja tehnologija omogućava bolje upravljanje memorijom?3) Koliki je uticaj operativnog sistema(Linux, Windows) na performanse distribuirane aplikacije?4) Koliki je uticaj propusnog opsega mreže na performanse distribuirane aplikacije?
Istraživanje ima za cilj da olakša izbor tehnologije za razvoj distribuirane aplikacije na taj način što ukazuje na parametre koji imaju uticaja na performanse krajnjih softverskih rešenja. Očekivani doprinos master rada ogleda se u realizaciji postavljenih ciljeva:
1) Prikaz udaljenog pozivanja metoda (RMI) i korišćenje te tehnologije u realizaciji klijent-server arhitekture
2) Prikaz EJB 3.0 tehnologije i njene primene u razvoju složenih aplikacija3) Dinamička analiza RMI i EJB 3.0 tehnologija4) Komparativna analiza dobijenih rezultata dinamičke analize
U prvom delu rada je objašnjen je koncept udaljenog pozivanja metoda, prikazane su tehnologije koje su u osnovi udaljenog pozivanja metoda, i navedeno je uputstvo za programiranje aplikacija koje su zasnovane na RMI tehnologiji. Nakon toga je prikazana arhitektura RMI tehnologije i tom smislu je opisan svaki od tri sloja RMI arhitekture : Stub/Skeletons, sloj udaljene reference i transportni sloj.U drugom delu rada je prikazana Java Enterprise Edition specifikacija za razvoj složenih(Enterprise) aplikacija i EJB 3.0 tehnologija koja je sastavni deo JEE specifikacije i namenjana je za programiranje poslovne logike složenih aplikacija. Nakon toga su prikazani Stateful i Message Driven Beans koji se koriste za modeliranje poslovnih procesa poslovnog sistema kao i programerski interfejs koji omogućava perzistentnost Java objekata(Java Persistence API).U trećem delu rada je prikazan razvoj softverskog sistema korišćenjem RMI i EJB 3.0 tehnologija. Metoda koja je korišćena u razvoju je zasnovana na Larmanovoj metodi razvoja softverskih sistema, po kojoj razlikujemo sledeće faze u razvoju softverskih sistema[Larman] :
1. Prikupljanje zahteva2. Analiza3. Projektovanje4. Implementacija5. Testiranje.
Faze prikupljanja zahteva i analize su u potpunosti preuzete od Larmanove metode, dok je faza projektovanja prilagođena tronivojskoj arhitekturi[Vlajić 1]. Razvoj softverskog sistema prati studija slučaja „Evidencija radnih naloga“.U četvrtom delu rada prikazana je komparativna analiza RMI i EJB 3.0 tehnologija. Tehnologije će se komparativno analizirati na osnovu monitoringa3 studije slučaja i vremena izvršenja udaljenih metoda. Na slici 2. je prikazan dijagram aktivnosti (engl. Unified Modeling Language - UML4 activity diagram) koji grafički opisuje organizaciju istraživanja ovog rada.
3 Monitoring aplikacije prikazuje informacije o upotrebi memorije i upravljanju nitima aplikacije.4 Unified Modeling Language – UML je grafički jezik za specifikaciju, konstrukciju, vizuelizaciju, i dokumentovanje softverskih proizvoda.[Veljovic]
2
Slika 2. Organizacija istraživanja
3
2. Poziv udaljenih metoda (Remote Method Invoke)Tehnologija poziva udaljenih metoda omogućava da objekat klijentskog programa poziva metode objekta serverskog programa koji se izvršava u okviru druge Java virtuelne mašine na lokalnom ili udaljenom računaru.
2.1. RMI osnoveU osnovi RMI tehnologije su ulazno-izlazni tokovi podataka(streams), serijalizacija objekata i soketi[RMI 2].
2.1.1. Ulazno-izlazni tokovi podataka
Tok je uređen niz bajtova. Java program koristi ulazni tok (Input Stream) za čitanje bajtova podataka iz nekog izvora (tastatura,datoteka,mreža i dr.), dok izlazni tok (Output Stream) koristi za pisanje bajtova podataka iz programa u navedeno odredište(ekran, datoteka, mreža i dr.). Apstraktne klase iz kojih se izvode navedeni tokovi su java.io.InputStream i java.io.OutputStream[Java API]. InputStream je apstraktna klasa koja reprezentuje izvor podataka, i sadrži metode koje imaju tri najznačajnije uloge: čitanje podataka iz nekog izvora (tastatura,datoteka,mreža i dr.), kretanje kroz tok podataka, oslobađanje resursa operativnog sistema koje je zauzeo ulazni tok.Čitanje podataka omogućava metoda read klase InputStream:
read() - vraća sledeći slobodan bajt u toku podataka.read(byte[] niz) – čita niz bajtova iz nekog ulaznog toka i upisuje ih u niz
Kretanje kroz tok podataka omogućavaju sledeće metode klase InputStream:available() – vraća broj bajtova dostupnih za čitanje skip(long brojBajtova)- preskače brojBajtova bajtovamark(int brojBajtova)- obeležavanje pozicije u toku toku
Oslobađanje resursa operativnog sistema omogućava sledeća metoda klase InputStream:close() – oslobađanje resursa operativnog sistema koje je zauzeo ulazni tok.
OutputStream je apstraktna klasa koja reprezentuje odredište podataka. OutputStream sadrži metode namanjene pisanju podataka u navedeno odredište(ekran, datoteka, mreža i dr.), oslobađanju resursa operativnog sistema koje je zauzeo izlazni tok.Pisanje podataka omogućava metoda write klase OutputStream :
write(byte[] buffer) – upisuje niz bajtova u neki od izlaznih tokova
Upravljanje resursima operativnog sistema omogućavaju sledeće metode klase OutputStream: flush() – transportuje podatake iz bafera izlaznog toka u izlazno odredišteclose() – poziva se kada klijent završi sa čitanjem toka i želi da oslobodi resurse operativnog sistema koje je zauzeo izlazni tok.
Sve klase koje reprezentuju ulazno/izlazne tokove bajtova nasleđuju InputStream/Outputstream klase i prikazane su na slici 3.
4
Slika 3. Klase koje reprezentuju ulazno/izlazne tokove bajtova
Klasa System sadrži statične atribute5 koji se odnose na tokove. To su out, i err koji su tipa PrintStream i in koji je tipa InputStream. Pomenutim objektima se može pristupiti iz bilo kog dela programa preko klase System. Atribut System.in se odnosi na standardni ulazni tok, koji je podrazumevano tastatura. Atribut System.out se odnosi na standardni izlazni tok, koji je podrazumevano ekran, dok se atribut System.err odnosi na standardni tok za greške koji je takođe ekran.Klase Reader i Writer su apstraktne klase slične pomenutim klasama InputStream i OutputStream ali su orijentisane prema karakteru za razliku od pomenutih koje su orijentisane prema bajtu. Time su podržani npr. Unicode, UTF-8 i drugi formati podataka koji svaki karakter predstavljaju sa dva bajta.Metode klase Reader i Writer su analogne metodama klasa InputStream i OutputStream sa razlikom što npr. metoda read klase Reader vraća celobrojnu vrednost u rasponu od 0-65535, dok metoda read klase InputStream vraća broj u intervalu od 0-255.
5 Statični atribut je deljiv za sve objekte klase kojoj pripada kao i za objekte drugih klasa koji mu pristupaju[Ćirić]
5
Slika 4. Klase koje reprezentuju ulazno/izlazne tokove karaktera
Svi tokovi u okviru biblioteke tokova se mogu podeliti na primitivne i posredničke. Primitivni tokovi omogućavaju prenos podataka iz izvora(input) odnosno odredišta(output) u Java programski jezik. Primeri primitivnih tokova su InputStream, OutpuStream, Reader, Writter i dr.Posrednički tokovi se koriste kao omotači (wrap) primitivnih tokova i omogućavaju im dodatne funkcionalnosti npr.BufferedInputStream buffer= new BufferedInputStream(inputStream);
U ovom konkretnom primeru smo ulazni tok proširili BufferedInputStream klasom i omogućili da se podaci iz toka smeštaju u privremenu memoriju(buffer) iz koje kasnije preuzimamo sve podatke iz ulaznog toka.Slojevitost tokova podrazumeva da se jedan posrednički tok može obuhvatiti drugim i na taj način dodati nove mogućnosti postojećeg posredničkog toka.
2.1.2. Serijalizacija objekata
Serijalizacija je proces kojim se konvertuje stanje objekta u niz bajtova. RMI koristi serijalizaciju da prenese stanje objekta između dve virtuelne mašine, bilo kao argumente prilikom poziva udaljenih metoda ili kao povratne vrednosti izvršenih udaljenih metoda. Serijalizacija objekata se vrši kreiranjem objekta6 klase ObjectOutputStream i pozivom writeObject() metode. Učitavanje serializovanog objekta (deserijalizacija) omogućava readObject() metoda klase ObjectInputStream. Pomoću serijalizacije veza između dva ili
6 Objekat predstavlja jedno konkretno pojavljivanje(primerak, instancu) svoje klase[Ciric].
6
više objekta, koja je ostvarena referencama u toku izvršenja programa biva snimljena u navedeno odredište(npr. datoteka) tj. deserijalizacijom se veze između njih obnavljaju. Da bi omogućili serijalizaciju objekata klase, moramo ispuniti četiri uslova :
1. Klasa mora implementirati Serializable interfejs,2. Omogućiti da svi atributi klase budu serijalizovani,3. Omogućiti da nadređena klasa bude serijalizovana,4. Preklopiti metod equals() i hashCode() (nije obavezno)
Samo objekti koji mogu biti serijalizovani se mogu koristiti kao ulazni/izlazni parametri metoda koje se udaljeno pozivaju pomoću RMI tehnologije.
2.1.3. Soketi
Soket je apstrakcija za komunikacioni kanal koji se uspostavlja između dva programa koji se izvršavaju kao odvojeni procesi. Java realizuje sokete koristeći paket java.net, pri čemu su dve osnovne klase za kreiranje soketa java.net.Socket i java.net.ServerSocket[Java API]. Realizacija prenosa podataka između udaljenih računara podrazumeva postojanje pojavljivanja klase Socket na klijentskoj i serverskoj strani. Pomenuta klasa omogućava četiri osnovne soket operacije:
1. Povezivanje(connect) na udaljeni računar2. Slanje podataka3. Prijem podataka4. Zatvaranje konekcije
Kreiranje pojavljivanja klase Soket na serverskoj strani podrazumeva izvršavanje sledeće dve naredbe:
1. Kreiranje pojavljivanja klase ServerSocket, pri čemu se prosleđuje port sa kojim se server soket povezuje7.ServerSocket ss = new ServerSocket(8189);
2. Pozivanje accept() metode klase ServerSocket: public Socket accept( ) throws IOException
Metoda accept() blokira izvršenje programa u smislu da je izvršenje programskih instrukcija koje slede poziv accept() metode moguć jedino ako se klijent poveže sa serverom. Povratna vrednost pozvane metode je pojavljivanje klase Socket koja se koristi za komunikaciju sa jednim povezanim klijentom.Povezivanje(connect) klijenta sa serverskim programom omogućava klasa Socket koja se kreira pozivom sledećeg konstruktora :public Socket(String host, int port)
Promenjiva host je string koji predstavlja simboličku ili IP adresu računara na kome se nalazi serverski soket. Primer za simboličku adresu je www.finansijebgd.org, dok IP adresa 32-bitni broj koji jedinstveno identifikuje računar kome su poslati podaci, npr. 132.163.135.130. Port služi za identifikaciju programa (procesa) koji će da prihvati podatke na klijentskom ili serverskom računaru sa navedenom adresom host. Slanje i prijem podataka preko soketa omogućavaju pojavljivanja klasa InputStram i OutputStram koje se dobijaju kao povratne vrednosti sledeće dve metode klase Socket :
7 Za svo vreme trajanja programa soket osluškuje(prati) rad navedenog porta.
7
public InputStream getInputStream() throws IOExceptionpublic OutputStream getOutputStream() throws IOException
Zatvaranje soketa se realizuje metodom close() klase Socket :public synchronized void close() throws IOException
2.2. RMI programiranje Tehnologija poziva udaljenih metoda(RMI) omogućava da objekat klijentskog programa poziva metode objekta serverskog programa koji se izvršava kao odvojen proces na istom ili nekom drugom računaru u mreži.
RMI tehnologija smanjuje složenost programiranja distribuiranih aplikacija u odnosu na sokete obzirom da korisnik ne programira detalje interakcije između dva udaljena računara. Osnova za razvoj RMI-a je tehnologija udaljenog pozivanje procedura(Remote Procedures Call-RPC)8 koja se pojavila sedamdesetih godina prošlog veka.
2.2.1. Komunikacija klijentskog i serverskog objekta
Osnovni koncepti RMI tehnologije su :1. Klijent i server program – Java aplikacije koju piše programer(korisnik RMI tehnologije), 2. Stub i skeletons klase – klase koje imaju ulogu posrednika preko kojih klijent poziva metode
serverskog objekta.3. RMI izvršno okruženje – omogućava transport podataka koristeći sokete.4. RMI registrator(RMI registry) – servis preslikavanja(naming service)
Koncepti RMI tehnologije su prikazani na slici 5.
8 Remote Procedures Call (RPC) je omogućio proceduralnim programskim jezicima da izvršavaju potprograme na udaljenim računarima
8
slika 5. Komunikacija klijentskog i serverskog objekta
Komunikacija između klijentkog i serverskog programa se realizuje u više koraka:1. Startuje se serverski program koji povezuje stub klasu sa rmi registratorom. Stub klasa se
automatski generiše na serveru, i sadrži neophodne informacije za poziv metoda serverskog objekta.
2. Klijentski program prihvata pojavljivanje stub klase od RMI registratora.3. Klijent poziva metodu serverskog objekta koristeći Stub klasu. Stub klasa prihvata zahtev za
izvršavanje metode serverskog objekta, i prosleđuje ga RMI izvršnom okruženju koji ga transformiše i prenosi kroz mrežu do servera. Informacioni blok koji se transportuje kroz mrežu se sastoji od [Vlajić 2] :
Identifikatora serverskog objekta Opisa metode koja se poziva Kodiranih(serijalizovanih) ulaznih parametara metode. Proces kodiranja parametara se
naziva parameter marshaling, i omogućava prenos ulaznih parametara motode kroz mrežu.
4. RMI izvršno okruženje servera prihvata informacioni blok koji je poslao klijent i prosleđuje ga Skeletons klasi koja dekodira prihvaćeni blok i poziva metodu kojoj šalje odgovarajuće ulazne parametre klijenta. Nakon toga, prihvata izlazne vrednosti pozvane metode, kodira ih, i posredstvom rmi izvršnog okruženja ih prosleđuje klijentu .
5. Stub klasa vrši dekodiranje podataka koje je dobila od servera i prosleđuje ih klijentskom programu.
9
2.2.2. Realizacija RMI aplikacije
Realizacija RMI aplikacije podrazumeva sledeće korake :• Kreiranje serverskog programa • Kreiranje klijentskog programa• Kompajliranje i pokretanje programa
2.2.2.1. Kreiranje serverskog programa
Serverski program u kontekstu RMI tehnologije sadrži[Vlajic 2] :1. Interfejs koji definiše skup metoda koje se udaljeno pozivaju2. Klasu koja implementira metode navedenog interfejsa3. Klasu koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru(engl. RMI
Registry)
Interfejs serverskog programa se naziva udaljeni interfejs i ima sledeće karakteristike:• Nasleđuje interfejs java.rmi.Remote• Svaka metoda interfejsa baca java.rmi.RemoteException izuzetak npr.
public interface KontrolerAL extends Remote{ public void izmeni(ArtikalDTO dto)throws
RemoteException,ArtikalNePostojiException;...
U nastavku navodimo primer klase serverskog programa koja implementira metode udaljenog interfejsa :
public class KontrolerALImpl implements KontrolerAL{ public int izmeni(ArtikalDTO dto)throws
RemoteException,ArtikalNePostojiException{ Artikal artikal = new Artikal(); artikal.postaviArtikal(to); IzmeniArtikal.izvrsi(artikal); }....
Klasa koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru izvršava sledeće naredbe : KontrolerAL obj = new KontrolerALImpl(); KontrolerAL stub = (KontrolerAL) UnicastRemoteObject.exportObject(obj, 0); LocateRegistry.getRegistry().bind("Racun", stub);Statična metoda UnicastRemoteObject.exportObject(obj, 0) automatski kreira serverski soket i prihvata pozive klijenta ka metodama udaljenog objekta. Kao ulazni argument se pored udaljenog objekta navodi i port na kome se očekuju budući pozivi metoda. Kao rezultat izvršenja metode dobija se Stub klasa za prosleđeni objekat. Stub klasa predstavlja referencu udaljenog objekta koja se prenosi na klijentski računar i pomoću koje klijenti pozivaju udaljene
10
metode. Klijent prihvata referencu pomoću servisa preslikavanja(naming sevice) koji se naziva rmi registrator (engl. RMI registry). Povezivanje serverskog objekta sa rmi registratorom se obavlja pozivom bind(String ime, Remote obj) metode java.rmi.Naming klase. Ulazni argumenti metode su udaljeni objekat i njegovo simboličko ime. Klijenti koriste simboličko ime da bi jedinstveno identifikovali udaljeni objekat u rmi registratoru. U nastavku je dat prikaz serverske klase koja kreira serverske objekte i registruje kreirane objekte u rmi registratoru :
public class KontrolerALServer { public static void main(String[] args){
try { KontrolerAL obj = new KontrolerALImpl(); KontrolerAL stub = (KontrolerAL) UnicastRemoteObject.exportObject(obj, 0); Registry registry = LocateRegistry.getRegistry(); registry.bind("Stub", stub); System.out.println("Server spreman...");} catch (Exception e) { System.err.println("Server exception: " + e.toString()); }
}
2.2.2.2. Kreiranje klijentskog programa
Klijentski program u kontekstu RMI tehnologije sadrži[Vlajic 2] :1. Klasu koja implementira klijentski program2. Interfejs koji definiše skup operacija(metoda) koje poziva klijentski program
Klasa koja implementira klijentski program obavezno izvršava sledeće naredbe : Registry registry = LocateRegistry.getRegistry(„192.168.0.1.“,1099);
KontrolerAL stub = (KontrolerAL) registry.lookup("Stub"); stub.izmeni(dto);//poziv udaljene metodeStatična metoda LocateRegistry.getRegistry(„207.105.25.253“,1099) omogućava pristup rmi registratoru koji je pokrenut na računaru sa mrežnom adresom(IP) 207.105.25.253. i portu 1099. Poziv lookup metode java.rmi.Naming klase vraća pojavljivanje Stub klase koja predstavlja serijalizovanu kopiju objekta koji u registratoru ima logičko ime Stub. Klijent koristi Stub klasu da direktno pozove metode na serveru bez korišćenja registratora. Pozivanje metode udaljenog objekta se obavlja posredstvom stub interfejsa koju dobijamo od RMI registratora. Interfejs klijentskog programa ima istu implementaciju kao i interfejs serverskog programa. Dobija se kao rezultat poziva lookup metode, i omogućava poziv udaljenih metoda.Primer klijentskog programa iz studijskog primera :
public interface KontrolerAL extends Remote{ public void izmeni(ArtikalDTO dto)throws RemoteException,ArtikalNePostojiException;
...}
11
public class Client { public static void main(String[] args){ try{
Registry registry = LocateRegistry.getRegistry(„192.168.0.1.“,1099); KontrolerAL stub = (KontrolerAL) registry.lookup("Racun"); stub.izmeni(new ArtikalDTO(1,“Bobina”,3)); } catch (Exception e) { System.err.println("Client exception: " + e.toString()); e.printStackTrace(); } }
}
2.2.2.3. Pokretanje RMI aplikacije
Pokretanje serverskog programa podrazumeva:1. pokretanje rmi registratora - registrator objekata se pokreće pozivom datoteke
rmiregistry.exe koja se sastavni deo JDK-a.
2. podešavanje sledećih svojstava(properties) za Java virtualne mašine koje izvršavaju serverski i klijentski program :
a) java.rmi.server.codebase (baza koda) b) java.java.security.manager (kreiranje menadžera zaštite)c) java.security.policy (definisanje dozvola za menadžer zaštite)
Svojstva virtuelne mašine se postavljaju prilikom pokretanja programa u komandnoj liniji na sledeći način :
java –Dsvojstvo=vrednost imePrograma
Postavljanjem svojstva java.rmi.server.codebase omogućeno je definisanje lokacija na mreži gde se nalaze class datoteke serverskog programa npr. -Djava.rmi.server.codebase = http://localhost/bdragan. Prilikom registrovanja serverskog objekta u rmi registratoru, navedena baza koda se prosleđuje kao anotacija(metapodatak) reference serverskog objekta(Stub klase). Kada klijent zatraži Stub klasu sa navedenim logičkim imenom, rmi registrator vraća klijentu pojavljivanje stub klase i pomenutu anotaciju. Virtuelna mašina koja izvršava klijentski program prvo pokušava da učita class datoteku Stub-a lokalno tj. pretražujući poznate putanje pretrage klasa(Classpath). Ako se class datoteka stub-a ne može učitati lokalno onda se pretražuje baza koda koja je preuzeta od rmi registratora i klasa se dinamički učitava sa lokacije koja je navedena u bazi koda.Ukoliko se prilikom poziva udaljene metode prosledi ulazni argument referentnog tipa za koji u poznatim putanjama pretrage klasa(Classpath) servera ne postoji class datoteka, baza koda koja je definisana prilikom pokretanja klijentskog programa se koristi da bi se dinamički preuzela potrebna class datoteka. Analogno tome klijentski program preuzima bazu koda koja je definasana prilikom pokretanja servera za povratne vrednosti udaljenih metoda koje ne postoje u putanjama pretrage klasa klijenta.
12
Svojstvo java.security.manager kreira menadžer zaštite za pokrenutu aplikaciju. Menadžer zaštite kontroliše da li kod koji izvršava virtuelna mašina ima pristup pojedinim resursima operativnog sistema na lokalnom računaru. Dozvole za menadžer zaštite se postavljaju pomoću datoteke za prodešavanje dozvola(policy file). Datoteka za prodešavanje dozvola definiše koje dozvole su odobrene za kod koji se poziva sa određene lokacije. Primer datoteke za prodešavanje dozvola koja dozvoljava kodu čitanje svojstava operativnog sistema ima sledeći sadržaj :
grant { permission java.util.PropertyPermission "java.vendor", "read";
};
Povezivanje programa sa datotekom za podešavanje dozvola izvršavamo na taj način što u argumentu prilikom pozivanja programa postavimo java.security.policy svojstvo. npr. java -Djava.security.policy=policy.dat i navede se putanja do fajla definiše putanju polise koja se koristi.
2.3. RMI tehnologija
RMI implementacija se sastoji od tri sloja :1. Osnovni/Kostur sloj (Stub/Skeletons)2. Sloj udaljene reference(Remote reference)3. Transportni sloj
Prilikom poziva udaljene metode od strane klijenta, poziv prolazi kroz osnovni sloj i ide u referentni sloj, koji obavlja proces pakovanja objekata i prosleđuje iste preko transportnog sloja do servera. Transportni sloj na serveru prihvata poziv i prosleđuje ga do referentnog nivoa, gde dolazi do raspakivanja argumenata i prosleđivanja do kostur nivoa, a zatim do implementacije servera. Prilikom vraćanja vrednosti udaljenog metoda prolazi se ista putanja.Postojanje tri sloja omogućava svakom sloju da bude nezavisno kontrolisan odnosno implementiran. Arhitektura RMI implementacije je prikazana na slici 6.
Slika 6. RMI implementacija
13
stub skeletons
sloj udaljene reference
transportni slojRMI implementacija
klijent server
2.3.1. Osnovni/Kostur sloj (Stub/Skeletons)
Stub klasa je pomoćna klasa koju RMI automatski generiše na serveru, i koju koristi klijentski program za pozivanje metoda serverskog objekta. Stub klasa sadrži metodu sa istim potpisom kao i udaljena serverska metoda koja se poziva i koja izvršava sledeće :
1. Prihvata poziv udaljene metode sa prosleđenim argumentiima od klijenta.2. Serijalizuje argumente metode koji su prosleđeni sa klijenta i prosleđuje ih sloju udaljene
reference(remote reference). 3. Čeka rezultate izvršene metode4. Deserijalizuje povratne vrednosti5. Vraća vrednosti pozivaocu
Stub klasa sakriva serijalizaciju parametara, i mrežnu komunikaciju sa drugom virtuelnom mašinom i na taj način omogućava klijentu jednostavan mehanizam za udaljeno pozivanje metoda. Skeletons je deo koda koji se automatski generiše i omogućava deserijalizaciju argumenata udaljenih poziva, poziv metode serverskog objekta, serijalizaciju podataka koji su nastali kao rezultat izvršenja od RMI izvršnog okruženja, i prosleđivanje podataka RMI izvršnom okruženju.
2.3.2. Nivo udaljene reference (Remote Reference Layer - RRL)
Nivo udaljene reference ima ulogu posrednika između stub/skeletons klasa i transportnog sloja. Uloga pomenutog sloja je da prevede reference na lokalne objekte u reference na distribuirane objekte tj. da kreira objekat klase ObjId, koji sadrži identifikator objekta i identifikator adresnog prostora(virtuelne mašine) u okviru koga se objekat izvršava, i koji jedinstveno identifikuje udaljeni objekat. Implementacija RRL-a određuje semantiku poziva serverske metode. Primeri implementacija RRL-a su:
1. Poziv jedne reference prema drugoj referenci na serveru (engl. unicast point-to-point)2. Pozivanje perzistentne reference na serveru(aktivacija objekta) 3. Poziv jedne reference klijenta ka više referenci na različitim serverima i td.
2.3.3. Transportni slojTransportni sloj je odgovoran za kreiranje i održavanje soket veza(engl. socket connections) koje sloj udaljenih referenci koristi da prenese pozive od klijenta do servera. Kreirana soket veza se može koristiti za izvršavanje više poziva ka serverskom objektu. Nivo udaljene reference kreira pojavljivanje klase ObjId na osnovu koga soketi, koji se koriste više puta, mogu da identifikuju serverski objekat koji izvršava poziv. Transportni sloj isključuje veze koje se ne koriste određeno vreme (10 minuta). Format i redosled poruka koje razmenjuju klijent i server je definisan Java Remote Method Protocol (JRMP) protokolom.
2.4. Rezime poglavljaU ovom poglavlju je dat prikaz RMI tehnologije. Prikazani su koncepti koji su u osnovi RMI-a tj. Java tokovi, soketi i serijalizacija. Prikazana je procedura za pisanje RMI aplikacija i dat je opis RMI implementacije. Na taj način je realizovan prvi cilj istraživanja (Dati prikaz udaljenog pozivanja metoda (RMI) i korišćenje te tehnologije u realizaciji klijent-server arhitekture).
14
3. Enterprise Java Beans 3.0Enterprise JavaBeans je standardna Java tehnologija za kreiranje poslovne logike distribuiranih aplikacija. Razlozi za korišćenje EJB tehnologije su :
1. EJB komponente se izvršavaju u okviru servera koji obezbeđuje usluge upravljanja transakcijama, upravljanje životnim ciklusom bean-ova, sigurnost dr. koje značajno smanjuju napor korisnika koji ne mora da programira usluge servera. Korisnici EJB tehnologije su fokusirani na programiranje poslovne logike aplikacije.
2. EJB tehnologija omogućava pozivanje operacija bean-a sledećim tipovima klijenata : servlet, JSP, Web servis, druga Java aplikacija, druga EJB komponenta, CORBA klijent i dr. , što omogućava fleksibilnost u razvoju programa u smislu da se operacije bean-a mogu pozivati preko Interneta, PDA uređaja i dr.
3. Enterprise Java Bean-ovi su modularne softverske komponente u smislu da programer može koristiti postojeće bean-ove za kreiranje novih aplikacija.
4. Nezavisnost od platforme na kojoj se bean izvršava. EJB aplikacija može da se izvršava u okviru svakog kontejnera koji implementira EJB specifikaciju, nezavisno od proizvođača kontejnera.
5. EJB je standardna Java tehnologija za razvoj distribuiranih aplikacija i postoji od 1998. godine što znači da postoji dosta literature za njeno korišćenje.
Enterprise Java Beans 3.0 je sastavni deo Java Enterprise Edition 5 specifikacije.
3.1. Java Enterprise Edition 5Java Enterprise Edition (JEE) je specifikacija za razvoj složenih(enterprise) aplikacija. JEE je nadskup tj. proširuje Java Standard izdanja (Java Standard Edition) i obuhvata veliki broj tehnologija koje omogućavaju brz i lak razvoj složenih aplikacija. Tehnologije koje proširuju JSE su:
1. Tehnologije za razvoj aplikacija koje obrađuju XML dokumente i implementiraju Web servise
● Java XML-Web Service API (JAX-WS 2.0)
● Java XML-RPC API (JAX-RPC 1.1)
● SOAP Attachments API za Javu(SAAJ)
● Java arhitektura za XML povezivanje (JAXB 2.0)
● Java API za parsiranje XML dokumenata (StAX)
● Metapodaci web sevisa
2. Web tehnologije za razvoj prezentacionog nivoa JEE aplikacije
● Java server oblici (Java Server Faces - JSF 1.2)● Java server strane (Java Servlet Pages - JSP 2.1)● Java server strane sa standardnom bibliotekom tagova (JavaServer Pages Standard Tag
Library - JSTL) ● Java servleti (Java Servlet 2.5)
15
3. Tehnologije za razvoj složenih aplikacija
● Enterprise Java Beans 3.0
● J2EE arhitektura za povezivanje( J2EE Connector Arcitecture 1.5)
● Java API za perzistenciju (Java Persistence API - JPA)
● Java API za transakcije(Java Transaction API - JTA)
● Java API za elektronsku poštu (Java Mail)
● Java sevrvis za kreiranje,slanje,prihvatanje i čitanje poruka(Java Message Service - JMS)
4. Tehnologije za upravljanje i sigurnost
● Java API za autorizaciju (Java Authorization Contract for Containers)
● Java tehnologija za saradnju sa sistemima za upravljanje i protokolima. (Java Management)
● Java API za izvršavanje aplikacija (Java Deployment)
3.1.1. Komponente JEE arhitekture
JEE arhitektura definiše četiri tipa komponenti složene aplikacije(slika 7). JEE komponenta je jedinica softverkog sistema koja se uklapa u JEE aplikaciju tako što komunicira sa ostalim komponentama. Svaka aplikaciona komponenta se izvršava u odgovarajućem kontejneru tj. Java izvršnom okruženju koje obezbeđuje potrebne tehnologije za izvršavanje komponente aplikacije.
slika 7. Arhitektura JEE aplikacija[JEE 3]
16
Razlikujemo sledeće JEE komponente:1. Aplikacioni klijent i apleti su komponente koje se izvršavaju na klijentu. Aplikacioni klijent je
Java program koji realizuje korisnički interfejs aplikacije kao kod tradicionalnih(desktop) programa. Najčešće se realizuje korišćenjem Swing ili AWT paketa, ali može biti i aplikacija koja se izvršava sa komandne linije. Aplikacioni klijent može komunicirati sa Web, EJB kontejnerom kao i sa bazom podataka. Aplet realizuje korisnički interfejs aplikacije u okviru Web pretraživača(browser) ili neke druge aplikacije koja podržava aplete. Komunicira sa Web kontejnerom.
2. Web komponente se izvršavaju na serveru i mogu biti servleti ili strane. Strane se kreiraju korišćenjem java server strana(JSP) i/ili java server oblika(JSF). Servleti su java programi koji dinamički obrađuju HTTP zahteve klijenta i formiraju odgovarajuće odgovore. JSP i JSF tehnologije su apstrakcija servleta koja omogućava njihovo jednostavnije kreiranje korišćenjem tagova.
3. Enterprise JavaBeans (EJB) komponente se izvršavaju na serveru i sadrže poslovnu logiku9 JEE aplikacije.
3.1.2. EJB izvršno okruženje
EJB komponente se obavezno izvršavaju u okviru EJB kontejnera koji obezbeđuje izvršno okruženje za enterprise bean-ove. EJB kontejner kreira i upravlja bean-ovima u toku njihovog izvršenja i obezbeđuje sledeće usluge bean-ovima :
1. Upravljanje transakcijama10 – EJB kontejner je odgovoran da automatski upravlja tj. startuje i potvrdi/poništi transakcije bean-a. Na taj način programer nije obavezan da upravlja transakcijama u programskom kodu bean-a. EJB kontejner omogućava upravljanje lokalnim i distribuiranim transakcijama. Lokalne transakcije jedinstveno izvršavaju skup operacija na jednoj bazi podataka, dok distribuirane transakcije jedinstveno izvršavaju skup operacija na više baza podataka koje se nalaze na različitim računarima.
2. Sigurnost bean-ova – EJB kontejner je odgovoran proveri identitet(authentication) i dodeljena ovlašćenja(authorization) za svakog klijenta koji pristupa bean-u i da zabrani pozive koji nisu u skladu sa dozvolama koje je programer definisao u okviru aplikacionog servera.
3. Upravljanje resursima i životnim ciklusom bean-a – kontejner kreira bean-ove u memoriji, uništava ih, aktivira/deaktivira kreirane bean-ove u zavisnosti od broja klijenata koji pozivaju metode bean-a. Na taj način se smanjuje broj neophodnih bean-ova za izvršavanje zahteva klijenata.
4. Udaljeni pristup – kontejner omogućava klijentskim programima koji se izvršavaju na drugoj virtuelnoj mašini da udaljeno pristupaju bean-u .
5. Obrada više istovremenih zahteva za bean-om – prilikom istovremenih zahteva klijenata kontejner ili kreira novu instancu ili čeka da se zauzeti bean oslobodi.
9 Poslovna logika je deo softverskog sistema koji upravlja razmenom informacija između korisničkog interfejsa i baze. 10 Transakcija je skup operacija nad bazom podataka koje predstavljaju jednu logičku celinu i izvršavaju se po principu
„sve ili ništa“.
17
3.2. Tipovi enetrprise bean-ova
Dosadašnji EJB standardi su definisali tri vrste JavaBean-ova; to su session beans, message driven beans i entity beans. EJB 3.0 zadržava session beans i message driven beans, dok je entity beans zamenjen sa entitetima(Entities) koji su izdvojeni u Java Persistence API specifikaciju koja je sastavni deo EJB 3.0. Na osnovu toga razlikujemo dva tipa enterprise bean-ova :
1. Session beans2. Message-Driven Beans
3.2.1. Session beansSession bean-ovi modeliraju poslovne procese aplikacije. Klijent pristupa aplikaciji koja se nalazi na serveru pozivom metoda session bean-a.Razlikujemo stateless i stateful session bean-ove.Stateless sesion bean podrazumeva klijent-bean konverzaciju11 koja obuhvata jedan poziv metode bean-a od strane klijenta. Stateless session bean održava stanje specifično za klijenta samo za vreme trajanja poziva metode, i zbog toga se kaže da stateless session bean ne održava konverzaciono stanje. Stateless session bean se koristi za modeliranje poslovnih procesa čija je priroda takva da klijent šalje samo jedan zahtev na koji dobija odgovor npr. provera kreditnih kartica. Korisnik unosi podatke o kartici koje prihvata stateless session bean koji obaveštava korisnika da li je kartica validna. Nakon izvršenog zadatka bean čeka drugi poziv bez ikakvih informacija o prethodnom korisniku.Stateful session bean podrazumeva klijent-bean konverzaciju koja se sastoji od više poziva metoda ili transakcija, zbog čega stateful session bean mora održavati stanje klijenta. Održavanje stanja podrazumeva da ako se između poziva metoda promeni stanje(promena vrednosti nekog atributa) stateful bean-a to stanje se održava do kraja rada klijenta. Ukoliko klijenti ne pozivaju stateful bean metode dovoljno dugo, kontejner oslobađa primarnu memoriju na taj način što stanje bean-a prebacuje u sekundarnu memoriju tj. prebacuje bean u pasivno stanje(keširanje bean-a). Bean se nalazi u sekundarnoj memoriji do sledećeg poziva klijenta kada kontejner vraća bean u primarnu memoriju tj. aktivno stanje.
3.2.1.1. Session Bean program
Implementacija session bean program-a se sastoji od dva dela : jednog ili više interfejsa, i bean klase.Interfejs preko koga klijent pristupa metodama session bean-a se naziva poslovni interfejs. Razlikujemo lokalne(Local), udaljene(Remote), i web servis(Web service) poslovne interfejse. Klijent može pristupiti bean-u preko lokalnog interfejsa jedino ako se izvršava u okviru istog kontejnera kao i bean kome pristupa. Klijent koji pristupa bean-u lokalno se naziva lokalni klijent i može biti drugi enterprise bean ili web komponenta. Lokalni interfejs je označen @Local anotacijom12. Klijenti koji se izvršavaju u okviru istog ili drugog kontejnera pritupaju bean-u preko udaljenog interfejsa. Klijent koji pristupa bean-u udaljeno se naziva udaljeni klijent i može biti druga java aplikacija, aplet, servlet, ili CORBA klijent. Udaljeni interfejs se označava @Remote anotacijom.Web servis klijent pristupa stateless session bean-u preko web servis poslovnog interfejsa. U slučaju Java klijenta pristup omogućavaju JAX-WS i JAX-RPC programerski interfejsi(API). Web servis klijent je označen anotacijom @WebService. Stateful session bean klasa ne može implementirati web servis interfejs.
11 Konverzacija podrazumeva razmenu informacija između klijenta i bean-a.12 Anotacija je metapodatak koji se dodaje kodu i omogućava lakše korišćenje programerskih interfejsa(API)
18
Primer poslovnog interfejsa iz studijskog primera:
@Remotepublic interface ArtikalKontroler { public void obrisi(ArtikalPKTO pk) throws EntityNotFoundException;...}
Anotacija @Remote označava da će bean-u pristupati udaljeni klijenti tj. da je ovo udaljeni poslovni interfejs.
Session bean klasa implementira metode navedene u jednom ili višе poslovnih interfejsa. Bean klasa je označena @Stateless ili @Stateful anotacijom koja označava tip bean-a. Anotacije imaju sledeće atribute:
1. name – označava ime bean-a. Većina kontejnera koriste ovaj parametar za dodelu simboličkog imena u servisu preslikavanja.
2. mappedName – značenje parametra je određeno kontejnerom koji se koristi. Aplikacioni server GlassFish koristi ovaj parametar za dodelu simboličkog imena u servisu preslikavanja.
3. description – opis session bean-a
Stateless session bean klasa može implementirati dva tipa povratnih metoda(engl. callback method) : 1. Metode koje se pozivaju nakon što je bean kreiran u memoriji i ubačeni svi resursi tj. kada se
dogodi PostConstruct događaj. Navedene metode su označene @PostConstruct anotacijom.2. Metode koje se pozivaju kada se bean briše iz memorije tj. kada se dogodi PostDestroy događaj.
Pomenute metode imaju @PostDestroy anotaciju.Stateful session bean se može registrovati za PostConstruct, PostDestroy, PrePassivate i PostActivate događaje:
1. Metoda sa anotacijom @PrePassivate se izvršava pre nego što kontejner prebaci bean u pasivno stanje,
2. @PostActivate metod se poziva nakon što se bean vrati u aktivno stanje.Primer session bean klase iz studijskog primera : @Stateless(mappedName="ArtikalKontroler") public class ArtikalKontrolerBean implements ArtikalKontroler { @PersistenceContext private EntityManager entityManager; public void obrisi(Integer pk)throws EntityNotFoundException { Artikal artikal =new Artikal(pk); Object object = this.find(artikal, artikal.getPKArtikla()); try {
entityManager.remove(object); } catch (Exception ex) { System.err.println("ArtikalKontrolerBean.obrisi cought exception : " +
ex.getMessage()); } }
Primer aplikacionog klijenta iz studijskog primera :
19
public class Main { public static void main(String[] args) { try { Context ctx = new InitialContext(); ArtikalKontroler stub = (ArtikalKontroler)
con.lookup("ArtikalKontroler"); stub.obrisi(new Integer(1)); } catch (NamingException ex) {} } }
3.2.1.2. Životni ciklus stateless session bean-a
Životni ciklus stateless session bean-a ima dva stanja : ne postoji(Does Not Exist) i spreman za pozivanje(Method-Ready Pool). Stanje ne postoji podrazumeva da bean još nije kreiran u memoriji. Kontejner u zavisnosti od broja poziva klijenata bean-ove prebacuje u stanje spreman za pozivanje. Spreman za pozivanje znači da je bean kreiran u memoriji ali da se ne koristi. Kada klijent pozove metod bean-a kontejner prosleđuje poziv jednom od bean-ova iz grupe spremnih za pozivanje. Prelaz u fazu spreman za pozivanje podrazumeva tri koraka :
1. Životni ciklus stateless session bean-a započinje onda kada kontejner kreira novo pojavljivanje session bean-a u memoriji.
2. Kontejner ubacuje(injects) sve resurse koji su navedeni u metapodacima bean-a. Resursi se mogu navesti pomoću anotacija ili u XML datoteci(XML descriptor).
3. Nakon kreiranja bean-a EJB kontejner šalje post-construction događaj (event). Bean klasa se može registrovati za ovaj događaj implementacijom povratne(callback) metode tj. Implementacijom metode koja je obeležena @javax.annotation.PostConstruct anotacijom. Kontejner poziva ovaj metod odmah nakon instanciranja bean-a.
Beanovi prelaze iz skupa bean-ova spremnih za pozivanje u stanje ne postoji onog momenta kada kontejner odluči da smanji broj bean-ova iz memorije. Proces počinje tako što EJB kontejner šalje pre-destroy događaj tj. poziva metodu sa @PreDestroy anotacijom ukoliko postoji koja se najčešće koristi za oslobađanje zauzetih resursa.Životni ciklus stateless session bean-a je prikazan na slici 8.
20
slika 8. Životni ciklus stateless session bean-a
3.2.1.3. Životni ciklus stateful session bean-a
Stateful session je ceo životni ciklus posvećen jednom klijentu tj. ne postoji mogućnost da jedan klijent koristi više pojavljivanja stateful session bean-a. Životni ciklus stateful session bean-a ima tri stanja : ne postoji, spreman za pozivanje, i pasivan.
1. Stanje ne postoji podrazumeva da bean nije kreiran u memoriji.2. Stanje spreman za pozivanje podrazumeva da je bean kreiran u memoriji i da može izvršiti
zahteve klijenta. Prelaz u stanje spreman za pozivanje započinje kada klijent prvi put pozove neku metodu bean-a. Kontejner tada kreira pojavljivanje stateful bean-a u memoriji, zatim ubacuje(injects) sve resurse koji su navedeni u metapodacima bean-a i poziva metodu sa @PostConstruct anotacijom, ako postoji.
3. Stanje pasivan podrazumeva da se bean nalazi u periodu kada klijent ne poziva metode,ali bean održava konverzaciono stanje sa klijentom. Zbog smanjenja korišćenja resursa, algoritam za keširanje kontejnera prebacuje pojavljivanje bean-a u pasivno stanje. Prelaz u pasivno stanje počinje pozivom @PrePassivate metode bean-a. Kada se izvrši povratna metoda kontejner snima stanje bean-a u sekundarnu memoriju. Ako klijent pozove metod pasivnog bean-a kontejner aktivira stateful bean iz sekundarne memorije i poziva @PostActivate metod, ako postoji.
Životni ciklus stateful session bean-a je prikazan na slici 9.
21
Ne postoji(Does Not Exists)
Skup bean-ova spremnih za pozivanje(Method-Ready Pool)
1. kreiraj session bean2. ubacivanje zavisnosti (dependency injection) 3. @PostConstruct
1. @PreDestroy
pozivi klijenata
Slika 9. Životni ciklus stateful session bean-a
3.2.2. Message Driven Bean(MDB)
MDB je tip EJB-a koji ima ulogu korisnika poruka u Message Oriented Middleware - MOM arhitekturi. Message-oriented middleware je izraz za softver koji omogućava razmenu poruka između različitih sistema preko mreže. MOM je infrastruktura koja se sastoji od :
1. proizvođača poruka(message producer)2. srednjeg sloja (message middleware)3. korisnika poruka(message consumer) (slika 10.)
Kada proizvođač pošalje poruku srednji sloj je prihvata i prosleđuje je ka korisniku. U poređenju sa direktnom komunikacijom komponenti npr. (RMI-IIOP koji koriste Session bean-ovi), komunikacija preko posrednika omogućava sledeće prednosti: asinhrona obrada poruka, razdvajanje pošiljaoca i primaoca poruke, pouzdana isporuka poruke, podrška za više pošiljalaca i primalaca itd.
slika 10. MOM(Message Oriented Middleware) arhitektura
22
Ne postoji(Does Not Exists)
1. kreiraj stateful bean2. ubacivanje zavisnosti (dependency injection) 3. @PostConstruct
1. @PreDestroy
pozivi klijenata Skup bean-ova spremnih za pozivanje
(Method-Ready Pool)Pasivno stanje
(Passive)
prekid(time out)
@PrePassivate @PostActivate
prekid(time out)
Java Messaging System je standardni programerski interfejs (API) koji koriste Java programeri za pristup MOM sistemima.
MDB ima karakteristike slične session bean-u:
1) ne održava konverzaciono stanje za klijenta koji mu pristupa.
2) pojavljivanja MDB su ekvivalentna što omogućava da više korisnika poziva jedno pojavljivanje bean-a.
Klijent ne može pristupiti MDB-u preko poslovnog interfejsa. Jedini način na koji klijenti pristupaju je putem sistema poruka.
3.2.2.1. Životni ciklus message driven bean-a
Message driven bean ima dva stanja : ne postoji, i spreman za pozivanje. Stanje ne postoji označava da bean još nije kreiran u memoriji. Bean-ovi prelaze u stanje spreman za pozivanje onog momenta kada kontejner ne može da obradi sve poruke koje dolaze od klijenata za bean-ovima koji su kreirani u memoriji. Prilikom prelaska iz stanja ne postoji u stanje spreman za pozivanje kontejner realizuje tri koraka :
1. Kontejner poziva newInstance() metod MDB klase i na taj način kreira novo pojavljivanje.2. Kontejner ubacuje(injects) sve resurse koji su navedeni u metapodacima MDB-a. Resursi se
mogu navesti pomoću anotacija ili u XML datoteci(XML descriptor).3. Kontejner poziva metodu koja ima @PostConstruct anotaciju.
Na kraju životnog ciklusa kontejner poziva metod sa @PreDostroy anotacijom.Životni ciklus message driven bean-a je prikazan na slici 11.
slika 11. Životni ciklus Message bean-a
23
Ne postoji(Does Not Exists)
Skup bean-ova spremnih za pozivanje(Method-Ready Pool)
1. kreiraj message bean2. ubacivanje zavisnosti (dependency injection) 3. @PostConstruct
1. @PreDestroy
pozivi klijenata
3.3. Java Persistence API (JPA)
JPA omogućava preslikavanje Java objekata u tabele relacione baze podataka(O/RM, ORM, O/R – Object Relation Mapping). Objektno-relaciono preslikavanje omogućava izvršavanje upita i ažuriranja baze podataka koristeći Java objekte.
3.3.1. EntitetiEntiteti su domenske klase13 koje su povezane sa tabelama relacione baze podataka koristeći JPA metapodatke. Klasa entiteta predstavlja jednu tabelu u relacionoj bazi podataka, dok objekat klase entiteta odgovara jednom slogu u tabeli.
Entitetska klasa ima sledeće karakteristike :1. označena je javax.persistence.Entity anotacijom,2. entitetska klasa, njene metode, i atributi predviđeni za perzistenciju ne smeju biti označeni sa
final.3. entitetska klasa mora imati public ili protected konstruktor bez argumenata,4. atributi enitetske klase moraju imati private ili protected način pristupa.
Atributi entiteta mogu biti 1. Java primitivni tipovi podataka, 2. Java referentni tipovi podataka : java.lang.String. java.math.BigInteger,
java.math.BigDecimal, java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp
3. korisničke klase koje mogu biti serijalizovane4. byte[], Byte[], char[], i Character[], nabrojani tipovi; 5. entiteti i/ili kolekcije entiteta; 6. ugnježdene klase.
JPA definiše dva načina za postavljanje anotacija nad atributima: field access i property access. Property pristup stavlja anotacije na pristupne(get i set) metode atributa, za razliku od field pristupa koji stavlja anotacije direktno na atribute. Nije dozvoljeno mešanje dva pristupa.U nastavku su navedeni osnovni JPA metapodaci : @Table – povezuje entitet sa tabelom@Id – označava prost primarni ključ entiteta(složeni primarni ključ se obeležava sa @EmbeddedId i @IdClass anotacijama)@Column – povezuje atribute entiteta sa kolonama tabele u baziPrimer entitetske klase iz studiskogsa anotacijama postavljenim direktno na atribute :
@Entity@Table(name = "\"Artikal\"")public class Artikal implements Serializable {
private static final long serialVersionUID = 1L; @Id @Column(name = "\"PKArtikla\"", nullable = false) private String PKArtikla; @Column(name = "\"Naziv\"")
13 Domenske klase su Java klase koje opisuju strukturu softverskog sistema[Vlajić 1].
24
private String naziv; @Column(name = "\"Cena\"") private Double cena;...
3.3.2. Veze između entiteta Tipovi veza između entiteta su prikazane u tabeli 1.
Multiplikativnost14 Navigacija veze15
jednosmerna(unidirectional) dvosmerna(bidirectional)
@OneToOne
Primer :
Svaka instanca entiteta država ima JEDAN glavni grad.
Svaka instanca entiteta država ima JEDAN glavni grad, i svaki glavni grad je u vezi sa jednom državom tj. postoji mogućnost da saznamo državu za pojavljivanje glavnog grada.
@OneToMany Primer :
Jedno pojavljivanje entiteta račun je u vezi sa više stavki računa.
Jedno pojavljivanje entiteta račun je u vezi sa više stavki računa, i jedno pojavljivanje stavke računa je u vezi sa jednim računom.
@ManyToOne
Primer :
Jedno pojavljivanje entiteta radnik je u vezi sa jednim odeljenjem.
Jedno pojavljivanje entiteta radnik je u vezi sa jednim odeljenjem, i jedno pojavljivanje entiteta odeljenje je u vezi sa više radnika.
@ManyToMany
Primer :
Jedno pojavljivanje entiteta student je u vezi sa više ispita.
Jedno pojavljivanje entiteta student je u vezi sa više ispita, i jedno pojavljivanje entiteta ispit je u vezi sa više studenata, u smislu da više studenata polaže jedan ispit.
Tabela 1. JPA tipovi veza
14 Multiplikativnost veze određuje koliko je pojavljivanja entiteta u vezi sa JEDNIM pojavljivanjem drugog entiteta. Multiplicitet je obično interval koji definiše najmanji odnosno najveći broj pojavljivanja koji se mogu pridružiti jednom pojavljivanju u posmatranoj vezi. [Veljović].
15 Navigacija veze određuje smer komunikacije između objekata.
25
glavni graddržava
stavka računaračun
odeljenjeradnik
ispitstudent * *
*
*
3.3.3. Upravljanje entitetima
EntityManager(EM) API je interfejs koji koristi metapodatke(anotacije) entiteta da promeni relacije u bazi podataka. EM omogućava kreiranje, brisanje, čitanje, i izmenu entiteta u bazi podataka.
3.3.3.1. Životni ciklus entitetaŽivotni ciklus entita ime četiri faze : novi(new), odvojen(detached), obrisan(removed) i sinhronizovan sa bazom podataka(managed) :
1. novi(new) – entitet je kreiran u memoriji,2. sinhronizovan sa bazom podataka(managed) – faza u kojoj se svaka promena entiteta reflektuje
na promenu relacije u bazi podataka sa kojom je entitet povezan tj. EM obezbeđuje da su podaci entiteta sinhronizovani sa podacima tabele. EM ostvaruje pomenutu sinhronizaciju koristeći perzistentni kontekst(PK). Perzistentni kontekst je skup pojavljivanja entitetskih klasa koje se nalaze u managed fazi. EM prati svaku promenu entiteta koji se nalaze u perzistentnom kontekstu i izvršava promene u tabelama baze podataka za kojom je entitet povezan. Kada se zatvori perzistentni kontekst svi entiteti u okviru njega prelaze u fazu detached, i njihovo stanje nije sinhronizovano sa bazom podataka. Svi entiteti koji pređu u detached fazu napuštaju PK.
3. odvojen(detached) – pojavljivanje entitetske klase koje se ne nalazi u okviru perzistentnog konteksta. Entitet se nalazi u ovom stanju ako je izvan opsega, serijalizovan, kloniran ili obrisan(ako podaci ne postoje u bazi entitetom se ne može upravljati).
4. removed – entitet je obrisan iz baze podatatakaŽivotni ciklus entiteta je prikazan na slici 12.
slika 12. Životni ciklus entiteta
26
sinhronizovan sa bazom podataka(managed)
novi(new)
odvojen(detached)
obrisan(removed)remove()
novi()
persist()
Završetak perzistentnog konteksta
merge()
3.3.3.2. Kreiranje EntityManager-a
U JSE okruženju EM se kreira pozivom createEntityManagerFactory metode klase javax.persistence.Persistence, kojoj prosleđujemo perzistentnu jedinicu kao ulazni parametar(persistence unit - PU). PU definiše skup entitetskih klasa koje se koriste u aplikaciji, i definisana je u okviru META-INF/ persistence.xml datoteke. Primer kreiranja EM u JSE okruženju : EntityManagerFactory emf = Persistence.createEntityManagerFactory("MasterTopLinkPU"); EntityManager em = emf.createEntityManager();
EJB kontejner kreira EM koristeći @PersistenceContext anotaciju pri čemu se perzistentna jedinica nalazi na aplikacionom serveru i navodi se kao atribut anotacije npr. @PersistenceContext(unitName="MasterEnterprise-ejbPU") EntityManager entityManager;Anotacija @PersistenceContext ima sledeće atribute :
• unitName- ime perzistentne jedinice
• type – tip perzistentnog konteksta. Može biti PersistenceContextType.EXTENDED ili PersistenceContextType.TRANSACTION
3.3.4. Upitni jezik
Java upitni jezik(Java Persistence Query Language - JPQL) definiše osnovu za pisanje upita nad entitetima. Upitni jezik omogućava pisanje upita koji se mogu izvršavati nezavisno od sistema za upravljanje bazom podataka. Upitni jezik kao model podataka koristi apstraktne perzistentne šeme entiteta, uključujući i njihove veze, i definiše operatore i izraze koji su zasnovani na takvom modelu podataka. Upitni jezik koristi sintaksu koja je veoma slična SQL-u kako bi izvršio izbor objekata i vrednosti zasnovanih na apstraktnoj šemi tipova entiteta i njihovih veza.
3.3.4.1. SELECT upitiSelect upit ima šest klauzula : SELECT, FROM, WHERE, GROUP BY, HAVING i ORDER BY. SELECT i FROM klauzule su obavezne a ostale su opcione. Dajemo prikaz sintakse za kreiranje SELECT upita korišćenjem BNF (Backus-Naur Form) forme:
QL_statement ::= select_klauzula_from_kluzula[where_klauzula], [groupby_klauzula], [having_klauzula], [orderby_klauzula]
3.3.4.2. UPDATE i DELETE upitiUPDATE i DELETE upiti omogućavaju ažuriranje stanja sistema za upravljanje bazom podataka. Za ažuriranje konkretnog opsega tabele koristi se WHERE kluzula.
update_statement ::= update_kluzula [where_kluzula] delete_statement ::= delete_kluzula [where_kluzula]
27
3.4. EJB Tehnologija
EJB tehnologija koristi JNDI (Java Naming and Directory Interface) API za komunikaciju sa servisom preslikavanja, dok je distribucioni mehanizam zasnovan na RMI/IIOP(Remote Method Invoke/Internet InterORB Protocol) tehnologiji.
3.4.1. JNDI APIJNDI progamerski interfejs omogućava komunikaciju Java programa sa servisima preslikavanja i direktorijuma. Servis preslikavanja omogućava povezivanje objekata sa njihovim logičkim imenima, kao i pristup objektima na osnovu pridruženog logičkog imena. Primer servisa preslikavanja je Domain Name Service(DNS). DNS omogućava lociranje računara na mreži na taj način što korisnik unosi logičku adresu(npr. www.finansijebgd.org), koju DNS preslikava u IP adresu (207.105.25.253) na osnovu koje se pristupa računaru u mreži.Servis direktorijuma proširuje servis preslikavanja u smislu da omogućava objektima da imaju atribute, i omogućava operacije za manipulisanje atributima objekata. Objekti koji imaju atribute se nazivaju direktorijumski objekti. Primer servisa direktorijuma je LDAP, NIS, Microsoft ActiveDirectory itd.
3.4.1.1. JNDI arhitektura
JNDI arhitektura se sastoji od sledećih slojeva:1. JNDI klijentski API – klijenti koriste JNDI klijentski API za izvođenje operacija nad objektima
direktorijuma. Ovaj interfejs je jedinstven za sve tipove servisa preslikanja i direktorijuma.2. Service Provider Interface (SPI) – skup klasa koje implementiraju odgovarajuće JNDI interfejse
preko kojih JNDI klijentski API zapravo komunicira sa servisima preslikavanja i direktorijuma(DNS, LDAP i dr.).
Slika 13. JNDI ahitektura
28
JNDI Client
DNS LDAP RMI Registry ...
JNDI klijentski API
JNDI SPI
3.4.2. RMI/IIOP
RMI/JRMP je mehanizam za pozivanje metoda objekata koji se izvršavaju na drugoj JVM.CORBA(Common Object Request Broker Architecture) je standardni mehanizam za pozivanje metoda objekata koji se izvršavaju na istom, ili drugom umreženom računaru. Corba je standard nezavistan od operativnog sistema, i od programskog jezika tj. omogućava saradnju aplikacija koje se izvršavaju na različitim platformama, i koje su realizovane različitim programskim jezicima.RMI/IIOP je tehnologija koju su razvili SUN i IBM sa osnovnim ciljem da povežu CORBA i RMI/JRMP tehnologije. RMI/IIOP poboljšava standardnu RMI/JRMP tehnologiju tako da se komunikacija klijenta i servera obavlja pomoću CORBA IIOP (Internet InterORB Protocol) protokola. Na taj način postignut je osnovni cilj da CORBA i RMI aplikacije mogu da sarađuju.
3.4.2.1. RMI/IIOP arhitektura RMI/IIOP arhitektura se sastoji od dva sloja(Slika 14.) :
1. Stub/Tie sloj 2. Object Request Brocker - ORB sloj koji koristi Internet InterORB Protocol – IIOP za
komunikaciju klijentskog i serverskog procesa.
Slika 14. RMI/IIOP ahitektura
3.4.2.1.1. Stub/Tie sloj Stub klasa implementira interfejs udaljenog objekta čije se metode pozivaju i nasleđuje javax.rmi.CORBA.Stub klasu koja omogućava saradnju sa ORB slojem. Stub klasa poseduje metode sa istim potpisom kao i serverski objekat. Prilikom poziva neke od metoda stuba, obavljaju se sledeći koraci :Ako se objekat izvršava u okviru posebne virtuelne mašine :
1. Poziva se ORB delegat klase javax.rmi.CORBA.Stub da kreira poziv za metodu serverskog objekta.
2. Kodiraju se argumenti za poziv metode.3. Pomoću ORB delegata klase javax.rmi.CORBA.Stub se poziva udaljena metoda.4. Dekodiraju se rezultati.5. Poziva se _releaseReply metoda delegata da bi se oslobodili zauzeti resursi delegata.6. Vraćaju se rezultati klijentu.
Ako se objekat izvršava u okviru iste virtuelne mašine :1. Poziva se servant_preinvoke metoda ORB delegata za prihvatanje pojavljivanja klase
ServantObject. Klasa ServantObject je posrednik za pozivanje metoda objekata i
29
Stub Tie
ORB ORB
IIOP
Klijent Server
omogućava prihvatanje objekta koji izvršava poziv.2. Kopiraju se argumenti3. Poziva se metoda objekta(servant) koji se dobija od ServantObject-a.4. Kopira se rezultat5. Informise se delegat da je poziv izvršen.6. Vraća se rezultat.
Tie klasa implementira interfejs javax.rmi.CORBA.Tie i nasleđuje org.omg.CORBA_2_3.portable klasu koja omogućava saradnju sa ORB slojem. Poziv metode serverskog objekta podrzumeva poziv sledeće metode Tie interfejsa :
OutputStream _invoke( String method, InputStream input, ResponseHandler handler );
Metoda _invoke obavlja sledeće korake :1. Dekodira(Unmarshal) argumente koji se prosleđuju metodi udaljenog objekta na osnovu klase
InputStream.2. Poziva metodu serverskog objekta koja ima naziv method, i prosleđuje dekodirane argumente.3. Koristi metodu ResponseHandler.createReply() za kreiranje odgovarajućeg tipa
odgovora na poziv metode.4. Ispisuje rezultat poziva u izlazni tok koji je rezultat poziva _invoke metode.
3.4.2.1.2. Object Request Brocker - ORB sloj
ORB prosleđuje pozive ka udaljenim ili lokalnim serverskim objektima i vraća odgovore klijentskom objektu. ORB prihvata pozive stuba i kreira Interoperable Object Reference-IOR identifikator udaljenog objekta. Koristići IOR objekat ispituje se da li postoji veza ka udaljenom objektu, i ako ne postoji veza se kreira. Nakon toga, ORB kreira poruku koja se prenosi ka serveru. Sadržaj poruka koje razmenjuju klijent i server je definisan IIOP protokolom. Ako serverski proces na kome se izvršava objekat nije pokrenut zahtev se prosleđuje ORB niti koja ima mogućnost da pokrene serverski proces na kome se izvršava objekat. Nit na serveru prihvata poruku koja stiže sa klijenta i na osnovu podataka iz zahteva prosleđuje poziv odgovarajućem TIE objektu koji dekodira argumente, poziva metodu, kodira argumente i vraći izlazni rezultat klijentu. Odgovor servera se vraća klijentu na sličan način kao i opisani poziv klijenta.
3.4.3. EJB arhitekturaOsnovni koncepti Session Bean ahitekture su :
1. Klijent 2. Stub i Tie klase– klase koje imaju ulogu posrednika preko kojih klijent poziva metode bean-
a.3. Enterprise Naming Context(ENC) – servis imenovanja gde EJB kontejner registruje reference
bean-a.4. Server klasa – klasa koju aplikacioni server kreira automatski i koja obezbeđuje dodatni kod
neophodan za pružanje bean-u usluga kontejnera.5. Usluge servera – usluge koje EJB kontejner obezbeđuje bean-ovima6. Session Bean
30
Koncepti Session Bean ahitekture su prikazani na slici 15.
Slika 15. Session Beans arhitektura
Udaljeni klijenti preuzimaju referencu na poslovni interfejs(stub objekat) koja je registrovana u ENC servisu imenovanja. Stub i Tie klase se kreiraju prilikom raspoređivanja(deploy) EJB komponente na server. Kada se startuje aplikacioni server stub i tie objekti se kreiraju u memoriji i stub objekat postaje dostupan za pruzimanje u servisu imenovanja. Prilikom preuzimanja reference stub objekat se serijalizuje i prosleđuje klijentu, a nakon toga klijent učitava stub klasu sa servera. Klijent poziva metode bean-a posredstvom pruzetog stub objekta. Ukoliko se preuzima referenca na stateful session bean sporedni efekat(side effect) preuzimanja reference je kreiranje stateful bean-a za tog klijenta. RMI/IIOP tehnologija omogućava prenos poziva do kontejnera koji prihvata poziv i prosleđuje ga do serverske klase. Serverska klasa se kreira prilikom raspoređivanja(deploy) bean-a u kontejner, i ona je odeđena tipom EJB kontejnera. Pomenuta klasa obezbeđuje dodatni kod neophodan za pružanje bean-u usluga kontejnera. EJB kontejner pruža bean-u sledeće usluge : sigurnost(provera identiteta i ovlašćenja), upravljanje transakcijama, upravljanje životnim ciklusom bean-a i dr. Nakon izvršavanja poslovne metode session bean-a povratna vrednost(ako postoji) se serijalizuje i prosleđuje klijentu.
Kod Message Driven Bean-ova klijenti preuzimaju referencu na destinaciju ili krajnju tačku(endpoint) pretraživanjem svog JNDI imenskog prostora ili ubacivanjem zavisnosti(dependency injection). Kontejner prihvata pristigle poruke i obezbeđuje sve usluge kao i kod session bean-a a zatim prosleđuje poruku MDBu koji je pridružen toj destinaciji i koji obrađuje poslatu poruku (slika 16).
31
2
stub3 RMI/IIOP
Enterprise Naming Context(ENC)
1
tie5
ClientsessionBean
server klasa
4
kreiraj stateful session bean
Slika 16. Message-Driven Beans arhitekura
3.5. Rezime poglavlja
U ovom poglavlju je prikazana Java Enterprise Edition specifikacija i EJB 3.0 tehnologija koja je sastavni deo JEE. Prikazani su session i message driven bean-ovi koji omogućavaju modeliranje procesa poslovnog sistema. Zatim je dat prikaz JPA programerskog iterfejsa koji omogućava perzistentnost Java objekata. Nakon toga su prikazane tehnologije koje su u osnovi EJB-a : JNDI i RMI/IIOP, kao i arhitektura EJB tehnologije. Na taj način je osvaren drugi cilj istraživanja (Dati prikaz EJB 3.0 tehnologije i njene primene u razvoju složenih aplikacija).
32
Enterprise Naming Context(ENC)
1
2
Clientmessagedrivenbean
krajnja tačka(endpoint)
3
4 5
4. Larmanova metoda razvoja softverskog sistema
Softverski sistem (Slika 17) je skup atributa i sistemskih operacija. Atributi opisuju strukturu sistema dok sistemske operacije opisuju ponašanje sistema.Korisnički interfejs realizuje ulaz i izlaz softverskog sistema.
Slika 17: Softverski sistem
Razvoj softverskog sistema se sastoji iz sledećih faza :
1. Prikupljanje zahteva od korisnika2. Analize 3. Projektovanja 4. Implementacije5. Testiranja
4.1. Prikupljanje zahteva od korisnika
Zahtevi se mogu podeliti na funkcionalne koji određuju funkcionisanje sistema i nefunkcionalne koji se odnose na upotrebljivost, pouzdanost, performanse, podrživost i td.Funkcionalni zahtevi se opisuju pomoću UML Modela slučaja korišćenja.Model slučaja korišćenja se sastoji od skupa slučaja korišćenja, aktora i veza između SK i aktora.Slučaj korišćenja opisuje scenario korišćenja softverskog sistema.Aktor predstavlja spoljnog korisnika sistema koji postavlja zahteve sistemu za izvršenje sistemskih operacija.Aktor izvodi tri vrste akcija:
1. Aktor Priprema Ulaz za Sistemsku Operaciju(APUSO)2. Aktor Poziva sistem da izvrši Sistemsku Operaciju(APSO)3. Aktor izvršava NeSistemsku Operaciju(ANSO)
Sistem izvodi dve vrste akcija : 1. Sistem izvršava Sistemsku Operaciju(SO)2. Sistem prosleđuje Izlazne Argumente aktoru (IA)
33
4.1.1. Predstavljanje slučaja korišćenjaSK se u početnim fazama razvoja predstavlja tekstualno (Larman, JPRS) dok se kasnije oni predstavljaju pomoću sekvencnih dijagrama, dijagrama saradnje, dijagrama prelaza stanja ili dijagrama aktivnosti.
Tekstualni opis SK ima sledeću strukturu:1. Naziv SK2. Aktori SK3. Učesnici SK4. Preduslovi koji moraju biti zadovoljeni da bi SK počeo da se izvršava5. Osnovni scenario izvršenja SK6. Postuslovi koji moraju biti zadovoljeni da bi se slučaj korišćenja izvršio7. Alternativna scenarija izvršenja SK8. Specijalni zahtevi9. Tehnološki zahtevi10. Otvorena pitanja
U nastavku navodimo slučajeve korićenja za softverski sistem „Evidencija radnih naloga”.SK1.1: Slučaj korišćenja – Unos artikla
Naziv SKUnos artikla
Aktori SKAdministrator
Učesnici SKAdministrator i program (u daljem tekstu sistem)
Preduslov: Sistem je uključen i administrator je ulogovan. Sistem prikazuje formu Artikal (kada korisnik pozove sistem da se izvrši(APSO), sistem inicijalno prikazuje formu na kojoj se nalazi podaci o poslednjem unetom artiklu (IA)).
Osnovni scenario SK
1. Administrator unosi podatke o novom artiklu(APUSO)2. Administrator poziva sistem da izvrši evidentiranje unetih podataka(APSO)3. Sistem evidentira unete podatke(SO)4. Sistem vraća poruku o uspešnosti unosa podataka u bazu(IA)
Alternativni scenario SK4.1. Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru. Prekida se izvršenje scenarija.
34
SK1.2: Slučaj korišćenja – Prikaz artikla
Naziv SKPrikaz artikla
Aktori SKAdministrator
Učesnici SKAdministrator i sistem
Preduslov: Sistem je uključen i prikazuje formu za obradu artikla.
Osnovni scenario SK
1. Administrator unosi kriterijum za prikaz artikla.(APUSO)2. Administrator poziva sistem da mu prikaže podatke za artikal sa zadatom šifrom.(APSO)3. Sistem pronalazi artikal.(SO)4. Sistem prikazuje administratoru, podatke o traženom artiklu.(IA)
Alternativna scenarija
4.1. Ukoliko artikal zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog artikla. Prekida se izvršenje scenarija.
35
SK1.3: Slučaj korišćenja – Brisanje artikla
Naziv SKBrisanje artikla
Aktori SKAdministrator
Učesnici SKAdministrator i sistem
Preduslov: Sistem je uključen i prikazuje formu za obradu artikla.
Osnovni scenario SK
1. Administrator unosi šifru artikla čije podatke želi da izbriše(APUSO)2. Administrator poziva sistem da izbriše podatke o artiklu sa zadatom šifrom(APSO)3. Sistem pronalazi artikal sa zadatom šifrom(SO)4. Sistem prikazuje administratoru artikal(IA).5. Administrator potvrđuje brisanje artikla(APSO)6. Sistem briše podatke o artiklu(SO)7. Sistem javlja administratoru da su podaci o artiklu izbrisani (IA)
Alternativna scenarija
5.1. Ukoliko postoji radni nalog sa tim artiklom sistem prikazuje poruku o postojanju takvog radnog naloga. Prekida se izvršenje scenarija.
36
SK2.1: Slučaj korišćenja – Unos radnog naloga
Naziv SKUnos radnog naloga
Aktori SKAdministrator
Učesnici SKAdministrator i sistem
Preduslov: Sistem je uključen i administrator je ulogovan. Sistem prikazuje formu radnih naloga.
Osnovni scenario SK
1. Administrator poziva sistem da kreira novi radni nalog(APSO).2. Sistem kreira novi radni nalog(SO)3. Sistem prikazuje administratoru novi radni nalog(IA)4. Administrator unosi podatke o novom radnom nalogu(APUSO)5. Administrator poziva sistem da izvrši evidentiranje radnog naloga(APSO)6. Sistem evidentira unete podatke(SO)7. Sistem vraća poruku o uspešnosti unosa podataka u bazu(IA).
Alternativni scenario SK
7.1.Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru. Vraća se na korak 3.
37
SK2.2: Slučaj korišćenja – Prikaz radnog naloga
Naziv SKPrikaz radnog naloga
Aktori SKAdministrator
Učesnici SKAdministrator i sistem
Preduslov: Sistem je uključen i prikazuje formu za obradu radnih naloga.
Osnovni scenario SK
1. Administrator unosi kriterijum za prikaz radnog naloga.(APUSO)2. Administrator poziva sistem da mu prikaže podatke radnog naloga sa zadatom šifrom.
(APSO)3. Sistem proverava postojanje radnog naloga.(SO)4. Sistem prikazuje administratoru, podatke o traženom radnom nalogu.(IA)
Alternativna scenarija
3.1. Ukoliko radnim nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog automobila. Prekida se izvršenje scenarija.
38
SK2.3: Slučaj korišćenja – Storniranje radnog naloga
Naziv SKStorniranje radnog naloga
Aktori SKAdministrator
Učesnici SKAdministrator i sistem
Preduslov: Sistem je uključen i prikazuje formu za obradu radnih naloga.
Osnovni scenario SK
1. Administrator bira radni nalog čije podatke želi da stornira(APSO).2. Sistem proverava postojanje radnog naloga(SO).3. Sistem prikazuje administratoru, podatke o traženom radnom nalogu ukoliko postoje(IA)4. Aktor poziva sistem da stornira radni nalog(APSO).5. Sistem stornira radni nalog(SO).6. Sistem prikazuje administratoru poruku da je radni nalog storniran.(IA)
Alternativna scenarija
3.1. Ukoliko radni nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog radnog naloga. Prekida se izvršenje scenarija.5.1. Ukoliko sistem ne može da stornira nalog, prikazuje poruku administratoru. Prekida se izvršenje scenarija.
39
4.2. Analiza
Faza analize opisuje logičku strukturu i ponašanje softverskog sistema. Logička struktura opisana je pomoću konceptualnog i relacionog modela, a ponašanje softverskog sistema pomoću sistemskih dijagrama sekvenci ili dijagrama saradnje.
4.2.1. Ponašanje softverskog sistema – sistemski dijagram sekvenci
Sistemski dijagram sekvenci prikazuje, za izvojeni scenario SK, događaje u određenom redosledu koji uspostavljaju interakciju između aktora i softverskog sistema[Vlajic1].
DS1.1 : Dijagram sekvenci slučaja korišćenja – Unos artikla
Osnovni scenario SK
1. Administrator poziva sistem da izvrši evidentiranje unetih podataka(APSO)2. Sistem vraća poruku o uspešnosti unosa podataka u bazu(IA).
Alternativni scenario SK
2.1.Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru. Prekida se izvršenje scenarija.
40
DS1.2 : Dijagrami sekvenci slučaja korišćenja – Prikaz artikla
Osnovni scenario SK
1. Administrator poziva sistem da prikaže podatke artikla sa zadatim kriterijumom.(APSO)2. Sistem prikazuje administratoru, podatke o traženom artiklu.(IA)
Alternativna scenarija
2.1. Ukoliko artikal zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog artikla. Prekida se izvršenje scenarija.
41
DS1.3 : Dijagrami sekvenci slučaja korišćenja – Brisanje artikla
Osnovni scenario SK
1. Administrator poziva sistem da izbriše podatke o artiklu sa zadatom šifrom(APSO)2. Sistem briše podatke o artiklu(IA)
Alternativna scenarija
2.1. Ukoliko artikal sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog artikla. Prekida se izvršenje scenarija.
42
DS2.1 : Dijagrami sekvenci slučaja korišćenja – Unos radnog naloga
Osnovni scenario SK
1. Administrator poziva sistem da kreira novi radni nalog(APSO).2. Sistem prikazuje administratoru novi radni nalog(IA)3. Administrator poziva sistem da izvrši evidentiranje radnog naloga(APSO)4. Sistem vraća poruku o uspešnosti unosa podataka u bazu.
Alternativni scenario SK
4.1.Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru. Vraća se na korak
43
DS2.2 : Dijagrami sekvenci slučaja korišćenja – Prikaz radnog naloga
Osnovni scenario SK
1. Administrator poziva sistem da mu prikaže podatke radnog naloga sa zadatom šifrom.(APSO)
2. Sistem prikazuje administratoru, podatke o traženom radnom nalogu.(IA)
Alternativna scenarija
2.1. Ukoliko radnim nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog automobila. Prekida se izvršenje scenarija.
44
DS2.3 : Dijagrami sekvenci slučaja korišćenja – Storniranje radnog naloga
Osnovni scenario SK
1. Administrator bira radni nalog čije podatke želi da stornira(APSO).2. Sistem prikazuje administratoru, podatke o traženom radnom nalogu ukoliko postoje(IA)3. Aktor poziva sistem da stornira radni nalog(APSO).4. Sistem prikazuje administratoru poruku da je radni nalog storniran.(IA)
Alternativna scenarija
2.1. Ukoliko radni nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog radnog naloga. Prekida se izvršenje scenarija.
4.1. Ukoliko sistem ne može da stornira nalog, prikazuje poruku administratoru. Prekida se izvršenje scenarija.
45
4.2.2. Definisanje ugovora o sistemskim operacijamaUgovori opisuju ponašanje sistemske operacije. Jedan ugovor je vezan za jednu sistemsku operacijuUGOVOR UG1: Unesi artikalOperacija: UnosArtikla(Artikal):signalVeza sa SK:DS1.1Preduslovi: Postavljene vrednosti artiklaPostuslovi: Kreiran novi artikal
UGOVOR UG2: Prikazi artikalOperacija: PostaviArtikal(Artikal):signalVeza sa SK: DS1.2Preduslovi: - Postuslovi: Vraćen artikal ako postoji
UGOVOR UG3: Brisanje artiklaOperacija: BrisanjeArtikla(Artikal):signalVeza sa SK:DS1.3Preduslovi: - Postuslovi: Obrisan artikal iz baze podataka ako postoji UGOVOR UG4: Kreiraj radni nalogOperacija: KreirajNovi():signalVeza sa SK:DS2.1Preduslovi: - Postuslovi: Postavljene su početne vrednosti radnog naloga
UGOVOR UG5: Unos radnog nalogaOperacija: UnosRadnogNaloga(RadniNalog):signalVeza sa SK:DS2.1 Preduslovi: Postavljene početne vrednosti radnog nalogaPostuslovi: Kreiran radni nalog
UGOVOR UG6: Prikaz radnog nalogaOperacija: PostaviRadniNalog(RadniNalog):signalVeza sa SK : DS2.2, DS2.3Preduslovi: -Postuslovi : Vraćen radni nalog ako postoji
UGOVOR UG7: Storniranje radnog nalogaOperacija: StornirajRadniNalog(RadniNalog):signalVeza sa SK : DS2.3Preduslovi : Radni nalog nije storniranPostuslovi : Radni nalog je storniran
46
4.2.3. Struktura softverskog sistema-Konceptualni model
Konceptualni model opisuje konceptualne klase (domenske klase) domena problema i asocijacije (veze) između konceptualnih klasa.
47
4.3. Projektovanje
Projektovanje opisuje fizičku strukturu i ponašanje soft. sistema (arhitekturu softverskog sistema).
Arhihitektura softverskog sistema(Slika 18.) – se sastoji od tri nivoa :
Korisnički interfejs – predstavlja ulazno-izlaznu reprezentaciju softverskog sistemaAplikacione logike – koja opisuje strukturu i ponašanje softverskog sistemaSkladišta podataka – čuva stanje atributa softverskog sistema
Slika 18. Arhitektura softverskog sistema
4.3.1. Aplikaciona logika RMI realizacije studije slučaja
Aplikaciona logika RMI realizacije studije slučaja se sastoji od Kontrolera aplikacione logike, poslovne logike i Database broker-a(slika 19.).
Slika 19. Aplikaciona logika RMI realizacije studije slučaja
48
Skladište podataka
Korisnički interfejs
Aplikaciona logika
Softverski sistemprvi nivo
drugi nivo treći nivo
KlijentKontroler
aplikacione logikeSkladište podataka
Server
Database brokerPoslovna logika
Aplikaciona logika
4.3.1.1. Aplikaciona logika RMI realizacije studije slučaja-KontrolerKontroler je udaljeni objekat koji je odgovoran da prihvati zahtev za izvršenje sistemske operacije od klijenta, transformiše objekat za transfer podataka(TO) u domenski objekat i da prosledi domenski objekat do poslovne logike koja je odgovorna za izvršenje sistemske operacije.
public class KontrolerAL implements RemoteKontrolerAL {
public void storniraj(RadniNalogPKTO pk) throws OperationFailsException, EntityNotFoundException, InvalidParameterException,RemoteException { RadniNalog radniNalog = new RadniNalog();//Kreiraj domenski objekat radniNalog.mergeRadniNalogPKTO(pk);//podesi klasu na osnovu vrednosti atributa TO StornirajRadniNalog.storno(radniNalog);//pozovi sistemsku operaciju poslovne logike }//ostale metode....
49
4.3.1.2. Aplikaciona logika RMI realizacije studije slučaja-Poslovna logika
Poslovna logika je opisana strukturom(domenskim klasama) i ponašanjem (sistemskim operacijama) softverskog sistema.Klase strukture softverskog sistema su projektovane korišćenjem JPA programerskog interfejsa(API) na osnovu konceptualnih klasa koje su prikazane u fazi analize.
50
Navodimo realizaciju klase Artikal:@Entity@Table(name = "\"Artikal\"")public class Artikal implements Serializable { private static final long serialVersionUID = 1L; @Id @Column(name = "\"PKArtikla\"", nullable = false) private String PKArtikla; @Column(name = "\"Naziv\"") private String naziv; @Column(name = "\"Cena\"") private Double cena; public Artikal() { }...}
Sistemske operacije su klase koje opisuju ponašanje softverskog sistema. Za svaki od ugovora se projektuje konceptualno rešenje sistemske operacije. Konceptualne realizacije su prikazane preko sekvencnih dijagrama.
51
UGOVOR UG1: Unesi artikalOperacija: UnosArtikla(Artikal):signalPreduslovi: Postavljene vrednosti artiklaPostuslovi: Kreiran novi artikal
52
UGOVOR UG2: Prikazi artikalOperacija: PostaviArtikal(Artikal):signalPostuslovi: Vraćen artikal ako postoji
53
UGOVOR UG3: Brisanje artiklaOperacija: BrisanjeArtikla(Artikal):signalPostuslovi: Obrisan artikal iz baze podataka ako postoji
54
UGOVOR UG4: Unos radnog nalogaOperacija: UnosRadnogNaloga(RadniNalog):signalPreduslovi: Postavljene početne vrednosti radnog nalogaPostuslovi: Kreiran radni nalog
55
UGOVOR UG5: Prikaz radnog nalogaOperacija: PostaviRadniNalog(RadniNalog):signalPostuslovi : Vraćen radni nalog ako postoji
56
UGOVOR UG6: Storniranje radnog nalogaOperacija: StornirajRadniNalog(RadniNalog):signalPreduslovi : Radni nalog nije storniranPostuslovi : Radni nalog je storniran
57
4.3.1.3. Aplikaciona logika RMI realizacije studije slučaja-Database Broker(DBBR)DBBR predstavlja skup klasa i interfejsa koji omogućavaju perzistentnost objektima16 različitih klasa.
4.3.2. Aplikaciona logika EJB realizacije studije slučajaAplikaciona logika EJB realizacije studije slučaja sadrži strukturu(domenske klase) i ponašanje(sistemske operacije) softverskog sistema koji je realizovan EJB 3.0 tehnologijom. Na slici 20. je prikazana aplikaciona logika EJB realizacije studije slučaja. Konceptualni prikaz ponašanja EJB realizacije studije slučaja je prikazan sekvencnim dijagramima u nastavku rada.
Slika 20. Aplikaciona logika EJB realizacije studije slučaja
16 Perzistentan objekat je onaj koji nastavlja da postoji i nakon prestanka rada programa koji ga je stvorio.
58
Klijent Skladište podataka
server
Poslovna logika
Apolikacioni server
Kontroleraplikacione logike
UGOVOR UG1: Unesi artikalOperacija: UnosArtikla(Artikal):signalPreduslovi: Postavljene vrednosti artiklaPostuslovi: Kreiran novi artikal
59
UGOVOR UG2: Prikazi artikalOperacija: PostaviArtikal(Artikal):signalPostuslovi: Vraćen artikal ako postoji
60
UGOVOR UG3: Brisanje artiklaOperacija: BrisanjeArtikla(Artikal):signalPostuslovi: Obrisan artikal iz baze podataka ako postoji
61
UGOVOR UG4: Unos radnog nalogaOperacija: UnosRadnogNaloga(RadniNalog):signalPreduslovi: Postavljene početne vrednosti radnog nalogaPostuslovi: Kreiran radni nalog
62
UGOVOR UG5: Prikaz radnog nalogaOperacija: PostaviRadniNalog(RadniNalog):signalPostuslovi : Vraćen radni nalog ako postoji
63
UGOVOR UG6: Storniranje radnog nalogaOperacija: StornirajRadniNalog(RadniNalog):signalPreduslovi : Radni nalog nije storniranPostuslovi : Radni nalog je storniran
64
4.3.3. Projektovanje skladišta podatalaNa osnovu domenskog modela može se napraviti relacioni model koji predstavlja osnovu za projektovanje relacione baze podataka.
RadniNalog(BrojNaloga, DatumIzdavanja, Storniran, Napomena)StavkaMaterijala(redniBroj , BrojNaloga ,PKArtikla, Kolicina)Artikal(PKArtikla, Naziv, Cena)
Na osnovu relacionog modela kreiraju se sledeće tabele baze podataka :
Tabela : ArtikalNaziv kolone Tip polja VeličinaPKArtikla character varying 255Naziv character varying 255Cena double precision
Ograničenja : ArtikalTip ograničenja Naziv ograničenja Polje Primarni ključ Artikal_pkey PKArtikla
Tabela : RadniNalogNaziv kolone Tip polja VeličinaBrojNaloga integerNapomena character varying 255DatumIzdavanja dateStorniran booleanNazivUsluge character varying 255CenaUsluge double precision
Ograničenja : RadniNalogTip ograničenja Naziv ograničenja Polje Primarni ključ RadniNalog_pkljuc BrojNaloga
65
Tabela : StavkaMaterijalaNaziv kolone Tip polja VeličinaRedniBroj integerPKArtikla character varying 255Kolicina integerBrojNaloga integer
Ograničenja : StavkaMaterijalaTip ograničenja Naziv ograničenja Polje Primarni ključ StavkaMaterijala_pkljuc BrojNaloga, RedniBrojSpoljni ključ Artikal_skljuc PKArtiklaSpoljni ključ RadniNalog_skljuc BrojNaloga
Tabela 2. Skladište podataka
U nastavku je prikazan programski kod za kreiranje tabela baze podataka (Data Definition Language-DDL).Programski kod za kreiranje tabele Artikal :
CREATE TABLE "Artikal"( "PKArtikla" character varying NOT NULL, "Naziv" character varying, "Cena" double precision, CONSTRAINT "Artikal_pkljuc" PRIMARY KEY ("PKArtikla")) WITHOUT OIDS;ALTER TABLE "Artikal" OWNER TO postgres;
Programski kod za kreiranje tabele RadniNalog :
CREATE TABLE "RadniNalog"( "BrojNaloga" integer NOT NULL, "Napomena" character varying, "DatumIzdavanja" date, "Storniran" boolean, "NazivUsluge" character varying, "CenaUsluge" double precision, CONSTRAINT "RadniNalog_pkljuc" PRIMARY KEY ("BrojNaloga")) WITHOUT OIDS;ALTER TABLE "RadniNalog" OWNER TO postgres;
66
Programski kod za kreiranje tabele StavkaMaterijala :CREATE TABLE "StavkaMaterijala"( "RedniBroj" integer NOT NULL, "PKArtikla" character varying, "Kolicina" integer, "BrojNaloga" integer NOT NULL, CONSTRAINT "StavkaMaterijala_pkljuc" PRIMARY KEY ("RedniBroj", "BrojNaloga"), CONSTRAINT "Artikal_skljuc" FOREIGN KEY ("PKArtikla") REFERENCES "Artikal" ("PKArtikla") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "RadniNalog_skljuc" FOREIGN KEY ("BrojNaloga") REFERENCES "RadniNalog" ("BrojNaloga") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION) WITHOUT OIDS;ALTER TABLE "StavkaMaterijala" OWNER TO postgres;
67
4.3.4. Konačan izgled arhitektura RMI i EJB 3.0 realizacije studije slučaja
Konačan izgled arhitekture RMI realizacije slučaja je prikazan na slici 21.
Slika 21. Konačan izgled arhitekture RMI studije slučaja
68
Konačan izgled arhitekture EJB realizacije slučaja je prikazan na slici 22.
Slika 22. Konačan izgled arhitekture EJB studije slučaja
69
4.3.5. Projektovanje korisničkog interfejsa
Korisnički interfejs (Slika 19) predstavlja realizaciju ulaza i/ili izlaza softverskog sistema. Realizovan je preko Javinih klasa koje se nalaze u java.awt.* i javax.swing.* paketima, i se sastoji od :
Ekranske forme (EF) koja je odgovorna da:1. prihvata podatke aktora2. prihvata događaje aktora3. poziva kontroler korisničkog interfejsa prosleđujući mu podatke4. prikazuje podatke
Kontrolera korisničkog interfejsa koji je odgovoran da:
1. prihvati podatke EF2. konvertuje podatke u objekat koji će biti ulazni element za sistemsku operaciju3. šalje zahtev za izvršenje SO4. prihvata objekat koji predstavlja izlaz iz softverskog sistema5. konvertuje objekat u grafičke komponente
Slika 23. Ekranske forme
70
Ekranska forma KontrolerKI
Softverskisistem
SK1.1: Slučaj korišćenja - Unos artikla
Preduslov: Sistem je uključen i administrator je ulogovan. Sistem prikazuje formu Artikal.
Osnovni scenario1. Administrator unosi podatke o novom artiklu(APUSO)2. Administrator poziva sistem da izvrši evidentiranje unetih podataka(APSO)
Opis akcije: Administrator pritiska dugme Unos, nakon čega se poziva sistemska operacija UnosArtikla(Artikal).
3. Sistem evidentira unete podatke(SO)4. Sistem vraća poruku o uspešnosti unosa podataka u bazu(IA)
Alternativni scenario SK 4.1 Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru. Prekida
se izvršenje scenarija.
71
SK1.2: Slučaj korišćenja - Prikaz artikla
Preduslov: Sistem je uključen i prikazuje formu za obradu artikla.
Osnovni scenario SK1. Administrator unosi kriterijum za prikaz artikla.(APUSO)
Opis akcije: Administrator popunjava polje Šifra.2. Administrator poziva sistem da mu prikaže podatke artikla sa zadatom šifrom.(APSO)
Opis akcije: Administrator pritiska dugme Prikaz, nakon čega se poziva sistemska operacija PrikazArtikla(Artikal).
3. Sistem pronalazi artikal.(SO)4. Sistem prikazuje administratoru, podatke o traženom artiklu.(IA)
Alternativna scenarija4.1 Ukoliko artikal zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju takvog
artikla. Prekida se izvršenje scenarija.
72
SK1.3: Slučaj korišćenja - Brisanje artikla
Preduslov: Sistem je uključen i prikazuje formu za obradu artikla.
Osnovni scenario SK1. Administrator unosi šifru artikla čije podatke želi da izbriše(APUSO)
Opis akcije: Administrator popunjava polje Šifra.2. Administrator poziva sistem da izbriše podatke o artiklu sa zadatom šifrom(APSO)
Opis akcije: Administrator pritiska dugme Brisanje
3. Sistem briše podatke o artiklu(SO)4. Sistem javlja administratoru da su podaci o artiklu izbrisani (IA)
Alternativna scenarija4.1 Ukoliko postoji radni nalog sa tim artiklom sistem prikazuje poruku o postojanju takvog radnog
naloga. Prekida se izvršenje scenarija.
73
SK2.1: Slučaj korišćenja - Unos radnog naloga
Preduslov: Sistem je uključen i administrator je ulogovan. Sistem prikazuje formu radnih naloga.
Osnovni scenario SK1. Administrator unosi podatke o novom radnom nalogu(APUSO)2. Administrator poziva sistem da izvrši evidentiranje radnog naloga(APSO)
Opis akcije: Administrator pritiska dugme Unos, nakon čega se poziva sistemska operacija UnosRadnogNaloga(RadniNalog).
3. Sistem evidentira unete podatke(SO)4. Sistem vraća poruku o uspešnosti unosa podataka u bazu.
Alternativni scenario SK4.1 Ukoliko sistem ne može da evidentira unete podatke, prikazuju poruku administratoru.
74
SK2.2: Slučaj korišćenja - Prikaz radnog naloga
Preduslov: Sistem je uključen i prikazuje formu za obradu radnih naloga.
Osnovni scenario SK1. Administrator unosi kriterijum za prikaz radnog naloga.(APUSO)
Opis akcije: Administrator popunjava polje Broj Naloga.2. Administrator poziva sistem da mu prikaže podatke radnog naloga sa zadatom šifrom.(APSO)
Opis akcije: Administrator pritiska dugme Prikaz, nakon čega se poziva sistemska operacija PrikazRadnogNaloga(RadniNalog).
3. Sistem proverava postojanje radnog naloga.(SO)4. Sistem prikazuje administratoru, podatke o traženom radnom nalogu.(IA)
75
Alternativna scenarija3.1 Ukoliko radnim nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju
takvog automobila. Prekida se izvršenje scenarija.
76
SK2.3: Slučaj korišćenja - Storniranje radnog naloga
Preduslov: Sistem je uključen i prikazuje formu za obradu radnih naloga.
Osnovni scenario SK1. Administrator unosi kriterijum za prikaz radnog naloga.(APUSO)
Opis akcije: Administrator popunjava polje Broj Naloga.2. Aktor poziva sistem da stornira radni nalog(APSO).
3. Sistem stornira radni nalog(SO).Opis akcije: Administrator pritiska dugme Storniraj, nakon čega se poziva sistemska operacija StornirajRadniNalog(RadniNalog).
4. Sistem prikazuje administratoru poruku da je radni nalog storniran.(IA)
Alternativna scenarija3.1 Ukoliko radni nalog sa zadatom šifrom ne postoji, sistem prikazuje poruku o nepostojanju
takvog radnog naloga. Prekida se izvršenje scenarija.5.1 Ukoliko sistem ne može da stornira nalog, prikazuje poruku administratoru. Prekida se izvršenje
scenarija.
77
4.4. Implementacija
Implementacija softverskog sistema podrazumeva kompajliranje komponenti softverskog sistema. Navodimo redosled podsistema po kome bi trebalo kompajlirati aplikacije. Komponente softverskog sistema su
1. Korisnički interfejs2. Ponašanje softverskog sistema 3. Struktura softverskog sistema 4. Database broker 5. Skladište podataka
4.5. Testiranje
Testiranje, shodno arhitekturi softverskog sistema, može da se podeli u nekoliko nezavisnih jedinica testiranja. Nezavisne jedinice testiranja su softverske komponente koje smo dobili u fazi implementacije softverskog sistema.Testiranje svake softverske komponente podrazumeva pravljenje :
1. Test slučajeva koji opisuju šta test treba da proveri2. test procedure koje opisuju kako će se izvršiti test3. test komponente koje bi trebalo da automatizuju test procedure
Nakon testa komponenti vrši se njihovo integrisanje i testira se softverski sistem kao celina.
4.6. Rezime poglavljaU ovom poglavlju je prikazan razvoj softverskog sistema „Evidencija radnih naloga” korišćenjem RMI i EJB 3.0 tehnologija. Metoda koja je korišćena u razvoju je zasnovana na Larmanovoj metodi razvoja softverskih sistema. po kojoj razlikujemo sledeće faze u razvoju softverskih sistema[Larman] :
1. Prikupljanje zahteva2. Analiza3. Projektovanje4. Implementacija5. Testiranje
Na taj način smo doprineli realizovanju prvog i drugog cilja. (Prikaz udaljenog pozivanja metoda (RMI) i korišćenje te tehnologije u realizaciji klijent-server arhitekture kao i prikaz EJB 3.0 tehnologije i njene primene u razvoju složenih aplikacija)
78
5. Dinamička analiza RMI i EJB 3.0 tehnologija
Za dinamičku analizu RMI i EJB 3.0 tehnologija koristićemo NetBeans Profiler. NetBeans profajler je Sun JFluid profajler integrisan u Netbeans okruženje. NetBeans profajler omogućava monitoring aplikacije, analizu performansi centralnog procesora i analizu memorije.
5.1. Monitoring
Monitoring aplikacije prikazuje informacije o upotrebi memorije i upravljanju nitima aplikacije. Monitoring prikazuje sledeće dijagrame :
1. Dijagram upotrebe dinamičke memorije kod koga razlikujemo liniju koja pokazuje koliko je memorije zauzeto, i liniju koja pokazuje koliko memorije se zapravo koristi.
2. Dijagram koji prikazuje podatke o sakupljaču smeća(garbage collector) kod koga razlikujemo :
• Liniju koja pokazuje procenat vremena izvršenja koji JVM troši na sakupljanje smeća. Veliki procenat potrošenog vremena ukazuje da bi trebalo dodeliti aplikaciji više dinamičke memorije ili promeniti algoritam sakupljanja smeća.
• Liniju koja pokazuje broj kolekcija smeća(garbage collections) koji su objekti na heap-u prošli. Ukoliko se broj kolekcija smeća povečava tokom vremena to znači da aplikacija instancira nove objekte, i uporedo zadržava reference na “starije” objekte koji su već instancirani tj. dešava se curenje memorije.
3. Dijagram koji pokazuje broj aktivnih niti i broj učitanih klasa.
4. Izveštaj o upravljanju nitima prikazuje sve pokrenute niti i njihovo stanje(running, waiting, sleeping, monitor).
79
5.1.1. Monitoring RMI realizacije studije slučaja U nastavku prikazujemo rezultate monitoringa RMI realizacije studije slučaja „Evidencija radnih naloga”.
Slika 24. Upotreba dinamičke memorije RMI realizacije studije slučaja
Slika 25. Podaci o sakupljaču smeća RMI realizacije studije slučaja
80
Slika 26. Broj aktivnih niti i učitanih klasa RMI realizacije studije slučaja
Analizom prikazanih dijagrama dolazimo do podataka da je zauzeto 5.117 megabajta dinamičke(heap) memorije, a da je maksimalno korišćeno 3.044 megabajta dinamičke memorije. Virtuelna mašina je učitala 2595 klasa, pri čemu je maksimalno pokrenuto 9 niti. Sakupljač smeća je napravio 21 kolekciju smeća, a procenat vremena izvršenja koji JVM troši na sakupljanje smeća iznosi maksimalno 6.5% prilikom pokretanja aplikacije, dok najveći deo izvršavanja aplikacije iznosi 0%.
81
5.1.2. Monitoring EJB realizacije studije slučajaU nastavku prikazujemo rezultate monitoringa EJB realizacije studije slučaja „Evidencija radnih naloga”.
Slika 27. Upotreba dinamičke memorije EJB realizacije studije slučaja
Slika 28. Podaci o sakupljaču smeća EJB realizacije studije slučaja
82
Slika 29. Broj aktivnih niti i učitanih klasa EJB realizacije studije slučaja
EJB aplikacija zauzima 48,648 megabajta dinamičke(heap) memorije, od čega se koristi 33,6 megabajta. Virtuelna mašina je učitala 9020 klasa, pri čemu je maksimalno pokrenuto 48 niti. Sakupljač smeća je napravio 60 kolekcija smeća, a procenat vremena izvršenja koji JVM troši na sakupljanje smeća iznosi maksimalno 21.5% prilikom pokretanja aplikacije, dok najveći deo izvršavanja aplikacije iznosi 0%.
Dinamička meorija Sakupljač smeća(GC) Broj niti i učitanih klasaZauzeta memorija (MB)
Korišćena memorija(MB)
najveći broj kolekcija smeća
najviše vremena potrošeno na GC
broj učitanih klasa
broj pokrenutih niti
RMI 5.117 3.044 21 6.5 2595 9EJB 48.648 33.6 60 21.5 9020 48
Tabela 3. Rezultati monitoringa
83
5.2. Analiza performansi centralnog procesora
Analiza performansi centralnog procesora prikazuje broj poziva i vreme izvršenja svake metode u lancu pozvanih metoda aplikacije. Pozivom opcije prikazuju se tri izveštaja :
1. Lista poziva(Call Tree) prikazuje sve pozivane metode, i vreme izvršenja/broj pozivanja za svaku metodu, pri čemu su metode razvrstane u zavisnosti od niti u okviru koje se izvršavaju.
2. Najznačajnije tačke(Hot Spots) je prikaz broja poziva i vremena trajanja izvršenja svih metoda nezavisno od niti u okviru koje se izvršavaju.
3. Kombinovan prikaz prikazuje listu poziva u gornjem delu ekrana a najznačajnije tačke u donjem delu.
4. Informacije prikazuju osnovne informacije o pozivu opcije CPU Snapshot.
U nastavku navodimo performanse pozivanja udaljenih metoda za RMI i EJB3.0 realizacije studije slučaja. Vreme je mereno od momenta pozivanja udaljene metode klijenta do momenta kada klijentski program dobije povratnu vrednost od serverskog programa pri čemu metode na serveru samo vraćaju ulazni argument klijentu(perzistentni sloj nema uticaja). Primer metode koja se koristi za merenje performansi pozivanja udaljenih metoda za RMI i EJB3.0 tehnologije : @Stateless
public class ArtikalKontrolerBean implements ArtikalKontroler {... public ArtikalTO prikaziArtikal(String pk) throws RemoteException { Artikal artikal = new Artikal(pk); artikal.setCena(150d); artikal.setNaziv(„Naziv“); return artikal.createArtikalTO(); }...}
U tabeli koja sledi prikazane su performanse pozivanja udaljenih metoda za RMI i EJB3.0 realizacije studije slučaja. Rezultat merenja je izražen u nanosekundama.
Udaljene metode RMI EJB
Brisanje artikla 1973715 7172166
Prikazi artikal 2615975 8164166Unosi artikla 2922997 8733944Storniraj nalog 2141054 8507506Prikazi nalog 5662173 12121094Unesi nalog 5202616 11590300
Tabela 4. Performanse pozivanja udaljenih metoda za RMI i EJB realizacije studije slučaja
84
Na slici 30. je dat grafički prikaz rezultata iz tabele 4.
Slika 30. Performanse pozivanja udaljenih metoda za RMI i EJB realizacije studije slučaja
U tabeli koja sledi merene su performanse pozivanja udaljene metode u zavisnosti od broja stavki prodatog materijala koje se u okviru radnog naloga prenose kroz mrežu. Rezultat merenja je izražen u nanosekundama. Metoda koja se poziva na serveru i koja služi za merenja je : @Stateless public class RadniNalogKontrolerBean implements RadniNalogKontroler { ...
public RadniNalogTO prikaziRadniNalog(Integer pk) throws RemoteException { RadniNalogTO radniNalog = new RadniNalogTO(); postaviNalogTO(radniNalog,100); return radniNalog;}...
}1 10 100 1000
RMI 5632132 6579886 8358046 10927087EJB 12028624 11897602 36135598 71873939
Tabela 5. Performanse pozivanja udaljenih metoda u zavisnosti od broja stavki prodatog materijala koje se u okviru radnog naloga prenose kroz mrežu
Na slici 31. je dat grafički prikaz rezultata iz tabele 5.
85
Brisanje artikla Prikazi artikal Unosi artikla Storniraj nalog Prikazi nalog Unesi nalog0
2000000
4000000
6000000
8000000
10000000
12000000
14000000
RMI EJB
Slika 31. Performanse pozivanja udaljenih metoda u zavisnosti od broja stavki prodatog materijala koje se u okviru radnog naloga prenose kroz mrežu
U tabeli koja sledi prikazane su performanse pozivanja udaljene metode u zavisnosti od broja klijentskih niti koje istovremeno pristupaju serveru. Klijenti pozivaju istu metodu kao i u prethodnom testu pri čemu radni nalog ima 100 stavki materijala. Rezultat merenja je izražen u nanosekundama.
1 klijent 4 klijenta 8 klijenata 16 klijenataRMI 8358046 13806785 20312746 43678838EJB 36135598 45235220 59932650 93966984
Tabela 6. Performanse pozivanja udaljenih metoda u zavisnosti od broja klijenata koji istovremeno pozivaju metodu
Na slici 32. je dat grafički prikaz rezultata iz tabele 6.
Slika 32. Performanse pozivanja udaljenih metoda u zavisnosti od broja klijenata koji istovremeno pozivaju metodu
86
1 10 100 10000
10000000
20000000
30000000
40000000
50000000
60000000
70000000
80000000
RMIEJB
1 klijent 4 klijenta 8 klijenata 16 klijenata0
10000000
20000000
30000000
40000000
50000000
60000000
70000000
80000000
90000000
100000000
RMI EJB
U ovom poglavlju su prikazani rezultati monitoringa EJB 3.0 i RMI realizacije studije slučaja „Evidencija radnih naloga”. Nakon toga su prikazane performanse pozivanja udaljenih metoda za EJB i RMI tehnologije. Kriterijumi koji su korišćeni za merenje performansi su ulazno/izlazni tipovi podataka udaljene metode, broja klijenata koji istovremeno pozivaju metodu i veličine niza koji se prosleđuju kao ulazni i izlazni parametri metode. Na taj način smo realizovali treći cilj istraživanja (Dinamička analiza RMI i EJB 3.0 tehnologija).
5.3. Zaključak dinamičke analize Na osnovu izvršenog monitoringa EJB i RMI realizacija studija slučaja dolazimo do sledećih zaključaka :
1. Studija slučaja koja je realizovana RMI tehnologijom zauzima 5 megabajta, dok EJB realizacija studije slučaja zauzima 48 megabajta dinamičke memorije.
2. Studija slučaja koja je realizovana RMI tehnologijom učitava 2595 klasa i pokreće 9 niti, dok EJB realizacija učitava 9019 klasa i pokreće 48 niti
3. Sakupljač smeća prilikom izvršavanja EJB realizacije studije slučaja pravi tri puta više kolekcija smeća i troši više vremena rada procesora za sakupljanje smeća od RMI realizacije
Na osnovu navedenih zaključaka monitoringa ispunila su se očekivanja da RMI tehnologija ima bolje performanse od EJB 3.0 tehnologije. Analiza performansi RMI i EJB 3.0 tehnologija je dovela do sledećih zaključaka :
1) Pozivi udaljenih metoda RMI tehnologije se brže izvršavaju u odnosu na EJB tehnologiju2) Prilikom povećanja broja klijenata koji paralelno pozivaju udaljene metode na serveru RMI
tehnologija ima bolje performanse od EJB 3.0 tehnologije 3) Prilikom povećanja količine podataka koji se prenose između klijentskog i serverskog procesa
RMI tehnologija ima bolje performanse od EJB 3.0 tehnologije.
87
6. Zaključak
Očekivani doprinos master rada ogleda se u realizaciji postavljenih ciljeva:• Prikaz udaljenog pozivanja metoda (RMI) i korišćenje te tehnologije u realizaciji
klijent-server arhitekture• Prikaz EJB 3.0 tehnologije i njene primene u razvoju složenih aplikacija• Dinamička analiza RMI i EJB 3.0 tehnologija• Komparativna analiza dobijenih rezultata dinamičke analize
Kao razultat prikaza udaljenog pozivanja metoda (RMI) i korišćenja te tehnologije u realizaciji klijent-server arhitekture navodimo sledeća zapažanja :
1. RMI tehnologija smanjuje kompleksnost programiranja distribuiranih aplikacija obzirom da korisnik ne programira detalje interakcije između dva udaljena računara.
2. RMI tehnologija je prilagođena objektno orijentisanom programiranju – putem RMI-a se pozivaju metode objekta koje kao ulazne i izlazne parametre mogu imati primitivne ili referencene tipove podatataka, pri čemu se udaljenim objektima pristupa preko njihovih interfejsa što omogućava promenu realizacije interfejsa nezavisno od klijenta.
3. RMI koristi Java sigurnosne mehanizme(RMISecurityManager) koji obezbeđuju sigurnost distribuirane aplikacije
4. Postoje realizacije RMI tehnologije preko različitih mrežnih protokola (JRMP,IIOP, SOAP i dr.)
5. RMI omogućava distribuirano čišćenje smeća(Distributed Garbage Collector) kao i pokretanje serverskog programa sa klijentskog računara (Activation).
6. RMI podržava različite tipove soketa za transport podataka(RMI Socket Factory) što omogućava kriptovanje podataka(SSL), ili kompresiju podataka prilikom slanja na server.
Rezultat prikaza EJB 3.0 tehnologije i njene primene u razvoju složenih aplikacija daje sledeće zaključke :
1. EJB tehnologija smanjuje kompleksnost programiranja distribuiranih aplikacija obzirom da programer ne programira detalje interakcije između dva udaljena računara .
2. EJB tehnologija je prilagođena objektno orijentisanom programiranju – putem EJB-a se pozivaju metode komponenti koje kao ulazne i izlazne parametre mogu imati primitivne ili referencene tipove podatataka, pri čemu se udaljenim komponentama pristupa preko njihovih poslovnih interfejsa što omogućava promenu realizacije interfejsa nezavisno od klijenta.
3. EJB komponente se obavezno izvršavaju u okviru EJB kontejnera koji obezbeđuje usluge upravljanja transakcijama, upravljanje životnih ciklusa bean-ova, sigurnost i dr. koje značajno smanjuju napor programera koji ne mora da programira usluge servera.
4. EJB tehnologija omogućava pozivanje operacija bean-a različitim tipovima klijenata : servlet,JSP, Web servis, druga Java aplikacija, druga EJB komponenta, CORBA klijent i dr. , štoomogućava fleksibilnost u razvoju programa u smislu da se operacije bean-a mogu pozivatipreko Interneta, PDA uređaja i dr.
5. Java Bean-ovi su modularne softverske komponente u smislu da programer može koristitipostojeće bean-ove za kreiranje novih aplikacija.
88
Dinamička analiza RMI i EJB 3.0 tehnologija je sprovedena u dva koraka.1. Monitoring RMI i EJB 3.0 realizacija studije slučaja 2. Analiza performansi RMI i EJB 3.0 tehnologija
Monitoring studije slučaja dovodi do sledećih zaključaka :1. Studija slučaja koja je realizovana RMI tehnologijom zauzima 5 megabajta dinamičke(Heap),
dok EJB realizacija studije slučaja zauzima 48 megabajta2. Studija slučaja koja je realizovana RMI tehnologijom učitava 2595 klasa i pokreće 9 niti, dok
EJB realizacija učitava 9019 klasa i pokreće 48 niti3. Sakupljač smeća prilikom izvršavanja EJB realizacije studije slučaja pravi tri puta više
kolekcija smeća i troši više vremena rada procesora za sakupljanje smeća od RMI realizacije
Na osnovu navedenih zaključaka monitoringa ispunila su se očekivanja da RMI tehnologija ima bolje performanse od EJB 3.0 tehnologije. Analiza performansi RMI i EJB 3.0 tehnologija je dovela do sledećih zaključaka :
4) Pozivi udaljenih metoda RMI tehnologije se brže izvršavaju u odnosu na EJB tehnologiju5) Prilikom povećanja broja klijenata koji paralelno pozivaju udaljene metode na serveru RMI
tehnologija ima bolje performanse od EJB 3.0 tehnologije 6) Prilikom povećanja količine podataka koji se prenose između klijentskog i serverskog procesa
RMI tehnologija ima bolje performanse od EJB 3.0 tehnologije.
89
7. Literatura
[Vlajić 1] Dr Siniša Vlajić: Projektovanje programa (Skripta) Beograd 2004[Vlajić 2] Dr. Siniša Vlajić: Napredni koncepti Jave i Web programiranje u Javi, FON,Beograd 2005[Ćirić] Dr Siniša Vlajić, prof. dr Vidojko Ćirić, Dušan Savić: Projektovanje programa (Praktikum-programski jezik Java), FON, Beograd 2003.[Milić] Miloš Milić: Komparativna analiza Spring i EJB tehnologije, Beograd 2007[Bobić]Dragan Bobić: Veb aplikacija za javne prihode grada Beograda u PHP okruženju, Beograd 2007[RMI 1] Rickard Öberg : Mastering RMI, John Wiley&Sons, Inc. 2000[RMI 2] William Grosso : Java RMI, O’Reilly 2001[EJB 1] Grupa autora : Mastering EJB 3.0 , Wiley Publishing, Inc. 2006[EJB 2] Debu Panda, Reza Rahman, Derek Lane : EJB 3 IN ACTION, Manning Publications [EJB 3] Grupa autora : EJB Core Contracts and Requirements, Sun Microsystems 2006[EJB 4] Rod Johnson : J2EE™ Development without EJB Expert One-on-One™ , Wrox Press 2004[EJB 5] Bill Burke, Richard Monson-Haefel : Enterprise JavaBeans 3.0, O’Reilly 2006[EJB 6] Rima Patel Spriganesh, Gerald Brose, Micah Silverman : Mastering Enterprise JavaBeans 3.0, Willey publishing[JEE 1] J2EE Design patterns, O’Reily,September 2003 [JEE 2]Rod Johnson: Expert One-on-One J2EE Design and Development, Wrox Press 2003[JEE 3] Grupa autora : Java EE Tutorial, Sun Microsystems 2006[Veljović] dr Alempije Veljović : Osnove objektnog modeliranja UML, ”Svetlost” Čačak, 2004[Larman] Craig Larman : Applying UML and Patterns, Second Edition, Prentice Hall, New Jersy, 1998[Juric] Matjaz B. Jurić -Articles on performance and efficiency http://lisa.uni-mb.si/~juric/paperss.htm [Orenstein]Orenstein, David. "QuickStudy: Application Programming Interface (API)". 1.10.2000.[Zukowski] John Zukowski : Majstor za Javu 2, Kompjuter biblioteka 2004, Čačak.[Java API] Java interfejs za programiranje aplikacija (engl. Java Application Programming Interface – Java API) : http://java.sun.com/javase/6/docs/api/
90