utep computer science colloquium, august 16, 2005 transparent autonomization: a practical approach...

UTEP Computer Science Colloquium, August 16, 2005

Transparent Autonomization:Transparent Autonomization:A Practical Approach to Autonomic A Practical Approach to Autonomic

ComputingComputing

S. Masoud Sadjadi

Autonomic Computing Research Laboratory (ACRL)School of Computing and Information Sciences

Florida International University

Email: [email protected]: http://www.cs.fiu.edu/~sadjadi/

Aug. 16, 2005 2UTEP Computer Science Colloquium

FIUACRL AgendaAgenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions

OvervieOverview:w:Motivation

Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Increase in Software ComplexityIncrease in Software Complexity

The ever increasing complexity of computing systems has been accompanied by an increase in the complexity of their management.

Contributing factors – Increasing heterogeneity of software and hardware

components.– Dramatic growth of the size of individual networks and

the Internet.– The deployment of new networking technologies.– The emergence of pervasive computing.– A2A and B2B Integration.

We focus on management that requiresdynamic adaptation.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Demand for Pervasive Computing – Promises anywhere, anytime access to data and computing.

Examples

Need for dynamic adaptation– Heterogeneity of hardware, network, software

– Dynamics of the environmental conditions

– Limited resources (CPU, memory, battery, etc.)

Why Dynamic Adaptation?Why Dynamic Adaptation?

Wearable Computing Military Applications


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Demand for Critical Systems– Must continue to operate correctly during exceptional

situations. Examples:

Why Dynamic Adaptation?Why Dynamic Adaptation?

Need for dynamic adaptation– hardware component failures

– network outages

– software faults

– security attacks


Overview

Realizations

Case Study

Related Work

Conclusions

Financial Networks Water/Power Systems


FIUACRL

Solution using Autonomic Solution using Autonomic ComputingComputing

Observation:– Processor time is becoming virtually free.– Human time/effort is becoming more expensive.

Autonomic Computing:– Initiated by IBM and originated in the human autonomic

nervous system, autonomic computing promises self-managed and long-running systems that require only limited, high-level human guidance.

Approach:– Embed management of complex systems inside the systems

themselves

Risk:– Entangling code for self-management with the code for the

business logic of the original systems

Management complexity may actually increase!


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Observation 1Observation 1

Autonomic behavior is concerned only with their non-functional requirements.

Definition– Functional requirements describe the interaction between

the system and its actors (e.g., end users and other external systems) independent of its implementation.

– Non-functional requirements describe aspects of the system that are not directly related to the functional requirements of the system (e.g., QoS, security, scalability, performance, fault-tolerance, and self-*).

Assumption– Software systems are composed of functional and non-

functional code, corresponding to the functional and non-functional requirements of the system, respectively.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Observation 2Observation 2

Non-functional code tends to crosscut the functional code.– It is impossible to localize non-functional aspects

(e.g., security) into functions or objects using procedural or object-oriented languages.

– Therefore, non-functional code is typically tangled into functional code.

– Therefore modification (maintenance/offline) and adaptation (run time/online) of non-functional code requires modification of functional code, which is error-prone and hard to accomplish.

How to solved this problem:– Separation of concerns both offline and online!


Overview

Realizations

Case Study

Related Work

Conclusions



Motivation

Overview

Realizations

Case Study

Related work

Conclusions


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL RAPIDware ProjectRAPIDware Project

Funded by U.S Office of Naval Research– Adaptable Software / Critical Infrastructure Protection

Program Software adaptation technologies for:

– Detecting and responding to environmental changes

– Strengthening self-auditing capabilities of “always-on” systems

Focus: High-assurance adaptive middleware– Rigorous software engineering, code generation, etc

– Military command and control, crisis management systems Enable systems to operate through failures and attacks

Key Question: How to support run-time adaptive behavior not envisioned during original development?


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Transparent AutonomizationTransparent Autonomization

Evolved from Transparent Shaping, which was developed in RAPIDware project.

Definitions: – Transparent Autonomization

provides a new software development methodology that supports autonomic behavior in new, as well as in existing, software systems without the need to modify the code for the business logic of the systems.

