Příklad iPOJO komponenty

Instance iPOJO a její kontejner

Kompozice

Zajímavou vlastností iPOJO je možnost vytváření kompozic, tj. aplikací agregujících několik bundlů a schopných určit rozsah viditelnosti (propagace) jejich služeb. Prakticky řečeno lze nastavit, které služby budou dostupné jen uvnitř kompozice a které budou uveřejněny i pro bundly vnější vzhledem ke kompozici (více zde). V příkladu na obrázku je služba Dictionary Service dostupná pouze uvnitř kompozice, zatímco služba komponenty Checker je propagována vně kompozice.

Příklad kompozice

Kompozice je možné definovat pouze v XML deskriptoru (element composite), nikoli pomocí anotací. Možnosti definice metadat je ale možné kombinovat, takže není problém používat anotace na vše ostatní a pouze kompozici definovat pomocí XML. S kompozicí se dále zachází podobně jako s komponentovým typem ve smyslu instancování a poskytování služeb.

Dále je pak možné skládat kompozice kompozic a dalších bundlů a tím dosáhnout hierarchické struktury celé agragace, na jejíž každé úrovni je možné omezit propagování služeb za její hranici. Příklad na obrázku ilustruje takovou situaci.

Příklad hierarchické kompozice

Možnosti customizace

Možností vlastních úprav komponentového modelu iPOJO je definování vlastních handlerů (včetně vlastních anotací). Podrobné informace o tomto tématu naleznete zde. Handler komunikuje s kontejnerem komponenty, POJO, ostatními komponentami, službami, bundly, OSGi frameworkem, atd. Prvním krokem k vytvoření vlastního handleru je implementace Java třídy rozšiřující abstraktní třídu PrimitiveHandler ze základního balíku iPOJO. Dále nad hlavičku této třídy je nutné přidat anotaci @Handler s atributy pro jméno (název anotace, kterou se bude handler označovat) a jmený prostor (balík handleru). Handler funguje (téměř) jako jakýoli komponentový typ ve smyslu, že používá další handlery, požaduje a poskytuje služby, atd. Dalším krokem vytvoření vlastního handleru je implementace/překrytí metod abstraktní třídy. Obrázek znánzorňuje životní cyklus handleru pro ilustraci funkcí metod.

Životní cyklus handleru

Metody abstraktní třídy PrimitiveHandler, které je třeba překrýt:

• configure()
  • volána po inicializaci handleru metodou initializeComponentFactory()
  • kontroluje handler a a konfiguruje vlastnosti (properties) specifické pro instanci
• start()
  • volána po konfiguraci handleru
  • spouští handler, obsahuje aktivační kód
  • stav po handleru po startu je active, pokud jsou ve stejném stavu všechny jím využívané handlery
  • následně handler přechází do stavu valid nebo invalid v závislosti na stavech jím využívaných handlerů
• stop()
  • volána při zastavování handleru (před likvidací jeho instance)
  • zastavuje handler, obsahuje deaktivační kód
  • volá se po zastavení (ne zničení) instance komponentovho typu, která handler využívá, tudíž pokud bude restartována bude potřebovat opět stejnou instanci handleru

Metody abstraktní třídy PrimitiveHandler, které je možné překrýt/rozšířit/využít:

• initializeComponentFactory()
  • volána, když framework zjistí použití handleru
  • kontroluje validitu popisu komponentového typu, aby nebyly spuštěny nevalidní factories
• setValidity()
  • nastavuje stav na valid nebo invalid

Handler je pak možné používat přidáním v XML deskriptoru (viz odkaz výše) nebo pomocí definování anotace. Anotaci je možné definovat vytvořením Java souboru s následující hlavičkou:

    public @interface JmenoHandleru {

Zde je podle potřeby možné definovat atributy anitace formou atributů Java třídy. Poté lze handler snadno používat v komponentových typech použitím jeho anotace (popř. s atributy). Pro funkčnost je samozřejmě nutné nasadit bundle s handlerem před spuštěním aplikace, která ho používá. Návody na zpracování konfigurace handleru a instance, interakce s iPOJO frameworkem a další pokročilé techniky včetně 2 ilustračních příkladů, viz odkaz výše.

Komponenta

Komponenta je centrálním konceptem iPOJO. Komponentu jako samostatně nasaditelnou jednotku (ve smyslu definice z hlavní stránky této wiki) v iPOJO představuje bundle, stejně jako v OSGi. Tím vzniká menší konflikt v terminologii, jelikož iPOJO notace (v anotacích, XML, atd.) označuje slovem Component Java třídy, poskytující a požadující služby z jiných bundlů. Tyto třídy se pak také označují za komponentové typy (component types) nebo továrny (factories).

Bundle

Bundle je svazek komponentových typů (ideálně tématicky spřízněných) nasazovaný zároveň. Z programátorského pohledu je to vlastně Java projekt, který specifikuje imporotované (požadované) a exportované (poskytované) balíky. To určuje pouze jejich viditelnost pro ostatní bundly, ne přímo poskytování služeb. Balíky pak obsahují jednotlivé factory/komponentové typy (třídy), z nichž se tvoří instance (objekty). Ty pak poskytují/požadují služby (implementovaná rozhraní/metody, resp. objekty tříd typované na tyto rozhraní) a jejich vlastnosti (properties; proměnné).

Komponentový typ

V jádru iPOJO modelu komponentový typ popisuje závislosti služeb, poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponentového typu (třídy). Jelikož iPOJO staví na principu POJO (Plain Old Java Object; standardních Java tříd), komponentový typ v iPOJO reprezentuje třída označená jako component type (také označovaná jako factory) jedním ze tří základních způsobů - anotace přímo ve zdrojovém kódu, XML v speciálním souboru popisující iPOJO komponentové typy a nastavení (XML deskriptoru) nebo pomocí fluent API. Stejnými způsoby lze z component type vytvořit instanci. Instance komponentového typu je analogií k instanci třídy v objektovém programování.

Instance jejich životní cyklus

Instance mají ke komponentovým typům (component type / factory) týž vztah, jako běžná Java instance ke třídám. Narozdíl od životního cyklu komponent (bundlů; stejný jako v OSGi) iPOJO instance mají velmi jednoduchý životní cyklus, který obsahuje pouze 2 stavy: INVALID a VALID. Po svém vytvoření může instance být validní pouze tehdy, pokud všechny její připojené handlery jsou validní. V nejzákladnějším případě to znamená, že všechny instancí požadované služby jsou dostupné. Například, instance požadující službu (a tím pádem používající dependency handler) nemůže být validní, pokud požadovaná služba není dostupná. Instance začíná a končí ve stavu INVALID (viz obr. níže).

Životní cyklus instance

Pro úspěšné spuštění instance je ovšem nutné aby všechny bundly poskytující jí služby byly ve stavu Resolved. Do něj framework převede všechny automaticky všechny takové instalované bundly. Problém nastává, pokud takový bundle závisí na dalším (a zřetězením případně dále), který není nainstalován, nebo nemůže být převeden do stavu Resolved. Tento případ končí výjimkou org.osgi.framework.BundleException: Unresolved constraint in bundle ....

Vytvoření instance lze vynutit okamžitě po přechodu komponenty (bundlu) do stavu ACTIVE atributem immediate=true anotace @Component (viz obr. níže). Vytvoření instance volá konstruktor (defaultní/prázný, pokud neexistuje jiný), čímž se v kombinaci s immediate de facto nahrazuje/duplikuje funkci anotace @Validate (viz níže). Rozdílem je, že konstruktor je volán pouze jednou (při vytvoření instance), zatímco validate callback je volán při každé validaci (spuštění).

Rozhraní (kontrakt)

Rozhraní je reprezentováno poskytovanými a požadovanými službami (metodami nebo promněnými, popř.: konstantami), které se v iPOJO specifikují stejnými způsoby zápisu jako komponentové typy (anotace, XML, fluentAPI). Služba je vlastně jakékoli rozhraní, které POJO reprezentující komponentový typ implementuje. Komponentový typ tak může poskytovat více služeb. Framework automaticky hledá všechny taková rozhraní a nadtřídy každého komponentového typu při instalaci bundlu.

Kompozice

Zajímavou vlastností iPOJO je možnost vytváření kompozic, tj. aplikací agregujících několik bundlů a schopných určit rozsah viditelnosti (propagace) jejich služeb. Prakticky řečeno lze nastavit, které služby budou dostupné jen uvnitř kompozice a které budou uveřejněny i pro bundly vnější vzhledem ke kompozici (více zde). V příkladu na obrázku je služba Dictionary Service dostupná pouze uvnitř kompozice, zatímco služba komponenty Checker je propagována vně kompozice.

Příklad kompozice

Kompozice je možné definovat pouze v XML deskriptoru (element composite), nikoli pomocí anotací. Možnosti definice metadat je ale možné kombinovat, takže není problém používat anotace na vše ostatní a pouze kompozici definovat pomocí XML. S kompozicí se dále zachází podobně jako s komponentovým typem ve smyslu instancování a poskytování služeb.

Dále je pak možné skládat kompozice kompozic a dalších bundlů a tím dosáhnout hierarchické struktury celé agragace, na jejíž každé úrovni je možné omezit propagování služeb za její hranici. Příklad na obrázku ilustruje takovou situaci.

Příklad hierarchické kompozice

Model

Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) model servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu v životním cyklu (např. PostRegistration, PostUnregistration callbacky při (od)registrování služby, nebo přechod instance na stav Valid a Invalid).

