OSGi Remote Services

OSGi Remote the Way
Transforming Services
the World Runs Applications
A Flexible Foundation for
Composite Applications

Holger Hoffstätte
holger.hoffstatte@paremus.com

Paremus www.paremus.com Nov 2010
Copyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.

Who am I?
• Transforming the Way
Holger Hoffstätte (aka @asynchronaut)
Living & working in Germany, near Cologne
• Consulting Engineer for Paremus Ltd.
Working on next-generation Service Fabric product line

• >20 years experience with concurrent/distributed systems, incl.
Agile/Process coaching, AOP, B2B, Enterprise Integration etc.


What's this about?
OSGi & Remote Services:
Motivation & History
the World Runs Specifications
• Overview of Remote Services/RSA Applications
• Applicability & Use Cases
→ little to no code!


OSGi = SOA!
Physical and logical isolation of Bundles

• Bundle Wiring with dynamic behaviour
• Service registration, discovery & matching

• Lifecycle control

• In R4.2: scoped visibility of services & events


Systems Hygiene:
simply a good idea
Transforming the Way
„The ability of OSGi to
handle complex systems as
a set of interdependent
modules is kind of like toilet
paper: Sooner or later, you're
going to want to use it.“
– Hal Hildebrand


..but what about Distributed
Systems?


..hmm..why not..
„Just use RMI or EJB!
It's built-in and Standard!“ Runs Applications
the World
– your local Architecture Astronaut

...ooomphh →


/**
* Implementation of ICustomRemote Interface.
*/
public class CustomRemoteImpl extends UnicastRemoteObject implements ICustomRemote {

/**
* Necessary because Super-Class constructor throws RemoteException.

* @throws java.rmi.RemoteException Will be thrown if there are some network
* errors.
*/
public CustomRemoteImpl() throws RemoteException {
}
/**
* Returns a string which say 'Hello World with RMI.'
* @return the string which holds the value.
* @throws java.rmi.RemoteException Will be thrown if there are some network
* problems.
*/
public String sayHello() throws RemoteException {

:-(
return "Hello World with RMI.";
}
}


..hmm..why not..
„We should just use JMS or
our EnterpriseyWorld Runs Applications
the 'Service Bus' for
everything!“
– probably someone on your team

..alrighty then.. →


..hmm..why not..
„I know! We can simply write
our own RPC library over Runs Applications
the World
sockets! It's so easy! I did
that back in Uni!“
– your „Rock Star“ intern

..oh noes! →


Sad Reality
Any kind of distribution often still hardwired into „stuff“
(and nobody really understands how it works..or wants to)

• System evolutionWorld Runs Applications the
the often burdened with architectural decisions at
wrong time of the development cycle:

• Distribution features added either „too early“ or „too late“

• Negatively impacts time-to-feature & subsystem/integration testing

• Iterations increasingly resemble wading through mud

Silver Lining?
Previous attempts:
Tuscany SCA, R-OSGi, Newton..
the or less similar
• All have more World Runs Applications
ideas: composite applications,
distributed wiring..

• All more or less incompatible with
each other and/or „standard“ OSGi

Key Realizations
Transforming theALL aspects:
• Distributed systems need adaptability for Way
development, testing, deployment, runtime, maintenance

• No Silver Bullet/Golden Hammer possible:
too many contradicting requirements like
availability, cost, licensing, interop, latency, knowledge, security..


Standardize interaction,
not features!
• Allow multiple implementations using different technologies
side-by-side World Runs Applications
the
• Prevent „Golden Hammer Syndrome“:
don't force choice of one technology for every kind of interaction,
even when inappropriate


Consequences
Transforming OSGi service model:
• Almost-transparent extension of the the Way
no explicit infrastructure API in „user code“!

• No mandated use of SOAP/RMI/HTTP/JMS/etc.:
choice of technology can be driven by requirements

• anything that moves bytes from A to B should be usable
as transport!


OSGi EEG to
the Rescue!
• Definition of Remote Services in OSGi R4.2
• Two minimalistic specs that accommodate each other:
• Remote Services: the „mechanics“ of transports
• Remote Service Admin: standardized discovery &
import/export visibility control


Remote Services


Remote Services
Transforming the Way between
• Standardized Service Properties define the interaction
participants

• Abstract „Intents“ specify context-dependent „required vs. provided“
capabilities; matched by standard OSGi filters

• Flexible configuration: properties, code, vendor-specific..


Remote Services
Easier cross-platform
integration for OSGi!
ProtocolBuffers, Thrift,
JSON-RPC, Avro..

php

Remote Service Admin


Remote Service Admin
Transforming the Wayimplementors,
• RSA itself merely an abstract control interface for
usually the vendor of a distribution provider

• Discovery providers discover/announce services on the network
• „Topology Manager“ controls import/export visibility;
specifics left to implementation → innovation!


Discovery
• Discovery providers are simply „EndpointListeners“
that map a specific service announcement to & from a
standardized „EndpointDescription“

• Can use any mechanism that can store & update
service state/visibility

• Obvious candidates: SLP, DNS-SD, Data Distribution Service,
Apache Zookeeper, RDBMS, Data Grids, P2P Systems, DHTs..

Sounds awesome!


..but not so fast!
• Service interactions defined by Java interface
– well-understood :-)
– not very flexible :-(

• Fundamental limits to what can be
expressed with a synchronous RPC model

• Fallacies of Distributed Computing etc.


Problems with RPC
Transforming Detection (active & passive)
• Lack of reliability necessitates Fault the Way
• Call-by-reference vs. Call-by-value:
impact on interaction semantics that cannot be ignored

• Latency spikes will introduce strong variance in perceived behaviour

• Variance adds up if remote services are chained


OSGi helps!
Transforming with „unexpected“ faults:
• Can't fix the network, but does help the Way
org.osgi.framework.ServiceException extends RuntimeException

• Service are expected to be dynamic – no change! :-)

• What changes is the scope of a disappearing service -
...but does that really matter? Gone is gone!


Actual Benefits (1)
Transforming the that keeps crashing
• Isolate that special third-party native code Way
your entire JVM

• Operational isolation through service visibility policies
→ smaller/faster test cycles → faster time-to-feature
→ no accidental crosstalk between development teams
→ runtime: security, confidentiality..


Actual Benefits (2)
Transforming the updates of isolated
• Ops teams usually more open to dynamic Way
services the World Runs Applications
in separate processes – much easier now

• Service Migration on host downtime
→ switching services much faster than host recovery/reboot

• Service selection based on cost/performance/latency..
→ finally a good reason to do proper end-to-end system design :)


Implementations
the World Runs on Eclipse Communication Framework
RSA Reference Implementation using
Apache CXF and Zookeeper
Built Applications

Based on RI but rewritten for correctness, extensibility,
Built with Tuscany/SCA RSA compliance. Basis for commercial product.


OSGi Remote Services

More Related Content

Similar to OSGi Remote Services (20)

Recently uploaded (20)

OSGi Remote Services