– Autonomic Program is a program that can automatically respond to unexpected

changes at run time.

– Adaptable Autonomic Program is one whose autonomic behavior can be changed

(adapted) dynamically (at run time).

– Adapt-Ready Program is one that initially behaves similar to the original program,

but can accommodate new autonomic behavior at run time as need arises.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL ChallengesChallenges

New programs (developing from scratch)– Autonomic code is scattered over functional code.

Code for self-healing, self-optimization, self-protection, and self-configuration tend to crosscut functional code.

– Unanticipated and transient adaptations. Not all events/exceptions at run time are expected. Limited resources such as memory.

Enhancing existing programs– Source code may not be available.

Legacy code

– It may not be desirable to modify the source code. New bugs may be introduced over time.


Overview

Realizations

Case Study

Related Work

Conclusions

We use transparent autonomization to weave self-management code into existing applications.


FIUACRL Key Concepts and TechnologiesKey Concepts and Technologies

Aspect-Oriented Programming

Behavioral Reflection

Component-Based Programming

Transparent AutonomizationTransparent Autonomization

Adaptive Middleware Technologies

Program Families andProduct Lines


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Aspect-Oriented ProgrammingAspect-Oriented Programming

AOP Supports– Separation of concerns

at development and maintenance time.

Problem– Tangled Code at run time.

– Dynamic reconfiguration need separated concerns at run time.

Business LogicTangled Code

Woven Code

Run Run TimeTime

Aspect Weaver

Compile Compile TimeTime

AspectsBusiness Logic

Dev. Dev. TimeTime

“We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement.” [Kiczales97]


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Base Level

1

Message flow Intercepted Message flow

Base-Level Objects Sender ObjectReceiver Object

Behavioral ReflectionBehavioral Reflection

Meta LevelGeneric MOP

Dynam

ic MOPs

Meta-Level Objects

Metaobjects

2”

1’2’3”

Separation of concerns at run time Base Level: Application objects are represented. Meta Level: Metaobjects are categorized into MetaObject Protocols Interception: Base-level messages are intercepted

“Computational reflection is the activity performed by a computational system when doing computation about (and by that possibly affecting) its own computation.” [Maes87]


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Component-Based DesignComponent-Based Design

Compile-time composition

Run-time recomposition– Adapt-ready

programs– Late binding

“Components are units of independent deployment, third-party composition, which have no (externally) observable states.” [Szyperski99]

Compile Time

Compile Time

……

Run Time


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL MiddlewareMiddleware

Middleware lies between application and OS– Traditionally hides distribution (CORBA, Java/RMI, .NET)

– Can make many other issues transparent to application

APPLICATION LAYER

Application

Host computer(wired workstation)

Application

Host computer(wireless laptop)

Application

Host computer(wireless palmtop)

Message & data paths

MIDDLEWARE LAYER

NETWORK LAYER

“… applications should be able to inspect internal components and also adapt the system at run time to meet current application needs.” [Blair97]

APPLICATION LAYER

Application

Host computer(wired workstation)

Application

Host computer(wireless laptop)

Application

Host computer(wireless palmtop)

Message & data paths

MIDDLEWARE LAYER

NETWORK LAYER

observersresponders

Proxy node(e.g., desktop)

“core” middlewarecomponents


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Families of Autonomic ProgramsFamilies of Autonomic Programs

Observation– Autonomic programs derived from an existing

program share the functional code of the program.– They differ only in their autonomic code.

Approach– Instead of developing each autonomic program

individually, transparent autonomization provides a model to produce a family of autonomic programs derived from an existing program.

Definition– A program family is a set of programs whose

extensive commonalities justify the expensive effort required to study them as a whole rather than individually [Parnas76].


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Steps in Transparent Steps in Transparent AutonomizationAutonomization

X4X3

X8

Second Step:at run time

X5 X7X6

X9S1 S2

X1

(managed program)

First Step:at compile, startup, or load time

X2

(managed program)

X0

(existing program)

Xautonomic program reversible design decisiondesign decision subfamily boundary

Two Steps1. An adapt-ready program or a managed element is

produced statically: The existing program with generic interceptors, called

