Kako pomiriti potrebu programerâ da softversko rješenje razvijaju koristeći novije tehnologije i potrebu sistemskog sektora za čuvanjem verzije aplikativnog servera? IBM ima rješenje: WebSphere Application Server Feature Packs. Feature packs, u slobodnom prijevodu modernizacijski paketi, produžuju životni vijek verzije aplikativnog servera donoseći prijeko potrebna tehnološka osvježenja. Primjer je WAS 6.1, koji je i nakon 4 godine u mnogim tvrtkama aktualna verzija. U softverskom je svijetu to jako dugo razdoblje, a ne bi bilo moguće bez modernizacije kroz feature packove. U međuvremenu je i aktualna verzija 7.0 dobila nekoliko zanimljivih paketa modernizacije. U protekle dvije godine, otkako je sedmica izašla, dogodilo se podosta toga. U prvom je redu dovršena nekolicina standarda koji, svaki na svoj način, olakšavaju razvoj i predstavljaju najbolje programske prakse. Standardi koje izdvajamo jesu: OSGi Service Platform Enterprise Specification Release 4 version 4.2, JPA 2.0 i XML standardi XSLT 2.0, XPath 2.0 i XQuery 1.0. Podrška za sve nabrojeno dostupno je kroz dva paketa modernizacije koje predstavljamo u nastavku.
Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0
OSGI
Većina današnjih softverskih rješenja uglavnom koristi nekolicinu biblioteka u svrhu ispunjenja poslovnih zahtjeva. Takav način implementacije spada među dobre prakse (ne otkriva se topla voda), ali donosi i nove izazove. Biblioteke trećih strana pakiraju se zajedno s razvijenim izvršnim kodom u arhivu koja se šalje na deployment. Kako, u općenitom slučaju, imamo više kopija istih biblioteka, to rezultira neoptimalnim korištenjem resursa aplikativnog servera. Duplikati zauzimaju (skupu) radnu memoriju i diskovni prostor. Kako bismo riješili taj problem, dvije aplikacije možemo deployati kao tri odvojena modula; kao dva modula s izvršnim kodom i treći sa zajedničkim bibliotekama. To je, pojednostavljeno, konceptualna ideja OSGI specifikacije. Pojavljuje se i razlika u terminologiji pa u OSGI okruženju module nazivamo bundleovima. Bundleovi opisuju međuovisnost kroz pakete koje potražuju i koje nude OSGI okruženju. Na taj način naše dvije aplikacije instaliramo kao tri bundlea, a otkrivanje i povezivanje međusobnih ovisnosti prepuštamo OSGI okruženju. Tim smo mehanizmom programere (i ostale uključene) u velikoj mjeri riješili problema koji se popularno nazivaju JAR hell. Naime, OSGI bundle osim naziva specificira i verziju biblioteka koje su potrebne za funkcioniranje modula. Tako je moguće deployati više verzija iste biblioteke bez glavobolje izazvane međuovisnostima.
Međuodnosi bundleova u OSGi okruženju
Service registry
Osim biblioteka, OSGI okruženje omogućuje da se bundleovi funkcionalno povezuju servisima. Kroz service registry moguće je Plain Old Java Objects (POJO) servise registrirati, pronaći te konzumirati iz drugog bundlea. Uz znanje da OSGI omogućuje instaliranje, povezivanje i pokretanje bundleova bez ponovnog pokretanja samog kontejnera, vidimo da taj mehanizam omogućuje komponentni razvoj softverskog rješenja. Na programeru je da napiše kod te ga zapakira u jedan od bundlea softverskog rješenja (podatkovni, integracijski, prezentacijski), a na OSGI izvršnom okruženju je da bundleove poveže s potrebnim bibliotekama i servisima.
Arhitektura OSGi kontejnera
Pretvorba EAR-a u OSGI bundle
Razveselit će vas da standardne (JEE) web-aplikacije možemo pretvoriti u web application bundles (WEB) na veoma jednostavan način. Dovoljno je promijeniti ekstenziju datoteke iz .ear u .eba te je importirati u WebSphere® Application Server kao Asset. To je dovoljno za početak, no za puno iskorištenje mogućnosti OSGI kontejnera potrebno je softversko rješenje dizajnirati kroz međusobno povezane module.
JPA 2.0
Mapiranje objekata u relacijski model (bazu podataka) jedna je od prvih zadaća postavljenih pred Java enterprise aplikacije. Tradicionalno, taj se posao obavlja pomoću JDBC specifikacije koja apstrahira različitosti implementacija relacijskih baza podataka. U slučajevima kada se traži povećana produktivnost i fleksibilnost, na štetu smanjene kontrole nad SQL upitima, JDBC nije dovoljan. Moderniji i sve češće upotrebljavan način rada s bazom podataka jest uporaba programskih alata za objektno-relacijsko mapiranje. Java standard programskog okruženja za mapiranje definiran je kroz specifikaciju JSR 220, a standard nazvan Java Persistence API (JPA 1.0). WAS 7 dolazi s implementacijom specifikacije. Kako to obično biva, u prvoj verziji specifikacije nisu pokriveni svi slučajevi uporabe pa je tako nedavno završena nadogradnja, verzija 2.0. Kroz paket modernizacije WAS-a 7, zajedno s podrškom za OSGI, dolazi i podrška za JPA 2.0. To nije slučajno. Naime, kao dio OSGI enterprise specifikacije definira se posebna vrsta Persistence i Client bundleova. Na taj je način moguće implementirati Persistance bundle koristeći JPA 2 tehnologiju i deployati ga u OSGI kontejner kako bi ih ostali (Client) bundleovi mogli upotrebljavati u situacijama kada je potrebno raditi s bazom podataka.
Nove funkcionalnosti JPA 2.0
Projekti na kojima se već upotrebljava JPA, ili oni koji su u fazi dizajna, trebali bi razmotriti prelazak na verziju 2.0 zbog nekoliko razloga:
Bolja je podrška za kompliciranije scenarije kao što su ugniježđeni (embeddable) objekti i složeni primarni ključevi.
Criteria query API – omogućava nam da umjesto da pišemo upite kao slobodan tekst koristimo Javu i sve blagodati razvojnog okruženja (code completion, provjeru sintakse…).
Bean validation – uz metapodatke(anotacije) o mapiranju moguće dodati i one za validaciju.
Veća je količina poboljšanja koja nije vidljiva izvana kao, npr., bolja podrška za serijalizaciju.
JPA 2.0 dio je JEE 6 standarda koji će biti podržan u WebSphereu 8, a kroz ovaj paket modernizacije možete ga koristiti već danas.
Feature Pack for XML
Možete li se sjetiti novije aplikacije u čijem ste razvoju sudjelovali a da ona u nekom segmentu ne koristi XML? Ja ne mogu. Danas, u SOA svijetu, XML je de facto standard za razmjenu podataka preko žice (wire format). Zbog toga je bitno, složit ćete se, imati mogućnost korištenja zadnje W3C specifikacije XML standarda. Feature Pack for XML u WAS 7 donosi podršku za sljedeće standarde:
Extensible Stylesheet Language Transformations (XSLT) 2.0
XML Path Language (XPath) 2.0
XML Query Language (XQuery) 1.0
Ta su tri standarda međusobno povezana. XPath se koristi u XSLT 2.0 transformacijama, a podskup je XQuery 1.0 specifikacije. Zbog toga podrška za te tri specifikacije dolazi u paketu. Kroz podršku za XSLT 2.0 dobivamo podršku za sve ugrađene tipove u XML Schemi i veći broj novih operatora i funkcija. Bez obzira na to želimo li dokument transformirati koristeći korisnički definirane funkcije ili pak u više izlaznih dokumenata, sada nam je to omogućeno. XPath je standardan način za poslove izvlačenja određenih elemenata iz XML dokumenta. Zadatak koji je danas veoma čest. Verzijom 2.0 na raspolaganju imamo povećan skup operatora i funkcija. Na taj način operacije koje su s XPathom 1.0 bile teške ili nemoguće s verzijom 2.0 postaju jednostavne. Za kompliciranije scenarije, koje je do sada bilo teško riješiti bez programiranja u Javi, feature pack donosi implementaciju XQuery 1.0 specifikacije. XQuery je jezik sa sintaksom koja uključuje XPath i izraze slične SQL-u. Često ćemo ga koristiti kao jezik za izvlačenje podataka iz XML repozitorija. Baš kao SQL za rad s relacijskom bazom podataka. Zapravo DB2 v9 podržava XML tip podatka, a zajedno s njime i XQuery kao jezik za manipulaciju podacima. Tako je dobrodošla podrška za XQuery i u WAS-u kako bi se olakšao rad s podacima u XML formatu.
Za kraj alati. Razvoj rješenja koji koristi Feature pack for XML podržan je u RAD-u 7.5.5.1 nadalje. Moguće je i debugiranje XSLT 2.0 transformacija, što RAD stavlja ispred sličnih alata. Podrška za OSGI i JPA 2.0 dostupna je kroz betu Rational Application Developera 8.0.
Cilj ovog kratkog pregleda modernizacijskih paketa za WAS 7.0 bio je približiti vam tehnologije koje postaju dostupne i koje će vam, nadamo se, ubrzati razvoj softverskih rješenja. OSGI, JPA 2.0 i XQuery tehnologije su čije je vrijeme došlo. Kako biste ih koristili već danas, dovoljno je besplatno skinuti feature pack arhive s IBM-ovih stranica te ih instalirati na već postojeću instalaciju WAS-a 7.
U jednom od prošlih brojeva našeg FYI-a mogli ste pročitati članak o jednom specifičnom portalskom rješenju. Kao dio tog članka dan je opširan uvod u povijesni razvoj portala kao koncepta i pregled najvažnijih predstavnika portalskih rješenja te su objašnjene glavne namjene istih.
Da štovani čitatelji ne bi doživjeli preveliki déjà vu, ovdje ćemo se koncentrirati isključivo na jedan dio porodice portalskih rješenja, a to su enterprise portalska rješenja, odnosno portali. Takva su rješenja temelj izrade korporativnih portala koji velikim organizacijama i tvrtkama s kompleksnim poslovnim i specifičnim tehničkim potrebama pružaju lakši, konzistentniji put do ostvarenja njihovih zahtjeva. Srce je svakog enterprise portala programski okvir za integraciju informacija, poslovnih procesa i ljudi. Svoje integracijske mogućnosti portali pružaju kroz jedinstvenu, sigurnu, mogućnostima bogatu točku pristupa informacijama, dokumentima, aplikacijama i ostalim resursima putem logičkih organizacijskih jedinica – portleta. Tipični zadaci koji se obavljaju kroz sučelja portala uključuju sakupljanje, objavu i održavanje informacija i dokumentacije te izradu i objavljivanje specifičnih poslovnih aplikacija koje pomažu u svakodnevnom životu organizacije ili tvrtke. Tako nabrojane zadatke i slučajeve uporabe pokrivaju sva ili gotovo sva moderna portalska rješenja, no kako u fokusu i portfelju tvrtke CROZ dva rješenja čine glavninu implementacijskih iskustava, koncentrirat ćemo se na prikaz mogućnosti i usporedbu baš tih rješenja. Riječ je o open source rješenju imena Liferay Portal te rješenju koje nudi IBM pod nazivom WebSphere Portal. Oba spomenuta rješenja bit će predstavljena kroz najbitnije zadatke koji se pred njih stavljaju u svakodnevnom radu, s isticanjem sličnosti i razlika. Također, bit će prezentirane prednosti i mane svakog od njih s ciljem da potencijalni korisnici mogu lakše zaključiti koje rješenje bolje odgovara njihovim potrebama. Tipični zadaci koji će poslužiti kao ogledalo mogućnosti obje platforme bit će upravljanje i objava sadržaja te razvoj i objava specifičnih poslovnih aplikacija. Time ne zaboravljamo ključne točke zbog kojih su enterprise portali to što jesu:
· Single Sign-On (SSO)
· Personalizacija i prilagodba
· Upravljanje pravima pristupa
Te ključne stvari svako portalsko rješenje dovodi gotovo do savršenstva i ne postoje bitne razlike u pristupu različitih rješenja. Stoga je bitno naglasiti već spomenuta područja na kojima se rješenja bar minimalno razlikuju, makar krajnjom izvedbom i dojmom.
Sesame Street Liferay Portal – vesela primjena ozbiljnog portalskog rješenja
Pogled iz sistemske sobe
Prije nego što krenemo pričati o upravljanju dokumentima ili razvoju specifičnih poslovnih funkcionalnosti, osvrnimo se samo ukratko na sistemske temelje potrebne da se Liferay Portal i WebSphere Portal postave u produkcijski rad. Razmjerna je potreba za resursima i u ostalim okolinama, počevši od razvojne, no za ilustraciju potreba poslužit će produkcijski uvjeti. S obzirom na to da su oba rješenja zapravo JEE aplikacije čije pokretanje ovisi o postojanju JEE aplikativnog poslužitelja, očito je da se mogu izvoditi gotovo na bilo kojoj dostupnoj platformi, počevši od Microsoft Windows platforme, bilo koje UNIX bazirane platforme pa čak i z/OS platforme. S time na umu potrebno je naglasiti da su oba rješenja poprilični potrošači resursa. Diskovni će podsustav već samom instalacijom WebSphere Portal rješenja biti na udaru s obzirom na to da je potrebno minimalno 4 GB diskovnog prostora samo za instalaciju. Liferay Portal puno je “nježniji” što se toga tiče – do 500 MB prostora na disku sasvim je dovoljno za instalaciju. Kako počne rasti količina podataka koji se održavaju i pohranjuju korištenjem jednog ili drugog rješenja, rast će dakako potrošnja diskovnog prostora kojeg koriste baze podataka i repozitoriji dokumenata u koje se podaci i dokumenti pohranjuju. Što se radne memorije tiče, oba će rješenja u produkcijskim uvjetima biti sretna ako im osigurate 4 GB radne memorije po procesoru te izdvojite njihove poslužitelje baze podataka na zasebni hardver.
Liferay i WebSphere u svijetu upravljanja dokumentima
Ključni procesi u životu (bilo svakodnevnom, bilo dugoročnom) svake ozbiljne organizacije i tvrtke uključuju rad s velikim količinama raznih dokumenata, odnosno, bolje rečeno, velikim količinama raznih informacija. Dakako da portalska rješenja nisu “izmislila” procese upravljanja dokumentima uz pomoć programske podrške, no kao centralno integracijsko mjesto cijele organizacije portalsko je rješenje idealno za osiguravanje konzistentnog upravljanja važnim (ili svim) dokumentima. Što je tipično potrebno za upravljanje dokumentima? Upravljanje dokumentima se, bio Portal uključen ili ne, temelji na repozitoriju dokumenata, kreiranju procesa za upravljanje dokumentima (document workflow) te sučelju za upravljanje dokumentima i procesima. Kako bismo usporedili dva portalska rješenja, pogledat ćemo tri upravo navedena temelja upravljanja dokumentima. Odmah moram napomenuti da će možda neka od zapažanja vezana uz sučelje za upravljanje dokumentima biti osobna, no to je gotovo uvijek slučaj kada se bavimo sučeljima aplikacija.
Repozitorij dokumenata
Bilo koje iole ozbiljnije rješenje za upravljanje dokumentima izgrađeno je oko kvalitetnog repozitorija. Isto tako, ako je rješenje temeljeno na JEE platformi, tada će taj repozitorij biti izgrađen na temeljima specifikacije JSR-170, odnosno imat će obilježja Java Content Repository specifikacije. Ovdje se oba rješenja ne razlikuju mnogo – Liferay Portal koristi Apache Jackrabbit JCR implementaciju, dok WebSphere Portal koristi vlastitu implementaciju istog standarda. Potrebno je napomenuti da je implementacija koju koristi Liferay Portal bolje dokumentirana te tako omogućava lakše dodavanje specifičnih funkcionalnosti ukoliko su potrebne.
Procesi upravljanja dokumentima
Oba rješenja donose mogućnosti prilagodbe procesa upravljanja dokumentima (document workflow) koja će zadovoljiti većinu poslovnih potreba. Doduše, Liferay Portal ima čak i malo fleksibilniji model procesa, no razlike su gotovo nevidljive. Oba rješenja već definiraju standardne role koje sudjeluju u procesu upravljanja dokumentima te se posao prilagodbe svodi na ispravno definiranje koraka procesa kroz koji dokumenti prolaze od njihova kreiranja pa do objave i održavanja.
Portalsko sučelje za upravljanje dokumentima
Sličnosti Liferay i WebSphere Portala ogledaju se i u sučelju, no samo zbog činjenice da oba rješenja nude istu funkcionalnost – upravljanje dokumentima. Sučelje (u cjelini, ne samo dio za upravljanje dokumentima) jest dio gdje Liferay briljira. Odlikuju ga intuitivnost, lakoća korištenja, jasno naglašavanje i isticanje bitnih informacija i dostupnih akcija. Jednom riječju, usability je na izrazito visokoj razini. Razvojni tim koji stoji iza Liferay Portal rješenja napravio je dinamično i bogato, ali u isto vrijeme i jednostavno sučelje. WebSphere Portal tu ponešto zaostaje, iako je sučelje mnogo bolje nego u prošlim verzijama. Napomenuo sam da će ovdje zapažanja biti vjerojatno osobna, pa tako treba istaknuti da WebSphere Portal ima vrlo funkcionalno sučelje za upravljanje dokumentima koje je u skladu sa sučeljem ostatka portala i omogućit će korisniku da izvede željeni niz akcija, no završni dojam nije toliko dobar i pozitivan. Možda bi dojam bio bolji kada drugo rješenje ne bi ostavljalo fantastičan dojam.
Mogućnost proširenja
U ovoj usporedbi svakako treba imati na umu proširivost IBM-ova rješenja koje se lako može “nasloniti” na trenutno najbolji sustav upravljanja dokumentima na tržištu, IBM Filenet. U slučaju takve simbioze WebSphere Portal postaje zapravo samo sučelje kroz koje se otvara pogled u Filenet, koji nudi bezbroj mogućnosti i funkcionalnosti u prilagodbi procesa upravljanja dokumentima. I Liferay Portal može se po želji proširiti samostalnim rješenjem za upravljanje dokumentima u vidu izvrsnog open source Alfresco rješenja, no IBM Filenet trenutno je vrh ponude i uparivanje WebSphere Portal rješenja s Filenet rješenjem nudi maksimalne mogućnosti u svijetu upravljanja i objave sadržaja i dokumenata.
Opći dojam
Upravljanje je dokumentima, iskreno priznajmo, jednoličan i pomalo dosadan zadatak koji se stavlja pred informacijske sustave, odnosno njihove komponente. Kakav zadatak, takva i rješenja. Nikakvih iznenađenja nema ni kad su u pitanju WebSphere Portal i Liferay Portal. Postavite repozitorij dokumenata, prilagodite proces upravljanja dokumentima, dodijelite ljudima prava sudjelovanja u tom procesu i koristite ugrađeno sučelje za izradu i objavljivanje dokumenata. Sve ćete to nekako malo jednostavnije i brže izvesti s Liferay Portal rješenjem, te je ono za tipične upotrebe iskoristivije, no ako vam se količina dokumenata ili kompleksnost procesa upravljanja znatno poveća, tada WebSphere Portal proširen s IBM Filenet rješenjem postaje bolji izbor.
Samo još jedan portlet, molim
Ako imate potrebu dodatno osnažiti već ionako snažnu platformu (što i Liferay i WebSphere jesu) određenom specifičnom poslovnom funkcionalnošću, najlakše ćete to načiniti razvojem portleta prema funkcijskoj (i nefunkcijskoj) specifikaciji koja je stavljena pred implementacijski tim. Obje portalske platforme nude cijeli niz različitih mogućnosti koje će vam olakšati posao te podržavaju gotovo istovjetnu paletu razvojnih tehnologija. No, postoji jedna bitna razlika. WebSphere Portal sistemski je dosta zahtjevniji te postavlja pred razvojni tim zadatak uspostave razvojne okoline u kojoj će razvoj portleta biti brz i jednostavan. To može uključivati razvoj na nekom drugom portalskom okruženju (Apache Pluto ili JetSpeed, Oracle OpenPortal, pa čak i Liferay Portal) ili podizanju WebSphere Portala kao razvojnog okruženja, što podrazumijeva nabavu zaista snažnih razvojnih računala. Liferay, s druge strane, ne postavlja tako visoke sistemske zahtjeve pa se bez pretjerane prilagodbe može koristiti i kao razvojno okruženje. Pogledajmo sada najbitnije razvojne tehnologije (čije detalje možete pogledati u okviru uz tekst) za razvoj vlastitih portleta te pružaju li WebSphere Portal i Liferay podršku za njih.
JSR-286
Najnoviju portlet specifikaciju podržavaju oba portala, što je vrlo bitno za razvoj modernih portleta nove generacije.
JSR-186
Naravno, za jednostavne portlete i dalje je dostupna stara portlet specifikacija koja se preporuča za manje “zahvate” te portlete koji nemaju potrebe za AJAX funkcionalnostima.
JSR-314
JSF postaje sve popularnija tehnologija, i to s razlogom. Otklonjeni su performansni problemi JSF implementacija, a izašla je i nova specifikacija, JSF2. Obećane su prednosti, između ostalog, brži, jednostavniji i standardniji razvoj sučelja, performansna poboljšanja, bolja podrška od strane razvojnih alata. Ovdje WebSphere Portal ne briljira – ne nudi podršku za JSF2 “iz kutije”, no uz male prilagodbe mogu se razvijati i JSF2 portleti. Liferay, s druge strane, već nudi podršku za JSF2 portlete.
Nagrada za najbolji portal ide u ruke…
Pobjednika u ovoj usporedbi nema i ne može biti. Zašto je tome tako? Tvrdnja s početka ove kratke priče i dalje stoji, ova su dva rješenja vrlo slična u svakom pogledu. Korisničko je sučelje Liferay Portal rješenja za nijansu bolje, ljepše, intuitivnije za rad. WebSphere Portal je proširivija platforma, donosi šire područje uporabe, pogotovo ako ga se kombinira s nekim od specijaliziranih rješenja za upravljanje dokumentima (Filenet) ili procesima (Process Server) koja nudi IBM. Ako vam zahtjevi nisu enterprise tipa, tada je Liferay Portal besplatan te nema podršku izvan Liferay foruma i širokih prostranstava interneta. No takva upotreba Liferay rješenja ima smisla u edukativnim, istraživačkim, osobnim svrhama. Ako imate iole ozbiljniji slučaj uporabe, tada ćete sigurno krenuti u implementaciju Liferay Portal rješenja s plaćenom i visoko dostupnom stručnom podrškom kakvu WebSphere Portal rješenje ima odmah dostupnu. U svojim trenutnim verzijama (Liferay Portal 5.2, WebSphere Portal 6.1.5.1) oba su rješenja dostigla zavidan stupanj zrelosti te se problemi pojavljuju rijetko, no uvijek su mogući, tako da je rad bez stručne podrške gotovo pa nemoguć. Iskustva CROZ-ovih timova u implementaciji rješenja temeljenih na obje platforme mahom su vrlo dobra, i bez većeg čupanja ono malo kose što nam je ostalo. Naša se preporuka u odabiru konkretne platforme uvijek temelji na intenzivnoj suradnji s korisnikom kako bismo pokušali definirati njihove zahtjeve te im pomoći da krajnje rješenje temeljeno na jednom od Portala bude točno ono što oni žele i trebaju te da ga, na kraju, mogu koristiti što duže, jednostavnije i sa zadovoljstvom.
IBM Lotus Software pruža robusni softver za suradnju koji spaja ljude i potiče suradnju i inovativnost tijekom optimizacije njihova načina rada. S Lotusom se postižu bolji rezultati poslovanja kroz pametniju suradnju.
Zbog brojnih upita korisnika i partnera za unificiranom ECM platformom, iz pogona je izašlo CROZ-ovo rješenje za upravljanje dokumentima, procesima i zapisima - cDocs.
To platformsko rješenje namijenjeno je srednjim i velikim organizacijama koje žele sustavno informatizirati svoje poslovne procese. U svojoj srži cDocs je business process management i document management platforma koja dolazi s nekoliko unaprijed spremnih modula: Ulazna pošta, Izlazna pošta, Interna pošta, Ugovori, Računi, Uplate/Isplate, ali i s mogućnošću efikasne izgradnje podrške za nove i specifične poslovne procese. Naše iskustvo u poslovnoj analizi pomoglo nam je da postojeće module prilagodimo što većem broju korisnika out-of-the-box, a modularna nam platforma omogućava potpunu prilagodbu gotovih i novih modula vašim specifičnim potrebama.
Pri projektiranju platforme i modula koji zaokružuju proizvod namjera nam je bila omogućiti maksimalno očuvanje investicije u IT znanja i tehnologije te spriječiti vezivanje korisnika uz zatvorene formate. Osim toga, ideja je bila i ne opteretiti buduće korisnike dodatnim licencnim troškovima pa smo se odmah u početku odlučili za integraciju najkvalitetnijih open source komponenti i izgradnju modula nad takvom otvorenom platformom.
Upravo se zato u samoj srži sustava nalaze Alfresco document management system i JBoss jBPM platforma za upravljanje poslovnim procesima. Alfresco DMS je proizvod kompanije Alfresco Inc. i riječ je o vodećem open source sustavu za upravljanje dokumentima. Zbog njegovih izvrsnih mogućnosti skaliranja prema velikom broju zapisa i korisnika, cDocs platforma nema ograničenja u tom pogledu, što naše reference mogu i posvjedočiti. Alfresco se, dakle, u cDocsu brine za prihvat, pohranu, otpremu i distribuciju dokumenata. jBPM je proizvod kompanije JBoss Inc. i riječ je, opet, o vodećem open source sustavu za upravljanje poslovnim procesima.
Osim integracije otvorenih i open source komponenti CROZ cDocs rješenje bazirano je na javno definiranim standardima u upravljanju poslovnim procesima – jPDL i BPEL, što znači da vaše poslovne procese možemo projektirati u alatima na koje smo navikli, a isto vrijedi i za vaše odjele koji se bave poslovnom analizom. Ukoliko već imate procese opisane u BPEL jeziku, mi na brz način možemo izgraditi modularnu IT podršku za njihovo upravljanje. Isto tako, procese opisane i implementirane u cDocs modulima možemo izvesti i analizirati u specijaliziranim alatima. Igra dobro s drugima, i na to smo iznimno ponosni!
cDocs je nadogradivo i robusno rješenje, a te karakteristike proizlaze iz njegovih dviju glavnih arhitekturalnih komponenti – CROZ ECM (Enterprise Content Managememt) platforme i sustava modula.
ECM platforma je u srži rješenja i brine se o definiranju i izvođenju procesa, životnom ciklusu procesa i dokumenata, korisničkim pravima, notifikacijama, kalendaru, upravljanju zapisima, integraciji sa sustavima za prihvat (skeniranje, digitalizacija), data miningu i ostalim poslovima “ispod haube”. ECM platforma je motor ovog rješenja, i to pouzdan i testiran motor s dugim vijekom trajanja. Testirana je na desetcima milijuna dokumenata i tisućama istovremenih korisnika, ali skalira se i prema tisućama dokumenata i desetcima korisnika.
Sustav modula omogućava efikasnu izgradnju podrške za specifične poslovne procese i on je upravljač ovog rješenja (isprike zbog otrcane usporedbe s automobilom, bolji smo u izradi rješenja nego u pisanju tekstova:-). Gotove module koje isporučujemo s proizvodom prilagodili smo što široj publici, s velikim brojem opcija i mogućnostima, ali i ostavili prilagodljivima za konkretne potrebe organizacije u kojoj se implementiraju. Sve nove module gradimo kroz otvorene standarde u komunikaciji s odjelom za poslovnu analizu, a nakon dokumentiranja procesa u suradnji s korisnikom.
Neke od najvažnijih mogućnosti rješenja:
- robusna, moćna i fleksibilna platforma za upravljanje procesima i dokumentima
- skup gotovih modula koje je pripremio CROZ-ov odjel za poslovnu analizu, s mogućnošću prilagodbe
- brza i efikasna priprema novih modula nad unificiranom platformom, jako malen time-to-market za dodatne procese
- sustav notifikacija u potpunosti integriran s procesnim kalendarom koji u pozadini obavještava korisnika o njegovim obavezama u procesima, podsjeća na kašnjenja i istek rokova
- odlična integracija s rješenjima za digitalizaciju i prihvat: Kofax, Kodak, Abby i ostali
- integracija sa sustavima za izvještavanje kao data platforma te integriran fleksibilan sustav za izvještavanje
- pouzdan historijat svih događaja
- fleksibilan i siguran sustav korisničkih prava uz mogućnost integracije u Lotus i Active Directory sustave za autentikaciju
- integracija u različite IT okoline, rad na virtualiziranim sustavima i s raznim bazama podataka, nad različitim operativnim sustavima
- integracije u Microsoft Office, OpenOffice, Windows Explorer, Mac OS
Dosadašnje reference potvrdile su naš odabir arhitekture i put prema otvorenom sustavu, i da danas startamo, ponovili bismo iste odluke. Manje zahtjevnosti odabranih komponenti naši majstori i alatničari korigirali su u hodu, a u budućnosti ćemo također nastaviti proizvodnju na istom tragu. Ponudit ćemo dodatne module i integracije, s posebnim fokusom na brzini i jednostavnosti korištenja sustava. Mi smo zadovoljni, nadamo se da će i naši korisnici prepoznati trud i rad jutrima i noćima uz zvuk tvorničke sirene.
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
