1 / 31

Java komponens modellek

Java komponens modellek. avagy hány JSR kell egy használható komponens modell bevezetéséhez? Srágli Attila. Á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ő?. Fogalmak – komponens.

job
Télécharger la présentation

Java komponens modellek

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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!

More Related