hooks, at certain points in its execution path.

2. Adaptable Autonomic programs are generated dynamically: Using the hooks, a composer can insert or remove new

autonomic code into the adapt-ready program.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Overview of the approachOverview of the approach

Program Address Space Run T

ime

Run T

imeManaged Element

Autonomic Manager

Com

pile/Startup Tim

eC

ompile/Startup T

ime

Original application

Transformation ProcessTransformation Process

Generated managed program

A configuration file


Overview

Realizations

Case Study

Related Work

Conclusions



Motivation

Overview

Realizations

Case Study

Related work

Conclusions


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Transparent Autonomization Transparent Autonomization RealizationsRealizations

We target distributed applications.

Depending on where the hooks are incorporated, we identify three approaches to transparent shaping.1. inside an application program itself

2. inside its supporting middleware

3. inside the system platform.

Client Program Server Program

ApplicationLayer

MiddlewareLayer

Program component Flow of service request Hook

process boundaries

NetworkNetwork

Requester Component

ProviderComponent

OperatingSystem

Interaction

A typical client/server application.

We target distributed applications.

Depending on where the hooks are incorporated, we identify three approaches to transparent shaping.1. inside an application program itself

2. inside its supporting middleware

3. inside the system platform.

TRAP

ACT


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Middleware-Based ApproachMiddleware-Based Approach

Motivation– We focus on adapting distributed systems.– Incorporating adaptive code inside middleware

produces transparency to the application code.– Most middleware have embedded interception

techniques.

Approach [ICDCS’04,ICAC’04]– We use CORBA portable interceptors– A generic interceptor is incorporated into a CORBA

program at startup time (adapt-ready)– Later at run time, the generic interceptor can be used

to insert adaptive code into the adapt-ready program (adaptable programs)


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

ACT: Middleware-Based Realization ACT: Middleware-Based Realization of TSof TS

Com

pile Tim

eC

ompile T

ime

Startup Tim

eStartup T

ime

armstrong:~> java Host.class Host.class.config OriginalApplication.class AutonomicManger.cla ss

No need for any transformation in the original CORBA program (the hook is inside ORB).

Program Address Space

Autonomic Manager

Managed Element

Run T

ime

Run T

ime


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL


ApplicationLayer

MiddlewareLayer

OperatingSystem

Server Program

process boundaries

NetworkNetwork

Client ORB

Requester object

Server ORB

Provider object

Request flowRequest flowProgram component Hook

Generic Interceptor

Generic Interceptor

ACT Architecture OverviewACT Architecture Overview

The flow of a request/reply in an ACT-ready application.


ApplicationLayer

MiddlewareLayer

OperatingSystem

Server Program

process boundaries

NetworkNetwork

Client ORB

Autonomic Manager

Requester object

Generic Interceptor

Server ORB

Autonomic Manager

Provider object

Generic Interceptor

Request flowRequest flowProgram component Hook


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Case Study: Image Retrieval Case Study: Image Retrieval ApplicationApplication

Image Client Image Server

ApplicationLayer

MiddlewareLayer

Program object Flow of service request Hook

process boundaries

NetworkNetwork OperatingSystem

Interaction

Generic Interceptor

readSmall

GetStatus

RemoveInterceptor

InsertInterceptor

CORBAORB

read

stub

generic interceptor

dynamic interceptor

send_request

AP-1: 11 Mbps, Dept. subnet

AP-2: 2 Mbps, Dept. subnet

AP-3: 11 Mbps, College subnet

A B

C

D

Image ServerImage Client

pipeline

rule

Rule-Based Interceptor


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Evaluation of Self-Optimization Evaluation of Self-Optimization

Automatic maintenance of frame-rate in an image retrieval application using ACT transparently

Frame Rate Using Automatic Adaptation

0

0.5

1

1.5

2

2.5

3

3.5

4

0 60 120 180 240 300 360 420 480 540

Time in seconds

Fra

me R

ate

11Mbps 2Mbps 11Mbps


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL ACT SummaryACT Summary

ACT is a middleware-base approach to transparent autonomization.

ACT implements interception and redirection inside the supporting middleware.

