Implicit Middleware

Implicit MiddlewareT. Riedel, M. Beigl, M. Berchtold, C. Deckerand A. Puder

Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 2

Motivation

Control of complex information flows between processes in the real world and computer-based information systems.

Information systems

Real world

ManualAccumulation

Files

Information

Objects, items, activities, events

Data basesObject-ID

Barcodescanning

RFID Tags

State

Sensor networks

Processes

SmartItems


Motivation: CoBis

Business Logic describes the real world processes in a virtual representation

Interfaces needed to couple real and virtual world and keep consistency

Smart Items: deploy business logic on sensor nodes

Example CoBIs: SAP Environment Health and Safety (EH&S)

Sensor Nodes on Chemical Drums

Storage Regulations Detection Services: Storage Incompatibility

Absolute volume limit

Temperature / Environmental constraints


Relocation of Services

Challenge: Integration Sensing Services in Application Framework

Problems: How to provide syntactically and semantically equal Interfaces?How to integrate into development process?How much of the code to execute on “the Node”?How to partition (existing) Services?

Task

Relocated Task

Collaborative Business Item s

Business Logic Backend

Sensor Network Relocated Task


Design of an Implicit Middleware

How much of code to execute on “the node”? Development date != deployment date

Changing HardwareAdvances in HardwareUse of more constraint/cheaper HW

Changing ConstraintsLifetime/energy saving constraints differ per application (not per service)

Changing Networking/topologies Based on local necessities, link costs vary with topologies (1 vs. n hop)Networks with hybrid nodes: more powerful router/gateway nodes


Design of an Implicit Middleware

How to partition (existing) Services? Maintain semantics of existing Service (Middleware):

Location transparencyAccess transparencyConcurrency transparencyFailure transparency *Technology transparency

Adding Middleware adds new abstractions: use VM semantics instead !!


Implicit Middleware Work-flow

Generating the optimal distribution of an application/service Optimality based on model !

Just before deployment

Implementation optimizes execution times network

instruction


Transformation Architecture

Java App/Service

Allocation Model

Trace Model

Optimization Problem

Distributed App

System Model

Platform ModelsSystem Landscape

Simulation

Optimization

Monitoring

Byte-Code Transformation

DeploymentInstantiation


Modeling Software and System

Java App/Service

Allocation Model

Trace Model


Distributed App

System Model


Simulation Monitoring

Deployment


System/Trace Model

System Model References Platform Model

Contains cost functions/parametersUser defined/from simulation

Generated from Node Discovery

Trace Model Use Eclipse Test and Performance Tools

Generates ecore model

Use simulated inputs Currently by random distributionSet of simulated runtime libraries

Execute program locally

Approximateaverage execution time of Class Aaverage number of calls from Class A to B

System Model


Monolithic Java App

Trace Model


Optimization

Java App/Service

Allocation Model

Trace Model


Distributed App

System Model


Optimization

Deployment


Optimization

Generate formal ILP Problem that assigns all classes to a Platform

( is the allocation relation to be found)

while minimizing communication and execution costs

Sensor Classes and immovable interfacesare fixed:

Allocation Model

Trace Model


System Model

Optimization

is a product :(



Java App/Service

Allocation Model

Trace Model


Distributed App

System Model



Deployment



Uses either ASM or XMLVM for code analysis/rewriting

Transformations build to retain code semantics

Statical analysis and rewriting/code generation on byte code/XMLVM level

Monolithic Java App

Allocation Model

Distributed App

Example: computationally heavy orclasses w/ WS interface

1st Stage: Partitioning Generate platform independent middleware code

2nd Stage: Target code generation

Use of XSLT technology

Principal support for arbitrary target language

Proof of concept javascript/C++ targets


Stub and Dispatcher Generation

Generated class stubs replace remote classes Interface to middleware runtime

Connects local and remote garbage collection

Generated dispatcher No runtime reflection

Perfect hash (possible because of late optimization)


Transparent Distribution

Stubs call Middleware to marshal calls Simple push interface

Type safe for basic data types

Objects are passed by reference

Add fixed class and method id

Dispatch calls method by id pops arguments from message


Runtime Architecture

Generic

Portable Specif

ic


Instantiation

Java App/Service

Allocation Model

Trace Model


Distributed App

System Model


DeploymentInstantiation


Deployment: Java on Particles/Sun Spots

Ultra light-weight Java VM on Particle computersFurther size and static optimizations on byte code level

Platform Independent Java ByteCode

Java ByteCodefor Particles

Strip down, optimization, versioning

Particle Computer

Java Virtual Machine

WirelessTransfer

Versioning control, Selective updates,Mass programming

CLDC 1.1 Java for Sun Spots


Optimization Results

Optimizing only for execution times

Optimizing only for call latencies


Performance

Optimizer (Simple Vibration Alarm Example) Using ZIMPL Interface: 342 variables and 980 constraints

Solved 0.2s on 1.65GHz x86 CPU by soPlex solver

Branch and Bound

Called once on deployment

Middleware Overhead Particle Computer

Low execution overhead (typ. <1ms per call vs. 13ms RF slot)Low memory overhead (in bytes):

Sun SpotsStub w/ Methods: code size 4,13 kByte High overhead due to thread generation (round trip >500 ms!!!)


Limitations/Discussion I

More complex cost models?Trace model based

Also becomes more difficult to modelExhaustive search

implemented but slowPossible heuristics are questionable

Describe as non-linear (convex) optimizations does also not describe most network effects

Simulation in the loopEasy integrability

All VM basedSimulator hooks can be generated

Really costly!


Limitations/Discussion II

Finer granularity for partitioning?Object mobility

Probably needed for realistic appsStubs for all classesSynchronization overhead = more runtime middlewareEfficient only with more statical analysis (data flow)

Function levelNeed to expose internal state

Instruction levelMore difficult to retain semanticsDistributed VM


Conclusion

Solution for easy development of “smart item” technology (1-click)

Optimizes partitioning between hybrid devices Based on device capabilities

Network properties

Implementation using generative model based approach Minimal runtime requirements

No reflection / efficient platform independent code

Support for energy efficient Particle sensor nodes and CLDC 1.1


Future Directions

Integration in Deployment Framework like OSGiRun Implicit Middleware as container/host rOSGi synergies?

Start directly from Abstract Models Does not require “reverse” engineering of classes

System already nicely integrates in EMF Toolchain

Build better models for simulation aspects

Integrate e.g. performance measures earlier in development process

Support for distributed sensor networking Capture semantics of context

Move away from pure Java semantics

Support parallel aggregating/redundant operations with variable # of nodes


Questions?