This document discusses OSGi and Apache Aries, which is an open source project that aims to make OSGi and Java EE technologies work better together. It provides an overview of OSGi concepts like modularity, services, and lifecycle management. It also explains how Apache Aries uses Blueprint to define and manage components and references between bundles. Finally, it highlights Apache Aries' integration of technologies like JNDI and provides examples of how Blueprint can be used to define services and dependencies between bundles in an OSGi application.
Apache Aries: A blueprint for developing with OSGi and JEE
1. Apache Aries A Blueprint for developing with OSGi and JEE Valentin Mahrwald, IBM
2.
3. Modularity Services Life cycle Module Execution environment S e c u r i t y Bundles Hardware / OS System Loader Extension Loader App 1 Loader App 2 Loader WebApp 1 Loader System Loader Extension Loader Bundle A Bundle C 1 Bundle B Bundle C 2 Traditional OSGi Import-Package: org.blah.util; version=[1.0.2,2.0.0) Export-Package: org.blah.util; version=1.5.0 Export-Package: org.blah.util; version=2.0.0
Introduce the subject briefly Apache Aries, very recent incubator @Apache Built around OSGi for Java EE dev => ProgModel: modular applications through OSGi using existing JEE technology at the same time Introduce yourself Working on an OSGi related project at IBM Hursley
OSGi Alliance, Founded in 1999 Started in mobile and embedded space Sometimes feels teleported back to Java 1.0 Proven technology, highly active, revision 4.2 Execution environment on top of the JVM or embedded into some other execution environment Wide adoption (growing): Example implementations: Eclipse, Felix Built in too enterprise servers: WAS, WebLogic, Jboss Not quite the only game in town: project jigsaw in JDK 7
Jar hell Higher level modularity Jar-file level rather than class or package Dependency declaration Versioning Benefits Maintainance Sharing without risk This is the aspect most commonly exploiting (for example in a server runtime like WAS)
Bundles can come and go dynamically - enables more lazyness !!! - not every app can handle this transparently => use services Services: - model for loose coupling, to allow dynamic updates, Dynamic change of services, (potentially fall-over) Built-in “SOA” (low level admittedly)
Surprisingly late addition, 2007 OSGi EEG How to access EE technology from inside OSGi Java SE and EE don't cope well with OSGi Make EE technology accessible to apps developed for OSGi Problem EE has its own assumptions about the execution environment JNDI just one example, JPA, JSP etc all have similar issues
OSGi alliance working on number of other specs Will find a home in Apache Aries Examples: webcontainer, transactions Blueprint Standardized (by the OSGi alliance) Spring ( ! only the dependency injection part) Core dependency injection + OSGi awareness Extensible for supporting other parts that Spring simplifies
Familiar to anyone who has used Spring before Dependency injection framework With OSGi support, in particular services Extra dynamism steroids Injected services can change overtime Injected services can temporarily be absent (without the bundle knowing) Complexity is handled by Blueprint Explain scopes and extensibility
Scope: “prototype” -> maybe the programmer is worried about concurrency problems :)
Updating components of an app while it is running Old state Install updated bundle Remove old bundle => blueprint automatically wires you to the new component NB: The BillingService interface should not be contained in either bundle but rather be in a third api bundle