OSGi: Použít nebo nepoužít?

Hned na začátku článku musím říci, že jsem velký fanda modulárních systémů a OSGi především. Ale to hned nemusí znamenat, že OSGi budu používat vždy a za všech okolností - pro mě je důležité za použitím jakékoliv technologie vidět určitý přínos a tedy důvod, proč danou technologii použít. Samozřejmě to také musí být vyvážené rozumnou pracností.

O OSGi je v poslední době hodně slyšet. Málokdo asi ví, že tato věc vznikla už někdy v roce 1999, takže se nejedná o žádnou novinku. Určitě znáte resp. používáte Eclipse nebo IBM WebSphere - to jsou asi dva hlavní představitelé produktů, které jsou postaveny nad OSGi. Přijde mi, že to správné buzzword z toho udělal až Spring, protože Spring si OSGi vybral jako nosné řešení pro své všechny projekty, pro svoji vlastní aplikační serverovou platformu SpringSource Application Platform. Základem je projekt Spring Dynamic modules, který zase funguje jako nástavba na "čistým" API OSGi a nabízí spoustu ulehčení - prostě standardní Spring :). Možná ještě více publicitě OSGi pomohl sám Sun, který přišel s něčím podobným přímo do JVM - Java Module System. Do teď není zcela jasné, které řešení nakonec zvítězí, ale řekl bych, že OSGi má v současné době navrch.

Cílem článku není vysvětlovat možnosti OSGi, na to jsou jiné weby. Tento článek shrnuje mé osobní poznatky z průzkumu OSGi, jakožto možné platformy pro vývoj naší nové aplikace. Připravujeme vývoj nové webové aplikace (možná by se dalo říci i produktu), která technologicky nevybočuje nijak z průměru (Spring, Hibernate, JSF). Nejedná se také o aplikaci nijak zásadně kritickou, spíše o podpůrný nástroj pro menší skupinku lidí ve firmě. Aplikace to nebude (aspoň na začátku) nijak rozsáhlá.

A teď jsme před rozhodnutím, zda použít nebo nepoužít OSGi. Ještě jsme se finálně nerozhodli, ale spíše to vidím tak, že OSGi pro tento projekt zatím nepoužijeme. Mám k tomu následující důvody:

• Sice jsem psal, že OSGi bude mít příští rok 10 let, ale v oblasti serverové Javy tak dlouho nepůsobí. Nejdříve tato technologie byla vyvíjena pro mobilní aplikace (to je záruka, že OSGi je opravdu lightweigth řešení), poté se adaptovala v oblasti standalone aplikací (např. Eclipse, kontejner Equinox) a teď v poslední době je snaha o adaptaci v oblasti serverových aplikací. To je trochu složitější, protože jsou potřeba minimálně dva kontejnery - pro Javu resp. servlety a pro OSGi. Jsou plně podporovány kontejnery Tomcat, Jetty a prý další nejsou problém, ale nikde jsem k tomu moc informací nenašel. OSGi kontejner může být vložen do webového kontejneru a naopak, více zde. Jak je možné integrovat do OSGi+webového kontejneru stávající MVC řešení? Co když budu chtít použít další kontejner pro EJB? Tak v tomto vůbec jasno nemám.


• Abych mohl aplikaci modularizovat pomocí OSGi, tak pak musím mít vše rozdělené do tzv. bundlů - moje i všechny knihovny třetích stran musí být bundly. Vznikají tedy různá repository (např. 1, 2), kde je možné si stáhnout bundly známých knihoven, např. pro Hibernate, Jakarta Commons apod. Nicméně určitě všechny knihovny tam v podobě bundlů nenajdete. Pak jsou dvě možnosti - buď si počkáte až bundle bude a nebo si bundle z jar souborů vytvoříte sami. Buď ručně nebo s pomocí nástroje Bnd.


• Pokud tedy budu mít OSGi aplikaci, tak mohu za běhu aplikace instalovat, nahrávat, rušit jednotlivé moduly resp. bundly, mohu efektivně řešit verzování apod. Na to se dá říci jen SUPER. Ale potřebuji to tak zrovna pro mojí aplikaci? Nikdy jsem to zrovna nepotřeboval a pro tuto aplikaci to asi také nepotřebuji. Aplikace není kritická, takže ji v pohodě mohu celou otočit. Ani velká moc nebude, takže upgrade bude otázka chvilky. Na druhou stranu mě hned napadá, že se bude jednat o aplikaci s instalacemi a úpravami u více zákazníků, což by se hezky dalo řešit pomocí modulů. Také hromadný upgrade všech instalací z jednoho místa by nemusel být k zahození.


• Nikdy neříkej nikdy - možná přijde doba, kdy z malé počáteční aplikace bude velký systém, který bude potřebovat modularizovat. Nemám s tím žádnou zkušenost, ale řekl bych, že nebude tak velký problém z již existující aplikace vytvořit OSGi aplikaci. Příkladem mohou být např. Spring projekty, které jsou nyní plně OSGi - jednotlivé jar soubory jsou zároveň bundly exportující a importující potřebné služby resp. balíky.

Nějaké zdroje k OSGi:

• Spring Team blog for OSGi
  
• JavaWorld článek - Hello OSGi I, II, III.
  
• Dagi je dle mého názoru velkým fandou OSGi.
  
• Prezentace na JavaLobby 2006