From Distributed to Pervasive OSGi
Upcoming SlideShare
Loading in...5
×
 

From Distributed to Pervasive OSGi

on

  • 3,181 views

OSGi DevCon 2009 Presentation

OSGi DevCon 2009 Presentation

Statistics

Views

Total Views
3,181
Views on SlideShare
3,088
Embed Views
93

Actions

Likes
1
Downloads
82
Comments
0

5 Embeds 93

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

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

From Distributed to Pervasive OSGi From Distributed to Pervasive OSGi Presentation Transcript

  • 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