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.

OSGi Overview TomTom DevDay May 2009


Published on

Explorations into OSGi on the server side

Published in: Technology
  • Be the first to comment

  • Be the first to like this

OSGi Overview TomTom DevDay May 2009

  1. 1. 10 Questions & Answers on OSGi (on the server side) Toralf Richter, May 11, 2009
  2. 2. 1. What is OSGi? Answer 1 An acronym : Open Services Gateway initiative Answer 2 The name of a consortium : the „OSGi Alliance“ Founded 1999 more than 100 companies as members world-wide (IBM, Oracle+Sun, Nokia, and many telcos, automotive equipment manufacturers)
  3. 3. 1. What is OSGi? Answer 3 a specification : the OSGi Service Platform defines basic concepts of OSGi components and services terminology: bundle, life cycle, services, dependencies defines a programming interface (API) to interact with the service platform, other services in the same platform, etc. defines how bundles (components) are built and how their needed meta information is added current specification version is R4.1 (since May 2007)
  4. 4. 1. What is OSGi? Answer 4 a set of paradigms : in some sense OSGi is yet another incarnation of the component architecture - complex software systems (should) consist of simpler building blocks (components)  OSGi bundles service orientation within the application - components exists besides each other and express dependency but true interaction is by services using a producer-consumer pattern It is fine-grained (versus monolithic) - the building blocks are loosely coupled and ought to never rely on another building block‘s presence it is dynamic – services can appear and disappear (white board pattern) It aims at continuous operation (uninterrupted by updates and maintenance)
  5. 5. 2. Origins of OSGi Mainly from the embedded software development in automotive (think of BMW iDrive), mobile (think of Java on mobile phones), home entertainment (many recent DVD players run on OSGi bundled Java applications
  6. 6. 3. So what is the server-side story with OSGi? Drive to „enterprise OSGi“ recognisable Foundation of OSGi Enterprise Expert Group in January 2007 transport Java EE APIs and functionalities to OSGi Specification R4.2 due June 2009 will contain “enterprise features” which will make OSGi much more practicable (than now) for large scale server side applications Initial attempt at “distributed OSGi”   We made some studies into OSGi for server applications starting from 2007/2008 this but it only starts to get really interesting now
  7. 7. 4. How mature can we consider it on the server side? Some examples of server / server-infrastructure applications built on OSGi already JBoss, Glassfish v3, BEA Weblogic Mule ESB, Apache ServiceMix ESB For the typical JEE application there are still shortcomings of the specification and available and possible implementations. It seems this is going to improve with R 4.2 OSGi on the server side can currently be considered a heavily emerging technology
  8. 8. 5. What are the basic principles? Software is made of components Each component has a clearly marked functionality („core competency“) The „same“ component can be present in several versions In OSGi components are called bundles
  9. 9. 5. What are the basic principles? OSGi compliant componentised software runs in a suitable runtime environment called an “OSGI framework” or “OSGI container” The container takes care of interpreting the meta information attached to the components, i.e. provide the export and requests the imports (quite similar to well know web or JEE containers) It takes care choosing a suitable isolation level between bundles based in meta information, in effect determining “visibility” between bundles
  10. 10. 5. What are the basic principles? Complex applications are composed of bundles and the dependencies expressed between them Dependencies can be direct export / import relationship Fragment relationship Service producer / service consumer relationship The container resolves dependencies from the “visible” offerings deployed in the container
  11. 11. 6. How to manage visibility? Bundles specify explicitly what (Java) packages they provide to other bundles, the OSGi term for this is export what packages or entire other bundles are needed, or in OSGi terms are imported and what packages are kept strictly private, etc. In addition to Java code level visibility (public, protected, …) visibility between bundles is determined by package exports and their version information The OSGi container takes care of dependency resolution (I.e. does export meet import) An importer of a package does usually not care which exporter actually provides package, alternatives / substitutes of the same functionalities / exports are easily interchangeable
  12. 12. 7. How to express version constraints? Version number pattern „major.minor.bugfix.qualifier“ Exports specify the version they provide Imports specify the precise version or version range they require Specifying range in the manifest is done in “mathematical notation” : [ means >=, ] means <=, ( means >, ) means < Example range: from including 1.5.0 to not including 2.0 - manifest notation: version=“[1.5.0, 2.0)” When more than one bundle or package match an importers version constraint there are decisions rules (set by OSGi specification) which one goes first
  13. 13. 8. How does an OSGi manifest look? Key elements of an OSGi JAR MANIFEST below. MANIFEST is to be found in jar:<xyz>!/METAINF/MANIFEST.MF Bundle-SymbolicName: ttwBase Bundle-Version: 1.0.0 Bundle-Activator: com.tomtomwork.base.Activator Require-Bundle: ttwOther;bundle-version=“[1.3.1, 1.4.0)“ Export-Package: com.tomtomwork.base.*;version=“1.0.0“ Import-Package: org.osgi.framework;version="1.3.1“,com.tomtomwork.webf leet;version=“[2.0.0, 2.1.99)“ Private-Package: com.tomtomwork.internal.*
  14. 14. 9. How bundles interact using services? bundles can register objects they instantiate and hold as services they become service providers or service producers when registering service the provider specifies a service interface and arbitrary additional (meta) information and announces the service(s) on a public white board (service registry) also bundles can lookup services fulfilling certain criteria and when available consume the service provider and consumer do not and should not know each other. They interact through the white board (service registry) loose coupling + dynamism: (non-)availability of services can be queried “per-access”, notifications can be set up using service listeners, and since specification R 4.x the service tracker can be used for constant and transparent service state tracking
  15. 15. 10. What are advantages and costs of OSGi development? Developer must learn new API plain OSGi partially invasive on code (can be avoided using declarative services) developer MUST honour OSGi paradigms third party libraries are sometimes not yet OSGi complaint tooling not yet “up to speed” when you compare it to standard Java IDE products JEE capabilities still emergent (e.g. complex / multiple web applications or JDBC still somewhat complicated)
  16. 16. 10. What are advantages and costs of OSGi development? robust clearly defined and managed dependencies code quality / maintainability bundles can and should be developed separately and interact on defined interfaces … this helps to avoid growing huge tangled monoliths flexibility / adaptability Composed arbitrarily complex applications from small bundles focusing on their “core competency” (high) availability / continuous operation update / swap bundles without rebooting the entire application container (“hot deploy” is rather default mode of operation instead an option) extensibility add bundles and capabilities at runtime
  17. 17. Thanks for your patience. Toralf Richter @ToralfRichter