Modelování existujících OSGi komponent

Modelování existujících OSGi komponent Lukáš Valenta, Přemysl Brada Katedra informatiky a výpočetní techniky, FAV, ZČU Západočeská univerzita, Univerzitní 22, 30100, Plzeň lvalenta@kiv.zcu.cz, brada@kiv.zcu.cz Abstrakt. Pohlížíme-li na komponenty jako na zapouzdřené objekty, pracujeme pouze s jejich rozhraním. Toto rozhraní je možno formálně popsat nějakým modelem a pracovat tak s abstraktní reprezentací rozhraní komponenty. Při skládání komponentové aplikace lze tedy s výhodou používat tuto reprezentaci. Často se však setkáváme se situací, kdy je potřeba do modelu zahrnout komponentu získanou(typicky zakoupenou) od třetí strany většinou pak nemáme k dispozici zdrojový kód ani dostačující technickou dokumentaci. Modelovou reprezentaci takové komponenty je pak potřeba získat přímo z její distribuční formy. Tento článek shrnuje naše zkušenosti a problémy s tímto postupem pro komponentový model OSGi. Klíčová slova: OSGi, komponenta, rozhraní, model, Objekty 1 Úvod Existuje několik průmyslově používaných platforem pro komponentové programování Enterprise JavaBeans(EJB) [14], CORBA Component Model [9], OSGi[11], Robocop[10] a například také portlety[8]. Všechny používají pojem komponenta vesmyslučástiaplikace,kteroujemožnésamostatněnasadit, aktualizovat a(v run-time) referencovat. Obvyklý obsah pojmu[13] je ale poněkud širší, neboť zahrnuje také vlastnost, že komponenta je černá skříňka s explicitně definovanými rozhraními a závislostmi na okolí. V tomto článku chceme diskutovat, jak se s tímto chápáním komponenty vypořádává OSGi framework, a ukázat, s jakými obtížemi se lze setkat v případě, kdy z existující komponenty chceme získat kompletní informace o jejím rozhraní. 2 Reprezentace rozhraní komponent Cílem komponentového programování je, aby většina využití komponent byla ve formě čistého re-use bez znalosti vnitřní implementace. Z tohoto důvodu potřebujeme velmi často pracovat s popisem jejich vnějšího rozhraní nebo také povrchu proúčelyzakomponovánídoexistujícínebovyvíjenéaplikace(tj.nikoli za účelem jejího vlastního vývoje). Typickou ukázkou je modelování aplikací