ACT enables interoperation among otherwise incompatible adaptive middleware frameworks.

ACT/J is a prototype of ACT in Java.

The overhead introduced by ACT/J is negligible, while the adaptation provided is highly flexible.

Reusable assets– Generic interceptors as hooks– Rule-based interceptors and rules as adaptive code


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Language-Based ApproachLanguage-Based Approach

Motivation– Not all distributed systems use middleware.– Not all middleware provide facilities for interception.– Lack of behavioral reflection in many OO languages.– Need for direct modifications to source code.– Direct modification is difficult and error-prone

Approach [ICAC’05,DOA’04]– Using a compile- or load-time program

transformation technique compile-time aspect weaving (e.g., AspectJ) compile-time meta-object protocols (e.g., Open C++) load-time meta-object protocols (e.g., JOIE)


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

TRAP: Language-Based Realization TRAP: Language-Based Realization of TSof TS

Reflective Class Generator

Original application

Aspect Compiler

Intercepting Aspect Generator

A configuration file

AspectAspectIntercepting

Aspects

TRAP at compile timeTRAP at compile time

Generated managed application

AspectAspectWrapper-Level

Classes AspectAspectMeta-Level

Classes

Com

pile Tim

eC

ompile T

ime

Program Address Space

Autonomic Manager

Managed Element

Run T

ime

Run T

ime


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL TRAP/JTRAP/J

Existing program

Selecting classes

Generating hooks

Weaving hooks

A configuration file (contains a list of classes to become reflective)

Original Application(.class files)

AspectJ Compiler (ajc)

Generated adapt-ready application (.class files)

Data Flow A File A Process TRAP/J Boundary

MetaLevelClass

BaseLevelClassAspect

MetaLevelClass

BaseLevelClassAspect

Wrapper-Level Class

Meta-Level Class

Intercepting Aspects

Intercepting Aspect Generator Reflective Class Generator

TRAP/J at Compile Time


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Sender

Receiver

Receiver

ReceiverAd-Hoc Wireless Network

Audio Stream Path

close

pipeline

filter

MetaSocket ASA Sender ASA Receiver

ApplicationLayer

MiddlewareLayer

Program object Flow of service request Hook

process boundaries

Ad HocAd HocNetworkNetwork

OperatingSystem

Interaction

GetStatus

RemoveDelegate

InsertDelegate

Java SocketClass

send

wrapper object

meta object

delegate

WrapperLevel_Socket

InvokeMethod

Case Study: Wireless Audio Case Study: Wireless Audio StreamingStreaming


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Wireless Network

Sender

Meta-Socket

Java Socket

JVM on Windows XP

Receiver

Meta- Socket

Java Socket

JVM on Familiar Linux

Base Level

Meta Level

Java.net package

Java Virtual Machine

Audio Packet Path

FECEncoder

FECDecoder

xxxx

1 2 3 4 1 2 3 4

Packet Lostx

Loss Rate Status

0

10

20

30

40

50

60

70

80

90

100

5 65 125 185 245 305 365 425

Time to the experiment in seconds (Samples per 5 seconds)

Lo

ss

Ra

te (

%) Network Loss Rate Application Loss Rate

MetaSockets EvaluationMetaSockets Evaluation


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL TRAP.NETTRAP.NET

AspectAspect

Metaobject AssemblyGenerator

.NET Assemblies (dll, exe)

AspectDNG Compiler (AspectDNG.exe)

Generic Aspect Generator

Class Name List

AspectsAssemblies

TRAP.NETTRAP.NET

AspectAspectMetaobjectAssemblies

Adapt-Ready .NET Assemblies

Com

pile Tim

eC

ompile T

ime

Startup T

ime

Startup T

ime

C:> Host.exe Host.exe.config AdaptReadyApplication.exe AutonomicManger.exe


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL TRAP.NET – Adapt-Ready GeneratorTRAP.NET – Adapt-Ready Generator


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL TRAP.NET – Composer InterfaceTRAP.NET – Composer Interface


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL TRAP SummaryTRAP Summary

TRAP is a language-based approach to transparent Autonomization.

