Java Modularity with OSGi


Published on

This presentation shows the benefits of modularity and component/service based development in Java

Published in: Technology
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Java Modularity with OSGi

  1. 1. Modular Java(Component Oriented Programming with OSGi) December 2009 Ilya Rybak
  2. 2. Agenda Modularization and Object-Oriented Modularization in Java Component-Oriented buzz Introduction to OSGi Java 7 „wanted‟ list 2
  3. 3. Modularization Recycling old ideas that were raised in the early 70s o High Cohesion o Low Coupling Manage growing complexity o Modularization minimizes complexity by creating proper boundaries between the parts that compose a system Support dynamic extensibility o Properly modularized systems are easier to maintain and extend o Changes are more localized and affect less of the overall system 3
  4. 4. Complexity vs. Productivity 4
  5. 5. Object-Oriented One of the primary goals of object oriented programming (OOP) was, and still is, Re-Use It has mostly failed in that goal! 5
  6. 6. What went wrong? Focus in OO was on encapsulation of instance variables, which is some form of modularization, but granularity is too small Coupling o Classes can almost never be used in isolation, they depend on other classes o Those classes depend on other packages, which depend on other JARs/DLLs… o OO systems become tangled webs quickly 6
  7. 7. A Solution? Re-use of classes outside their original context is hard, so. . . Leave them where they are, Give up and hide by a façade and call it duplicate "SOA" Patterns like SOA, Factories, Dependency Injection, Inversion of Control are trying to minimize the consequences of the OOP’s lack of modularization 7
  8. 8. Modularization in Java 8
  9. 9. What‟s a Module? Beyond the simple means of packaging, a true module should define:  Identity and scope  Unit of deployment  Dependencies  What it provides to other modules It is up to a module system to see if a module‟s requirements can be satisfied and make sure consumers are „wired‟ to providers 9
  10. 10. JARsPackaging o Classes encapsulate data o Packages contain classes o Jars contain packagesVisibility Access o private o package-private o protected o publicJars have no module characteristics 10
  11. 11. Java application 11
  12. 12. “Jar Hell” 12
  13. 13. Class Loading 13
  14. 14. Modularization in Java - Issues Classes are too fine grained, packages are too simplistic, class loaders are too low level Jars provide packaging, but… o Have no runtime representation (no identity and scope) o Have no explicit dependencies o Can not be used to restrict access - public class is globally visible o Are not true deployment units Severe problems like split packages o Multiple jars have classes with the same name in the same package No versioning support o Order on CLASSPATH define chosen version o Single version of a class in the VM Has no proper extension/collaboration model In fact, Java never planned introducing module concept, yet… 14
  15. 15. Assembly Assemblies are the building blocks of .NET applications. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality .NET has the built-in module system o Early attempts were made already in Windows 2000 It defines o security boundary o type boundary o reference scope boundary o version boundary o deployment unit 15
  16. 16. What‟s a component?The most common analogy - Lego? Lego is a poor analogy o Dead lump of plastic – no life cycle o Not really replaceable - try replacing a block in already built model o Not really reusable - try using a „Duplo‟ block in a „Lego‟ model Has characteristics closer to that of an object in OO 16
  17. 17. What‟s a component? A better analogy – Bees! Active participants in the system Aware of and adapt to their environment May provide services to other components and use services from other components Have a life cycle 17
  18. 18. EnvironmentEcosystem in which a component lives, e.g.:beehive, Java VM When the environment is good, the component flourishes. When the environment is harsh, the component survives. When very harsh, the component dies. 18
  19. 19. Introduction to OSGi OSGi™ - The Dynamic Module System for Java o Formerly Open Services Gateway Initiative Driven by OSGi Alliance - consortium of vendors o Non-profit corporation founded in 1999 Mission: Build ecosystem to support component based development in Java Alcatel-Lucent ProSyst Software GmbH Aplix Corporation Qualcomm Deutsche Telekom Red Hat Ericsson Mobile Platforms SAP AG AB Siemens AG Hitachi, Ltd. Siemens Enterprise IBM Corporation Communications LinkedIn Software AG Makewave Sonatype Inc. Mitsubishi Electric SpringSource (a Division of Corporation VMware) NEC Corporation Sun Microsystems, Inc. NTT Telcordia Technologies, Inc. Oracle Corporation TIBCO Software Inc. Paremus, Ltd. Westell Inc. Progress Software 19
  20. 20. OSGi is about… Module system for the Java platform o Building systems from smaller components o Includes visibility, security rules, dependency management and versioning control Dynamic o Installing, starting, stopping, updating modules, all dynamically at runtime  No downtime or 24 7 are the terms customers like to hear Service-oriented collaborative model o POJOs can be registered as services, consumed and managed inside a VM, again, all dynamically at runtime 20
  21. 21. Work Groups Multiple groups define the specifications o Core Platform Expert Group (CPEG) – Core framework o Mobile Expert Group (MEG) – Mobile o Vehicle Expert Group (VEG) – Automotive o Enterprise Expert Group (EEG) – Enterprise o Residential Expert Group (REG) – Home Automation No more „All in One‟ solution – each group has its own purpose and objectives 21
  22. 22. Evolution path Original use case (Home Automation) faltered around 2000 OSGi used in niche areas (automotive, mobile) for a decade now Eclipse 3.0 released June 2004 - First Eclipse platform built on OSGi Gradual adoption and recognition for OSGi after Eclipse Currently undergoing widespread adoption in the enterprise market 22
  23. 23. OSGi Architecture and Layers The OSGi Platform specifies a modular architecture for dynamic component based systems o Execution Environment o Module Layer o Life Cycle Layer o Service Layer o Security Introduces Bundles as modules L0 - JRE Level a publish/find/bind in-VM service model L3 – Manages the life cycle modules L2 Provides L1 - Creates the concept of of a bundle Security •OSGi Minimum Execution Environment instances • Standard methods for registering service • Fine grained use classes from (bundles) thatJava security modeland • Discoveron events for application Based •CDC/Foundation to services from other components • component lifecycle, e.g.: installing, each other and bindA only way to use the XYZ • Example: in a controlled wants •J2SE-1.3 Vendor according stopping, updating B (could be multiple other starting,provided byand bundle service to system Vendor … • implementations of XYZ) constraints.API for with packaging, Standard Deals registering, listening, •J2SE-1.5 • and acting on events versioning and dependencies using certificates •JavaSE-6 can be expressed Constraints • from signed jars or attributes for bundle, service, etc. No VM restarts 23
  24. 24. BundleBundle is a module in OSGi terminology o Simply a JAR file plus module metadata stored in jar manifest • Bundle Identity • Dependencies • VersioningWhat does a bundle JAR contain? o Java classes (i.e., standard JAR file content) o Resources (e.g., configuration files, images, etc.) o Native code o Embedded JAR files • Bundles can have their own class pathA bundle JAR file can be both a standard JAR file and a bundle at the same time 24
  25. 25. Bundle Manifest META-INF/ Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.servicemix.kernel.filemonitor Bundle-Version: Bundle-Name: Apache File Monitor Bundle-Vendor: Apache Foundation Bundle-RequiredExecutionEnvironment: J2SE-1.5 Bundle-Classpath: ., libmonitor.jar, libtest.jar, libreport.jar Bundle-Activator: org.apache.servicemix.filemonitor.FileMonitorActivator Bundle-Description: This bundle monitors the deploy directory for new deployments Import-Package: org.apache.commons.logging,;version="1.4“, javax.servlet;version=“[2.4,2.5]" , org.osgi.service.packageadmin Export-Package: org.apache.jmx.facade, org.apache.servicemix.kernel.filemonitor; version="“ 25
  26. 26. Bundle Life Cycle 26
  27. 27. Lazy BundlesBundles can be activated on demand o Defer the creation of the bundle class loader and activation of the bundle until the bundle is first used o Can save resources and initialization time on startup o Triggered by classloading event META-INF/ Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.servicemix.kernel.filemonitor Bundle-Version: Bundle-Activator: org.apache.servicemix.filemonitor.FileMonitorActivator Bundle-ActivationPolicy: lazy 27
  28. 28. Bundle Activator  Bundle-Activator: Like main() for your bundle  Bundles can hook into their life cycle by implementing a bundle activator interface o Notifies them when they are started/stopped o Gives them access to their bundle context • Which is how they access framework capabilities, e.g.:  Bundle life cycle management  Publishing or looking up services  Simple Java interface public interface BundleActivator { public void start(BundleContext context) throws Exception; public void stop(BundleContext context) throws Exception; } 28
  29. 29. Resolving a Bundle exported package install package dependency resolve existing bundle bundle resolution bundle OSGi Framework  Resolution of dependencies at deployment  If resolution fails, bundle is not available for use  No runtime CNFE unless you‟re still relying on Class.forName(…)  Services and lifecycle methods not called until AFTER resolution 29
  30. 30. Multi-version support Export-Package: foo; Import-Package: foo; Export-Package: foo; version="1.3.0“ version=“[1.3.0, 2.0.0)“ version="1.0.0" foo foo foo  Same package can be installed with different versions  Bundles explicitly expose internal packages (i.e., export) o Exporters export precise package versions  Export-Package: bar; version="1.0.0“  Bundles explicitly declare dependencies on external packages (i.e., import) o Importers may specify an open or closed version range  Import-Package:; foo version="[1.0.0,1.5.0)"  Allows staged migration of multiple components 30
  31. 31. Controlling Dependencies Export-Package: foo; Import-Package: foo; Export-Package: foo; version="1.0.0“; version=“1.0.0” ; version="1.0.0" provider=“Pooh” provider=“Pooh” foo foo foo  Arbitrary export/import attributes for more control o Exporters may attach arbitrary attributes to their exports o Importers can match against arbitrary attributes o Exporters may declare attributes as mandatory  Mandatory attributes provide simple means to limit package visibility o Importers influence package selection using arbitrary attribute matching 31
  32. 32. Class space consistency Import-Package: foo Export-Package: foo Export-Package: bar; uses:="foo" Import-Package: foo, bar Export-Package: foo  Exporters may declare package “uses” dependencies  Exported packages express dependencies on imported or other exported packages, which constrain the resolve process  The framework must ensure that importers do not violate constraints implied by “uses” dependencies 32
  33. 33. Class Filtering Exporters may declare that certain classes are included/excluded from the exported package o Ideal solution for building facades around existing jars Export-Package: foo; exclude:="*Impl", Import-Package: foo; Import-Package: foo foo; friend="yes“; mandatory:="friend" friend=“yes” foo foo exclude:=”*Impl” friend=”yes” include:=”*” 33
  34. 34. Bundle-to-Bundle dependency Bundle-SymbolicName: A Require-Bundle: A Export-Package: bar, foo Export-Package: bar  Allows for tight coupling of bundles when required  Import everything that another, specific bundle exports 34
  35. 35. Bundle Fragments Fragment-Host: B Bundle-SymbolicName: B Export-Package: foo Export-Package: bar foo bar, Import-Package: baz Import-Package: woz baz woz,  Allows bundle content to be extended  A special bundle that attaches to a host bundle and uses the same class loader o Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles 35
  36. 36. Bundles - Summary  Package level dependencies i.e.: Export/Import-Package: • Can be mandatory(default) or optional  Support for versioning  Support arbitrary attributes and filters  Control dependency graph with uses attribute  Bundle-to-Bundle relationship with Require-Bundle:  Fragments as bundles extender model META-INF/ … Import-Package: org.apache.commons.logging; resolution:=optional,; version=“[1.3,1.5.0]" , org.osgi.service.packageadmin Export-Package: org.apache.jmx.facade; role=“admin“; mandatory:=“role" org.apache.servicemix.kernel.filemonitor; uses:=“org.apache.commons.logging”; exclude:= “*Impl,*Helper*” Require-Bundle: org.apache.felix.http; bundle-version="[,“ 36
  37. 37. Classloading The standard Java classloading hierarchy 37
  38. 38. Classloading – Java EE 38
  39. 39. Classloading - OSGi Tree is simply the wrong shape! What we really need is a graph 39
  40. 40. Class Search Order  Classloading in OSGi is fast compared to the conventional CL tree model o Classloaders wiring happens at the bundle‟s resolution time o No walking up and down the parent tree when looking up classes  Classloading event is directly delegated to the owning classloader 40
  41. 41. OSGi Module System - Summary  OSGi technology bridges the gap in the area that Java has not addressed  Promotes a better structuring of your application code by defining clear boundaries  Robust classloading model that overcomes the deficiencies of the conventional Java  Control over versioning  Lifecycle  Modularization is rewarded when creating new systems and modifying existing ones  No silver bullet, bad code and bad ideas are still bad 41
  42. 42. What else is missing? 42
  43. 43. Service-Oriented-Architecture for the JVM OSGi introduces service layer as primary means of collaboration between bundles Lightweight implementation o No protocols, no stubs - direct Java method calls o Cross-VM communication is out of scope (addressed by EE group) Service Registry is where decoupling between provider and consumer happens offer Registry query 43
  44. 44. Services Services are POJOs o Services are identified with components o Registered and looked up using their interface name Follow publish/find/bind model o Used as bundle‟s input/output ports o Allow loose coupling between modules – modules can be substituted Allow lazy instantiation and late binding Meta-data is decoupled from implementation o Service properties can be queried without the need for creating service instance 44
  45. 45. Services But most importantly, services are dynamic o Static dependencies are handled by the module layer, runtime dynamics are realized through services o Services can be enabled/disabled/substituted dynamically at runtime service dependency (dynamic) package dependency (static) OSGi Framework However, there is a challenge o Fully dynamic systems require a different way of thinking  Services may come and go at any moment in time • Java programming not for faint hearted  Multiplicity of service providers 45
  46. 46. OSGi Compendium Services OSGi uses services to extend its functionality o One or more service components „bundled‟ together implementing a specific functionality o Provided separately from the OSGi core o Many services are defined as mandatory for OSGi framework providers Application architecture can be defined by a set of deployed services o Create your own profile – VM + OSGi core + required services Log Service Initial Provisioning Event Admin UPnP Http Service Declarative Services User Admin Auto Configuration Configuration Admin Application Admin Deployment Admin DMT Admin Metatype Service Monitor Admin Preferences Service Device Access Wire Admin IO Connector 46
  47. 47. Bundling existing code ... legacy code is a challenge. Many developers say things like: “My code is very modular”, or “My code doesn’t depend on very much”, or “No one uses any of my classes except from the Foo package” Unless they are already using osgi, they are wrong. Until modularity is enforced, it is not there. John Wells, BEA Analyze what you have o What are the dependencies between the JARs that make up your application OSGi bundles need manifest headers o Exported/Imported packages o Versions Good chances are your favorite open source is already „OSGfied‟ o Check with the online repository, e.g.: 47
  48. 48. Bundling existing code 48
  49. 49. Bundling existing code  Start with your existing application and all its dependent jars  Create a bundle activator (i.e.: the existing startup class or main) if needed  Put all libraries into one bundle • Super sized! • Don‟t worry, it‟ll get better  Having a working bundle (whatever the size) is a good baseline and allows for gradually replacing the dependent jars with bundles  Keep it working! 49
  50. 50. To Include or to Refer? When to refer to a library? o External API o Implementations can differ, e.g.: javax.naming, javax.transaction o Very large library o Sharing When to include a library in the bundle? o High Cohesion o Localized library version o Reduces number of dependencies 50
  51. 51. OSGi Best Practices Raw OSGi APIs are powerful but create coupling o Isolate the use of the OSGi APIs to a minimal number of classes Best practices is to write POJOs that are not coupled to a framework o There are many such application models for OSGi  OSGi Declarative Services (xml descriptors)  Apache iPOJO (annotations)  Spring-DM (formerly Spring-OSGi)  Service Application Toolkit Pick one of these application models after you got your existing application running Convert the application part-by-part 51
  52. 52. OSGi Implementations Several independently implemented OSGi frameworks exist today, including four that are available as open source software o Equinox - the most widely deployed OSGi framework today owing to its use in the core runtime of Eclipse. It is also the official RI (Reference Implementation) of the OSGi spec. o Knopflerfish - popular and mature implementation of both OSGi Release 3 and 4.1. It is developed and maintained by Makewave AB o Apache Felix - a community implementation of the OSGi Release 4.x. It is designed particularly for compactness and ease of embedding, and is the smallest (JAR size ~360K) implementation o Concierge - a very compact and highly optimized implementation of OSGi Release 3. This makes it particularly suited to resource-constrained platforms such as mobile phones. 52
  53. 53. Markets & Solutions Automotive: BMW, Volvo, Bombardier… Mobile: Nokia, Ericsson, Motorolla… Smart Home: Bosh, Siemens, Phillips… E-Health: Siemens Med… Enterprise o Currently the OSGi framework is adopted by most enterprise Java vendors for internal use as the underlying infrastructure platform o Base for the new application server generation architecture o Oracle BEA mSA – micro-service architecture built on OSGi is the base for BEA products o JBoss MicroContainer - replaces old JMX MicroKernel o IBM WebSphere, Lotus as well as other ~200 products run on Equinox o JOnAS, SpringSource DM server… o Smaller vendors, such as SpringSource and Paremus, as well as open source projects such as Apache ServiceMix and Apache Aries, are starting to promote the direct use of the OSGi programming model in developing enterprise applications, and some early adopters such as LinkedIn and VMware have started to do so 53
  54. 54. A bit of Java politics… JavaSE 7 (OpenJDK) long awaited features o G1 garbage collector o JSR 292: VM support for non-Java languages o JSR 294: Language and VM support for modular programming o Project „Jigsaw‟ – modularization of JDK(merged with JSR 294) Java 7 was expected at the end of 2009 The release date was postponed to Oct. 2010 Modularity and Jigsaw is in the center of continuous debates 54
  55. 55. Jigsaw - Motivation JDK is BIG o JDK 1.1 = 3.5Mb o JDK 6 = 65.2Mb (>1800% growth) o Startup time is relatively long • 306 classes to load for a simple “Hello World” o Difficult to evolve APIs • Deprecation has no meaning o Depending on whole JDK version is no longer feasible • Would like to depend on, e.g., Swing v2 and Concurrency v1.x • Or Swing 1.x but NO higher - now v2 can break compatibility o Doesn‟t scale down(for small devices) o Doesn‟t scale up(ME cannot run on SE) 55
  56. 56. Module (the Jigsaw way) org/company/services/ui/ module @1.0 { system jigsaw; requires module java-core @7; requires module java-swing @1.7.*; requires optional module commons-lang @ [2.4,3.0); requires private module @1.0; class; } org/company/services/ui/ public class Utils { module boolean foo(); //new access level modifier –“module” public boolean bar(); } java –m 56
  57. 57. Jigsaw - Summary No support for package-level dependencies Not dynamic – requires VM restarts on installing, updating and uninstalling a module No Lifecycle Does not offer collaboration model i.e.: services Questionable as primary development model for your application, but… A big step forward in terms of affirmation (from Sun) that modularity is important and currently missing from Java Probably the shortest path for modularizing JDK as a product 57
  58. 58. Useful Links OSGi Alliance Peter Kriens presentation Neil Bartlett‟s blog Equinox Apache Felix SpringSource repository 58
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.