Middleware Systems Driven by Sensing Scenarios

1. Middleware Systems Driven by Sensing Scenarios Gagan Agrawal CSE (Joint Work with Qian Zhu, David Chiu, Ron Li, Keith Bedford …. )

2. Context: Cyberinfrastructure for Coastal Forecasting and Change Analysis: 2006 - 2009 Gagan Agrawal (PI) Hakan Ferhatosmanoglu Ron Li Keith Bedford

3. Coastal Forecasting and Change Detection (Lake Erie)

4. Need for New CS Research • Adapting to Time Constraints • Standard Computing Model: Run this program • Our need: Do the best in time X • General middleware solution • Querying Low-level data • Existing solutions • Database Systems • Low-level Tools • Our need: High-level Queries on Low-level datasets

5. Other Considerations • Work in Context of Grid / Cloud / Cyberinfrastructre • Service-oriented Solutions • Dynamic Resources • General Solutions • Not specific to geospatial data or Nowcasting/Forecasting Models

6. HASTE: Autonomic Middleware • Adaptive System for Time-critical Events • Optimize a Benefit Function Within the Time Constraint • Numerous Performance-Related Parameters • Buzz-word Intensive  • For Grid and Cloud Environments • Supports Software as a Service (SaaS) • Autonomic • Self-managing • Self-optimizing

7. Motivation: Great Lakes Forecasting System • Regularly Scheduled Nowcasts /Forecasts of the Great Lakes’ physical conditions • Joint venture of OSU Civil Engineering Dept. and NOAA/GLERL • Meteorological data and consultation provided by the National Weather Service, Cleveland Office Low water due to negative storm surge on eastern end of Lake Erie - Oct. 25, 2001 Great Lakes Forecasting System

8. Specific Scenario • A significant event occurs • Accident / Storm • Local and State Authorities Need to React • Existing Models can Provide Helpful Information • Where to target the search • How will a storm impact the sewage systems • Limited time before one needs to act • Give me most in 10 / 30 minutes / 6 hours

9. Scenario (Contd). • A lot of flexibility in the application • Spatial and Temporal Granularity • How many models to run • Find most resources for the computation • Grid/ Cloud / SaaS models are helpful • Can’t tell parameter choices for the time constraint • Can a Runtime System / Middleware Help ?

10. Specifics of Functionality • Application developer specifies a QoS or Benefit function • Capture adaptable parameters • Middleware’s goal is to maximize this • Fixed resources and time • Other issues • Resource allocation for this purpose (Grid Computing) • Tradeoff between Budget and Benefit (Cloud Computing)

11. Middleware Design

12. Autonomic Adaptation Algorithm • Optimize the Benefit Function Within the Time Constraints by Adapting Service Parameters • In the Normal Processing Phase • Multiple processing rounds • For each checkpoint of parameter X in service S • Learn the Estimators of the value of X with • execution time • benefit function • Update the system model • In the Time Critical Event Handling Phase • Adjust X based on the system model • Accelerate the adaptation if violating the time deadline ICAC 2008

13. Control Model • System Model Definitions ICAC 2008

14. System Model • State Equation • Performance Measure time constraint adaptation overhead benefit • Constraints ICAC 2008

15. Policy Without Learning • It is simple and straightforward • Parameter convergence depends on the learning rate • It may incur a large adaptation overhead ICAC 2008

16. Policy with Learning • Reinforcement Learning Based • Normal Processing Phase – Explore • Q-learning • Discrete and continuous parameters • Global Pattern • Correlation between adaptable service parameters if x is continuous otherwise

17. Experimental Evaluation Goals • Demonstrate that parameters converge • meet the time constraint • Overhead of adaptation is modest • Overhead caused by learning is very small.

18. Image Size 18 ICAC 2008

19. Overhead of the Adaptation Algorithm 12% 11% 9%

20. Overhead of the Adaptation Algorithm (Learning Phase) • The overhead of the adaptation algorithm for tuning 1,2 and 3 parameters is 2.2%, 3.0% and 4.8%. 20 ICAC 2008

21. HASTE Summary • Significant new functionality • Combines control models, machine learning, and service-oriented computing • Other work on • Resource Allocation • Fault Tolerance • Budget Management (Cloud Computing)

22. Motivation Again: Coastal Forecasting and Change Detection (Lake Erie)

23. Observations • A lot of low-level data • Different modalities, formats • A number of different users / use cases • Different Programs (Services) • Computations • Format conversions • Viewing results • Choosing right dataset and workflow is hard

24. More Globally • Data-intensive sciences • Scientific data repositories • Web services / Service-oriented software • Metadata standards • Within domains / countries

25. Questions • Can we provide simple access to low-level information • Not just data, but derived results • Very simple interfaces • `Google’ to low-level datasets • Other considerations • Time vs. Quality of Service • Cache derived data results

26. Summary of Desiderata US High level query... - Keywords - Natural language Don’t just give me the data, but... - Transform it - Manipulate it - Compose it with other processes and data sets AU ... And do this with the least amount of work required from me! EU

27. System Goals • To enable queries over low level data sets, which involves: • identification of relevant data sets • automatic planning for the composition of dependent services (processes) for derivation • ... while being non-intrusive to existing schemes, i.e., • avoids a standardized format for storing data sets • accommodates heterogeneous metadata

28. System Overview

29. Domain concepts can be derived from executing a service Domain concepts can also be derived from retrieving an existing data set Service parameters represent different domain concepts In the Semantics Layer Applying Domain Information

30. Data Registration Service Indexing Data Sets • Handling heterogeneous metadata • For instance, just within the geospatial domain,

31. Data Registration Service Handling Heterogenuous Metadata

32. Supporting High Level Queries • Original Query: • “return water level from station=32125 on 10/31/2008” • The elements of our query have been parsed against the ontology

33. The Planning Layer Service Composition: An Example A subset of the ontology (unrolled)

34. Planning Times

35. AUSPICE: Summary • We came up with acronym only recently • AUtomatic Service Planning and execution In Cloud/Grid Environments  • Our system... • proposes to unify heterogeneous metadata • extracts certain metadata attributes and indexes low level data sets and services for fast access from distributed repositories • automatically composes these services and data sets to answer user queries

36. The AUSPICE System AUSPICE: Automatic Service Planning and Execution in Cloud/Grid Environments

37. Conclusions • Interesting CS research can be done driven by (sensing) applications • Apologies to NSF !! • Both systems applicable / extendable to other circumstances • Wanna write more proposals ? • We had fun !!