TRAP/J is a prototype of TRAP in Java.

TRAP/J is transparent to both the application and JVM.

Reusable assets– Pairs of wrapper and meta classes as hooks– Delegates realize non-functional code

A MetaSocket delegate can be replaced with a more appropriate one, if required.


Overview

Realizations

Case Study

Related Work

Conclusions



Motivation

Overview

Realizations

Case Study

Related work

Conclusions


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Transparent Application IntegrationTransparent Application Integration

Motivation– Using transparent Autonomization tools beyond a

single application – Supporting higher level type of adaptation, namely,

application integration

Approach– Translating the syntax and semantics of

heterogeneous applications during execution.– Using Web services as a common language to

reduce the number of translators from N2 to N.– Transparent Autonomization of applications to host

translators.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Application IntegrationApplication Integration

Constituent applications may be developed in– different programming languages

– targeted to run on different platforms

This requires conversion of data and commands between the applications.– Advent of Middleware in 1990’s mitigated this problem.

– MW hides differences among programming languages, computing platforms, and network protocols.

– Very successful in corporate wide application integration.

– Examples: Java RMI, CORBA, DCOM/.NET

Ironically, the difficulty of application integration has reappeared with the proliferation of heterogeneous

middleware technologies.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Middleware IntegrationMiddleware Integration

Problem: We need to translate the syntax and semantics of each middleware approach to other middleware approaches

Typically translation occurs at run time

Translations for N different applications involves– N * (N-1) / 2 translators

Using a common language reduces this number to N

Need for a common middleware, or middleware for middleware!


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Web Services to the Rescue!Web Services to the Rescue!

Source of Problems:– Different corporations adopted different middleware

technologies. – Middleware packets often cannot pass through

Internet firewalls.

Web services – Well supported by academia and industry.– Can be used atop the popular HTTP protocol.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Requester Program Provider Program

ApplicationLayer

MiddlewareLayer

Program component Flow of service request A2A Interaction

process boundaries

NetworkNetwork

Requester Component

ProviderComponent

System Platform

Web Services BackgroundWeb Services Background

Service-Oriented Architecture– A provider program.

– A requester program.

– A directory service (for simplicity, not considered further). Web services

– are software programs delivered over the Internet

– can be used through a service descriptor defined in WSDL and the SOAP messaging protocol

WSDL

SOAP

WSDL

SOAP

InternetInternet


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Transparent Application IntegrationTransparent Application Integration

Web services by themselves do not provide a transparent solution to application integration.

Question: Where to host the translators?

Bridge Approach– Hosting the translators inside a bridge programs

sitting between applications in a separate process intercepting and translating the interactions

Transparent Autonomization Approach– Hosting the translators inside the existing application

(requester and provider programs) without modifying the source code directly.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Provider ProgramRequester Program

ApplicationLayer

MiddlewareLayer

System Platform

InternetInternet IntranetIntranetIntranetIntranet

?

XX

Bridge ApproachBridge Approach

Advantages: – no modification to the original programs, scalability,

maintainability. Disadvantages:

– overhead of process-to-process redirection, SPOF, bottleneck, impossible in some cases.

InternetInternet

Provider-Side Bridge Provider Program

IntranetIntranet

Requester Program

IntranetIntranet

Requester-Side Bridge

WSDL

SOAP

WSDL

SOAP

ApplicationLayer

MiddlewareLayer

System Platform


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL


ApplicationLayer

MiddlewareLayer

System Platform

InternetInternet

?

X X

WSDL

SOAP

WSDL

SOAP

InternetInternet


ApplicationLayer

MiddlewareLayer

System Platform

1

2

3

4

5

6

Transparent Autonomization Transparent Autonomization ApproachApproach

Advantages:– Resolves the problems mentioned for the bridge approach.

– Java, C++, .NET, and CORBA are supported Disadvantages:

– The appropriate tools may not be available


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Case Study: Fault-Tolerance Case Study: Fault-Tolerance Surveillance Surveillance

Transparent integration of two existing applications– An image retrieval application

Developed in CORBA by BBN Technologies. Client retrieves stored images from the server continuously. Freely available as part of the QuO framework

