Java komponens modellek

1. Java komponens modellek avagy hány JSR kell egy használható komponens modell bevezetéséhez? Srágli Attila

2. Áttekintés • Fogalmak • Miért kell nekünk komponens modell? • A múlt • Komponens modellek • Komponens modell implementációk • Összehasonlítás • A jelen • A jövő?

3. Fogalmak – komponens Ahány ház, annyi definíció. A kedvenceim: „A component is a unit of composition with contractually specified interfaces and fully context dependencies that can be deployed independently and is subject to third-party composition” Clemens Szyperski: Component Software: Beyond Object-Oriented Programming, 1998. „the smallest architecturally relevant building block, a piece of encapsulated application functionality” Markus Völter

4. Fogalmak – komponens • Egy komponens tehát explicit módon deklarálja: • az általa nyújtott szolgáltatásokat • Java megfelelője: implementált interfészek • az általa igényelt szolgáltatásokat • Java megfelelője: ?? • a kapcsolódási pontokat (portok) az igényelt szolgáltatások egyedei számára (referencia neve, kardinalitás) • Java megfelelője: ??

5. Fogalmak – komponens modell Definiálja a komponensek • struktúráját (Hogyan néz ki egy komponens?): • interfészek • konfiguráció • kompozíció (Hogyan építkezünk belőlük?) • viselkedését (Hogyan működnek?): • életciklus-kezelés • kommunikáció • ... valamilyen formalizmust használva.

6. Fogalmak – komponens framework • A komponens modell implementációja • Kezeli a komponensek • függőségeit • életciklusát (telepítés, indítás, leállítás, frissítés, eltávolítás) • nem-funkcionális követelményeit (QoS, perzisztencia, naplózás, kommunikáció, biztonság, tranzakciók stb.) -> fw. szolgáltatások.

7. Fogalmak – Dependency Injection (DI) • Tervezési minta • Egyéb elnevezése: Inversion of Control (IoC) • Adott objektum (szolgáltatás) létrehozását kiveszi a szolgáltatás igénylője (kliens) hatásköréből. A szolgáltatást a komponens konténer hozza létre, majd az arra mutató referenciát megfelelő módon (konstruktor, egyedváltozó, metódus vagy byte-kód beszúrással) átadja a kliensnek.

8. Fogalmak – Dependency Lookup • Tervezési minta • Egyéb elnevezései: Service Locator, Object Factory, Component Broker, Component Registry • Adott objektum (szolgáltatás) létrehozását kiveszi a szolgáltatás igénylője (kliens) hatásköréből. A szolgáltatást a komponens konténer hozza létre és tárolja (registry), a kliens a konténer API-n keresztül érheti el az arra mutató referenciát (lookup).

9. Miért kell nekünk komponens modell? • Mert lehetővé teszi • a komponens alapú szoftverfejlesztést • a komponens formátum szabványosítását, szabványos szolgáltatások kialakítását (COTS) • a Java nyelv és VM hiányosságainak pótlását: • kód-hordozhatóság (magasabb szintű absztrakció, konténerek között) • verziókezelés (JAR-hell) • alkalmazás-felügyelet • …

10. A múlt • Kezdetben nem definiáltak komponens modellt • Később: Java Beans, EJB 1.x, 2.x, … • Problémák: • túl specifikusak • hiányzó verziókezelés • nem alkalmazhatók széles körben (beágyazott eszközök – nagyvállalati felhasználás)

11. Komponens modellek – DI framework-ök • Struktúra: • POJO/POJI modell (szolgáltatás = osztály [+ interfész]) • Konfiguráció: • Java annotációk és/vagy konfigurációs file stb. • Kompozíció: • Dependency Injection • Életciklus-kezelés: • nincs vagy eltérő implementációk

12. Komponens modellek – DI framework-ök

13. Komponens modellek - OSGi • Struktúra: • POJO/POJI modell (szolgáltatás = osztály [+ interfész]) • Konfiguráció: • MANIFEST.INF, XML (pl. Declarative Services, Spring-DM, Extension Registry), opcionálisan Java annotációk (pl. Spring-DM) • Kompozíció: • Dependency Lookup (BundleContext) • Dependency Injection: konstruktor, setter (Spring-DM), egyedváltozó, metódus (iPOJO) • Életciklus-kezelés: • szabványos (JSR 291) • állapotok: installed, resolved, starting, active, stopping, uninstalled

14. Komponens modellek - OSGi

15. Komponens modellek – Java Module System • Struktúra: • POJO/POJI modell (szolgáltatás = osztály [+ interfész]) • Konfiguráció: • MANIFEST.INF, opcionálisan Java annotációk • Kompozíció: • Dependency Lookup • Életciklus-kezelés: • szabványos (JSR 277) • állapotok: new, preparing, validating, resolved, ready, error

16. Komponens modellek - SCA • Célja elsősorban a technológia-függetlenség és az interoperabilitás. • Struktúra: • POJO/POJI modell (szolgáltatás = osztály [+ interfész]) • Konfiguráció: • Java annotációk és XML • Kompozíció: • Dependency Injection (vagy más, a szabvány említi, de nem definiálja) • Életciklus-kezelés: • a szabvány nem definiálja, implementáció-specifikus

17. Komponens modellek - SCA

