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
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
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