20.08.2006., nedjelja
Java extras 1 - O/R mapping
Nastavljamo u duhu baza podataka i čitanja/pisanja po bazama podataka. Već smo napomenuli da EJB 2.1 pruža mogućnost replikacije zapisa u bazi podataka u objekte koji se zatim spremaju u EJB conatiner. Zamislimo istu mogućnost, ali ne s EJB, već s POJO. Što to znači? Zamislimo da entitete u bazi podataka pretvorimo direktno u niz objekata koji predstavljaju rezultate upita. Znači rezultate upita ne dobivamo kroz java.sql.ResultSet, već kao listu jednostavnih objekata.
Da biste to bili u mogućnosti izvesti, morate imati neki O/R (Object/Relational) mapping tool. Naravno, ako se dobri, stvarno dobri u programiranju, uvijek možete napisati svoj O/R mapping tool. Ili možete uzeti već gotove O/R mapping tool-ove. Kako mapping tool funkcionira? Mapping tool zapravo izvede traženi upit na bazi. Na temelju rezultata upita u java.sql.ResultSet obliku, klase iz koje će se stvarati objekti, te property mappinga (nešto slično EJB-RDB mappingu kod CMP entity beana), O/R mapping tool stvara listu objekata koja se nakon toga može koristiti.
Generalno, da biste ovo shvatili, morate imati neka predznanja o trajnom pohranjivanju objekata (Object Persistence). Da bismo trajno pohranili objekt, moramo pohraniti njegovo unutarnje stanje u neki trajniji spremnik podataka. Baza podataka predstavlja jedan takav spremnik. Što predstavlja unutarnje stanje objekta? Svojstva, a zatim i dodatne varijable koje su bitne za izvođenje poslovnih metoda. Naravno, ako pokušamo koncipirati objekt na način da imamo samo bitna svojstva, tada dileme nema. Objekt=tablice, svojstvo=atribut. Kod reaktivacije objekta samo čitamo upisana svojstva i ponovo formiramo objekt.
Hibernate
Hibernate je OpenSource O/R mapping tool koji možete pronaći ovdje! Nakon otpakiranja nalazite cijelu hrpu dodatnih library-a, dokumentacije, programa, itd...
Bitno je pročitati reference manual koji ćete dobit ovim downloadom. Prvo trebate u vašu aplikaciju dodati određeni niz library-a navedenih u reference manualu, a koje dobivate s downloadom Hibernate-a. Zatim trebate stvoriti konfiguracijski XML opisnik za hibernate. Opisnik se smješta u root source direktorija vaše WEB aplikacije i mora se zvati hibernate.cfg.xml.
Pokazat će se jedan jednostavan primjer (baziran na prethodnom članku) koji će pokazati kako koristiti Hibernate. Pokažimo primjer konfiguracijskog XML opisnika:
Ono zanimljivo kod Hibernate-a jest činjenica da su tvorci ovog tool-a razvili svoj vlastiti HQL (Hibernate Query Language). HQL je vrlo sličan klasičnom SQL uz razliku da se upotrebljava na objektima. Kako bi Hibernate HQL pretvorio u SQL za točno određenu bazu, u konfiguracijskoj datoteci smo naveli dijalekt SQL-a koji se koristi: org.hibernate.dialect.PostgreSQLDialect. Za neku drugu bazu koristimo drugi SQL dijalekt. Ovo nam daje izvanredne mogućnosti! Možemo sve upite napisati u HQL-u, a cijela WEB aplikacija nam je praktički nezavisna o bazi podataka koju koristimo. Samo promijenimo SQL dijalekt i spajanje na bazu i opet smo u igri.
Ako malo bolje pogledamo konfiguracijski XML opisnik, vidimo da i dalje koristimo JDBC driver, samo posredno, korištenjem Hibernate-a!
Slijedeći korak je izrada singletona koji će nam omogućiti pristup jedinstvenom org.hibernate.SessionFactory. Ovo možemo pronaći reference manualu, poglavlje 1.2! Slijedeće što moramo napraviti jest klasa objekata koji će se stvarati.
Slijedi mapping koji će se nazvati Mapping.hbm.xml. Ovo smo već definirali u konfiguracijskom opisniku.
Sada još pokažimo kako napraviti upit...
HibernateUtil predstavlja singleton o kojem smo govorili, a koji će svima dati jednak SessionFactory. Ovdje moramo posebno naglasiti da treba voditi računa o Session-u. Svaki HTTP request rezultira stvaranjem nove dretve u Java serveru u kojoj se HTTP request obrađuje. Kroz cijelo svoje trajanje dretva bi trebala koristiti isti Session. Ukoliko Session na početku ne vežemo uz dretvu, nakon prvog zatvaranja transakcije nad bazom podataka, zatvorit će se i Session koji smo koristili za izvođenje upita. Slijedeće povlačenje Session-a iz SessionFactory-a rezultirat će stvaranjem novog Session-a, a time i novog konteksta, što u nekim slučajevima može rezultirati greškama. Preporučam proučavanje paketa org.hibernate.context!
Zašto je to bitno? Zamislite da imate asocijacije. Hibernate može raditi i s asocijacijama objekata. Međutim, asocijacije mogu uključivati lazy-reading. Što to znači? To znači da se prilikom čitanja objekta, njegovim podobjektima čitaju samo identifikatori. To automatski znači da se podtabele u kojima se nalaze podobjekti ne čitaju. Tek kad se dohvati neko konkretno svojstvo podobjekta (ne identifikator), tada Hibernate počinje čitati podtabelu u bazi podataka u kojoj se nalazi traženi podobjekt. Ovo je vrlo lijepo svojstvo koje značajno ubrzava čitanje po bazi podataka. Čita se samo ono što program zaista treba. Klasični pristup, za čitanje jednog objekta uključivao bi čitanje svih njegovih podobjekata, pa svih podobjekata od podobjekata, pa.... Ovo naravno nije baš dobra metoda ako u našem objektnom modelu imamo mnogo asocijacija, a posebno ako imamo kružne asocijacije - ova pojava može završiti beskonačnom petljom i smrću servera ili programa.
Ako želimo omogućiti tehnologiju lazy-readinga za podobjekte, jednom izdani Session mora vrijediti kroz cijelu dretvu kojom se opslužuje HTTP request ili čak u nekim slučajevima i kroz cijeli HTTP session!
Jedan od mogućih problema uključuje multipliciranje objekata. Zamislimo da naš Korisnik ima podobjekt Posta. Ako čitamo listu korisnika, naravno da je moguća pojava iste pošte kod dva različita korisnika. To znači da bi Hibernate mogao stvoriti dva ista objekta klase Posta? Ako jednome promijenimo neko svojstvo, što se u tom slučaju dešava s drugim? Naime, Hibernate u Session-u čuva listu repliciranih objekata, pa ako se objekt već pronađe u toj listi, vraća se taj objekt s liste, a ponovna replikacija se preskače. To znači da ćemo u opisanom slučaju u memoriji imati dva objekta klase Korisnik, a samo jedan objekt klase Posta.
Postoji mogućnost pojave istog objekta u različitim Session-ima. To će automatski povlačiti mogućnost konflikta. No, bez brige! Taj će se konflikt razriješiti transakcijom nad bazom podataka. Svi izvantransakcijski konflikti razrješavaju se prethodnom provjerom stanja objekta u bazi podataka. To znači da bi možete imati replicirani objekt u memoriji servera (u HTTP sessionu npr.) po par dana, a ako je stanje u bazi podataka drukčije od onog kakvo je bilo prilikom replikacije objekta, Hibernate baca iznimku koja označava konflikt. Upravo stvoreno za WEB aplikacije!!
Pokažimo drugi primjer!
Klasa Posta...
I Mapping.hbm.xml...
EJB 3.0 se prilično približava načinu na koji funkcionira Hibernate. Zapravo se vodi dosta rasprava o tome koliko je Hibernate svojom pojavom, jednostavnošću i popularnošću uticao na EJB 3.0!
Hibernate smatram izuzetnim dodatkom, alatom koji je napravio malu revoluciju u O/R mappingu. Ne mogu zamisliti niti jednu WEB aplikaciju bez Hibernate-a, a u zadnje vrijeme razmišljam o korištenju u troslojnim aplikacijama. Iako to baš nema puno smisla u trenutku kad EJB 3.0 postaje sve popularniji i zastupljeniji u Java EE serverima.
Za one koji vole alternative, tu je iBATIS!
|
- 16:41 -
Komentari (1) -
Isprintaj -
#
19.08.2006., subota
Java tehnologije 3
Paketi (Packages)
Kada se učita virtualni stroj unutar kojeg se izvodi Java program, automatski se učitava i cijeli niz arhiva koje čine JRE/JDK. Te arhive već u sebi imaju cijeli niz klasa i sučelja koje Java program može koristiti. Svaka klasa, osim svojeg naziva može imati i poseban prefiks. Prefiks ispred naziva klase predstavlja paket u kojem se klasa nalazi. Primjer jedne takve klase iz JRE/JDK je java.sql.Driver. Paket je java.sql, dok je naziv klase Driver (konvencija je da Java klase počinju s velikim slovom). Drugi primjer je java.text.SimpleDateFormat. Vaše klase sa vašim paketima uključuju se u zajednički prostor klasa JRE/JDK-a. Isto vrijedi i za dodatne library-e u arhivama koje koristite. Preporuča se da svoje klase stavljate u jedinstvene pakete tipa com.moja_firma ili org.milkyway. Naravno, ovo ovisi o programeru ili poduzeću. Ovakvo strukturiranje klasa je vrlo nalik na strukturu tvrdog diska.
JDBC
Prije daljnje priče oko Jave, moramo spomenuti rad s bazama podataka. Baze podataka nezaobilazni su dio WEB ili troslojnih aplikacija. Da bismo u Java programu mogli koristiti bazu podataka, treba nam posebni driver za bazu podataka. Java ima standardizirano sučelje za drivere za baze podataka koje se naziva i JDBC (Java DataBase Connectivity). Zbog toga se driveri za baze podataka zovu JDBC driveri. Uglavnom, svi driveri predstavljaju zapravo realizaciju apstraktnih klasa i sučelja iz java.sql paketa. Sučelje java.sql.Driver predstavlja početnu točku svakog JDBC drivera. Na JDBC driveru je da realizira to sučelje.
Manje više sve baze podataka nude i JDBC drivere. JDBC drivere ću spomenuti u kontekstu par zanimljivih i besplatnih baza podataka:
- MySQL - OpenSource baza podataka. Ova je baza dobar početak za programiranje WEB aplikacije. Zanimljivo je da dosta WEB hostinga nude kombinaciju Tomcat/MySQL, što će zadovoljiti većinu manjih i srednje velikih WEB aplikacija. Bazu možete pronaći ovdje! Za MySQL 5.0 JDBC driver možete pronaći ovdje! Za administraciju ove baze podataka preporučam phpMyAdmin kojeg možete pronaći ovdje! Za phpMyAdmin morate imati Apache WEB server koji može interpretirati PHP skripte.
- PostgreSQL - OpenSource baza podataka. Ovo je već značajnije bolja baza podataka od MySQL-a. Ima mnogo više opcija, puno je stabilnija i može progutati veće količine podataka. Bazu možete pronaći ovdje, a JDBC driver ovdje! Nažalost, nisam pronašao dostupan hosting sa Tomcat/PostgreSQL kombinacijom. Preporučam korištenje pgAdmin-a za administraciju baze koji se može pronaći ovdje!
Primjer spajanja i upita na PostgreSQL bazi:
Prethodni kod je dobar i za druge baze podataka. Potrebno je promijeniti klasu drivera koja više neće biti org.postgresql.Driver, connection string za spajanje na bazu podataka, te sam upit koji može varirati od baze do baze. Detalje kako koristiti driver možete pronaći na stranici s koje ste ga downloadali.
|
- 19:33 -
Komentari (2) -
Isprintaj -
#
18.08.2006., petak
Java serveri
Slijedeća bitna stvar u životu svakog Java programera je server. Vidite, Java je izvanredna u mrežnoj okolini, a malo manje izvanredna kod pisanja standalone aplikacija. Zbog toga većina programera upotrebljava Javu za WEB ili troslojne aplikacije (Java EE). No, istog trenutka nakon što ste se odmaknuli od standalone aplikacija i prešli na mreže, bit će potreban server za izvođenje vaše aplikacije. Zajedničkim nazivom: Java server. Molim da se ovi serveri ne brkaju i ne poistovjećuju sa WEB serverima. Razlika je u načinu kako serveri upravljaju mrežnim konekcijama i kako se stvaraju procesi za opsluživanje korisnika. Ovdje moramo razlikovati dvije osnovne vrste servera: Java SE i Java EE serveri. Razlika je u JDK pod kojim se serveri izvode. Treba se napomenuti da je za Java servere potrebna JDK, a ne JRE! JSP skripte se moraju kompajlirati, a to čini Java server prilikom prvog poziva skripte. Razlika je i u mogućnostima koje server pruža WEB ili troslojnoj aplikaciji.
Java SE serveri
Tomcat - niže od verzije 5.5
Radi se o OpenSource Java serveru koji služi za izvođenje Java SE WEB aplikacija. Server se može pronaći ovdje! Sa Tomcat Java serverom se ne dobiva JDK, a sve verzije 5.x zahtijevaju Sun JDK verzije 1.5.0 i više! Niže verzije Tomcata od 5.x mogu se izvoditi na Sun JDK 1.4.2! Server je zapakiran u klasične arhive - nije potrebna nikakva instalacija već se server otpakira i pokrene (za Windows operacijske sustave možete skinuti i instalacijsku verziju - exe). Naravno, za pokretanje servera treba imati JDK bin poddirektorij u PATH enviroment varijabli. Server u svojem bin poddirektoriju ima skripte za svoje pokretanje (startup.sh i startup.bat) i zaustavljanje (shutdown.sh i shutdown.bat). Server će se inicijalno moći pronaći na portu 8080. Browserom možete testirati aktivnost vašeg servera koristeći link http://localhost:8080 ! Dodatnu provjeru možete uraditi pregledom liste procesa na računalu. Ako je server aktivan mora biti prisutan barem jedan java proces.
Konfiguracije
Sve konfiguracijske datoteke mogu se pronaći u conf poddirektoriju Tomcat servera. Bitnije konfiguracijske datoteke su server.xml i users.xml! U server.xml možete pronaći sve postavke servera. Od HTTP porta, HTTPS porta, porta za coyote connector (nešto kasnije) i slično. Datoteka users.xml sadržava korisnike administracijskih aplikacija za server. Do administracijske aplikacije možete doći korištenjem linka http://localhost:8080/admin !
Logovi
Svi logovi se mogu pronaći u logs poddirektoriju vašeg servera. Osnovni log je catalina.out ! U ovom logu će se pronaći svi detalji i problemi, kao i ispisi vaših WEB aplikacija. Bitno je uočiti da u ovaj log idu ispisi svih aplikacija, te se kod ispisa i bug trackinga preporuča ispisati i o kojoj se WEB aplikaciji radi.
WEB aplikacije
WEB aplikacije se smještaju u webapps poddirektorij. WEB aplikacija koja se stavlja na server može biti u expanded obliku ili u obliku arhive - WAR (WEB Application aRchive).
Ako se aplikacija deploya u expanded obliku, u tom slučaju se u webapps poddirektoriju stvara novi poddirektorij s nazivom WEB aplikacije. U taj se poddirektorij stavljaju sve datoteke koje trebaju za funkcioniranje WEB aplikacije (HTML, JSP, JS, CSS, XML, ...). Uz sve te datoteke dolazi i poseban poddirektorij koji čuva class datoteke programa (kompajlirani iz java koda), te opisnik WEB aplikacije. Ovo treba izgledati na slijedeći način:
..../webapps/moja_aplikacija/index.html
..../webapps/moja_aplikacija/style.css
..../webapps/moja_aplikacija/prva.jsp
..../webapps/moja_aplikacija/ispis.jsp
..../webapps/moja_aplikacija/WEB-INF/classes/org/moja_firma/servleti/MojServlet.class
..../webapps/moja_aplikacija/WEB-INF/lib/ifxjdbc.jar
..../webapps/moja_aplikacija/WEB-INF/web.xml
Datoteka web.xml predstavlja opisnik WEB aplikacije. Unutar WEB-INF direktorija postoji i lib poddirektorij u koji stavljamo sve vanjske library-e koje WEB aplikacija koristi. Vanjski library-i dostupni su u obliku arhiva (Java Application aRchive) . Nakon što smo na ovaj način posložili WEB aplikaciju, sve što trebamo je restartati server. Provjera aktivnosti aplikacije može se izvesti korištenjem administracije servera. Ako aplikacija nije aktivna, razlog provjerimo u logu.
Deployment WAR arhive se izvodi korištenjem administracije servera. Ovo je standardan način deploymenta WEB aplikacije ako se server ne nalazi na vašem računalu. WAR sa sobom nosi cijelu WEB aplikaciju.
Eclipse i Tomcat
Vrlo je zanimljivo automatizirati ovaj deployment WEB aplikacija iz razvojnog alata. Pretpostavimo da se skinuli eclipse i većinu dostupnih pluginova koji dolaze uz eclipse. Otvorite eclipse i odaberite opciju Window > Show View > Other ! Otvara se prozor s popisom. Pronađite server view i kliknite OK. U donjem dijelu prozora otvara se jedan tab s nazivom Servers. Desnim klikom iznad praznog prostora u tabu dobivamo kontekstni izbornik u kojem možemo pronaći opciju New > Server. Sada odaberemo Tomcat koji imamo na raspolaganju i slijedimo wizard do kraja.
Kada pokrećemo WEB aplikaciju, dovoljno je napraviti desni klik iznad projekta WEB aplikacija (lijeva strana prozora), te odabrati opciju Run > Run on server. Nakon toga se otvara wizard koji će vam pomoći spojiti projekt WEB aplikacije sa serverom iz liste koju ste prethodno definirali. Nakon pokretanja WEB aplikacije, u donjem dijelu prozora otvara se View u kojem možete pronaći server log printout (catalina.out).
Upravljanje Java serverom izvodi se u Servers view-u. Kliknete na server s kojim nešto želite učiniti, a opcije se nalaze na kontekstnom izborniku koji se dobiva desnim klikom.
Java EE serveri
Tomcat v5.5
Od verzije 5.5 na dalje, osim WEB containera, Tomcat sadrži i EJB container. Iako to nisam isprobao, imam namjeru isprobavanja u skoroj budućnosti. Server možete pronaći ovdje!
IBM WebSphere Application Server
Komercijalni Java EE server. Ima različitih verzija, u različitim cjenovnim razredima. Ako bismo Tomcat usporedili sa stojadinom, WAS je Mercedes među Java EE serverima. Izvodi se na IBM JDK 1.4! Ovaj server je toliko obiman da ga osobno ne mogu savladati ni nakon par godina rada i administracije s njim. Server ima fantastičnu administracijsku WEB aplikaciju s kojom možete učiniti gotovo sve (osim kad treba restartati servere). Od svih goodiesa moram spomenuti neke: formiranje clustera (kod network deployment verzije), kontrolu JNDI (Java Naming Directory Interface), fantastična kontrola datasource-va, sinkronizacije, deploymenta aplikacije, itd...
Iako u nekim dijelovima još ima nekih sitnih bugova, u odnosu na veličinu i mogućnosti koje ovaj server nudi to su prave sitnice. Razočarava jedino činjenica da WAS6 u sebi ne nosi EJB 3.0! No, nadajmo se da će se i to doraditi u kratkom roku. Server se prirodno spaja u testing enviroment kod Rational Application Developera. Moguće ga je integrirati i sa eclipse.
JBoss
OpenSource Java EE server. Fin server sa mnoštvom opcija. Ima nekolicinu dodatnih pluginova za eclipse koje si možete dodati "usput". Lako se integrira u eclipse. Razlog zašto spominjem ovaj server je ostvarenje EJB 3.0! Viva JBoss! Server možete pronaći ovdje !
BES - Borland Enterprise Server
Komercijalan Java EE server. Još jedan od finih servera. Nešto slabiji od IBM WAS-a, no održavanje i support servera je klasično na Borlandovom visokom nivou, što je jedan veliki plus.
Od ostalih Java EE servera trebamo spomenuti:
BEA WebLogic - Komercijalan. Server se može pronaći ovdje
Sun Java System Application Server - komercijalan. Koristi Java EE JDK 1.5.0! Također podržava EJB 3.0! Server se može pronaći ovdje !
Apache Geronimo - OpenSource. Java EE server iz Apache radionice. Podržava EJB 3.0! Ovo je server kojeg svakako namjeravam isprobati u bližoj budućnosti. Home page servera je ovdje !
|
- 20:16 -
Komentari (2) -
Isprintaj -
#
17.08.2006., četvrtak
Java IDE
Pa krenimo. Gdje početi? Prvo bih preporučio nabavku nekakvog razvojnog alata koji će poslužiti za razvoj programa. Naravno, uvijek te stvari možete razvijati u običnom tekst editoru tipa UltraEdit, Notepad, vi ili nešto slično. Moj savjet: odustanite od takvog nauma. Potrošit ćete mnogo vremena, a rezultati će biti skoro pa nikakvi.
Počnimo od komercijalnih alata. Napominjem da ideja ovog posta nije reklama, već upoznavanje s različitim opcijama koje mogu poslužiti za razvoj programa u Javi.
Borland JBuilder
Prvi alat s kojim sam radio u Javi. Dobar alat. Dolazi unutar većeg paketa u kojem se mogu naći alati za dizajn (dobar Together), testiranje, deployment, itd... Jednako funkcionira na Windows, kao i na Linux operacijskim sustavima. JBuilder je fantastično brz IDE s dosta opcija, editora, wizarda i svim potrebnim sitnicama koje vam omogućavaju život jednostavnijim. Jedno veliko razočaranje u JBuilder-u X (kojeg sam isprobavao) bio mi je nedostatak HTML/JSP dizajnera. Bez obzira na to, JBuilder ima fantastično brz i funkcionalan editor za vizualne klase (Swing, AWT). Izvanredno se integrira sa serverima. Sve u svemu vrlo dobar alat, iako su mu u verzijama koje sam isprobavao falili neki poprilično bitni detalji. Kad pogledate cijenu alata, više nećete biti tako oduševljeni.
WebSphere Studio Application Developer / Rational Application Developer
IBM alat, baziran na eclipse-u kao podlozi, odn. frameworku. Alat je samo jedna kockica u lepezi IBM-ovih alata, a za programere sasvim dovoljan. Alat je prilično moćan. Ima hrpe dizajnera, editora, wizarde za opisnike. Izvanredno se integrira sa velikim brojem servera. Nudi preglede i spajanje na razne tipove baza podataka. Od svega toga treba spomenuti HTML/JSP/JSF dizajner i editor, dizajnere i editore za vizualne klase, wizarde za WEB, Java EE i druge opisnike. Ima wizarda za razne dodatne tehnologije tipa Apache struts. Uglavnom alat ima sve potrebno za razvoj Java EE aplikacija. Još jedna pozitivna stvar je mogućnost uključivanja dodatnih pluginova u eclipse na kojem RAD funkcionira.
Negativnost ovog alata je njegova glad za resursima. Nemojte niti pokušavati raditi s alatom ako nemate barem P4 i 1Gb RAM-a. Preporučam 2Gb RAM-a. Alat je prilično velik i neki dijelovi su bug-oviti. Nadajmo se da će se te stvari popraviti u slijedećim verzijama. Šteta tako dobrog alata. Cijena nešto prihvatljivija nego Borland JBuilder.
Od drugih komercijalnih alata mogu još spomenuti Sun NetBeans i BEA Workshop.
Osim komercijalnih, moraju se spomenuti i besplatni alati.
Eclipse
Eclipse, osim što predstavlja izvrsnu platformu i framework za razvoj alata, i sama predstavlja alat za programiranje u Javi. Što je zapravo eclipse i kako funkcionira? Eclipse je podloga i framework. Sama po sebi ne predstavlja razvojni alat, već omogućava stvaranje pluginova koji čine razvojni alat. Kakve i koliko pluginova ćete instalirati u svoj eclipse, ovisi samo o vama i vašim potrebama. Uz eclipse razvijena je nekolicina pluginova koji zajedno čine sasvim pristojan početni alat za razvoj programa u Javi. Naravno, nema tu veliki broj dizajnera, editora i wizarda, već toliko da se pokrije ona osnova koja svima olakšava život. Pa kako do dobrog alata uz pomoć eclipse-a?
Callisto download
Koja je zapravo ideja callista? Korisnici, često zbunjeni verzijama pluginova i verzijama eclipse-a nisu bili u mogućnosti sastaviti alat od traženih pluginova. Callisto predstavlja sinkronizaciju svih pluginova i projekata. Svi pluginovi izlaze istog trenutka kad i novi eclipse. Na taj se način izbjegavaju problemi sa verzijama i kompatibilnošću.
Eclipse je nažalost, kao i RAD, gladna za resursima. Naravno, to sve ovisi o vrsti i broju pluginova koje ste instalirali u eclipse. Preporuke su slične kao i za RAD.
Svi ovi alati (a posebno ovi koji su bazirani na eclipse) koncipirani su da funkcioniraju na različitim operacijskim sustavima. Pa to je i bit Jave. Ako ste volite Linux, Java je pravi izbor jer nećete imati problema u odabiru razvojnog alata za vaše programiranje!
|
- 19:04 -
Komentari (0) -
Isprintaj -
#
14.08.2006., ponedjeljak
Java tehnologije 2
Dosad smo pričali o osnovnim tehnologijama koje nudi Java, a koje se mogu pronaći unutar svakog JRE/JDK. Ono o čemu je bilo riječi može se pronaći u svim Java SE (Java Standard Edition) JRE/JDK. Naravno, uz Java SE postoji i nešto šira verzija JRE/JDK. Java EE (Java Enterprise Edition) je proširena verzija JRE/JDK. Ova verzija uključuje EJB (Enterprise Java Beans).
Troslojna arhitektura
Osnovna ideja Java EE je izgradnja troslojne arhitekture. Najniži sloj predstavljaju podaci informacijskog sustava organizirani u neke smislene strukture. U ovom sloju redovito nailazimo na bazu podataka. Neki će ovdje komentirati kako baza podataka sadrži i neke programske elemente (pohranjenje procedure), pa nije čisti podatkovni spremnik, već može sadržavati i poslovne algoritme. U principu te pohranjene procedure logički spadaju u srednji sloj. Srednji sloj je zapravo poslovni sloj koji u sebi sadrži poslovna pravila, odn. algoritme. Srednji sloj se može izvesti na različite načine: pohranjene procedure, POJO (Plain Old Java Objects), EJB.
Naviši sloj predstavlja prezentacijski sloj. Radi se o korisničkom sučelju. Nije bitno o kakvom se koričkom sučelju radi: standalone aplikaciji, WEB aplikaciji, appletu ili nečem drugom. Bitno je naglasiti da ovaj sloj ne sadrži poslovne algoritme.
Većina od vas će reći: pa uglavnom svi programi su onda troslojni. Imam spremnik za pohranu podataka, poslovne algoritme, a bome i korisničko sučelje! Pa o čemu onda ovaj tu priča!?
Ideja novijeg pristupa troslojnim arhitekturama ide u smjeru jasnog razdjeljivanja pojedinih slojeva. Iako je to u slučaju baze podataka (zbog pohranjenih procedura) skoro nemoguće, ideja je toliko rigorozna da se, u cilju čistoće, ne preporuča korištenje pohranjenih procedura. Poslovni sloj se potpuno odvaja i ne smije sadržavati nikakve vizualne elemente. Prezentacijski sloj također mora biti jasno odvojen od poslovnog i ne smije sadržavati nikakve izračune, preračune, već se gotovi podaci za prikaz vuku iz poslovnog sloja.
EJB
Već smo napomenuli da se EJB smješta u poslovni sloj. Pa što su zapravo Enterprise Java Beans? Većina ljudi koji su već dugo u programiranju ne znaju jasno odgovoriti na ovo pitanje. EJB su zapravo razdijeljeni mrežni objekti. Razdijeljeni mrežni objekt (Fragmented object) je vrsta objekta koji se istovremeno izvodi na više različitih računala i povezan je računalnom mrežom. Naravno da takav objekt može funkcionirati i na istom računalu. U tom slučaju dijelove objekta (object fragments) ne povezuje mreža, već lokalna petlja.
Zašto uopće EJB? Živimo u svijetu u kojem je skalabilnost i raspodijeljenost sustava postala primarna stvar kod dizajna i ostvarenja informacijskog sustava. EJB su odgovor na pitanje: kako napraviti informacijski sustav koji se izvodi na više različitih računala, više različitih baza podataka, više različitih kontinenata, a da krajnji fizički korisnik zapravo uopće ne osjeti tu raspodijeljenost informacijskog sustava prilikom korištenja.
Imamo dvije osnovne vrste EJB-a: entity i session beanovi. Entity beanovi su zapravo replike podataka iz podatkovnog sloja unutar EJB spremnika (EJB container). Na zahtjev, stvara se niz objekata koji predstavljaju replike entiteta iz baze podataka. Entity beanovi mogu imati i poslovne metode, koje se odnose na konkretan entitet. Session beanovi služe za čuvanje poslovnih metoda. Iako mogu imati unutarnje stanje, to unutarnje stanje nije vezano uz trajni spremnik, osim ako se to ne izvede programski.
Entity beanovi se dijele u dvije grupe: BMP i CMP entity beanove. BMP (Bean Managed Persistence) su entity beanovi koji sami upravljaju transakcijama, čitanjem i pisanjem po bazi podataka. BMP entity bean sam upravlja sinkronizacijom svojeg unutarnjeg stanja i baze podataka. CMP (Container Managed Persistence) su entity beanovi koji sinkronizaciju svojeg unutarnjeg stanja s bazom podataka prepuštaju Java EE serveru - nema dodatnog programa kojeg mora napisati programer, ali zato ima EJB-RDB mapping. EJB-RDB mapping je zapravo XML opisna datoteka koja generatorima koda objašnjava kako generirati sinkronizaciju unutarnjeg stanja CMP entity beana i baze podataka. To je zapravo čisto mapiranje svojstva CMP entity beana i polja u tablici unutar baze podataka.
EJB naravno napreduje kroz vrijeme. Tako postoje različite vizije EJB-a u budućnosti. Postoji više različitih standarda za EJB. Trenutno aktivan i najkorišteniji je EJB 2.1! EJB 2.1 je prilično opsežan i kompliciran. Za svaki EJB se definira više sučelja. Osim sučelja i ostvarenja EJB-a, postoji XML opisna datoteka koja definira ostatak detalja vezan uz sam EJB. Generatori koda zatim taj opisnik pretvaraju u niz kodova, koji se konačno uključuje u krajnji program. 2.1 EJB ne može živjeti izvan spremnika Java EE servera (EJB container).
Novija razmišljanja idu u smjeru pojednostavnjenja rada s EJB, barem kada se radi o lokalnim pozivima. Želi se izbjeći korištenje spremnika (EJB container-a). Tako nastaje novi standard - EJB 3.0, kojeg neki Java EE serveri već ostvaruju. EJB 3.0 je "revolucionaran" u pogledu životnog ciklusa i smještaja entity beanova. Entity beanovi u ovom standardu bliži su POJO pristupu kakvog nudi Hibernate (o tome će još biti riječi). Filozofija zagovaratelja EJB 3.0 ide u smjeru pojednostavnjenja rada s entity beanovima. I dalje postoje sve dobre strane EJB 2.1, posebno one koje se odnose na uspostavu raspodijeljenog sustava. Filozofija EJB 3.0 ide u smjeru umatanja (wrapping) entity beanova u Session facade pattern (vidi OOP patterns).
|
- 19:11 -
Komentari (0) -
Isprintaj -
#
07.08.2006., ponedjeljak
Java tehnologije 1
Java, kao platforma, sadrži širok spektar različitih tehnologija. Tehnologija se bira u ovisnosti o tome što želimo isprogramirati, odn. koji je naš cilj.
AWT/Swing/SWT
Radi se o standardnim dijelovima Jave koji pokrivaju, odn. koriste se za programiranje standalone vizualnih aplikacija. Ovakve aplikacije pokrivaju i Java applete. Java applet koji se izvršava unutar browsera na strani klijenta je zapravo vizualna standalone aplikacija kojoj browser samo "posuđuje" svoj canvas ili površinu za crtanje.
Prvi nastaje AWT (Abstract Windowing Toolkit). AWT je poprilično rudimentaran dio Jave. Naravno, omogućava programiranje vizualnih standalone aplikacije, no broj komponenata je prilično ograničen. Sam izgled aplikacije je također oskudan i često je ovisan o samom JDK. Može se desiti da aplikacija pisana u AWT-u drukčije izgleda na Linux, Windows i UNIX operacijskim sustavima, a i od verzije do verzije JRE se to može znatnije mijenjati. Dobra strana je što AWT postoji i u starijim verzijama Jave, pa se barem tu ne trebaju stavljati neka ograničenja glede verzije ili implementatora JRE/JDK.
Neka sredina predstavlja SWT (Standard Widget Toolkit). Izrađen od strane IBM-a. Uglavnom se koristi u Eclipse-u. Kompleksniji od AWT-a, no to još uvijek ne dostiže kompleksnost koju nudi Swing. No, SWT je ujedno i značajnije brži od Swinga.
Swing je najnoviji i najopsežniji dio Jave koji se koristi za izradu standalone vizualnih aplikacija. Nekim dijelovima se oslanja na AWT, pa ne treba čuditi da se AWT i Swing djelomice preklapaju. Swing u svim implementacijama JRE/JDK funkcionira jednako. Aplikacije izgledaju jednako. No, Swing je kompleksan i spor.
Osobno se ne bavim izradom ovakvih vrsta aplikacija. Imam neka sitnija ostvarenja. Kod izrade ovakvih aplikacije uglavnom je problem što se teško pronalaze vizualni dizajneri. Vrlo malo programera se odlučuju na programiranje vizualnih aplikacija u klasičnom editoru. O ovome će još biti riječi.
Servlet/JSP/JSF
Ovakva kombinacija se koristi za izradu WEB aplikacija. Govorimo o raznim tipovima i vrstama WEB aplikacija. Ova kombinacija tehnologija je ujedno i najzastupljenija kad govorimo o programiranju u Javi.
Servlet predstavlja aktivnu komponentu WEB aplikacije. Servlet uobičanjeno predstavlja klasu koja naslijeđuje neko sučelje predefinirano Java standardom. Ovo nisu klase koje ostvaruju vizualne objekte, već objekte koji služe za obradu zahtjeva upućenih od strane WEB browsera. HTTP request upućen od strane browsera prema Java serveru može aktivirati neki od servleta, koji zatim obradi HTTP request i formira HTTP response kao odgovor prema browseru. Servlet, iako nije vizualan, može na programski način napuniti HTTP response HTML kodom, ili nekim drugim odgovorom koji browser može interpretirati kao vizualnu informaciju.
JSP (Java Server Pages) su zapravo server-side skripte koje formiraju HTML stranice. Radi se o klasičnim HTML stranicama "obogaćenim" aktivnim kodom koji može interpretirati Java server. U ovisnosti o aktivnom kodu unutar JSP-a, server formira HTML stranicu koja se vraća kroz HTTP response do browsera.
JSF (Java Server Faces) je relativno nova tehnologija koja može značajno pojednostaviti izradu WEB aplikacija, kada govorimo o poslovnim WEB aplikacijama. JSF u sebi sadrži hrpe već gotovih komponenti. Izrada stranice se uglavnom svodi na slični postupak kao i kod izrade vizualnih standalone aplikacija. JSF nudi cijeli niz gotovih library-a koji omogućavaju jednostavnu kontrolu komponenti na stranici. Svi znamo kako može biti problematično hvatanje key eventa na samoj stranici. JSF ovakve stvari rješava bez problema. Cijeli niz komponenti je asinkrono (AJAX). Osim toga, JSF u sebi već sadrži ostvarenje MVC (Model View Controller pattern), što znači da vam je tehnologija poput Apache struts totalno nepotrebna (o Apache struts nešto više kasnije).
Ovakva kombinacija tehnologija često se koristi za izradu WEB aplikacija ili izradu prezentacijskog sloja u slučaju višeslojnih aplikacija.
|
- 18:42 -
Komentari (0) -
Isprintaj -
#
22.07.2006., subota
Java
Što reći o ovoj temi? Jednom sam se prilikom našao u poziciji jednom poznaniku objašnjavati kako započeti s Java programskim jezikom. Zadnjih dana vidim da nije jedini kojeg to zanima. U trenutku razmišljanja o tome kako objasniti gdje i kako započeti s Javom, shvatio sam da to nije baš lagan, bezazlen i malen zadatak.
Prvo što trebate znati jest neke osnovne informacije o Java programskom jeziku. Programski jezik je razvijen od strane Sun Microsystems i predstavljen "davne" 1995. godine.
Osnovna ideja Jave je fleksibilnost. Jedna od osnovnih mogućnosti Jave je njezina neovisnost o arhitekturi računala, kao i operacijskom sustavu. Jednom napisani program može se jednako pokrenuti na i386, x86, x86_64, ppc arhitekturi procesora. Osim toga, isti program se bez preinaka jednako može pokrenuti na Windows, Linux i UNIX operacijskim sustavima. Upravo zbog toga je Java dobro prihvaćena među velikim proizvođačima strojne i programske podrške (osim naravno Microsofta).
Da bi to bilo moguće, Java je koncipirana na principu virtualnog stroja. Prilikom prevođenja source koda pisanog u Javi, program prevodioc ne prevodi program sve do izvršnog koda, već stvara neku vrstu standardiziranog međukoda - Java bytecode. Da biste pokrenuli program pisan u Javi morate imati virtualni stroj (VM - virtual machine) koji će vam omogućili pokretanje programa. Virtualni stroj pretvara međukod u izvršni kod za određenu arhitekturu procesora. Ovdje je također bitan i operacijski sustav na kojem se program izvodi.
Virtualni stroj za Javu možemo dobiti sadržan u:
- JRE
Java Runtime Enviroment - Služi isključivo za pokretanje Java programa.
- JDK
Java Development Kit - Sadrži i programe prevodioce. Nužno kad razvijate programe ili kad pokrećete određene module ili produkte bazirane na Javi (recimo serveri).
Kada govorimo o JRE ili JDK, moramo shvatiti da to nije samo virtualni stroj za pokretanje programa, već da u sebi sadrži dodatne programe i library-e za rad s Javom. Programi prevodioci su upravo takav primjer.
Najpoznatiji JRE/JDK za Javu izrađeni su od strane IBM-a i Sun-a. Uglavnom programi pisani i prevedeni prevodiocem jednog JDK rade na drugom i obrnuto. Osobno sam naišao na situacije u kojima programi koji koriste baze podataka neće raditi kada miješamo JDK s kojim prevodimo i JDK s kojim pokrećemo program. U tim se situacijama preporuča korištenje istog JDK za prevođenje i pokretanje programa.
Kada govorimo o tehnologiji virtualnih strojeva, odmah nam pada na pamet tehnologija interpretera, što i nije daleko od istine. Rane verzije Jave koristile su upravo takav pristup. Java bytecode interpretiran je od strane virtualnog stroja i na taj način izvršavan. Naravno, takav pristup je prilično spor i od samog početka Java je slovila kao spora. Novije verzije virtualnih strojeva (1.4 i 1.5) uglavnom imaju u sebe ugrađen JIT (Just In Time compiler). Program prevodioc omogućava just-in-time prevođenje na izvršni kod na nivou funkcije ili klase. Ovakvi just-in-time prevodioci omogućavaju brže izvođenje Java programa.
Gdje do JDK?
http://www-128.ibm.com/developerworks/java/jdk/
http://developers.sun.com/resources/downloads.html
|
- 20:25 -
Komentari (0) -
Isprintaj -
#
Revival
U zadnje vrijeme mi se često događa da moram objašnjavati nešto ljudima vezano uz tehniku i programiranje. Dapače, uvijek sam bio otvoren prema drugima i uvijek spreman pomoći onima koji su to željeli.
Tako se rodila ideja o nastavku ovog tehno bloga. Želja mi je malo oživiti ovaj blog i pisati o aktualnim temama, o tehnologiji i eventualno na taj način nekome i pomoći. Ako ste ljubitelj tehnologije, računala, programer, tada će ovaj blog biti dobro mjesto za vas. Barem ću se potruditi da to bude.
Naravno, blog će ostati na default predlošku, budući da nemam vremena, kao niti želje raditi vlastiti dizajn bloga. Osim toga, smatram da je puno važniji sadržaj bloga, a ne njegov izgled. A ovim sam predloškom sasvim zadovoljan. Pa krenimo.
|
- 10:02 -
Komentari (0) -
Isprintaj -
#
01.08.2004., nedjelja
Da gospodine naredniče, na zapovijed!
Eto, svi se "veselimo" pameti naše države. Ukoliko se vlast može usporediti s državom. Već prošle godine je donesen Zakon o znanstvenoj djelatnosti i visokom školsku. Pred kojih par dana donesene su njegove dopune i izmjene. Novi Zakon bi prema riječima ljudi iz Vlade donijeti red u korištenje akademskih titula, te usklađivanje istih s Europom.
Sve je to divno i krasno ako u ovom trenutku zanemarimo prošlost. U toj su se prošlosti na ovim našim krajevima, ako se koncentriramo na tehnička zanimanja, pojavljivala četiri različita akademska stupnja: ing. (s završenom višom školom, odn. vrlo često u trajanju od 5 semestara), dipl.ing. (s završenim fakultetom iliti 8 do 9 semestara), mr.sc. (s završenim poslijediplomskim studijem u trajanju od 3 semestra), te dr.sc. (s završenim poslijediplomskim studijem u trajanju od 6 semestara).
Novi Zakon predviđa samo tri stupnja s ponešto drukčijim nazivima. Stupnjevi su podijeljeni prema osvojenim ECTS bodovima, što se može povezati s trajanjem studija: prvostupnik (baccalaureus, s skupljenih 180 do 240 ECTS bodova, koji se ujedno može usporediti s ing.), mag. struke (s skupljenih 300 ECTS bodova, koji se ujedno može usporediti s dipl.ing.) i dr.sc. (s završenim poslijediplomskim studijem).
Na prvi pogled se vidi da se dosadašnji mr.sc. više nigdje ne spominje. No, pravo pitanje se postavlja: Što to znači za sve one koji su fakultet završili i imaju određenu akademsku titulu?? Odgovor na ovo pitanje je vrlo nejasan i zasad nema nikakvih objašnjenja osim tumačenja pravnika. Tumačenje pravnika ide u ovom smjeru: Novi Zakon se odnosi samo na osobe koje će svoju akademsku titulu primiti nakon donošenja Zakona, dok svi ostali svoje titule pišu kao i dosad, odnosno točno onako kako piše na diplomi.
Što će se dogoditi kad nakon par godina izađu prvi magistri struke... Zamislite konkuriranje dipl.ing. i mag. struke kod poslodavca za isto radno mjesto. Ne prate svi poslodavci sva događanja u javnosti i sve Zakone koji su u međuvremenu izašli. Mislite da će dipl.ing. uspjeti poslodavcu objasniti da ima završen isti stupanj kao i ovaj mag. struke? Mislite li da možda poslodavac usprkos tome neće zaposlit magistra samo zbog naziva titule? Na kraju svega, da li se neće događati da poslodavci razmišljati kako se uz titulu značajnije promijenio i studij za ove magistre struke!?
Kako će se to odraziti na magistre znanosti s završenim poslijediplomskim? Pa magistar je magistar u krajnjem slučaju.
Mišljenja sam da će to izazvati veliki kaos kod akademski obrazovanih građana. Ceh će platiti svi oni koji imaju zastarjelu titulu, a posebno dosadašnji magistri znanosti čiji će poslijediplomski studij istog trenutka završiti u košu za smeće. Pametni potezi vlasti? Deja vu?
|
- 17:48 -
Komentari (2) -
Isprintaj -
#
27.07.2004., utorak
Novi alati, stari problemi
Sve je počelo davno. Prijatelj mi je predstavio tadašnji pravi vizualni alat za programiranje. Na Microsoft Windows 95 operativnom sustavu, Microsoft Visual Basic (sada se više niti se sjećam verzije alata). Pa kasnije i Borland Delphi 3.0! Uskoro se tu našao i Microsoft Visual C++ 6.0! Sve izvrsni alati s kojim si mogao raditi čuda. Pa ipak, svi su oni imali neke svoje "muhice". Tu i tamo bi se alat srušio, pa bi nestala kakva datotekica, pa thread deadlock i slične stvarčice. Općenito je programiranje pojavom vizualnih alata pošlo nekim boljim stazama, no to nikako ne treba shvatiti kao veličanje tih alata jer je s njima došla i nova agonija - problem stabilnosti alata.
Danas već s nostalgijom govorim o tim sitnim bugovima prvih vizualnih alata jer ih noviji i moderniji i sve natrpaniji alati za razvoj programa kose u svim pogledima. Kako u broju opcija koje donose sobom, tako i u broju problema i patcheva, fix packova i sličnih raznih zakrpica problematičnih i sve bugovitijih razvojnih alata.
I tako već polako dolazimo do onog momenta kada naši razvojni alati postaju toliko veliki i nestabilni da nešto što je radilo u prošloj verziji, u novoj verziji može srušiti operativni sustav i resetirati računalo.
Odabir razvojnog alata danas postaje prava noćna mora svakog poduzeća u IT industriji. To je posebno izraženo u trenutku kad nije moguć oslonac na jednu stabilnu verziju. Osim tog teškog izbora, postavlja se i pitanje isplativosti. Jedan pravi razvojni alat danas dođe par tisuća eura. Zamislite da kupite alat od par tisuća eura, a tamo vam ne radi jedan od osnovnih dizajnera. Žalite se, a nitko vas ne sluša. Platite godišnje održavanje, dobijete novu verziju u kojoj isto tako taj isti dizajner ne radi. Nakon dvije godine vam kažu da više ne možete dobiti novu verziju alata na račun godišnjih održavanja, te da morate platiti nadogradnju, a dizajner još uvijek ne radi i vi pišete dotične skripte u običnom notepadu.
|
- 19:32 -
Komentari (0) -
Isprintaj -
#
11.05.2004., utorak
Parkiralište na kraju galaksije
Gledam na TV-u, problemi s prometom u glavnom gradu. Gužva se uvukla u svaki dio države. Pa tako i u naš grad. Parkiranje me izluđuje. Voziš se parkiralištem, kružiš ko lešinar oko umirućeg, u nadi da će se netko maknuti pa da se ubaciš.
A onda u navali, u izmjeni smjena obližnje tvornice krkljanac. Linije parkirališta više ne znače ništa. Ljudi psuju, trube. Na parkiralištu za 1000 automobila parkirano barem 1500 automobila.
Izlaziš, vrtiš ključeve automobila, a ono...tvoj automobil zagrađen. Gledaš, mjeriš, ali nema šanse da se izvučeš!! Što sad? Bušit gume? Pozvat ekipu iz lokalne krčme da za gajbu pive dignu i maknu jedan od automobila?
|
- 19:55 -
Komentari (2) -
Isprintaj -
#
Neiskusni WEB dizajneri
- 09:49 -
Komentari (0) -
Isprintaj -
#
|