Framework

Komponentový framework je pak celé iPOJO, resp. iPOJO spojené s patřičnou implementací OSGi (viz technické detaily níže). Princip fungování závisí na 2 hlavních částech - kontejner a handler. Kontejner obklopuje obsah (implementace POJO objektů) a spravuje všechny jeho mimofunkční požadavky jako propojení s ostatními instancemi nebo zdroji, životní cyklus, atd. Kontejner je popsán v component type třídě (opět anotacemi, XML nebo API). Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každý handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponentového typu je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám (viz zde). Při běhu aplikace pak iPOJO runtime kombinuje funkční (implementace instancí) a mimofunkční (uchované v konfiguraci kontejneru) aspekty aplikace, odhaluje a "vstřikuje" (inject) požadované služby spojením metadat komponenty a konfigurace instance. Následně uveřejňuje (propaguje) poskytované služby a řídí životní cyklus komponenty.

Možnosti customizace

Možností vlastních úprav komponentového modelu iPOJO je definování vlastních handler (včetně vlastních anotací)

• význam: definuje, že třída je komponentovým typem (component type / factory)
• cíl: třída implementující komponentový typ

• pokud je použito stejné jméno komponentového typu v anotaci jako v XML souboru, XML definice má přednost, ale během manipulace se ukáže varování

• cíl: třída implementující komponentový typ

Komponentový typ

Komponentový typ (factory) stačí označit anotací @Component a v případě instancování i @Instantiate nad hlavičkou třídy. Obě anotací disponují atributem name pro pojmenování a dalšími možnostmi. Máli být instancování provedeno okamžitě po validaci, použijte atribut immediate=true anotace @Component (u komponentových typů neposkytujících služby je tato hodnota defaultní). Lze také vytvořit komponentový typ, která bude mít jedinou instanci (singleton) použitím atributu publicFactory=false opět na anotaci @Component. Anotacemi nelze vytvořit kompozity a využívat některých dalších možností iPOJO (viz výše).

Možné je též specifikovat vlastnosti služeb anotacemi @Property, @ServiceProperty a jejich atributy. Zajímavá je pak anotace @StaticServiceProperty pro statickou vlastnost všech služeb instance, užívaná v atributu properties anotace @Provides. Jedná se o další možnost rozlišování různých komponentových typů poskytujících stejné služby (např. implementujících stejné rozhraní).

• podporují: akquinet, Grenoble University, Bull (viz zde)
• success stories: Schneider Electric, Ubidreams, JOnAS (viz zde)

• hromadně pro všechny části - přes mvn install na pom.xml v kořenové složce (přeloží pouze podprojekty bundlů, ne Felix!)

Model - Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) model servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu v životním cyklu (např. PostRegistration, PostUnregistration callbacky při (od)registrování služby, nebo přechod instance na stav Valid a Invalid).

Oba příklady jsou vypracovány s maximální možnou podobností (až na několik drobných změn) jako jejich protějšky z kapitoly o OSGi pro snadné porovnání obou implementací. Kroky převodu implementačních principů z OSGi na iPOJO v příkladech použité jsou z většiny popsané v kapitole Rozdíly v implementaci oproti OSGi (viz výše). Oba příklady využívají anotace a Maven.

Instance mají ke komponentám (component type / factory) týž vztah, jako běžná Java instance ke třídám. Tam kde životní cyklus komponent odpovídá OSGi, iPOJO instance mají velmi jednoduchý životní cyklus, který obsahuje pouze 2 stavy: INVALID a VALID. Po svém vytvoření může instance být validní pouze tehdy, pokud všechny její připojené handlery jsou validní. V nejzákladnějším případě to znamená, že všechny instancí požadované služby jsou dostupné. Například, instance požadující službu (a tím pádem používající dependency handler) nemůže být validní, pokud požadovaná služba není dostupná. Instance začíná a končí ve stavu INVALID (viz obr. níže). Vytvoření instance lze vynutit okamžitě po přechodu komponenty do VALID stavu (jiný než VALID stav instance!) atributem immediate=true anotace @Component (viz obr. níže). Vytvoření instance volá konstruktor (defaultní/prázný, pokud neexistuje jiný), čímž se v kombinaci s immediate de facto nahrazuje/duplikuje funkci anotace @Validate (viz níže). Rozdílem je, že konstruktor je volán pouze jednou (při vytvoření instance), zatímco validate callback je volán při každé validaci (spuštění).

