Transcript Incorporating Fault Tolerance and Reliabilityin 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
– Autonomous functionality/ Behavior in Web Services
Challenges
Conclusion
Future Work
Recommendations
References
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 ServiceOriented 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.
Service Oriented Architecture
Web Services Repository
• In order to interoperate, each
service publishes its description,
which defines its interface and
1 Publicize
expresses constraints and
policies that must be respected
in order to interact with it.
• Discovery enables agents to
retrieve Web service-related
resource descriptions.
2
Discover
3 Use
Web Services
Provider
Web Services
Client
SOA roles
Service Oriented Architecture
Business
Workflow
Catalog and
Description
Web Services
WS1
WS2
Registry
Communications
...
HEADER
PAYLOAD
Document
Storage
Transports
HTTP
...
...
DBMS
SSL
OS
TCP/IP
processes
Web services layers
Supporting structures
SOA architectural layers.
memory
file system
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.
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
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
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.
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.
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, WSReliableMessaging and WS-Transaction standards were proposed.
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.
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.
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 selfmonitoring, self-diagnosis of faults, self-contained,
discoverable, self-adapting and self-repair properties
that is being sought currently.
Recommendations
• Suggestions/feedback:
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 649654, 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/NOTEws-arch-20040211/wsa.pdf, February 2004.