Modular Enterprise Applications

Mark Nuttall, [email protected]

IBM WebSphere OSGi Applications development lead

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

“(Desirable) property of a system, such that individual components can be examined, modified and maintained 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.”

PCIe x16

VGA

DVI

So what is Modularity?

www.cs.bath.ac.uk/~jap/MATH0015/glossary.html

Modularity

Complexity and System Rot

Time

Traditionalsystem

Modularsystem

Time

Traditionalsystem

Modularsystem

In a software system, entanglement is the primary cause of decay.

Java needs help: enforcing modularity makes entanglement less likely

People dothis to software all the time!

• Java unit of modularity = JAR

• Enterprise apps are collections of JARs

• But a JAR lacks the primary characteristics of modularity:

• It does NOT hide its internals

• It does NOT declare its externals

• The global Java classpath does NOT support versioning

JarJar

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, …

Package

ClassClass

Class

Package

ClassClass

Class

Package

ClassClass

Class

Package

ClassClass

Class

Explicit exports

Explicit dependencies

BundleBundle

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

Package

ClassClass

Class

Package

ClassClass

Class

Package

ClassClass

Class

Package

ClassClass

Class

Explicit exports

Explicit dependencies

BundleManifest-Version: 1.0Bundle-ManifestVersion: 2

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: My Example BundleBundle-SymbolicName: com.my.bundleBundle-Version: 1.0.0Export-Package: com.something.i.provide;version="1.0.0"Import-Package: com.something.i.need;version="[1.1,2.0)"

Bundle

Bundle

Bundle

Manifest-Version: 1.0

Bundle-ManifestVersi

Manifest-Version: 1.0

Bundle-ManifestVersi

Manifest-Version: 1.0

Bundle-ManifestVersi

OSGi Modules (aka Bundles)• A Jar plus OSGi Manifest, includes:

– Bundle Identity– Exported Packages– Imported Packages

• Dependency resolution “wires” bundles intoa dependency graph

• Each gets its own class loader

• Classloading delegates via graph

Classloader

Classloader

Classloader

Classloader

Dynamic Lifecycle

• Bundles have a dynamic lifecycle

• Can come and go independently

• APIs enable graceful reaction to changes

Bundle

OSGi Services

• 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

serviceProviderBundle

ConsumerBundle

registerget

listen

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

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 XMLRepository1Repository1

Repository2Repository2

Repository3Repository3

XMLResolverResolver

SubsystemSubsystem

Environment

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.

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

Subsystems Model: Hierarchy

• Most common model is hierarchy and so Subsystems are no different– Each has 1 parent– Each can have many children– Children of the same parent

are siblings

• Visually represented by containment

subsystemsubsystem

subsystemsubsystem

subsystemsubsystem

subsystemsubsystem

subsystemsubsystem

subsystemsubsystem subsystemsubsystem

Feature Subsystems• Collection of Resources (e.g.

Bundles)

• Shared life-cycle

• Can be nested

• No isolation or affinity

• Repository-based provisioning

• Examples: Karaf Features, Virgo unscoped Plans

feature

bundlebundle

bundlebundle

bundlebundle

bundlebundle

bundlebundle

bundlebundle

feature

Composite Subsystems• Coarse-grained sub-assembly

module

• Isolated

• Explicit share in/out

• Affinity

• Repository-based provisioning

• Examples: RFC 138 Composite Bundles*, WebSphere Composite Bundles

*old design prior to resolver hooks

compositecomposite

bundlebundle

bundlebundle

bundlebundle

bundlebundle

bundlebundle

bundlebundle

Application Subsystems

• Model for hosted applications

• Isolated

• No sharing out, implicit sharing in

• Affinity

• Repository-based provisioning

• Examples: Aries Application, Virgo Scoped Plans, Virgo PARs

applicationapplication

bundlebundlebundlebundle

bundlebundle

bundlebundle

bundlebundle

Example Combination

• Subsystem Types can be mixed and matched

• Example shows:– Features used to assemble

a Composite– Composite providing a

‘platform’ to Applications

frameworkframework

compositecomposite

applicationapplication

feature feature

feature

applicationapplication

Portability

• Subsystem Manifests are portable to a point– Target Environment + Transitive

Dependencies must support the required resource implementation types (e.g. Blueprint, WAB, DS, etc)

• Transitive dependencies may be portable– Different Target Environments

likely to require different Transitive Dependencies

Subsystem Definition

Target Environment

Transitive

Dependencies

Packaging

• Packaged in a Subsystem Archive

• A zip file with .ssa extension:– Subsystem Manifest (optional)– Deployment Manifest (optional)– Resources

(optional)

my.first.subsystem.ssa

OSGI-INF/SUBSYSTEM.MF

OSGI-INF/DEPLOYMENT.MF

an.osgi.bundle-1.0.0.jaran.osgi.bundle-1.0.0.jar

an.osgi.bundle2-1.0.0.jaran.osgi.bundle2-1.0.0.jar

ExampleCompositeComposite ACTIVE

Start with an empty Composite

ExampleCompositeComposite

transitive bundletransitive bundle

ApplicationApplication

bundlebundle

RESOLVED

RESOLVED

RESOLVED

ACTIVE

Application Subsystem installed and resolved

CompositeComposite

ApplicationApplication

bundlebundle

transitive bundletransitive bundle transitive bundletransitive bundle

ApplicationApplication

bundlebundle

RESOLVED

ACTIVEACTIVE

ACTIVERESOLVED

ACTIVE

ACTIVE

Second Application Subsystem installed and

startedExample

CompositeComposite

ApplicationApplication

bundlebundle

transitive bundletransitive bundle transitive bundletransitive bundle

ApplicationApplication

bundlebundle

RESOLVED

UNINSTALLEDRESOLVED

UNINSTALLEDRESOLVED

UNINSTALLED

ACTIVE

Second Application Subsystem uninstalledExample

CompositeComposite

ApplicationApplication

bundlebundle

transitive bundletransitive bundle

ApplicationApplication

bundlebundle

UNINSTALLED

UNINSTALLED

UNINSTALLEDUNINSTALLED

UNINSTALLED

ACTIVE

First Application Subsystem uninstalled

transitive bundletransitive bundle

UNINSTALLED

Example

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

Demo Time: Colors by WebSphere

Colors by WebSphere: Bundles and Services

colors.web

colors.provider.red

colors.provider.blue

colors.api

colors.blender

colors.provider.green

Colors by WebSphere: Color services

colors.web

colors.provider.blue

colors.api

colors.blender

Color services colors.provider.red

colors.provider.green

Colors by WebSphere: Color services

colors.web

colors.provider.blue

colors.api

colors.blender

Adjustment Service(Extension Point) colors.provider.red

colors.provider.green

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

Thank you! Any questions?