The document provides an overview of the first two chapters of the book "OSGi in Action". Chapter 1 introduces OSGi and discusses its benefits for modularity in Java applications. It describes the three layers of OSGi - modules, lifecycle, and services. Chapter 2 delves deeper into OSGi modularity. It defines modules, bundles, and how bundles are used to achieve logical and physical modularity. The chapter also covers OSGi metadata and how bundles are constructed to export and import code/packages.

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