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

      Informatio...
Module Management in Java

 Traditional Java: The mystical class path

 java –cp commons-X.jar foo.jar bar.jar
  my.appl...
The OSGi Framework
  Export-Package: Package 1                                       Export-Package: Package I, Package II...
Modularity: Coupling vs. Cohesion

    Two components are loosely coupled, when changes in one never or rarely
    necessi...
OSGi Services: Reducing Coupling

    Bundles are Modules
           encapsulate functionality
           deployment un...
The Service Registry


 The OSGi framework maintains a central service registry

 Bundles can register their own service...
Distributed OSGi

 General idea: use services provided by a remote machine
        Loose coupling

 Remote can be
     ...
Preview: OSGi 4.2 Remote Services

 Service Hooks
        Distribution Software can intercept service requests

 Proxie...
Example: Eclipse Communication Framework

                                 Application                                    ...
ECF Remote Services

 Can do RFC 119 Remote Service Provider
        Will be made compliant with the 4.2 specs
        ...
R-OSGi

 Preserves the expressiveness of OSGi
        Every Java class can be a service
 Runs with every OSGi framework...
Dynamic Proxy Generation

 Service: Interface + Implementation
 Shared Knowledge: Interface




   public class MyServic...
Remote Services: Cohesion Distributed




Tuesday, June 23, 2009   Jan S. Rellermeyer, ETH Zürich   15
Type Injection: Dealing with Coupling

 public interface MyService {                                        Bundle


     ...
DISTRIBUTED OSGI

Location-transparency for services
Point to point

Not a single system image
Not a distributed module ru...
The Cloud(s)




     Amazon EC2                                                                   Yahoo Pipes

        I...
The Fabric of the Cloud: Distributed Systems

 Under the hood:

 Potentially
        unreliable hardware
        unrel...
Distributed Systems Are Still Challenging

      Architecture
      Complexity
      Parallelization
      Debugging, ...
Software Modules as an Application Model

      Composable
      Reusable
      Manageable
      Focus on functional a...
R-OSGi: A First Step Into The Cloud

 Services facilitate loose coupling and high cohesion
                         Instr...
Example: R-OSGi Deployment Tool




            [J. S. Rellermeyer, G. Alonso, T. Roscoe: Ready for Distribution? Turning ...
Modules for the Cloud

 Distribution can be added as an orthogonal concern
                         R-OSGi turns OSGi mod...
Research Prototype: Cirrostratus




                                                          Overlay
                   ...
A Virtual Runtime for Modules

 “Hypovisor” for OSGi Modules

 Instruments Bundles
        For paravirtualization
     ...
The Model of State




      The fields of a service instance are “state”
      The fields of “state” are “state”
     ...
Code Analysis: Symbolic Execution
                                                    private int state;
add(I)I
   L0    ...
Instrumentation for Replication
                         private int state;

                         int add(int i) {
   ...
A Virtual Module Runtime




+ non-functional requirements
+ orthogonal concerns




Tuesday, June 23, 2009          Jan S...
CONCLUSIONS
 OSGi is a very interesting platform for building dynamic modular
  applications for Java.
 Distribution sof...
Upcoming SlideShare
Loading in...5
×

From Distributed to Pervasive OSGi

1,571

Published on

OSGi DevCon 2009 Presentation

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,571
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
83
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

From Distributed to Pervasive OSGi

  1. 1. From Distributed to Pervasive OSGi Jan S. Rellermeyer Systems Group, ETH Zürich
  2. 2. Welcome to Zürich! Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Remote Services: Cohesion Distributed Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 15
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25. Research Prototype: Cirrostratus Overlay Network Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 25
  26. 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. 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. 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. 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. 30. A Virtual Module Runtime + non-functional requirements + orthogonal concerns Tuesday, June 23, 2009 Jan S. Rellermeyer, ETH Zürich 30
  31. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×