Services-First Migration to OSGi
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Services-First Migration to OSGi

  • 5,123 views
Uploaded on

Presentation by Peter Kriens and BJ Hargrave at JavaOne 2011.

Presentation by Peter Kriens and BJ Hargrave at JavaOne 2011.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,123
On Slideshare
5,101
From Embeds
22
Number of Embeds
3

Actions

Shares
Downloads
231
Comments
1
Likes
5

Embeds 22

http://a0.twimg.com 17
http://paper.li 4
http://us-w1.rockmelt.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Services-FirstMigration to OSGi BJ Hargrave (IBM) Peter Kriens (aQute)
  • 2. Agenda• Modularity Maturity Model• The Brick Wall• Couplings• µServices• What Broker?• Example• Conclusion
  • 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. Modularity Maturity Model
  • 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. 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. 2. Managed• Treat JARs as a module• JAR Identity • Naming • Versioning• Dependencies• Repositories
  • 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. 3. Contracts• Interface based design, POJOs• Provide contracts for each connection between JARs• Implementation details inside the JAR• Versioning on contracts
  • 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. 4. Fences• Explicitly Import/Export packages• Explicitly specify requirements and capabilities• Enforce the module boundaries• Semantic Versioning• Side-by-side versioning supported
  • 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. 5. Optimize• Exploit concepts for modules and contracts• Delegated Control• Optimize the code base to leverage new patterns: • Extender • Whiteboard• Repeat
  • 14. 5. Optimize• Exploit concepts for modules and contracts• Delegated Control• Optimize the code base to leverage new patterns: • Extender • Whiteboard• Repeat
  • 15. Today 1. Ad Hoc 2. 3.Managed Contracts 4. Fences 5. Optimize
  • 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. 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. 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. Class.forName(String)
  • 20. Class Spacepackageclass
  • 21. Class Spacepackageclass
  • 22. Class Spacepackageclass
  • 23. Class Space V1 V2
  • 24. Class Space V1 V2
  • 25. Class Space V1 V2Class.forName
  • 26. Class Space V1 V2x x Class.forName
  • 27. Class Space V1 V2x x Class.forName
  • 28. Why Class.forName?
  • 29. Why Class.forName? ! ! ! ! ! ! ! ! ! ! ! ! N G! P LIC OU
  • 30. How to get an Instance? That is the Question!
  • 31. Couplings modular not Example modular type FooImpl foo; Foo foo = (Foo)instance Class.forName(“FooImpl”) .newInstance();
  • 32. Type Couplingclass Client {} class FooImpl{}
  • 33. Type Couplingclass Client {} class FooImpl{}
  • 34. Type Couplingclass Client {} class FooImpl{} interface Foo{}
  • 35. Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements
  • 36. Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements get instance
  • 37. Type Couplingclass Client {} class FooImpl{} o r ?l o ut s n einterface Foo{} C s uses implements Is get instance
  • 38. Instance Coupling• New• Factory• Inversion of Control• Broker
  • 39. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  • 40. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  • 41. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  • 42. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  • 43. Instance Coupling client container impl• New• Factory• Inversion of Control• Broker
  • 44. µServices Primitive• Broker Pattern• Direction• Contract• Publish• Find• Bind• Who’s Listening?• Cardinality
  • 45. µServices Primitive• Broker Pattern• Direction• Contract• Publish A S B• Find• Bind• Who’s listening?• Cardinality
  • 46. Patterns• Factory• Listener• Discovery• Distribution
  • 47. 5. Optimize E
  • 48. 5. OptimizeA B CD E FG H I
  • 49. Back to the Brick Wall
  • 50. MigrationA B CD E FG H I
  • 51. MigrationA B CD E FG H I
  • 52. MigrationA B CD E FG H I
  • 53. MigrationA B CD E FG H I
  • 54. MigrationA B CD E FG H I
  • 55. So we need a broker that runs without fences...
  • 56. So we need a Broker that runs without Fences...SR o j o P
  • 57. POJOSR• Developed by Karl Pauls• JavaOne presentation 24811• http://pojosr.googlecode.com• Based on Apache Felix
  • 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. 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. Migrating• Example: extend ant … the tool we all (sometimes) love and (sometimes) hate• We make different <helloXXX/> tasks
  • 61. Ant Your Service• Base ant• Activator• Extender ant ... ...
  • 62. Ant Your Service• Base ant pojosr ant• Activator• Extender ant ... ...
  • 63. Ant Your Service• Base ant pojosr ant• Activator• Extender ant ... ...
  • 64. Ant Your Service Class<Task>• Base ant pojosr ant• Activator• Extender ant ... ...
  • 65. Ant Your Service Class<Task> hello activator• Base ant pojosr ant• Activator• Extender ant ... ...
  • 66. Ant Your Service Class<Task> hello activator• Base ant pojosr ant• Activator• Extender ant ... ...
  • 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. 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. 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. Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant• Activator• Extender ant ... ...
  • 71. Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant hello extendee• Activator• Extender ant ... ...
  • 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. 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. 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. 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. Good FencesMake Good Neighbors
  • 77. Good Fences od ul esMake Good Neighbors m
  • 78. Q&A