Download to read offline
Uploaded byTill Riedel
Implicit Middleware
The document discusses the development of implicit middleware for integrating real-world processes with computer-based information systems, emphasizing smart items and their application in environments like chemical safety. It addresses challenges such as service integration and optimization of application distribution based on device capabilities and network conditions. Future directions include enhanced deployment frameworks and improved modeling for simulation and performance measures.
Implicit Middleware
- 1. Implicit Middleware T. Riedel,M. Beigl, M. Berchtold, C. Decker and A. Puder
- 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, 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
- 3. Motivation: CoBis BusinessLogic 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 3
- 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 Persys'08, Monterrey, 14.11.2008 4
- 5. Design of anImplicit 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 5
- 6. Design of anImplicit 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 Persys'08, Monterrey, 14.11.2008 6
- 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 instruction Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 7
- 8. 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 8
- 9. Modeling Software andSystem System Java App/Service Platform Models Landscape Simulation Monitoring Trace Model System Model Optimization Problem Allocation Model Distributed App Deployment Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 9
- 10. 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 10
- 11. Optimization System Java App/Service Platform Models Landscape Trace Model System Model Optimization Problem Optimization Allocation Model Distributed App Deployment Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 11
- 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 Persys'08, Monterrey, 14.11.2008 12
- 13. Byte-Code Transformation System Java App/Service Platform Models Landscape Trace Model System Model Byte-Code Optimization Problem Transformation Allocation Model Distributed App Deployment Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 13
- 14. 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 14
- 15. Stub and DispatcherGeneration 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 Persys'08, Monterrey, 14.11.2008 15
- 16. Transparent Distribution Stubscall 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 16
- 17. Runtime Architecture Generi c Portabl e Specifi c Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 17
- 18. Instantiation System Java App/Service Platform Models Landscape Trace Model System Model Optimization Problem Allocation Model Distributed App Deployment Instantiation Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 18
- 19. Deployment: Java onParticles/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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 19
- 20. Optimization Results Optimizing onlyfor call latencies Optimizing only for execution times Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 20
- 21. Performance Optimizer (SimpleVibration 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 Persys'08, Monterrey, 14.11.2008 21
- 22. Limitations/Discussion I Morecomplex 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 Persys'08, Monterrey, 14.11.2008 22
- 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 VM Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 23
- 24. Conclusion Solutionfor 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 24
- 25. Future Directions Integrationin 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 Till Riedel , TecO Persys'08, Monterrey, 14.11.2008 25
- 26. Questions? Till Riedel ,TecO Persys'08, Monterrey, 14.11.2008 26
Editor's Notes
- #3 Die Schlüsselposition der Perv.Comp.Systeme führt zu einer noch stärkeren Informatisierung der realen Welt