OSGi in Action Chapter 1 and 2
- 1. OSGi IN ACTION Chapters 1 and 2 9/12/2012 1
- 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 collaboration 9/12/2012 2
- 3. Breaking Down the Details • Three layers – Module – Lifecycle – Services 9/12/2012 3
- 4. Chapter One OSGi Revealed 9/12/2012 4
- 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 components 9/12/2012 5
- 6. OSGi Alliance • Addresses the lack of support for modularity in the Java platform 9/12/2012 6
- 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. 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. 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. Limited Deployment & Management Support • No easy way in Java to deploy the proper transitive set of versioned code dependencies and execute your application 9/12/2012 10
- 11. OSGi Help You • See pages 112 - 114 9/12/2012 11
- 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. 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 modules 9/12/2012 13
- 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 Java 9/12/2012 14
- 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 constraints 9/12/2012 15
- 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 framework 9/12/2012 16
- 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. 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. OSGi-based Application 1. Breaking down an application into service interfaces (interface-based programming). 2. Use preferred tools and practices. – Eclipse 3. 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. Module Layer Example • Pages 133 – 155 • Group discussion 9/12/2012 20
- 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. 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 framework 9/12/2012 22
- 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 evolving 9/12/2012 23
- 24. OSGi in Context Cont • Service Component Architecture (SCA) – Component model – defines composite components • .NET – Assembly which has modularity aspects similar to an OSGi bundle 9/12/2012 24
- 25. Chapter Two Mastering Modularity 9/12/2012 25
- 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. 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. 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. 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. 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 units 9/12/2012 30
- 31. Why modularize? • Two key concepts – Cohesion – Coupling • Reusable code • Using OSGi to modularize an application will address the Java limitations discussed in Chapter One 9/12/2012 31
- 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. 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. 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 annotations 9/12/2012 34
- 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. Metadata • Human-readable information – Optional information intended to document the bundle • Bundle identification/ Code visibility – Used by the OSGi framework 9/12/2012 36
- 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, clause 9/12/2012 37
- 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. 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 Qualifier 9/12/2012 39
- 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.0 9/12/2012 40
- 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 depends 9/12/2012 41
- 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. 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 file Bundle-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. Bundle Class Path – Internal • Internal class path using Bundle-ClassPath • Specify a list of paths where the class loader should look for classes Bundle-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. 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.other Export-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 bundles 9/12/2012 45
- 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. Importing External Code • OSGi requires bundles to explicitly declaring their dependencies on external code via importing. Import-Package: org.foo.shape Import-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. 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. 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. Bundle Growth • Bundle grows too large over time REFACTOR • Splitting the various export packages into multiple bundles. 9/12/2012 50
- 51. Class Search Order • See section 2.5.4 9/12/2012 51
- 52. Bundle a JAR file or a JAR file a Bundle • Group discussion 9/12/2012 52
- 53. Paint Program • Group discussion 9/12/2012 53
Editor's Notes
- #4: The spec addresses there layers
- #6: These techniques are brittle and error prone, mot enforceable on compile time or execution time. Impacts development, deployment and Execution see page 94
- #8: See page 98 figure
- #9: This exposure leads to dependencies on nonpublic APIs. See page 103, 105-106
- #10: Page 106
- #13: See page 115
- #15: Bundle does not represent the entire application
- #20: OSGi world your services will publish themselves in the service registry.
- #33: Bundle is similar to the definition of a module except that is combines the physical and logical aspects of modularity into one concpt.
- #40: Page 240