Transcript Design of Secure Multi-Tier Web

Transparent Autonomization:
A Practical Approach to Autonomic Computing
S. Masoud Sadjadi
Autonomic Computing Research Laboratory (ACRL)
School of Computing and Information Sciences
Florida International University
Email: [email protected]
URL: http://www.cs.fiu.edu/~sadjadi/
UTEP Computer Science Colloquium, August 16, 2005
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
2
FIU
ACRL
Increase in Software Complexity
Overview:
Motivation

The ever increasing complexity of computing
systems has been accompanied by an increase
in the complexity of their management.

Contributing factors
Overview
Realizations
Case Study
Related Work
Conclusions
– 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 requires
dynamic adaptation.
UTEP Computer Science Colloquium
Aug. 16, 2005
3
FIU
ACRL
Overview:
Why Dynamic Adaptation?

Demand for Pervasive Computing
– Promises anywhere, anytime access to data and computing.
Motivation
Overview
Realizations

Examples
Case Study
Related Work
Wearable Computing
Military Applications
Conclusions

Need for dynamic adaptation
– Heterogeneity of hardware, network, software
– Dynamics of the environmental conditions
– Limited resources (CPU, memory, battery, etc.)
UTEP Computer Science Colloquium
Aug. 16, 2005
4
FIU
ACRL
Overview:
Why Dynamic Adaptation?

– Must continue to operate correctly during exceptional
situations.
Motivation
Overview
Realizations
Demand for Critical Systems

Examples:
Case Study
Financial Networks
Related Work
Water/Power Systems
Conclusions

Need for dynamic adaptation
–
–
–
–
hardware component failures
network outages
software faults
security attacks
UTEP Computer Science Colloquium
Aug. 16, 2005
5
FIU
ACRL
Overview:
Solution using Autonomic Computing

Observation:
– Processor time is becoming virtually free.
– Human time/effort is becoming more expensive.
Motivation
Overview
Realizations
Case Study

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.
Related Work
Conclusions

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!
UTEP Computer Science Colloquium
Aug. 16, 2005
7
FIU
ACRL
Observation 1
Overview:
Motivation

Autonomic behavior is concerned only with their nonfunctional requirements.

Definition
Overview
Realizations
Case Study
– 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-*).
Related Work
Conclusions

Assumption
– Software systems are composed of functional and nonfunctional code, corresponding to the functional and nonfunctional requirements of the system, respectively.
UTEP Computer Science Colloquium
Aug. 16, 2005
8
FIU
ACRL
Observation 2
Overview:
Motivation

Overview
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.
Realizations
Case Study
Related Work
Conclusions

How to solved this problem:
– Separation of concerns both offline and online!
UTEP Computer Science Colloquium
Aug. 16, 2005
9
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
10
FIU
ACRL
RAPIDware Project
Overview:
Motivation

– Adaptable Software / Critical Infrastructure Protection
Program
Overview
Realizations
Case Study
Funded by U.S Office of Naval Research

Software adaptation technologies for:
– Detecting and responding to environmental changes
– Strengthening self-auditing capabilities of “always-on”
systems
Related Work
Conclusions

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?
UTEP Computer Science Colloquium
Aug. 16, 2005
11
FIU
ACRL
Overview:
Transparent Autonomization

Evolved from Transparent Shaping, which was
developed in RAPIDware project.

Definitions:
Motivation
Overview
Realizations
Case Study
Related Work
– Transparent Autonomization

Conclusions
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.
UTEP Computer Science Colloquium
Aug. 16, 2005
12
FIU
ACRL
Overview:
Challenges

New programs (developing from scratch)
– Autonomic code is scattered over functional code.
Motivation
Overview

Realizations
Case Study
Code for self-healing, self-optimization, self-protection,
and self-configuration tend to crosscut functional code.
– Unanticipated and transient adaptations.
Related Work

Conclusions


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.
We use transparent autonomization to weave selfmanagement code into existing applications.
UTEP Computer Science Colloquium
Aug. 16, 2005
13
FIU
ACRL
Key Concepts and Technologies
Overview:
Motivation
Overview
Realizations
Case Study
Aspect-Oriented
Programming
Behavioral
Reflection
Component-Based
Programming
Related Work
Conclusions
Transparent Autonomization
Adaptive Middleware
Technologies
UTEP Computer Science Colloquium
Program Families and
Product Lines
Aug. 16, 2005
14
FIU
ACRL
Overview:
Motivation
Overview
Aspect-Oriented Programming
“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]
Realizations
Case Study
Business
Tangled Code
Logic

