Transparent%20Autonomization:%20A%20Practical%20Approach%20to%20Autonomic%20Computing

1
Transparent AutonomizationA Practical Approach
to Autonomic Computing

• S. Masoud Sadjadi
• Autonomic Computing Research Laboratory (ACRL)
• School of Computing and Information Sciences
• Florida International University
• Email sadjadi_at_cs.fiu.edu
• URL http//www.cs.fiu.edu/sadjadi/

2
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
3
Increase in Software Complexity
Overview

• 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 requires
• dynamic adaptation.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
4
Why Dynamic Adaptation?

• 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.)

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
5
Why Dynamic Adaptation?

• Demand for Critical Systems
• Must continue to operate correctly during
  exceptional situations.
• Examples

Overview
Motivation
Overview
Realizations
Case Study
Financial Networks
Water/Power Systems
Related Work
Conclusions

• Need for dynamic adaptation
• hardware component failures
• network outages
• software faults
• security attacks

6
Why Dynamic Adaptation?
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Uplink Gbps
Conclusions
7
Solution using Autonomic Computing
Overview

• 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!

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
8
Observation 1
Overview

• 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.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
9
Observation 2
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.
• How to solved this problem
• Separation of concerns both offline and online!

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
10
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
11
RAPIDware Project
Overview

• 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?

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
12
Transparent 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
13
Challenges

• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
We use transparent autonomization to weave
self-management code into existing applications.
14
Key Concepts and Technologies
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
15
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


Overview
Motivation
Overview
Realizations

• AOP Supports
• Separation of concerns
• at development and maintenance time.
• Problem
• Tangled Code at run time.
• Dynamic reconfiguration need separated concerns
  at run time.

Case Study
Related Work
Conclusions
16
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
Overview
Motivation
Overview
Realizations

• 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

Case Study
Related Work
Conclusions
17
Component-Based Design
Components are units of independent deployment,
third-party composition, which have no
(externally) observable states. Szyperski99
Overview
Motivation
Overview

• Compile-time composition
• Run-time recomposition
• Adapt-ready programs
• Late binding

Realizations
Case Study
Related Work
Conclusions
18
Middleware
applications should be able to inspect
internal components and also adapt the system at
runtime to meet current application needs.


Blair97
Overview
Motivation
Overview

• Middleware lies between application and OS
• Traditionally hides distribution (CORBA,
  Java/RMI, .NET)
• Can make many other issues transparent to
  application

Realizations
Case Study
Related Work
Conclusions
19
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.
• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
20
Steps in Transparent Autonomization

• Two Steps
• 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.
• Adaptable Autonomic programs are generated
  dynamically
• Using the hooks, a composer can insert or remove
  new autonomic code into the adapt-ready program.

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
21
Overview of the approach
Overview
Original application
Motivation
Overview
Realizations
Case Study
Related Work
Compile/Startup Time
Conclusions
22
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
23
Transparent Autonomization Realizations

• We target distributed applications.
• Depending on where the hooks are incorporated, we
  identify three approaches to transparent shaping.
• inside an application program itself
• inside its supporting middleware
• inside the system platform.

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Client Program
Server Program
Interaction
Application Layer
Requester Component
Provider Component
Middleware Layer
Operating System
Network
process boundaries
Program component
Flow of service request
Hook
A typical client/server application.
24
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.
• Approach ICDCS04,ICAC04
• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
25
ACT Middleware-Based Realization of TS
Overview
Motivation
No need for any transformation in the original
CORBA program (the hook is inside ORB).
Overview
Compile Time
Realizations
Case Study
Related Work
Conclusions
armstronggt java Host.class Host.class.config
OriginalApplication.class AutonomicManger.cla ss
Startup Time
Program Address Space
Autonomic Manager
Run Time
Managed Element
26
ACT Architecture Overview
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
The flow of a request/reply in an ACT-ready
application.
27
Case Study Image Retrieval Application
AP-3 11 Mbps, College subnet
Overview
Motivation
Image Client
A
B
D
Image Server
Overview
Realizations
C
Case Study
AP-1 11 Mbps, Dept. subnet
AP-2 2 Mbps, Dept. subnet
Related Work
Conclusions
28
Evaluation of Self-Optimization

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

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
29
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
• Generic interceptors as hooks
• Rule-based interceptors and rules as adaptive code

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
30
Language-Based Approach
Overview

