Architecture | Modular Enterprise Applications | Mark Nuttall

1,670 views

Published on

2011-11-02 | 02:25 PM - 03:15 PM
Enterprise applications are often long-lived, traditionally becoming more difficult and expensive to maintain over time. This talk will show how modular design and OSGi technology can help prevent this 'system rot' and enable more dynamic behaviour. We will outline the programming model and demonstrate running applications being maintained and extended on WebSphere Application Server version 8.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,670
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Architecture | Modular Enterprise Applications | Mark Nuttall

  1. 1. Modular Enterprise Applications Mark Nuttall, mnuttall@uk.ibm.com IBM WebSphere OSGi Applications development lead
  2. 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. 3. ModularitySo what is Modularity?“(Desirable) property of a system, suchthat individual components can beexamined, modified and maintained PCIe x16independently of the remainder of thesystem. Objective is that changes inone part of a system should not lead tounexpected behavior in other parts.” VGA DVIwww.cs.bath.ac.uk/~jap/MATH0015/glossary.html
  4. 4. Complexity and System Rot Traditional system Modular system Modular system Traditional system Time TimeIn a software system, entanglement is theprimary cause of decay.
  5. 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. 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. 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. 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. 9. Dynamic Lifecycle Bundle• Bundles have a dynamic lifecycle• Can come and go independently• APIs enable graceful reaction to changes
  10. 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. 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. 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. 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. 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. 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. 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
  17. 17. Composite Subsystems • Coarse-grained sub-assembly bundle module • Isolated composite • Explicit share in/out bundle • Affinity • Repository-based bundle provisioning bundle • Examples: RFC 138 Composite Bundles*, WebSphere Composite Bundles bundle bundle*old design prior to resolver hooks
  18. 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. 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. 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. 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. 22. Start with an emptyExample CompositeComposite ACTIVE
  23. 23. Application SubsystemExample installed and resolvedComposite ACTIVE Application RESOLVED bundle RESOLVED transitive bundle RESOLVED
  24. 24. Second Application Subsystem installed andExample startedComposite ACTIVE Application RESOLVED Application ACTIVE bundle bundle RESOLVED ACTIVE transitive bundle transitive bundle ACTIVE ACTIVE
  25. 25. Second ApplicationExample Subsystem uninstalledComposite ACTIVE Application RESOLVED Application UNINSTALLED bundle bundle RESOLVED UNINSTALLED transitive bundle transitive bundle RESOLVED UNINSTALLED
  26. 26. First Application SubsystemExample uninstalledComposite ACTIVE Application UNINSTALLED Application UNINSTALLED bundle bundle UNINSTALLED UNINSTALLED transitive bundle transitive bundle UNINSTALLED UNINSTALLED
  27. 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
  28. 28. Demo Time: Colors by WebSphere
  29. 29. Colors by WebSphere: Bundles and Services colors.provider.redcolors.web colors.blender colors.provider.green colors.provider.blue colors.api
  30. 30. Colors by WebSphere: Color services Color services colors.provider.redcolors.web colors.blender colors.provider.green colors.provider.blue colors.api
  31. 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. 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
  33. 33. Thank you! Any questions?

×