Aspects
AOP Supports
– Separation of concerns
at development and
maintenance time.
Related Work
Conclusions
Dev.
Time
Aspect Weaver

Problem
Compile
Time
– Tangled Code at run time.
– Dynamic reconfiguration
need separated concerns at
run time.
Woven Code
Run
Time
UTEP Computer Science Colloquium
Aug. 16, 2005
15
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Behavioral Reflection
“Computational reflection is the activity performed by a
computational system when doing computation about (and by that
possibly affecting) its own computation.” [Maes87]

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
Meta-Level Objects
Meta Level
Generic MOP
Metaobjects
2”
3”
2’
Base Level
1’
1
Base-Level Objects
Message flow
UTEP Computer Science Colloquium
Receiver Object
Sender Object
Intercepted Message flow
Aug. 16, 2005
16
FIU
ACRL
Overview:
Motivation
Component-Based Design
“Components are units of independent deployment, third-party
composition, which have no (externally) observable states.” [Szyperski99]
Overview
Realizations
Case Study
Related Work

Conclusions
Compile-time
composition
Compile Time

Run-time
recomposition
…
– Adapt-ready
programs
– Late binding
Compile Time
UTEP Computer Science Colloquium
Run Time
Aug. 16, 2005
17
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Middleware
“… applications should be able to inspect internal components and
also adapt the system at runtime to meet current application needs.”
[Blair97]

Middleware lies between application and OS
– Traditionally hides distribution (CORBA, Java/RMI, .NET)
– Can make many other issues transparent to application
Conclusions
Host computer
(wired workstation)
APPLICATION
LAYER
MIDDLEWARE
LAYER
Message &
data paths
Application
Host computer
(wireless laptop)
Host computer
(wireless palmtop)
Application
Application
“core” middleware
components
Proxy node
(e.g., desktop)
observers
responders
NETWORK
LAYER
UTEP Computer Science Colloquium
Aug. 16, 2005
18
FIU
ACRL
Overview:
Families 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.
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions

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].
UTEP Computer Science Colloquium
Aug. 16, 2005
19
FIU
ACRL
Overview:
Motivation
Overview
Steps in Transparent Autonomization

Two Steps
1. An adapt-ready program or a managed element is
produced statically:

Realizations
Case Study
Related Work
Conclusions
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.
X1
(managed program)
X3
X0
(existing program)
X4
X8
X autonomic program
X2
(managed program)
First Step:
at compile, startup, or load time
X5 X6 X7
S1
S2
design decision
UTEP Computer Science Colloquium
Second Step:
at run time
X9
reversible design decision
subfamily boundary
Aug. 16, 2005
20
FIU
ACRL
Overview of the approach
Overview:
Motivation
Original application
A configuration file
Realizations
Case Study
Related Work
Conclusions
Transformation Process
Generated
managed
program
Autonomic Manager
Managed Element
UTEP Computer Science Colloquium
Run Time
Program Address Space
Compile/Startup Time
Overview
Aug. 16, 2005
21
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
22
FIU
ACRL Transparent Autonomization Realizations
Overview:

We target distributed applications.

