OSGi DevCon 2009 Review
-
Upload
njbartlett -
Category
Technology
-
view
2.610 -
download
0
description
Transcript of OSGi DevCon 2009 Review
OSGi DevCon 2009 Review
Neil Bartlett - UK OSGi Users’ Forum
ThemesOSGi Ubiquity
Enterprise OSGi
Distributed OSGi
Tooling
API Modernisation
OSGi for Eclipse Developers
“Symmetric” service oriented programming
JSR 294, Jigsaw, IBM/Sun Rumours
Ubiquity
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.
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.
Enterprise
Goals
Adapt enterprise tech without creating “editions”.
Preserve compatibility for users of enterprise APIs.
Timeline
Updated (R4.2) core & compendium specs in June 09.
Most changes are already implemented (provisionally) in Equinox.
“Enterprise Profile” in December 09.
Parts
Blueprint
Distributed OSGi (RFC 119)
Java EE Modularity
Blueprint
Essentially Spring-DM...
But name “Spring” is a trademark.
“Enterprise Programming Model”.
Old Spring
CustomerDAO
DataSource Log
CustomerManager
Spring-DM/Blueprint
Services as the Glue
Interoperable!
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).
Distribution
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).
Timeline
Spec will be included in R4.2 in June.
Reference implementation: Apache CXF available now.
Eclipse Comms Framework (ECF) also implements.
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...
Distribution
Find a remote service somehow*.
Extender bundle will create a local proxy service for it.
Discovery
Publishing and look-up of services.
Many ways to do it, many challenges.
Examples: SLP (RFC 2608), Bonjour/Zeroconf/DNS-SD.
Controversy?
Controversy?
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...?
Key Points...
No new protocols!
D-OSGi wraps existing protocols.
It is optional.
Fears of bloating the core spec seem misplaced.
Tools
Tools
Lots of tooling discussions.
One evening BoF, a Summit, many hallway conversations.
More details from David.
API Modernisation
OSGi APIs “Feel” Old!
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
More Radical Ideas
Should exports have ranges rather than imports?
Make all events (ServiceEvent, BundleEvent etc) asynchronous.
OSGi for Eclipse Devs
OSGi for Eclipse Devs
Most Eclipse developers now know they are using OSGi!
Some even experimenting with Services (instead of Extensions).
Declarative Services
Eclipse SDK Galileo includes SCR.
Riena aids integration of Services and Extensions.
Component models tutorial (DS, Spring-DM, iPOJO) was packed.
“Symmetric” Services
What Is it?
Giving some power back to service producers.
Producers have no idea if anybody even needs the service they offer.
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.
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.
How It Works
Hooks are themselves published as services.
Powerful but NOT for the faint-hearted.
Wait for frameworks to make this easier?
Rumours...
JSR 277 Is Dead
Jigsaw Is Undead
Jigsaw
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...
JSR 294
Not necessarily evil...
Java language support for modules.
Designed for Jigsaw, but may help OSGi also.