Atributy bundlů jako jméno, symbolické jméno, verze a další vedených v OSGi v manifestu je možné nahradit obdobnými elementy v Mavenu (pom.xml). Obdobně importované balíky jsou nahrazeny dependencies a exportované balíky pomocí elementu <Export-Package> viz následující příklad:

Rozhraní (kontrakt) - Rozhraní je reprezentováno poskytovanými a požadovanými službami (metodami nebo promněnými, popř.: konstantami), které se v iPOJO specifikují stejnými způsoby zápisu jako komponenta samotná. Služba je vlastně jakékoli rozhraní, které POJO reprezentující komponentu implementuje. Framework automaticky hledá všechny taková rozhraní a nadtřídy každé komponenty při instalaci bundlu.

Bundle - Bundle je svazek kompnent (ideálně tématicky spřízněných) nasazovaný zároveň. Z programátorského pohledu je to vlastně Java projekt, který specifikuje imporotované (požadované) a exportované (poskytované) balíky. To určuje pouze jejich viditelnost pro ostatní bundly, ne přímo poskytování služeb. Balíky pak obsahují jednotlivé factory/komponentové typy (třídy), z nichž se tvoří instance komponent (objekty). Ty pak poskytují/požadují služby (implementovaná rozhraní/metody, resp. objekty tříd typované na tyto rozhraní) a jejich vlastnosti (properties; proměnné).

Pozn.: Pro úplnost by bylo třeba přidat nad obě třídy ještě anotaci @Instantiate, nebo vytvořit instanci jiným způsobem.

Komponentu (factory) stačí označit anotací @Component a v případě instancování i @Instantiate nad hlavičkou třídy. Obě anotací disponují atributem name pro pojmenování a dalšími možnostmi. Máli být instancování provedeno okamžitě po validaci, použijte atribut immediate=true anotace @Component (u komponent neposkytujících služby je tato hodnota defaultní). Lze také vytvořit komponentu, která bude mít jedinou instanci (singleton) použitím atributu publicFactory=false opět na anotaci @Component. Anotacemi nelze vytvořit kompozity a využívat některých dalších možností iPOJO (viz výše).

• Základní příkazy:
  • výpis bundlů
    • lb
  • výpis instancí
    • instances
  • přidání bundlů
    • install file:cesta_k_bundlu/bundle.jar
  • spuštění bundlů
    • start id_bundlu (může být i více oddělených mezerou)
  • zastavení bundlů
    • stop id_bundlu (může být i více oddělených mezerou)
  • odstranění bundlů
    • uninstall id_bundlu
  • nápověda
    • help (příkaz)

    
@Component
    @Provides
    public class MyServiceImplementation implements MyService {
        //....
    }

    
@Component
    public class MyServiceConsumer {
        @Requires
        private MyService myservice;
        // stačí použít požadovanou službu jako obyčejnou proměnnou
    }

    
<build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Export-Package>
                            cz.zcu.kiv.ppicha.ipojo.parkoviste.brana
                        </Export-Package>
                    </instructions>
                </configuration>
            </plugin>
        ...

    
@Publishes(name="vysilac_parkoviste_mista", synchronous=true, topics="parkoviste/mista")
    Publisher vysilac_mista;

    @Publishes(name="vysilac_parkoviste_plne", synchronous=true, topics="parkoviste/plne")
    Publisher vysilac_plne;
    ...
    private void posliZpravu() {
        if (volnaMista == 0) {
	    vysilac_plne.send(new Properties());
        }
        Dictionary<Object, Object> properties = new Properties();
        properties.put("volnaMista", volnaMista);
        vysilac_mista.send(properties);
    }

    [@@Subscriber(name="prijmac_tabule_plne", topics="parkoviste/plne")
    public void prijmoutPlno(Event e) {
        println("Parkoviste plne!");
    }

    @Subscriber(name="prijmac_tabule_mista", topics="parkoviste/mista", dataKey="volnaMista", dataType="java.lang.Integer")
    public void prijmoutMista(Integer mista) {
        println("Zbyva mist : " + mista);
    }@]

Použití EventHandler nebo Listener obejktů a jejich registrace jako samostatných služeb pro správu událostí v OSGi je v iPOJO opět značně zjednodušeno. Je ale nutno přilinkovat k bundlům externí handler Event Admin Handler a balík org.osgi.service.event a dále na instanci Felix nasadit EventAdminHandler a EventAdmin bundly (vše dostupné na Maven repository). Poté stačí pro posílání událostí použít anotaci @Publishes s patřičnými atributy nad proměnou typu Publisher, nad kterou se poté volá jedno z metod pro posílání zpráv:

Oba příklady jsou vypracovány s maximální možnou podobností (až na několik drobných změn) jako jejich protějšky z kapitoly o OSGi pro snadné porovnání obou implementací. Kroky převodu implementačních principů z OSGi na iPOJO v příkladech použité jsou z většiny popsané v kapitole Rozdíly v implementaci oproti OSGi (viz výše).

Celý koncept práce s událostmi ilustruje obrázek níže. Pro více informací o Event Admin Handleru viz zde.

Zasílání a zpracování událostí v iPOJO

Rozdíly v implementaci oproti OSGi

Popisované rozdíly jsou demostrovány na implementaci iPOJO aplikací pomocí Maven a anotací. Pro další možnosti implementace (XML deskriptor, fluentAPI, Ant, atd.) možno konzultovat hlavní stránku iPOJO na Apache Felix nebo další zdroje uvedené na této wiki.

Nahrazení manifestu

Atributy bundlů jako jméno, symbolické jméno, verze a další vedených v OSGi v manifestu je možné nahradit obdobnými atributy (elementy) v Mavenu (pom.xml). Obdobně importované balíky jsou nahrazeny dependencies a exportované balíky pomocí elementu <Export-Package> viz následující příklad:

<build>

    <plugins>
        <plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <instructions>
                    <Export-Package>
                        cz.zcu.kiv.ppicha.ipojo.parkoviste.brana
                    </Export-Package>
                </instructions>
            </configuration>
        </plugin>
    ...

Komponenty

Komponentu (factory) stačí označit anotací @Component a v případě instancování i @Instantiate nad hlavičkou třídy. Obě anotací disponují atributem name pro pojmenování a dalšími možnostmi. Máli být instancování provedeno okamžitě po validaci, použijte atribut immediate=true anotace @Component (u komponent neposkytujících služby je tato hodnota defaultní). Lze také vytvořit komponentu, která bude mít jedinou instanci (singleton) použitím atributu publicFactory=false opět na anotaci @Component. Anotacemi nelze vytvořit více instancí jedné komponenty, kompozity a využívat některých dalších možností iPOJO (viz výše).