Depending on where the hooks are incorporated, we
identify three approaches to transparent shaping.
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
TRAP
1. inside
insidean
anapplication
application
program
program
itself
itself
2. inside
inside its
itssupporting
supporting
middleware
middleware
3. inside the system platform.
Client Program
Application
Requester
Layer
ACT
Server Program
Interaction
Provider
Component
Component
Middleware
Layer
Operating
System
Network
process boundaries
Program component
Flow of service request
Hook
A typical client/server application.
UTEP Computer Science Colloquium
Aug. 16, 2005
23
FIU
ACRL
Overview:
Middleware-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.
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions

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)
UTEP Computer Science Colloquium
Aug. 16, 2005
24
FIU
ACRL ACT: Middleware-Based Realization of TS
Overview:
Overview
Realizations
No need for any transformation in the original
CORBA program (the hook is inside ORB).
Case Study
Related Work
Conclusions
armstrong:~> java Host.class Host.class.config
OriginalApplication.class AutonomicManger.cla
ss
Autonomic Manager
Managed Element
UTEP Computer Science Colloquium
Run Time
Program Address Space
Compile Time Startup Time
Motivation
Aug. 16, 2005
25
FIU
ACRL
ACT Architecture Overview
Overview:
Motivation
Client Program
Overview
Realizations
Case Study
Application
Layer
Related Work
Conclusions
Server Program
Middleware
Layer
Requester object
Provider object
Autonomic Manager
Autonomic Manager
Generic
Interceptor
Generic
Interceptor
Client ORB
Server ORB
Operating
System
Network
process boundaries
Program component
Request flow
Request flow
Hook
The flow of a request/reply in an ACT-ready application.
UTEP Computer Science Colloquium
Aug. 16, 2005
26
FIU
ACRL
Case Study: Image Retrieval Application
AP-3: 11 Mbps,
College subnet
Overview:
Motivation
Overview
A
B
Image Client
D
Image Server
Realizations
C
Case Study
AP-1: 11 Mbps,
Dept. subnet
Related Work
AP-2: 2 Mbps,
Dept. subnet
Conclusions
Rule-Based
Interceptor
readSmall
read
send_request
Image Client
Image Server
pipeline
Interaction
RemoveInterceptor
Middleware
Layer
InsertInterceptor
rule
dynamic interceptor
CORBA
ORB
GetStatus
generic interceptor
stub
Application
Layer
Network
Operating
System
process boundaries
Generic Interceptor
UTEP Computer Science Colloquium
Program object
Flow of service request
Aug. 16, 2005
Hook
27
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Evaluation of Self-Optimization

Automatic maintenance of frame-rate in an
image retrieval application using ACT
transparently
Case Study
Related Work
Conclusions
Frame Rate Using Automatic Adaptation
11Mbps
2Mbps
11Mbps
4
Frame Rate
3.5
3
2.5
2
1.5
1
0.5
0
0
60
120
180
240
300
360
420
480
540
Time in seconds
UTEP Computer Science Colloquium
Aug. 16, 2005
28
FIU
ACRL
Overview:
ACT 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
– Generic interceptors as hooks
– Rule-based interceptors and rules as adaptive code
UTEP Computer Science Colloquium
Aug. 16, 2005
29
FIU
ACRL
Language-Based Approach
Overview:
Motivation

Motivation
–
–
–
–
–
Overview
Realizations
Case Study
Related Work
Conclusions

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)
UTEP Computer Science Colloquium
Aug. 16, 2005
30
FIU
ACRL TRAP: Language-Based Realization of TS
Overview:
Original application
A configuration file
Motivation
Overview
TRAP at compile time
Realizations
Related Work
Intercepting Aspect Generator
Reflective Class Generator
Conclusions
Intercepting
Aspect
Aspect
Aspects
Wrapper-Level
Aspect
Aspect
Classes
Meta-Level
Aspect
Aspect
Classes
Compile Time
Case Study
Aspect Compiler
Generated
managed
application
Autonomic Manager
Managed Element
UTEP Computer Science Colloquium
Run Time
Program Address Space
Aug. 16, 2005
31
FIU
ACRL
TRAP/J
Overview:
Motivation

Existing program

Selecting classes
Original Application
(.class files)
A configuration file (contains a list of
classes to become reflective)
Overview
Realizations
Case Study
Related Work
Conclusions
TRAP/J at Compile Time

Generating hooks
Intercepting Aspect Generator

