1 / 16

Incorporating Fault Tolerance and Reliability in Software Architectures

Incorporating Fault Tolerance and Reliability in Software Architectures. Ingrid Buckley 01/15/09. Agenda. Introduction Service Oriented Architecture Motivation Problem Related Work & Approaches RobustBPEL Using Fault Tolerance measures in software Architecture

Download Presentation

Incorporating Fault Tolerance and Reliability in Software Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Incorporating Fault Tolerance and Reliabilityin Software Architectures Ingrid Buckley 01/15/09

  2. Agenda • Introduction • Service Oriented Architecture • Motivation • Problem • Related Work & Approaches • RobustBPEL • Using Fault Tolerance measures in software Architecture • Autonomous functionality/ Behavior in Web Services • Challenges • Conclusion • Future Work • Recommendations • References

  3. Introduction • The Software Architecture (SA) of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. • A service is a function or method that does some particular action. • Web services are software components defined by their interfaces that can be accessed on the Internet and incorporated into applications. • The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is required. • Web services are a realization of a more abstract architectural style called Service-Oriented Architecture (SOA). • Service-Oriented Architecture (SOA) has been considered to be the new phase in the evolution of distributed system applications. • We define SOA as an architectural style in which a system is composed from a set of loosely coupled services that interact with each other by sending messages.

  4. Service Oriented Architecture • In order to interoperate, each service publishes its description, which defines its interface and expresses constraints and policies that must be respected in order to interact with it. • Discovery enables agents to retrieve Web service-related resource descriptions. SOA roles

  5. Service Oriented Architecture SOA architectural layers.

  6. Motivation • SOA could enable the design and realization of flexible and extensible applications which span across multiple organizations. • SOA has promised to provide enterprises with modular, reusable and easily extensible architectures that would enable them to adapt their applications easily so that they remain competitive and compliant. • Even though there is a common acceptance of this concept, a real problem hinders the widespread use of SOA: • A methodology to design and build secure service-oriented applications is needed.

  7. Problem • How to achieve greater usage of the Service Oriented Architecture by making it more dependable. • How to achieve reliable and fault tolerant web services • The following properties must be added to the SOA : • Reliability • Fault Tolerance

  8. Using Fault Tolerance tactics in Software Architecture Approach • The study was done on the impact of incorporating fault tolerance tactics into system architecture that use architectural patterns. • Primarily for Legacy systems and already existing systems but can be used for green systems. • Fault Tolerance tactics employed – detection, recovery( preparation, repair, reintroduction and prevention • Ten architectural patterns including Client-Server, Broker, Layers, Model View, Pipes and Filters were used. • An impact scale was mapped from easy, neutral, trivial and difficult to show which of these patterns are easily changed to include fault tolerance into the system architecture. • Useful in giving a cost analysis of the comparative amount of work required to add fault tolerance to existing systems

  9. RobustBPEL Approach • This study looked at a language-based approach to address reliability in the business layer. • RobustBPEL is a part of the transparent shaping programming model • A composite web service defined as a BPEL process is instrumented automatically to monitor its partner web services at runtime. • Events such as faults and timeouts are monitored from within the adapted process. • This adapted process is augmented with a proxy that dynamically replaces failed services. • They assert that this will improve fault tolerance and performance of BPEL processes by transparently adapting their behavior. • Transparency is achieved by using a dynamic proxy. • No change is made to the BPEL engine.

  10. Autonomous functionality in Web Services Approach • This study is primarily geared at high availability of long running web services by extending the Web Services Architecture. The following new components were proposed: • Component Health Monitoring (CHM) module represents a new service used to track the health of individual Web Services components. basically a failure detection service. • Consistent and Reliable Messaging (CRM) a simple optimized group communication layer, limited to small groups that use virtual synchrony for replication. • Data Dissemination (DDS) module provides ‘reliable’ multicast-style data streaming from the Web Services platform to a potentially large number of clients that must link directly to the DDS protocol. the DDS framework standardizes such notions as joining a group, sending a message, and delivering a message, but offers plug-in flexibility with respect to the actual properties of the protocol.

  11. Autonomous functionality in Web Services Approach • Monitoring, Distributed Control (MDC) component responds to the need for mechanisms capable of monitoring and managing the entire system, by tracking performance metrics and other state variables and reporting them out [Bir04]. • Event Notification (EVN) is last major component proposed and is still at an early design stage. EVN service focuses on urgent, small, one-time events. They have a notion of using some form of distributed query processing, in which the components of a Web Services system are treated as small Databases that can be queried [Bir04]. • These five new components along with the use of the WS-Reliability, WS-ReliableMessaging and WS-Transaction standards were proposed.

  12. Challenges • Difficult to address reliability and fault tolerance in collaborating webs services in multiple application scenarios. • Multiple services developed and maintained on different environments introduce new levels of complexity. • Unreliable communication channels • Long running composite web service applications • If the architecture of system already exist, thus it is difficult to make substantial changes • Cost of incorporating fault tolerance into a system • Given the architecture used in a system, which patterns are easier to maintain and adjust when necessary. • May Become too complex if one extends the Web Services architecture to include autonomous functionality. • In extending the SOAn by adding new layers and frameworks, may introduce additional vulnerabilities to the architecture. • May affect the robustness of the architecture.

  13. Conclusion • In sum a lot of work is being done to achieve reliability and fault tolerance in web services, however analysis of some these approaches show that they can introduce undesirable consequences such as increase in overall cost, complexity and maintenance. • The use of patterns can be useful in adding reliability and fault tolerance to the Service Oriented Architecture. • Reliability Patterns - WS-ReliableMessaging and WS-reliability • Fault Tolerance Patterns – Acknowledgement and Active Replication • Look into the feasibility of extending the SOA framework to make it more dependable. • It’s not enough to have a dependable SOA but also to design secure and dependable web services applications. • Systematic methodology that can be used to aid designers in building dependable web services.

  14. Future Work • Look into designing a methodology to implement fault tolerance, reliability and autonomous functionality into the framework of the Web Services Architecture. • “Autonomous” Webs Services supports reliability, as such we can develop patterns that describes the “big picture” general properties which include self-monitoring, self-diagnosis of faults, self-contained, discoverable, self-adapting and self-repair properties that is being sought currently.

  15. Recommendations • Suggestions/feedback:

  16. References • [Bir04] Ken Birman, Robbert van Renesse and Werner Vogels. Adding High Availability and Autonomic Behavior to Web Services. Proceedings of 26th International Conference on Software Engineering (ICSE’04).2004. • [Eze08] Onyeka Ezenwoye and S. Masoud Sadjadi. A language-based approach to addressing reliability in composite web services. In Proceedings of the 20th International Conference on Software Engineering and Knowledge Engineering (SEKE'2008), pages 649-654, San Francisco Bay, USA, July 2008. • [Har08] Neil B. Harrison and Paris Avgeriou. Incorporating Fault Tolerance Tactics in Software Architecture Patterns. Proceedings of ACM. SERENE 2008. NewCastle, UK, November 17-19,2008. • [W3c04] David Booth, et al. Web Services Architecture. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/wsa.pdf, February 2004.

More Related