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

Ohio State University 2 Context: Cyberinfrastructure for Coastal Forecasting and Change Analysis: Gagan Agrawal (PI) Hakan Ferhatosmanoglu Ron Li Keith Bedford

Ohio State University 3 Coastal Forecasting and Change Detection (Lake Erie)

Ohio State University 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 4

Ohio State University 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 5

Ohio State University 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

Ohio State University 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 Great Lakes Forecasting System Low water due to negative storm surge on eastern end of Lake Erie - Oct. 25, 2001

Ohio State University 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 8

Ohio State University 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 ? 9

Ohio State University 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) 10

Ohio State University 11 Middleware Design

Ohio State University 12 Autonomic Adaptation Algorithm ICAC 2008 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

Ohio State University Control Model VariableDescription x(k)Adjustable service parameters u(k)Increase/Decrease to parameters w(k)Estimated overall response time System Model Definitions ICAC 2008

Ohio State University 14 System Model ICAC 2008 State Equation Performance Measure time constraint benefit adaptation overhead Constraints

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

Ohio State University 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

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

Ohio State University 18 Image Size ICAC 2008

Ohio State University Overhead of the Adaptation Algorithm 9% 11% 12%

Ohio State University 20 Overhead of the Adaptation Algorithm (Learning Phase) ICAC 2008 Normal Execution (Min) Number of Adapted Parameters (Min) The overhead of the adaptation algorithm for tuning 1,2 and 3 parameters is 2.2%, 3.0% and 4.8%.

Ohio State University 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) 21

Ohio State University 22 Motivation Again: Coastal Forecasting and Change Detection (Lake Erie)

Ohio State University 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 23

Ohio State University More Globally Data-intensive sciences Scientific data repositories Web services / Service-oriented software Metadata standards –Within domains / countries 24

Ohio State University 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 25

Ohio State University 26 Summary of Desiderata US EU AU... 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 And do this with the least amount of work required from me!

Ohio State University 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

Ohio State University 28 System Overview

Ohio State University 29 In the Semantics Layer Applying Domain Information 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

Ohio State University 30 Data Registration Service Indexing Data Sets Handling heterogeneous metadata For instance, just within the geospatial domain, CountryMetadata Standards USCSDGM AU, NZANZLIC EU??? CDN???...

Ohio State University 31 Data Registration Service Handling Heterogenuous Metadata

Ohio State University 32 Supporting High Level Queries Entire system is domain-concept-driven So, we should decompose queries into concepts first

Ohio State University 33 Supporting High Level Queries

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

Ohio State University 35 The Planning Layer Service Composition: An Example

Ohio State University 36 The Planning Layer Service Composition: An Example A subset of the ontology (unrolled)

Ohio State University 37 Planning Times

Ohio State University 38 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

Ohio State University 39 The AUSPICE System AUSPICE: Automatic Service Planning and Execution in Cloud/Grid Environments

Ohio State University 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 !! 40