18. Spring - programozási modell XML konfiguráció: <bean id=„service” class=„com.acme.Service” /> <bean id=„consumer” name=„consumer” class=„com.acme.ServiceConsumer”> <property name=„service” ref=„service”/> </bean> vagy annotációk: @Component public class Service { … } public class ServiceConsumer { @AutoWired private Service service; … } POJO-k: public class Service { … } public class ServiceConsumer { private Service service; public void setService(Service service) { this.service = service; } … }

19. OSGi - programozási modell package com.acme.service; public class Service { … } public class ServiceActivator implements BundleActivator { public void start(BundleContext context) { Service service = new Service(); context.registerService(Service.class.getName(), service, null); } public void stop(BundleContext context) { … } } package com.acme.client; public class ConsumerActivator implements BundleActivator { public void start(BundleContext context) { Service service = (Service) context .getService(Service.class.getName()); … } public void stop(BundleContext context) { … } } Service bundle - MANIFEST.INF Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Service Plug-in Bundle-SymbolicName: Service Bundle-Version: 1.0.0 Bundle-Activator: com.acme.service.ServiceActivator Export-Package: com.acme.service … ServiceConsumer bundle - MANIFEST.INF Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: ServiceConsumer Plug-in Bundle-SymbolicName: ServiceConsumer Bundle-Version: 1.0.0 Bundle-Activator: com.acme.client.ConsumerActivator Import-Package: com.acme.service …

20. SCA – programozási modell package services.account; @Remotable public interface AccountService{ public AccountReport getAccountReport(String customerID); } package services.account; public class AccountServiceImpl implements AccountService { @Property private String currency = "USD"; @Reference private AccountDataService accountDataService; public AccountReport getAccountReport(String customerID) { … } }

21. SCA – programozási modell XML konfiguráció: <componentType xmlns=http://www.osoa.org/xmlns/sca/1.0 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <service name="AccountService"> <interface.java interface="services.account.AccountService"/> </service> <reference name="accountDataService"> <interface.java interface="services.accountdata.AccountDataService"/> </reference> <property name="currency" type="xsd:string">USD</property> </componentType>

22. Összehasonlítás Szempontok, melyek szerint differenciálni lehet: • Hordozhatóság • Dinamikus modulkezelés (betöltés, eltávolítás, frissítés) • Framework szolgáltatások • Verziókezelés • Elterjedtség, szabvány • … javaslatok?

23. Hordozhatóság • OSGi: • beágyazott eszközök (otthon-automatizálás, járműipar, navigációs eszközök stb.), ME (JSR 232), SE (JSR 291), EE (pl. BEA) • DI framework-ök • SE, EE • Java Module System (JSR 277) • tervezés alatt, leginkább SE • SCA • EE • több implementáció (SpringSource, IBM, Oracle stb.)

24. Dinamikus modulkezelés • Spring, Guice, JSR 277: statikus, a framework/alkalmazás indításakor vagy alkalmazás által kezelt módon • OSGi: teljesen dinamikus (futás közben is), a framework alapszolgáltatása • SCA: implementáció-specifikus

25. Framework szolgáltatások • DI framework-ök: • egyedi megoldások • OSGi: • szabványban rögzítve (JSR 232, JSR 291) • Java Module System: • a szabvány nem tartalmazza, más JSR-ek (pl. JSR 294) specifikálják majd • SCA: • nem része a szabványnak, implementáció-specifikus

26. Verziókezelés • Spring, Guice: nincs • OSGi, Java Module System: szabványos, modul szintű • SCA: nincs specifikálva, más absztrakciós szint (fw-implementáció)

27. Elterjedtség, szabvány • Spring: • nagy felhasználói bázis (SE/EE) • első verzió: 2002 • kvázi szabvány (EE) • Guice: • terjedőben (SE/EE) • első verzió: 2007 • OSGi: • viszonylag nagy felhasználói bázis (beágyazott/ME, SE, EE) • első implementáció: 2000 • szabványosított: JSR 232 (ME), JSR 291 (SE) • Java Module System: • csak szabványtervezet (JSR 277, early draft) • nincs publikus implementáció • SCA: • több implementáció (leginkább EE) • OSOA szabvány, 2005 (v0.9, az első publikus specifikáció), 2007 (v1.0)

28. A jelen • Nagyon hasonló megoldások • Spring, OSGi gyors térhódítása • együttműködés: Spring Dynamic Modules • Guice terjedése • együttműködés: Guice-OSGi, Spring • Java Module System szabványosítás alatt, publikus implementáció nincs • együttműködés: OSGi (javaslat) • Egyre több SCA implementáció • Szabványháború (JSR 291, JSR 277)

29. A jövő? • A komponens-alapú alkalmazások egyértelmű terjedése • Szabványosítás (JCP?) vagy kvázi-szabványok? • Java 7: JSR 277 vagy OSGi ? • Együttműködő implementációk (pl. SCA) vagy Universal Middleware?

30. Hivatkozások • Google Guice (http://code.google.com/p/google-guice/) • Guice-OSGi (http://wiki.ops4j.org/confluence/display/ops4j/Guice-OSGi) • Java Module System (http://www.jcp.org/en/jsr/detail?id=277) • OSGi (http://www.osgi.org/) • Service Component Architecture (SCA) (http://www.osoa.org/display/Main/Service+Component+Architecture+Home) • Spring (http://www.springframework.org/) • Spring Dynamic Modules (http://www.springframework.org/osgi/)

31. Köszönöm a figyelmet!