Veliki broj klijenata prepoznaje CROZ kao tvrtku koja se bavi pružanjem usluga razvoja softvera baziranog na Spring frameworku. Pri tome Spring framework često koristimo u kombinaciji s IBM Rational Software Architect ili Rational Application Developer alatima. Kako bi omogućio developerima ugodniji i produktivniji razvoj aplikacija baziranih na Spring frameworku SpringSource nudi vrlo koristan dodatak za Eclipse IDE - SpringIDE. Nažalost, SpringSource službeno ne podržava SpringIDE unutar IBM RSA/RAD okruženja, a zbog promjena u kodu već nekoliko verzija (otprilike zadnjih godinu dana) SpringIDE ne radi unutar IBM RAD/RSA razvojnog okruženja.
U CROZ-u smo to prepoznali kao jedan od problema koji muči naše developere, kao i developere naših klijenata, te smo odlučili istražiti postoji li rješenje. Kao rezultat našeg istraživanja predstavljamo vam modificiranu inačicu SpringIDE 2.5.x koja je za potrebe naših developera prilagođena radu na IBM RSA/RAD 7.5.x platformi.
Komprimirani update site podoban za instalaciju modificirane inačice SpringIDE 2.5.x, kao i xerces repozitorij potreban pri instalaciji možete pronaći na sljedećim linkovima:
IBM je ponudio na download 60 dnevni besplatni trial posebne verzije popularnog WAS-a. WAS Hypervisor Edition je unaprijed konfigurirana i zapakirana inačica „normalnog'' WAS-a 7.0. Instalacija nije potrebna, dovoljno je otpakirati i pokrenuti virtualnu mašinu koristeći VMware ESX ili ESXi server (koji je također moguće besplatno skinuti). Glavna prednost Hypervisor Edition-a je eliminiranje overhead-a instalacije i konfiguriranja. Kroz novo konfiguracijsko sučelje moguće je birati profil virtualne mašine: deployment manager, stand alone server, IHS… Na taj način moguće je brzo izgraditi (ili proširiti) deployment okolinu, popularno zvanu cloud. Trošak operativnog sustava je također eliminiran, Hypervizor dolazi s tuniranim Novel SUSE Linux-om.
HyperVisor Edition je okosnica IBM-ove cloud inicijative, te je aplikacijski server prilagođen CloudBurst uređajima. Ukoliko si ne možete priuštiti uređaj (koji nudi puno veći komfor) zakoračite u cloudcomputing testirajući WAS Hypervisor Edition.
Svako moderno poslovanje, bez obzira na djelatnost, ovisi o ključnim faktorima (critical asset) za obavljanje svakodnevnih poslova, bez obzira radi li se o sredstvima transporta, sredstvima za proizvodnju, računalnoj opremi… Briga o tim sredstvima (engl. asset) je krucijalna, jer imaju izrazit utjecaj na produktivnost i profitabilnost korporacije. Kompanije su uglavnom bile primorane oslanjati se na raznolika softverska rješenja zbog različitih tipova sredstava. Takva rješenja pružala su samo djelomično praćenje u odnosu na sva sredstva kompanije, što je otežavalo prepoznavanje mogućnosti poboljšanja učinka. IBM Maximo® Asset Management (Maximo AM) diže upravljanje imovinom na potpuno novu razinu. Razvijen na jedinstvenoj softverskoj platformi, pruža iscrpan uvid u sve tipove sredstava, proizvodnju, objekte i transport kroz Vašu kompaniju. Ovakav kompletan pregled imovine pruža mogućnost uočavanja neiskorištenih potencijala unutar sredstava.
Upravljanje imovinom se može optimizirati analizom inventara, sredstava, nabave, te analizom i planiranjem rada, a Maximo nudi šest ključnih rješenja za upravljanje: Assets, Work, Services, Contracts, Materials i Procurement. Ova rješenja sa svojim funkcionalnostima u potpunosti pokrivaju sve što je potrebno za optimizaciju i upravljanje sredstvima i pripadajućim servisima. U nastavku ćemo Vam probati približiti neke od glavnih funkcionalnosti kako biste stvorili sliku zašto je upravo Maximo AM cjelovito rješenje za upravljanje imovinom.
Upravljanje sredstvima (Asset Management) je sveobuhvatni sustav koji posjeduje sve potrebne kontrole kako bi s lakoćom pratili upravljanje sredstvima kroz cijeli njihov životni vijek. Detalji o pojedinom sredstvu sadrže lokaciju, povijesno praćenje utrošenog vremena i resursa kroz vrijeme, te se samim time maksimizira produktivnost i produljuje vijek sredstva.
Upravljanje radom (Work Management) podržava planirano i neplanirano djelovanje na održavanju, od inicijalnog zahtjeva preko generiranja radnog naloga, sve do izvršavanja i evidentiranja obavljena posla. Alati za praćenje omogućuju detaljnu analizu utrošenih resursa, materijala i opreme, kako bi se smanjili utrošak materijala i rada.
Upravljanje servisima (Service Management) omogućuje korisniku da unese novi servisni zahtjev (Service Request), te također omogućuje praćenje i ažuriranje postojećih zahtjeva. Sa servisnom podrškom možete implementirati ITIL smjernice za incidente, probleme, change i release management za visoko kvalitetne i cijenom niske Service Desk operacije. Prilikom pružanja usluge može se koristiti SLA (Service Level Agreement) i Performance Monitoring kako bi se uskladili ciljevi i prioriteti na najbolji način podržavajući cjelovite ciljeve poslovanja. Bitna komponenta također je i Email Listener koji služi za generiranje servisnih zahtjeva direktno iz elektronske pošte.
Upravljanje ugovorima (Contract Management) je iscrpan sklop funkcionalnosti koji pruža kompletnu kontrolu nad ugovorima s dobavljačima te podržava nabavu, davanje u najam, unajmljivanje, jamstva, procjenu posla, glavne i korisnički definirane ugovore. Ugovori se s dobavljačima povezuju Service Level Agreementima (SLA) kako bi se lakše identificirali nepouzdani dobavljači i proizvodi nezadovoljavajuće kvalitete.
Upravljanje materijalima (Materials Management) je komponenta Maxima koja zna sve – što, kada, kako, koliko, koliko dragocjeno – o materijalima vezanim za sredstva i njihovoj uporabi. Upravljanje materijalima bilježi sve transakcije pružajući uvid u stanje materijala u realnom vremenu.
Upravljanje nabavom (Procurment Management) podržava sve faze dobavljanja unutar organizacije, uključujući i direktnu kupovinu potrebnih sredstava i nadopunjavanje skladišta. Ove mogućnosti informiraju kupca o zahtjevu, ponudama, dobavljačima, narudžbama i podacima iz ugovora, omogućujući time proaktivno planiranje. Također se ove mogućnosti lako integriraju s proizvodima treće strane kao što su SAP® ili Oracle.
MaximoIT Service Management brine za poslužitelje, mrežnu opremu, prijenosnike, radne stanice, mobilne uređaje, točnije, za sve šireg spektra od računalnih periferija, do softverskih licenci. Maximo Discovery alat, koristeći računalnu mrežu, identificira fizičku lokaciju uređaja i pruža reviziju korištenog softvera.
U današnjem svijetu tvrtke zahtijevaju integraciju više poslovnih sustava unutar tvrtke te integraciju s eksternim sustavima partnera i klijenata. Maximo se lako integrira u većinu postojećih poslovnih sustava. Maximo interoperability framework pruža integraciju infrastrukture baziranu na servisno orijentiranoj arhitekturi (SOA), a ugrađena integracijska komponenta, Maximo Enterprise Adapter, omogućava bržu integraciju s enterprise poslovnim sustavima.
Kroz ovaj post pokušat ću vam približiti programski jezik Groovy. Pa, što je Groovy? Prema definiciji s http://groovy.codehaus.org: Groovy je agilni dinamični jezik za Java platformu u mnogo toga inspiriran jezicima poput Pythona, Ruby i Smalltalka. Napredne opcije tih jezika približene su Java programerima kroz sintaksu jako sličnoj Java sintaksi. Na taj način Java programeri mogu koristiti neke programske konstrukte o kojima se tek priča da će se dodati u Javu, npr. closures. Zašto čekati i ne iskoristiti te napredne funkcionalnosti već danas koristeći Groovy? Nekima, bi zapreka mogla biti činjenica da je Groovy dynamicly typed jezik. Većina grešaka će biti otkrivena tek u runtime-u. Drugi će biti oduševljeni jer se više ne moraju brinuti o tipiziranju varijabli.
Groovy se često naziva i skriptnim jezikom, ali daleko od toga da je dobar samo za pisanje skripti. Ali ako je pisanje skripti vaš ulazak u Groovy svijet, samo naprijed! Za početak neke osnovne informacije o Groovy-u:
skripte/klase se obično nalaze u .groovy datotekama
skripte se mogu interpretirati ili se mogu kompajlirati u Java .class biblioteke
Groovy u većinu poslovnih aplikaciju ne unosi značajnu degradaciju u performansama
iz Groovy-a možemo zvati Java kod (i obrnuto)
većina Java ključnih riječi ima isto značenje i u Groovy-u
redoslijed package, import, class deklaracija je isti kao i u Java-i
Groovy već unaprijed importira pakete groovy.lang.*, groovy.util.*, java.lang.*, java.util.*, java.net.* i java.io.*
u Groovy-u sve je objekt (nema primitivnih tipova)
Groovy ima ugrađenu podršku za kolekcije (def praznaLista = [])
Groovy olakšava rad sa stringovima, datumima, I/U
dolazi s podrškom za rad s JDBC-om, XML-om
Lista dobrih strana bi mogla biti višestruko duža. Za detaljnije upoznavanje preporučam Groovy homepage: http://groovy.codehaus.org. Mogućnosti Groovy-a pokazat ću kratkom skriptom koja će nam dati aktualnu (ili arhivsku) tečajnu listu. Kao izvor koristit ćemo XML datoteku dostupnu na stranicama Erste banke.
def lista = new XmlSlurper().parse(procitajTecajnuIz)
lista.valuta.each(this.&printTecaj)
printSrednjiZaValutu(lista, 'EUR')
Skripta će ispisati:
001 AUD = 4,273200 kn
001 CAD = 4,870200 kn
001 CZK = 0,279000 kn
001 DKK = 1,003300 kn
100 HUF = 2,724900 kn
100 JPY = 5,576900 kn
001 NOK = 0,839700 kn
001 SEK = 0,691300 kn
001 CHF = 4,926700 kn
001 GBP = 8,660800 kn
001 USD = 5,343700 kn
001 BAM = 3,819300 kn
001 EUR = 7,345000 kn
001 PLN = 1,667400 kn
Srednji tečaj za EUR na datum 10.06.2009. iznosi 7,345000 kn.
Nije loše za 15 linija koda. Morate priznati da bi se isto teško moglo postići koristeći Javu. Svi znamo da je svaka linija koda potencijalni izvor bug-a. U konačnici radije bi održavali 15 linija skripte nego 100-tinjak linija Java koda, zar ne?
Kratki opis koda:
def printTecaj(tecaj) {
println "$tecaj.jed $tecaj.opis = $tecaj.t3 kn"
}
Ovdje vidimo primjer tipične definicije metode u Groovy-u. Kao povratni tip stoji ključna riječ „def“ što bi značilo „dynamicly typed“ tj. metoda vraća bilo koji tip. Parametar metode nije potrebno tipizirati pa koristimo samo ime, „tecaj“. U tijelu metode nalazi se samo jedna linija koja će ispisati na konzolu tečaj koristeći tzv. parametrizirani „GString“.
println "Srednji tečaj za $valuta na datum $lista.datum iznosi $zaValutu.t3 kn"
}
U definiciji ove metode je nova klozura (closure) koja se koristi u pretrazi liste tečaja po određenoj valuti. Klozure možemo prepoznati po vitičastim zagradama, a razlikuju se od definicija metoda po tome što nemaju imena i definicije parametara.
Za metodu linkZaTecajnu je posebno to što vidimo da možemo koristiti još jednu funkcionalnost koju Java nema, defaultne vrijednosti parametara metode (def datum = new Date()). Također vidimo da smo stavili def ispred datum, ali nismo trebali, Groovy je jako fleksibilan. Ključnu riječ return nije potrebno pisati. Povratna vrijednost će biti rezultat zadnje izvršene linije u metodi. U ovom slučaju povratna vrijednost je tipa GString.
def lista = new XmlSlurper().parse(procitajTecajnuIz)
lista.valuta.each(this.&printTecaj)
printSrednjiZaValutu(lista, 'EUR')
Pošto smo definirali nekoliko pomoćnih metoda sada nam je lako ispisati tečajnu listu i ispisati srednji tečaj za euro. Tečajnu listu istim kodom možemo pročitati sa interneta ili (već spremljenu) s diska. Parsiranje XML-a radimo jednom linijom koda koristeći XmlSlurper. To je jedna od Groovy klasa koja olakšava rad s XML-om. Pošto smo pročitali XML, sa xml strukturom radimo kao Java/Groovy objektnom strukturom. Iako su ove linije koda jasne mogli bismo se zapitati što znači this.&printTecaj. Konstruktom instanca.& koristimo već definiranu metodu kao klozuru i predajemo je kao parametar metodi each. Veoma zgodno.
Nadam se da Vam se kroz ovih par linija koda Groovy dopao. Malo linija čini čuda, no potrebno je vremena kako bi se steklo iskustvo. Uza sve, Groovy bi nam mogao pomoći da postanemo još bolji programeri u Javi primjenjujući koncepte iz Groovy-a. Također, ne smijemo zanemariti dobrobit potencijalnog oduševljenja mogućnostima Groovya, što će zasigurno dići radni moral i neke podsjetiti na ushićenje kada su prvi put u Pascalu/Basicu uspjeli iscrtati grafiku na ekran :-). Na kraju pozivam Vas da skinete najnoviju verziju s http://groovy.codehaus.org i napišete pokoju zgodnu skriptu ili programčić.
U današnje vrijeme mnoge organizacije svoje poslovne procese povjeravaju WEB orijentiranim softwareima. Upravo iz tog razloga implementacija sigurnosti u web sustave treba biti sastavni dio procesa razvoja i isporuke softwarea, no na nesreću neprestana utrka s konkurencijom zahtijeva uvijek nove funkcionalnosti i usluge, na štetu testiranja, osobito sigurnosnog. Kao rezultat tržišne utrke, aplikacije su ranjive i dozvoljavaju razne načine za krađu kako poslovnih tako i privatnih korisničkih podataka.
IBM Rational AppScan je alat namijenjen automatizaciji sigurnosnog i penetracijskog testiranja WEB aplikacija i servisa. Rješenje kao što je AppScan omogućava organizacijama kontinuirano otkrivanje sigurnosnih rizika u aplikaciji i pravovremeno osiguraju svoju aplikaciju, čime se znatno umanjuju rizici prije isporuke softwarea.
AppScan je već više od godinu dana dio Rational portfelja i trenutno je dostupan u slijedećim verzijama:
IBM Rational AppScan Standard Edition (desktop rješenje)
IBM Rational AppScan Express Edition (desktop rješenje namijenjena manjim organizacijama)
IBM Rational AppScan Enterprise Edition (web orijentirano rješenje namijenjeno velikom broju paralelnih korisnika)
IBM Rational AppScan Tester Edition (integracija za Mercury testne alate)
IBM Rational AppScan Build Edition (rješenje za implementaciju security testiranja u vaš build proces)
IBM Rational AppScan Developer Edition (rješenje za integraciju u Eclipse namijenjeno programerima koji nisu stručnjaci za security testiranje)
Svaki od ponuđenih alata omogućava odabir testova koje ćete izvršavati, skeniranje sustava i pronalaženje potencijalnih sigurnosnih rizika i ranjivosti, testiranje, analizu dobivenih rezultata te detaljno izvještavanje o izvršenim testovima. AppScan sa svojim mogućnostima namijenjen je gotovo svim članovima razvojnog tima, od programera preko testnih timova, penetracijskih testera, ljudi zaduženih za kontrolu sigurnosti u sustavima pa do senior managera.
Miroslav Zaninović
Ponedjeljak, 17. studenog 2008.
Rational Team Concert je prvi produkt razvijen na Jazz tehnološkoj platformi. Predstavlja timski kolaboracijski alat razvijen na skalabilnoj i proširivoj platformi koja olakšava razmjenu informacija između članova razvojnih timova. Rational Team Concert implementira i međusobno integrira sve komponente potrebne za brži i kvalitetan razvoj vašeg softwarea:
Mogućnost implementacije vlastitog razvojnog procesa
Kreiranje vlastitog razvojnog tima
Sustav za prijavu i praćenje bugova, taskova i zahtjeva (Work Item)
Sustav za verzioniranje softwarea (Source Control)
Planiranje projekta i razvojnih iteracija
Build sustav
Reporting i Web Dashboard
Out-of-the-box integraciju i sinkronizaciju s nizom drugih alata
Rational Team Concert je dostupan u tri verzije:
Timski razvoj softwarea u mnogo čemu sliči sviranju instrumenta u orkestru. Svatko je koncentriran na svoj instrument i svoju ulogu u orkestru, no ujedno mora biti sinkroniziran s cijelim orkestrom. Za razvoj kvalitetnog softwarea nije dovoljno koncentrirati se samo na kvalitetan kôd, već je nužno koordinirati i razumjeti sve aktivnosti tima kako bi se sve komponente razvoja uklopile u jedinstvenu cjelinu. Nužno je pronaći ravnotežu timske suradnje i improvizacije, no zašto biste se vi time zamarali kad Rational Team Concert to može učiniti za vas.
Rational Requirements Composer je alat namijenjen upravljanju i definiranju zahtjeva koji će svojim novitetima znatno unaprijediti proces praćenja zahtjeva.
Rational Quality Management je web orijentiran alat namijenjen test managementu. Alat pruža kolaborativno i prilagodljivo okruženje za planiranje, kreiranje, izvršavanje testova, te praćenje rezultata izvršavanja.
Miroslav Zaninović
Ponedjeljak, 17. studenog 2008.
Servisi u servisno orijentiranoj arhitekturi se najčešće implementiraju koristeći web servise. Jedna od dobrih strana web servisa je neovisnost o komunikacijskom protokolu. S mogućnošću izbora dolazimo do problema, koji protokol je pravi? Jedan od nefunkcionalnih zahtjeva može biti vrijeme odziva servisa. Usporedili smo 2 najpopularnija protokola SOAP/HTTP i SOAP/JMS. Kompletan test možete pročitati na:
Uz nove verzije marketinški stručnjaci odlučili su nadodati sufiks „for WebSphere“ kako bi naglasili primarnu namjenu alata, razvoj aplikacija za WebSphere platformu. Najvažnije novosti koje donose ovi alati su:
JEE5 – podržava razvoj po cijeloj specifikaciji uključujući JPA i EJB 3.0
vizualna podrška razvoju Web 2.0 aplikacija koristeći AJAX i Dojo
Eclipse 3.4
RSAWS 7.5 dodatno donosi mogućnost kreiranja vlastitog domain specific modeling language-a kojim se može vizualno na jedinstveni način predstaviti poslovni problem.
WAS 7.0
Uz alate za razvoj novost je i WebSphere Application Server v7.0. Od ove verzije WAS je kontejner za aplikacija pisane po JEE5 specifikaciji (EJB 3.0, JPA,..) kao i za J2EE 1.4 (i starije) aplikacije (EJB2.x,..) . Više o WAS-u 7.0 na http://www-01.ibm.com/software/webservers/appserv/was/.
Prema dostupnim informacijama WAS 7.0 će se temeljiti na kodnoj bazi WAS-a 6.1 i feature pack-ovima za EJB3 i web servise (WSFP). Već dostupnu podršku za dijelove JEE5 u WAS-u 6.1, sedmica će nadograditi u ostalim područjima kako bi bio kompatibilan sa JEE5 specifikacijom.
Posljednjeg radnog dana prije Božića (nadam se da ne morate raditi na Badnjak) 21.12.2007., IBM WebSphere odjel je izdao verzije 6.1 svojih produkata namijenjenim Business Process Management-u. Ovim velikim release-om WebSphere nudi nove verzije produkata sa podrškom za sva 4 koraka (Model, Assemble, Deploy i Manage) u SOA razvoju. Razvojni alati su temeljeni na Rational Application Developer (RAD) v7 za razliku od verzija 6.0.x koji su bili proširenja RAD-a v6.
Model - WebSphere Business Modeler v6.1 (WBM)
Za fazu modeliranja novi WBM v6.1 kao najveću novost donosi poboljšanu integraciju sa ostalim IBM BPM alatima, poglavito sa WebSphere Integation Developer-om. Bolja integracija nam omogućuje lakše praćenje promjena nad artefakata koje razmjenjujemo među alatima. Uz pregršt ostalih novosti vrijedi izdvojiti i podršku za human task-ove. Kompletan popis novosti možete vidjeti ovdje.
Novi WID v6.1 uz bolju integraciju sa WBM-om v6.1 trebao bi nas oduševiti kraćim vremenom build-anja i manjim memorijskim zahtjevima. Podška human workflow-ova je također poboljšana pa sada imamo na raspolaganju novi wizard za generiranje portlet-a. Kompletan popis novosti možete vidjeti ovdje.
Deploy – WebSphere Process Server v6.1 (WPS)
Za izvršnu okolinu imamo na raspolaganju WPS v6.1 koji je sada temeljen na WebSphere Application Server-u v6.1, a to znači da možemo koristiti noviju Javu 5. Novih funkcionalnosti je dosta, najvažnija su poboljšanja human workflow-a i bolja integracija sa WebSphere Portal-om kao i JMS sučelje prema Business Flow Manager-u. Kompletan popis novosti možete vidjeti ovdje.
Manage - WebSphere Business Monitor v6.1 (WBM)
Za praćenje poslovnog procesa u izvršnoj okolini na raspolaganju nam je WBM v6.1. U novoj verziji ga je još lakše instalirati i poboljšane dokumentacije. Korisničko sučelje je potpuno novo sa Web 2.0 tehnologijom i podrškom za drag-and-drop realizirano AJAX tehnologijom. Kompletan popis novosti možete vidjeti ovdje.
Prije 2 tjedna, točnije 30.11., IBM je ponudio na skidanje novu beta-u alata za razvoj Java aplikacija, Rational Application Developer (RAD) 7.5. Iza brojke 7.5 krije se više novosti nego što bi se očekivalo od poluverzije. Najvažnija je podrška za JEE5. Upućenima sigurno izmamljuje osmijeh na lice. Svi znamo da J2EE 1.4 okolina programerima nije bila po volji ponajviše zbog nespretnog EJB razvoja.
Sa RAD-om 7.5 konačno imamo na raspolaganju JEE tehnologije kao što su EJB 3.0 i JPA. Također podržava najnovije web development standarde: JSF 1.2, JSP 2.1 i Servlet 2.5. Ako koristimo web servise važna će nam biti podrška za JAX-WS 2.0/JAX-B 2.0, WS-Policy Assertions for Web Services, WS-Reliable Messaging, WS-Addressing, MTOM, SOAP 1.2, WS-Secure Conversation i SIP (JSR 289).
CROZ kroz program edukacije stoji na raspolaganju za lakši prijelaz na novije standarde. RAD 7.5 beta je nastala na solidnim temeljima RAD-a 7 i Eclipse Europa-e (Eclipse v3.3) pa je već i u ovoj prvoj beta-i dovoljno stabilna za ozbiljniju evaluaciju. RAD 7.5 beta možete skinuti na IBM® Rational® Application Developer for WebSphere® v7.5 Open Beta stranici.
IBM je donedavno bio dosta konzervativan u pogledu izdavanja novih verzija Jave. WAS 6.0 dolazi s Javom 1.4.2, a Java 5 se već naveliko koristila! Stvari se mijenjaju, čini se, WAS 6.1 podržava Javu 5, a upravo je postala dostupna i Java 6 Early Release program. Za očekivati je "feature pack" za WAS 6.1 koji će podržavati i Javu 6.
U osnovi, Lotus Symphony je Eclipse RCP aplikacija koja je uspješno integrirala OpenOffice komponentu. Za prvu beta verziju je dovoljno stabilno, no svakako treba poraditi na brzini.
InfoWorld piše kako IBM ulazi u (još jednu) borbu protiv MicroSofta, ovaj put na području uredskih alata. Kako piše u vijesti, IBM je "donirao" 35 developera OpenOffice.org zajednici, a kao rezultat njihovog rada će se roditi Lotus Symphony, u osnovi prepakirani OpenOffice.org. IBM već ima iskustva u ovakvim pothvatima (Eclipse) tako da ovakav potez ne iznenađuje.
Drugo je pitanje kako će ovo utjecati na MicroSoft i njihov MS Office, ako uopće.
Kao korisnik Linuxa, redovito koristim i OpenOffice u svakodnevnom radu i nemam problema s izmjenom .doc, .ppt i ostalih fajlova s kolegama i poslovnim partnerima. To samo znači da je OpenOffice dovoljno kvalitetan komad softvera za svakodnevnu upotrebu, pa bi i Lotus Symphony trebao biti takav. Porade li IBM-ovci na brzini samog OpenOffice alata, cijela open source zajednica će im biti u najmanju ruku zahvalna, no bojim se da će njihovi napori i ostati na toj razini. No vrijedi pričekati i vidjeti, Lotus Symphony - bar na temelju marketinškog letka - itekako obećava.
Iako postoje i drugi načini konfiguriranja Springa, XML format je daleko najpopularniji i najprihvaćeniji, te je prava rijetkost susresti nešto drugo. U verziji Springa 2.0 (čija je finalna verzija izdana u listopadu 2006.) su zbog toga uvedena brojna poboljšanja koja bi trebala konfiguriranje aplikacija baziranih na Springu učiniti bržim, jednostavnijim i fleksibilnijim.
Novost - Springove XML Scheme
U dosadašnjim verzijama Springa, XML konfiguracijske datoteke su tipično započinjale sljedećim odsječkom:
Time je definiran DTD (Documet Type Definition) koji, između ostaloga, propisuje način na koji se zapisuju podaci o bean-ovima. Sami zapisi za bean-ove su generički, otvori se <bean> tag, kao atributi mu se definiraju id i naziv klase, a onda se unutar njega, za pojedina polja vrijednosti definiraju kombiniranjem npr. <property>, <ref> i <value> tagova (ili value atributa). Ovo pravilo vrijedi za sve bean-ove, bilo da se radi o Springovim klasama, o klasama koje ste dobili kao dio nekog API-ja ili ste ih sami napisali. Ovakva generičnost je s jedne strane prednost jer je jasno kako mora izgledati Spring konfiguracija bilo koje Java klase, no također je i ograničenje koje često rezultira prilično dugim i teško preglednim konfiguracijskim datotekama.
DTD definicije nisu ukinute u novoj verziji Springa, te su i dalje ispravan način konfiguriranja. Štoviše, Spring 2.0 u svojoj distribuciji uz stari DTD donosi i novi http://www.springframework.org/dtd/spring-beans-2.0.dtd u kojem se nalaze neke konfiguracijske novosti na koje se nećemo posebno osvrtati u ovom članku (npr., nova područja vrijednosti bean-ova - scope).
Kako prelazak na XML Schema konfiguracije ne znači da morate primijeniti Spring 2.0 konfiguracijske novosti (definicije bean-ova i dalje mogu biti identične kao u Spring 1.x, samo se zaglavlje XML konfiguracije mijenja), a ipak se omogućava njihovo korištenje, DTD zaglavlja ćemo vjerojatno viđati sve manje u aplikacijama baziranim na Spring 2.0.
Jedan tipičan odsječak konfiguracijskog koda koji se do sada susretao bi nalikovao na sljedeći ispis:
Ovo, naravno, nije pravi primjer koji bi pokazao sva ograničenja konfiguracije bazirane na DTD-u, no i ovdje je moguće uočiti ograničenja:
Za dohvat JNDI resursa (bean bankDS) se koristi Springova klasa koja se bavi samo time. Sam naziv klase nam je pomalo nerazumljiv i nebitan te bi zapravo bilo bolje kad bi se na neki drugi (jednostavniji) način moglo naznačiti da želimo dohvatiti JNDI resurs.
Različite klase se sastoje od različitih property-ja, a ipak se svi definiraju na identičan način, pomoću kombinacije tagova <property>, <ref>, <value>, <list>...
Potrebno je znati kako se u Java klasama zovu pojedini property-ji koje želimo popuniti, pri čemu je vrlo lagano napraviti pogrešku u pisanju njihovih naziva. Pojedini alati mogu biti od pomoći, no oni nisu raspoloživi za sve razvojne okoline s kojima se možete susresti (npr. Spring IDE koji prilikom pisanja konfiguracije prikazuje nazive članskih varijabli odabrane klase je skup pluginova koji se integriraju samo u Eclipse, pri čemu Eclipse mora biti verzije 3.1 ili noviji)
Da bismo otkrili koje članske varijable su obavezne, a koje opcionalne, morali bismo pregledati javadoc komentare same klase.
Razni razvojni alati su ograničeni u mogućnosti pružanju podrške prilikom pisanja XML konfiguracija zbog manjka informacija o samim bean-ovima
Kako bismo počeli koristiti Spring 2.0 novosti, prvo moramo promijeniti zaglavlje naše konfiguracijske datoteke na način da zamijenimo spomenutu DTD definiciju XML Schemom. Osnovna XML Schema donosi pravila za pisanje uobičajenih bean-ova (npr. za klase koje smo sami napisali):
Naše bean-ove možemo i dalje pisati na način na koji smo to radili do sada, te je ovakvo zaglavlje po značenju ekvivalentno značenju zaglavlja iz ispisa 1. No, ovako možemo uključiti i još poneku XML Schemu koje će nam pomoći kod korištenja Springovih klasa u našoj konfiguraciji. Npr., ako bismo htjeli na novi način dohvaćati JNDI resurse, uključili bismo jee XML Schemu, kao u sljedećem primjeru zaglavlja (podebljanim slovima su označene izmjene u odnosu na ispis 3):
Osim jednostavnosti samog zapisa, razvojni alati mogu automatski provjeriti da li je naš zapis za navedeni bean ispravan prema jee XML Schemi. Sama jee XML Schema definira da takvi bean-ovi obavezno moraju imati navedenu vrijednost za atribut jndi-name, pa će nam već pri pisanju konfiguracije od strane razvojnog alata biti naznačeno da smo napravili grešku ako smo ga izostavili. Osim toga, razvojni alati će često ponuditi sve moguće atribute, kao i vrijednosti koje im je moguće dodijeliti.
Osim JNDI resursa, novi način konfiguriranja će olakšati definiranje AOP bean-ova ili npr. transakcijskog konteksta. Ne ulazeći u detalje (uočite npr. nedostatak definicije bean-a txManager koji ovisi o resursima nad kojima definiramo transakciju), ako bismo htjeli postaviti transakcijski timeout na neki naš servis, napisali bismo sljedeći odsječak konfiguracije :
Predefinirani namespace-i
Spring 2.0 donosi 6 predefiniranih namespace-a raspoloživih za korištenje, uz obećanje da će novije verzije Springa postupno dodavati nove kako bi se olakšalo konfiguriranje u verziji 2.0 zapostavljenih područja (npr. Spring MVC klasa):
tx – olakšava definiranje transakcija
aop – pojednostavljuje AOP konfiguracije
jee – donosi podršku za definiranje JNDI resursa, EJB-ova i slično
lang – za rad s objektima definiranim u dinamičkim jezicima, poput Groovy ili JRuby
util – za svakodnevne zadatke, najviše vezano za učitavanje java.util.Properties objekata
<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<!— set timeout to 120 seconds on all methods -->
<tx:method name="*" timeout="120"/>
</tx:attributes>
</tx:advice>
<aop:config>
<aop:pointcut id="allMethods" expression="execution(*
net.croz.fyi.spring.BankService.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="allMethods"/>
</aop:config>
Namespace p
Definiranje vlastite XML Scheme nije potpuno jednostavno te iziskuje određeni napor. Također, za brojne već postojeće biblioteke klasa XML Schema dokumenti još ne postoje. Srećom, Spring 2.0 donosi poseban namespace koji možemo upotrijebiti na bilo kojem bean-u. Na taj način dobijamo pojednostavljenje konfiguracije i za situacije kad XML Schema ne postoji.
Namespace p omogućava definiranje vrijednosti property-ja klase kroz atribute taga <bean>, bez potrebe za kombiniranje brojnih XML elemenata koje smo do sada morali koristiti. Npr. neki property naziva color kojem bismo željeli pridijeliti vrijednost green bi se definirao atributom p:color="green".
Vlastite XML Scheme
Kako ćete razvijati svoje biblioteke klasa, možda ćete poželjeti na sličan način dodati podršku za svoje bean-ove. Spring vam to omogućuje, a sam zadatak se sastoji od 3 koraka:
Definiranje svojeg XML Schema dokumenta koji opisuje vaše bean-ove
Implementiranje sučelja NamespaceHandler iz paketa org.springframework.beans.factory.xml kojim definirate način generiranja objekata na temelju vaše scheme
Mijenjanje datoteke spring.handlers na način da registrirate vašu NamespaceHandler klasu. Na taj način biste Spring „naučili“ kako mora obrađivati bean-ove koji su definirani preko vaše scheme
Možda se pitate kako bi se onda definirao property koji pokazuje na objekt? Jednostavno, na naziv property-ja biste dodali sufiks -ref, a vrijednost koju mu pridijelite predstavlja id bean-a u Spring konfiguraciji.
Kako se namespace p ne provjerava, morat ćete biti oprezni prilikom pisanja naziva atributa, a niti razvojni alati vam za sada neće biti od velike pomoći, no osnovna namjena ovog namespace-a je ionako samo pojednostavljenje konfiguracije.
Sad bismo mogli pogledati kako bi u konačnici korištenjem Spring 2.0 konfiguracijskih novosti izgledala potpuna konfiguracijska datoteka s početka članka (ispisi 1 i 2). Podebljanim slovima je označen dio kojim smo uključili namespace p u našu konfiguraciju:
Jedan od projekata na kojima sudjeluje CROZ posvećen je izradi aplikacije s bogatim klijentom (Rich Client Application). Kao platforma za izradu klijentske strane odabran je Eclipse Rich Client Platform (Eclipse RCP) čija je ključna karakteristika da omogućuje XML-ovsku konfiguraciju korisničkog sučelja. Platforma automatski upravlja različitim vizualnim elementima kao što su izbornici, vrpce s alatima, okviri za pregled (View) ili uređivanje (Editor) itd. Korisnik platforme (tj. razvijatelj aplikacije) mora se brinuti samo o ključnom poslu koji obavlja neki element – npr. o akciji koju treba obaviti na odabir stavke u izborniku ili o sadržaju okvira za pregled. O svemu ostalome brine se platforma – npr. za okvir, njegovo pozicioniranje i veličina, otvaranje/zatvaranje, minimiziranje/maksimiziranje, docking, stacking itd. Razvoj je time znatno ubrzan, a i puno je lakše održavati konzistentan izgled aplikacije. U XML-ovskoj konfiguraciji korisničkog sučelja tipično se navodi ime klase koja brine o pojedinom vizualnom elementu. Tipičan izgled konfiguracijskog elementa:
Osnovni način rada jest da platforma upravlja instanciranjem tih klasa i konfiguriranjem instanci pa korisnik putem XML-ovske konfiguracije ima utjecaj samo na one aspekte klase koji proizlaze iz njezine uloge kao vizualnog elementa kojim barata Eclipse RCP. Na primjer, tipično je da će klasa za pregledni okvir imati ovisnosti o nekim izvorima podataka koje treba vizualizirati. Za sve takve stvari autor klase prepušten je vlastitim rješenjima. S druge strane, CROZ već ima tradiciju korištenja Springovog IoC-a za konfiguraciju objekata, tako da se prirodno nametnula potreba za rješenjem koje će omogućiti da se upravljanje instanciranjem i konfiguracijom objekata preseli s Eclipse RCP-a na Springov IoC kontejner. Na svu sreću, Eclipse RCP barata koncepcijom Factory Object – ako je u XML-u navedeno ime klase koja implementira odgovarajuće Factory sučelje, RCP će instancirati tu klasu i zatim toj instanci prepustiti kreiranje konačnog objekta koji upravlja vizualnim elementom.
Još jedna značajna karakteristika platforme Eclipse RCP jest da omogućuje modularnost aplikacije iznad razine koju nudi sam jezik Java. Ustvari, upravo ta modularnost bila je glavna motivacija za uvođenje XML-ovske konfiguracije. Osnovni pristup je sljedeći: sam RCP sastoji se od skupa modula (Eclipseov termin za „modul“ je „plugin“ pa ćemo ga nadalje koristiti) od kojih je npr. jedan posvećen upravljanju vizualnim elementima. On deklarira točke proširenja ( extension point) za svaku vrstu elementa, npr. točka views za pregledne okvire. Plugin koji razvija korisnik platforme definira svoje proširenje za tu točku time što u XML-ovskoj konfiguraciji navede ime svoje klase i druge parametre koji se tiču prikaza okvira. Samim dodavanjem svojeg plugina skupu pluginova koji sačinjavaju aplikaciju postižemo da on aplikaciji doprinese svoje vizualne elemente, bez pisanja upravljačkog koda u Javi.
Zahtjev za modularnošću aplikacije odražava se i na Springovu konfiguraciju. Jasno je da se ne može centralizirano izgraditi cijeli aplikacijski kontekst jer bi to značilo da neki „glavni“ plugin unaprijed mora znati za sve ostale plugine i konfigurirati njihove objekte. Dakle, svaki plugin mora imati svoj vlastiti kontekst, a poželjno je i da se taj kontekst može nadovezati na neki zajednički, globalno definiran kontekst koji sadrži objekte od šireg značenja za cijelu aplikaciju.
Na Webu smo pronašli open-source projekt [1] (zvat ćemo ga ESpring) koji omogućuje rješavanje ovih pitanja na prilično elegantan način. Dotični projekt ostao je u prilično rudimentarnom stanju i više predstavlja proof-of-concept nego konačan proizvod, tako da smo ga u priličnoj mjeri doradili i debagirali, ali ključne ideje su ostale.
Projekt se sastoji od jednog plugina koji deklarira svoju točku proširenja. Aplikacijski pluginovi vežu svoja proširenja na tu točku tako da doprinesu svoj aplikacijski kontekst centralnom registru kontekstâ. Kontekst se u registar upisuje pod ID-jem definiranim u proširenju. Pri izgradnji svojeg aplikacijskog konteksta plugin može od ESpringa po ID-ju zatražiti proizvoljan drugi aplikacijski kontekst da ga iskoristi kao svojeg roditelja. Primjer definicije proširenja za ESpring:
Svi registrirani konteksti dostupni su na svakom mjestu u Eclipseovoj konfiguracijskoj datoteci plugin.xml, gdje se uobičajeno navodi ime klase vizualnog elementa. Umjesto imena klase objekta koji želimo, navedemo ime posebne klase iz plugina ESpring koja implementira Factory sučelje i koja će platformi dostaviti objekt konfiguriran u aplikacijskom kontekstu:
Ovdje ulazi u igru još jedna važna mogućnost Eclipse RCP-a bez koje ovaj pristup ne bi mogao zaživjeti: nakon imena Factory-klase možemo nadovezati dvotočku i iza nje string koji će biti proslijeđen instanci te klase. Na taj način možemo prenijeti ključne podatke potrebne Factoryju da locira odgovarajući aplikacijski kontekst i objekt unutar njega.
Pažljivom analizom arhitekture opisanog rješenja moglo bi se prigovoriti da je kreiranje aplikacijskog konteksta nepotrebno zakomplicirano: nije dovoljno navesti samo lokaciju konfiguracijske datoteke, već je potrebno kreirati klasu ApplicationContextContributor koja sama obavlja kreiranje aplikacijskog konteksta. Razlog ovome jest ranije natuknuta modularnost RCP-ovih pluginova „iznad razine koju nudi sam jezik Java“: naime, jedan plugin vidi samo one klase drugog plugina koje je on eksplicitno deklarirao „javnim“. Stoga je nužno da kreiranje aplikacijskog konteksta odradi klasa u klijentskom pluginu.
[1] Neil Bartlett, projekt „Eclipse RCP Spring Support“, http://sourceforge.net/projects/eclipse-spring
