1. ONR Review – June 11, 2003 RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Philip McKinley, Kurt Stirewalt, Betty Cheng, Laura Dillon, Sandeep Kulkarni Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University (http://www.cse.msu.edu/sens)

2. Software Engineering and Network Systems Laboratory Motivations  Increasingly, distributed software must interact with both the physical environment and its execution environment  Mobile computing software must adapt to dynamic conditions in several cross-cutting concerns: –Quality of Service –Platform characteristics –Security –Energy Consumption –Fault Tolerance  How to support run-time adaptive behavior not envisioned during development?

3. Software Engineering and Network Systems Laboratory RAPIDware Project Goal...  Develop adaptive middleware technologies that enable users to communicate seamlessly and securely across a diverse, dynamic, and evolving mobile computing and communication infrastructure.  Target domain is collaborative computing –military command and control –crisis management systems –management of military/industrial installations –computer supported cooperative work  The methods investigated can be applied to many other domains

4. Software Engineering and Network Systems Laboratory Key Issues  Separation of Concerns –Separating adaptive software functionality from the imperative code  Adaptation Assurance –Guaranteeing that adaptations do not change the imperative behavior of the application in unexpected ways  Migration Path for Development –Support adaptation through existing and new development paradigms.

5. Software Engineering and Network Systems Laboratory Separation of Concerns  Can adaptive behavior in “non-functional” concerns be separated from the (functional) application code?  Doing so can facilitate the development, operation, and maintenance of adaptive systems  How to implement “tradeoffs” among concerns –control changes in communication quality of service –manage energy consumption in battery-powered devices –provide fault tolerance according to specifications –actively monitor the system, execute security policies

6. Software Engineering and Network Systems Laboratory Separating Adaptive Behavior

7. Software Engineering and Network Systems Laboratory Adaptation Assurance Issues  Do reconfigured components compose properly?  When is it “safe” to adapt the system without incurring negative side effects?  How can new software components be introduced to the system in a secure manner?

8. Software Engineering and Network Systems Laboratory Assurance Issues  How to support synchronization and atomicity during recomposition  Use of ``certified components’’  How to define and reach safe points  System-wide integrity –Feature interaction –Global/system invariants

9. Software Engineering and Network Systems Laboratory Migration Path  Complexity of adaptive software is high  Different types of developers: –Application developers –Adaptation developers  Support existing programming models  Transition to new programming techniques/languages/paradigms

10. Software Engineering and Network Systems Laboratory Approaches to Software Adaptation  Middleware-based adaptation  Context-aware adaptation

11. Software Engineering and Network Systems Laboratory RAPIDware Activities Assurance in Adaptation Models DesignCorrectness Empirical Theoretical AOP Reflection Syntactic Contracts Semantic Contracts Patterns

12. Software Engineering and Network Systems Laboratory New Ideas  Separation of concerns in adaptive software  Extracting adaptive software functionality from the imperative code  Codifying interactions among concerns  Adaptation assurance in recomposable software  Integrity in recomposition (synch., state maint.)  Safe adaptation points  Syntactic and semantic contracts to govern adaptation  Migration path for development  Design abstractions that can be realized in existing software development methods  Same abstractions can lead to new paradigm for developing adaptive software RAPIDware Component-Based Development of Adaptable and Dependable Middleware Impacts  Self-healing systems to support mission-critical communication and computation, despite highly dynamic environmental conditions.  Self-auditing systems that can report and respond automatically to security threats and component failures.  Principled approaches to design of high-assurance adaptable software for use in both military and commercial environments.  What else??? Schedule  Years 1 and 2:  Baseline studies on adaptability in mobile computing  Theoretical models for (re)compositon and FT  Design approaches using AOP, reflection, patterns  Assurance: synchronization, safe adaptation  Year 3:  Feature interaction analysis and software support  Decision-making design and experiments  Year 4:  Year 5:

13. Software Engineering and Network Systems Laboratory This page intentionally left blank.

14. Software Engineering and Network Systems Laboratory Models DesignCorrectness RAPIDware Activities: 1.Models 2.Design 3.Correctness

15. ONR Review – June 11, 2003 Empirical Studies in Mobile Computing P. K. McKinley

16. Software Engineering and Network Systems Laboratory Mobile Computing Testbed  Multiple-cell WLAN –802.11b (for now) –WLAN analyzers –Dual-processor proxies  Mobile computers –Dell laptops (Windows and Linux) –iPAQ handhelds (Familiar Linux, Blackdown Java) –Xybernaut MA-V wearables (Windows)

17. Software Engineering and Network Systems Laboratory Our Approach  Collect baseline results to quantify tradeoffs among QoS, energy consumption, security, etc.  Translate these results into rules for dynamic adaptation  Focus thus far on communication-related tasks  “MetaSockets” –An adaptable communication component developed in Adaptive Java (discussed later) –Can be used directly by applications or by other middleware layers

18. Software Engineering and Network Systems Laboratory Adaptive Java Background  Three-Dimensional Interfaces: –Invocations: normal component imperative operations. –Refractions: operations for inspecting components. –Transmutations: operations for modifying components.  Component Absorption and Metafication: send() close() joinGroup() send() close() insertFilter() removeFilter() getStatus() receive() base-level invocation send() close() transmutation refraction leaveGroup() base-level method replaced invocation Java MulticastSocket AJ SendMSocket Base Component AJ MetaMulticastSocket

19. Software Engineering and Network Systems Laboratory MetaSockets  Provide low-level, adaptable communication  “Host-infrastructure” middleware (Schmidt) MetaSockets Operating system JVM Middleware Application Code Operating system JVM Higher-Level Middleware Application Code Adaptive Communication Functionality

20. Software Engineering and Network Systems Laboratory Example MetaSocket Architecture get() put() send() close() Filter Pipeline put() get() receive() joinGroup() close() Filter Pipeline send() close() receive() joinGroup() leaveGroup() close() getStatus() insertFilter() removeFilter() insertFilter() removeFilter() FP LP Fltr MT SS LP FP Fltr MT RS invocation refraction transmutation FP : firstPacketBuffer SS : SendMSocket dependency packet flow direction RS : RecvMSocket LP : lastPacketBuffer Fltr : Filter MT : MetaSocketThread thread MetaSendMSocket Internal Architecture: MetaRecvMSocket Internal Architecture:

21. Software Engineering and Network Systems Laboratory Typical MetaSocket Experiment  Audio Streaming Application (ASA) –MetaSocket is used instead of MulticastSocket –Live audio stream from a desktop to multiple iPAQs –Physical experiment configuration: Access Point Wireless Receivers Audio Stream Wired Sender...

22. Software Engineering and Network Systems Laboratory Wired Network Wireless Network Trader Filter Pipeline Component Loader (CL) Decision Maker (DM) Player Event Mediator (EM) LP FP MT RS PB AL NL FD FP: firstPacketBuffer AL: RecvAppLossDetector RS: RecvMSocket LP: lastPacketBuffer PB: PacketBuffer FD: FECDecoder refraction or transmutation invocation thread MT: MetaSocketThread NL: RecvNetLossDetector Dependency Reflection Event propagation ASA Component Interaction

23. Software Engineering and Network Systems Laboratory ASA Components  Decision Maker: a optional component that controls all the non-functional behavior of the subcomponents in its container component, according to its rule-base.  Component Loader: a unique component in an address space that loads components from a trader, according to a set of policies.  Trader: a server that works as yellow pages and replies to component requests.  Event Mediator: Supports asynchronous interaction among decoupled components using a publisher- subscriber pattern.  Player: plays the incoming audio stream.

24. Software Engineering and Network Systems Laboratory WLAN Error Characteristics  Most burst errors are very short  Small packets help to isolate errors  Well suited to use of block-based FEC

25. Software Engineering and Network Systems Laboratory  Wireless networks produce dynamic and location dependent packet loss because of signal strength, interference, antenna alignment.  802.11b MAC layer does not provide link-level acknowledgement for multicast frames.  FEC can be used to improving reliability by introducing redundancy into the data channel. Block Erasure Code Operation

26. Software Engineering and Network Systems Laboratory  MetaFECEncoder: a component in AJ that absorbs a FECEncoder class.  MetaFECDEcoder: a component in AJ that absorbs a FECDecoder class. Forward Error Correction Filters invocationrefraction transmutation FE: FECEncoder dependency event propagation path thread (a) MetaFECEncoder start() stop() setSrcPacketBuffer() setDstPacketBuffer() setNK() FE getSrcPacketBuffer() getDstPacketBuffer() getNK() start() stop() setSrcPacketBuffer() setDstPacketBuffer() setNK() FD` getSrcPacketBuffer() getDstPacketBuffer() getNK() FilterMismatchEvent FECMismatchNKEvent FD: FECDecoder (b) MetaFECDecoder

27. Software Engineering and Network Systems Laboratory Performance (Emulated Losses)  FEC Filters inserted automatically at time 8, when loss rate exceeds 30%.  FEC Filters removed automatically at time 45, when loss rate drops below 10%.  Inserted again at time 60.  Removed again at time 80.

28. Software Engineering and Network Systems Laboratory Performance (Real Losses)  Insert threshold: 10%  Remove threshold: 1%

29. Software Engineering and Network Systems Laboratory Energy Management Baselining  Multimeter connected to iPAQs  Audio/video/data streams across wireless LAN  Measure energy usage, vary FEC parameters

30. Software Engineering and Network Systems Laboratory Effect of FEC Parameters  Reception of parity packets (plus decoding) is major consumer of energy  Reference point: system shutdown at 860 mV

31. Software Engineering and Network Systems Laboratory Software measurements…  Dynamically measure remaining battery life during earlier experiment  Periodically read from /proc/hal/battery

32. Software Engineering and Network Systems Laboratory MetaSocket Filter Delay (iPAQs)  Delay can be significant, largely due to thread synchronization in JVM  Some tasks (encryption) too slow for real-time streaming on these iPAQs  Others (FEC decoding, loss monitoring) can keep up with real-time audio

33. Software Engineering and Network Systems Laboratory Current Activities  Decision-making software: –Tradeoffs among QoS, energy, security, FT –Event/Rule based approach –Hierarchical discriminant regression (HDR)  Using MetaSockets to support higher level middleware  Investigations of “safe” adaptation

34. Software Engineering and Network Systems Laboratory Related Work...  Adaptive Middleware –TAO, 2K/Gaia, QuO, MCF, MOST/ADAPT, CEA, CompOSE|Q, MOOSCo, DaCapo++, MASH/Ninja, Rover, Odyssey, MobiWare, etc.  PCL (Adve, et al.)  Composition filters (Aksit, et al.)  AOP (Kiczales), COOL (Lopes),...  GenVoca (Batory)

35. Software Engineering and Network Systems Laboratory Conclusions, Future Directions  Conclusions: –Experiments show that MetaSockets are an effective means to QoS-oriented adaptation.  Future Directions: –A MetaSocket is only one type of adaptable components. Any AJ component can be metafied and adapted at run time. –Other cross-cutting concerns (security, power consumption, and fault-tolerance) can be addressed with AJ components.

36. Software Engineering and Network Systems Laboratory Further Information  Project descriptions and related papers of the Software Engineering and Network Systems (SENS) Laboratory are available at:  RAPIDware project: www.cse.msu.edu/rapidware  Email contact: mckinley@cse.msu.edu http://www.cse.msu.edu/sens

37. Software Engineering and Network Systems Laboratory This page intentionally left blank.

38. Software Engineering and Network Systems Laboratory RAPIDware Activities: 1.Models 2.Design 3.Correctness Models Design Correctness

39. ONR Review – June 11, 2003 Computational Reflection and Adaptive Java E. P. Kasten and P. K. McKinley

40. Software Engineering and Network Systems Laboratory Origins of Adaptive Java  Many adaptive middleware approaches involve computational reflection –ability of a process to reason about (and possibly alter) its behavior  Key issue: Openness vs. Preemption  Adaptive Java provides language-level support for adaptability that separates introspection and intercession.  Maes’ original work did not necessarily intertwine these two functions, although most contemporary works do so.

41. Software Engineering and Network Systems Laboratory Reflection  Base-level program is augmented with one or more meta levels  Entities at a meta level are called meta-objects  Meta-object protocol (MOP): collection of interfaces provided  Different MOPs may be defined for different cross-cutting concerns: performance, fault- tolerance, security, etc.

42. Software Engineering and Network Systems Laboratory One possible view...  MOPs are constructed from primitive atoms that provide access to component behavior  May facilitate coordination, consistency- checking, and extension of MOPs

43. Software Engineering and Network Systems Laboratory “Orthogonality”  Instead of considering orthogonal MOPs, we assume that they may intersect  We do consider orthogonal dimensions of accessing component behavior:

44. Software Engineering and Network Systems Laboratory Components in Adaptive Java  Can be considered as objects that have been “wrapped” in a meta layer that provides: –invocations: provide access to imperative functionality (base methods) –refractions: operations to observe internal structure and behavior –transmutations: operations that modify computational behavior  Encapsulation (rather than inheritance) is the principle mechanism to support dynamic composition

45. Software Engineering and Network Systems Laboratory Component Interfaces

46. Software Engineering and Network Systems Laboratory Role of Encapsulation  Encapsulation (rather than inheritance?) is the principle mechanism to support dynamic composition  We can view composition as parameterization of one component with another (GenVoca). E.g., –S = G[F] –system S is composed of component G parameterized by F

47. Software Engineering and Network Systems Laboratory Absorption and Metafication  Absorption: Turning a base-level class into a base- level component, redefining computational interface with (mutable) invocations  Metafication: run-time creation of refractive and transmutative interfaces on a component (and so on)

48. Software Engineering and Network Systems Laboratory Adaptive Java Implementation  Language extensions developed to support the functionality described above  Adaptive Java 1.0 implemented with source- to-source translation, using CUP parser  Invocations, refractions, and transmutations are all converted into Java classes, which are accessed via a hash map.  Eventually, we may re-implement Adaptive Java as a compiled language, possibly requiring support from the JVM

49. Software Engineering and Network Systems Laboratory Basic Component Structure  Similar to Java class  Can also extend existing components /* A simple component */ component BasicComponent { /* Constructor */ public BasicComponent() {... } /* Invocation */ public invocation void method1(String arg) {... }. }

50. Software Engineering and Network Systems Laboratory Absorption Example: RecvSocket /* receive-only socket component */ public component RecvSocket absorbs Socket { /* constructor */ public RecvSocket(int port, String group, byte ttl) throws UnknownHostException, IOException { setBase(new Recv(port, group, ttl)); }...

51. Software Engineering and Network Systems Laboratory Absorption (cont.) public invocation void receive(DatagramPacket p) throws IOException { base.receive(p); } public invocation void close() throws IOException { base.close(); }

52. Software Engineering and Network Systems Laboratory Metafication /* Meta receive-only socket component */ public component MetaRecvSocket metafy RecvSocket{ /* Constructor */ public MetaRecvComponent(int port, String group, byte ttl) throws UnknownHostException, IOException { setBase(new RecvComponent(port, group,ttl)); }

53. Software Engineering and Network Systems Laboratory Example Transmutation /* Transmutation that sets the data stream compression level. */ public transmutation void SetCompression(int level) {. }

54. Software Engineering and Network Systems Laboratory Example Refraction /* Refraction that returns the observed bytes transferred by the RecvSocket component. */ public refraction long GetBytesXmit() {. return bytes_transfered; }

55. Software Engineering and Network Systems Laboratory Models  Empirical Models –Baseline experiments on mobile computing testbed –Quantify tradeoffs among aspects in current systems  QoS, energy, security, fault tolerance, platform  Theoretical Models

56. Software Engineering and Network Systems Laboratory MetaSocket Absorption Code public component SendMSocket absorbs java.net.MulticastSocket { /* constructor */ public SendMSocket(...) { setBase(new java.net.MulticastSocket(...)); } /* invocations */ public invocation void send(...) { base.send(...); } public invocation void close() { base.close(); } }

57. Software Engineering and Network Systems Laboratory MetaSocket Metafication Code public component MetaSendMSocket metafy SendMSocket { /* constructor */ public MetaSendMSocket(SendMSocket sendMSocket) { setBase(sendMSocket); } /* invocation that "replaces" the send() invocation in SendMSocket */ public invocation void send(...) {... firstPacketBuffer.put(packet);... } /* refractions */ public refraction byte[] getStatus() { return filterPipeline.getStatus(); } /* transmutations */ public transmutation void insertFilter(int position, Filter filter) {... filterPipeline.add(position, filter);... } public transmutation Filter removeFilter(int position) {... return filterPipeline.remove(position); } /* private fields */ private java.util.Vector filterPipeline = new java.util.Vector(); PacketBuffer firstPacketBuffer = new PacketBuffer(); }

58. Software Engineering and Network Systems Laboratory Summary  Summarize AJ

59. Software Engineering and Network Systems Laboratory Issues  From survey

60. Software Engineering and Network Systems Laboratory Ongoing Subproject: Perimorph