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
Aug. 16, 2005 3UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 4UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 5UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Financial Networks Water/Power Systems
Aug. 16, 2005 7UTEP Computer Science Colloquium
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!
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 8UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 9UTEP Computer Science Colloquium
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!
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 10UTEP Computer Science Colloquium
FIUACRL AgendaAgenda
Motivation
Overview
Realizations
Case Study
Related work
Conclusions
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 11UTEP Computer Science Colloquium
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?
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 12UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 13UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
We use transparent autonomization to weave self-management code into existing applications.
Aug. 16, 2005 14UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 15UTEP Computer Science Colloquium
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]
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 16UTEP Computer Science Colloquium
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]
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 17UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 18UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 19UTEP Computer Science Colloquium
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].
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 20UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 21UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 22UTEP Computer Science Colloquium
FIUACRL AgendaAgenda
Motivation
Overview
Realizations
Case Study
Related work
Conclusions
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 23UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 24UTEP Computer Science Colloquium
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)
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 25UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 26UTEP Computer Science Colloquium
FIUACRL
Client Program Server Program
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.
Client Program Server Program
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 27UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 28UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 29UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 30UTEP Computer Science Colloquium
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)
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 31UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 33UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 34UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 35UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 36UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 37UTEP Computer Science Colloquium
FIUACRL TRAP.NET – Adapt-Ready GeneratorTRAP.NET – Adapt-Ready Generator
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 38UTEP Computer Science Colloquium
FIUACRL TRAP.NET – Composer InterfaceTRAP.NET – Composer Interface
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 39UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 40UTEP Computer Science Colloquium
FIUACRL AgendaAgenda
Motivation
Overview
Realizations
Case Study
Related work
Conclusions
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 41UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 42UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 43UTEP Computer Science Colloquium
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!
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 44UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 45UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 46UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 47UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 48UTEP Computer Science Colloquium
FIUACRL
Provider ProgramRequester Program
ApplicationLayer
MiddlewareLayer
System Platform
InternetInternet
?
X X
WSDL
SOAP
WSDL
SOAP
InternetInternet
Provider ProgramRequester Program
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 49UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 50UTEP Computer Science Colloquium
FIUACRL Original ApplicationsOriginal Applications
Wired NetworkWired Network
Image Retrieval Client Application
Image Retrieval Server Application
Frame Grabber Standalone Application
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 51UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 52UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 53UTEP Computer Science Colloquium
FIUACRL AgendaAgenda
Motivation
Overview
Realizations
Case Study
Related work
Conclusions
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 54UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 55UTEP Computer Science Colloquium
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
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 56UTEP Computer Science Colloquium
FIUACRL AgendaAgenda
Motivation
Overview
Realizations
Case Study
Related work
Conclusions
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 57UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 58UTEP Computer Science Colloquium
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 …….…………………..
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 59UTEP Computer Science Colloquium
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 …….…………………..
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 60UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 61UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 62UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 63UTEP Computer Science Colloquium
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.
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions
Aug. 16, 2005 64UTEP Computer Science Colloquium
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/
OvervieOverview:w:Motivation
Overview
Realizations
Case Study
Related Work
Conclusions