Weaving hooks
Intercepting
Aspect
Aspect
Aspects
Reflective Class Generator
Wrapper-Level
MetaLevel
MetaLevel
Class
Class
Class
Meta-Level
BaseLevel
BaseLevel
Class
Class
Class
AspectJ Compiler (ajc)
Generated adapt-ready
application (.class files)
Data Flow
UTEP Computer Science Colloquium
A File
A Process
TRAP/J Boundary
Aug. 16, 2005
33
FIU
ACRL
Case Study: Wireless Audio Streaming
Overview:
Receiver
Motivation
Sender
Overview
Receiver
Ad-Hoc
Wireless
Network
Realizations
Case Study
Related Work
Receiver
Conclusions
Audio Stream Path
MetaSocket
close
send
InvokeMethod
pipeline
filter
delegate
ASA Receiver
Interaction
RemoveDelegate
Java Socket
Class
GetStatus
WrapperLevel_Socket
UTEP Computer Science Colloquium
Application
Layer
Middleware
Layer
InsertDelegate
meta object
wrapper object
ASA Sender
Ad Hoc
Network
Operating
System
process boundaries
Program object
Flow of service request
Aug. 16, 2005
Hook
34
FIU
ACRL
MetaSockets Evaluation
Overview:
Motivation
1 2 34
Sender
Base Level
Receiver
FEC
Encoder
MetaSocket
Meta Level
MetaSocket
Java
Socket
Java.net package
Java
Socket
Overview
Realizations
JVM on
Windows XP
Case Study
Java Virtual Machine
1 2 34
FEC
Decoder
JVM on
Familiar Linux
Wireless Network
Related Work
x
x
x
x
Conclusions
Audio Packet Path
x
Packet Lost
Loss Rate (%)
Loss Rate Status
100
90
80
70
60
Network Loss Rate
Application Loss Rate
50
40
30
20
10
0
5
65
125
185
245
305
365
425
Time to the experiment in seconds (Samples per 5 seconds)
UTEP Computer Science Colloquium
Aug. 16, 2005
35
FIU
ACRL
TRAP.NET
Overview:
Motivation
Class Name List
.NET Assemblies (dll, exe)
Overview
TRAP.NET
Realizations
Related Work
Conclusions
Generic Aspect
Generator
Metaobject Assembly
Generator
Aspects
Aspect
Aspect
Assemblies
Metaobject
Aspect
Aspect
Assemblies
AspectDNG Compiler (AspectDNG.exe)
Compile Time
Case Study
Adapt-Ready .NET Assemblies
UTEP Computer Science Colloquium
Startup Time
C:> Host.exe Host.exe.config AdaptReadyApplication.exe
AutonomicManger.exe
Aug. 16, 2005
36
FIU
ACRL
TRAP.NET – Adapt-Ready Generator
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
37
FIU
ACRL
TRAP.NET – Composer Interface
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
38
FIU
ACRL
Overview:
TRAP 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
– 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.
UTEP Computer Science Colloquium
Aug. 16, 2005
39
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
40
FIU
ACRL
Overview:
Transparent Application Integration

Motivation
– Using transparent Autonomization tools beyond a
single application
– Supporting higher level type of adaptation, namely,
application integration
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions

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.
UTEP Computer Science Colloquium
Aug. 16, 2005
41
FIU
ACRL
Overview:
Application Integration

Motivation
Constituent applications may be developed in
– different programming languages
– targeted to run on different platforms
Overview
Realizations
Case Study
Related Work
Conclusions

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.
UTEP Computer Science Colloquium
Aug. 16, 2005
42
FIU
ACRL
Middleware Integration
Overview:
Motivation

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
Overview
Realizations
Case Study
Related Work
Conclusions
– N * (N-1) / 2 translators

Using a common language reduces this number
to N
Need for a common middleware, or
middleware for middleware!
UTEP Computer Science Colloquium
Aug. 16, 2005
43
FIU
ACRL
Overview:
Web Services to the Rescue!

Source of Problems:
– Different corporations adopted different middleware
technologies.
– Middleware packets often cannot pass through
Internet firewalls.
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions

Web services
– Well supported by academia and industry.
– Can be used atop the popular HTTP protocol.
UTEP Computer Science Colloquium
Aug. 16, 2005
44
FIU
ACRL
Overview:
Web Services Background

– A provider program.
– A requester program.
– A directory service (for simplicity, not considered further).
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Service-Oriented Architecture

Web services
– are software programs delivered over the Internet
– can be used through a service descriptor defined in WSDL
and the SOAP messaging protocol
Requester Program
Provider Program
Application
Requester
Layer
Provider
Component
Component
Middleware
Layer
WSDL
WSDL
SOAP
SOAP
System
Platform
Network
Internet
process boundaries
Program component
UTEP Computer Science Colloquium
Flow of service request
A2A Interaction
Aug. 16, 2005
45
FIU
ACRL
Overview:
Transparent Application Integration

Web services by themselves do not provide a
transparent solution to application integration.
Question: Where to host the translators?

Bridge Approach

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
– 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.
UTEP Computer Science Colloquium
Aug. 16, 2005
46
FIU
ACRL
Overview:
Bridge Approach

Motivation
Advantages:
– no modification to the original programs, scalability,
maintainability.
Overview
Realizations
Case Study

Disadvantages:
– overhead of process-to-process redirection, SPOF,
bottleneck, impossible in some cases.
Related Work
Conclusions
Requester Program
Requester-Side Bridge
Provider Program
?
Application
Layer
Middleware
Layer
System
Platform
Provider-Side Bridge
Intranet
WSDL
WSDL
SOAP
SOAP
X
UTEP Computer Science Colloquium
Internet
X
Intranet
Aug. 16, 2005
47
FIU
ACRL
Overview:
Transparent Autonomization Approach

