Exploring the Role of Software Architecture in Dynamic and Fault Tolerant Pervasive Systems

1. Exploring the Role of Software Architecture in Dynamic and Fault Tolerant Pervasive Systems Authors Chiyoung Seo1, Sam Malek1, George Edwards1, Daniel Popescu1, Nenad Medvidovic1, Brad Petrus2, and Sharmila Ravula3 Presenter Edward Gerhardstein

2. Introduction • The past few decades have witnessed a growth in size and complexity of software systems. • An emerging class of embedded and pervasive software system are growing in popularity. • Due to speed, cost, wireless networks, and handheld devices. • Software architectures provide abstractions for representing the • structure, behavior, and key properties of a software system.

3. Introduction • They are described in terms of • software components (computational elements), • connectors (interaction elements), • And their configurations. • Software architectural styles further refine the vocabulary of component and connector types and propose a set of constraints on how instances of those types may be combined in a system. • (e.g., publish subscribe, peer-to-peer, pipe-and-filter, client-server)

4. Introduction • For software architectural models to be truly useful in a development setting, they must be accompanied by support for their implementation. • With embedded and pervasive environments: The authors argue that an architectural middleware platform, which provides native implementation-level support for the key architectural abstractions, is better suited than traditional middleware platforms to address the software engineering challenges inherent in developing pervasive systems.

5. Introduction • Three key facilities are required for the development of fault tolerant pervasive systems: • (1) dynamic discovery of new services and resources, • (2) automated and transparent recovery from failure, and • (3) analytical determination of component replication strategies and deployment architectures. • We show that by making fault tolerance concerns explicit in the architectural models, we can analyze and improve the system’s resilience to unexpected failures. • We demonstrate that an architectural middleware can provide advanced fault tolerance facilities, while achieving efficiency and architectural clarity.

6. Introduction • This concept will be demonstrated through a family of fault tolerant sensor net works. • Section 2 provides an overview of a family of sensor network applications. • Section 3 presents a middleware platform that implements an architecture-based solution to fault tolerance in pervasive systems. • Section 4 discusses our support for service discovery. • Section 5 presents the facilities for recovering from failure. • Section 6 presents a tool-suite for exploring and analyzing a system’s QoS properties, including its fault tolerance. • Section 7 presents the related work. • Finally, the paper concludes with a brief discussion and overview of future work.

7. Application Scenario Figure 1. MIDAS system.

8. Application Scenario • MIDAS is composed of a large number of sensors, gateways, hubs, and PDAs that are connected wirelessly. • Many instances of MIDAS operate in safety-critical or regulated environments, in which a given event must be delivered to its recipients under all conditions. • The software system should support autonomic fail-over.

9. Application Scenario • One approach to providing fail-over support is through the replication of software components, and thus the services they provide. • However, component replication in MIDAS is difficult mainly due to its resource-constrained nature (i.e., limited CPU, memory, battery, network bandwidth, etc.). • The existing approaches for providing fault tolerance on traditional desktop platforms are often inefficient in this domain. • On top of this, given finite computing resources, components must be replicated selectively in order to achieve the maximum benefit. • At the same time, while replication can improve fault tolerance, other QoS properties can degrade due to the overhead of executing additional components and keeping replicas synchronized. • Finally, often the implementation complexity of advanced fail-over support (i.e., replication, synchronization, and recovery) and its coupling with the application logic

10. Architectural Middleware

11. Architectural Middleware • Prism-MW Is a middleware paltform that supports architecural abstrations by providing implementation-level modules for representing and manipulating each architectural element. • This enables direct mapping between an architecture and its implementation. • The shaded classes constitute the middleware core, a minimal subset of Prism-MW that enables implementation and execution of the architectures in a single address space.

12. Architectural Middleware • Core - a minimal subset of Prism-MW that enables implementation and execution of the architectures in a single address space. • Brick - represent the different architectural building blocks that are describe. • Architecture - records the configuration of its constituent components, connectors, and ports, and provides facilities for addition and removal. • Events - are use to capture communications • Request • Reply • Ports - are the loci of interaction • Request • Reply • Weld - is a link between two ports. • Components - perform computation and maintain their own internal state. • Connectors – are used to control the routing of events among the attached components

13. Architectural Middleware • Prism-MW design is intended to be extensible while keeping the core unchanged. • The core constructs are subclassed via specialized classes. • Each of which has reference to a number of abstract classes • Each abstract class can ave multiple implementations

14. Architectural Middleware

15. Service Discovery • Service discovery in the embedded and pervasive environments is a challenging problem. • 1) We typically do not know the location of a service provider at design-time. • 2) A service provider may become unavailable due to hardware, software and network failures. • 3) The location of a service provider may change at runtime.

16. Small Fragment of the Midas Architecture

17. Advantages of Service Discovery • Topology-based routing • Events are not tagged with a service provider; instead, they are routed based on topology and routing policies. • Separation of concerns • Application logic is completely separated from the services discovery protocol and its nuances • Efficiency • By leveraging connectors, we are able to minimize the number of required ports. • Scallability • Service lookup is perform in a hierarchical manner • A service lookup request is done locally first and the if not found then globally.

