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

Like this? Share it with your network

Share

From Distributed to Pervasive OSGi

on

  • 3,203 views

OSGi DevCon 2009 Presentation

OSGi DevCon 2009 Presentation

Statistics

Views

Total Views
3,203
Views on SlideShare
3,108
Embed Views
95

Actions

Likes
1
Downloads
82
Comments
0

5 Embeds 95

http://osgilook.wordpress.com 52
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 Presentation Transcript

  • 1. From Distributed to Pervasive OSGi Jan S. Rellermeyer Systems Group, ETH Zürich
  • 2. Welcome to Zürich! Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 2
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. Remote Services: Cohesion Distributed Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 15
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. Distributed Systems Are Still Challenging  Architecture  Complexity  Parallelization  Debugging, Testing  Deployment  Management Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 20
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Research Prototype: Cirrostratus Overlay Network Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 25
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. A Virtual Module Runtime + non-functional requirements + orthogonal concerns Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 30
  • 31. 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