Služby

Poskytovanou služby stačí identifikovat anotací @Provides rovněž nad hlavičkou třídy. iPOJO automaticky najde všechny implementovaná rozhraní a rodičovské třídy a zpřístupní je. Požadovanou službu lze identifikovat anotací @Requires nad patřičnou proměnou, nebo @Bind nad metodou. Možné je využít specifikace a filtry (atributy anotace) pro upřesnění parametrů požadovaných služeb / metod / dat. U @Requires je navíc kombinací atributů optional=true a defaultImplementation specifikovat např. lokální implementaci (ve stejném bundlu) služby, která se má použít v případě, že nebude nalezen její jiný poskytovatel. Služby není nutné registrovat, ani jinak přidávat do kontextu, iPOJO to zařídí automaticky.

Vlastnosti

Možné je též specifikovat vlastnosti služeb anotacemi @Property, @ServiceProperty a jejich atributy. Zajímavá je pak anotace @StaticServiceProperty pro statickou vlastnost všech služeb komponenty, užívaná v atributu properties anotace @Provides. Jedná se o další možnost rozlišování různých komponent poskytujících stejné služby (např. implementujících stejné rozhraní).

Activator

Místo aktivátoru používaného v OSGi stačí použít callbacky identifikované anotacemi @Validate (ekvivalent start()), @Invalidate (ekvivalent stop()), @PostRegistration, @PostUnregistration and libovolně pojmenovanou metodou.

Události

Použití EventHandler nebo Listener obejktů a jejich registrace jako samostatných služeb pro správu událostí v OSGi je v iPOJO opět značně zjednodušeno. Je ale nutno přilinkovat k bundlům externí handler Event Admin Handler a balík org.osgi.service.event a dále na instanci Felix nasadit EventAdmin bundle (vše dostupné na Maven repository). Poté stačí pro posílání událostí použít anotaci @Publishes s patřičnými atributy nad proměnou typu Publisher, nad kterou se poté volá jedno z metod pro posílání zpráv:

• send(Dictionary d) pro obecné události,
• sendData(Object o) pro posílání dat.

Defaultní způsob zasílání událostí je asynchronní. Názorná ukázka zasílání událostí:

@Publishes(name="vysilac_parkoviste_mista", synchronous=true, topics="parkoviste/mista")

Publisher vysilac_mista;

@Publishes(name="vysilac_parkoviste_plne", synchronous=true, topics="parkoviste/plne")

Publisher vysilac_plne;

...

private void posliZpravu() {

    if (volnaMista == 0) {
	vysilac_plne.send(new Properties());
    }
    Dictionary<Object, Object> properties = new Properties();
    properties.put("volnaMista", volnaMista);
    vysilac_mista.send(properties);

}

Příjem událostí je realizován použitím anotace @Subscriber a jejími atributy přímo nad obslužnou metodou libovolného jména. Atributy lze specifikovat i která data ze zprávy potřebujeme, pokud jí nechceme zpracovávat celou. Opět následuje názorný příklad:

@Subscriber(name="prijmac_tabule_plne", topics="parkoviste/plne")

public void prijmoutPlno(Event e) {

    println("Parkoviste plne!");

}

@Subscriber(name="prijmac_tabule_mista", topics="parkoviste/mista", dataKey="volnaMista", dataType="java.lang.Integer")

public void prijmoutMista(Integer mista) {

    println("Zbyva mist : " + mista);

}

Attach:ParkovisteIpojo.zip.

Felix

Oba níže uvedené příklady obsahují instanci Felix frameworku konfigurovanou pro své potřeby pomocí Maven.

• Instalace: stačí spustit příkaz mvn install na pom.xml v podsložce Felix*.

• Základní příkazy
  • Výpis bundlů: lb
  • Výpis instancí: instances
  • Přidání bundlů: install file:cesta_k_bundlu/bundle.jar
  • Spuštění bundlů: start id_bundlu (může být i více oddělených mezerou)
  • Zastavení bundlů: stop id_bundlu (může být i více oddělených mezerou)
  • Odstranění bundlů: uninstall id_bundlu
  • Nápověda: help (příkaz)

Překlad příkladů

• hromadně pro všechny části - přes mvn install na pom.xml v kořenové složce (přeloží pouze podprojekty komponent, ne Felix!)
• postupně - přes mvn install na pom.xml v dané podsložce
• výsledné .jar soubory vždy ve složkách target v jednotlivých podsložkách

Příklad Message Printer

Attach:MessagePrinterIpojo.zip.

Příklad Parkoviště

Attach:ParkovisteIpojo.zip.

Instance jejich životní cyklus Instance mají ke komponentám (component type / factory) týž vztah, jako běžná Java instance ke třídám. Tam kde životní cyklus komponent odpovídá OSGi, iPOJO instance mají velmi jednoduchý životní cyklus, který obsahuje pouze 2 stavy: INVALID a VALID. Pon svém vytvoření může instance být validní pouze tehdy, pokud všechny její připojené handlery jsou validní. V nejzákladnějším případě to znamená, že všechny instancí požadované služby jsou dostupné. Například, instance požadující službu (a tím pádem používající dependency handler) nemůže být validní, pokud požadovaná služba není dostupná. Instance začíná a končí ve stavu INVALID (viz obr. níže). Vytvoření instance lze vynutit okamžitě po přechodu komponenty do VALID stavu (jiný než VALID stav instance!) atributem immediate=true anotace @Component (viz obr. níže). Vytvoření instance volá konstruktor (defaultní/prázný, pokud neexistuje jiný), čímž se v kombinaci s immediate de facto nahrazuje/duplikuje funkci anotace @Validate (viz níže). Rozdílem je, že konstruktor je volán pouze jednou (při vytvoření instance), zatímco validate callback je volán při každé validaci (spuštění).

Životní cyklus instance iPOJO komponenty

Okamžité vytvoření instance atributem immediate

Model - Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) model servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu v životním cyklu (např. PostRegistration?, PostUnregistration? callbacky při (od)registrování služby, nebo přechod instance na stav Valid a Invalid).

Pozn.: Pro úplnost by bylo třeba přidat nad obě třídy ještě anotaci @Instantiate, nebo vytvořit instanci jiným způsobem.

• význam: definuje, že třída je komponentou (component type / factory)
• cíl: třída implementující komponentu
• atributy: name, immediate, architecture, propagation, managedservice, factoryMethod, publicFactory

• význam: určuje, že komponenta poskytuje službu
• cíl: třída implementující komponentu
• atributy: specifications, strategy, properties

• význam: signalizuje závislost na službě jiné komponenty
• cíl: proměnná nebo parametr konstruktoru
• atributy: filter, optional, id, nullable, defaultimplementation, exception, policy, comparator, from, specification, proxy, timeout

• význam: definuje vlastnost služby
• cíl: proměnná
• atributy: name, value, mandatory

