This document discusses distributing OSGi applications across multiple nodes. It describes how the OSGi architecture provides a collaborative service-oriented architecture model within a single Java virtual machine. It then explains how the Distributed OSGi specification allows OSGi services to publish themselves and discover services outside their own runtime, maintaining the OSGi service programming model. The document provides examples of how services can invoke each other across OSGi runtimes. It also describes responsibilities of the DistributionProvider and Discovery services and how service registry hooks can be used. Finally, it outlines a demo using Terracotta middleware to cluster services across OSGi runtimes.

1. Distributing OSGi™
OSGi 4.2- Early Draft RFC-119 (with
a twist of Terracotta)

2. So who is Bram?
Bram de Kruijff
Computer Science / Cognitive Science
Lead Architect GX R&D
Mainly interested in web x.y, Java™, Linux,
Open Source, Open Standards
Bram.deKruijff@gxwebmanager.com

3. … and what is GX?
GX creative online development
Web Content Management
Nijmegen, Amsterdam, Eindhoven, Boston
Founded in 1995, first (Java™) CMS in 1998
GX WebManager 9 powered by OSGi™
http://www.gxwebmanager.com
http://www.gxdeveloperweb.com

4. Today’s menu!
Problem statement
OSGi™ Architecture
Distributed OSGi™
Demo setup
Code & Demo
Questions & discussion

5. Problem statement
How do we scale OSGi™ based application
without loosing flexibility at runtime or
violating the service programming model?
•Sharing object caches between nodes
•Manage deployment over multiple nodes
•Manage application state over multiple nodes
•Service collaboration over multiple nodes

6. OSGi™ Architecture
OSGi™ Architecture
• Security
• Modules
• Life Cycle
• Service Registry
• Services
“OSGi provides an inVM collaborative SOA model”

7. Distributed OSGi™
RFC 119 addresses the need for OSGi™
applications to operate in heterogeneous IT
environments
•Allow OSGi™ services to publish themselves
and be invoked from outside their own
runtime
•Allow OSGi™ services to discover and consume
services outside their own runtime

8. Distributed OSGi™
Example of a remote system invoking a service inside
the OSGi™ runtime
Source: OSGi specification

9. Distributed OSGi™
Example of a an service inside the OSGi™ runtime
invoking an external service
Source: OSGi specification

10. Distributed OSGi™
Example using this mechanism for communication
between multiple OSGi runtimes
Source: OSGi specification

11. Distributed OSGi™
Hey! I can do that using <enter favorite
middleware product here> too!
True, but…
Distributed OSGi™ standardizes the mechanism,
abstracts away from implementation specifics and
keeps the OSGI™ service programming model
intact

12. Distributed OSGi™
OSGi™ service programming model is kept
intact!
•Remotable services simply publish their Java
service interface with the service registry
•Remote services are published through
standard service registry
•Discovery and distribution through standard
service interfaces

13. Distributed OSGi™
Local services for distribution and discovery
Source: OSGi specification

14. Distributed OSGi™
Responsibilities of the DistributionProvider
service:
•Monitor availability of local remotable services
•Publish local remotable services with
Discovery
•Publish local endpoints for remote services
•Handle local service invocation of remote
services
•Handle remote service invocation of local
services

15. Distributed OSGi™
Responsibilities of the Discovery service
•Discover available remote services
•Monitor availability of remote services
•Notify DistributionProvider of changes
•Publish services in remote serviceregistries

16. Distributed OSGi™
Leveraging Service Registry Hooks (RFC 126)
•PublishHook – filtering service lifecycle
events before delivery
•FindHook – filtering service references
before return
•ListenerHook – monitoring service registry
listener registrations

17. Distributed OSGi™
Interaction example
Source: OSGi specification

18. Distributed OSGi™
Metadata and configuration
•org.osgi.remote.publish – indicates that a
service is to be made available
•org.osgi.remote.intents – list of (qualified)
intents for the published service
•org.osgi.remote.configuration.type – type of
additional metadata
Additional configuration is done at
deployment time through the DSW software

19. Distributed OSGi™
Conclusion
•Spec is still in early draft
•Nice fit wit existing service model
•Open and focused on collaboration
•Service Registry Hooks are very powerful
And it works 
•Apache CXF (Reference Implementation)
•Apache Tuscany (Work in progress)
•GXLabs JSpring 2009 demo!

20. Demo setup
To get things started we need an OSGi™
runtime and some kind of middleware
•OSGi™ framework •JVM level clustering
•Open source (ASL) •Open source (TPL)
•Small footprint •Non invasive
•Very stable •Lightweight

21. Demo setup
To meet our objectives we are going to create
several services
•MessageBus – Simple messaging service infrastructure based on
collections clustered by Terracotta
•DeploymentManager – Bundle deployment service that allows
cluster wide deployment of bundles using the MessageBus
•DistributionProvider – DSW implementation that remotes calls
using the MessageBus
•Discovery – Implementation of the Discovery service that
communicates over the MessageBus

22. Demo setup
More then a thousand words
OSGi runtime 1 TC OSGi runtime 2
Discovery Discovery
Message Message
BUS
Bus Bus
Distribution Distribution
Provider Provider
Distribution Cache Cache Cache Distribution
Manager Manager (1..n) Manager Manager

23. Demo & Code

24. Q&A
For more info on GX WebManager 9 have a look at
http://www.gxdeveloperweb.com