MICS Cluster 4 In-network information management

Size: px

Start display at page:

Download "MICS Cluster 4 In-network information management"

Joan Warner
6 years ago
Views:

Rellermeyer, Christian Duda, Cedric Gaspoz, Michael Duller, Angela Nicoara, Rokas

1 MICS Cluster 4 In-network information management A summary by XXX 1 1 Affilation with slides provided by: Adriana Budura, Rene Mueller, Jan S. Rellermeyer, Christian Duda, Cedric Gaspoz, Michael Duller, Angela Nicoara, Rokas Tamosevicius, Oana Jurca, Daniel Tamburino, Lasaro Camargos, Marija Stamenkovic, Patrik Stuedi, Philipp Rostalski, 1

2 The Flux Daniel Tamburrino / EPFL Goal: Create a big image database How to: part of an exhibition in a museum, people upload their pictures and they are projected in the museum Results: pictures with tags andkeywords available for research use 2

3 Metadata Imputation on sensor data Adriana Budura, Philippe Cudré-Mauroux, Karl Aberer/ EPFL - I&C - LSIR Goals: Improve search and semantic interpretation of annotated sensor data by automatic generation of metadata Employ both semantic information (existing annotations) and content-based information (extracted features) in the metadata generation process Sensor annotation: <description>a sensor presenting the nodes inside the sensor scope</description> <life-cycle pool-size="10" /> <addressing> <predicate key="latitude"> </predicate> <predicate key="longitude">6.5676</predicate> </addressing> <storage history-size="1m" />.. Opportunity: Similar Resources share Similar Metadata Nearest Neighbor Imputation - missing values are propagated among similar records 3

4 Publish Subscribe Systems for Sensor Data Oana Jurca, Ali Salehi, Karl Aberer - EPFL Pub/sub enhanced GSN Allow users to subscribe to sensor data in eventlike fashion independent on which (different) sensor network created the data The pub/sub layer deals with anonymous many-tomany communication and applies Ouksel filters to reduce subscriptions, while GSN directs the queries to the actual data sources Creating composite virtual sensors Light Temperature s 1 - [10, 50] s 2 [500, 1500] - s 3 [500, 1100] [15, 30] s 4 [900, 1500] [25, 50] s 5 [700, 1200] [20, 45] In general, each subscription generates (defines) a corresponding virtual sensor (VS) in GSN VS can be composed, in order to provide filtered information to the new filters and to correlate data from different sensor networks The VS composition reflects subscription subsumption 4

5 Keyword Search in Application Data Cristian Duda, Donald Kossmann, ETH Zürich Goal: Provide a generic search engine over (any) application data Idea: Teach the application logic to the search engine, at the data level Applications: Cross-Application Search Searching Versioned data Indexing AJAX (Web 2.0) 5

6 Windows for XQuery (1/2) Irina Carabus, Peter M. Fischer, Daniela Florescu*, Donald Kossmann, Tim Kraska, Rokas Tamosevicius ETH Zurich, Department of Computer Science, *Oracle, USA Motivation XML has had a breakthrough success as a data format for different kinds of data (WebServices, RSS, Meta Data, MS Office 2007, XHTML, ) XQuery is the most promising programming language to deal with XML data Many XML application work on a (possible infinite) sequence of items XQuery 1.0 lacks support for window/continues queries Contributions Window Queries: FORSEQ clause in order to define and process complex windows using XQuery Continuous Queries: A simple extension to the XQuery data model in order to process infinite data streams and use XQuery for continuous queries Use Cases, Implementation Design, Linear Road Benchmark BNF: FFLOWERExpr ::= (Forseq For Let)+ Where? OrderBy? RETURN Expr Example (average temperature per day): forseq $w in $sensors tumbling window start curitem $f when $f/time eq 7am end when newstart return <avgtemp> { fn:avg($w/temp)} </avgtemp> 6

7 Windows for XQuery (2/2) Irina Carabus, Peter M. Fischer, Daniela Florescu*, Donald Kossmann, Tim Kraska, Rokas Tamosevicius ETH Zurich, Department of Computer Science, *Oracle, USA Implementation/Evaluation Extension implemented into an existing Java-based open-source XQuery engine named MXQuery Implementation evaluated using the Linear Road Benchmark; 1.5 expressways throughput achieved Future Work Standardization by the W3C in the emerging XQuery 1.1 XQueryP and streaming Integration into XTream... I N P U T Linear Road Benchmark Implementation Car positions Segment Statistics for every minute Accident Segments Car Position Car positions to Respond Historical Queries Part Toll Calculation Historical Tolls Accidents Segment Tolls Accident Events Toll Events Balance Query Balance Daily Expenditure Query Result Output Result Output Result Output Result Output More details you can find here: Irina Carabus, Peter M. Fischer, Daniela Florescu, Donald Kossmann, Tim Kraska, Rokas Tamosevicius: Extending XQuery with Window Functions, VLDB

