OSGi provides a module system for Java applications by treating JAR files as bundles with additional metadata specifying things like name, version, dependencies, and exports/imports. This allows for greater modularity by resolving dependencies and supporting side-by-side versions. Components in OSGi are bundles that can be dynamically installed, updated, and uninstalled. Annotations and services allow bundles to be configured and discover other bundles at runtime.

1. Introduction to OSGi
Neil Bartlett – 2009 12 23

2. ❶
Brief Intro to OSGi

3. OSGi: The Module
System for Java

4. Standard Java
JARs are Deployment
Units
ABC.JAR
They are Not Modules

5. What’s Missing?
Meaningful name
Version
Vendor
ABC.JAR
Exports
Dependencies

6. Dependencies
JARs do have dependencies
They are implicit.
A dependency is an assumption.
“I assume module X (version Y) is on the
classpath. If not I will crash and burn.”

7. Module = “Bundle”

8. Just a JAR + Metadata
Meaningful name
Version
Vendor
org.foo.mylib
Manifest-Version: 1.0
Exports
Bundle-SymbolicName: com.mylib
Bundle-Name: My Library Bundle
Bundle-Vendor: Neil Bartlett
Bundle-Version: 1.0.0
Import-Package: javax.swing, org.w3c.dom
Export-Package: com.mylib1.ui;version=“1.0.0”,
com.mylib1.util;version=“1.0.0”
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Dependencies

9. MANIFEST.MF
Manifest-Version: 1.0
Bundle-SymbolicName: com.mylib
Bundle-Name: My Library Bundle
Bundle-Vendor: Neil Bartlett
Bundle-Version: 1.0.0
Import-Package: javax.swing, org.w3c.dom
Export-Package: com.mylib.ui;version=“1.0.0”,
com.mylib.util;version=“1.0.0”
Bundle-RequiredExecutionEnvironment: J2SE-1.5

10. Works Outside OSGi

11. Dependency Graphs

