Architecture | Modular Enterprise Applications | Mark Nuttall
-
Upload
jax-london -
Category
Technology
-
view
1.163 -
download
0
description
Transcript of Architecture | Modular Enterprise Applications | Mark Nuttall
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?