– Resolves the problems mentioned for the bridge approach.
– Java, C++, .NET, and CORBA are supported
Motivation
Overview
Realizations
Case Study
Advantages:

Disadvantages:
– The appropriate tools may not be available
Related Work
Conclusions
Requester Program
Application
Layer
Provider Program
?
1
Middleware
Layer
2
System
Platform
3
4
WSDL
WSDL
SOAP
SOAP
UTEP Computer Science Colloquium
X
Internet
X
5
6
Aug. 16, 2005
48
FIU
ACRL Case Study: Fault-Tolerance Surveillance
Overview:
Motivation

Transparent integration of two existing applications
– An image retrieval application
Overview
Realizations

Case Study

Related Work

Conclusions
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.
UTEP Computer Science Colloquium
Aug. 16, 2005
49
FIU
ACRL
Overview:
Motivation
Original Applications
Image Retrieval
Client Application
Image Retrieval
Server Application
Overview
Realizations
Case Study
Related Work
Wired Network
Conclusions
Frame Grabber
Standalone Application
UTEP Computer Science Colloquium
Aug. 16, 2005
50
FIU
ACRL
Overview:
Integrated Fault-Tolerant Application
Image Retrieval Application
Frame Grabber Application
Motivation
Overview
Client
Realizations
Server
Case Study
Related Work
Internet
Conclusions
Original CORBA
Original CORBA
Application Application
camera
Image Retrieval
Server Program
Java
CORBA
Intranet
UTEP Computer Science Colloquium
Sample Grabber
Server Program
1
camera
C#
WSDL
WSDL
SOAP
SOAP
Internet
Linux
Translator components
Original
Original
.NET
.NET
Application
Application
2
Java
CORBA
Program components
Fault-Tolerant
Component
Image Retrieval
Client Program
files
Linux
Transparent
Application Integration
Flow of data
.NET
Windows
Flow of service request
A2A Interaction
Aug. 16, 2005
51
FIU
ACRL
Overview:
Transparent App. Integration Summary

Motivation
Overview
Transparent Autonomization provides
transparent application integration
– Alternative solutions using TRAP and ACT
– Supports interoperation among Java RMI, CORBA,
and .NET applications through Web service.
Realizations
Case Study
Related Work
Conclusions

Remaining issues
– Automatic translation
– Automatic service discovery
UTEP Computer Science Colloquium
Aug. 16, 2005
52
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
53
FIU
ACRL
Overview:
When?

When the adaptivr code is incorporated?
Motivation
Overview
Middleware Type
Realizations
Mutable
Case Study
Tunable
Related Work
Configurable
Conclusions
Customizable
Transparent Shaping
Dynamic
Middleware
Static
Middleware
Hardwired
Develop. Time
Compile Time
Startup Time
Run Time
Middleware Lifetime
Hardwired Middleware:
Electra, Totem, Horus, Isis
Customizable Middleware:
Personal/Embedded Java, Orbix/E
Configurable Middleware:
Eternal, IRL, FTS, TAO-LB, Rocks, Racks, Orbix, ORBacus, JacORB, QuO
Tunable Middleware:
TAO, ZEN, CIAO, DynamicTAO, UIC, OpenCORBA, ACE, FlexiNet, Iguana/J, MetaXa
Mutable Middleware:
Open ORB, Open COM
UTEP Computer Science Colloquium
Aug. 16, 2005
54
FIU
ACRL
Overview:
Motivation
Overview
Where and How?


Where the adaptive code resides?
How the adaptive code is incorporated?
Realizations
Adaptable Applications, Existing/Non-Adaptable Applications
Application
Case Study
Transparent
Shaping
Conclusions
BBS, …
Domain-Specific
Services
QuO, OGS, …
Common Services
ACT/J, IRL,FTS,TAO-LB, …
Java RMI, TAO,DynamicTAO,Orbix, JacORB, Squirrel,OpenCorba, OpenORB, Electra,…
Distribution Services
Middleware
TRAP/J, Composition Filters, RNTL ARCAD, …
Related Work
Iguana/J, PROSE, Guaraná, …
MetaSockets, Java Net Package, ACE, Horus, Isis, Ensemble, …
Host-Infrastructure
Services
KMX, Eternal, Rocks, Racks, DEOS, GRACE, Graybox, …
Windows OS, Linux OS, Sun Solaris OS, Mac OS
Transparent shaping boundary
UTEP Computer Science Colloquium
System Platform
Hooks to incorporate adaptive code dynamically
Aug. 16, 2005
55
FIU
ACRL
Overview:
Agenda