13. Imports..... and Exports
} {
com.foo.bar com.mylib
javax.swing com.mylib.ui
org.wibble com.mylib.util

14. Package Resolution
com.foo.bar
A

15. Package Resolution
com.foo.bar com.foo.bar
B A

16. Package Resolution
com.foo.bar com.foo.bar
B A

17. Versioned Dependency
com.foo.bar
[1.2.0,1.4.0) A

18. Versioned Dependency
com.foo.bar com.foo.bar
B 1.4.5 [1.2.0,1.4.0) A

19. Versioned Dependency
B
com.foo.bar
1.4.5
✘ com.foo.bar
[1.2.0,1.4.0) A

20. Versioned Dependency
com.foo.bar com.foo.bar
B’ 1.3.12 [1.2.0,1.4.0) A

21. Versioned Dependency
com.foo.bar com.foo.bar
B’ 1.3.12 [1.2.0,1.4.0) A

22. Side-by-Side Versions
com.foo.bar com.foo.bar
B X
1.4.5 [1.4.0,1.5.0)
com.foo.bar com.foo.bar
B’ Y
1.3.12 [1.2.0,1.4.0)

23. Side-by-Side Versions
com.foo.bar com.foo.bar
B X
1.4.5 [1.4.0,1.5.0)
com.foo.bar com.foo.bar
B’ Y
1.3.12 [1.2.0,1.4.0)

24. How it Works
Bundle-SymbolicName: com.mylib1
Bundle-Version: 1.2.0
Export-Package:
com.mylib1.ui;version=“1.2.0”,
com.mylib1.util;version=“1.2.0”
Bundle-SymbolicName: com.app1
Bundle-Version: 2.2.3.alpha
Import-Package:
com.mylib1.ui;version=“[1.2.0,1.3.0)”
com.mylib1.util;version=“[1.2.0,1.3.0)”

25. Private Internals
Exports must be stated explicitly
Packages not listed in “Export-Package” are not
available to other bundles

26. Versions
Standard numbering scheme with well-defined
ordering.
major.minor.micro.qualifier
First three numeric, last alphanumeric
Eg 1.0.0.beta2
Unspecified ! 0.0.0

27. Version Ranges
Open, closed or implicit
[1.0.0, 2.0.0] ! 1.0.0 ! version ! 2.0.0
[1.0.0, 2.0.0) ! 1.0.0 ! version < 2.0.0
Informally “1.*”
1 ! [1.0.0, ")
Unspecified ! [0.0.0, ")

28. Our Promise*: No More
NoClassDefFoundErrors!

29. Dynamic!

30. Dynamic
Install Bundles
Update Bundles
Uninstall Bundles
... all “on the fly”

31. ❷
OSGi in Infrastructure

32. OSGi is the King of
Infrastructure
All Major JEE Application Servers use OSGi
Most ESBs use OSGi
2 of 3 Open Source IDEs use OSGi
Even Build Tools (Maven and Hudson) Moving to
OSGi

33. Where are the
“Business” Apps?

34. OSGi for Applications
Until Recently, Application Servers used OSGi “on
the inside”
Now SpringSource dm Server, Paremus Infiniflow,
WAS 7, GlassFish v3 and WebLogic DM all expose
OSGi
Application Developers can Finally Deploy OSGi
bundles to their OSGi servers!

35. Why is OSGi Attractive
for Application
Development?

36. ❸
The Failure of Object
Oriented Programming

37. OOP Was Meant to
Enable Reuse

38. HARDER THAN
EXPECTED!

39. “Building a new system
would be a snap. Just get a
few classes, bunch them
together... and voila!”
– Peter Kriens

40. What Went Wrong??

41. Tight Coupling

42. COMPLEXITY

43. Classes coupled to
Other Classes

44. Packages coupled to
Other Packages

45. Packages coupled to
JARs

46. JARs coupled to More
JARs

47. Which are coupled to
yet more JARs...

49. Dependency Injection?

50. DI Frameworks
Provide “Late Binding” of Implementations to
Interfaces
But Not Late Enough!

51. Spring Framework
<bean id="MyBean" class="org.example.MyBean">
<property name="dataSource" ref="OracleDataSource"/>
</bean>
<bean id="OracleDataSource" class="...">
<property name="..." />
</bean>

52. Traditional Spring

53. Static DI
“Beans” are wired together once, at start-up
They cannot be rewired
Limited support for optional dependencies

54. FRAGILE

55. One Solution: Give Up!

56. Reuse is Hard, So Don’t
Try!

57. Leave Code in One
Place, and Call
Remotely
(...also known as “SOA”)

58. ❹
Component Oriented
Programming

59. What is a
“Component”?

60. The Usual Analogy:

61. LEGO?

62. Not Really...
Dead Lumps of Plastic
Many Copies of the Same Thing

63. BIOLOGY

64. BIOLOGY

65. Dr Alan Kay
Inventor of Object
Oriented Programming
& Smalltalk
“I thought of objects
being like biological
cells...”

66. Components
Do Something, or Provide Something
Aware of and Adapt to their Environment
Have a Life-cycle (birth to death).

67. “Do” Something
Open a socket
Monitor a device
Poll a queue
Display a GUI
.... etc.

68. “Provide” Something
Publish a Service – may be used by other
components

69. The “Environment”
The “Environment” of a Component means:
Services provided by other Components
Resources, Devices, Network etc

70. Components Adapt to
their Environment

71. Good Environment
Most services are available
The component flourishes

72. Harsh Environment
Some non-essential services are unavailable
Component adapts and survives

73. Very Harsh Environment
Essential services are unavailable
Component hibernates or dies

74. Composition
Components Use other Components
In this way, whole Systems are Composed
Resilient, Elastic Systems

75. ❺
Developing
Components

76. Services
Components provide Services
Registered with a Service Registry
Services are POJOs!
Looked up by Java interface name

77. In-Process SOA
Service
Broker
Find
Register
Service
Contract
Service
Service Provider
Consumer
Client Bind Service

78. Plain Old Java Objects

79. The Glue Between
Components

80. Dynamics Make
Services Slippery

81. We Don’t Code Directly
against Services (it’s too hard!)

82. Let a Framework
Handle the Hard Stuff

83. Choice of Frameworks
Declarative Services (DS)
Blueprint (from Spring-DM)
iPOJO
Guice Peaberry

84. Framework Interop
Perfect Interoperability of these Frameworks!
No need to choose “The One True Framework”
Use 3rd-party components implemented with
other frameworks.

85. Examining DS
Dynamic dependency injection (DI)
... and “uninjection”

86. Starting Point...
import javax.sql.DataSource;
public class DbMailbox implements Mailbox {
private DataSource dataSource;
void setDataSource(DataSource ds) { /*...*/ }
void unsetDataSource(DataSource ds) { /*...*/ }
public long[] getAllMessages() {
// ...
}
}

87. Starting Point...
No OSGi API Used
import javax.sql.DataSource;
public class DbMailbox implements Mailbox {
private DataSource dataSource;
void setDataSource(DataSource ds) { /*...*/ }
void unsetDataSource(DataSource ds) { /*...*/ }
public long[] getAllMessages() {
// ...
}
}

88. Starting Point...
No OSGi API Used
import javax.sql.DataSource;
public class DbMailbox implements Mailbox {
private DataSource dataSource;
void setDataSource(DataSource ds) { /*...*/ }
void unsetDataSource(DataSource ds) { /*...*/ }
public long[] getAllMessages() {
// ...
}
} JavaBeans Style => Testable

89. Make it a Component
import javax.sql.DataSource;
@Component
public class DbMailbox implements Mailbox {
private DataSource dataSource;
@Reference(service = DataSource.class)
void setDataSource(DataSource ds) { /*...*/ }
void unsetDataSource(DataSource ds) { /*...*/ }
public long[] getAllMessages() {
// ...
}
}

90. Annotations
@Component – Create a Component of this type.
Service is automatically published
@Reference – Use the specified service

91. Add Life-cycle
@Activate
void start() {
thread = new Thread();
thread.start();
}
@Deactivate
void stop() {
thread.interrupt();
}

92. Make it Configurable
@Activate
void start(Map<String, Object> configuration) {
thread = new Thread();
thread.start();
}
@Modified
void modify(Map<String, Object> newConfiguration) {
// This method is optional
}
@Deactivate
void stop() {
thread.interrupt();
}

93. Optional Reference
@Reference(service = LogService.class, optional = true)
void setLogService(LogService log) { /* ... */ }
void unsetLogService(LogService log) { /* ... */ }

94. Multiple Reference
@Reference(service = MailboxListener.class, multiple = true)
void addListener(MailboxListener listener) { /* ... */ }
void removeListener(MailboxListener listener) { /* ... */ }

95. ❻
DEMO

96. Mailbox Reader
Mailbox
Fixed
Mailbox

97. Mailbox Reader
MailboxListener
Mailbox
Growing
Mailbox

98. Mailbox Reader
MailboxListener
Mailbox
Trades
Order Entry
Mailbox
Matching
EventHandler
Service
Trade Matching
Event Broker
Engine
EventAdmin