Hints and Tips for Modularizing Existing Enterprise Applications (OSGi Community Event 2012)

Uploaded on

Presentation given at the OSGi Community Event in 2012 on an approach to modularizing existing Java EE applications using OSGi

Presentation given at the OSGi Community Event in 2012 on an approach to modularizing existing Java EE applications using OSGi

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Graham Charters - Senior Technical Staff Member, WebSphere Application Server October 2012 Hints and Tips for Modularizing Existing Enterprise Applications Graham Charters © IBM Corporation 2012
  • 2. Agenda  Motivation for a Modular Enterprise  Approaches to OSGi Adoption  A Staged Approach in Detail  Summary 2 © IBM Corporation 2012
  • 3. Modularity Issues in Java EE Java EE modularity is inadequate Across apps - each archive typically contains all required libraries – Common libraries/frameworks get installed with each application – Multiple copies of libraries in memory webB.war WEB-INF/classes/servletB.class WEB-INF/lib/json4j.jar webC.war WEB-INF/lib/commons-logging.jar WEB-INF/classes/servletC.class WEB-INF/lib/junit.jar… WEB-INF/lib/json4j.jar WEB-INF/lib/commons-logging.jar WEB-INF/lib/junit.jar… plankton.v1 Within apps - 3rd party libraries consume other 3rd party libraries leading to conflicting versions on the application classpath. 3 plankton.v2 © IBM Corporation 2012
  • 4. Enterprise OSGi Specifications are growing coverage  First specification released 2010 added: – Web Applications (WAR -> WAB) – JNDI (including OSGi Service scheme) – Transactions – Blueprint (inspired by Spring) – Remote Services  Second specification released 2012, added: – Subsystems (standard application model) – Repository – Resolver  Work in the pipeline – EJB – CDI – Blueprint transactions – Blueprint enhancements  Platforms are plugging the gaps: Apache Aries, Eclipse Virgo, Apache Geronimo, WebSphere Application Server, JBoss AS, Glassfish, ... your mileage may vary... 4 © IBM Corporation 2012
  • 5. A Staged Approach  Lots of good reasons to improve modularity but don‟t have to achieve all in one go – “Big bang” =often=> “damp squib”  Incremental successes are successes that help build and sustain momentum  A bad practice may still be a better practice (a means to an end) A How? B C D 5 © IBM Corporation 2012
  • 6. Useful Tools  Many tools help with OSGi development, including bundle generation from simple configuration – Rational Application Developer – IBM WebSphere Application Server V8.5 Developer Tools V8.5 – BND – BNDTools – Maven-bundle-plugin – BND Ant Task – ...  Example taken from modularizing the Apache Geronimo DayTrader application.  DayTrader is built using maven and so maven-bundle-plugin snippets are used throughout. 6 © IBM Corporation 2012
  • 7. Strategies  A number of possible approaches: – Hargrave & Kriens: “Single Bundle” – Feng & Charters: “One to One” – Nottingham & Charters: “Fragments” (a “work in progress”) 7 © IBM Corporation 2012
  • 8. Hargrave & Kriens  JavaOne 2008: http://www.osgi.org/wiki/uploads/Links/TS-5122.pdf  Approach Summary: 1. Single bundle project with all dependent jars on Bundle-Classpath 2. Over time, pull out dependent jars as bundles  Focuses on Java SE: – Does not consider Java EE classloaders – Does not consider Java EE component models  Surfaces OSGi slower, but delivers incremental benefits bundle entities application bundle entities log entities log core ejb3 core core ejb3 ejb3 log 8 © IBM Corporation 2012
  • 9. Feng & Charters  ApacheCon 2009: http://people.apache.org/~lresende/presentations/felix%20goes%20to%20tuscany.pdf  Approach Summary: 1. Convert each build module directly to an OSGi Bundle 2. Analyze and refactor  Focused on Java SE – No consideration for Java EE classloaders – No consideration for Java EE component models  Motivated by need to deliver assembly subsets  Surfaces OSGi early, but longer lead-time to first success soap soap wsappclient entities entities soap wsappclient entities beans log beans log wsappclient core web web core core streamer json-proxy json-proxy ejb3 9 web streamer streamer json-proxy ejb3 ejb3 © IBM Corporation 2012
  • 10. Nottingham & Charters  EclipseCon 2012: this deck  Approach Summary: 1. Replicate existing classloading in OSGi using bundle fragments 2. Incrementally separate out individual bundles 3. Adopt OSGi best practices  Considers Java EE classloading and component models  Surfaces OSGi early, and incrementally - a staged approach soap wsappclient entities wab web app-host wab beans log web core ejb3 core log web app-host ejb3 core log streamer json-proxy ejb3 10 © IBM Corporation 2012
  • 11. Stage 1: Understanding the starting point Bootstrap  Java EE prescribes a hierarchical classloading model  Assuming “parent first” and “multiple”: – Each Application has own classloader – Each WAR has own class loader – WAR has visibility to Application classes – WAR prefers Application classs, Application prefers System classes, etc...  OSGi modularity enforced through class visibility using classloaders  Migration strategies need to consider the impact of this change – e.g. replicate visibility relationships of existing application in OSGi 11 Extensions System Application WAR Application WAR WAR © IBM Corporation 2012
  • 12. Replicating Java EE classloading: Classloaders  Preserve Application and WAR roles  Application -> Application Host Bundle – Add application modules to fragments of host bundle  Web App Archive -> Web Application Bundle – Add WEB-INF/classes to BundleClasspath – Extract WEB-INF/lib jars and add as fragments of Web Application Bundle  We now have two classloaders just as we did in Java EE  System app-host Application ejb3 core log wab WAR  We also have full visibility of the modules web 12 © IBM Corporation 2012
  • 13. Maven-bundle-plugin - Application Host Bundle Example ... <parent> ... </parent> <packaging>bundle</packaging> bundle artefact type to be built <groupId>org.apache.geronimo.daytrader.modules</groupId> <artifactId>app-host</artifactId> <version>0.1</version> <name>DayTrader :: Modules – Application</name> <description>DayTrader Application Module</description> plugin uses this as default bundle metadata <dependencies> ... </dependencies> the dependencies to build against <build> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> ... </instructions> </configuration> </plugin> </plugins> </build> </project> 13 extra bundle configuration (e.g. exports, imports, etc) © IBM Corporation 2012
  • 14. Maven-bundle-plugin - Fragment Bundle Example <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Fragment-Host>org.apache.geronimo.daytrader.modules.daytrader-app-host</Fragment-Host> </instructions> </configuration> </plugin> Fragment-Host: org.apache.geronimo.daytrader.modules.daytrader-app-host 14 © IBM Corporation 2012
  • 15. Replicating Java EE classloading: Delegation  App and wab can‟t see the container apis from the System Classloader  Wab can‟t see app classes  Solution: – Add package imports for container packages to app and wab – Add package exports to app-host fragments required by wab – Add require bundle from wab to app  Note: delegation semantics are not identical to Java EE – WAS provides all imported packages (close to “parent-first”) – Bundle provides everything else – Now have control over what wab & app-host see from the System classloader 15 System X app-host X X wab © IBM Corporation 2012
  • 16. Determining the Container APIs (System Classloader) Warning: This step will vary depending on target server  <was_install>/dev contains the APIs in was_public.jar and JavaEE/jee.jar  Take Export-Package entries and add as Import-Package entries on app and wab bundles  If using BND-based tools then can wildcard values (e.g. com.ibm.*, javax.*)  <was_install>/dev includes a pom for WAS API for maven development (available since v8.0)  Applications should not rely on packages not defined in <was_install>/dev 16 © IBM Corporation 2012
  • 17. Maven-bundle-plugin: Container delegation mvn install:install-file -DgroupId=com.ibm.websphere.appserver -DartifactId=was_public -Dversion=8.5 Dpackaging=jar -Dfile=was_public-8.5.0.jar maven dependency on WAS API maven-bundle-plugin (pom.xml) daytrader-app.jar META-INF/MANIFEST.MF 17 <dependency> <groupId>com.ibm.websphere.appserver</groupId> <artifactId>was_public</artifactId> <version>8.5</version> </dependency> <Import-Package> <!-- from was_public.jar --> com.ibm.*, ... <!-- from jdk & jee.jar --> javax.* </Import-Package> Import-Package: com.ibm.websphere.ActivitySession;version="1.1.0", ... javax.xml.rpc.server;version="1.1.0", javax.xml.rpc.soap;version="1.1.0" © IBM Corporation 2012
  • 18. Maven-bundle-plugin: WAB to App Delegation  Fragment exports (daytrader package naming allowed wildcarding) <instructions> <Fragment-Host>org.apache.geronimo.daytrader.modules.daytrader-app-host</Fragment-Host> <Export-Package>org.apache.geronimo.samples.daytrader.core*</Export-Package> </instructions>  Wab Require-Bundle <instructions> <Require-Bundle>org.apache.geronimo.daytrader.modules.daytrader-app-host</Require-Bundle> </instructions> wab Require-Bundle: app-host Export-Package: ... app-host core log entities ejb3 ejb3 18 core log © IBM Corporation 2012
  • 19. A Note on Require-Bundle  Uses – Merge split package – When there‟ll only ever be one provider (e.g. extension points)  Considered bad practice because: – The required bundle can change what it provides - brittle in the face of refactoring 19 © IBM Corporation 2012
  • 20. Extenders: Enabling Component Models  Web Components, EJBs, Persistence Contexts, Blueprint Beans all handled by extenders  Extenders look inside bundles for code/metadata to process  Extenders typically require a bundle to „opt in‟ using a manifest header – host must opt-in  JPA entities not permitted to come from fragments: “...any entity classes must originate in the bundle’s JAR, it cannot come from a fragment.” <!-- maven-bundle-plugin configuration snippet--> <instructions> ... <!-- Opt in for EJB Extender --> <Export-EJB>&lt;&lt;EMPTY&gt;&gt;</Export-EJB> </instructions> <!-- maven-bundle-plugin configuration snippet--> <instructions> <!-- Opt in for Web Extender --> <Web-ContextPath>/daytrader</Web-ContextPath> </instructions> 20 Tip: <<EMPTY>> allows empty header in BND (needs a recent version of maven-bundle-plugin) app-host Export-EJB: wab Web-ContextPath: /daytrader © IBM Corporation 2012
  • 21. OSGi Application Warning: this step will vary depending on target server  Servers typically enable a deployment artefact and build tools for an application  Example was targeting WebSphere, so used a .eba (a zip file with an application manifest) – RAD/WDT tools make development simple – Ant zip task and eba-mavenplugin (Apache Aries) can also be used in builds <plugin> <groupId>org.apache.aries</groupId> <artifactId>eba-maven-plugin</artifactId> <version>0.4-SNAPSHOT</version> <extensions>true</extensions> <configuration> <generateManifest>true</generateManifest> <instructions> <Application-SymbolicName> ${project.artifactId} </Application-SymbolicName> </instructions> </configuration> </plugin> Application-Name: DayTrader Application Application-SymbolicName: org.apache.aries.samples.daytrader Application-ManifestVersion: 1 Application-Version: 0.1 Manifest-Version: 1.0 Application-Content: daytrader.app;version="[0.1,1.0)", daytrader.wab;version="[0.1,1.0)" wab app-host daytrader.eba © IBM Corporation 2012
  • 22. Stage 2: Factoring out Bundles  Now the application‟s running in OSGi we can start to split out the fragments as independent, re-usable bundles  Strategy: – Do one fragment at a time – Start with the leaf dependencies • Wab bundle contents first, then the app bundle • Project build dependencies help with identification • Third-party libraries • “shared libraries” (if runtime supports this concept) – Detach from host and calculate the package imports & exports wab wab Import-Package: daytrader.web Fragment-Host: wab web 22 Export-Package: daytrader.web web © IBM Corporation 2012
  • 23. Split Package Strategies  A split package is a package exported by more than one provider where the contents differ – Sub-set/superset relationship - e.g. javax.transactions – Intersecting or non-intersecting subsets – Not different releases  Split packages hint at poor modularity or naming  Consumers often need access to all providers, but OSGi Import-Package will only wire to one  Solution: – Combine jars with split packages into a single bundle • Multiple jars on single Bundle-Classpath or • Fragment Bundles attached to a single host log Bundle-Classpath: ., A.jar. B.jar Export-Package: p A  This approach is tactical and is addressed in Stage 3 23 B p p © IBM Corporation 2012
  • 24. Converting Jars to Bundles  Using RAD/WDT? – Convert Java projects to OSGi Bundle Projects (also works for EJB and WAR) – Or import “Java Archive into OSGi Bundle” • Wraps Jar in a Bundle <packaging>bundle</packaging>  Using maven or ant? – Modify build to produce bundles (e.g. maven-bundle-plugin or bnd in ant task) – Use wild-cards to generate initial imports/exports then refine... 24 <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> ... </instructions> </configuration> </plugin> © IBM Corporation 2012
  • 25. Third-party Libraries  Applications often use third-party libraries, such as open source – DayTrader uses commons.logging  Many now come with OSGi metadata  Most others have been bundlized by repository projects – Eclipse Orbit - bundlized, pedigree reviewed for Eclipse projects – Apache Felix Commons – SpringSource Enterprise Bundle Repository  or by other OSGi-based projects – Apache Tuscany – Apache ServiceMix – Ops4J Pax *  Use these if available  But what if you can‟t find a bundlized library...? 25 © IBM Corporation 2012
  • 26. Bundlizing third-party libraries  Use tools to calculate manifest – RAD/WDT Import -> Java Archive into an OSGi Bundle – BND – Refine Imports/Exports  If library required to work inside and outside OSGi? – inject OSGi manifest into existing jar – Doesn‟t work for signed Jars – Can‟t aggregate multiple Jars  If library only required to work in OSGi – Wrap jar in bundle (add jar to BundleClasspath) – Works for signed jars – Can aggregate multiple jars, if necessary 26 log log inject Export-Package: org.c... org/apache/commons/... log wrap log Bundle-Classpath: ., log.jar Export-Package: org.c... log © IBM Corporation 2012
  • 27. The story so far...  The first two stages have: – Taken Java EE application and run in OSGi – Decomposed single deployment artefact into multiple bundles  Now have the potential to: – Understand the application architecture; modules used and their relationships (OSGi Application Console) – Remove duplicate deployment binaries (single bundle in repository) – Remove duplicate runtime binaries (share bundle in server) – Reduce operational costs and errors - deploy shared binaries based on application needs – Determine which binaries are in use (e.g. to apply critical fix)  But there‟s more... 27 © IBM Corporation 2012
  • 28. Stage 3: Incrementally Adopt Best Practices  Stage 2 documents the „as-is‟ architecture, warts-„n‟-all  OSGi Best Practices show how to make the most of OSGi – Hopefully you attended Emily Jiang‟s session – http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html  Adopting best practices leads to: – High cohesion - bundles with clear and distinct roles in the architecture – Loose coupling - flexible, but necessary, dependencies  ...which all leads to greater agility, flexibility and re-use – Development teams can understand and explain the architecture and are no longer afraid to change the code – Applications can evolve and new application can be created at a pace that enables, rather than inhibits, the business 28 © IBM Corporation 2012
  • 29. Summary  Moving enterprise applications to OSGi helps: – increase understanding of application architecture – increase module cohesiveness – reduce module coupling  Leads to greater application agility through re-use and understanding of impact of change  A staged approach to adoption delivers value sooner and in-line with investment  With the wealth of tools, runtimes, and existing assets, it‟s never been easier to adopt OSGi  What OSGi could do to better: – Enable „fragments‟ to define everything except a classloader – Enable JPA entities in fragments 29 © IBM Corporation 2012
  • 30. Questions 30 © IBM Corporation 2012
  • 31. Trademarks  Eclipse and the Eclipse logo are trademarks of Eclipse Foundation, Inc.  Apache, Apache Felix, Felix, the Apache Felix project logo, Apache Tuscany and the Apache Tuscany project logo are trademarks of The Apache Software Foundation.  Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.  IBM and the IBM logo are trademarks of International Business Machines Corporation, registered in many jurisdictions.  Other marks may be trademarks or registered trademarks of their respective owners. 31 © IBM Corporation 2012