A Fault Taxonomy for Service-Oriented Architecture

Abstract

Service-Oriented Architecture (SOA) is a popular design paradigm for distributed systems today. Its dynamics and loose coupling are predestined for self-adaptive systems. This adaptivity and complexity, however, opens many chances for a failure. Therefore, a clear understanding of the kinds of faults that may occur is necessary for detection, tolerance, and testing, e.g. by fault injection. For this purpose, we present a fault taxonomy for service-oriented architecture. Starting with a definition of service and SOA, we describe and analyze different structures and the process of service invocation with a five step model. Furthermore, we describe possible faults and define SOAspecific faults as a new fault class that extends the known fault set for distributed systems. The application of our fault taxonomy is demonstrated with the use case of an online airline reservation system. We conclude with the benefits of our fault taxonomy for designing and testing SOA-based systems.

Deriving a unified fault taxonomy for event-based systems

“…Fault taxonomies for service-oriented architecture (SOA) have been discussed in [11] and [14]. The taxonomies are tailored to issues related to service-based computing and Web services (e.g., service discovery, binding, or composition), whereas we focus on specifics of event-based systems.…”

“…This has led to comprehensive surveys and taxonomies for very specific types of faults, including program and operating system faults [3], faults in object-oriented software [10], faults in service-based applications [11,14], faults in memory devices [70], or faults in microprocessor design [4]. Event processing, as an emerging research direction, is yet lacking a common model for faults.…”

A Novel Approach for Exception Handling in SOA

“…They provide a set of fundamental rules, exception categories and strategies. Stefan Bruning, Stephan Weileder and Miroslaw Malek introduce fault taxonomy for a systematic description of possible faults in SOA and show how they relate to each other [6]. This knowledge is essential for building dependable systems as well as for testing the system via fault injection.…”

Expressive Exceptions for Safe Pervasive Spaces

“…Note that the input parameter e is used twice in the description, and both occurrences of e match the same situation description. However, they can represent different instantiations, e [1]and e [2], if necessary. In addition, it embeds the repetition of e in "(#T < t ; e)*," so that e [2] …”

“…The last two types of events enable access to the execution status of an operation (action) through the properties of an event. Parameters can be actual values or formal variables, but for simplicity, 1 Reserved words are in typewriter font, and reserved symbols are underlined,while other symbols denotegrammaticalconstruction. 2 We will omit the word "pattern" in the name of this grammar symbol to avoid lengthy symbol names.…”