OSGi DevCon Europe: Remote Services

Module management in java

Mystical class path
In the end, classpath is flat
With OSGi: explicit dependencies, yet declarative
Allows events, dynamic handling, introspection
Services in OSGi allow to reduce coupling, but when package dependencies are explicit it limits the modularity.

Service Registry

Registering services by name, therefore allowing to reference a service without dependency on the implementation

Distributed OSGi

Remote can be separate machine, or separate JVM
Why? Isolation, Redundancy, Distribution is needed by your architecture

OSGi 4.2 Remote Services

Service Hooks (can intercept service requests)
Proxies
Intents (denotes an abstract distribution capability, requires mutual agreement, derives from SCA)

Very Nice: R-OSGi Deployment definition tool for Eclipse!

Remote Services Mostly based on the fact that services are stateless.

Work in progress: replication,Research prototype: Cirrostratus

Interesting as this allows completely virtual deployment of bundles.

Though it is unclear how much of what is presented is actually really available. Presentation is tough to follow, yet very interesting.

To summarize, seems that for stateless services, OSGi 4.2 would be enough, Cirrostratus prototype deals with state replication, service migration and hardening policies.