Services-First Migration to OSGi

5,321 views
5,184 views

Published on

Presentation by Peter Kriens and BJ Hargrave at JavaOne 2011.

Published in: Technology, Education
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
5,321
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
242
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Services-First Migration to OSGi

  1. 1. Services-FirstMigration to OSGi BJ Hargrave (IBM) Peter Kriens (aQute)
  2. 2. Agenda• Modularity Maturity Model• The Brick Wall• Couplings• µServices• What Broker?• Example• Conclusion
  3. 3. Modularity Maturity Model• 1 Ad Hoc• 2 Managed• 3 Contracts• 4 Fences Page 2 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved, © IBM Corp. 2011 21.09.2011• Inspired by Graham Charters’ excellent OSGi Community Event 2011 5 Optimize presentation @ http://slidesha.re/q8EHFp
  4. 4. Modularity Maturity Model
  5. 5. 1. Ad Hoc• Flat, manual class path• Single name space• Full visibility and normal accessibility• Monolithic• Highly coupled• Split Packages• Add/Shuffle JARs until it works
  6. 6. 1. Ad Hoc• Flat, manual class path• Single name space e l l H• Full visibility and normal accessibility• Monolithic AR•• Highly coupled Split Packages J• Add/Shuffle JARs until it works
  7. 7. 2. Managed• Treat JARs as a module• JAR Identity • Naming • Versioning• Dependencies• Repositories
  8. 8. 2. Managed a d• Treat JARs as a module n l o w he t• JAR Identity • Naming D o t • Versioning r n e• Dependencies n t e• Repositories i
  9. 9. 3. Contracts• Interface based design, POJOs• Provide contracts for each connection between JARs• Implementation details inside the JAR• Versioning on contracts
  10. 10. 3. Contracts• d e r a Interface based design, o POJOs• Provide contracts for l s s k s c a a each connection l h between JARs• Implementation details inside the JAR c• Versioning on contracts
  11. 11. 4. Fences• Explicitly Import/Export packages• Explicitly specify requirements and capabilities• Enforce the module boundaries• Semantic Versioning• Side-by-side versioning supported
  12. 12. 4. Fences• Explicitly Import/Export packages• Explicitly specify requirements and capabilities o d!•• Enforce the module boundaries Semantic Versioning Go• Side-by-side versioning supported
  13. 13. 5. Optimize• Exploit concepts for modules and contracts• Delegated Control• Optimize the code base to leverage new patterns: • Extender • Whiteboard• Repeat
  14. 14. 5. Optimize• Exploit concepts for modules and contracts• Delegated Control• Optimize the code base to leverage new patterns: • Extender • Whiteboard• Repeat
  15. 15. Today 1. Ad Hoc 2. 3.Managed Contracts 4. Fences 5. Optimize
  16. 16. Today 1. Ad Hoc Enterprise DI vn ,C m ice ing 2. 3. Ivy Managed Contracts gu r saw spjig 4. Fences 5. Optimize
  17. 17. Today 1. Ad Hoc Enterprise DI vn ,C m ice ing 2. 3. Ivy Managed Contracts gu r OSGi saw s pjig 4. Fences 5. Optimize
  18. 18. Today 1. Ad Hoc Enterprise DI vn ,C m ice ing 2. 3. Ivy Managed Contracts gu r OSGi saw s pjig 4. Fences 5. Optimize
  19. 19. Class.forName(String)
  20. 20. Class Spacepackageclass
  21. 21. Class Spacepackageclass
  22. 22. Class Spacepackageclass
  23. 23. Class Space V1 V2
  24. 24. Class Space V1 V2
  25. 25. Class Space V1 V2Class.forName
  26. 26. Class Space V1 V2x x Class.forName
  27. 27. Class Space V1 V2x x Class.forName
  28. 28. Why Class.forName?
  29. 29. Why Class.forName? ! ! ! ! ! ! ! ! ! ! ! ! N G! P LIC OU
  30. 30. How to get an Instance? That is the Question!
  31. 31. Couplings modular not Example modular type FooImpl foo; Foo foo = (Foo)instance Class.forName(“FooImpl”) .newInstance();
  32. 32. Type Couplingclass Client {} class FooImpl{}
  33. 33. Type Couplingclass Client {} class FooImpl{}
  34. 34. Type Couplingclass Client {} class FooImpl{} interface Foo{}
  35. 35. Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements
  36. 36. Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements get instance
  37. 37. Type Couplingclass Client {} class FooImpl{} o r ?l o ut s n einterface Foo{} C s uses implements Is get instance
  38. 38. Instance Coupling• New• Factory• Inversion of Control• Broker
  39. 39. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  40. 40. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  41. 41. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  42. 42. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  43. 43. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  44. 44. µServices Primitive• Broker Pattern• Direction• Contract• Publish• Find• Bind• Who’s Listening?• Cardinality
  45. 45. µServices Primitive• Broker Pattern• Direction• Contract• Publish A S B• Find• Bind• Who’s listening?• Cardinality
  46. 46. Patterns• Factory• Listener• Discovery• Distribution
  47. 47. 5. Optimize E
  48. 48. 5. OptimizeA B CD E FG H I
  49. 49. Back to the Brick Wall
  50. 50. MigrationA B CD E FG H I
  51. 51. MigrationA B CD E FG H I
  52. 52. MigrationA B CD E FG H I
  53. 53. MigrationA B CD E FG H I
  54. 54. MigrationA B CD E FG H I
  55. 55. So we need a broker that runs without fences...
  56. 56. So we need a Broker that runs without Fences...SR o j o P
  57. 57. POJOSR• Developed by Karl Pauls• JavaOne presentation 24811• http://pojosr.googlecode.com• Based on Apache Felix
  58. 58. Gain• Existing libraries and many bundles work without modification• Bundle (JAR) activation (have their own local main)• µServices• Dynamicity (in µServices)• Extender pattern (react on JAR content)• Migration path to Fences (OSGi)• Existing OSGi and non-OSGi tooling can be used
  59. 59. Loss• No dynamic install/uninstall/update• No side-by-side versioning• No module privacy• No explicit dependencies• No Lazy activation• No Bundle classpath• No Native Code support
  60. 60. Migrating• Example: extend ant … the tool we all (sometimes) love and (sometimes) hate• We make different <helloXXX/> tasks
  61. 61. Ant Your Service• Base ant• Activator• Extender ant ... ...
  62. 62. Ant Your Service• Base ant pojosr ant• Activator• Extender ant ... ...
  63. 63. Ant Your Service• Base ant pojosr ant• Activator• Extender ant ... ...
  64. 64. Ant Your Service Class<Task>• Base ant pojosr ant• Activator• Extender ant ... ...
  65. 65. Ant Your Service Class<Task> hello activator• Base ant pojosr ant• Activator• Extender ant ... ...
  66. 66. Ant Your Service Class<Task> hello activator• Base ant pojosr ant• Activator• Extender ant ... ...
  67. 67. Ant Your Service<project name="master"> <path id="bundles"> <fileset dir="bundles"> <include name="*.jar" /> </fileset> </path> <taskdef name="auto" classname="aQute.ant.connect.AutoTask" classpathref="bundles" /> <auto /> <helloActivator /></project>
  68. 68. Ant Your Servicepublic class Activator implements BundleActivator { public void start(BundleContext context) throws Exception { Properties props = new Properties(); props.put("ant", "helloActivator"); context.registerService(Class.class.getName(), HelloTask.class, props); } public void stop(BundleContext context) throws Exception { }}public class HelloTask extends Task { String message = "Hello Activator"; public void execute() { System.out.println(message); } public void setMessage(String m) { this.message = m; }}
  69. 69. Ant Your Servicepublic class Activator implements BundleActivator { t public void start(BundleContext context) throws Exception { f Properties props = new Properties(); u props.put("ant", "helloActivator"); r context.registerService(Class.class.getName(), c HelloTask.class, props); } public void stop(BundleContext context) throws Exception { }}public class HelloTask extends Task { String message = "Hello Activator"; public void execute() { System.out.println(message); } public void setMessage(String m) { this.message = m; }}
  70. 70. Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant• Activator• Extender ant ... ...
  71. 71. Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant hello extendee• Activator• Extender ant ... ...
  72. 72. Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant hello extendee• Activator Manifest-Version: 1.0• ant Ant-Task: helloExtender=HelloTask Extender ... ...
  73. 73. Ant Your Servicepublic class HelloTask extends Task { String message = "Hello Extender"; public void execute() { System.out.println(message); } public void setMessage(String m) { this.message = m; }}
  74. 74. Ant Your Servicepublic class HelloTask extends Task { String message = "Hello Extender"; public void execute() { System.out.println(message); } public void setMessage(String m) { this.message = m; }} u ft c r N O
  75. 75. Conclusion• Moving to Fences is hard because popular instance creation patterns are fundamentally not modular• Services-First approach works without Fences• After completion, moving to Fences is much easier
  76. 76. Good FencesMake Good Neighbors
  77. 77. Good Fences od ul esMake Good Neighbors m
  78. 78. Q&A

×