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 in Action Chapter 1 and 2

723 views

Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

OSGi in Action Chapter 1 and 2

  1. 1. OSGi IN ACTION Chapters 1 and 29/12/2012 1
  2. 2. OSGi Modularity• OSGi framework – Dynamic modular system for Java• Better control over the structure of your code – Dynamically manage code lifecycle – Loosely coupled approach for code collaboration9/12/2012 2
  3. 3. Breaking Down the Details• Three layers – Module – Lifecycle – Services9/12/2012 3
  4. 4. Chapter One OSGi Revealed9/12/2012 4
  5. 5. Java’s Shortfalls• No explicit support for building modular systems beyond OO data encapsulation• Lack of modularization – Programming practices to capture logical structure – Tricks with class loaders – Serialization between in-process components9/12/2012 5
  6. 6. OSGi Alliance• Addresses the lack of support for modularity in the Java platform9/12/2012 6
  7. 7. What is OSGi• Modularity layer for the Java platform“Modularity refers to the logical decomposition of a large system into smaller collaborating pieces”9/12/2012 7
  8. 8. Java’s Modularity Limitations• Java provides some aspect of modularity via OO but doest not support coarse-grained modular programming.• Partitioning code via Package – Sometimes logical structure of a application requires to call specific code to belong in different package because of the dependencies among the packages MUST be exposed as “public”, which makes them exposed to everyone.9/12/2012 8
  9. 9. Error-Prone Class Path Concept• Class path pays NO ATTENTION to code versions – finds the first version on the class path• No way to explicitly specify dependencies• Class path approach lacks any form of consistency checking.9/12/2012 9
  10. 10. Limited Deployment & Management Support• No easy way in Java to deploy the proper transitive set of versioned code dependencies and execute your application9/12/2012 10
  11. 11. OSGi Help You• See pages 112 - 1149/12/2012 11
  12. 12. OSGi Architectural Overview• Composed of two parts – OSGi framework • Runtime that implements and provides OSGi functionality • Not tied to a particular vendor based on the specification – OSGi standard services • Define reusable APIs for common tasks, such as Logging and Preferences.9/12/2012 12
  13. 13. OSGi Layered Architecture Service• Module Layer Lifecycle – Packaging and sharing code• Lifecycle Layer Module – Providing execution-time modular management and access to the OSGi framework• Service Layer – Interaction and communication among modules9/12/2012 13
  14. 14. Module Layer (Bundle)• Defines the OSGi module concept called a bundle. A JAR file extra metadata.• Logical modules that combine to form a given application.• They explicitly declare which contained packages are externally visible (export package)• Bundles extend the normal access modifiers (public, private, protected) in Java9/12/2012 14
  15. 15. Module Layer (Bundle) Cont• Explicitly declare which external packages the bundles depend (import packages) – OSGi manage bundle consistency via the bundle resolution process • Respect to versions and other constraints9/12/2012 15
  16. 16. Lifecycle Layer• Defines how bundles are dynamically installed and managed in the OSGi framework.• Lifecycle layer serves two different purposes – External to the application defines bundle lifecycle operations (install, update, start, stop & uninstall) • Bundles can be safely added and removed from the framework without restarting the application – Internal to the application defines how bundles gain access to the their execution context, provides a way to interact with the OSGi framework9/12/2012 16
  17. 17. Service Layer• Promotes the concepts of service-oriented computing.• Publish and register a service via a registry – Operations: publish, find and bind• OSGi services are local to a single VM, sometimes refer to SOA in a VM.9/12/2012 17
  18. 18. Service Layer• Promotes interface-based development.• Promotes the separation of interface and implementation.• OSGi services are Java Interfaces, representing contract between service provider and service clients.9/12/2012 18
  19. 19. OSGi-based Application1. Breaking down an application into service interfaces (interface-based programming).2. Use preferred tools and practices. – Eclipse3. Package the service provider and client components into separate JAR files with OSGi metadata.4. Start the OSGi framework.5. Install and start all your component JAR files from step 3.9/12/2012 19
  20. 20. Module Layer Example• Pages 133 – 155• Group discussion9/12/2012 20
  21. 21. OSGi in Context• Java Enterprise Edition – Enterprise vs. embedded markets – OSGi plays a role in all major application servers: IBM’s WebSphere, JBoss, GlassFish and so on• Jini – Concept of service providers, service consumers and service lookup registry. – Jini model assumes remote access across multiple VM processes whereas OSGi assumes everything occurs in a single VM process. – Open source Newton combines OSGi and Jini technologies in a single framework.9/12/2012 21
  22. 22. OSGi in Context Cont• NetBeans – Common with OSGi – promotes interface programming. Uses a lookup pattern similar to OSGi registry.• Java Management Extensions (JMX) – Not comparable to OSGi; it’s complementary – Used to mange and monitor an OSGi framework and its bundles and services. – JMX is not a module system.• Lightweight Containers – Significant movement from IoC vendors to port there infrastructures to the OSGi framework9/12/2012 22
  23. 23. OSGi in Context Cont• Java Business Integration (JBI)• JSR 277 (Java Module System) – Intend to define a module framework, packaging format and repository system.• JSR 294 (Improved Modularity Support) – Superpackage – Project Jigsaw – modularize the JDK – Still evolving9/12/2012 23
  24. 24. OSGi in Context Cont• Service Component Architecture (SCA) – Component model – defines composite components• .NET – Assembly which has modularity aspects similar to an OSGi bundle9/12/2012 24
  25. 25. Chapter Two Mastering Modularity9/12/2012 25
  26. 26. What is modularity?• Designing a system from a set of logically independent pieces; these logical pieces are called modules• A module defines an enforceable logical boundary• Details of a module are visible only to code that is part of a module.9/12/2012 26
  27. 27. Module“A module defines a logical boundary. The module itself is explicitly in control of which classes are completely encapsulated and which are exposed for external use.”9/12/2012 27
  28. 28. Modularity vs. OO• Modularity provides many of the same benefits as OO. – Separation of concerns • Break down a system into minimally overlapping functionality or concerns• Classes have explicit dependencies due to the references contained in the code. Modules have implicit dependencies due to the code they contain.• Modularity and OO each address granularity at different levels.9/12/2012 28
  29. 29. Module“A set of logically encapsulated implementations classes, an optional public API based on a subset of the implementation classes and a set of dependencies on external code.”9/12/2012 29
  30. 30. Logical vs. Physical Modularity• Logical Modularity – Code visibility – module defines a logical boundary in an application which impacts code visibility – Logical module is referred as a bundle• Physical Modularity – How code is packaged and/or made available for deployment. – Physical module is the JAR file – Physical modules also referred to as deployment modules or deployment units9/12/2012 30
  31. 31. Why modularize?• Two key concepts – Cohesion – Coupling• Reusable code• Using OSGi to modularize an application will address the Java limitations discussed in Chapter One9/12/2012 31
  32. 32. Bundle“A physical unit of modularity in the form of a JAR file containing code, resources and metadata where the boundary of the JAR file also serves as the encapsulation boundary for logical modularity at execution time.”9/12/2012 32
  33. 33. Bundle’s Role in Physical Modularity• Don’t need anything special to make a class a member of a bundle. Just added it to the JAR file.• Physical containment of classes in a bundle JAR files leads to a deployment unit• Containment of bundle metadata via the manifest file.9/12/2012 33
  34. 34. Where should the metadata go?• In source code or a separate file?• Separate file – Don’t need to recompile your bundle to make a change to the metadata – Don’t need access to the source code – Don’t need to load classes into the JVM to access associated metadata – Code doesn’t get a compile time dependency on OSGi API. – Can use the same code in multiple modules – Can easily use code on older or smaller JVMs that don’t support annotations9/12/2012 34
  35. 35. Code Visibility• OSGi extents code visibility – A public utility being used with a bundle is NOT exposed outside the bundle. This extents encapsulation above the package level in Java. Which means that the bundle imposes a logical boundary on public classes. – Code is ONLY exposed explicitly via the export statement.9/12/2012 35
  36. 36. Metadata• Human-readable information – Optional information intended to document the bundle• Bundle identification/ Code visibility – Used by the OSGi framework9/12/2012 36
  37. 37. JAR File Manifest• Groups of name-value pairs (attributes) name: value Manifest-VersionL 1.0 Creaked-By 1.4 (Sun) Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.api Bundle-Version: 1.0.0.SNAPSHOT Bundle-Name: Simple Paint API Export-Package: org.foo.api Import-Package: javax.swing, org.foo.api• OSGi manifest attribute values are a list of clauses separated by commas Property-Name: clause, clause, clause9/12/2012 37
  38. 38. Bundle Identification• Bundle-Name – doest not defined the bundle name to the framework. Used for documentation.• Bundle-SymbolicName – defined the bundle name to the framework. Follows the Java packaging naming. Required! (R4 Spec) Bundle-SymbolicName: org.foo.shape• Bundle-Version – bundle version number Bundle-Version: 2.0.0  Only valid value!9/12/2012 38
  39. 39. OSGi Version Number Format• Version number is composed of three separate numerical values plus an optional qualifier 1.0.0.alpha Major Number Minor Number Micro Number Qualifier9/12/2012 39
  40. 40. OSGi Version Number Examples• 1.0.0.beta is newer than• 1.0.0.alpha• 1.0.0 is older than both Higher Version 1.0.0 1.0.0.alpha 1.0.0.beta 1.1.0 1.1.1 1.2.09/12/2012 40
  41. 41. OSGI Metadata Captures• Internal bundle class path – the code forming the bundle• Exported internal code – explicitly expose code from the bundle class path for sharing with other bundles• Imported external code – external code on which the bundle class path depends9/12/2012 41
  42. 42. Code Visibility – Standard JAR File• JAR file with a Main-Class attribute in the manifest file java –jar app.jar• No Main-Class attribute java –cp app.jar org.foo.Main• Page 250 (iBook)• Standard JAR files are implicitly searched.9/12/2012 42
  43. 43. Code Visibility - OSGi• Internal Bundle Class Path – The Explicit search is called  bundle class path – List of locations to search for classes – Locations define in the bundle manifest fileBundle-Classpath “An ordered, comma-separated list of relative bundle JAR file locations to be searched for class and resource requests”9/12/2012 43
  44. 44. Bundle Class Path – Internal• Internal class path using Bundle-ClassPath• Specify a list of paths where the class loader should look for classesBundle-ClassPath: .,other-classes/,embedded.jar• Period (.) signifies the bundle JAR file. If period not supplied the framework supplies the period.• Ordering is important!9/12/2012 44
  45. 45. Bundle Class Path – External• External class path use Export-Package – Explicitly expose internal bundle classes to share with other bundles Export-Package: org.foo.shape, org.foo.otherExport-Package “A comma-separated list of internal bundle packages to expose for sharing with other bundles”• Instead of exposing individual classes, OSGi defines sharing among bundles at the package level• Not every public class contained in the package is exposed to other bundles9/12/2012 45
  46. 46. Package Versioning• Every package has a version number. Attributes are used to associate a version number. Export-Package: org.foo.shape; org.foo.other; version=“2.0.0”• No version specified, defaults to “0.0.0”9/12/2012 46
  47. 47. Importing External Code• OSGi requires bundles to explicitly declaring their dependencies on external code via importing. Import-Package: org.foo.shapeImport-Package “A comma-separated list of packages needed by internal bundle code from other bundles”• Importing packages does not import subpackages• Not uncommon in large projects the Import- Package declaration to grow large.9/12/2012 47
  48. 48. Importing Examples• Adding attributes to filter packages Import-Package: org.foo.shape; vendor=“Manning”• Adding version number Import-Package: org.osgi.framework; version=“1.3.0” – Note the version range is 1.3.0 to infinity – See Table 2.2 for version range and meaning – No version number, default to “0.0.0” to infinity.9/12/2012 48
  49. 49. Java vs. OSGi Import• Import statement in source files are managing namespaces not dependences• OSGi uses package-level granularity for expressing dependences.9/12/2012 49
  50. 50. Bundle Growth• Bundle grows too large over time REFACTOR• Splitting the various export packages into multiple bundles.9/12/2012 50
  51. 51. Class Search Order• See section 2.5.49/12/2012 51
  52. 52. Bundle a JAR file or a JAR file a Bundle• Group discussion9/12/2012 52
  53. 53. Paint Program• Group discussion9/12/2012 53

×