• význam: kontrola expozice (vystavení?) služby
• cíl: proměnná (Boolean)
• atributy: value, specification

• význam: definuje vlastnost
• cíl: proměnná, metoda, parametr konstruktoru
• atributy: name, value, mandatory

• význam: určuje metodu volanou při dokončení rekonfigurace
• cíl: metoda (se slovníkem jako vstupním argumentem)

• význam: určuje metodu pro binding
• cíl: metoda
• atributy: id, specification, aggregate, optional, filter, policy, comparator, from

• význam: určuje metodu pro unbinding
• cíl: metoda
• atributy: id, specification, aggregate, optional, filter, policy, comparator, from

• význam: určuje metodu volanou, když je aktualizována bound (vázaná) služba
• cíl: metoda
• atributy: id, specification, aggregate, optional, filter, policy, comparator, from

• význam: určuje callback vyvolaný při přechodu instance do stavu Valid životního cyklu
• cíl: metoda

• význam: určuje callback vyvolaný při přechodu instance do stavu Invalid životního cyklu
• cíl: metoda

• význam: určuje callback vyvolaný po registraci služby; callback musí mít hlavičku public void name(ServiceReference ref)
• cíl: metoda

• význam: určuje callback vyvolaný po odregistrování služby; callback musí mít hlavičku public void name(ServiceReference ref)
• cíl: metoda

• význam: deklaruje jednoduchou instanci (ekvivalentní k <instance component="..."></instance> v XML souboru)
• cíl: třída
• atributy: name
• nepodporuje konfiguraci, pojmenování a má pouze globální rozsah platnosti (tudíž nelze použít kompozici)

• Přidání bundlů: příkaz felix:install file:cesta_k_bundlu/bundle.jar.

Komponenta - Komponenta je centrálním konceptem iPOJO. V jádru iPOJO modelu komponenta popisuje závislosti služeb, poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponenty. Jelikož iPOJO staví na principu POJO (Plain Old Java Object; standardních Java tříd), komponentu v iPOJO reprezentuje třída označená jako component type (také označovaná jako factory) jedním ze tří základních způsobů - anotace přímo ve zdrojovém kódu, XML v speciálním souboru popisující iPOJO komponenty a nastavení (XML deskriptoru) nebo pomocí fluent API. Stejnými způsoby lze z component type vytvořit instanci. Instance komponenty je analogií k instanci třídy v objektovém programování.

• hromadně pro všechny části - přes mvn install na pom.xml v kořenové složce
• postupně - přes mvn install na pom.xml v dané podsložce
• výsledné .jar soubory vždy ve složkách target v jednotlivých podsložkách

Příklad Message printer - implementace: Attach:MessagePrinterIPOJO.zip.

• Překlad:

1. hromadně pro všechny části - přes mvn install na pom.xml v kořenové složce
2. postupně - přes mvn install na pom.xml v dané podsložce

• výsledné .jar soubory vždy ve složkách target v jednotlivých podsložkách

Instance Felix frameworku s nastavením pro iPOJO pomocí Maven: Attach:FelixIPOJO.zip.

• Instalace: stačí spustit příkaz mvn install na pom.xml.
• Spuštění: ze složky target přes příkazovou řádku spustit java -jar bin/felix.jar.
• Přidání bundlů: příkaz felix:install file:cesta_k_bundlu/bundle.jar.

Příklad Message printer - implementace: Attach:MessagePrinterIPOJO.zip.

Příklad Message printer - implementace: Attach:MessagePrinterIPOJO.zip.

• Instalace: stačí spustit příkaz mvn install na pom.xml.
• Spuštění: ze složky target přes příkazovou řádku spustit java -jar bin/felix.jar.
• Přidání bundlů: příkaz felix:install file:cesta_k_bundlu/bundle.jar.

Příklad MessagePrinter? - implementace: Attach:MessagePrinterIPOJO.zip.

Instalace: stačí spustit příkaz mvn install na pom.xml.

Spuštění: ze složky target přes příkazovou řádku spustit java -jar bin/felix.jar.

Přidání bundlů: příkaz felix:install file:cesta_k_bundlu/bundle.jar

Příklad MessagePrinter? - implementace: Attach:MessagePrinterIPOJO.zip

Instance Felix frameworku s nastavením pro iPOJO pomocí Maven: Attach:FelixIPOJO.zip.

• slajdy přednášky od Richarda S. Halla iPOJO: The Simple Life

Praktická část

Instance Felix frameworku s nastavením pro iPOJO pomocí Maven: Attach:FelixIPOJO.zip Instalace: stačí spustit příkaz mvn install na pom.xml Spuštění: ze složky target přes příkazovou řádku spustit java -jar bin/felix.jar Přidání bundlů: příkaz felix:install file:cesta_k_bundlu/bundle.jar

Příklad MessagePrinterOsgi pak dokumentuje jen technologicky specifické problémy. Výsledná implementace: Attach:MessagePrinterOsgi.zip

Příklad ParkovisteOsgi a specifikace jeho možné podoby pak dokumentuje jen technologicky specifické problémy. Výsledná implementace: Attach:ParkovisteOsgi.zip

• v XML deskriptoru metadata.xml v bundlu (podobně jako u OSGi) za pomoci kořenového elementu <iPojo> (příklady např. v Reference Card nebo dalších zdrojích dole na stránce)

Další znaky iPOJO

iPOJO funguje na jakékoli implementaci R4.1 OSGi a také na mnoha JVM jako Oracle JRockit, JamVM, Dalvik (Android) a Mika. Požaduje pouze J2ME Fondation 1.1 JVM. Díky tomu lze aplikace používat v mobilních a jiných zařízeních.

• @ServiceProperty

• @ServiceController

• @PostRegistration

• @PostUnregistration

Další anotace mohou být v externích handlerech, např. temporální závislosti nebo možnost vystavení instance jako JMX MBean. K použití externích anotací je nutné pouze přidat je do build path. Více informací o anotacích např. zde.

Instance iPOJO a její kontejner

Interakce služeb mezi iPOJO instancemi

Příklad iPOJO komponenty

Instance iPOJO a její kontejner

Interakce služeb mezi iPOJO instancemi

Příklad iPOJO komponenty

Hlavní znaky iPOJO

• komponenty jsou vyvíjeny jako POJO, bez závislostí a komplexní API
• použití anotací, XML nebo fluent API k deklarování komponent a instancí
• požadování a poskytování služeb bez vyžadování kódu za současné vysoké efektivity
• iPOJO aplikace jsou nativně odolné proti dynamizmu
• rozšiřitelnost a přizpůsobivost, možnost vlastní úpravy komponentového modelu
• iPOJO aplikace podporují dynamické adaptace a vykazují autonomní chování
• použití v různých zařízeních a oblastech (mobilní zařízení, domácí brány, JEE servery)
• jednoduchost použití - není nutno starat se o "skryté" technické služby a detaily bindingu, stačí se soustředit pouze na vlastní kód
• staví koncept služeb jako top-level, čímž poskytuje lepší znovupoužitelnost, dovoluje nahrazování jedné implementace za jinou a správu dynamizmu
• malý "footprint" - iPOJO Core má pouze cca 550KB

