Implicit Middleware

769 views

Published on

http://link.springer.com/chapter/10.1007%2F978-3-540-88875-8_108

This paper introduces an approach for abstracting access to functionality in Pervasive Computing systems where very different types of devices co-exist. Tiny, resource-poor 8-bit based wireless embedded sensor nodes use highly fragmented programming, with code distributed over possibly hundreds of nodes. More powerful devices as mobile, handled devices, laptops or even server use coarse-grained distribution. The Implicit Middleware approach provides a way to both unify and simplify middleware for Pervasive Computing systems, by means of transparently distributing functionality in the system and making them context aware. The approach ensures optimized run-time behavior and adaptation to the system landscape. We also present an implementation using the XMLVM representation for code generation, and an evaluation running on PCs, J2ME CLDC 1.0 compatible 32Bit sensor nodes and 8Bit-MCU based nodes with an optimized light-weight VM.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
769
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Die Schlüsselposition der Perv.Comp.Systeme führt zu einer noch stärkeren Informatisierung der realen Welt
  • Implicit Middleware

    1. 1. Implicit MiddlewareT. Riedel, M. Beigl, M. Berchtold, C. Deckerand A. Puder
    2. 2. 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, eventsControl of complex information flows between processes in the real world and computer-based information systems.Till Riedel , TecO Persys08, Monterrey, 14.11.2008 2
    3. 3. 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 constraintsTill Riedel , TecO Persys08, Monterrey, 14.11.2008 3
    4. 4. 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?Till Riedel , TecO Persys08, Monterrey, 14.11.2008 4
    5. 5. 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 nodesTill Riedel , TecO Persys08, Monterrey, 14.11.2008 5
    6. 6. 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 !!Till Riedel , TecO Persys08, Monterrey, 14.11.2008 6
    7. 7. Implicit Middleware Work-flow Generating the optimal distribution of an application/service  Optimality based on model ! Just before deployment Implementation optimizes execution times  network  instructionTill Riedel , TecO Persys08, Monterrey, 14.11.2008 7
    8. 8. Transformation Architecture System Java App/Service Platform Models Landscape Simulation Monitoring Trace Model System Model Byte-Code Optimization Problem Transformation Optimization Allocation ModelDistributed App Deployment InstantiationTill Riedel , TecO Persys08, Monterrey, 14.11.2008 8
    9. 9. Modeling Software and System System Java App/Service Platform Models Landscape Simulation Monitoring Trace Model System Model Optimization Problem Allocation ModelDistributed App DeploymentTill Riedel , TecO Persys08, Monterrey, 14.11.2008 9
    10. 10. System/Trace ModelSystem Model  References Platform Model System Platform Models Landscape  Contains cost functions/parameters  User defined/from simulation  Generated from Node Discovery System ModelTrace 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 BTill Riedel , TecO Persys08, Monterrey, 14.11.2008 10
    11. 11. Optimization System Java App/Service Platform Models Landscape Trace Model System Model Optimization Problem Optimization Allocation ModelDistributed App DeploymentTill Riedel , TecO Persys08, Monterrey, 14.11.2008 11
    12. 12. Optimization Trace Model System Model  Generate formal ILP Problem that assigns all classes to a Platform Optimization Problem ( 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:Till Riedel , TecO Persys08, Monterrey, 14.11.2008 12
    13. 13. Byte-Code Transformation System Java App/Service Platform Models Landscape Trace Model System Model Byte-Code Optimization Problem Transformation Allocation ModelDistributed App DeploymentTill Riedel , TecO Persys08, Monterrey, 14.11.2008 13
    14. 14. Byte-Code Transformation1st Stage: Partitioning Generate platform Monolithic Java App independent middleware code Allocation Model2 Stage: ndTarget 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 forExample: computationally heavy or code analysis/rewritingclasses w/ WS interface Transformations build to retain code semantics  Statical analysis and rewriting/code generation on byte code/XMLVM level Till Riedel , TecO Persys08, Monterrey, 14.11.2008 14
    15. 15. 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)Till Riedel , TecO Persys08, Monterrey, 14.11.2008 15
    16. 16. 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 messageTill Riedel , TecO Persys08, Monterrey, 14.11.2008 16
    17. 17. Runtime Architecture Generi c Portabl e Specifi cTill Riedel , TecO Persys08, Monterrey, 14.11.2008 17
    18. 18. Instantiation System Java App/Service Platform Models Landscape Trace Model System Model Optimization Problem Allocation ModelDistributed App Deployment InstantiationTill Riedel , TecO Persys08, Monterrey, 14.11.2008 18
    19. 19. Deployment: Java on Particles/Sun Spots Ultra light-weight Java VM on Particle computers Further size and static optimizations on byte code levelPlatform 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 programmingTill Riedel , TecO Persys08, Monterrey, 14.11.2008 19
    20. 20. Optimization ResultsOptimizing only for call latenciesOptimizing only for execution times Till Riedel , TecO Persys08, Monterrey, 14.11.2008 20
    21. 21. 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!!!)Till Riedel , TecO Persys08, Monterrey, 14.11.2008 21
    22. 22. 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!Till Riedel , TecO Persys08, Monterrey, 14.11.2008 22
    23. 23. 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 VMTill Riedel , TecO Persys08, Monterrey, 14.11.2008 23
    24. 24. 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.1Till Riedel , TecO Persys08, Monterrey, 14.11.2008 24
    25. 25. 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 nodesTill Riedel , TecO Persys08, Monterrey, 14.11.2008 25
    26. 26. Questions?Till Riedel , TecO Persys08, Monterrey, 14.11.2008 26

    ×