Lessons Learned: 5 Years of Building Enterprise OSGi ... JUnit, FIT, Spring DM, Jetty, CICS-Adaptor,...
46
© 2009 by Martin Lippert; made available under the EPL v1.0 | April 23rd, 2009 Lessons Learned: 5 Years of Building Enterprise OSGi Applications Martin Lippert (akquinet it-agile GmbH)
Transcript of Lessons Learned: 5 Years of Building Enterprise OSGi ... JUnit, FIT, Spring DM, Jetty, CICS-Adaptor,...
© 2009 by Martin Lippert; made available under the EPL v1.0 | April 23rd, 2009
Lessons Learned: 5 Years of Building Enterprise OSGi Applications
Martin Lippert (akquinet it-agile GmbH)
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Overview
• Background• Structure matters• Extensions & Services• Dynamics• Integration• Build & Provisioning
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Background
• Enterprise Business ApplicationsOn top of OSGiDeveloped since (2004, Eclipse 3.0)No classical RCP stuff… ;-)
• Client apps using:Swing, Hibernate, JDO, JDBC, JNI, SOAP, a lot of Apache stuff, JUnit, FIT, Spring DM, Jetty, CICS-Adaptor, …
• Server apps using:JDO, Hibernate, SOAP, REST, Tomcat, Spring DM, CICS-Adaptor, HTTP, a lot of custom libs, Memcached, …
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Characteristics
• Highly integrated systemsBroad variety of backend systemsAll kinds of technologies used for integration
• Different deliverablesDifferent rich client configurationsDifferent standalone configurationsDifferent server container setups
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Structure matters
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Dependencies
Managing dependencies within large systemsis one of the most critical success factors for healthy object-oriented business applications
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
What kind of dependencies?
• Dependencies between:Individual classes and interfacesPackagesSubsystems/Modules
• Dependencies of what kind?UsesInheritsImplements
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Experiences
“Less coupling, high cohesion”is no theoretical blah
OSGi makes you thinkabout dependencies
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Observations when using OSGi
• Design flaws and structural problems often have a limited scope
Problems remain within single bundlesNo wide-spreading flaws
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Import-Package vs. Require-Bundle
• We used Require-Bundle a lot• That was a very bad decision
• Why?
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
What is the difference?
• Require-BundleImports all packages of the bundle, including re-exported bundle packages
• Import-PackageImport just the package you need
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
What does it mean?
• Require-BundleDefines a dependency on the producer Broad scope of visibility
• Import-PackageDefines a dependency on what you needDoesn't matter where it comes from!
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
When to use what?
• Prefer using Import-PackageLighter coupling between bundlesLess visibilitiesEases refactoring
• Require-Bundle only when necessary:Higher coupling between bundlesUse only for very specific situations:
split packages
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Keep Things Private
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Bundle API
• What should you export from a bundle?• The easy (stupid) way:
Export everything
• That is a really bad idea:If everything is visible, everything will be used by someoneBroad visibilityHigh coupling between components
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Instead: Think about your APIs
• Export only the public API of a bundleLess is moreThink about what is the API of a componentAPI design is not easy
• Don’t export anything until there is a good reason for itIts cheap to change non-API codeIts expensive to change API code
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Your Buddies are Your Enemies
Don’t use buddy loading to solveall your dependency problems
mostly it is your fault(structural problem, design flaws)
Use with care to workaround libraryclassloading problems
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Composing
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Structuring Bundles
Just having bundles is not enough
You still need an architectural viewYou still need additional structures
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Your Bundles shouldn't end up like this
Go! Get some structure!
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
What we do
• Bundle rules in the smallSeparate UI and coreSeparate service implementations and interfacesIsolate backend connectors
• Bundle rules in the mid-sizeAccess to resources via services onlyAccess to backend systems via services onlyTechnology-free domain model
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
What we do
• Bundle rules in the largeSeparate between domain featuresSeparate between applications / deliverablesSeparate between platform and app-specific bundles
• Don’t be afraid of having a large number of bundlesMylynWorking SetsPlatforms
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Shippable units
• Bundle sets form different productsDifferent clientsDifferent server-side apps
• Easy to deploy different apps, but not for free• You need:
Less bundle dependenciesPluggable units (adding stuff from outside)
• Configuration code is a bad smell
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Refactoring Bundles
“A good design today might be a bad one tomorrow”
Refactor early, refactor often
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Don’t forget to test
• JUnit-Tests wherever you can(TDD preferred, of course)
• Don’t rely on the OSGi runtime
• Test bundle-internals?No, just the public API is good (black-box)Yes, I would like more tests (while-box)
x-friendsFragmentsSeparate source folders
Having both is a good idea
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Extensions and/or OSGi Services
(borrowed from Peter Kriens)
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Experiences
• Extension Points are really useful and powerfulAllows you to implement pluggable appsDecouples your systemForces Dependency InversionEases scaling up
• You can easily misuse themWe used extension points for all kinds of thingsWe used them staticallyWe used them for N-to-one relationships
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
OSGi Services vs. Extension-Points
• Some things are like extensions• Some things are like services
• Use the appropriate mechanism
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Dynamics
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Dynamics are hard
Its hard to build a really dynamic system,you need to change your mindset
Think about dependenciesThink about services
Think about everything as of being dynamic
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Dynamics are hard
It’s even harder to turn a static systeminto a dynamic one
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Integration
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Integration is easy
Integrating an OSGi system into anexisting environment is easy
OSGi runtimes are easy to start and to embedClear separation between inside and outside world
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Experiences
• Integrate existing rich client app into proprietary client container
Ugly boot-classpath additions like XML parser stuffSelf-implemented extension model using classloaders in a strange wayUsed a large number of libs that where not necessarily compatible with the existing rich client app
• Integration went smoothlyjust launch your OSGi framework and you are (mostly) done
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Integration can be hard
• Using existing libraries can be hardSometimes they do strange classloader stuffStart to love ClassNotFoundException, it will be your best friend for some time
• The Context-Classloader hellSome libs are using context-classloaderOSGi has no meaning for context-classloaderArbitrary problems
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Experiences
• We got every (!) library we wanted to use to work within our OSGi environment
Rich-client on top of EquinoxServer-app on EquinoxServer-app embedded into Tomcat and Jetty using Servlet-Bridge
• But it can cause some headaches at the beginning
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Build & Provisioning
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Build
• An automated server-side build is pricelessPDE-BuildCustom ANT-BuildCruiseControlHudsonUnit-TestsPMD, Checkstyle, FindBugs, etc.
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Experiences
• Even though its server-side - it should be fastLong-running builds are a bad smell
• Produce ready-to-use packagesAdditional installation work is tedious and errorprone
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Provisioning
• We use p2, of course… - Just kidding…
• Used zipped install package• Simple solutions to simple problems… ;-)
• Adopted existing self-implemented server-side update mechanism
But avoid tedious publishing steps of new builds
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Conclusions
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Looking back
• Large OO system, grown over years• Its still easy and fast to add/change features
• I think OSGi is a major reason…• But why?
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
OSGi led us to…
• Thinking about structure all the timeAvoids mistakes early (before the ugly beast grows)Less and defined dependenciesNo broken windows
• Good separation of concerns• Dependency inversion & pluggable architecture
easy to add features without changing existing parts
• Many small frameworksbetter than few overall ones
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
Conclusions
Never again without OSGi
You will love itYou will hate it
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
And in the end its your best friend
Lessons Learned: 5 Years of Building Enterprise OSGi Applications | © 2009 Martin Lippert; made available under the EPL v1.0
• Questions and feedback welcome!
• Let us know if you need assistance!!!• Visit us at our booth!!!
Martin Lippert: [email protected]
Thank you for your attention!
