pátek 31. srpna 2007

Zdrojáky online

Hodně často potřebuji rychle nakouknout do zdrojových souborů open source Java knihoven, které používám na svých projektech, případně se nějakým způsobem vztahují k mé práci. Pohodlnou cestu představuje nastavení zdrojáků přímo v IDE, ale ne všechny knihovny mám slinkované se zdrojáky a proto jsem si oblíbil dvě webové stránky, které agregují open source zdrojáky všech možných Java knihoven a umožňují jejich vyhledání , zobrazení a efektivní procházení.

První stránkou je JDocs, který se díky AJAX rozhraní celkem blíží možnostem IDE. Druhou stránkou je Docjar, který má jednodušší, ale o to přímočařejší rozhraní. Obě dvě stránky nabízejí možnost vyhledávání integrovat do IDE a Docjar nabízí rovněž tuto integraci do webového prohlížeče. Osobně však dávám prozatím přednost přímému hledání na stránkách.

Pokud potřebujete rychle nakouknout do nějakého zdrojáku open source projektu, mohu obě tyto stránky doporučit. Minimálně JDocs stojí za vyzkoušení.

úterý 28. srpna 2007

Certifikace - děkuji nechci

Říkám to rovnou na úvod, aby bylo jasno, nejsem příznivce certifikací a v tomto spotu se zkusím podělit o důvody, které mě k tomu vedou. K sepsáni tohoto článku mě vedou celkem tři události.

Pokud budu mluvit konkrétně,tak Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0. mě neláká z toho důvodu, že nenosím v hlavě ani kompilátor, ani interpretr a už vůbec si nedovedu představit jak runtime zpracovávám v hlavě (překlad, interpretace, výpis výstupu) zdrojový kód na kusu papíru. Ušetřený procesorový čas budu raději věnovat jiným samovzdělávacím aktivitám.

Ovšem uznávám, že tento certifikát má jistou vypovídající hodnotu. Jestli tato hodnota napoví cosi o tom, že držitel dokáže v hlavě překládat a provádět java kód a nebo o tom, že má dobré znalosti Javy, záleží pouze a jenom na interpretaci toho kdo na certifikát pohlíží. Co se týká pokročilejších certifikací od Sunu, tak tam bych byl ještě obezřetnější.

Asi nejvíce mi vadí fakt, že nalévají do hlavy pouze a jenom pravdu od Sunu. To bohužel vede k tomu, že je do člověka v některých případech napumpovaná teorie, která je v praxi nepoužitelná. A tak člověk bohužel získá deformovaný pohled na ostatní technologie.

V celku se mi proto líbila myšlenka diskuse Open Source Contribution - Alternative to Certification?. Je to jednoduché, místo času tráveného tréninkem na certifikaci, budete raději věnovat svůj čas spolupráci na některém open source projektu. Bohužel ani tato myšlenka není spásná.

Problém číslo jedna, kontribuce a její rozsah a přínos se dá těžko nějak prověřit v případě, že se zrovna nejmenujete Gavin King. Vývojáři vetšinou pomáhají v těch projektech, které samo používají a pokud se jedná o projekty větší, pak je kontribuce skoro nemožná, což je problém číslo dva. Posloužím vlastním příkladem. Nedávno jsem našel jednu "blbou" chybu v Hibernate. Chyba už byla nějaký čas nereportovaná, oprava byla trapně jednoduchá. Takže jsem chybu potvrdil, udělal jsem fix a ten jsem včetně diffu a unit testu připojil. Bohužel ani mailová urgence s tím nepohla.

Tenhle příklad dokládá, že člověk může mít snahu o kontribuci, ale stejně je mu to k ničemu. Stejně jako má certifikace vypovídající hodnotu, má i kontribuce vypovídající hodnotu, jejíchž interpretace je silně závislá na tom, kdo ji posuzuje. Na druhou stranu kontribuce má tu ne nepodstatnou výhodu, že je prakticky uchopitelná, což se o certifikaci dá říci pouze stěží.

pondělí 27. srpna 2007

OSGi klíč k rozšiřitelnosti aplikací?

Většina aplikací, na kterých jsem pracoval, vyžadovala jistou míru rozšiřitelnosti (customization) podle potřeb zákazníka a naopak, některé vlastnosti bylo potřeba přidat/odebrat podle zakoupené verze. Tyto požadavky vedou k potřebě jisté modulárnosti aplikace. Na tu se již myslelo při návrhu, to je ten lepší případ a nebo se ad hoc dodělávala, horší případ. Java, jedno či standard či enterprise edice, nenabízí žádné oficiální prostředky pro tvorbu rozšiřitelnosti aplikací.

Obecně můžeme aplikaci rozšiřovat v dvou místech: frontendu (UI) a backendu (aplikační logika). Praktický vzato můžeme mít například rozšíření, které do aplikace přidává novou funkčnost v podobě komplexního UI a aplikační logiky a nebo jednu třídu, která se řadí kamsi do exekučního procesu. K tomu abychom mohli rozšíření provádět, potřebujeme nějaký systém, který bude jednotlivé rozšíření aplikovat. Tento systém by měl mít určitě možnost rozšíření spravovat a nebylo by na škodu, kdyby se rozšíření dala přidávat za bšhu aplikace.