iPOJO používají

• akquinet, Grenoble University, Bull, Schneider Electric, Ubidreams, a další

Principem iPOJO je co největší oddělení funkčního od mimofunkčního kódu (dependency management, service provision, konfigurace, atd.).

Komponenta - Komponenta je centrálním konceptem iPOJO. V jádru iPOJO modelu komponenta popisuje závislosti služeb, poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponenty. Jelikož iPOJO staví na principu POJO (Plain Old Java Object; standardních Java tříd), komponentu v iPOJO reprezentuje třída označená jako component type jedním ze tří základních způsobů - anotace přímo ve zdrojovém kódu, XML v speciálním souboru popisující iPOJO komponenty a nastavení (XML deskriptoru) nebo pomocí fluent API. Stejnými způsoby lze z component type vytvořit instanci. Instance komponenty je analogií k instanci třídy v objektovém programování.

Model - Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) modelu servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu v životním cyklu (např. přechod na stav Valid).

Framework - Komponentový framework je pak celé iPOJO, resp. iPOJO spojené s patřičnou implementací OSGi (viz technické detaily níže). Princip fungování závisí na 2 hlavních částech - kontejner a handler. Kontejner obklopuje obsah (implementace POJO objektů) a spravuje všechny jeho mimofunkční požadavky jako propojení s ostatními instancemi nebo zdroji, životní cyklus, atd. Kontejner je popsán v component type třídě (opět anotacemi, XML nebo API). Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každý handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponenty je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám. Při běhu aplikace pak iPOJO runtime kombinuje funkční (implementace instancí) a mimofunkční (uchované v konfiguraci kontejneru) aspekty aplikace, odhaluje a "vstřikuje" (inject) požadované služby spojením metadat komponenty a konfigurace instance. Následně uveřejňuje (propaguje) poskytované služby a řídí životní cyklus komponenty.

Technické detaily

Základem iPOJO fyzicky je iPOJO Core bundle (stáhnout).

• přímo v kódu anotacemi (nejjednodušší příklad a výpis základních anotací viz níže, další ukázky stejně jako u XML deskriptoru)
• přímo v kódu přes fluent API

OSGi Service Platform poskytuje výborný základ pro vývoj dynamicky rozšiřitelných Java aplikací. Nicméně tato síla a pružnost není zadarmo. Kromě nevýhod ve formě nových API a formátů balíků, vývojáři v OSGi musí změnit svoje uvažování, aby byli schopni vytvářet vysoce dynamické aplikace. Rané pokusy, jako Service Binder a Service Tracker, se snažily o zmírnění některých z těchto problémů stejně jako některé aktuálnější příklady jako Declarative Services a Spring Dynamic Modules. iPOJO je další takovou snahou v této oblasti. Je to service-oriented komponentový model vytvořený přímo pro OSGi Service Platform.

Vytvoření aplikace prostřednictvím služeb v samotném OSGi bez dalších frameworků je náročné, protože OSGi API je komplexní a je třeba určité úrovně znalosti o vnitřních mechanismech, aby se předešlo problémům se synchronizací. iPOJO poskytuje velmi jednoduchý vývojový model, což ukazuje následují základní ilustrační příklad (bez vnitřní implementace) pro

• poskytnutí služby

• požadování služby:

Další výhodou iPOJO je jeho flexibilita. Poskytuje totiž mechanismy pro rozšíření sebe samotného, které nevyžadují úpravy jádra. iPOJO se dá tudíž adaptovat pro vlastní potřeby pomocí vlastních handlerů (viz výše Základní principy)

Anotace jsou jedním ze způsobů zápisu metadat komponent a konfigurace instancí v iPOJO. Anotace jsou automaticky zpracovány iPOJO manipulátorem a nemusí být nasazeny při runtimu. Zde jsou vyjmenovány základní anotace iPOJO obsažené v knihovně org.apache.felix.ipojo.annotations a jejich význam, cíl (část kódu, s kterou jsou asociovány, resp. nad kterou se používají) a atributy. Po stažení stačí knihovnu přidat do build path / class path / dependencies. Podrobnější informace nejen o atributech na stránce pod odkazem dole pod seznamem.

• význam: definuje, že třída je komponentou (component type)

• význam: kontrola expozice (vystavení?) služby

• význam: určuje metodu pro binding

• význam: určuje metodu pro unbinding

• význam: určuje metodu volanou, když je aktualizována bound (vázaná) služba

• význam: určuje callback vyvolaný při přechodu do stavu Valid životního cyklu

• význam: určuje callback vyvolaný při přechodu do stavu Invalid životního cyklu

• význam: deklaruje jednoduchou instanci (ekvivalentní k <instance component="..."></instance> v XML souboru)

iPOJO Reference Card pak ukazuje paralelně použití některých základních principů jak anotacemi, tak XML deskriptorem + několik dalších věcí jako Extender Pattern a Whiteboard Pattern.

iPOJO (injected-POJO) je runtime servisních komponent zaměřený na zjednodušení vývoje OSGi aplikací. Nativně podporuje veškeré dynamické aspekty OSGi. iPOJO je vytvořen pro běh moderních aplikací, které se vyznačují modularitou, vyžadující adaptaci za běhu a autonomní chování. iPOJO je vyvíjen týmem kolem Apache Felix (implementace OSGi). Prvotní verze 0.8 je z roku 2008 a vznikla na univerzitě v Grenoblu (Clement Escoffier, Richard S. Hall). Aktuální verze (prosinec 2014) je 1.12.1.

Základní principy

Komponenta - Jelikož iPOJO staví na principu POJO (Plain Old Java Object; standardních Java tříd), komponentu v iPOJO reprezentuje třída označená jako component type jedním ze tří základních způsobů - anotace přímo ve zdrojovém kódu, XML v speciálním souboru popisující iPOJO komponenty a nastavení (XML deskriptoru) nebo pomocí fluent API. Stejnými způsoby lze z component type vytvořit instanci.

Rozhraní (kontrakt) - Rozhraní je reprezentováno poskytovanými a požadovanými službami (metodami nebo promněnými, popř.: konstantami), které se v iPOJO specifikují stejnými způsoby zápisu jako komponenta samotná.

Model - Komponentový model iPOJO je v základu stejný jako u OSGi, jelikož iPOJO pouze vylepšuje tento framework. Jedná se o jednoduchý a rozšiřitelný (viz níže) modelu servisních komponent založených na POJO. Servisní komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Model představují základní možnosti iPOJO ohledně nastavení konfigurace a komunikace mezi komponentami (viz seznam anotací níže). Model lze však libovolně upravovat a rozšiřovat přidáváním vlastních anotací. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu.

