1. Why OSGi?
BJ Hargrave, IBM
Peter Kriens, aQute

2. Agenda
• Why OSGi?
• The Dream
• Looking for Shoulders
• Java & Packages
• OSGi Bundles & Services
• Conclusion

3. Why OSGi?

4. Why OSGi?
Scriptorium

5. Why OSGi?
… because there should be a better
way to develop software ...

6. Why OSGi?
2010 2003
1996 1989
1982 1982
1975 1968
1961
Amount of software doubling every 7 years
source: http://users.jyu.fi/~koskinen/smcosts.htm

7. Why OSGi?
2010 2003
1996 1989
2017
1982 1982
1975 1968
1961
Amount of software doubling every 7 years
source: http://users.jyu.fi/~koskinen/smcosts.htm

8. The Dream

9. The Dream
• Adaptive
• Flexible
B C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

10. The Dream
• Adaptive
• Flexible
A B C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

11. The Dream
• Adaptive
• Flexible
A Ba B Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

12. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

13. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

14. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

15. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I
• Distributed

16. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H
• Distributed

17. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H
• Distributed

18. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H
• Distributed

19. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H
• Distributed

20. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure
• Evolution
G H I v2.0
• Distributed

21. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure S;1.1.0
• Evolution
G H I v2.0
• Distributed

22. The Dream
• Adaptive
• Flexible
A Ba Bb C
• Contracts
• Robust D E F
• Secure S;1.1.0
• Evolution
G H I v2.0
• Distributed

23. The Dream
• Adaptive
• Flexible
A Ba Bb
• Contracts
• Robust D E F
• Secure S;1.1.0
• Evolution
G H I v2.0
• Distributed

24. Cambridge in the 50’s

25. Cambridge in the 50’s
“As soon as we started programming, we found to
our surprise that it wasn't as easy to get programs
right as we had thought.”
“… the realization came over me with full force that
a good part of the remainder of my life was going to
be spent finding errors in my own programs.”
Maurice Wilkes

26. Subroutines

27. Subroutines
Subroutines

28. Subroutines
• Subroutine:
• Focus on what, not how
• Encapsulate the implementation details
• Formalized the input data (arguments)
• Formalized the output (return values)

29. Subroutines
• Abstraction
• Easier to understand
• Less Code
• Fewer Errors
• Sharing
• Simpler Maintenance
(depends …)

30. Subroutines

31. Functions

32. Functions
Function

33. Functions
Input
(arguments)
Function

34. Functions
Input Output
(arguments) (return)
Function

35. Functions
Private
Input Output
(arguments) (return)
Function

36. Then Systems Grew

37. Then Systems Grew

38. Spaghetti Code

39. Pittsburg 70’s

40. Pittsburg 70’s
“ … modularization as a mechanism for improving
the flexibility and comprehensibility of a system
while allowing the shortening of its development
time.”
David Parnas

41. Modules

42. Modules
Module

43. Modules
Private Functions
Imported Exported
Functions Functions
Module

44. Then Systems Grew

45. Then Systems Grew

46. Sharing Proved Hard

47. Sharing Proved Hard

48. Sharing Proved Hard

49. Palo Alto 80’s

50. Palo Alto 80’s
“Objects support modularity - the functioning of an
object does not depend on the internal details of
another object. The complexity of the system is
reduced by this minimization of interdependencies
of system components.”
Smalltalk Team

51. Objects

52. Objects
Private Members
Imported Exported
Members Members
Type

53. Objects
• Objects/Classes => Modules +
• Instantiation (private data per instance)
• Inheritance
• Polymorphism

54. Then Systems Grew

55. Then Systems Grew

56. C++

57. Menlo Park 90’s

58. Menlo Park 90’s

59. Packages
“Chapter 7 describes the structure of a program,
which is organized into packages similar to the
modules of Modula.”
Java Language Specification

60. Packages
Private Types
Imported Exported
Types Types
Packages

61. Then Systems Grew

62. Then Systems Grew

63. And Distributed

64. And Distributed

65. And Multiplied

66. And Multiplied

67. Small Java App ...

68. Worldwide 00’s

69. Worldwide 00’s

70. Worldwide 00’s

71. Next Level of
Modularity

72. Next Level of
Modularity
Functions

73. Next Level of
Modularity
Classes/Objects
Functions

74. Next Level of
Modularity
Packages
Classes/Objects
Functions

75. Next Level of
Modularity
Bundles
Packages
Classes/Objects
Functions

76. Next Level of
Modularity
Bundles
Packages
Classes/Objects
Functions

77. Bundles
Private Packages
Imported Exported
Packages Packages
Bundle
(JAR file)

78. Type Coupling

79. Type Coupling

80. Download the Internet

81. Type Coupling

82. Type Coupling
substitutable
packages
= API

83. Instance Coupling
Consumer Bundle Provider Bundle

84. Instance Coupling
Consumer Bundle Provider Bundle
API Bundle

85. Instance Coupling
Consumer Bundle Provider Bundle
need an
instance ...
API Bundle

86. Instance Coupling
Consumer Bundle Provider Bundle
X
need an
instance ...
API Bundle

87. Instance Coupling

88. Instance Coupling
Consumer Bundle Provider Bundle
Service
API Bundle

89. A Dream Come True
A B C
D E F
G H I

90. Why OSGi?
… because it is a better way to
develop software ...

91. Conclusion
2010 2003
2017
1996 1989
1982 1982
1975 1968
1961
Amount of software doubling every 7 years
source: http://users.jyu.fi/~koskinen/smcosts.htm

92. OSGi
• Legacy and backward compatibility is important
• Modularizing is hard
• Many popular Java patterns are fundamentally
not modular
• In the next 7 years, we double the amount of
software
• Investment in modularity has a great ROI!

93. OSGi Alliance
• The OSGi Alliance is a non-profit that has the
vision to develop a Java component model to ease
software development
• Comprehensive framework specification
• Service specifications
• An active community
• Repository
• Tools

94. Join!
• Help us to achieve our vision to make
software simpler to develop
• Provide Requirements
• Develop specifications
• Help the community
• OSGi Alliance restructured to provide
lower-cost membership levels

95. Q&A