Services-First Migration to OSGi

Services-FirstMigration to OSGi BJ Hargrave (IBM) Peter Kriens (aQute)

Agenda• Modularity Maturity Model• The Brick Wall• Couplings• µServices• What Broker?• Example• Conclusion

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

Modularity Maturity Model

1. Ad Hoc• Flat, manual class path• Single name space• Full visibility and normal accessibility• Monolithic• Highly coupled• Split Packages• Add/Shufﬂe JARs until it works

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/Shufﬂe JARs until it works

2. Managed• Treat JARs as a module• JAR Identity • Naming • Versioning• Dependencies• Repositories

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

3. Contracts• Interface based design, POJOs• Provide contracts for each connection between JARs• Implementation details inside the JAR• Versioning on contracts

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

4. Fences• Explicitly Import/Export packages• Explicitly specify requirements and capabilities• Enforce the module boundaries• Semantic Versioning• Side-by-side versioning supported

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

5. Optimize• Exploit concepts for modules and contracts• Delegated Control• Optimize the code base to leverage new patterns: • Extender • Whiteboard• Repeat

Today 1. Ad Hoc 2. 3.Managed Contracts 4. Fences 5. Optimize

Today 1. Ad Hoc Enterprise DI vn ,C m ice ing 2. 3. Ivy Managed Contracts gu r saw spjig 4. Fences 5. Optimize

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

Class.forName(String)

Class Spacepackageclass

Class Space V1 V2

Class Space V1 V2Class.forName

Class Space V1 V2x x Class.forName

Why Class.forName?

Why Class.forName? ! ! ! ! ! ! ! ! ! ! ! ! N G! P LIC OU

How to get an Instance? That is the Question!

Couplings modular not Example modular type FooImpl foo; Foo foo = (Foo)instance Class.forName(“FooImpl”) .newInstance();

Type Couplingclass Client {} class FooImpl{}

Type Couplingclass Client {} class FooImpl{} interface Foo{}

Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements

Type Couplingclass Client {} class FooImpl{} interface Foo{} uses implements get instance

Type Couplingclass Client {} class FooImpl{} o r ?l o ut s n einterface Foo{} C s uses implements Is get instance

Instance Coupling• New• Factory• Inversion of Control• Broker

Instance Coupling client container impl• New• Factory• Inversion of Control• Broker

µServices Primitive• Broker Pattern• Direction• Contract• Publish• Find• Bind• Who’s Listening?• Cardinality

µServices Primitive• Broker Pattern• Direction• Contract• Publish A S B• Find• Bind• Who’s listening?• Cardinality

Patterns• Factory• Listener• Discovery• Distribution

5. Optimize E

5. OptimizeA B CD E FG H I

Back to the Brick Wall

MigrationA B CD E FG H I

So we need a broker that runs without fences...

So we need a Broker that runs without Fences...SR o j o P

POJOSR• Developed by Karl Pauls• JavaOne presentation 24811• http://pojosr.googlecode.com• Based on Apache Felix

Gain• Existing libraries and many bundles work without modiﬁcation• 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

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

Migrating• Example: extend ant … the tool we all (sometimes) love and (sometimes) hate• We make different <helloXXX/> tasks

Ant Your Service• Base ant• Activator• Extender ant ... ...

Ant Your Service• Base ant pojosr ant• Activator• Extender ant ... ...

Ant Your Service Class<Task>• Base ant pojosr ant• Activator• Extender ant ... ...

Ant Your Service Class<Task> hello activator• Base ant pojosr ant• Activator• Extender ant ... ...

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>

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; }}

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; }}

Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant• Activator• Extender ant ... ...

Ant Your Service Class<Task> hello activator• Base ant pojosr pojo ant hello extendee• Activator• Extender ant ... ...

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 ... ...

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; }}

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

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

Good FencesMake Good Neighbors

Good Fences od ul esMake Good Neighbors m

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

Services-First Migration to OSGi

by bjhargrave on Oct 06, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 22

Statistics

Services-First Migration to OSGi — Presentation Transcript