• 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 ICAC05,DOA04
• 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)

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
31
TRAP Language-Based Realization of TS
Original application
A configuration file
Overview
Motivation
Overview
TRAP at compile time
Realizations
Case Study
Related Work
Compile Time
Conclusions
Generated managed application
32
TRAP Architecture Layered Class Graph
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
33
TRAP/J
Overview

• Existing program
• Selecting classes
• Generating hooks
• Weaving hooks

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
34
Case Study Wireless Audio Streaming
Receiver
Overview
Sender
Motivation
Receiver
Overview
Ad-Hoc Wireless Network
Realizations
Case Study
Related Work
Receiver
Conclusions
Audio Stream Path
35
MetaSockets Evaluation
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
36
TRAP.NET
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
37
TRAP.NET Adapt-Ready Generator
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
38
TRAP.NET Composer Interface
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
39
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
• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
40
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
41
Transparent 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
42
Application Integration
Overview

• 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 1990s 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.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
43
Middleware Integration
Overview

• 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!

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
44
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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
45
Web 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

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Requester Program
Provider Program
Application Layer
Requester Component
Provider Component
Middleware Layer
System Platform
Network
process boundaries
Program component
Flow of service request
A2A Interaction
46
Transparent 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
47
Bridge Approach
Overview

• Advantages
• no modification to the original programs,
  scalability, maintainability.
• Disadvantages
• overhead of process-to-process redirection, SPOF,
  bottleneck, impossible in some cases.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
48
Transparent Autonomization Approach

• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
49
Case Study Fault-Tolerance Surveillance
Overview

• 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.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
50
Original Applications
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
51
Integrated Fault-Tolerant Application
Image Retrieval Application
Frame Grabber Application
Overview
Motivation
Overview
Client
Server
Realizations
Case Study
Related Work
Conclusions
52
Transparent App. Integration Summary

• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
53
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
54
When?

• When the adaptivr code is incorporated?

Overview
Motivation
Overview
Realizations
Transparent Shaping
Case Study
Related Work
Conclusions
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
55
Where and How?

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

Overview
Motivation
Overview
Realizations
Adaptable Applications, Existing/Non-Adaptable
Applications
Application
Case Study
Related Work
Domain-Specific Services
BBS,
Conclusions
Common Services
QuO, OGS,
Middleware
Distribution Services
Java RMI, TAO,DynamicTAO,Orbix, JacORB,
Squirrel,OpenCorba, OpenORB, Electra,
Host-Infrastructure Services
MetaSockets, Java Net Package, ACE, Horus, Isis,
Ensemble,
Windows OS, Linux OS, Sun Solaris OS, Mac OS
System Platform
Transparent shaping boundary
Hooks to incorporate adaptive code dynamically
56
Agenda

• Motivation
• Overview
• Realizations
• Case Study
• Related work
• Conclusions

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
57
Summary of Contributions
Overview

• 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.

Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
58
Specific Accomplishments

• A high level view of our accomplishments

Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
59
Supporting Other Existing Applications
Overview

• Expanding the set of supported existing programs.

Motivation
Overview
Transparent Autonomization
Model ...
Realizations
Case Study
Programming Model
ACT
TRAP
KMX
Extensions..
Related Work
Conclusions
ACT/J
TRAP/BPEL
ACT/C
KMX/Linux
TRAP/J
TRAP.NET
Prototypes
Generic Interceptors
Wrappers Metaobjects
Hooks .
iptables
Proxies Generic Proxy
Delegates MetaSockets
Coarse-Grained ..
Transient Proxies
Core Assets
non-functional code
Filters FEC, Encryption/Dec., Compression/Dec.
Rules Conn. Management,App. Integration
Fine-Grained
Audio Streaming App.
Image Retrieval App.
Frame Grabber App.
Existing Applications ...
Video Streaming App.
QoS
Security
QoS vs. Energy Man.
App. Integration
Self-Management/Optimization
Crosscutting Concerns .
60
Current 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
61
Acknowledgements

• 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
62
References (1)

• Computer04 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
63
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 191192. 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
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
64
Contact Information
S. Masoud Sadjadi Assistant Professor University
Park, ECS 212C 11200 S.W. 8th Street Miami, FL
33199 Tel [phone] Fax
[phone] Email sadjadi_at_cs.fiu.edu 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/
Overview
Motivation
Overview
Realizations
Case Study
Related Work
Conclusions

• Questions?

Thank you!