From Distributed to Pervasive OSGi

From Distributed to Pervasive OSGi Jan S. Rellermeyer Systems Group, ETH Zürich

Welcome to Zürich! Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 2

Software Modules  Structured Programming  Encapsulation David Parnas, 1972  Information Hiding  Coupling vs. Cohesion Larry Constantine, 1974  Separation of Concerns Edsger W. Dijkstra, 1974  Reuse Web services, OSGi  Orchestration  Software Design Principle  Base unit for adding orthogonal concerns The Future? Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 3

Module Management in Java  Traditional Java: The mystical class path  java –cp commons-X.jar foo.jar bar.jar my.application.MainClass  Which module contains the main class?  What are the dependencies between foo.jar and bar.jar?  What happens if bar.jar is upgraded to bar-1.01.jar? Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 4

The OSGi Framework Export-Package: Package 1 Export-Package: Package I, Package II Import-Package: Package 1 Exported Package Exported Package Package 1 Package I Bundle B Bundle A Import Package II Package 2 Package 3 Private Package OSGi Framework  Explicit dependencies  Explicit, yet declarative  Runtime  Dynamic  Events, Introspection Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 5

Modularity: Coupling vs. Cohesion Two components are loosely coupled, when changes in one never or rarely necessitate a change in the other A component exhibits high cohesion when all its functions/methods are strongly related in terms of function Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 6

OSGi Services: Reducing Coupling  Bundles are Modules  encapsulate functionality  deployment unit  Enable reuse, extension, and dynamic composition  But: Package dependencies are explicit. Interface  Can lead to all or nothing  Limits the modularity! Implementation  Solution: Services  Separate the interface from the implementation Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 7

The Service Registry  The OSGi framework maintains a central service registry  Bundles can register their own services and retrieve services provided by other bundles  Services can be registered with a set of properties  Additional description of the service, can be used to model constraints or do “best fit matching” Registry  Services are identified by their name Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 8

Distributed OSGi  General idea: use services provided by a remote machine  Loose coupling  Remote can be  Separate machine, connected through a network  Separate JVM, different address space  (Different language, different address space)  Why would you want this?  Isolation  Redundancy  Problem is inherently distributed Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 9

Preview: OSGi 4.2 Remote Services  Service Hooks  Distribution Software can intercept service requests  Proxies  Import a service into the local framework  Intents  Denotes an abstract distribution capability  Requires mutual agreement  Derived from SCA Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 10

Example: Eclipse Communication Framework Application Container Adapters Eclipse, RCP, Equinox Server Shared Editing Call 3 Jingle 1 2 Datashare Remote Services Discovery container Datashare File Transfer ECF Core Presence Shared Object XMPP (e.g.) OSGi/Equinox API Provider IAdaptable Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 11

ECF Remote Services  Can do RFC 119 Remote Service Provider  Will be made compliant with the 4.2 specs  Can use different distribution systems as backend  R-OSGi  ECF generic DSOs  Can do more  Proxy service has a distinct property service.imported set  In ECF, this is set to an IRemoteService instance  One-Shot, fireAsync  Futures, callAsync/1  Async with Listener, callAsync/2  Non-transparent access Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 12

R-OSGi  Preserves the expressiveness of OSGi  Every Java class can be a service  Runs with every OSGi framework  Consistently maps network failures to module lifecycle events  Proxy service provided by proxy bundle Life-cycle, consistent behavior  Is flexible, yet competitive in terms of performance [J. S. Rellermeyer, G. Alonso, T. Roscoe: R- OSGi: Distributed Applications through Software Modularization. In: Middleware 2007] Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 13