Motivation

Overview

Realizations

Case Study

Related work

Conclusions
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
UTEP Computer Science Colloquium
Aug. 16, 2005
56
FIU
ACRL
Summary of Contributions
Overview:
Motivation

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
UTEP Computer Science Colloquium
Aug. 16, 2005
57
FIU
ACRL
Overview:
Specific Accomplishments

A high level view of our accomplishments
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Transparent Autonomization
Model …….…………………..
Programming
Model
Extensions..…………………
TRAP
ACT
Prototypes ……………..……. TRAP/J, TRAP/C++, TRAP.NET, TRAP/BPEL
Hooks ….…………………………………
Core
Assets
Coarse-Grained ..
ACT/J
Wrappers & Metaobjects
Generic Interceptors
Delegates: MetaSockets
Proxies: Generic Proxy
non-functional
code
Fine-Grained …… Filters: FEC, Encryption/Dec., Compression/Dec.
Existing Applications …………………...
Crosscutting Concerns ………….………………. QoS
instantiates
provides
UTEP Computer Science Colloquium
Audio Streaming App.
Security
Image Retrieval App.
QoS vs. Energy Man.
uses
Rules: Conn. Management,App. Integration
Frame Grabber App.
Self-Management/Optimization App. Integration
is applied to
supports
Aug. 16, 2005
58
FIU
ACRL
Supporting Other Existing Applications
Overview:
Motivation

Expanding the set of supported existing programs.
Overview
Realizations
Case Study
Related Work
Transparent Autonomization
Model …….…………………..
Programming
Model
Extensions…………………..
TRAP
ACT
KMX
Conclusions
Prototypes ……………………TRAP/BPEL TRAP/J TRAP.NET
Hooks ……………………………………. Wrappers & Metaobjects
Coarse-Grained ..
Core
Assets
Delegates: MetaSockets
ACT/C++
ACT/J
KMX/Linux
Generic Interceptors
iptables
Proxies: Generic Proxy
Transient Proxies
non-functional
code
Fine-Grained ……Filters: FEC, Encryption/Dec., Compression/Dec.
Existing Applications …………………... Audio Streaming App.
Crosscutting Concerns …………………………. QoS
instantiates
provides
UTEP Computer Science Colloquium
Security
Video Streaming App.
QoS vs. Energy Man.
uses
Rules: Conn. Management,App. Integration
Image Retrieval App.
Frame Grabber App.
Self-Management/Optimization App. Integration
is applied to
supports
Aug. 16, 2005
59
FIU
ACRL
Overview:
Current Projects

Motivation
– Drs. Deng, Clarke, Hristidis, Rangaswami, Zhang,
and Prabakar.
– Students: Onyeka Ezenwoye, Eduardo Monterio,
Adelein Rodriguez, and Weixian Sun.
Overview
Realizations
Case Study
Related Work
Conclusions
IP_Comm

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.
UTEP Computer Science Colloquium
Aug. 16, 2005
60
FIU
ACRL
Overview:
Acknowledgements

This work was supported in part by
– U.S. Navy, Office of Naval Research
Motivation
Overview

Grant No. N00014-01-1-0744
– National Science Foundation grants
Realizations
Case Study

Related Work

Conclusions



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.
UTEP Computer Science Colloquium
Aug. 16, 2005
61
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
References (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, ``SelfOptimization in Wireless Audio Streaming,'' To appear in Proceedings of the International
Conference on Autonomic Computing (ICAC-04), New York, NY, May 2004.
UTEP Computer Science Colloquium
Aug. 16, 2005
62
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
References (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.
UTEP Computer Science Colloquium
Aug. 16, 2005
63
FIU
ACRL
Overview:
Motivation
Overview
Realizations
Case Study
Contact Information
S. Masoud Sadjadi
Assistant Professor
University Park, ECS 212C
11200 S.W. 8th Street
Miami, FL 33199
Related Work
Conclusions
Tel: (305)348-1835 Fax: (305)348-3549
Email: [email protected]
URL: 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/
Questions?
Thank you!
UTEP Computer Science Colloquium
Aug. 16, 2005
64