services first migration to osgi - osgi users forum uk 16-nov2011

Services-First Migration to OSGi

BJ Hargrave (IBM)Peter Kriens (aQute)

woensdag 16 november 11

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

• 5 Optimize

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 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/Shuffle JARs until it works


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

JAR H

ell


2. Managed

• Treat JARs as a module

• JAR Identity

• Naming

• Versioning

• Dependencies

• Repositories


2. Managed

• Treat JARs as a module

• JAR Identity

• Naming

• Versioning

• Dependencies

• Repositories

Down

load

the

inter

net


3. Contracts

• Interface based design, POJOs

• Provide contracts for each connection between JARs

• Implementation details inside the JAR

• Versioning on contracts


3. Contracts

• Interface based design, POJOs

• Provide contracts for each connection between JARs

• Implementation details inside the JAR

• Versioning on contracts

classloa

der

hacks


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

• Enforce the module boundaries

• Semantic Versioning

• Side-by-side versioning supported

Good!


5. Optimize• Exploit concepts for

modules and contracts

• Delegated Control

• Optimize the code base to leverage new patterns:

• Extender

• Whiteboard

• Repeat


Today1.

Ad Hoc

2.Managed

3.Contracts

4.Fences

5.Optimize


Today1.

Ad Hoc

2.Managed

3.Contracts

4.Fences

5.Optimize

mvn

Ivy

jigsaw

guice

,CDI

sprin

g

Enterprise


OSGi

Today1.

Ad Hoc

2.Managed

3.Contracts

4.Fences

5.Optimize

mvn

Ivy

jigsaw

guice

,CDI

sprin

g

Enterprise


OSGi

Today1.

Ad Hoc

2.Managed

3.Contracts

4.Fences

5.Optimize

mvn

Ivy

jigsaw

guice

,CDI

sprin

g

Enterprise

4.Fences


Class.forName(String)


Class Space

class

package


Class Space

V1 V2


Class Space

V1 V2

Class.forName


Class Space

V1 V2

xxClass.forName


Why Class.forName?


Why Class.forName?

COUP

LING!!!!!!!!!!!!!


How to get an Instance?That is the Question!


Couplings

modular not modular

Example

type FooImpl foo;

instanceFoo foo = (Foo) Class.forName(“FooImpl”) .newInstance();


Type Couplingclass FooImpl{}class Client {}


Type Couplingclass FooImpl{}

interface Foo{}

class Client {}



interface Foo{}

class Client {}

uses implements



interface Foo{}

class Client {}

uses implements

get instance



interface Foo{}

class Client {}

uses implements

get instance

Contro

l

Issue

s?


Instance Coupling

• New

• Factory

• Inversion of Control

• Broker


Instance Coupling

• New

• Factory

• Inversion of Control

• Broker

implclient container


µServices Primitive• Broker Pattern

• Direction

• Contract

• Publish

• Find

• Bind

• Who’s Listening?

• Cardinality


µServices Primitive• Broker Pattern

• Direction

• Contract

• Publish

• Find

• Bind

• Who’s listening?

• Cardinality

BA S


Patterns

• Factory

• Listener

• Discovery

• Distribution


5. Optimize

E


5. Optimize

D

A

G

B

E

H

C

F

I


Back to the Brick Wall


Migration

D

A

G

B

E

H

C

F

I


D

A

G

B

E

H

C

F

I

Migration

D

A

G

B

E

H

C

F

I


Migration

D

A

G

B

E

H

C

F

I


So we need a broker that runs without

fences...


So we need a Broker that runs without

Fences...

PojoSR


POJOSR

• Developed by Karl Pauls

• JavaOne presentation 24811

• http://pojosr.googlecode.com

• Based on Apache Felix


https://code.google.com/p/pojosr/

https://code.google.com/p/pojosr/

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


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

• Extenderant

......


Ant Your Service

• Base ant

• Activator

• Extenderant

pojosrant

......


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojosrant


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojosrant

Class<Task>


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojosrant

helloactivator

Class<Task>


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 {

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

cruft


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojoant

helloactivator

Class<Task>

pojosrant


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojoant

helloactivator

Class<Task>

pojosrant

helloextendee


Ant Your Service

• Base ant

• Activator

• Extenderant

......

pojoant

helloactivator

Class<Task>

pojosrant

helloextendee

Manifest-Version: 1.0Ant-Task: helloExtender=HelloTask


Ant Your Service

public 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 Service

public class HelloTask extends Task { String message = "Hello Extender"; public void execute() { System.out.println(message); } public void setMessage(String m) { this.message = m; }}

NO cr

uft


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 FencesMake Good Neighborsmodules


Q&A


services first migration to osgi - osgi users forum uk 16-nov2011

Technology