1. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE Why Current Middleware Fails for Mobile Peer-to-Peer Computing Thomas Kunz Systems and Computer Engineering Carleton University http://kunz-pc.sce.carleton.ca tkunz@sce.carleton.ca Abdulbaset Gaddah Joint work with Abdulbaset Gaddah, Ph.D. candidate

2. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 1 Agenda Background Traditional Middleware Requirements for Middleware for Mobile Applications Survey/Evaluation of Mobile Middleware Paradigms Conclusions and Future Work

3. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 2 Background We have explored issues related to mobile applications since 1997: WWW transcoding proxy Mobile code for adaptive mobile applications Now: how to incorporate our ideas into middleware for mobile applications What middleware? What extensions? Detailed report available from the WWW, http://www.sce.carleton.ca/wmc/middleware/

4. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 3 Middleware Definition: a layer of software that allows peers to interact a cross a network Context: distributed systems Role: coordination and communication (connectivity software) Implements: session and presentation layers Bonus: higher level primitives Applications Applications interfaces Middleware Local Operating System Hardware Platform

5. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 4 Traditional Middleware Requirements Network communication Support marshalling and unmarshalling Provide higher level primitives Coordination Components synchronization Components activation and deactivation Reliability Processing individual and multiple requests Support Fault-tolerant and different levels of QoS Scalability Load Balancing (transparent replication, access, and migration) Heterogeneity Integrate elements from various contexts Support interoperability

6. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 5 Current Middleware Solutions Model Network Communication CoordinationReliabilityScalabilityHeterogeneity Client requests are grouped into transactions Through synchronous and asynchronous methods. Support for activation policies Fault-tolerant due to DTP and 2 phase commit protocol. Support for transactions Support load balancing & replication of server components Component heterogeneity supported but no support for data heterogeneity Through Notification, Request and Reply messages. Content includes information Asynchronous message delivery. More scalable and easy broadcast but difficult for synchronous requests Fault-tolerance implemented using message queues Not scalable as no support for transparent replication, access & migration No support for heterogeneity either Transactional Message-oriented

7. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 6 Current Middleware Solutions (Cont.) Model Network Communication CoordinationReliabilityScalabilityHeterogeneity Marshalling and unmarshalling of procedure calls into messages by the stubs and messages sent to hosts where server reside Synchronous interactions between exactly one client & server. Support for activations At-most once semantics are only supported Limited Scalability as no replication mechanisms Heterogeneity of components and data supported Client objects can request execution of a server objects operation and client object has object reference of server object Mainly synchronous, but others supported. Also support activation policies Default is at- most once but others also supported Support for transactions too Still limited scalability as very limited replication support They support both kinds of heterogeneity Procedural Object-oriented

8. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 7 Challenges of Mobile P2P Computing Network condition: slow, expensive, disconnected, limited bandwidth, high error rate Mobile devices: limited resources and high diversity Physical mobility: different networks and services Internet Internet SlowNet ExpensiveNet Fast Net

9. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 8 An Electronic Shopping System: A Case Study Transparent replication: Application cannot influence the replication decision Location awareness: collecting my order on my way home Dynamic reconfiguration: interacting with servers running different middleware platforms Adaptivity: overloaded server (switching) image/video requested (filtration) Asynchronous: Clients are not blocked during the matching process or receiving notification receipt. PPC Laptop PC E-commerce Site

10. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 9 Requirements for Next Generation Middleware Dynamic Reconfiguration Detect changes in available resources and reallocate them or notify the application to change its behaviour Adaptivity The ability of a system to recognize unmet needs within its execution context and to adapt itself to meet those needs Context-Awareness Disclose the execution context to the upper layer. The context may include device characteristics, users activities, and services Asynchronous Paradigm Decouple the client and server components and deliver multicast messages Lightweight Minimum range of functionality used by most applications

11. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 10 Middleware State of the Art Reflective Middleware Reflection approach to support inspection and adaptation Examples: OpenCorba, Open-ORB, and DynamicTAO Tuple Spaces Middleware Tuple space approach to facilitate communication Examples: LIME, TSpaces, and JavaSpaces Context-Aware Middleware Awareness approach to expose the context information Examples: Nexus, Alternis, and SignelSoft Event-based Middleware Event notification approach to support large-scale systems Examples: Hermes, CEA, and JEDI

12. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 11 Requirements Addressed by Various Categories RequirementsReflective Tuple Spaces Context- Aware Event- based Synchronous/ connection based XX Asynchronous/ connectionless XX Reconfiguration X Adaptation XX Awareness XX Heavy weight XXX

13. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 12 Conclusions We have presented current middleware solutions and exhibited their characteristics Why traditional middleware systems fail to support mobile settings We have outlined a set of requirements for next generation middleware We have illustrated the state of the art of middleware for mobile computing and discussed four different classes of middleware We have shown what type of requirements are addressed by each class of middleware

14. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 13 Next Steps Better understand mobile application requirements and device/network constraints for specific application domains Select a specific middleware paradigm, experiment with sample system it in our testbed (iPaq/laptop/PCs, IEEE 802.11b wireless LAN and Bluetooth) Suggest and develop appropriate enhancements, based on our prior work

15. UNCLASSIFIED – APPROVED FOR PUBLIC RELEASE 14 Thank you Questions & comments