Framework - Komponentový framework je pak celé iPOJO, resp. iPOJO spojené s patřičnou implementací OSGi (viz technické detaily níže). Princip fungování závisí na 2 hlavních částech - kontejner a handler. Kontejner obklopuje obsah (implementace POJO objektů) a spravuje všechny jeho mimofunkční požadavky jako propojení s ostatními instancemi nebo zdroji, životní cyklus, atd. Kontejner je popsán v component type třídě (opět anotacemi, XML nebo API). Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každý handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponenty je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám. Při běhu aplikace pak iPOJO kombinuje funkční (implementace instancí) a mimofunkční (uchované v konfiguraci kontejneru) aspekty aplikace.

Základem iPOJO fyzicky je iPOJO Core bundle (stáhnout). Principem iPOJO je větší oddělení funkčního od mimofunkčního kódu (dependency management, service provision, konfigurace, atd.). jednoduchého a rozšiřitelného modelu servisních komponent založeného na POJO. Servisní (službová) komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu.

iPOJO (injected-POJO) je runtime komponent ve formě služeb zaměřený na zjednodušení vývoje OSGi aplikací. Nativně podporuje veškeré dynamické aspekty OSGi. iPOJO je vytvořen pro běh moderních aplikací, které se vyznačují modularitou, vyžadující adaptaci za běhu a autonomní chování. iPOJO je vyvíjen týmem kolem Apache Felix (implementace OSGi). Prvotní verze 0.8 je z roku 2008 a vznikla na univerzitě v Grenoblu (Clement Escoffier, Richard S. Hall). Aktuální verze (prosinec 2014) je 1.12.1.

• rozšiřitelnost a přizpůsobivost, možnost vlastní úpravy komponentového modelu
• iPOJO aplikace podporují dynamické adaptace a vykazují autonomní chování
• použití v různých zařízeních a oblastech (mobilní zařízení, domácí brány, JEE servery)

• staví koncept služeb jako top-level, čímž poskytuje lepší znovupoužitelnost, dovoluje nahrazování jedné implementace za jinou a správu dynamizmu

Komponenta je centrálním konceptem iPOJO. V jádru iPOJO modelu komponenta popisuje závislosti služeb poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponenty. Dalším z nejdůležitějších konceptů v iPOJO je instance komponenty. Instance komponenty je analogií k instanci třídy v objektovém programování. iPOJO runtime odhaluje a "vstřikuje" požadované služby spojením metadat komponenty a konfigurace instance. Následně uveřejňuje (propaguje) poskytované služby a řídí životní cyklus komponenty.

Dalším konceptem je kontejner, který spravuje všechny mimofunkční požadavky obsahu (implementace), jako propojení mezi instancemi nebo se zdroji, životní cyklus, atd. Kontejner je popsán v komponentovém typu, tj. třídě označené za komponentu. Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každý handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponenty je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám.

iPOJO Reference Card pak ukazuje paralelně použití některých základních principů jak anotacemi, tak XML deskriptorem + několik dalších věcí jako Extender Pattern a Whiteboard Pattern.

Základem iPOJO fyzicky je iPOJO Core bundle (stáhnout). Principem iPOJO je větší oddělení funkčního od mimofunkčního kódu (dependency management, service provision, konfigurace, atd.). Při běhu aplikace pak iPOJO kombinuje funkční a mimofunkční (uchované v konfiguraci kontejneru) aspekty aplikace pomocí jednoduchého a rozšiřitelného modelu servisních komponent založeného na POJO. Servisní (službová) komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt implementující dané rozhraní. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu.

Komponenta je centrálním konceptem iPOJO. V jádru iPOJO modelu komponenta popisuje závislosti služeb poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponenty. Dalším nejpodstatnějším konceptem v iPOJO je instance komponenty. Instance komponenty je analogií k instanci třídy v objektovém programování. Spojením metadat komponenty a konfigurace instance iPOJO runtime odhaluje a "vstřikuje" požadované služby, uveřejňuje (propaguje) poskytované služby a řídí životní cyklus komponenty.

Dalším konceptem je kontejner, který spravuje všechny mimofunkční požadavky obsahu (implementace), jako propojení mezi instancemi nebo se zdroji, životní cyklus, atd. Kontejner je popsán v komponentovém typu, tj. třídě označené za komponentu. Kontejner v iPOJO tudíž není monolitem, ale je složen z handlerů. Každá handler spravuje jeden mimofunkční požadavek a požadované hadlery jsou připojeny za běhu aplikace. Instance komponenty je pak validní pouze pokud všechny připojené handlery jsou validní. Handlery je možné vytvářet a nasazovat mimo jádro iPOJO, tudíž každý si může vytvořit vlastní handler a přizpůsobit si tak model iPOJO svým potřebám.

Samotné programování pak probíhá obdobně jako při standardním vývoji v Javě. Rozdílem je jen konfigurace instancí a metadata komponent. Ty je možné zavádět třemi způsoby:

• v XML deskriptoru (podobně jako u OSGi) za pomoci kořenového elementu <iPojo> (příklady např. v Reference Card nebo dalších zdrojích dole na stránce)
• přímo v kódu anotacemi (nejjednodušší příklad a výpis základních anotací viz níže, další ukázky stejně jako XML deskriptoru)
• přímo v kódu přes (fluent) API

Princip

iPOJO funguje na jakékoli implementaci R4.1 OSGi a také na mnoha JVM jako Oracle JRockit?, JamVM?, Dalvik (Android) a Mika. Požaduje pouze J2ME? Fondation 1.1 JVM. Díky tomu lze aplikace používat v mobilních a jiných zařízeních.

Základem iPOJO fyzicky je iPOJO Core bundle (stáhnout). Principem iPOJO je větší oddělení funkčního od mimofunkčních kódu (dependency management, service provision, konfigurace, atd.). Při běhu aplikace pak iPOJO kombinuje funkční a mimofunkční aspekty aplikace pomocí jednoduchého a rozšiřitelného modelu servisních komponent založeného na POJO. Servisní (službová) komponenta může poskytovat a/nebo požadovat služby, přičemž služba je objekt impleentující danné rozhraní. Navíc iPOJO zavádí koncept callbacků (volání), které dávají komponentě vědět o různých změnách stavu.

Komponenta je centrálním konceptem iPOJO. V jádru iPOJO modelu komponenta popisuje závislosti služeb poskytované služby a callbacky. Tyto informace jsou uloženy v metadatech komponenty. After components, the next most important concept in iPOJO is the component instance. A component instance is a special version of a component. By merging component metadata and instance configuration, the iPOJO runtime is able to discover and inject required services, publish provided services, and manage the component's life cycle.

• malý "footprint" - iPOJO Core má pouze cca 550KB