Dynamic Proxy Generation  Service: Interface + Implementation  Shared Knowledge: Interface public class MyServiceProxy implements MyService { public interface MyService { public String callMe(Integer i) { // generic remote service call public String callMe(Integer i); } } } Peer A Peer B Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 14

Remote Services: Cohesion Distributed Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 15

Type Injection: Dealing with Coupling public interface MyService { Bundle void enqueue(QueueItem item); Queue getQueue(); } MyService Proxy Bundle MyService Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 16

DISTRIBUTED OSGI Location-transparency for services Point to point Not a single system image Not a distributed module runtime PERVASIVE OSGI Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 17

The Cloud(s) Amazon EC2 Yahoo Pipes  Infrastructure as a service  Agility  Pay as you go  Permanently available  Horizontal Scale out Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 18

The Fabric of the Cloud: Distributed Systems  Under the hood:  Potentially  unreliable hardware  unreliable network  Virtualized environment  Little to no control Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 19

Distributed Systems Are Still Challenging  Architecture  Complexity  Parallelization  Debugging, Testing  Deployment  Management Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 20

Software Modules as an Application Model  Composable  Reusable  Manageable  Focus on functional aspects  Encourage to think about interfaces  Tool support  Building distributed systems without thinking of distribution Think of R-OSGi Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 21

R-OSGi: A First Step Into The Cloud  Services facilitate loose coupling and high cohesion Instrumental for parallelization, think about Map-Reduce!  R-OSGi preserves the expressiveness of OSGi services  Every Java class can be a service  With R-OSGi, almost every OSGi service can be a remote service Generality  Provides location transparency “Where” has a different meaning in a data center  Consistently maps network failures to module lifecycle events Node and network failures happen often! [J. S. Rellermeyer, M. Duller, G. Alonso: Engineering the Cloud from Software Modules. In: ICSE-Cloud 2009] Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 22

Example: R-OSGi Deployment Tool [J. S. Rellermeyer, G. Alonso, T. Roscoe: Ready for Distribution? Turning Modular into Distributed Applications with the R- OSGi Deployment Tool . Demo at OOPSLA 2007] Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 23

Modules for the Cloud  Distribution can be added as an orthogonal concern R-OSGi turns OSGi modules into a distributed system  So can replication  Instrumentation of the modules  Middleware support  Elasticity through redundancy and redeployment Module Module Module Module Module Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 24

Research Prototype: Cirrostratus Overlay Network Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 25

A Virtual Runtime for Modules  “Hypovisor” for OSGi Modules  Instruments Bundles  For paravirtualization  For state capturing  Shares internal state  Shared service registry  Shared bundle registry  Shares bundle state  Replication, migration Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 26

The Model of State  The fields of a service instance are “state”  The fields of “state” are “state”  “State” is replicated (and treated as “by reference”)  Everything else is local to the node (no state leakage) Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 27

Code Analysis: Symbolic Execution private int state; add(I)I L0 int add(int i) { ALOAD 0 state += i; DUP return state; GETFIELD test/Simple.state : I } ILOAD 1 IADD  Initialize the slots of the call stack PUTFIELD test/Simple.state : I with symbols L1  0 = “this”, 1 = arg0, 2 = local0 ALOAD 0  Initialize the fields with relative GETFIELD test/Simple.state : I IRETURN symbols L2  test/Simple.state = “Simple.state” LOCALVARIABLE this Ltest/Simple; L0 L2 0  Execute the code symbolically LOCALVARIABLE i I L0 L2 1  Execution stack becomes symbolic MAXSTACK = 3  Non-linear control flow leads to Phi- MAXLOCALS = 2 Symbols Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 28

Instrumentation for Replication private int state; int add(int i) { TransactionContext.BOT(“Simple.add”, i); private int state; TransactionContext.read(“Simple.state”); state += i; int add(int i) { TransactionContext.write(“Simple.state”, state += i; i); return state; return state; Simplication, it’s TransactionContext.EOT(); top of stack } }  TransactionContext binds free variables at runtime and puts fields into context  Similar: Instrumentation for thread migration Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zurich 29

A Virtual Module Runtime + non-functional requirements + orthogonal concerns Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 30

CONCLUSIONS  OSGi is a very interesting platform for building dynamic modular applications for Java.  Distribution software like R-OSGi facilitate remote access to OSGi services. The 4.2 specs will bring this to the mainstream.  The OSGi model is a perfect match for dynamic environments such as cloud computing  The Cirrostratus prototype enables adding even more sophisticated properties to modules than distribution, such as state replication, service migration, hardening policies.  It can thereby facilitate the even more pervasive usage of OSGi. Questions? Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 31

http://osgilook.com	33
http://osgilook.wordpress.com	23
http://www.slideshare.net	5
http://jisi.dreamblog.jp	2
http://www.linkedin.com	1

From Distributed to Pervasive OSGi

by Jan S. Rellermeyer on Jun 23, 2009

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 64

Statistics

From Distributed to Pervasive OSGi Presentation Transcript