1. UTEP Computer Science Colloquium, August 16, 2005 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: sadjadi@cs.fiu.edu URL: http://www.cs.fiu.edu/~sadjadi/

2. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 2 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

3. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 3 Increase 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 requires dynamic adaptation. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

4. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 4  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? Wearable Computing Military ApplicationsOverview: Motivation Overview Realizations Case Study Related Work Conclusions

5. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 5  Demand for Critical Systems –Must continue to operate correctly during exceptional situations.  Examples: Why Dynamic Adaptation?  Need for dynamic adaptation –hardware component failures –network outages –software faults –security attacks Overview: Motivation Overview Realizations Case Study Related Work Conclusions Financial Networks Water/Power Systems

6. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 6 Why Dynamic Adaptation? Uplink Gbps SCS Core Network Campus Network and Internet Uplink Gbps ACRL Network App &DB Server Media GW 1 Gbps Monitoring Box VoIP Phone desktop POTS to VoIP Adapter (Linux Box) POTS Phone VoIP Phone desktop 802.11g laptop 802.11b Cell Phone NAT Router Overview: Motivation Overview Realizations Case Study Related Work Conclusions

7. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 7 Solution using Autonomic Computing  Observation: –Processor time is becoming virtually free. –Human time/effort is becoming more expensive.  Autonomic Computing: –Initiated by IBM and originated in the human autonomic nervous system, autonomic computing promises self-managed and long-running systems that require only limited, high-level human guidance.  Approach: –Embed management of complex systems inside the systems themselves  Risk: –Entangling code for self-management with the code for the business logic of the original systems Management complexity may actually increase! Overview: Motivation Overview Realizations Case Study Related Work Conclusions

8. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 8 Observation 1  Autonomic behavior is concerned only with their non- functional requirements.  Definition –Functional requirements describe the interaction between the system and its actors (e.g., end users and other external systems) independent of its implementation. –Non-functional requirements describe aspects of the system that are not directly related to the functional requirements of the system (e.g., QoS, security, scalability, performance, fault-tolerance, and self-*).  Assumption –Software systems are composed of functional and non- functional code, corresponding to the functional and non- functional requirements of the system, respectively. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

9. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 9 Observation 2  Non-functional code tends to crosscut the functional code. –It is impossible to localize non-functional aspects (e.g., security) into functions or objects using procedural or object-oriented languages. –Therefore, non-functional code is typically tangled into functional code. –Therefore modification (maintenance/offline) and adaptation (run time/online) of non-functional code requires modification of functional code, which is error-prone and hard to accomplish.  How to solved this problem: –Separation of concerns both offline and online! Overview: Motivation Overview Realizations Case Study Related Work Conclusions

10. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 10 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

11. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 11 RAPIDware Project  Funded by U.S Office of Naval Research –Adaptable Software / Critical Infrastructure Protection Program  Software adaptation technologies for: –Detecting and responding to environmental changes –Strengthening self-auditing capabilities of “always-on” systems  Focus: High-assurance adaptive middleware –Rigorous software engineering, code generation, etc –Military command and control, crisis management systems  Enable systems to operate through failures and attacks Key Question: How to support run-time adaptive behavior not envisioned during original development? Overview: Motivation Overview Realizations Case Study Related Work Conclusions

12. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 14 Key Concepts and Technologies Aspect-Oriented Programming Behavioral Reflection Component-Based Programming Transparent Autonomization Adaptive Middleware Technologies Program Families and Product Lines Overview: Motivation Overview Realizations Case Study Related Work Conclusions

15. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 15 Aspect-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 RunTime Aspect Weaver CompileTime AspectsBusiness LogicDev.Time “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 Case Study Related Work Conclusions

16. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 16 Base Level 1 Message flow Intercepted Message flow Base-Level Objects Sender ObjectReceiver Object Behavioral Reflection Meta Level Generic MOP Dynamic MOPs Meta-Level Objects Metaobjects 2”2” 1’1’ 2’2’ 3”  Separation of concerns at run time  Base Level: Application objects are represented.  Meta Level: Metaobjects are categorized into MetaObject Protocols  Interception: Base-level messages are intercepted “Computational reflection is the activity performed by a computational system when doing computation about (and by that possibly affecting) its own computation.” [Maes87] Overview: Motivation Overview Realizations Case Study Related Work Conclusions

17. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 17 Component-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 … Run Time Overview: Motivation Overview Realizations Case Study Related Work Conclusions

18. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 18 Middleware  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 observers responders Proxy node (e.g., desktop) “core” middleware components Overview: Motivation Overview Realizations Case Study Related Work Conclusions

19. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 20 Steps in Transparent Autonomization X4X4 X3X3 X8X8 Second Step: at run time X5X5 X7X7 X6X6 X9X9 S1S1 S2S2 X 1 (managed program) First Step: at compile, startup, or load time X 2 (managed program) X 0 (existing program) X autonomic programreversible design decisiondesign decision subfamily boundary  Two Steps 1.An adapt-ready program or a managed element is produced statically:  The existing program with generic interceptors, called hooks, at certain points in its execution path. 2.Adaptable Autonomic programs are generated dynamically:  Using the hooks, a composer can insert or remove new autonomic code into the adapt-ready program. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

21. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 21 Overview of the approach Program Address Space Run Time Managed Element Autonomic Manager Compile/Startup Time Original application Transformation Process Generated managed program A configuration fileOverview: Motivation Overview Realizations Case Study Related Work Conclusions

22. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 22 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

23. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 23 Transparent Autonomization Realizations  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 ProgramServer Program Application Layer Middleware Layer Program componentFlow of service request Hook process boundaries Network Requester Component Provider Component Operating System 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 ACTOverview: Motivation Overview Realizations Case Study Related Work Conclusions

24. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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 [ICDCS’04,ICAC’04] –We use CORBA portable interceptors –A generic interceptor is incorporated into a CORBA program at startup time (adapt-ready) –Later at run time, the generic interceptor can be used to insert adaptive code into the adapt-ready program (adaptable programs) Overview: Motivation Overview Realizations Case Study Related Work Conclusions

25. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 25 ACT: Middleware-Based Realization of TS Compile Time Startup Time 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 Time Overview: Motivation Overview Realizations Case Study Related Work Conclusions

26. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 26 Client ProgramServer Program Application Layer Middleware Layer Operating System Server Program process boundaries Network Client ORB Requester object Server ORB Provider object Request flow Program component Hook Generic Interceptor Generic Interceptor ACT Architecture Overview The flow of a request/reply in an ACT-ready application. Client ProgramServer Program Application Layer Middleware Layer Operating System Server Program process boundaries Network Client ORB Autonomic Manager Requester object Generic Interceptor Server ORB Autonomic Manager Provider object Generic Interceptor Request flow Program component Hook Overview: Motivation Overview Realizations Case Study Related Work Conclusions

27. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 27 Case Study: Image Retrieval Application Image ClientImage Server Application Layer Middleware Layer Program objectFlow of service request Hook process boundaries Network Operating System Interaction Generic Interceptor readSmall GetStatus RemoveInterceptor InsertInterceptor CORBA ORB 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 AB C D Image Server Image Client pipeline rule Rule-Based InterceptorOverview: Motivation Overview Realizations Case Study Related Work Conclusions

28. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 28 Evaluation of Self-Optimization  Automatic maintenance of frame-rate in an image retrieval application using ACT transparently 11Mbps2Mbps11Mbps Overview: Motivation Overview Realizations Case Study Related Work Conclusions

29. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 30 Language-Based Approach  Motivation –Not all distributed systems use middleware. –Not all middleware provide facilities for interception. –Lack of behavioral reflection in many OO languages. –Need for direct modifications to source code. –Direct modification is difficult and error-prone  Approach [ICAC’05,DOA’04] –Using a compile- or load-time program transformation technique  compile-time aspect weaving (e.g., AspectJ)  compile-time meta-object protocols (e.g., Open C++)  load-time meta-object protocols (e.g., JOIE) Overview: Motivation Overview Realizations Case Study Related Work Conclusions

31. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 31 TRAP: Language-Based Realization of TS Reflective Class Generator Original application Aspect Compiler Intercepting Aspect Generator A configuration file Aspect Intercepting Aspects TRAP at compile time Generated managed application Aspect Wrapper-Level Classes Aspect Meta-Level Classes Compile Time Program Address Space Autonomic Manager Managed Element Run Time Overview: Motivation Overview Realizations Case Study Related Work Conclusions

32. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 32 BaseLevel Multicast- Socket Class Sender Class ms sender usesremoved Class Library Heap BaseLevel Multicast- Socket Class Sender Class ms sender usesremoved Class Library Heap WrapperLevel WrapperLevel_ MulticastSocket Class ms MetaLevel MetaLevel_ MulticastSocket Class meta-level objects BaseLevel Multicast- Socket Class Sender Class ms sender usesremoved Class Library Heap AdaptReady WrapperLevel WrapperLevel_ MulticastSocket Class ms TRAP Architecture: Layered Class Graph Overview: Motivation Overview Realizations Case Study Related Work Conclusions

33. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 33 TRAP/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 FlowA FileA ProcessTRAP/J Boundary MetaLevel Class BaseLevel Class Aspect MetaLevel Class BaseLevel Class Aspect Wrapper-Level Class Meta-Level Class Intercepting Aspects Intercepting Aspect Generator Reflective Class Generator TRAP/J at Compile Time Overview: Motivation Overview Realizations Case Study Related Work Conclusions

34. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 34 Sender Receiver Ad-Hoc Wireless Network Audio Stream Path close pipeline filter MetaSocket ASA SenderASA Receiver Application Layer Middleware Layer Program objectFlow of service request Hook process boundaries Ad Hoc Network Operating System Interaction GetStatus RemoveDelegate InsertDelegate Java Socket Class send wrapper object meta object delegate WrapperLevel_Socket InvokeMethod Case Study: Wireless Audio Streaming Overview: Motivation Overview Realizations Case Study Related Work Conclusions

35. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 35 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 FEC Encoder FEC Decoder x x x x 1 2 3 4 Packet Lost x MetaSockets Evaluation Overview: Motivation Overview Realizations Case Study Related Work Conclusions

36. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 36 TRAP.NET Aspect Metaobject Assembly Generator.NET Assemblies (dll, exe) AspectDNG Compiler (AspectDNG.exe) Generic Aspect Generator Class Name List Aspects Assemblies TRAP.NET Aspect Metaobject Assemblies Adapt-Ready.NET Assemblies Compile Time Startup Time C:> Host.exe Host.exe.config AdaptReadyApplication.exe AutonomicManger.exe Overview: Motivation Overview Realizations Case Study Related Work Conclusions

37. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 37 TRAP.NET – Adapt-Ready Generator Overview: Motivation Overview Realizations Case Study Related Work Conclusions

38. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 38 TRAP.NET – Composer Interface Overview: Motivation Overview Realizations Case Study Related Work Conclusions

39. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 40 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

41. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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 N 2 to N. –Transparent Autonomization of applications to host translators. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

42. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 42 Application Integration  Constituent applications may be developed in –different programming languages –targeted to run on different platforms  This requires conversion of data and commands between the applications. –Advent of Middleware in 1990’s mitigated this problem. –MW hides differences among programming languages, computing platforms, and network protocols. –Very successful in corporate wide application integration. –Examples: Java RMI, CORBA, DCOM/.NET Ironically, the difficulty of application integration has reappeared with the proliferation of heterogeneous middleware technologies. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

43. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 43 Middleware Integration  Problem: We need to translate the syntax and semantics of each middleware approach to other middleware approaches  Typically translation occurs at run time  Translations for N different applications involves –N * (N-1) / 2 translators  Using a common language reduces this number to N Need for a common middleware, or middleware for middleware! Overview: Motivation Overview Realizations Case Study Related Work Conclusions

44. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 45 Requester ProgramProvider Program Application Layer Middleware Layer Program componentFlow of service requestA2A Interaction process boundaries Network Requester Component Provider Component System Platform 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 WSDL SOAP WSDL SOAP Internet Overview: Motivation Overview Realizations Case Study Related Work Conclusions

46. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 47 Provider ProgramRequester Program Application Layer Middleware Layer System Platform InternetIntranetIntranet ? XX Bridge Approach  Advantages: –no modification to the original programs, scalability, maintainability.  Disadvantages: –overhead of process-to-process redirection, SPOF, bottleneck, impossible in some cases. Internet Provider-Side BridgeProvider Program Intranet Requester Program Intranet Requester-Side Bridge WSDL SOAP WSDL SOAP Application Layer Middleware Layer System Platform Overview: Motivation Overview Realizations Case Study Related Work Conclusions

48. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 48 Provider ProgramRequester Program Application Layer Middleware Layer System Platform Internet ? XX WSDL SOAP WSDL SOAP Internet Provider ProgramRequester Program Application Layer Middleware Layer System Platform 1 2 3 4 5 6 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 49 Case Study: Fault-Tolerance Surveillance  Transparent integration of two existing applications –An image retrieval application  Developed in CORBA by BBN Technologies.  Client retrieves stored images from the server continuously.  Freely available as part of the QuO framework –A sample grabber application  developed in.NET by NETMaster.  Freely available from Code Project web site.  Result of integration: –Transparent Integration: CORBA client can retrieve frames from the.NET sample grabber application. –Transparent self-healing: if one source fails, requests are automatically and transparently forwarded to the other source. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

50. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 50 Original Applications Wired Network Image Retrieval Client Application Image Retrieval Server Application Frame Grabber Standalone Application Overview: Motivation Overview Realizations Case Study Related Work Conclusions

51. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 51 Sample Grabber Server Program Intranet Image Retrieval Server Program Linux Java CORBA WindowsLinux Java CORBA.NET files Program componentsFlow of service requestA2A InteractionTranslator components C# camera Flow of data Image Retrieval Client Program Original CORBA Application Original.NET Application Integrated Fault-Tolerant Application Client Internet Server Frame Grabber Application Image Retrieval Application Overview: Motivation Overview Realizations Case Study Related Work Conclusions

52. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 53 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

54. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 54 When?  When the adaptivr code is incorporated? 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 Middleware Type Dynamic Middleware Mutable Tunable Configurable Customizable Hardwired Develop. Time Compile Time Startup Time Run Time Middleware Lifetime Static Middleware Transparent Shaping Overview: Motivation Overview Realizations Case Study Related Work Conclusions

55. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 55 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 Middleware 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á, … TransparentShaping Overview: Motivation Overview Realizations Case Study Related Work Conclusions

56. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 56 Agenda  Motivation  Overview  Realizations  Case Study  Related work  Conclusions Overview: Motivation Overview Realizations Case Study Related Work Conclusions

57. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 57 Summary of Contributions  We demonstrated the use of adaptive middleware to support transparent autonomization of distributed applications [ICDCS'04, ICAC'04-1].  We investigated how to enhance existing application code transparently in order to support autonomic behavior [ICAC'04-2, DOA'04].  We assessed the potential role of transparent autonomization beyond the domain of a single program to support application integration. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

58. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 58 Specific 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. QoSSecurityQoS vs. Energy Man. Delegates: MetaSockets Image Retrieval App. Rules: Conn. Management,App. Integration App. IntegrationSelf-Management/Optimization Frame Grabber App. instantiatesprovidesusesis applied to supports Generic InterceptorsWrappers & Metaobjects Coarse-Grained.. non-functional code Existing Applications …………………... Crosscutting Concerns ………….………………. Core Assets Hooks ….………………………………… Fine-Grained …… Programming Model Extensions..………………… Prototypes ……………..……. Model …….…………………..Overview: Motivation Overview Realizations Case Study Related Work Conclusions

59. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 59 Supporting Other Existing Applications  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. QoSSecurityQoS 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/JTRAP.NET iptables Transient Proxies Video Streaming App. instantiates providesusesis applied tosupports Programming Model Extensions………………….. Prototypes …………………… Model …….………………….. Overview: Motivation Overview Realizations Case Study Related Work Conclusions

60. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 62 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, ``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. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 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 191–192. Addison-Wesley Longman Publishing Co., Inc., 2001. [Maes87] Pattie Maes. Concepts and experiments in computational reflection. In Proceedings of the ACM Conference on Object-Oriented Languages. ACM Press, December 1987. [Kiczales97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J. M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented Programming. Springer-Verlag LNCS 1241, June 1997. [Szyperski99] C. Szyperski, Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1999. [Blair97] Gordon Blair, Geoff Coulson, and Nigel Davies. Adaptive middleware for mobile multimedia applications. In Proceedings of the Eighth International Workshop on Network and Operating System Support for Digital Audio and Video, pages 259-273, 1997. [Schmidt02] Douglas C. Schmidt. Middleware for real-time and embedded systems. Communications of the ACM, 45(6), June 2002. [CORBA03] Object Management Group, Framingham, Massachusett. The Common Object Request Broker: Architecture and Specification Version 3.0, July 2003. [Zinky97] John A. Zinky, David E. Bakken, and Richard E. Schantz. Architectural support for quality of service for CORBA objects. Theory and Practice of Object Systems, 3(1), 1997. [Yang02] Z. Yang, B. H.C. Cheng, R. E. K. Stirewalt, J. Sowell, S. M. Sadjadi, and P. K. McKinley. An aspect-oriented approach to dynamic adaptation. In Proceedings of the ACM SIGSOFT Workshop On Self-healing Software (WOSS'02), November 2002.Overview: Motivation Overview Realizations Case Study Related Work Conclusions

64. Aug. 16, 2005UTEP Computer Science Colloquium FIU ACRL 64 Contact Information Contact Information Questions? Thank you! S. Masoud Sadjadi Assistant Professor University Park, ECS 212C 11200 S.W. 8 th Street Miami, FL 33199 Tel: (305)348-1835 Fax: (305)348-3549 Email: sadjadi@cs.fiu.edusadjadi@cs.fiu.edu URL: http://www.cs.fiu.edu/~sadjadi/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/http://acrl.cs.fiu.edu/Overview: Motivation Overview Realizations Case Study Related Work Conclusions