46
OSGi DevCon 2009 Review Neil Bartlett - UK OSGi Users’ Forum

OSGi DevCon 2009 Review

Embed Size (px)

DESCRIPTION

A review of OSGi DevCon 2009, delivered at the first meeting of the UK OSGi Users' Forum.

Citation preview

Page 1: OSGi DevCon 2009 Review

OSGi DevCon 2009 Review

Neil Bartlett - UK OSGi Users’ Forum

Page 2: OSGi DevCon 2009 Review

ThemesOSGi Ubiquity

Enterprise OSGi

Distributed OSGi

Tooling

API Modernisation

OSGi for Eclipse Developers

“Symmetric” service oriented programming

JSR 294, Jigsaw, IBM/Sun Rumours

Page 3: OSGi DevCon 2009 Review

Ubiquity

Page 4: OSGi DevCon 2009 Review

Ubiquity

My third EclipseCon/OSGi DevCon

2007: Some people know what OSGi is.

2008: Most people know what OSGi is, some have developed for it.

2009: Many people know and have developed for OSGi.

Page 5: OSGi DevCon 2009 Review

Services and Apps

OSGi for modularity is mostly a done deal. All* app-servers & ESBs using it.

Next wave: Services/Dynamics, and OSGi for Apps.

Page 6: OSGi DevCon 2009 Review

Enterprise

Page 7: OSGi DevCon 2009 Review

Goals

Adapt enterprise tech without creating “editions”.

Preserve compatibility for users of enterprise APIs.

Page 8: OSGi DevCon 2009 Review

Timeline

Updated (R4.2) core & compendium specs in June 09.

Most changes are already implemented (provisionally) in Equinox.

“Enterprise Profile” in December 09.

Page 9: OSGi DevCon 2009 Review

Parts

Blueprint

Distributed OSGi (RFC 119)

Java EE Modularity

Page 10: OSGi DevCon 2009 Review

Blueprint

Essentially Spring-DM...

But name “Spring” is a trademark.

“Enterprise Programming Model”.

Page 11: OSGi DevCon 2009 Review

Old Spring

CustomerDAO

DataSource Log

CustomerManager

Page 12: OSGi DevCon 2009 Review

Spring-DM/Blueprint

Page 13: OSGi DevCon 2009 Review

Services as the Glue

Page 14: OSGi DevCon 2009 Review

Interoperable!

Page 15: OSGi DevCon 2009 Review

Java EE ModularityFor OSGi devs: add QoS (e.g. transactions, declarative security) to OSGi programming model.

For EE devs: enable OSGi modularity without breaking existing APIs.

Deployment of standard EE artefacts (WARs and EARs).

Page 16: OSGi DevCon 2009 Review

Distribution

Page 17: OSGi DevCon 2009 Review

What Is It?Normal OSGi is intra-JVM only.

D-OSGi makes the services programming model distributed.

Transparently publish services outside the JVM.

Transparently bind to services from other JVMs (or other non-Java runtimes).

Page 18: OSGi DevCon 2009 Review

Timeline

Spec will be included in R4.2 in June.

Reference implementation: Apache CXF available now.

Eclipse Comms Framework (ECF) also implements.

Page 19: OSGi DevCon 2009 Review

Distribution

Just add a property to the published service: osgi.remote.interfaces=*

Extender bundle will automatically make the service callable remotely.

Protocol depends on extender impl. E.g. SOAP, R-OSGi, XMPP, Skype...

Page 20: OSGi DevCon 2009 Review

Distribution

Find a remote service somehow*.

Extender bundle will create a local proxy service for it.

Page 21: OSGi DevCon 2009 Review

Discovery

Publishing and look-up of services.

Many ways to do it, many challenges.

Examples: SLP (RFC 2608), Bonjour/Zeroconf/DNS-SD.

Page 22: OSGi DevCon 2009 Review

Controversy?

Page 23: OSGi DevCon 2009 Review

Controversy?

Page 24: OSGi DevCon 2009 Review

Key Points...

D-OSGi allows transparent treatment of remote services

But it also allows clients to filter remote services and know when a service a remote proxy.

Is this enough...?

Page 25: OSGi DevCon 2009 Review

Key Points...

No new protocols!

D-OSGi wraps existing protocols.

It is optional.

Fears of bloating the core spec seem misplaced.

Page 26: OSGi DevCon 2009 Review

Tools

Page 27: OSGi DevCon 2009 Review

Tools

Lots of tooling discussions.

One evening BoF, a Summit, many hallway conversations.

More details from David.

Page 28: OSGi DevCon 2009 Review

API Modernisation

Page 29: OSGi DevCon 2009 Review

OSGi APIs “Feel” Old!

Page 30: OSGi DevCon 2009 Review

IdeasGenerics

Don’t return null arrays

Replace Dictionary with Map

Services returning multiple instances

Replace arrays with collections

Replace int masks with enums

Expanded filter ops

JSR 294 support

Page 31: OSGi DevCon 2009 Review

More Radical Ideas

Should exports have ranges rather than imports?

Make all events (ServiceEvent, BundleEvent etc) asynchronous.

Page 32: OSGi DevCon 2009 Review

OSGi for Eclipse Devs

Page 33: OSGi DevCon 2009 Review

OSGi for Eclipse Devs

Most Eclipse developers now know they are using OSGi!

Some even experimenting with Services (instead of Extensions).

Page 34: OSGi DevCon 2009 Review

Declarative Services

Eclipse SDK Galileo includes SCR.

Riena aids integration of Services and Extensions.

Component models tutorial (DS, Spring-DM, iPOJO) was packed.

Page 35: OSGi DevCon 2009 Review

“Symmetric” Services

Page 36: OSGi DevCon 2009 Review

What Is it?

Giving some power back to service producers.

Producers have no idea if anybody even needs the service they offer.

Page 37: OSGi DevCon 2009 Review

Why?

“On-demand” services.

Filtering on behalf of a consumer.

Service proxies – prevent the underlying service from being seen.

Needed for D-OSGi but will be part of core spec.

Page 38: OSGi DevCon 2009 Review

How It Works

ListenerHook – discover who is listening for which services.

EventHook – filter service events before they reach listeners.

FindHook – filter results of getServiceReferences() calls.

Page 39: OSGi DevCon 2009 Review

How It Works

Hooks are themselves published as services.

Powerful but NOT for the faint-hearted.

Wait for frameworks to make this easier?

Page 40: OSGi DevCon 2009 Review

Rumours...

Page 41: OSGi DevCon 2009 Review

JSR 277 Is Dead

Page 42: OSGi DevCon 2009 Review

Jigsaw Is Undead

Page 43: OSGi DevCon 2009 Review

Jigsaw

Page 44: OSGi DevCon 2009 Review

Jigsaw

Alternative module system to OSGi.

NOT a standard, just a Sun project.

EVIL.

Cannot be killed by silver bullets, but a Big Blue bullet might work...

Page 45: OSGi DevCon 2009 Review

JSR 294

Not necessarily evil...

Java language support for modules.

Designed for Jigsaw, but may help OSGi also.

Page 46: OSGi DevCon 2009 Review