ACT Adaptive CORBA Toolkit: Integrating Adaptive Middleware Techniques

1. ACTAdaptive CORBA Toolkit:Integrating Adaptive Middleware Techniques SeyedMasoud Sadjadi Advisor: Dr. Philip K. McKinley Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University www.cse.msu.edu/sens

2. Motivation: • Obsevations: • There is no one complete solution to adaptive middleware • Each adaptive middleware approach has some advantages and shortcoming comparing to other approaches. • For each application, a customized solution seems to work better than a general solution. • Goals: • Promoting Code Reuse: • So many existing applications and third party components. • Adaptive code are tangled in the business code and is not reusable • Providing Unanticipated (Dynamic) Adaptation • Target apps: distributed applications including mobile, embedded, real-time, … . • Supporting heterogeneous devices • Supporting dynamic changes of the context

3. Our Solution: • Integration of the best aspects of different adaptive middleware techniques depending on the application.

4. Acknowledgement: • OMG (CORBA) • BBN Technology (QuO) • IONA (ORBacus, Orbix) • Freie Universität Berlin and Xtradyne Technologies AG. (JacORB) • DOC Group (ACE, TAO, CIAO, ZEN, TAO LoadBalancer) • UIUC Researchers (DynamicTAO, LegORB, UIC) • Distributed Multimedia Research Group, Lancaster University (Open ORB) • University of Rome “La Sapienza” (IRL)

5. Agenda: • Background • Introducing Adaptive Middleware Approaches • Categorizing Each Approach in the Middleware Layers • Evaluating Each Approach • Introducing ACT • Current Status of ACT • Concluding Remarks and Future Work

6. Background • Object-Oriented Computational Model: • An application is represented by interactions among a web of objects. Voice Amplifier Application Service provided through interface Service is accessed through a reference Thread Main Loop

7. Background (cont.) • Evaluation: • Transparency: • Not transparent. • Performance: • Can be very high. • Interoperability: • Can be interoperable • HTTP, FTP, …. • Generality of supported adaptations: • Tangled adaptive code. • No code reuse for business and systematic behavior. • Ad hoc dynamic adaptation. • Distributed Object Computational Model: • Objects are distributed on a network Client Server Application Layer File Shared Memory Socket Pipeline Pipeline Socket Shared Memory File Operating System Layer Network

8. Background (cont.) • Evaluation: • Transparency: • Hardware, Network, OS. • Language heterogeneity • Performance: • Depends on the ORB implementation. • Interoperability: • Interoperable with CORBA compliant. • Generality of supported adaptations: • Application specific adaptive code is still tangled with the business code. • ORB code is reused. • Ad hoc dynamic adaptation. • Middleware • Offers a higher level of programming abstraction. Client Server Application Layer Proxy Skeleton Middleware Layer ORB ORB Operating System Layer Socket Shared Memory File Pipeline Pipeline File Shared Memory Socket Network

9. Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. Adaptive Distribution Middleware Client Server Application Layer Proxy Skeleton ORB ORB ZEN UIC Distribution Middleware Layer CIAO LegORB JacORB ORBix TAO DynamicTAO OpenORB ORBacus Socket Shared Memory File Pipeline Network Pipeline File Shared Memory Socket

10. Adaptive Distribution Middleware • Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. • ORB Generations: • Static Monolithic ORB • Monolothic ORB with Compile-Time Configurable Flags • Dynamic Micro-ORB • Dynamic Reflective Micro-ORB: • Static Reflective Micro-ORB: TAO

11. Adaptive Distribution Middleware Micro-ORB vs. Monolithic-ORB: • Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. • Context: • Implementing full-service can yield a monolithic-ORB with large footprint • Problem: • Embedded Systems often have severe memory limitations • Solution • Micro-Kernel pattern • Virtual Component Pattern • Identify core ORB services whose behavior may vary • Move each core ORB service out of the ORB ZEN Monolithic-ORB Architecture [ZEN] Micro-ORB Architecture [ZEN]