8 R-OSGi: Distributed OSGi Services (1/2) Jan S. Rellermeyer, Gustavo Alonso, Timothy Roscoe ETH Zurich, Department of Computer Science OSGi: Modularity for Java Applications Traditional Java: - Packages - Only a namespace concept - The mystical classpath - Modules = JAR files in the cp - No control over the dependencies - Static configuration - Extensibility? - Versioning? - Dependency Handling? OSGi: - Bundles - JAR files with explicit dependencies - Can be loaded/unloaded/updated at runtime - Services - Decouple bundles - Link against the service interface, not the implementation - The OSGi framework has a central service registry Bundle B Bundle A Concierge is our OSGi R3 implementation for resource-constrained devices. 8

9 R-OSGi: Distributed OSGi Services (2/2) Jan S. Rellermeyer, Gustavo Alonso, Timothy Roscoe ETH Zurich, Department of Computer Science R-OSGi: Transparent Service Proxies Goal - Allow remote peers to access OSGi services - Without changing the OSGi Framework - Without changing the services - Allow peers to discover new services - Spontaneous interaction - Controlling new devices R-OSGi: - Service Discovery - RFC 2608: SLP - Transmit only the interface - Service = implementation is hidden Bundle A Method 1 Method 2 Method 3 Method 4 Service I Service II R-OSGi R-OSGi Proxy I Method 1 Method 2 Method 3 Service I - Generate a proxy on the client - Bytecode engineering OSGi Framework OSGi Framework - The Proxy behaves exactly like the original service - R-OSGi syncs the states, etc. 9

10 XTream: Exploring Applications on Data Streams M. Duller, R. Tamosevicius, G. Alonso, D. Kossmann / ETH Zurich Design and implementation of a platform for building complex and distributed applications over data streams. Apps: Personal Data Streams (Skyp , Smart Home) and Linear Road Benchmark Processing Model similar to Ptolemy, Aurora, or Telegraph Slets, α-/ω-slets, and channels Prototype in OSGi Source α Slet ω Slet Sink Source α Slet ω Sink 10

Query Processing in WSNs Platform: SwissQM +

Processing SwissGate System Stream Processing QM

11 Query Processing in WSNs Platform: SwissQM + Gateway René Müller, Gustavo Alonso, Donald Kossmann ETH Zurich, Department of Computer Science Query 2 Query 1 Query 3 Gateway Query Processing SwissGate System Stream Processing QM Prog 1 QM Prog 2 Virtual Machine executing Bytecode Programs Sensor Network 11

12 Making Applications Persistent at Run-time Angela Nicoara, Gustavo Alonso / ETH Zurich, Department of Computer Science, Switzerland Architecture for object persistence Orthogonal Persistence - implemented as: Language extensions (e.g., PJama) A development time property (e.g., ORMs) A deployment time property (e.g., container) A compile time property Application O 1 O 2 O k initial state (1) object state modification events ev 1 ev 2 ev k (2) (3) Object Relational Mappers (ORMs) Oracle TopLink Oracle TopLink ORM ORM Hibernate ORM Hibernate ORM Cayenne ORM Cayenne ORM jdbc (4) Database Table A Table B Dynamic Persistence: A Java-based dynamic AOP infrastructure where persistence functionality can be dynamically added or removed from running applications Persistence as a run-time property Making applications independent of the container Persistence behavior can be added to existing apps without requiring to modify their original code Applications can be made persistent at run-time without having to stop or redeploy the code Adapting running applications with persistence functionality Application TestClass1 m k TestClass2 m q Service X (1) ' (2) m x m x (1) Method execution joinpoint 12 Field modification joinpoint Intercept fields state changes (3) Intercept set / get methods executions Persistence Extensions Persistence Persistence Field Field Extension Extension Persistence Persistence Method Method Extension Extension (4) Object Relational Mappers (ORMs) Oracle TopLink Oracle TopLink ORM ORM Hibernate ORM Hibernate ORM Cayenne ORM Cayenne ORM jdbc (5) Database Table A Table B

13 Exploit piggybacking to build Distributed Services P. Stuedi, G. Alonso / ETH Zurich AdHocSpace: Distributed Tuple Space based on routing packet piggybacking Allows to build services such as SIP, DNS, SLP Distributed SIP support Multihop Wireless VoIP 13