• iPOJO API

• přehled verzí iPOJO
• slajdy přednášky od Richarda S. Halla iPOJO: The Simple Life

iPOJO (injected-POJO) je runtime službových komponent zaměřený na zjednodušení vývoje OSGi aplikací. Nativně podporuje všechny dynamizmy OSGi. iPOJO je vytvořen pro běh moderních aplikací vykazujících modularitu a vyžadujících adaptaci za běhu a automatické chování. iPOJO je vyvíjen týmem kolem Apache Felix (implementace OSGi), prvotní verze 0.8 je z roku 2008 a aktuální (prosinec 2014) je 1.12.1.

• Hello Wrold příklad propojení technologie iPOJO a Maven

iPOJO (injected-POJO) je runtime službových komponent zaměřený na zjednodušení vývoje OSGi aplikací. Nativně podporuje všechny dynamizmy OSGi. iPOJO je vytvořen pro běh moderních aplikací vykazujících modularitu a vyžadujících adaptaci za běhu a automatické chování. iPOJO je vyvíjen týmem kolem Apache Felix (implementace OSGi), prvotní verze 0.8 je z roku 2008 a aktuální (prosinec 2014) je 1.12.x.

Další anotace mohou být v externích handlerech, např. temporální závislosti nebo možnost vystavení instance jako JMX MBean?. K použití externích anotací je nutné pouze přidat je do build path. Více informací o anotacích např. zde.

iPOJO [http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.html | Reference Card] pak ukazuje paralelně použití některých základních principů jak anotacemi, tak XML deskriptorem + několik dalších věcí jako Extender Pattern a Whiteboard Pattern.

Praktické příklady a tutoriály

Příklady na vyzkoušení jsou k nalezení na internetu a zahrnují aplikace

• prostý tutorial na příklady s prodavači občerstvení
• Spell simulující jednoduchý spellchecker
• Hello World příklad propojení technologie iPOJO a Maven
• příklad integrace iPOJO a Vaadin

Další zdroje

• Apache Felix iPOJO FAQ
• Describing your iPOJO components
• přehled verzí iPOJO

Anotace jsou automaticky zpracovány iPOJO manipulátorem a nemusí být nasazeny při runtimu. Zde jsou vyjmenovány základní anotace iPOJO obsažené v knihovně org.apache.felix.ipojo.annotations a jejich význam, cíl (část kódu, s kterou jsou asodiovány, resp. nad kterou se používají) a atributy. Po stažení stačí knihovnu přidat do build path / class path / dependencies.

• nepodporuje konfiguraci, pojmenování a má pouze globální rozsah platnost (tudíž nelze použít kompozici)
• lepší je pro vytváření instancí použít XML descriptor:

  <instance component="ipojo.example.hello.impl.HelloImpl"/>
  <instance component="AnnotedHelloClient"/>
  

Další anotace mohou být v externích handlerech, např. temporální závislosti nebo možnost vystavení instance jako JMX MBean?. K použití externích anotací je nutné pouze přidat je do build path. Více informací o anotacích např. zde

• pokud je použito stejné jméno komponenty v anotaci jako v XML souboru, XML definice má přednost, ale během manipulace se ukáže varování

• atributy: name

Další anotace mohou být v externích handlerech, např. temporální závislosti nebo možnost vystavení instance jako JMX MBean?. Více informací o anotacích např. zde

OSGi Service Platform poskytuje výborný základ pro vývoj dynamicky rozšiřitelných Java aplikací. Nicméně tato síla a pružnost není bez své ceny. Kromě nových API a formátů balíků, vývojáři v OSGi musí změnit svoje uvažování, aby byli schopni vytvářet vysoce dynamické aplikace. Ranné pokusy, jako Service Binder a Service Tracker, se snažily o zmírnění některých z těchto problémů stejně jako některé aktuálnější příklady jako Declarative Services a Spring Dynamic Modules. iPOJO je další takovou snahou v této oblasti. Je to service-oriented komponentový model vytvořený přímo pro OSGi Service Platform.

Další výhodou iPOJO je jeho flexibilita. Poskytuje totiž mechanismy pro rozšíření sebe samotného, které nevyžadují úpravy jádra. iPOJO se dá tudíž adaptovat pro vlastní potřeby pomocí vlastních handlerů.

Anotace

Zde jsou vyjmenovány základní anotace iPOJO obsažené v knihovně org.apache.felix.ipojo.annotations a jejich význam, cíl (část kódu, s kterou jsou asodiovány, resp. nad kterou se používají) a atributy.

• @Component
  • význam: definuje, že třída je komponentou
  • cíl: třída implementující komponentu
  • atributy: name, immediate, architecture, propagation, managedservice, factoryMethod, publicFactory
• @Provides
  • význam: určuje, že komponenta poskytuje službu
  • cíl: třída implementující komponentu
  • atributy: specifications, strategy, properties
• @Requires
  • význam: signalizuje závislost na službě jiné komponenty
  • cíl: proměnná nebo parametr konstruktoru
  • atributy: filter, optional, id, nullable, defaultimplementation, exception, policy, comparator, from, specification, proxy, timeout
• @ServiceProperty?
  • význam: definuje vlastnost služby
  • cíl: proměnná
  • atributy: name, value, mandatory
• @ServiceController?
  • význam: kontrola expozice služby
  • cíl: proměnná (Boolean)
  • atributy: value, specification
• @Property
  • význam: definuje vlastnost
  • cíl: proměnná, metoda, parametr konstruktoru
  • atributy: name, value, mandatory
• @Updated
  • význam: určuje metodu volanou při dokončení rekonfigurace
  • cíl: třída (se slovníkem jako vstupním argumentem)
• @Bind
  • význam: určuje bindovací metodu
  • cíl: metoda
  • atributy: id, specification, aggregate, optional, filter, policy, comparator, from
• @Unbind
  • význam: určuje unbindovací metodu
  • cíl: metoda
  • atributy: id, specification, aggregate, optional, filter, policy, comparator, from
• @Modified
  • význam: určuje metodu volanou, když je aktualizována bound služba
  • cíl: metoda
  • atributy: id, specification, aggregate, optional, filter, policy, comparator, from
• @Validate
  • význam: určuje validate callback životního cyklu
  • cíl: metoda
• @Invalidate
  • význam: určuje invalidate callback životního cyklu
  • cíl: metoda
• @PostRegistration?
  • význam: určuje callback vyvolaný po registraci služby; callback musí mít hlavičku public void name(ServiceReference ref)
  • cíl: metoda
• @PostUnregistration?
  • význam: určuje callback vyvolaný po odregistrování služby; callback musí mít hlavičku public void name(ServiceReference ref)
  • cíl: metoda
• @Instantiate
  • význam: deklaruhe jednoduchou instanci (ekvivalentní k <instance component="..."></instance> v XML souboru)
  • cíl: třída
  • atributy: name