12. Intent to factor out components that may not be needed Solution Use abstract interfaces for all components Upon ‘component-fault’ load concrete implementations using: Factory Method Proxy Component Configurator Adaptive Distribution Middleware Virtual Component Configurator Pattern • Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. Eager Static Loading Strategy Eager Dynamic Loading Strategy ZEN Virtual Component Static Structure Lazy Dynamic Loading Strategy

13. Adaptive Distribution Middleware • Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. DynamicTAO

14. Adaptive Distribution Middleware • Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB, UIC, OpenORB, JacORB, ORBacus, and ORBix. UIC

15. Adaptive Host Infrastructure Middleware • Evaluation: • Transparency: • Hardware, Network, and OS transparency for distribution ORB. • Performance: • Depends on the middleware implementation. • Interoperability: • Provides more interoperability. • Generality of supported adaptations: • Application specific adaptive code is still tangled with the business code. • ORB code is reused. • Ad hoc dynamic adaptation. • Examples are MetaSockets, ACE, and Rocks Client Server Application Layer Proxy Skeleton Distribution Middleware Layer ORB ORB ZEN CIAO TAO DynamicTAO UIC JacORB OpenORB ORBacus ORBix Meta- Sockets ACE Rocks Host Infrastructure Middleware Layer Rocks ACE Meta- Sockets Socket Shared Memory File Pipeline Network Pipeline File Shared Memory Socket

16. Adaptive Host Infrastructure Middleware • Examples are MetaSockets, ACE, and Rocks Meta- Sockets

17. Adaptive Host Infrastructure Middleware • Examples are MetaSockets, ACE, and Rocks ACE

18. Evaluation: • Transparency: • Provides transparent services to the application if used in combination with portable interceptors. • Performance: • Degrading the performance because of forwarding. • May have better overall performance, because of adaptation it offers. • Interoperability: • Can be designed CORBA compliant. • Generality of supported adaptations: • Some of the application specific adaptive code can be moved to this common middleware layer (limited). • Business code can be reused. • Adaptation code can be reused • Can be used for systematic dynamic adaptation. Adaptive Common Middleware • Examples are IRL, FTS, TAO LB, Eternal, Immune, and Realize. Client Server Application Layer IRL FTS TAO LB Eternal Immune Realize Common Layer Proxy Skeleton Distribution Layer ORB ORB ZEN CIAO TAO DynamicTAO UIC JacORB OpenORB ORBacus ORBix Host Layer MetaSockets ACE Rocks Rocks ACE MetaSockets Network Socket Shared Memory File Pipeline Pipeline File Shared Memory Socket

19. Adaptive Common Middleware • Examples are IRL, FTS, TAO LB, Eternal, Immune, and Realize.

20. Adaptive Common Middleware • Examples are IRL, FTS, TAO LB, Eternal, Immune, and Realize. Eternal

21. Adaptive Common Middleware • Examples are IRL, FTS, TAO LB, Eternal, Immune, and Realize. IRL

22. Evaluation: • Transparency: • Not transparent to the application. • Can be transparent if used with portable interceptors • Performance: • Have better performance if not used with interceptors. • Degrading the performance because of forwarding. • May have better overall performance, because of adaptation it offers. • Interoperability: • Can be designed CORBA compliant. • Generality of supported adaptations: • Most of the application specific adaptive code can be moved to this domain specific middleware layer. • Business code can be reused. • Adaptation code can be reused • Can be used for systematic dynamic adaptation. Adaptive Domain Specific Middleware • Examples are QuO and ACT. Client Server Application Layer Domain Layer Smart Proxies Delegates Adapters Callbacks Adapters Callbacks Delegates QuO Kernel ACT Kernel ACT Kernel QuO Kernel Common Layer IRL FTS TAO LB Eternal Immune Realize Proxy Skeleton Distribution Layer ORB ORB ZEN CIAO TAO DynamicTAO UIC JacORB OpenORB ORBacus ORBix Host Layer MetaSockets ACE Rocks Rocks ACE MetaSockets Network Socket Shared Memory File Pipeline Pipeline File Shared Memory Socket