18. Replication and Failover Facilities • Two types of replications • Active replication. Each replica of a service provider processes a service request event and rturns a response to the client. Duplication detection is necessary for the client to receive only one response. • Passive replication. Only one of the replicas, selected as primary replica , processes a request event and sends a response to the client. • Warm passive replication, the remaining backup replicas are synchronized periodically with the primary replica’s state • Cold passive replication, a backup replica is loaded into memory and its state initialized from a log only if current primary replica fails.

19. Replication and Failover Facilities • Advantages • Efficiency • Each request event is routed to the connector attached to a global service provider for backup. All the replicas receive the same sequence of request event • Extensibility • A global service provider can simple send its state periodically to all its backups. • Flexibility • Addition and removal of replication support can easily achieved at the architecture level by addition or removal of an connector

20. Replication and Deployment Analysis • The system components have varying degrees of reliability, and the replication of a highly reliably component provides less benefit than the replication of an unreliable component. • Each component can collaborate with other components in multiple system use cases. • The system hardware can fail and the performance and availability of the wireless network is unpredictable. • Once a component has been identified as a candidate for replication, a node must be selected for the replica’s deployment, taking into consideration the computational resources required and those available at each host. • The final element of our integrated fault tolerance strategy is the determination of component reliabilities, which impact heavily the replication and deployment algorithms, and ultimately the effectiveness of the runtime service discovery and failover support in Prism-MW.

21. Related Work • ArchJava is an extension to Java that unifies software architecture with implementation, ensuring that the implementation conforms to architectural constraints • Orbix/E is a lightweight CORBA ORB optimized fro embedded applications. • XMIDDLE is a data-sharing middleware for mobile computing (encoded as XML) • MobiPADS is reflective middleware that supports both active deployment of augmented services for mobile computing and dynamic adaptation for providing flexible configuration of resources

22. Conclusions • The development of fault tolerant software systems in pervasive environments is a challenging task. The complexity of providing advanced fault tolerance facilities, such as component replication, replica synchronization, and failover, often results in rigid and unmanageable applications. • This represented a novel approach to modeling and implementing fault tolerance facilities at the architectural level. • This approach results in a separation of application logic from fault tolerance logic, which in turn aids the construction, analysis, and adaptation of the software system. • We have leveraged these characteristics to quantitatively analyze various replication and deployment strategies., • One of the current shortcomings is the lack of fault tolerance support for middleware-level components potentially resulting in single points of failure.

23. Acknowledgement • This work is sponsored in part by the National Science Foundation under Grant number ITR-0312780 and by Bosch Research and Technology Center.

24. References • [1] J. Aldrich, et. al. ArchJava: Connecting Software Architecture • to Implementation. ICSE 2002, May 2002. • [2] A. Chan, et. al. MobiPADS: A Reflective Middleware for • Context-Aware Mobile Computing. IEEE Transactions on • Software Engineering, Vol. 29, No.12, December 2003. • [3] G. Edwards, et. al. Scenario-Driven Dynamic Analysis of • Distributed Architectures. FASE 2007, March 2007. • [4] Orbix/E. http://www.iona.com/whitepapers/orbix-e-DS.pdf • [5] E. A. Lee. Embedded Software. Advances in Computers • (Marvin V. Zelkowitz, ed.), Academic Press, London, 2002. • [6] LIME http://lime.sourceforge.net/ • [7] S. Malek, et. al. A Style-Aware Architectural Middleware for • Resource Constrained, Distributed Systems. IEEE Transactions • on Software Engineering. March 2005. • [8] S. Malek, et. al. Reconceptualizing a Family of Heterogeneous • Embedded Systems via Explicit Architectural Support. • IEEE Int’l Conf. on Software Engineering, May 2007. • [9] C. Mascolo et. al. XMIDDLE: A Data-Sharing Middleware • for Mobile Computing. Personal and Wireless Communications, • Kluwer. • [10] N. Medvidovic, et. al. A Family of Software Architecture Implementation • Frameworks. WICSA 2002, Aug. 2002.

25. References • [11] M. Mikic-Rakic, et. al. A Tailorable Environment for Assessing • the Quality of Deployment Architectures in Highly Distributed • Settings. CD 2004, Edinburgh, Scotland, May 2004. • [12] L. E. Moser, et. al. Totem: A fault-tolerant multicast group • communication system. Comms. of the ACM. April 1996. • [13] P. Narasimhan, et. al. State Synchronization and Recovery for • Strongly Consistent Replicated CORBA Objects. DSN 2001, • July 2001. • [14] P. Narasimhan, et. al., Eternal-A Component-based Framework • for Transparent Fault-Tolerant CORBA. Software • Practice and Experience, Vol. 32, pp. 771-788, 2002. • [15] D.E. Perry, et. al. Foundations for the Study of Software Architectures. • Software Engineering Notes, Oct. 1992. • [16] D. Popescu. Framework for Replica Selection in Fault-Tolerant • Distributed Systems. Tech. Report USC-CSSE-2007-702, • 2007. • [17] R. Roshandel, et. al. Estimating Software Component Reliability • by Leveraging Architectural Models. ICSE 2006, May • 2006. • [18] M. Shaw and D. Garlan. Software Architecture: Perspectives • on an Emerging Discipline. Prentice Hall, 1996. • [19] M. Shaw, et. al. Abstractions for Software Architecture and • Tools to Support Them. IEEE Trans. on Software Engineering, • April 1995. • [20] J. P. Sousa, et. al. Aura: an Architectural Framework for User • Mobility in Ubiquitous Computing Environments. WICSA • 2002, Montreal, August 2002.