Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Karaf - When OSGi Modularity meets Java world

189 views

Published on

Karaf - When OSGi Modularity meets Java world

Published in: Software
  • Be the first to comment

  • Be the first to like this

Karaf - When OSGi Modularity meets Java world

  1. 1. KARAF - WHEN OSGI MODULARITY MEETS JAVA WORLD Justinas Šlekas
  2. 2. Modularization • Ideas raised in the early 70s • High Cohesion • Low Coupling • Manage growing complexity • Modularization minimizes complexity by creating proper boundaries between the parts that compose system • Support dynamic extensibility • Properly modularized systems are easier to maintain and extend • Changes are more localized and affect less of the overall system
  3. 3. 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 
  4. 4. What went wrong? Focus in OOP was on encapsulation of instance variables, which is some form of modularization, but granularity is too small Coupling • Classes can almost never be used in isolation, they depend on other classes • Those classes depend on other packages, which depend on other JAR’s… • OO systems become tangled webs quickly
  5. 5. Module? Module should define: • Identity and scope • Unit of deployment • Dependencies • What it provides to other modules
  6. 6. What is module? A module is a self-contained component of a system, often interchangeable, which has a well- defined interface to the other components.
  7. 7. Software Development Goal One system that can evolve over time and modules can be replaced without impacting the other modules.
  8. 8. Software Development Goal (2) Multiple systems can be assembled in different products and do not have to be implemented again and again.
  9. 9. Modularity • Total control over library versions and dependencies, different versions of the same library will happily coexist in the same container • Decouple system and application modules between each other • Share classes and dependencies • Increase development agility, testing and version updating • Isolate changes within your components • Make your server go on a diet (Deploy exactly the modules and frameworks you’ll need, and no more)
  10. 10. Introduction to OSGi OSGi™ - The Dynamic Module System for Java Formerly Open Services Gateway Initiative Driven by OSGi Alliance - consortium of vendors Non-profit corporation founded in 1999 Mission - Build ecosystem to support component based development in Java
  11. 11. OSGi is about… Module system for the Java platform - Building systems from components - Includes visibility, security rules, dependency management and versioning control Dynamic - 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 - POJOs can be registered as services, consumed and managed inside a VM, again, all dynamically at runtime
  12. 12. OSGi Architecture and Layers The OSGi Platform specifies a modular architecture for dynamic component based systems - Execution Environment - Module Layer - Life Cycle Layer - Service Layer - Security Introduces Bundles as modules
  13. 13. OSGi Architecture and Layers L0 - JRE Level •OSGi Minimum Execution Environment •CDC/Foundation •JavaSE-6 •JavaSE-7 … L1 - Creates the concept of modules (bundles) that use classes from each other in a controlled way according to system and bundle constraints. Deals with packaging, versioning and dependencies
  14. 14. OSGi Architecture and Layers (2) L2 - Manages the life cycle of a bundle • Fine grained events for application and component lifecycle, e.g.: installing, starting, stopping, updating • Standard API for registering, listening, and acting on events • No VM restarts L3 – Provides a publish/find/bind in-VM service model • Standard methods for registering service instances • Discover and bind to services from other components
  15. 15. Interaction between the layers
  16. 16. Bundle Bundle is a module in OSGi terminology - Simply a JAR file plus module metadata stored in jar manifest Bundle Identity Dependencies Versioning What does a bundle JAR contain? - Java classes (i.e., standard JAR file content) - Resources (e.g., configuration files, images, etc.) - Native code - Embedded JAR files Bundles can have their own classpath A bundle JAR file can be both a standard JAR file and a bundle at the same time
  17. 17. Anatomy of a Bundle
  18. 18. Bundle manifest META-INF/manifest.mf Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.servicemix.kernel.filemonitor Bundle-Version: 2.0.0.0 Bundle-Name: Apache File Monitor Bundle-Vendor: Apache Foundation Bundle-RequiredExecutionEnvironment: J2SE-1.7 Bundle-Classpath: ., libmonitor.jar, libtest.jar, libreport.jar Bundle-Activator: org.apache.servicemix.filemonitor.FileMonitorActivator Bundle-Description: This bundle monitors directory for new deployments Import-Package: org.apache.commons.logging, org.apache.commons.io;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="1.0.0.0“
  19. 19. Bundles Dependencies By default, none of the classes in a bundle are visible from any other bundle Export packages from the source bundle and then import them into the target bundle Import-Package: org.apache.commons.logging, org.apache.commons.io;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="1.0.0.0“
  20. 20. Multi-version support
  21. 21. Controlling Dependencies
  22. 22. Bundle-to-Bundle dependency
  23. 23. Bundle Fragments
  24. 24. Bundle Life Cycle
  25. 25. Lazy Bundles Bundles can be activated on demand - Defer the creation of the bundle class loader and activation of the bundle until the bundle is first used - Can save resources and initialization time on startup - Triggered by classloading event
  26. 26. Bundle Activator - Bundle-Activator: Like main() for your bundle - Bundles can hook into their life cycle by implementing a bundle activator interface - Notifies them when they are started/stopped - 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
  27. 27. Bundles - Summary
  28. 28. OSGi classloading
  29. 29. A class space for a given bundle can contain classes from • The parent class loader (normally java.* packages from the boot class path) • Imported packages • Required bundles • The bundle's class path (private packages) • Attached fragments
  30. 30. OSGi Module System - Summary - Promotes a better structuring of your application code by defining clear boundaries - Robust class loading model that overcomes the deficiencies of the conventional Java - Versioning control - Lifecycle - Modularization is rewarded when creating new systems and modifying existing ones - No silver bullet, bad code and bad ideas are still bad
  31. 31. What else is missing?
  32. 32. Service-Oriented-Architecture - OSGi introduces service layer as primary means of collaboration between bundles - Lightweight implementation No protocols, no stubs - direct Java method calls - Service Registry is where decoupling between provider and consumer happens
  33. 33. Services Services - Services are identified with bundles - Registered and looked up using their interface name Follow publish/find/bind model - Used as bundle’s input/output ports - Allow loose coupling between modules – modules can be substituted Allow lazy instantiation and late binding Meta-data is decoupled from implementation - Service properties can be queried without the need for creating service instance
  34. 34. Services (2) But most importantly, services are dynamic - Static dependencies are handled by the module layer, runtime dynamics are realized through services -Services can be enabled/disabled/substituted dynamically at runtime However, there is a challenge - Fully dynamic systems require a different way of thinking Services may come and go at any moment in time Multiplicity of service providers
  35. 35. 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.
  36. 36. Apache Karaf • Birthdate - 16th of June 2010 • Platform running on OSGI (Apache Felix, Eclipse Equinox) • Provides a lightweight container where • Applications, Integration projects, Web Service, JMS Brokers, Java applications can be deployed • Used by ServiceMix, Geronimo projects
  37. 37. Karaf: an OSGi container Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.
  38. 38. Supported Karaf features • Hot deployment • Dynamic configuration • Provisioning • Native OS integration • Extensible Shell console • Remote access • Security framework • Managing instances
  39. 39. Karaf structure: Important Files and Folders +---bin: Startup scripts and commands +---data: Karaf work directory | +---cache: Installed bundles | +---log: Default log directory | +---tmp: Temporary files +---deploy: Directory for file system deployment +---etc: Configuration files +---instances: Instance management +---lib: Core libraries +---system: System bundle repository
  40. 40. Command line
  41. 41. Command Groups (Karaf 3.x) • bundle:* - Install and control bundles • dev:* - Development support • feature:* - Manage features • instance:* - Control of multiple instances • jaas:* - JAAS role and rights management • log:* - Log display • service:* - Manage OSGi Services • shell:* - Useful helper functions (i.e. grep, more, info) • ssh:* - SSH connections • system:* - OSGi framework management
  42. 42. Custom Commands • Add custom commands from your bundles • Extend org.apache.karaf.shell.console.OsgiCommandSupport • Add @org.apache.karaf.shell.commands.CommandAnnotation • Register command via Blueprint
  43. 43. Remote Management • Use command line via SSH: ssh-p 38031karaf@karaf-mydomain.paasplus.com • Configuration via: org.apache.karaf.shell.cfg • User and Role management via JAAS • Configure via users.properties • org.apache.karaf.command.acl.* for command specific permissions
  44. 44. Deployment Deployment of: • Bundles • Blueprint files (xml) • Features • Kar Archives • „plain“ jarfiles
  45. 45. Maven deployment Deploy via any Maven repository • Bundles • Features • Configurations Add additional repos to org.ops4j.pax.url.mvn.cfg Install features or bundles
  46. 46. Features
  47. 47. Configuration Admin Configuration can change at any time and you're expected to react to these changes; Bundles will be notified of new, updated, and removed configuration data.
  48. 48. Karaf & Spring Karaf has its own Dependency Injection API: Blueprint Blueprint is a standard defined in OSGi that allow bean definition, service definition and dependency injection Using Spring Dynamic Module we can also use Spring in Karaf. SpringDM explores bundles and load Spring xml files Spring DM allows you to interact with the world without using OSGi API in our code: in this way the code is cleaner and classes that we write (our modules) can be reused on other platforms.
  49. 49. Blueprint • Blueprint - dependency injection framework for OSGi. • Handles the wiring of JavaBeans, and instantiation and life cycle of an application. • Blueprint is expressed as an XML file. Blueprint will be expressed as a top-level element:
  50. 50. Blueprint example
  51. 51. Karaf & Web Pax Web allows Karaf to support web. Using integrated Web Server Jetty, it implements: HTTP Service API defined in OSGi Web Application API defined in OSGi Enterprise Like Spring DM, Pax Web explores Bundles installed in Karaf to find web.xml files. When it finds it, Pax Web starts application by creating servlets, filters and initializing servlet context defined in web deployment descriptor.
  52. 52. Web Applications • Webapp support via Pax Web feature • Integrated Jetty • etc/jetty.xml • OSGi http Service (Whiteboard pattern) • Register Web application resources as OSGi services • Full Webapp • Deploy war or wab • CDI support • Commands • web:list, stop, start (Webapps) • http:list (Servlets)
  53. 53. Web console A modular web console for managing your Java stuff
  54. 54. Pax-Exam testing framework Automated Testing Framework Automates: • Set up the environment and initial options for the OSGi container • Start the OSGi container • Install the prerequisite bundles into the OSGi container • Install and run the test classes
  55. 55. Cellar Clustering • Cluster solution for Apache Karaf • Based on Hazelcast • Support for different topologies • Synchronization of deployments and configurations • Cross-Node Event publishing
  56. 56. How can you use OSGi within your existing applications? 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!
  57. 57. Markets & Solutions Automotive: BMW, Volvo, Bombardier… 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
  58. 58. OSGi benefits • You can install, uninstall, start, and stop different modules of your application dynamically without restarting the container. • Your application can have more than one version of a particular module running at the same time. • OSGi provides very good infrastructure for developing service-oriented applications, as well as embedded, mobile, and rich internet apps.
  59. 59. Thank You Quations?

×