Java komponens modellek

Az előadások a következő témára: "Java komponens modellek"— Előadás másolata:

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 Azaz a hangsúly az egységbe záráson (komponens, mint egység) és a függőségek (nyújtott szolgáltatások (interfész) és elvárt szolgáltatások) definiálásán van.

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) A Java nyelv a nyújtott szolgáltatások explicit deklarálására képes ugyan („implements” kulcsszó), azonban az igényelt szolgáltatások és portok explicit módon nem deklarálhatók, tehát a kizárólag a nyelvi lehetőségekre épülő komponens modell nem lehet teljes. Egyértelmű tehát, hogy egy teljes komponens modellt csak egy magasabb absztrakciós szinten lehet megvalósítani.

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. A formalizmus fontos, különben nem beszélhetünk modellről.

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. Szebb nevén komponens konténer.

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. CIA-zsargonnal élve: Don’t call me, we call you.

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 … A Java nyelv nem ismeri a komponens koncepciót: az osztály túl kis egység (interfész, konfiguráció?) a package túl egyszerű (nincs mögötte a szükséges formalizmus - kötetlen struktúra, nem specifikált viselkedés) a class loader túl alacsony szintű a JAR file megfelelő lenne, de nincs megfelelően specifikálva, mi és milyen formában kerüljön bele

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) Ez sajnos csökkenti a Java platform elfogadottságát (lásd Java vs. .NET viták – a .NET-ben határozottan jó koncepció az Assembly). A „házon belüli” (Sun) fejlesztések gyakori problémái.

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 Példaként a Spring-et és a Guice-t használom az elterjedtségük miatt. Életciklus-kezelés: A „nincs” annyit jelent, hogy legtöbb esetben a komponensek a konténer elindulásakor indulnak, leállításakor leállnak.

12 Komponens modellek – DI framework-ök
A metamodell csak vázlatos, a koncepciót hivatott bemutatni.

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 A szabványtervezet egyelőre csak Early Draft verzió, így akár jelentős változások is lehetnek.

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
POJO-k: public class Service { … } public class ServiceConsumer { private Service service; public void setService(Service service) { this.service = service; 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; XML konfiguráció helyett természetesen Java annotációk is használhatók.

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 { Service service = (Service) context .getService(Service.class.getName()); 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 Bundle-Name: ServiceConsumer Plug-in Bundle-SymbolicName: ServiceConsumer Bundle-Activator: com.acme.client.ConsumerActivator Import-Package: com.acme.service Az Activator-ok kézzel való létrehozása elkerülhető, ha nem az alapértelmezett (és maximum csak egyszerűbb alkalmazások számára javasolt) függőség-kezelést vagy a ServiceTracker-t választjuk.

20 SCA – programozási modell
package services.account; @Remotable public interface AccountService{ public AccountReport getAccountReport(String customerID); } 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= xmlns:xsd=" <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 SCA OSGi: DI framework-ök Java Module System (JSR 277)
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 ( Java Module System ( OSGi ( Service Component Architecture (SCA) ( Spring ( Spring Dynamic Modules (

31 Köszönöm a figyelmet!