– A sample grabber application developed in .NET by NETMaster. Freely available from Code Project web site.

Result of integration:– Transparent Integration: CORBA client can retrieve

frames from the .NET sample grabber application.– Transparent self-healing: if one source fails, requests

are automatically and transparently forwarded to the other source.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Original ApplicationsOriginal Applications

Wired NetworkWired Network

Image Retrieval Client Application

Image Retrieval Server Application

Frame Grabber Standalone Application


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Sample GrabberServer Program

IntranetIntranet

Image RetrievalServer Program

Linux

Java

CORBA

WindowsLinux

Java

CORBA .NET

files

Program components Flow of service request A2A InteractionTranslator components

C#

camera camera

Flow of data

Image RetrievalClient Program

Original CORBAApplication

Original .NETApplication

Integrated Fault-Tolerant Integrated Fault-Tolerant ApplicationApplication

Client

InternetInternet

Server

Frame Grabber ApplicationImage Retrieval Application

InternetInternet

Sample GrabberServer Program

Image RetrievalClient Program

IntranetIntranet

Image RetrievalServer Program

WSDL

SOAP

Linux

Java

CORBA

WindowsLinux

Java

CORBAWSDL

SOAP .NET

files

Fault-TolerantComponent

Program components Flow of service request A2A InteractionTranslator components

C#

camera camera

Flow of data

1

2

Original CORBAApplication

Original .NETApplication

Transparent Transparent Application IntegrationApplication Integration


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Transparent App. Integration Transparent App. Integration SummarySummary

Transparent Autonomization provides transparent application integration– Alternative solutions using TRAP and ACT– Supports interoperation among Java RMI, CORBA,

and .NET applications through Web service.

Remaining issues– Automatic translation – Automatic service discovery


Overview

Realizations

Case Study

Related Work

Conclusions



Motivation

Overview

Realizations

Case Study

Related work

Conclusions


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL When?When?

When the adaptivr code is incorporated?

Hardwired Middleware: Electra, Totem, Horus, IsisCustomizable Middleware: Personal/Embedded Java, Orbix/EConfigurable Middleware: Eternal, IRL, FTS, TAO-LB, Rocks, Racks, Orbix, ORBacus, JacORB, QuOTunable Middleware: TAO, ZEN, CIAO, DynamicTAO, UIC, OpenCORBA, ACE, FlexiNet, Iguana/J, MetaXaMutable Middleware: Open ORB, Open COM

Middleware Type

Dynamic Middleware

Mutable

Tunable

Configurable

Customizable

Hardwired

Develop. Time Compile Time Startup Time Run Time Middleware Lifetime

Static Middleware

Transparent ShapingTransparent Shaping


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Where and How?Where and How?

Where the adaptive code resides? How the adaptive code is incorporated?

Adaptable Applications, Existing/Non-Adaptable Applications

Windows OS, Linux OS, Sun Solaris OS, Mac OS

Mid

dlew

are

Common Services

Domain-Specific Services

Application

System Platform

Host-Infrastructure Services

Distribution Services

Transparent shaping boundary

Java RMI, TAO,DynamicTAO,Orbix, JacORB, Squirrel,OpenCorba, OpenORB, Electra,…

BBS, …

QuO, OGS, …

MetaSockets, Java Net Package, ACE, Horus, Isis, Ensemble, …

Hooks to incorporate adaptive code dynamically

ACT/J, IRL,FTS,TAO-LB, …

TRAP/J, Composition Filters, RNTL ARCAD, …

KMX, Eternal, Rocks, Racks, DEOS, GRACE, Graybox, …

Iguana/J, PROSE, Guaraná, …

Tra

nsp

aren

tT

ran

spar

ent

Sh

apin

gS

hap

ing


Overview

Realizations

Case Study

Related Work

Conclusions



Motivation

Overview

Realizations

Case Study

Related work

Conclusions


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Summary of ContributionsSummary of Contributions

We demonstrated the use of adaptive middleware to support transparent autonomization of distributed applications [ICDCS'04, ICAC'04-1].

We investigated how to enhance existing application code transparently in order to support autonomic behavior [ICAC'04-2, DOA'04].