v diagramu komponent či tříd v UML2, kde je abstrahováno od vnitřní struktury komponent a jsou naopak zdůrazněny vazby mezi nimi, případně mezi komponentami a implementačními třídami aplikace, které je využívají. Poměrně často cd: Sample Application << component, UI >> StudentAdministration Student << component >> Student Persistence Student Persistence << component >> Database JDBC << component, infrastructure >> Persistence JDBC Obr. 1. Ukázkový UML2 diagram komponent se můžeme dostat do situace, kdy potřebujeme do modelu zahrnout komponentu získanou(typicky zakoupenou) od třetí strany; v takovém případě je nepravděpodobné, že bychom měli přístup ke zdrojovému kódu, a technická dokumentace nemusí být dostačující. Potřebovali bychom tedy provést jakousi reverzní analýzu distribuční podoby komponenty pro získání popisu jejího rozhraní. Tento popis typicky zahrnuje dvě množiny prvků(rozhraní, služeb, atributů, událostí, atd., dle možností použitého komponentového modelu): jednak ty, které jsou komponentou poskytovány okolí tzv. provides část, a za druhé ty, které ona sama vyžaduje od okolí pro svoji funkčnost tzv. requires část. 2.1 Praktické aspekty Problém nastává pokud model rozhraní, který máme k dispozici, neobsahuje všechny prvky komponentou skutečně poskytované či vyžadované. V takovém případě jej buďto musíme doplnit ručně, nebo pracovat s neúplným modelem za cenu nepřesností a možných komplikací, které se objeví až za běhu výsledné aplikace. Dalo by se očekávat, že model získaný automatickou analýzou distribuční podoby komponenty bude kompletní, tak jako je nutně kompletní sama distribuovaná komponenta. Moderní komponentové platformy obvykle používají nějakou formu deklarativního popisu komponenty(deployment descriptor u EJB, soubor manifestu u OSGi) a zároveň takové implementační jazyky, které obsahují mechanismus introspekce(java, C#). To dává šanci zjistit o komponentě vše potřebné až na úroveň jednotlivých tříd, metod a datových typů.

Naše zkušenosti bohužel potvrzují spíše opak. V následující části článku chceme ukázat na příkladu OSGi, jaké prvky rozhraní je potřeba mít k dispozici pro kompletní modelování komponenty a jakým způsobem lze které z nich získat. Zejména se pak budeme zabývat technicky pokročilými technikami a obtížemi, se kterými je spojeno získávání informací o některých z nich. 3 Komponentová platforma OSGi OSGi[11] je otevřená platforma umožňující nasazení a správu služeb. Původně byla jejím hlavním cílem oblast mobilních a zabudovaných(embedded) zařízení, v současné době ale tato komponentová architektura slouží i jako základ celých enterprise informačních systémů či například vývojových prostředí[6, 7]. Jádro platformy OSGi tvoří tzv. OSGi Framework(v jiných komponentových modelech se obvykle nazývá kontejner), který vytváří běhové prostředí umožňující nasazení a provoz aplikací(komponent) nazývaných bundle. V tomto článku se budeme zabývat modelováním právě těchto komponent OSGi bundles. 3.1 OSGi Bundle OSGi bundle je softwarová komponenta obsahující Javovské třídy tvořící vlastní implementaci a další pomocné zdroje, které společně poskytují funkcionalitu pro své klienty. Komponenty mohou sdílet Javovské balíky mezi exportéry a importéry mohou vznikat přesně definované vazby. Tento mechanismus umožňuje komponentě přistupovat k třídám poskytnutým komponentou jinou. Nejdůležitějším aspektem OSGi jsou však služby, přístupné přes Java rozhraní. Myšlenka celé architektury je založena na množině nezávislých komponent, které si mohou v centrálním registru běhového prostředí registrovat služby, které poskytují a naopak hledat služby, jež od svého okolí vyžadují. Bundle připravený k nasazení(distribuční forma) je ve formě JAR archivu. Tento soubor obsahuje: veškeré zdroje nutné k běhu obsaženého OSGi bundle, tedy přeložené Javovské třídy, HTML soubory, nápovědu, ikony atd. manifest souborpopisujícíobsaharchivu( deskriptor ).Hlavičkytohoto souboru specifikují informace, které OSGi Framework potřebuje pro úspěšné nasazení a spuštění komponenty. V okamžiku nasazení vyřeší Framework všechny vnější závislosti specifikované v manifestu a propojí importéry se správnými exportéry. Po spuštění komponenty jsou jí poskytované služby zpřístupněny i ostatním komponentám v daném prostředí.

4 Zjišťování prvků rozhraní OSGi komponent Mluvíme-li o modelování rozhraní komponent nějakého konkrétního komponentového modelu, musíme nejdříve prostudovat jeho specifikaci za účelem zjištění všech funkcí a vlastností, které překračují pomyslnou bariéru zapouzdření komponenty 1.NámizkoumanýmodelOSGiveverzi4specifikujemožnédruhyprvků rozhraní komponent uvedené v tabulce 1. Oproti jiným komponentovým modelům(např. EJB) je jejich počet poměrně malý. Název Role Popis export types Poskytovaný Java typy exportované touto komponentou import types Vyžadovaný Java typy touto komponentou vyžadované export services Poskytovaný Služby, které komponenta poskytuje ostatním import services Vyžadovaný Služby, které komponenta vyžaduje od okolí native code Vyžadovaný Vyžadované systémové knihovny require bundles Vyžadovaný Komponenta požaduje jiný celý bundle required exec env Vyžadovaný Podporované běhové prostředí(jedno či více) Tabulka 1. Druhy prvků rozhraní komponent OSGi Při vytváření abstraktní reprezentace rozhraní konkrétní komponenty je třeba získat z její distribuční formy(tedy ze zmíněného JAR archivu) informace o těch prvcích z výše uvedených, které komponenta opravdu poskytuje/vyžaduje. Následujícíkapitolyukazují,žeučástiznichjetoobtížnéažzcelanemožné. 4.1 Bezproblémové části rozhraní Nejprve uvedeme části rozhraní komponent OSGi, jejichž získání je bezproblémové. Jejich formální popis existuje v manifestu a obsahuje všechny potřebné informace. Jedná se o seznam vyžadovaných systémových knihoven(native code), běhových prostředí (required execution environment) a vyžadovaných bundle (require bundles), jak je ilustrováno na následujícím fragmentu manifest souboru: Bundle-RequiredExecutionEnvironment: OSGi/Minimum-1.1 Bundle-NativeCode: lib/http.dll; lib/zlib.dll; osname = Windows98; osname = WindowsNT; processor=x86 ; lib/linux/libhttp.so; osname=linux; 1 Jakbylozmíněnovúvodu nakomponentupohlížímejakonačernouskříňku,známe pouze její rozhraní.

processor = mips Require-Bundle: cz.zcu.example;resolution:=optional U následujících částí rozhraní již není zjištění všech podstatných informací takto triviální. 4.2 Exportované typy V manifestu JAR souboru slouží k popisu exportovaných typů hlavička Export- Package. Specifikovány jsou tedy celé Java balíky, pro potřeby modelování je všakpotřebapřejítojednuúroveň níž kekonkrétnímjavatřídámarozhraním 2. Bundle-Name: A Export-Package: cz.zcu.logging; version=1.3.0; exclude=cz.zcu.logging.invisible Bundle uvedený na příkladu exportuje celý Java balík cz.zcu.logging tedy všechny třídy a rozhraní definované jako public kromě třídy Invisible. Získání seznamu exportovaných tříd je poměrně jednoduché vzhledem k tomu, žecelýbalíkmusíbýtvjararchivupřítomen.jetřebaprojítcelýadresář a každou veřejnou javovskou třídu, která vyhovuje podmínkám include/exclude, do seznamu zařadit. Zda je třída veřejná lze zjistit instrospekčním mechanismem použitím Java Reflection API[15]. V tomto případě obsahuje distribuční forma komponenty tedy kompletní informaci o tomto poskytovaném prvku rozhraní introspekčním mechanismem je možno získat kompletní typovou informaci(jednotlivé metody, parametry,...),je-lipotřeba 3.Jakuvidímedále,zdalekanevždylzetaktokompletníinformace získat. 4.3 Importované typy Deklarace importovaných balíků u OSGi komponent slouží podobnému účelu, jako systémová proměnná CLASS PATH u běžných Javovských aplikací. Pouze určujezávislostikomponentyna knihovních (vyžadovaných)balících.výhodou oproti zmíněnému CLASS PATH je u OSGi samozřejmě nezávislost na umístění, komponentasenemusízajímatoto,odkudsepotřebnébalíky vezmou,toto zajistí OSGi Framework automaticky. Navíc dokáže řešit složitější podmínky a nároky kladené na exportovaná rozhraní, například požadovanou verzi, shodnost parametrů atd. Zjištění importovaných typů je na první pohled velice podobné typům exportovaným: 2 Užjen proto, žespecifikace OSGi umožňujekespecifikaci exportovanéhobalíku přidat seznam tříd z exportu vyloučených proto je lepší hovořit o seznamu tříd, nežo neúplném balíku. 3 Napříkladpřiurčovánípodtypovérelacemezidvěmakomponentami přiověřování jejich nahraditelnosti.

Bundle-Name: B Import-Package: cz.zcu.logging; version=[1.1.5, 2) Oproti nim je zde však jeden podstatný rozdíl: nikde není explicitně specifikovánapřesná podoba vyžadovanýchtřídarozhraní.vmanifestujespecifikován pouze název Java balíku, kompletní informace o obsažených typech k dispozici není. Podobuvyžadovanýchtypů(metodajejichhlaviček...)tak,jakjepředpokládá a s nimi pracuje komponenta B, bychom zjistili z exportující komponenty, tu ale obecně nemáme k dispozici. Musíme tedy použít informace z naší komponenty samotné: představu lze získat analýzou jejího přeloženého programového kódu. Je potřeba zjistit, jaké používá třídy, k čemuž je potřeba nejen introspekčního mechanismu, ale i přímé analýzy Java.class souborů. Výsledný postup lze slovy popsat jako rekurzivní procházení všech interních tříd zkoumané komponenty a hledání referencí na třídy, které náleží do balíků specifikovaných v Import-Package hlavičce: 1. Nechť List je množina názvů tříd, které ještě nebyly analyzovány. Nechť P arsed je množina názvů tříd, které již byly analyzovány. 2. List={NázevtřídyBundle-Activator }(tj. hlavní třídaosgibundle) Parsed=. 3.Nechť Class List(výběrjednétřídy), List=List \ {Class}, Parsed=Parsed {Class}. (a) Pokud třída Class náleží do tohoto OSGi bundle, analyzuj její byte-kód. Do List přidej všechny nalezené reference na jiné třídy nebo rozhraní (pouzepokudjižnejsouvparsed).jdinakrok4. (b) Patří-li třída do některého z balíků specifikovaných v hlavičce Import-Package, ulož její jméno do vytvářené abstraktní reprezentace této komponenty(jako import type). Jdi na krok 4. (c) Neplatí-li možnost(a) ani(b), třídu ignoruj(může se jednat například o knihovní třídu Javy). 4.Je-li List=,ukončiproces.Vopačnémpřípadějdinakrok3. Uvedený postup není ze své podstaty zcela spolehlivý, ale ve většině případů dává správné výsledky. Jeho výhodou je fakt, že nalezneme pouze ty třídy, které komponenta skutečně používá a nikoli všechny, které jsou jinou komponentou exportovány. Hledáníreferencínapoužívanétřídynenívzhledemkestruktuře.class 4 souborů tak obtížné, jak by se mohlo zdát. Soubory obsahují tabulky používaných konstant, řetězců, názvů metod, tříd a dalších důležitých údajů a stačí tedy procházet tyto tabulky bez nutnosti analýzy například jednotlivých instrukcí vlastního kódu. V naší prototypové implementaci tento algoritmus používá knihovnu The Byte Code Engineering Library(BCEL)[1]. 4 Souborůobsahujícíchpřeloženýkódkomponenty Javabyte-code

4.4 Služby Důležitou součástí rozhraní OSGi komponent jsou služby(services). Bohužel, právě tato důležitá vlastnost není žádným způsobem formálně specifikována. Narozdíl od Export-Package či Import-Package diskutovaných výše, o službách, které OSGi komponenta požaduje či poskytuje, není například v manifest souboru taková informace žádná. Veškeré operace se službami, včetně jejich publikování a vyhledávání, probíhají pouze ve vlastním kódu komponenty, tedy uvnitř pomyslné černé skříňky, za kterou komponentu považujeme. Způsob práce se službami je ilustrován v následujících ukázkách kódu. Registrace poskytované služby: BundleContextbc =...;/* muj BundleContext*/ /* ziskani objektu implementujiciho rozhrani sluzby*/ serviceimpl = new MyServiceImplementation(); /* registrovani sluzby - nazvem sluzby je nazev jejiho rozhrani */ bc.registerservice( MyServiceInterface.getName(), serviceimpl, new Hashtable()); Vyhledání a získání reference na vyžadovanou službu: /* nalezeni reference na sluzbu*/ ServiceReference sr = bc.getservicereference( MyServiceInterface.getName()); /* ziskani reference na sluzbu */ MyServiceInterface = (MyServiceInterface) bc.getservice(sr); /* volani metody poskytovane sluzbou*/ sr.servicemethod(...); /* uvolneni sluzby */ bc.ungetservice(sr); Postup použitý pro hledání referencí na používané třídy(viz sekce 4.3) nelze v tomto případě použít. Lehce modifikovaným postupem lze pouze odhalit, že třída volá nějakou konkrétní metodu (například BundleContext. registerservice()), což svědčí pouze o tom, že bundle pravděpodobně nějakou službu registruje. Další potřebné údaje(název služby, její rozhraní) již nenímožnézjistit,protožeparametrytétometodyjsoujižzcela skryty ve vlastním kódu komponenty a obecně je nelze určit. Stejný problém nastává i při určování služeb, které komponenta ke svému běhu potřebuje.

4.5 Shrnutí Komponentový model OSGi trpí, stejně jako i další průmyslově používané modely(např. EJB[14]), nedostatečným formálním popisem rozhraní komponent. Největší problém vidíme v absenci popisu komponentou vyžadovaných a poskytovaných služeb, protože se jedná o základ a princip celé architektury. Abstraktní reprezentace komponenty OSGi, získaná výše uvedenými automatickými postupy, proto bohužel postrádá de-facto nejdůležitější součást a jak jsme v předchozích kapitolách ukázali, informace nelze z distribuční formy získat žádným způsobem. Ale ani ostatní části rozhraní, kromě triviálních prvků(viz sekce 4.1), nejsou z tohoto pohledu bezchybné. Informace, které by měly být deklarativně přímo přístupné například v manifest souboru, se musejí složitě a ne vždy zcela spolehlivěhledatintrospekcíčiještěhlubšíanalýzou hotové formykomponenty. V naší práci využíváme pro abstraktní reprezentaci rozhraní softwarové komponenty ENT metamodel[4], jehož prototypová implementace nám umožňuje provádět nad reprezentacemi konkrétních komponent další operace(pro ilustraci viz obrázek 2). Především se zaměřujeme na ověřování nahraditelnosti softwarových komponent[5], konkrétní aplikací pro OSGi je nástroj pro automatické generování identifikátorů verzí nových revizí komponenty na základě analýzy změn v jejím rozhraní[16, 17]. Každé takové využití reprezentace rozhraní ovšem trpí neúplností informací, které je možné o komponentě získat. Obr. 2. Vytvoření modelu rozhraní a jeho použití 5 Závěr Na problém s nedostatečnými nebo chybějícími(formálními) popisy softwarových komponent je ukazováno v práci[2]. Autoři představují model a metriky

kvality komponent a v rozsáhlé případové studii analyzují množství komponent veformě,vjakéjemožnojezakoupitnatrzíchkomponent.vzávěrupráce upozorňují na fakt, že mnoho důležitých informací o komponentě není zákazníkovi k dispozici(a to ani nemluvíme o jejím formálním popisu, ale o libovolném zdroji informací návody, tutoriály...). Druhým významným závěrem je srovnánísmnožinoukomponent,kekterýmměliautoři plný přístup(zdrojové kódy...).tatomnožinadopadlaopoznánílépe vidíme,žeinformacekdispozici jsou, ale nejsou poté k dispozici v nějaké podobě(nejlépe formalizované) při distribuci komponent. Na směr, kterým se bude zřejmě komponentový výzkum dále ubírat, tedy na pokročilejší formální popisy jak rozhraní komponent, tak i jejich protokolů, chování, výkonových charakteristik atd., ukazují i další současné práce prezentované na konferencích věnovaných komponentovým systémům[3, 12]. Ukazuje se, že požadavky na komponentové programování kladené a především jeho očekávané přínosy(re-use, možnost update/upgrade komponenty za běhu aplikace a související přísné kontroly kompatibility, striktní black-box pohled na jednotlivé komponenty,...) jsou stále spíše v rovině teoretické. Současné průmyslově používané komponentové modely se soustřeďují spíše na implementační aspekty a spektrum podporovaných služeb(transakce, persistence, transparentní distribuovatelnost...). Námi prezentovaný pohled na OSGi ukazuje, že se jedná spíše o dobře navrženou běhovou architekturu či přesně specifikované běhové prostředí pro provoz nezávislých aplikací v jedné JVM, než o komponentový model s dobře definovanými(tj. formálně popsatelnými) rozhraními komponent, nemluvě o dalších zmíněných aspektech protokoly, chováním atd. v případě, že by další verze specifikace již nutily vývojáře s komponentou distribuovat i tyto modely, bylo by vyřešeno mnoho problémů, se kterými se nyní uživatelé OSGi potýkají. Reference 1. The Byte Code Engineering Library, http://jakarta.apache.org/bcel/. 2. Alexandre Alvaro, Eduardo Santana de Almeida, Silvio Lemos Meira, a Software Component Quality Model: a Preliminary Evaluation, In proceedings of 32nd EuroMicro conference, 0-7695-2594-6, 2006. 3. Egor Bondarev, Michel R.V. Chaudron, Compositional Performance Analysis of Component-Based Systems on Heterogeneous Multiprocessor Platforms, In proceedings of 32nd EuroMicro conference, 0-7695-2594-6, 2006. 4. P. Brada. The ENT model: a general model for software interface structuring. Technical Report DCSE/TR-2002-10, Department of Computer Science and Engineering, University of West Bohemia, Pilsen, Czech Republic, 2002. 5. P. Brada. Specification-Based Component Substitutability and Revision Identification, PhD thesis, Department of Computer Science, University of Western Bohemia, Pilsen, Czech Republic, 2003, http://www.kiv.zcu.cz/ brada/research/thesis/. 6. Eclipse, an open development platform, http://www.eclipse.org/. 7. IBM, Rational Application Developer, http://www-128.ibm.com/developerworks/rational/products/rad/.

8. Java Community Process, Java Portlets Specification, http://jcp.org/aboutjava/communityprocess/final/jsr168/. 9. Object Management Group, CORBA Component Model, V3.0, http://www.omg.org/technology/documents/formal/components.htm. 10. Ronan Mac Laverty, ROBOCOP Revised specification of framework and models, 2003, http://www.hitech-projects.com/euprojects/robocop/deliverables.htm 11. The OSGi Alliance. OSGi Service Platform Core Specification, Release 4, August 2005, available at http://www.osgi.org/. 12. Gernot Schmoelzer, Egon Teiniker, Christian Kreiner, Michael Thonhauser, Modeltyped Component Interfaces, In proceedings of 32nd EuroMicro conference, 0-7695- 2594-6, 2006. 13. Clemens Szyperski. Component Software. ACM Press, AddisonWesley, 1998. 14. SunMicrosystems.EnterpriseJavaBeans TM Specification,Version2.1,2003, available at http://java.sun.com/products/ejb/. 15. Sun Microsystems, Java Reflection API, http://java.sun.com/j2se/1.5.0/docs/guide/reflection/index.html. 16. L. Valenta, P. Brada. Automated generating of OSGi component versions. In proceedings of ECI 2006 conference, 80-8073-598-0, 2006. 17. L. Valenta, P. Brada. OSGi Component Substitutability Using Enhanced ENT Metamodel Implementation. Technical Report DCSE/TR-2006-05, Department of Computer Science and Engineering, University of West Bohemia, Pilsen, Czech Republic, 2006.