23. Adaptive Domain Specific Middleware • Smart Proxies. Client Server Application Layer Domain Layer Smart Proxy Common Layer Proxy Skeleton Distribution Layer ORB ORB Host Layer Network

24. Adaptive Domain Specific Middleware • QuO. Client Server Application Layer Domain Layer Adapters Callbacks Adapters Callbacks Delegate Delegate QuO Kernel QuO Kernel Common Layer Proxy Skeleton Distribution Layer ORB ORB Host Layer Network

25. Adaptive Domain Specific Middleware • ACT Overview. Client Server Application Layer Domain Layer Adapters Callbacks Adapters Callbacks Delegate Delegate ACT Kernel ACT Kernel Common Layer Proxy Skeleton Distribution Layer ORB ORB Host Layer Network

26. Adaptive Domain Specific Middleware Example of adding a rule dynamically: Rule rule = new Rule(1, RuleType.SEND_REQUEST, "com.bbn.quo.examples.bette.interceptor.” + “DynamicConditionAction.TargetIsServerSlideService_Condition", "com.bbn.quo.examples.bette.interceptor.DynamicConditionAction.” + “ForwardRequest2SlideService_ClientLocalProxy_Action"); try{ ruleBase.insertRule(rule); } catch(Exception e) { e.printStackTrace(); System.exit(1); } public class RuleBaseClientRequestInterceptor extends LocalObject implements ClientRequestInterceptor { public void send_request(ClientRequestInfo ri) throws ForwardRequest { if(!setRuleBase(ri)) return; try{ ruleBase.processRules(RuleType.SEND_REQUEST, ri); } catch(ForwardRequest fr) { throw fr; } catch(Exception e) {} } public void send_poll(ClientRequestInfo ri) {…} public void receive_reply(ClientRequestInfo ri) {…} public void receive_exception(ClientRequestInfo ri) throws ForwardRequest {…} public void receive_other(ClientRequestInfo ri) throws … {…} } public class GenericRequestInterceptor extends LocalObject implements ClientRequestInterceptor, ServerRequestInterceptor, RequestInterceptorRunTimeRegistererOperations { private void processClientRequestInterceptors( ClientRequestInfo ri, int interceptionPoint) throws ForwardRequest { Set keys = clientRequestInterceptors.keySet(); Iterator iter = keys.iterator(); while(iter.hasNext()) { Object key = iter.next(); ClientRequestInterceptor clientReqInt = (ClientRequestInterceptor)(clientRequestInterceptors.get(key)); switch(interceptionPoint) { case SEND_REQUEST: clientReqInt.send_request(ri); break; case SEND_POLL: clientReqInt.send_poll(ri); break; case RECEIVE_REPLY: clientReqInt.receive_reply(ri); break; case RECEIVE_EXCEPTION: … case RECEIVE_OTHER: clientReqInt.receive_other(ri); break; }}}} public class GenericRequestInterceptor extends LocalObject implements ClientRequestInterceptor, ServerRequestInterceptor, RequestInterceptorRunTimeRegistererOperations { private Object loadAndInstantiateRequestInterceptor( String className) { Object retObject = null; try { Class c = Class.forName(className); Class partypes[] = new Class[1]; partypes[0] = org.omg.CORBA.ORB.class; Constructor ct = c.getConstructor(partypes); Object arglist[] = new Object[1]; arglist[0] = orb; retObject = ct.newInstance(arglist); } catch(Exception e) { e.printStackTrace(); System.exit(1); } return retObject; }} public class RuleBase implements RuleManagementOperations { public void processRules( RuleType ruleType, org.omg.PortableInterceptor.RequestInfo reqInfo) throws org.omg.CORBA.UserException { Iterator iterator = activeRules.keySet().iterator(); while(iterator.hasNext()) { java.lang.Object key = iterator.next(); ActiveRule activeRule = (ActiveRule)(activeRules.get(key)); if(activeRule.ruleType == ruleType) { if(activeRule.condition.check(reqInfo)) { // may throw a UserException. activeRule.action.process(reqInfo); } }}}} • ACT details. public class GenericRequestInterceptor extends LocalObject implements ClientRequestInterceptor, ServerRequestInterceptor, RequestInterceptorRunTimeRegistererOperations { public void registerClientRequestInterceptor(String cri) throws AlreadyRegisteredException { ClientRequestInterceptor clientRequestInterceptor = (ClientRequestInterceptor) (loadAndInstantiateRequestInterceptor(cri)); clientRequestInterceptors.put(cri, clientRequestInterceptor); } public void registerServerRequestInterceptor(String sri) throws AlreadyRegisteredException { ServerRequestInterceptor serverRequestInterceptor = (ServerRequestInterceptor) (loadAndInstantiateRequestInterceptor(sri)); serverRequestInterceptors.put(sri, serverRequestInterceptor); }} public class GenericRequestInterceptor extends LocalObject implements ClientRequestInterceptor, ServerRequestInterceptor, RequestInterceptorRunTimeRegistererOperations { public void send_request(ClientRequestInfo ri) throws ForwardRequest { processClientRequestInterceptors(ri, SEND_REQUEST); } public void send_poll(ClientRequestInfo ri) {…} public void receive_reply(ClientRequestInfo ri) {…} public void receive_exception(ClientRequestInfo ri) throws ForwardRequest {…} public void receive_other(ClientRequestInfo ri) throws ForwardRequest {…} } Client Server Application Layer Domain Layer Common Layer Proxy Skeleton Distribution Layer ORB ORB Host Layer Network

27. Adaptive Domain Specific Middleware • ACT details. Client Server Application Layer Domain Layer Adapters Callbacks Adapters Callbacks Delegate Delegate ACT Kernel ACT Kernel Common Layer Proxy Skeleton Distribution Layer ORB ORB Host Layer Network

28. ACT Kernel Observer code sample in CDL: contract Diagnose ( syscond quo::ValueSC quo_sc::ValueSCImpl userLatencyThreshold, //msec syscond quo::DataSC quo_data::DataSCImpl expectedNetworkCapacity,//kbps syscond quo::DataSC quo_data::DataSCImpl expectedServerLoadAverage //num ) { syscond probe instr_sc::PropertyProbe measuredNetworkCapacity("network_Capacity", 100.0); //kbps syscond probe instr_sc::PropertyProbe measuredNetworkPropDelay("network_PropDelay", 50.0); //msecs …. }; Decision Maker sample in CDL: contract Diagnose (…) { region Normal ( (measuredAverageTotalLatency <= userLatencyThreshold * thresholdFactor) and (Not useInstrumentation )) { region Faster // The measured latency faster than half the // expected latency region Slower …. region Expected (true) … } region Instrumented (true) { region ObjectSlow region NetworkSlow region UnknownBottleneck (true) …. }; Responder sample code in CDL: contract Diagnose (…) { transition any->ObjectSlow { synchronous { instrumentationConverged.reset(-11); processingFactor.longValue(100); thresholdFactor.doubleValue(0.05); } } transition ObjectSlow->any {} transition any->NetworkSlow {} transition NetworkSlow->any {} transition any->UnknownBottleneck {} transition UnknownBottleneck->any {} …. }; Decision Maker (DM) Responder Observer ACT Kernel Event Mediator

29. ACT Delegate Delegate sample code in ASL: behavior Diagnose () { qosket slide::DiagnoseDelegateQosket qk; void slide::SlideShow::read(in long gifNumber, out string size, out octetArray buf) { inplaceof METHODCALL { region Instrumented { region ObjectSlow { iServer.readBig(gifNumber, size, buf, holder); } region NetworkSlow { iServer.readSmallProcessed(gifNumber, size, buf, holder); }…. }; getStatus() FP get() put() Fltr Delegate put() Filter Pipeline LP get() send() close() MT close() send() SS insertFilter() removeFilter()

30. ACT Current Status: • Generic Interceptors are implemented in Java. • Rule-based interceptors are developed in Java. • A library of catalysts is currently being developed. Examples are: • Power consumption adaptation. • Wireless network QoS adaptation. • Run-time architecture for ACT kernel is being develped. • Some sample delegates are ready for test.

31. Concluding Remarks and Future Work: • Different adaptive middleware are categorized according to a taxonomy first introduced by Schmidt [Taxonomy]. • Each approach is evaluated with respect to transparency, performance, interoperability, and generality of supported adaptations. • Novel key ideas such as generic and rule-based interceptors are developed that provide the minimum required infrastructure to support dynamic adaptation. • An architecture for run time adaptation is introduced that includes the three key components: decision maker, observer, and responder. • A high level programming abstraction that supports dynamic adaptation for distributed application is provided (this one not even started yet!). • A solution to dynamically composing of aspects with conflicting behaviors is provided (is being tested).

32. References: • [CORBA-overview] http://www.cs.wustl.edu/ schmidt/corba-overview.html. • [Taxonomy] D. C. Schmidt, “Middleware for real-time and embedded systems,” Communications of the ACM, vol. 45, June 2002. • [TAO] D. C. Schmidt, D. L. Levine, and S. Mungee, “The design of the tao real-time object request broker,” Computer Communications, vol. 21, pp. 294–324, April 1998. • [DynamicTAO] F. Kon, M. Rom´an, P. Liu, J. Mao, T. Yamane, L. C. M. aes, and R. H. Campbell, “Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB,” in Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2000), (New York), April 2000. • [UIC] M. Roman, F. Kon, and R. H. Campbell, “Reflective middleware: From your desk to your hand.” IEEE Distributed Systems Online Journal 2(5), 2001. • [QuO] J. A. Zinky, D. E. Bakken, and R. E. Schantz, “Architectural support for quality of service for CORBA objects,” Theory and Practice of Object Systems, vol. 3, no. 1, 1997. • [IRL] C.Marchetti, L.Verde, and R.Baldoni, “Corba request portable interceptors: A performance analysis,” in the 3nd International Symposium on Distributed Objects and Applications (DOA 2001), (Rome, Italy), Sept. 2001. • [Eternal] L. Moser, P. Melliar-Smith, P. Narasimhan, L. Tewksbury, and V. Kalogeraki, “The eternal system: an architecture for enterprise applications,” in the 3rd International Enterprise Distributed Object Computing Conference (EDOC’99), July 1999.

33. References (cont.): • [TAO-LB] O. Othman, “The design, optimization, and performance of an adaptive middleware load balancing service,” Master’s thesis, University of California, Irvine, 2002. • [ZEN] R. Klefstad, D. C. Schmidt, and C. O’Ryan, “Towards highly configurable real-time object request brokers,” in Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, April - May 2002. • [MetaProgramming] N. Wang, D. C. Schmidt, O. Othman, and K. Parameswaran, “Evaluating meta-programming mechanisms for orb middleware,” IEEE Communication Magazine, special issue on Evolving Communications Software: Techniques and Technologies, October 2000. • [OpenORB] G. S. Blair, G. Coulson, P. Robin, and M. Papathomas, “An architecture for next generation middleware,” in Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’98), (The Lake District, England), September 1998. • [MetaSockets] S. M. Sadjadi, P. K. McKinley, and E. Kasten, “Metasockets: Run-time support for adaptive communication services,” in Proceedings of the International Symposium on Distributed Objects and Applications (DOA) (submitted for acceptance!), (University of California, Irvine, U.S.A.), November 2002. • [WOSS] Z. Yang, B. Cheng, R. Stirewalt, J. Sowell, S. Sadjadi, and P. McKinley. An aspect-oriented approach to dynamic adaptation. In Proceedings of Workshop On Self-healing Software, Nov. 2002.