We assessed the potential role of transparent autonomization beyond the domain of a single program to support application integration.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Specific AccomplishmentsSpecific Accomplishments

A high level view of our accomplishments

ACTTRAP

Transparent Autonomization

ACT/J

Proxies: Generic Proxy

TRAP/J, TRAP/C++, TRAP.NET, TRAP/BPEL

Audio Streaming App.

Filters: FEC, Encryption/Dec., Compression/Dec.

QoS Security QoS vs. Energy Man.

Delegates: MetaSockets

Image Retrieval App.

Rules: Conn. Management,App. Integration

App. IntegrationSelf-Management/Optimization

Frame Grabber App.

instantiates provides uses is applied to supports

Generic InterceptorsWrappers & Metaobjects

Coarse-Grained ..non-functional code

Existing Applications …………………...

Crosscutting Concerns ………….……………….

Core Assets

Hooks ….…………………………………

Fine-Grained ……

Programming Model

Extensions..…………………

Prototypes ……………..…….

Model …….…………………..


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL

Supporting Other Existing Supporting Other Existing ApplicationsApplications

Expanding the set of supported existing programs.

Audio Streaming App.

ACTTRAP

Transparent Autonomization

ACT/J

Proxies: Generic Proxy

TRAP/BPEL

Filters: FEC, Encryption/Dec., Compression/Dec.

QoS Security QoS vs. Energy Man.

Delegates: MetaSockets

Image Retrieval App.

Rules: Conn. Management,App. Integration

App. IntegrationSelf-Management/Optimization

Frame Grabber App.

Generic InterceptorsWrappers & Metaobjects

Coarse-Grained ..non-functional code

Existing Applications …………………...

Crosscutting Concerns ………………………….

Core Assets

Hooks …………………………………….

Fine-Grained ……

KMX

ACT/C++ KMX/LinuxTRAP/J TRAP.NET

iptables

Transient Proxies

Video Streaming App.

instantiates provides uses is applied to supports

Programming Model

Extensions…………………..

Prototypes ……………………

Model …….…………………..


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Current ProjectsCurrent Projects

IP_Comm– Drs. Deng, Clarke, Hristidis, Rangaswami, Zhang,

and Prabakar.– Students: Onyeka Ezenwoye, Eduardo Monterio,

Adelein Rodriguez, and Weixian Sun. TRAP

– Studetns: Onyeka Ezenwoye, Lazaro Millo, Alain Rodriguez, and Ana Rodriguez.

Robust Web Services– Studetn: Onyeka Ezenwoye

Safe Adaptation– Drs. He, Cheng, McKinley, Clarke, and Ceberio.– Student: Gonzalo Argote and Farshad Samimi.

Knowledge Discovery in AC– Drs. Li and Zhang.– Student: Wei Peng.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL AcknowledgementsAcknowledgements

This work was supported in part by– U.S. Navy, Office of Naval Research

Grant No. N00014-01-1-0744

– National Science Foundation grants CCR-9912407 EIA-0000433 EIA-0130724 ITR-0313142

Thanks to my colleagues at SENS laboratory for their insightful discussions and feedbacks (in alphabetical order). – Betty Cheng, Kurt Stirewalt, Laurie Dillon– Eric Kasten, Farshad Samimi, Zhenxiao Yang, Zhinan

Zhou, Jesse Sowell, and others.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL References References (1)(1)

[Computer’04] Philip K. McKinley, S. Masoud Sadjadi, Eric P. Kasten, and Betty H. C. Cheng. Composing adaptive software. IEEE Computer, pages 56-64, July 2004.

