OSGi Remote Services

www.paremus.com

Transforming the Way the World Runs Applications

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

www.paremus.comParemus Nov 2010

OSGi Remote ServicesA Flexible Foundation forComposite Applications

Holger Hoffstä[email protected]

http://www.paremus.com/


www.paremus.com




Who am I?• 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.



www.paremus.com




What's this about?• OSGi & Remote Services:

Motivation & History

• Overview of Remote Services/RSA Specifications

• Applicability & Use Cases

→ little to no code!



www.paremus.com




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



www.paremus.com




Systems Hygiene:simply a good idea

„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



www.paremus.com




..but what about Distributed Systems?



www.paremus.com




..hmm..why not..

„Just use RMI or EJB!It's built-in and Standard!“– your local Architecture Astronaut

...ooomphh →



www.paremus.com




/** * 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."; }} :-(



www.paremus.com




..hmm..why not..

„We should just use JMS or our Enterprisey 'Service Bus' for everything!“– probably someone on your team

..alrighty then.. →



www.paremus.com




..hmm..why not..

„I know! We can simply write our own RPC library over sockets! It's so easy! I did that back in Uni!“– your „Rock Star“ intern

..oh noes! →



www.paremus.com




Sad Reality• Any kind of distribution often still hardwired into „stuff“

(and nobody really understands how it works..or wants to)

• System evolution often burdened with architectural decisions at the 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



www.paremus.com




Silver Lining?• Previous attempts:

Tuscany SCA, R-OSGi, Newton..

• All have more or less similarideas: composite applications, distributed wiring..

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



www.paremus.com




Key Realizations

• Distributed systems need adaptability for ALL aspects:development, testing, deployment, runtime, maintenance

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



www.paremus.com




Standardize interaction,not features!

• Allow multiple implementations using different technologiesside-by-side

• Prevent „Golden Hammer Syndrome“:don't force choice of one technology for every kind of interaction, even when inappropriate



www.paremus.com




Consequences

• Almost-transparent extension of the OSGi service model: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 usableas transport!



www.paremus.com




OSGi EEG tothe 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



www.paremus.com




Remote Services



www.paremus.com




Remote Services

• Standardized Service Properties define the interaction between participants

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

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



www.paremus.com




Remote Services

phpphp

Easier cross-platform integration for OSGi!

ProtocolBuffers, Thrift, JSON-RPC, Avro..



www.paremus.com




Remote Service Admin



www.paremus.com




Remote Service Admin

• RSA itself merely an abstract control interface for implementors,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!



www.paremus.com




Discovery

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

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

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



www.paremus.com




Sounds awesome!



www.paremus.com




..but not so fast!

• Service interactions defined by Java interface – well-understood :-) – not very flexible :-(

• Fundamental limits to what can beexpressed with a synchronous RPC model

• Fallacies of Distributed Computing etc.



www.paremus.com




Problems with RPC

• Lack of reliability necessitates Fault Detection (active & passive)

• 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



www.paremus.com




OSGi helps!

• Can't fix the network, but does help with „unexpected“ faults:

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!



www.paremus.com




Actual Benefits (1)

• Isolate that special third-party native code that keeps crashingyour 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..



www.paremus.com




Actual Benefits (2)

• Ops teams usually more open to dynamic updates of isolated services 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 :)



www.paremus.com




Implementations

RSA Reference Implementation using Apache CXF and Zookeeper

Built on Eclipse Communication Framework

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



OSGi Remote Services

Technology

Transcript of OSGi Remote Services