V n´asleduj´ıc´ı ˇc´asti je pops´ana technologie OSGi. Vˇetˇsina textu vych´az´ı ze:
[4] a [10].
2.2.1 Modularita v Javˇ e
Jiˇz bylo ˇreˇceno, ˇze v dneˇsn´ı dobˇe je kladen velk´y d˚uraz na modularitu apli-kac´ı. V programovac´ım jazyce Java jsou vˇsak tyto moˇznosti znaˇcnˇe omezen´e.
Aplikace vytvoˇren´e v Javˇe jsou typicky distribuov´any v JAR3 archivech, coˇz je souborov´y form´at zaloˇzen´y na ZIP kompresi, kter´y umoˇzˇnuje slouˇcit nˇ eko-lik soubor˚u do jednoho. Jsou v nˇem obsaˇzeny pˇredevˇs´ım soubory typuclass, metadata a pˇr´ıpadn´e dalˇs´ı zdroje pro ´uˇcely aplikace jako obr´azky nebo tex-tov´e dokumenty.
JAR soubory obvykle poskytuj´ı jednu knihovnu nebo pouze ˇc´ast funkci-onality aplikace. Jen zˇr´ıdka aplikaci tvoˇr´ı pouze jeden JAR archiv, rozs´ahl´e
3Souborov´y form´at JAR – akronym vytvoˇren´y z
”Java archive“. Soubory maj´ı pˇr´ıponu .jar. V´ıce na [8].
Komponentov´e programov´an´ı Platforma OSGi
aplikace se mohou skl´adat z des´ıtek aˇz stovek tˇechto soubor˚u [4]. Je zˇrejm´e, ˇ
ze kompozice tak velk´eho rozsahu je n´aroˇcn´a na spr´avu a ˇr´ızen´ı, avˇsak Java sama o sobˇe nenab´ız´ı uspokojiv´e n´astroje a technologie ke splnˇen´ı poˇzadavk˚u komponentovˇe orientovan´eho programov´an´ı tak, jak jsme je popsali v pˇred-choz´ıch kapitol´ach.
Zde je pˇrehled nejz´asadnˇejˇs´ıch nedostatk˚u4 spojen´ych s pouˇzit´ım JAR soubor˚u jako jednotek nasazen´ı [4]:
• Nedostatky naˇc´ıt´an´ı zdroj˚u z classpath, moˇznosti konflikt˚u v pˇr´ıpadech, kdy se v aplikaci vyskytuje v´ıce tˇr´ıd se stejn´ym jm´enem. Classloader vˇzdy naˇcte prvn´ı verzi tˇr´ıdy dan´eho jm´ena, na kterou naraz´ı.
• Neobsahuj´ı metadata ukazuj´ıc´ı jejich z´avislosti.
• Slab´a podpora verzov´an´ı, nˇekolik r˚uzn´ych verz´ı nem˚uˇze b´yt spuˇstˇeno souˇcasnˇe.
Z v´yˇse uveden´ych d˚uvodu vznikla pro platformu Java specifikace OSGi, kter´a tyto probl´emy odstraˇnuje.
2.2.2 Architektura OSGi
Technologie OSGi je specifikace dynamick´eho modul´arn´ıho syst´emu pro plat-formu Java, kter´a implementuje dynamick´y komponentov´y model. Standard je definov´an a udrˇzov´an mezin´arodn´ım konsorciem OSGi Alliance zaloˇzen´ym v roce 1999. P˚uvodnˇe zkratka OSGi znamenala Open Services Gateway ini-tiative, dnes se vˇsak jiˇz nepouˇz´ıv´a a
”OSGi“ se stalo ochrannou zn´amkou.
OSGi umoˇzˇnuje instalaci, spouˇstˇen´ı, aktualizaci a odeb´ır´an´ı modul˚u za bˇehu, tedy bez nutnosti zastaven´ı JVM (Java Virtual Machine). D´ale pak definuje ˇzivotn´ı cyklus modulu a nab´ız´ı infrastrukturu pro spolupr´aci modul˚u
4Tyto nedostatky jsou tak znaˇcn´e, ˇze vzniklo pojmenov´an´ı
”JAR hell“.
Komponentov´e programov´an´ı Platforma OSGi
skrze sluˇzby. Implementac´ı specifikace tohoto modul´arn´ıho syst´emu je OSGi framework, viz 2.2.5.
Na obr´azku 2.3 je zn´azornˇena architektura OSGi a jej´ı jednotliv´e vrstvy.
Obr´azek 2.3: Vrstvy v OSGi [9]
N´asleduje v´yˇcet vrstev s jejich popisem [10]:
• Bundles – bundly jsou OSGi komponenty vytvoˇren´e program´atory.
• Services – vrstva sluˇzeb dynamicky propojuje vytvoˇren´e bundly – za-jiˇst’uje komunikaci bundl˚u.
• Life Cycle – vrstva staraj´ıc´ı se o ˇzivotn´ı cyklus bundl˚u – instalaci, spuˇstˇen´ı, zastaven´ı, update a jejich odinstalov´an´ı.
• Modules– je vrstva staraj´ıc´ı se o zapouzdˇren´ı bundl˚u a definuj´ıc´ı, jak m˚uˇze bundle exportovat a importovat k´od.
• Execution Environment – definuje, jak´e metody a tˇr´ıdy konkr´etn´ı platforma nab´ız´ı.
• Security – vrstva zab´yvaj´ıc´ı se aspekty bezpeˇcnosti.
Komponentov´e programov´an´ı Platforma OSGi
2.2.3 Komponenty v OSGi
V souvislosti se specifikac´ı OSGi nehovoˇr´ıme o komponentˇe nebo modulech, ale o tzv. bundle. Bundle je reprezentov´an JAR souborem, kter´y mus´ı ob-sahovat manifest s informacemi o bundlu. V manifestu se nach´azej´ı
speci-´
aln´ı hlaviˇcky obsahuj´ıc´ı informace, kter´e framework potˇrebuje k ´uspˇeˇsn´e in-stalaci a spuˇstˇen´ı bundlu. Manifest se nach´az´ı v JAR archivu na obvykl´e cestˇe:META-INF/MANIFEST.MF. Prostˇrednictv´ım manifestu lze tak´e nastavit, jak´e sluˇzby budou dostupn´e ostatn´ım bundl˚um. N´asleduj´ıc´ı seznam obsahuje nˇekter´e typick´e hlaviˇcky manifestu OSGi bundlu:
• Bundle-Name: Jm´eno bundlu (srozumiteln´e ˇclovˇeku).
• Bundle-SymbolicName: Jedineˇcn´y identifik´ator bundlu. Je to jedin´a po-vinn´a hlaviˇcka manifestu.
• Bundle-Description: Kr´atk´y popis funkcionality bundlu.
• Bundle-ManifestVersion: Urˇcuje verzi OSGi, kter´a se m´a pouˇz´ıt.
• Bundle-Version: Verze bundlu.
• Export-Package: Seznam bal´ık˚u (packages), kter´e jsou viditeln´e a k dis-pozici ostatn´ım bundl˚um.
• Import-Package: Seznam bal´ık˚u, kter´e bundle vyuˇz´ıv´a a vyˇzaduje pro svoji funkˇcnost.
Pˇr´ıklad jednoduch´eho manifestu se nach´az´ı ve v´ypisu 2.1.
D˚uleˇzitou vlastnost´ı bundl˚u je, ˇze kaˇzd´y m´a sv˚uj vlastn´ı zavadˇeˇc tˇr´ıd (classloader), coˇz pˇrisp´ıv´a k vz´ajemn´e izolaci bundl˚u a tedy modularitˇe cel´e aplikace.
Komponentov´e programov´an´ı Platforma OSGi
Bundle−Name : H e l l o World
Bundle−SymbolicName : c z . zcu . k i v . h e l l o W o r l d Bundle−D e s c r i p t i o n : H e l l o World b u n d l e Bundle−M a n i f e s t V e r s i o n : 2
Bundle−V e r s i o n : 1 . 0 . 0
Export−Package : c z . zcu . k i v . h e l l o W o r l d ; v e r s i o n = ”1 . 0 . 0 ” Import−Package : o r g . o s g i . framework ; v e r s i o n = ”1 . 3 . 0 ”
V´ypis 2.1: Manifest OSGi bundlu
2.2.4 Zivotn´ı cyklus bundlu ˇ
Vrstva Life Cycle se star´a o ˇzivotn´ı cyklus bundlu, kter´y je zobrazen na obr´azku 2.4.
Obr´azek 2.4: ˇZivotn´ı cyklus bundlu [4]
Komponentov´e programov´an´ı Platforma OSGi
Stavy, ve kter´ych se m˚uˇze bundle nach´azet:
• INSTALLED – bundle byl ´uspˇeˇsnˇe nainstalov´an.
• RESOLVED – bundle je bud’ pˇripraven ke spuˇstˇen´ı (vˇsechny z´avislosti jsou splnˇeny a zdroje k dispozici), a nebo byl zastaven.
• STARTING – spouˇstˇen´ı bundlu, je zavol´ana metodastart()rozhran´ı BundleActivator.
• ACTIVE – bundle byl ´uspˇeˇsnˇe aktivov´an a bˇeˇz´ı, metodastart() pro-bˇehla ´uspˇeˇsnˇe.
• STOPPING – zastavov´an´ı bundlu. Je zavol´ana metoda stop() roz-hran´ıBundleActivator.
• UNINSTALLED – bundle byl odinstalov´an, koneˇcn´y stav.
2.2.5 OSGi framework
V souˇcasn´e dobˇe existuje nˇekolik na sobˇe nez´avisl´ych open source implemen-tac´ı standardu OSGi [4].
• Equinox – je zˇrejmˇe nejrozˇs´ıˇrenˇejˇs´ı OSGi framework [4], je souˇc´ast´ı v´yvojov´e platformy Eclipse. Equinox implementuje specifikaci OSGi 4.1 a je licencov´an pod Eclipse Public License (EPL).
• Knopflerfish – dalˇs´ı popul´arn´ı implementace OSGi, kter´a implementuje jak OSGi 3, tak OSGi 4. Framework je vyv´ıjen spoleˇcnost´ı Makewave a je licencov´an pod BSD licenc´ı. Existuje i komerˇcn´ı verze Knopflerfish Pro.
• Apache Felix – mal´a a velmi kompaktn´ı implementace OSGi 4.x. Felix je vyv´ıjen neziskovou spoleˇcnost´ı Apache Software Foundation a licen-cov´an pod Apache License Version 2.0.
Komponentov´e programov´an´ı Spring
• Concierge – je velmi kompaktn´ı a vysoce optimalizovan´a implementace OSGi Release 3, kter´a je urˇcena zejm´ena pro platformy s omezen´ymi zdroji, jako jsou mobiln´ı telefony nebo embedded zaˇr´ızen´ı. Concierge je licencov´an pod BSD licenc´ı.
2.2.6 Sluˇ zby
Moduly spolu mohou komunikovat kromˇe sd´ılen´ı Java bal´ık˚u, kter´e je rea-lizov´ano nastavov´an´ım viditelnosti v manifestu (hlaviˇcky Export-Package a Import-Package), i pomoc´ı sluˇzeb. Pˇr´ıstup ke sluˇzbˇe je definov´an pomoc´ı Java rozhran´ı, kter´e pˇredstavuje kontrakt mezi poskytovatelem a klientem.
Poskytovatel sluˇzby registruje sluˇzbu do registru sluˇzeb. Naopak klient vyu-ˇ
z´ıv´a registr k vyhled´an´ı poˇzadovan´e sluˇzby a jej´ı n´asledn´e vyuˇzit´ı. O zajiˇstˇen´ı tohoto mechanizmu se star´a vrstva Service Layer.