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