Judgment negotiation Prediction Markets Solutions Reduced to BUY/SELL, contributed by everybody Implicit in

14 Prediction Market for R&D Portfolio Management C. Gaspoz / UNIL HEC Lausanne R&D Portfolio Problems Data collection and actualisation Comparison criterion selection Judgment negotiation Prediction Markets Solutions Reduced to BUY/SELL, contributed by everybody Implicit in BUY/SELL, aggregated in the price Automatic market making betwen buyers/sellers Design Propositions Interface design Group sessions Claim description IPO process Automatic Market maker 14

Systems Key Elements: - One main exhaust at ceiling level (driving the flow) - Several smaller distributed exhausts - Distributed CO 2 sensors -

15 Energy efficient ventilation (1/2) Philipp Rostalski 1, Manfred Morari 1, Andrew W. Woods 2 1 Automatic Control Laboratory, ETH Zurich, Switzerland 2 BP Institute, University Cambridge, UK Analysis and Distributed Control of HVAC Systems Key Elements: - One main exhaust at ceiling level (driving the flow) - Several smaller distributed exhausts - Distributed CO 2 sensors - Distributed temperature sensors - Contaminant handling - Dynamic control - Disturbance rejection Controlled exhaust based on CO2 sensors Interface between polluted air and fresh air Supply plenum with diffusers Adjustable local inlets 15

Energy efficient ventilation (2/2) Philipp Rostalski 1, Manfred Morari 1, Andrew

Institute, University Cambridge, UK Understanding the Fluid Mechanic Current

Identification of Relevant Dynamics - Analyzing the effect of Sensor and

verification Actuator too low polluted layer exhaust interface CO 2 source laser

exhaust CO 2 source laser printer A collaboration between: exhaust interfaces

16 Energy efficient ventilation (2/2) Philipp Rostalski 1, Manfred Morari 1, Andrew W. Woods 2 1 Automatic Control Laboratory, ETH Zurich, Switzerland 2 BP Institute, University Cambridge, UK Understanding the Fluid Mechanic Current Research: Small-scale experiments - Fluid-dynamical Modeling of Flows - Identification of Relevant Dynamics - Analyzing the effect of Sensor and Actuator positioning - Design of Distributed Control Scheme - Experimental verification Actuator too low polluted layer exhaust interface CO 2 source laser printer Optimal exhaust of CO 2 Actuator too high polluted layer interface exhaust CO 2 source laser printer A collaboration between: exhaust interfaces Automatic Control Laboratory ETH Zürich polluted layer CO 2 source laser printer BP Institute University of Cambridge 16

17 Local-Knowledge Algorithms for Structured Message Diffusion in Unreliable Environments M. Allani, B. Garbinato, F. Pedone, R. Schmidt, M. Stamenković We consider large-scale wired systems with partially known topologies and restrict the knowledge of each peer to that of its close neighborhood. In this case we can only ensure the reliability probabilistically,and try to achieve the highest probability possible with a limited amount of messages/bandwidth. First, nodes learn the desired part of the system's topology and asses reliability properties. Further on, some system nodes build an overlay structure in order to disseminate messages. The frequency which defines how often the overlay is being constructed differentiates our two local-knowledge algorithms (LKAs), namely Lazy and Eager LKA. Which of these two approaches to chose is clearly a matter of tradeoff between accuracy and computation. 17

Fast Multi-coordinated Atomic Multicast Lasaro Camargos, Rodrigo Schmidt, Fernando Pedone, Edmundo Madeira Motivation Corporate P2P / Grids Strong consistency operations Any kind of consistent state

18 Fast Multi-coordinated Atomic Multicast Lasaro Camargos, Rodrigo Schmidt, Fernando Pedone, Edmundo Madeira Motivation Corporate P2P / Grids Strong consistency operations Any kind of consistent state change Standard approach Not fast for every node Not as resilient as possible Collision-Fast Protocol -- Faster Multi-coordinated Protocol -- More resilient Fast Multi-coordinated -- The best from both 18

19 Using Context Information for Image Classification (1/2) Achanta Radhakrishna / EPFL Segment Image Extract features of color, texture etc. Classify segments using decision tree training Add Exif information Classify whole images using decision tree training (The image on next slide explains this process) 19

20 Using Context Information for Image Classification (2/2) Achanta Radhakrishna / EPFL 20

Extending XQuery with Window Functions

Extending XQuery with Window Functions Irina Botan, Peter M. Fischer, Dana Florescu*, Donald Kossmann, Tim Kraska, Rokas Tamosevicius ETH Zurich, Oracle* Elevator Pitch Version of this Talk XQuery can