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?


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?


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


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


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


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


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


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


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


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


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]


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


Remote Services: Cohesion Distributed


Type Injection: Dealing with Coupling

public interface MyService { Bundle

void enqueue(QueueItem item);

Queue getQueue();

} MyService

Proxy
Bundle
MyService


DISTRIBUTED OSGI

Location-transparency for services
Point to point

Not a single system image
Not a distributed module runtime

PERVASIVE OSGI


The Cloud(s)

Amazon EC2 Yahoo Pipes

 Infrastructure as a service  Agility
 Pay as you go  Permanently available
 Horizontal Scale out


The Fabric of the Cloud: Distributed Systems

 Under the hood:

 Potentially
 unreliable hardware
 unreliable network

 Virtualized environment
 Little to no control


Distributed Systems Are Still Challenging

 Architecture
 Complexity
 Parallelization
 Debugging, Testing
 Deployment
 Management


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


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]


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]


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


Research Prototype: Cirrostratus

Overlay
Network


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


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)

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

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


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?

From Distributed to Pervasive OSGi

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (20)

Similar a From Distributed to Pervasive OSGi

Similar a From Distributed to Pervasive OSGi (20)

Último

Último (20)

From Distributed to Pervasive OSGi