Implicit Middleware

Implicit Middleware
T. Riedel, M. Beigl, M. Berchtold, C. Decker
and A. Puder

Motivation

Information systems Information

Files
Data bases
Object-ID State Processes

Barcode RFID Sensor Smart
Manual scanning Tags networks Items
Accumulation

Real world Objects, items, activities, events

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

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

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
B u s in e s s L o g ic B a c k e n d
Task

S e n s o r N e tw o rk R e lo c a te d
Relocated Task
Task

C o lla b o r a tiv e B u s in e s s
Ite m s

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?


Design of an Implicit Middleware

How much of code to execute on “the node”?
 Development date != deployment date
 Changing Hardware
 Advances in Hardware
 Use of more constraint/cheaper HW

 Changing Constraints
 Lifetime/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 transparency
 Access transparency
 Concurrency transparency
 Failure 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

System
Java App/Service Platform Models
Landscape
Simulation Monitoring
Trace Model System Model

Byte-Code Optimization Problem
Transformation
Optimization
Allocation
Model

Distributed App
Deployment
Instantiation

Modeling Software and System

System
Landscape
Simulation Monitoring

Optimization Problem

Allocation
Model

Distributed App
Deployment


System/Trace Model

System Model
 References Platform Model System
Platform Models
Landscape
 Contains cost functions/parameters
 User defined/from simulation

 Generated from Node Discovery System Model

Trace Model
 Use Eclipse Test and Performance Tools
 Generates ecore model
 Use simulated inputs
 Currently by random distribution Monolithic Java App
 Set of simulated runtime libraries

 Execute program locally
Trace Model
 Approximate
 average execution time of Class A
 average number of calls from Class A to B


Optimization

System
Landscape


Optimization
Allocation
Model

Distributed App
Deployment


Optimization

 Generate formal ILP Problem that
assigns all classes to a Platform

( is the allocation relation to be found) Optimization

while minimizing communication Allocation
Model
and execution costs

is a product :(

 Sensor Classes and immovable interfaces
are fixed:


Byte-Code Transformation

System
Landscape


Byte-Code Optimization Problem
Transformation
Allocation
Model

Distributed App
Deployment


Byte-Code Transformation
1st Stage: Partitioning
Generate platform Monolithic Java App
independent middleware code
Allocation Model
2 Stage:
nd

Target code generation Distributed App
 Use of XSLT technology
 Principal support for arbitrary
target language
 Proof of concept javascript/C++
targets
Uses either ASM or XMLVM for
Example: computationally heavy or code analysis/rewriting
classes w/ WS interface
Transformations build to
retain code semantics
 Statical analysis and
rewriting/code generation on
byte code/XMLVM level


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

Generi
c

Portabl
e Specifi
c


Instantiation

System
Landscape



Allocation
Model

Distributed App
Deployment
Instantiation

Deployment: Java on Particles/Sun Spots

Ultra light-weight Java VM on Particle computers
Further size and static optimizations on byte code level

Platform Independent CLDC 1.1 Java
Java ByteCode for Sun Spots

Strip down,
optimization, versioning Java
Virtual Machine
Wireless
Java ByteCode Transfer
for Particles
Versioning control,
Selective updates, Particle Computer
Mass programming


Optimization Results
Optimizing only for call latencies

Optimizing only for execution times


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 Spots
 Stub 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 model
 Exhaustive search
 implemented but slow
 Possible heuristics are questionable
 Describe as non-linear (convex) optimizations
 does also not describe most network effects

 Simulation in the loop
 Easy integrability
 All VM based
 Simulator hooks can be generated
 Really costly!


Limitations/Discussion II

Finer granularity for partitioning?
 Object mobility
 Probably needed for realistic apps
 Stubs for all classes
 Synchronization overhead = more runtime middleware
 Efficient only with more statical analysis (data flow)

 Function level
 Need to expose internal state
 Instruction level
 More difficult to retain semantics
 Distributed 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 OSGi
 Run 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?


Implicit Middleware

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (11)

Similaire à Implicit Middleware

Similaire à Implicit Middleware (20)

Plus de Till Riedel

Plus de Till Riedel (14)

Dernier

Dernier (20)

Implicit Middleware

Notes de l'éditeur