Introduction to OSGi (Tokyo JUG)

3,100 views

Published on

Published in: Technology, Education
1 Comment
11 Likes
Statistics
Notes
No Downloads
Views
Total views
3,100
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
167
Comments
1
Likes
11
Embeds 0
No embeds

No notes for slide

Introduction to OSGi (Tokyo JUG)

  1. 1. Introduction to OSGi Neil Bartlett – 2009 12 23
  2. 2. ❶ Brief Intro to OSGi
  3. 3. OSGi: The Module System for Java
  4. 4. Standard Java JARs are Deployment Units ABC.JAR They are Not Modules
  5. 5. What’s Missing? Meaningful name Version Vendor ABC.JAR Exports Dependencies
  6. 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. 7. Module = “Bundle”
  8. 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. 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. 10. Works Outside OSGi
  11. 11. Dependency Graphs
  12. 12. Imports..... and Exports } { com.foo.bar com.mylib javax.swing com.mylib.ui org.wibble com.mylib.util
  13. 13. Package Resolution com.foo.bar A
  14. 14. Package Resolution com.foo.bar com.foo.bar B A
  15. 15. Package Resolution com.foo.bar com.foo.bar B A
  16. 16. Versioned Dependency com.foo.bar [1.2.0,1.4.0) A
  17. 17. Versioned Dependency com.foo.bar com.foo.bar B 1.4.5 [1.2.0,1.4.0) A
  18. 18. Versioned Dependency B com.foo.bar 1.4.5 ✘ com.foo.bar [1.2.0,1.4.0) A
  19. 19. Versioned Dependency com.foo.bar com.foo.bar B’ 1.3.12 [1.2.0,1.4.0) A
  20. 20. Versioned Dependency com.foo.bar com.foo.bar B’ 1.3.12 [1.2.0,1.4.0) A
  21. 21. 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)
  22. 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. 23. 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)”
  24. 24. Private Internals Exports must be stated explicitly Packages not listed in “Export-Package” are not available to other bundles
  25. 25. 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
  26. 26. 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, ")
  27. 27. Our Promise*: No More NoClassDefFoundErrors!
  28. 28. Dynamic!
  29. 29. Dynamic Install Bundles Update Bundles Uninstall Bundles ... all “on the fly”
  30. 30. ❷ OSGi in Infrastructure
  31. 31. 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
  32. 32. Where are the “Business” Apps?
  33. 33. 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!
  34. 34. Why is OSGi Attractive for Application Development?
  35. 35. ❸ The Failure of Object Oriented Programming
  36. 36. OOP Was Meant to Enable Reuse
  37. 37. HARDER THAN EXPECTED!
  38. 38. “Building a new system would be a snap. Just get a few classes, bunch them together... and voila!” – Peter Kriens
  39. 39. What Went Wrong??
  40. 40. Tight Coupling
  41. 41. COMPLEXITY
  42. 42. Classes coupled to Other Classes
  43. 43. Packages coupled to Other Packages
  44. 44. Packages coupled to JARs
  45. 45. JARs coupled to More JARs
  46. 46. Which are coupled to yet more JARs...
  47. 47. Dependency Injection?
  48. 48. DI Frameworks Provide “Late Binding” of Implementations to Interfaces But Not Late Enough!
  49. 49. Spring Framework <bean id="MyBean" class="org.example.MyBean"> <property name="dataSource" ref="OracleDataSource"/> </bean> <bean id="OracleDataSource" class="..."> <property name="..." /> </bean>
  50. 50. Traditional Spring
  51. 51. Static DI “Beans” are wired together once, at start-up They cannot be rewired Limited support for optional dependencies
  52. 52. FRAGILE
  53. 53. One Solution: Give Up!
  54. 54. Reuse is Hard, So Don’t Try!
  55. 55. Leave Code in One Place, and Call Remotely (...also known as “SOA”)
  56. 56. ❹ Component Oriented Programming
  57. 57. What is a “Component”?
  58. 58. The Usual Analogy:
  59. 59. LEGO?
  60. 60. Not Really... Dead Lumps of Plastic Many Copies of the Same Thing
  61. 61. BIOLOGY
  62. 62. BIOLOGY
  63. 63. Dr Alan Kay Inventor of Object Oriented Programming & Smalltalk “I thought of objects being like biological cells...”
  64. 64. Components Do Something, or Provide Something Aware of and Adapt to their Environment Have a Life-cycle (birth to death).
  65. 65. “Do” Something Open a socket Monitor a device Poll a queue Display a GUI .... etc.
  66. 66. “Provide” Something Publish a Service – may be used by other components
  67. 67. The “Environment” The “Environment” of a Component means: Services provided by other Components Resources, Devices, Network etc
  68. 68. Components Adapt to their Environment
  69. 69. Good Environment Most services are available The component flourishes
  70. 70. Harsh Environment Some non-essential services are unavailable Component adapts and survives
  71. 71. Very Harsh Environment Essential services are unavailable Component hibernates or dies
  72. 72. Composition Components Use other Components In this way, whole Systems are Composed Resilient, Elastic Systems
  73. 73. ❺ Developing Components
  74. 74. Services Components provide Services Registered with a Service Registry Services are POJOs! Looked up by Java interface name
  75. 75. In-Process SOA Service Broker Find Register Service Contract Service Service Provider Consumer Client Bind Service
  76. 76. Plain Old Java Objects
  77. 77. The Glue Between Components
  78. 78. Dynamics Make Services Slippery
  79. 79. We Don’t Code Directly against Services (it’s too hard!)
  80. 80. Let a Framework Handle the Hard Stuff
  81. 81. Choice of Frameworks Declarative Services (DS) Blueprint (from Spring-DM) iPOJO Guice Peaberry
  82. 82. Framework Interop Perfect Interoperability of these Frameworks! No need to choose “The One True Framework” Use 3rd-party components implemented with other frameworks.
  83. 83. Examining DS Dynamic dependency injection (DI) ... and “uninjection”
  84. 84. 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() { // ... } }
  85. 85. 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() { // ... } }
  86. 86. 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
  87. 87. 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() { // ... } }
  88. 88. Annotations @Component – Create a Component of this type. Service is automatically published @Reference – Use the specified service
  89. 89. Add Life-cycle @Activate void start() { thread = new Thread(); thread.start(); } @Deactivate void stop() { thread.interrupt(); }
  90. 90. 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(); }
  91. 91. Optional Reference @Reference(service = LogService.class, optional = true) void setLogService(LogService log) { /* ... */ } void unsetLogService(LogService log) { /* ... */ }
  92. 92. Multiple Reference @Reference(service = MailboxListener.class, multiple = true) void addListener(MailboxListener listener) { /* ... */ } void removeListener(MailboxListener listener) { /* ... */ }
  93. 93. ❻ DEMO
  94. 94. Mailbox Reader Mailbox Fixed Mailbox
  95. 95. Mailbox Reader MailboxListener Mailbox Growing Mailbox
  96. 96. Mailbox Reader MailboxListener Mailbox Trades Order Entry Mailbox Matching EventHandler Service Trade Matching Event Broker Engine EventAdmin

×