Project Design

Alain Esteva-Ramirez

School of Computing and

Information Sciences

Florida International University

Bárbara Morales-Quiñones

Department of Computer

Engineering

University of Puerto Rico-Mayaguez

07/17/2007

REU Summer Program

2

Outline

Recap of Previous Phase Introduction

What are we doing now?

How the system will work

Request Scheduling

Diagrams

Algorithm outline

Goals

Questions?

3

Recap

Safe Adaptation with Validation Strategy to Testing AC Systems at RuntimePerformed background on safe adaptation (Zhang)

Focused on how to test self-optimization changes

Surveyed tools to support testing adaptive AC systems

Tools SurveyLooked at <number> of automated toolsDependency Analysis: JDepend and CapPerformance Metrics: TPTP Unit Testing Support: Cobertura and JUnitPerf

Where we left off last time…

4

Introduction

ProblemDesign an adaptable autonomic container.Incorporate self-optimization capabilityApply container in the context of a real problemIntegrate tools to support validation of self-

optimization

SolutionAutonomic Request Scheduling Container

What are we doing now?

How the system will work

Recall Stevens and Parsons autonomic stack of random numbers (REU 2006) Stack self-configured by increasing size

Container will now hold user requests that need to be serviced.

Agents dequeue requests according to some high-level scheduling algorithm, and service them.

Self-optimization changes strategy in attempt to prevent starvation

Autonomic Request Scheduling

6

How the system will work

First come, first serve (FCFS) Decision mode: non-preemptive Comments: A potential problem is when a

short request follows a long one. Shortest Request Next (SRN)

Decision mode: non-preemptive Comments: SRN is better than FCFS for short

request, but long request may have to wait for some time for service. To avoid this problem, a request's time limit can be used.

Request Scheduling Strategies

7

Design Constraints

Need a flexible design to facilitate seamless integration of new components E.g. New scheduling strategies

High-level design of autonomic system must conform with standard architecture of autonomic computing (IBM ‘06]

Self-testing framework must conform with safe adaptation with validation strategy (King et al.)

Reuse as much as possible, Patterns

8

High Level Architecture

<<subsystem>>requestContainer

<<subsystem>>requestAgents

<<subsystem>>rcSelfConfig

<<subsystem>>raSelfOptim

ManagedResources

TouchpointAMs

<<subsystem>>oamScheduler

OrchestratingAMs

<<subsystem>>rcSelfTest

<<subsystem>>raSelfTest

<<subsystem>>otmScheduler

Autonomic Computing System Self-Testing Framework

Knowledge Sources

(Repository and Registry)

TouchpointTMs

OrchestratingTMs

<<subsystem>>ksScheduler

9

Generic Manager Design

10

Minimal Class Diagram

TAMSelfOptim[from raSelfOptim]

KnowledgeCoordinator[from ACSTF.manager]

KSFacade[from ksScheduler]

TAMSelfConfig[from rcSelfConfig]

TTMSelfTest[from raSelfTest]

OAMReqSched[from oamScheduler]

Request[from requestContainer]

RequestContainer[from requestContainer]

Agent[from requestAgents]

AgentPool[from requestAgents]

RCTouchData[from requestContainer]

RATouchData[from requestAgents]

SchedStrategy[from requestAgents]

OTMSelfTest[from raSelfTest]

11

Selected Design Patterns

Façade (Interface pattern) Provides an interface that makes a

subsystem easy to use

Strategy (Operation pattern) Encapsulates alternate strategies in separate

classes

Observer (Responsibility pattern) Define a dependency between objects When one changes state, dependents are

notified and updated automatically

12

Algorithm OutlineStrategy swap : FCFS to SRN

Precondition: Three agents and approximately 15 requests FCFS is the current strategy. Agent3 is at finished, the others are working on heavy requests.

Steps: The Monitor of the TAMSelfOptim through RATouchData knows

that the AgentPool has the third agent free. (1) The Monitor of the TAMSelfConfig through RCTouchData knows

that the next request in the RequestContainer is heavy.(2) Both managers store that information in the Knowledge Source

through the KSFacade. The OAMReqSched analyses that information (1 and 2), thus

changes the strategy in the SchedStratey to SRN. Then the OAMReqShed notifies the TAMSelfOptim through the

KSFacade that the third agent should be set to ready.

13

Activity Diagram

1. TAMSelfOptim detects that the Agent Pool has a free agent.

2. TAMSelfConfig detects that the next request in the Request Container is heavy.

3. Both managers write this state information to the Knowledge Source (KS).

4. OAMReqSched analyzes information from KS and detects that more than 60% of other agents are working on heavy requests.

5. OAMReqSched requests to swap strategy to SRN.

6. OAMReqSched notifies that a free agent is now ready.

14

Activity Diagram

Agent finished processing request TAMSelfOptim's Monitor get state of AgentPool TAMSelfConfig's Monitor get state of RequestContainer

This info is stored in Knowledge Source

OAMReqSched changes strategy from FCFS to SRN

OAMReqShed notifies TAMSelfOptim that the agent should be ready

Set agent state to ready

[ Agent Free ] [ Next Request ]

[ otherwise ]

[ Next request is heavy and more than 60% of agents are working with heavy requests ]

Strategy swap : FCFS to SRN

15

Goals

Have a solid adaptive framework Test it during safe ad Write a technical paper Write a student paper

16

Questions?

Questions, comments and queries.