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

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (20)

Semelhante a From Distributed to Pervasive OSGi

Semelhante a From Distributed to Pervasive OSGi (20)

Último

Último (20)

From Distributed to Pervasive OSGi