[DOA'04] S. M. Sadjadi, P. K. McKinley, B. H.C. Cheng, and R. E. K. Stirewalt. “TRAP/J: Transparent generation of adaptable java programs,” To appear In the Proceedings of the International Symposium on Distributed Objects and Applications, Larnaca, Cyprus, October 2004.

[IWQoS'04] Z. Zhou, P. K. McKinley, and S. M. Sadjadi. On quality-of-service and energy consumption tradeoffs in fec-enabled audio streaming. In Proceedings of the 12th IEEE International Workshop on Quality of Service (IWQoS 2004), Montreal, Canada, June 2004.

[ICAC'04-1] S. M. Sadjadi, P. K. McKinley,``Transparent Self-Optimization in Existing CORBA Applications,'' To appear in Proceedings of the International Conference on Autonomic Computing (ICAC-04), New York, NY, May 2004.

[ICDCS'04] S. M. Sadjadi and P. K. McKinley. ACT: An adaptive CORBA template to support unanticipated adaptation. In Proceedings of the 24th IEEE International Conference on Distributed Computing Systems (ICDCS'04), Tokyo, Japan, March 2004. To appear.

[FTDCS'03] S. M. Sadjadi, P. K. McKinley, and E. P. Kasten. Architecture and operation of an adaptable communication substrate. In Proceedings of the Ninth IEEE International Workshop on Future Trends of Distributed Computing Systems, pages 46-55, San Juan, Puerto Rico, May 2003.

[ISWC'02] Philip K. McKinley, S. M. Sadjadi, E. P. Kasten, and R. Kalaskar. Programming language support for adaptive wearable computing. In Proceedings of International Symposium on Wearable Computers (ISWC'02), pages 205-214, Seattle, Washington, October 2002.

[ICAC'04-2] S. M. Sadjadi, P. K. McKinley, R. E. K. Stirewalt, and B. H.C. Cheng, ``Self-Optimization in Wireless Audio Streaming,'' To appear in Proceedings of the International Conference on Autonomic Computing (ICAC-04), New York, NY, May 2004.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL References References (2)(2)

[Bruegge04] Bernd Bruegge and Allen H. Dutoit. Object-oriented software engineering using UML, patterns, and Java, second edition, Prentice Hall, 2004.

[Parnas76] David L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, March 1976.

[Johnson01] Ralph Johnson. Introduction to “on the design and development of program families.” In Daniel M. Hoffman and David M. Weiss, editors, Software fundamentals: collected papers by David L. Parnas, pages 191–192. Addison-Wesley Longman Publishing Co., Inc., 2001.

[Maes87] Pattie Maes. Concepts and experiments in computational reflection. In Proceedings of the ACM Conference on Object-Oriented Languages. ACM Press, December 1987.

[Kiczales97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J. M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented Programming. Springer-Verlag LNCS 1241, June 1997.

[Szyperski99] C. Szyperski, Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1999.

[Blair97] Gordon Blair, Geoff Coulson, and Nigel Davies. Adaptive middleware for mobile multimedia applications. In Proceedings of the Eighth International Workshop on Network and Operating System Support for Digital Audio and Video, pages 259-273, 1997.

[Schmidt02] Douglas C. Schmidt. Middleware for real-time and embedded systems. Communications of the ACM, 45(6), June 2002.

[CORBA03] Object Management Group, Framingham, Massachusett. The Common Object Request Broker: Architecture and Specification Version 3.0, July 2003.

[Zinky97] John A. Zinky, David E. Bakken, and Richard E. Schantz. Architectural support for quality of service for CORBA objects. Theory and Practice of Object Systems, 3(1), 1997.

[Yang02] Z. Yang, B. H.C. Cheng, R. E. K. Stirewalt, J. Sowell, S. M. Sadjadi, and P. K. McKinley. An aspect-oriented approach to dynamic adaptation. In Proceedings of the ACM SIGSOFT Workshop On Self-healing Software (WOSS'02), November 2002.


Overview

Realizations

Case Study

Related Work

Conclusions


FIUACRL Contact InformationContact Information

Questions?

Thank you!

S. Masoud Sadjadi

Assistant Professor

University Park, ECS 212C

11200 S.W. 8th Street

Miami, FL 33199

Tel: (305)348-1835 Fax: (305)348-3549Email: [email protected]: http://www.cs.fiu.edu/~sadjadi/

For more information refer to the Autonomic Computing Research Laboratory (ACRL) web site:

URL: http://acrl.cs.fiu.edu/


Overview

Realizations

Case Study

Related Work

Conclusions

utep computer science colloquium, august 16, 2005 transparent autonomization: a practical approach...

Documents