ohio state university middleware systems driven by sensing scenarios gagan agrawal cse (joint work...

Ohio State University

Middleware Systems Driven by Middleware Systems Driven by Sensing ScenariosSensing Scenarios

Gagan Agrawal

CSE

(Joint Work with Qian Zhu, David Chiu, Ron Li, Keith Bedford …. )

1


2

Context: Cyberinfrastructure for Context: Cyberinfrastructure for Coastal Forecasting and Change Coastal Forecasting and Change

Analysis: 2006 - 2009Analysis: 2006 - 2009Gagan Agrawal (PI)

Hakan FerhatosmanogluRon Li

Keith Bedford


3

Coastal Forecasting and Change Coastal Forecasting and Change Detection (Lake Erie)Detection (Lake Erie)


Need for New CS ResearchNeed 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


Other ConsiderationsOther 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


HASTE: Autonomic MiddlewareHASTE: 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 Motivation: Great Lakes Forecasting SystemForecasting 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


Specific ScenarioSpecific 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


Scenario (Contd). 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


Specifics of FunctionalitySpecifics 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


11

Middleware DesignMiddleware Design

Application Layer

Service Layer

OGSA Infrastructure (Globus Toolkit 4.0)

Application Deployment Service

AUTONOMIC SERVICECOMPONENTS

App.Service 1

Agent/Controller

...

...App.

Service 3

Agent/Controller

App.Service 4

Agent/Controller

App.Service 5

Agent/ControllerApp.

Service 2

Agent/Controller Autonomic Adaptation Service

SystemModel

Estimator

Application

CodeConfiguration

FileBenefit

Function

Time-CriticalEvent


12

Autonomic Adaptation Algorithm 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


Control ModelControl ModelController

Application

Variable Description

x(k) Adjustable service parameters

u(k) Increase/Decrease to parameters

w(k) Estimated overall response time

u(k)

• System Model Definitions

ICAC 2008

x(k-1)

x(k)

w(k)

w(k-1)


14

System ModelSystem Model

ICAC 2008

• State Equation

))k(x(f)k(w)k(w

)k(Bu)k(Ax)k(x

1

1

• Performance Measure

maxmin x)k(xx:C 1

time constraint

benefit adaptation

overhead

• Constraints

1

1

232

3

01 2

1

2

11

2

1 N

k

)]k(ud)))k(x(B(d[))N(ww

(dJ


15

Policy Without LearningPolicy Without Learning

ICAC 2008

• It is simple and straightforward• Parameter convergence depends on the learning rate• It may incur a large adaptation overhead

'J)k(u)k(u 1


16

Policy with LearningPolicy with Learning

• Reinforcement Learning Based• Normal Processing Phase – Explore

– Q-learning

– Discrete and continuous parameters

• Global Pattern– Correlation between adaptable service parameters

))k(u),k(x(pTableLookUmax

))k(x|)k(u(max

)k(u

)k(u if x is continuous

otherwise


17

Experimental Evaluation GoalsExperimental Evaluation Goals

• Demonstrate that parameters converge• meet the time constraint

• Overhead of adaptation is modest• Overhead caused by learning is very small.


18

Image SizeImage Size

ICAC 2008

0

64

128

192

256

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Time Step

Imag

e S

ize

With Learning

Without Learning


Overhead of the Adaptation Overhead of the Adaptation AlgorithmAlgorithm

0

5

10

15

20

25

30

35

40

45

10 20 40

Time Constaints(Min)

Exe

cutio

n T

ime

(Min

)

Adaptive Execution

Optimal Execution

9%

11%

12%


20

Overhead of the Adaptation Overhead of the Adaptation Algorithm (Learning Phase)Algorithm (Learning Phase)

ICAC 2008

Normal Execution

(Min)

Number of Adapted Parameters (Min)

481 2 3

49.06 49.52 51.48

• The overhead of the adaptation algorithm for tuning 1,2 and 3 parameters is 2.2%, 3.0% and 4.8%.


HASTE SummaryHASTE 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


22

Motivation Again: Coastal Motivation Again: Coastal Forecasting and Change Detection Forecasting and Change Detection

(Lake Erie)(Lake Erie)


ObservationsObservations

• 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


More GloballyMore Globally

• Data-intensive sciences • Scientific data repositories • Web services / Service-oriented software • Metadata standards

– Within domains / countries

24


QuestionsQuestions

• 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


26

Summary of DesiderataSummary of DesiderataUS

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!


27

System GoalsSystem 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 OverviewSystem Overview


29

In the Semantics Layer

Applying Domain InformationApplying Domain InformationDomain concepts can be derivedfrom executing a service

Domain concepts can also be derived from retrieving an

existing data setService parameters representdifferent domain concepts


30

Data Registration Service

Indexing Data SetsIndexing Data Sets• Handling heterogeneous metadata• For instance, just within the geospatial domain,

Country Metadata Standards

US CSDGM

AU, NZ ANZLIC

EU ???

CDN ???

... ...


31

Data Registration Service

Handling Heterogenuous Handling Heterogenuous MetadataMetadata


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 QueriesSupporting High Level Queries


36

The Planning Layer

Service Composition: An Service Composition: An ExampleExample

A subset of the ontology (unrolled)


37

Planning TimesPlanning Times


38

AUSPICE: SummaryAUSPICE: 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


39

The AUSPICE SystemThe AUSPICE SystemAUSPICE: Automatic Service Planning and Execution in Cloud/Grid Environments


ConclusionsConclusions

• 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

ohio state university middleware systems driven by sensing scenarios gagan agrawal cse (joint work...

Documents