This document discusses modularity and OSGi, including:
- What modularity is and why Java needs it to reduce entanglement over time
- An overview of Enterprise OSGi and how it brings enterprise technologies to OSGi
- New features in OSGi Service Platform Release 4 such as a standard application model and bundle repository
- A demonstration of a colors application that uses OSGi bundles and services
2. Overview
• Modularity and OSGi: what they are and
why Java needs them
• Enterprise OSGi
• What’s new in the OSGi Service
Platform Release 4 Early Draft 2011.09,
and why it’s important
• Demonstration
3. Modularity
So what is Modularity?
“(Desirable) property of a system, such
that individual components can be
examined, modified and maintained
PCIe x16
independently of the remainder of the
system. Objective is that changes in
one part of a system should not lead to
unexpected behavior in other parts.” VGA
DVI
www.cs.bath.ac.uk/~jap/MATH0015/glossary.html
4. Complexity and System Rot
Traditional
system
Modular
system
Modular
system
Traditional
system
Time Time
In a software system, entanglement is the
primary cause of decay.
5. Java needs help: enforcing modularity
makes entanglement less likely
• Java unit of modularity = JAR
• Enterprise apps are collections of
JARs
• But a JAR lacks the primary
characteristics of modularity:
People do
this to software
all the time!
• It does NOT hide its internals
• It does NOT declare its externals
• The global Java classpath does
NOT support versioning
6. What is OSGi?
• “The dynamic module system for Java”
– Mature 10-year old technology
– Governed by OSGi Alliance: http://www.osgi.org
– Used inside just about all Java-based middleware
• IBM WebSphere, Oracle WebLogic, Red Hat JBoss, Sun GlassFish, Paremus
Service Fabric, Eclipse Platform, Apache Geronimo, …
Jar Jar
Package Explicit exports Package
Class Class
Class Class
Class Class
Package Package
Class Class
Class Class
Class Class
Explicit dependencies
6
7. How does OSGi help reduce cost?
• Enforces architecture and simplifies maintenance
• Enables modular deployment
• Enables co-existence of multiple versions of libraries
– Simplifies independent evolution of applications
– Better separation of concern between application and middleware
• Enables truly dynamic update of modules within applications
Bundle Bundle
Package Explicit exports Package
Class Class
Class Class
Class Class
Package Package
Class Class
Class Class
Class Class
Explicit dependencies
7
8. OSGi Modules (aka Bundles)
Classloader
Bundle
• A Jar plus OSGi Manifest, includes: Manifes t-Ver sion : 1.0
Bundle- Manif estV ersi
– Bundle Identity Classloader
Bundle
– Exported Packages
Manifes t-Ver sion : 1.0
Bundle- Manif estV ersi
Classloader
Bundle
– Imported Packages
Manifes t-Ver sion : 1.0
Bundle- Manif estV ersi
• Dependency resolution Classloader
“wires” bundles into
Bundle
a dependency graph
Manifest-Version: 1.0
• Each gets its own
Bundle-ManifestVersion: 2
class loader
• Classloading
delegates via graph
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: My Example Bundle
Bundle-SymbolicName: com.my.bundle
Bundle-Version: 1.0.0
Export-Package: com.something.i.provide;version="1.0.0"
Import-Package: com.something.i.need;version="[1.1,2.0)"
9. Dynamic Lifecycle
Bundle
• Bundles have a dynamic
lifecycle
• Can come and go
independently
• APIs enable graceful
reaction to changes
10. OSGi Services
service
Consumer get register Provider
Bundle Bundle
listen
• Publish/find/bind service model
– Fully dynamic
– Local
– Non-durable
• Primary mechanism for bundle collaboration
• POJO advertised with properties and/or interface and/or
class
11. OSGi Enterprise Specification
• Enterprise 4.2: Released 22 March 2010
– OSGi Enterprise Expert Group (EEG)
• Brings Enterprise technologies and OSGi together
• Using existing Java SE/EE specifications:
– JTA, JPA, JNDI, JMX, WebApps…
• Adds Spring-derived Blueprint component model and DI container
• New in the OSGi Service Platform release 4 early draft 2011.09:
– Standard application model
– Bundle repository
• Java EE provides the core enterprise application programming
model
• OSGi encourages modular design, simplifies reuse, and enables
dynamic module updates
12. OSGi Bundle Repository
• Standardizes the entities required to resolve requirements
– Used by the Subsystems specification for deployment
• Environment – enables context and policy
• Resolver – similar to runtime framework resolver
• Repository – provides candidate solutions to requirements
• Repository XML – interchange XML
Repository1
Resolver Environment Repository2
XML
Subsystem Repository3
13. Subsystems: Disclaimer
• Subsystems is an in-progress RFC.
What follows is a snapshot in time of the
expert group thinking and is subject to
change.
14. Subsystems: Motivation
• Enterprise Java platforms are awash with bundle
collections
– Apache Aries – Applications
– Apache Geronimo - Applications
– Apache Karaf – Features
– Eclipse Virgo – Plans, PARs
– IBM WebSphere Application Server –
Applications, Composites, Liberty Features
– Oracle GlassFish – Applications
– Paremus Service Fabric – Systems
• Crying out for standardization
– Portability
– Tools
– Ecosystem
15. Subsystems Model: Hierarchy
• Most common model is subsystem
hierarchy and so
Subsystems are no subsystem
different
– Each has 1 parent subsystem
– Each can have many children
subsystem subsystem
– Children of the same parent
are siblings
• Visually represented by subsystem subsystem
containment
16. Feature Subsystems
• Collection of Resources (e.g. feature
Bundles) bundle
• Shared life-cycle
• Can be nested feature
• No isolation or affinity bundle
• Repository-based
bundle
provisioning
bundle
• Examples: Karaf Features,
Virgo unscoped Plans
bundle bundle
18. Application Subsystems
• Model for hosted
applications application
bundle
• Isolated
• No sharing out, implicit bundle
sharing in
bundle
• Affinity
• Repository-based
provisioning
bundle bundle
• Examples: Aries
Application, Virgo Scoped
Plans, Virgo PARs
19. Example Combination
• Subsystem Types can be framework
mixed and matched
application application
• Example shows:
– Features used to assemble
a Composite composite
– Composite providing a feature feature
‘platform’ to Applications
feature
20. Portability
• Subsystem Manifests are
portable to a point Subsystem Definition
– Target Environment + Transitive
Dependencies must support the
required resource implementation Transitive
types (e.g. Blueprint, WAB, DS, Dependencies
etc)
• Transitive dependencies Target Environment
may be portable
– Different Target Environments
likely to require different Transitive
Dependencies
21. Packaging
• Packaged in a Subsystem my.first.subsystem.ssa
Archive
OSGI-INF/SUBSYSTEM.MF
• A zip file with .ssa
extension: OSGI-INF/DEPLOYMENT.MF
– Subsystem Manifest (optional)
– Deployment Manifest (optional)
an.osgi.bundle-1.0.0.jar
– Resources
(optional)
an.osgi.bundle2-1.0.0.jar
22. Start with an empty
Example Composite
Composite ACTIVE
23. Application Subsystem
Example installed and resolved
Composite ACTIVE
Application RESOLVED
bundle
RESOLVED
transitive bundle
RESOLVED
24. Second Application
Subsystem installed and
Example started
Composite ACTIVE
Application RESOLVED Application ACTIVE
bundle bundle
RESOLVED ACTIVE
transitive bundle transitive bundle
ACTIVE ACTIVE
25. Second Application
Example Subsystem uninstalled
Composite ACTIVE
Application RESOLVED Application UNINSTALLED
bundle bundle
RESOLVED UNINSTALLED
transitive bundle transitive bundle
RESOLVED UNINSTALLED
26. First Application Subsystem
Example uninstalled
Composite ACTIVE
Application UNINSTALLED Application UNINSTALLED
bundle bundle
UNINSTALLED UNINSTALLED
transitive bundle transitive bundle
UNINSTALLED UNINSTALLED
27. Subsystems: Summary
• With the publication of the next OSGi Service
Platform specification, subsystems will be the
standard way to manage groups of resources
• Version ranges allow flexibility in resource selection
• Subsystem types define sharing semantics
• Deployment definition
– locks down versions and sharing
– Identifies transitive dependencies
• API enables management of Subsystem life-cycle
29. Colors by WebSphere:
Bundles and Services
colors.provider.red
colors.web colors.blender
colors.provider.green
colors.provider.blue
colors.api
30. Colors by WebSphere: Color
services
Color services colors.provider.red
colors.web colors.blender
colors.provider.green
colors.provider.blue
colors.api
31. Colors by WebSphere: Color
services
Adjustment Service
colors.provider.red
(Extension Point)
colors.web colors.blender
colors.provider.green
colors.provider.blue
colors.api
32. Summary
• Modularity and OSGi: what they are and
why Java needs them
• Enterprise OSGi
• What’s new in the OSGi Service
Platform Release 4 Early Draft 2011.09,
and why it’s important
• Demonstration