Z pohledu vnitřní architektury aplikace budeme po tomto systému požadovat možnost definovat body rozšíření (extension points) a také možnost exportovat pouze určité API k vnějšímu použití. Tento problém za nás bude částečně řešit Java Module systém (více o Java Module systém na Dagblogu), ale ten bude až od Javy 7.

Pokud se podíváme na produkty, které používáme dnes a denně jako vývojáři, tak zjistíme, že zde je již rozšiřitelnost vyřešena celkem uspokojivě. Ano narážím skutečně na IDE jako Eclipse či NetBeans, kde je rozšiřitelnost takřka dotažená k dokonalosti.

Pokud vezmu konkrétně Eclipse, tak ten je celý postaven kolem OSGi resp. jeho implementace. OSGi je specifikace, která definuje standard pro vývoj, nasazení a správu aplikací v řízeném prostředí. Řízeným prostředím je OSGi kontejner a aplikací je takzvaný bundle. Zjednodušeně řečeno OSGi kontejner je vlastní prostředí vystavěné nad JVM, které řídí soužití aplikací (takzvaných bundles, dále v textu balíků) v tomto prostředí - viditelností určitého API počínaje a definicí závislostí konče.

Funkcionalita OSGi je rozdělena do několika vrstev.

  • security vrstva - rozšiřuje bezpečnostní mechanismy založená na standardní J2SE bezpečnosti, například grantování přístupu k určitým službám na základě digitálního podpisu daného balíku.
  • module vrstva - řeší viditelnost jednotlivých API v rámci balíků, to znamená skrývání vystavení určitých tříd či package.
  • life cycle vrstva - definuje runtime záležitosti pro balíky, to znamená jejich přidávání, odebíraní, startovaní a stopování za běhu. Zároveň definuje událostní API, které se využívá k managementu balíků.
  • service vrstva - umožňuje definovat služby, se kterými se balík integruje. V podstatě jde o to definovat rozhraní služby a její implementaci uschovat. Balík není závislý na konkrétní implementaci. To je podobný přístup jako například v J2EE, kde jsou nadefinována rozhraní např. servlet API a jednotlivý poskytovatelé služeb (aplikační server, serlvet kontejner) si jej implementují.
  • execution environment - vlastní Java prostředí, ve kterém dochází k běhu.

OSGi kontejner kromě služeb uvedených v rámci těchto vrstev slouží zároveň jako Service registry. Díky tomu je možné služby vyhledávat, registrovat a nebo vybírat podle jejich implementace. Samotná služba je pak opět balík (bundle) registrovaný v registry. Interakce balíku s jednotlivými vrstvami OSGi ukazuje následující obrázek.

OSGi je tu již od roku 1999, kdy byla založena OSGi Alliance což je sdružení stojící za dalším rozvojem OSGi. V současné době je na světě již čtvrtá verze specifikace, která je v rámci JCP podchycena jako JSR 291. OSGi má celou řadu implementací z těch nejzajímavějších open source OSGi kontejnerů například: Eclipse Equinox, Apache Felix, Knopflerfish.

Dostupnost těchto OSGi kontejnerů znamená, že je možné postavit architekturu aplikací kolem OSGi a nebo o tom minimálně uvažovat. OSGi kontejner je přesně ten typ platformy, který se hodí pro vývoj rozšiřitelných aplikací. To byl zřejmě ten důvod, proč se OSGi rozhodli využít následující produkty viz následující citace z článku Can Someone Tell Sun About OSGi?.

BEA moved their micro Service Architecture on top of OSGi, IBM Websphere 6.1 seems to have chosen OSGi, Jonas is an EE framework build on OSGi from day one, and the JBoss Microcontainer is modified to support OSGi. On top of that, we have one product that made many people re-think Java EE: Spring.

Když k tomu připočteme hrátky s OSGi v Struts 2 nebo projekt Equinox in a Servlet Container, pak zdá se, že jse OSGi začíná pronikat do enterprise oblasti. Zatím se jedná první vlaštovky, takže těžko očekávat interoperabilitu skrze širší spektrum enterprise technologií jako například EJB.

Pokud by se podařilo JSR 291 vmáčknout nějakým způsobem k J2EE 6, o čemž se živě spekuluje, znamenalo by to výrazný posun k tomu, aby se OSGi stalo prostředkem k psaní rozšiřitelných aplikací skrze Java platformu. Bohužel úsilí kolem OSGi a jeho standardizace v Jave naráží politické tlaky Sunu kolem konkurenční specifikace JSR 277 (Java Module System).

Situace JSR 277 vs JSR 291 bude vyjasněna v budoucnu, ale chceteli psát rozšiřitelné aplikace v tuto chvíli, stojí OSGi minimálně za vaší pozornost.

Související články