Nest: a nested-predicate scheme for fault tolerance

Laranjeira, Luiz A.; Malek, Miroslaw; Jenevein, Roy M.

doi:10.1109/12.247836

Cited by 13 publications

(3 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In literature about distributed systems, the focus is usually set on one kind of fault: hardware, software, or network. Cristian [4] proposed a fault taxonomy for computer systems which was extended by Laranjeira et al [5] and applied to parallel and distributed systems. Hayes [6] developed a fault taxonomy for the NASA used in the development for the ISS project.…”

Section: Related Workmentioning

confidence: 99%

A Fault Taxonomy for Service-Oriented Architecture

Sun

Hauptman

Lutz

2007

10th IEEE High Assurance Systems Engineering Symposium (HASE'07)

View full text Add to dashboard Cite

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.

show abstract

Section: Related Workmentioning

confidence: 99%

A Fault Taxonomy for Service-Oriented Architecture

Sun

Hauptman

Lutz

2007

10th IEEE High Assurance Systems Engineering Symposium (HASE'07)

View full text Add to dashboard Cite

show abstract

“…The specification of the testing procedure often depends on the particular infrastructure technology on which the system is deployed. This means that the system deals with a failure class best characterized as incorrect computation failure , which occurs when a processor fails to produce the correct result in response to a correct input. Furthermore, as the system is partially synchronous and bounds on message delay are unknown, a test reply may take longer than expected to arrive.…”

Section: Construction and Maintenance Of A Virtual Hypercubementioning

confidence: 99%

A distributed virtual hypercube algorithm for maintaining scalable and dynamic network overlays

Bona

Duarte

Fonseca

2014

Concurrency and Computation

View full text Add to dashboard Cite

SummaryNetwork overlays support the execution of distributed applications, hiding lower level protocols and the physical topology. This work presents DiVHA: a distributed virtual hypercube algorithm that allows the construction and maintenance of a self‐healing overlay network based on a virtual hypercube. DiVHA keeps logarithmic properties even when the number of nodes is not a power of two, presenting a scalable alternative to connect distributed resources. DiVHA assumes a dynamic fault situation, in which nodes fail and recover continuously, leaving and joining the system. The algorithm is formally specified, and the latency for detecting changes and the subsequent reconstruction of the topology is proved to be bounded. An actual overlay network based on DiVHA called HyperBone was implemented and deployed in the PlanetLab. HyperBone offers services such as monitoring and routing, allowing the execution Grid applications across the Internet. HyperBone also includes a procedure for detecting groups of stable nodes, which allowed the execution of parallel applications on a virtual hypercube built on top of PlanetLab. Copyright © 2014 John Wiley & Sons, Ltd.

show abstract

“…Therefore, we establish our fault model at the component level -the smallest entity, which may fail in our framework is a whole CORBA component. Our work assumes the fault model depicted in Figure 2, which was introduced in [SI and extended in [9]. This fault model distinguishes the following fault classes: Within our approach, we distinguish between design-time (programming) and runtime faults.…”

Section: Fault-model and Assumptionsmentioning

confidence: 99%

Automatic generation of fault-tolerant CORBA-services

Polze

Schwarz²,

Malek³

Proceedings. 34th International Conference on Technology of Object-Oriented Languages and Systems - TOOLS 34

Self Cite

View full text Add to dashboard Cite

The Common Object Request Broker Architecture (CORBA) is the most successful representative of an object-based distributed computing architecture. Although CORBA simplifies the implementation of complex, distributed systems significantly, the support of techniques for reliable, fault-tolerant software, such as group communication protocols or replication is very limited in the state-of-the-art CORBA or even fault-tolerant CORBA. Any fault tolerance extension for CORBA components needs to trade off data abstraction and encapsulation against implementation specijk knowledge about a component's internal timing behavior, resource usage and interaction patterns. These non-functional aspects of a component are crucial for the predictable behavior of fault-tolerance mechanisms. However, in contrast to CORBA 's intet$ace definition language (IDL), which describes a component's functional inte$ace, there is no general means to describe a component's non-functional properties.We present here a generic framework, which makes existing CORBA components faulttolerant. In adherence with a given, programmer-specified fault model, our framework uses design-time and configuration-time information for automatic distributed, replicated instantiation of components. Furthermore, we propose usage of aspect-oriented programming (AOP) techniques to describe fault-tolerance as a non-functional component property.We describe the automatic generation of replicated CORBA services based on aspect information and demonstrate service configuration through a graphical user-inte~ace.

show abstract

Nest: a nested-predicate scheme for fault tolerance

Cited by 13 publications

References 27 publications

A Fault Taxonomy for Service-Oriented Architecture

A Fault Taxonomy for Service-Oriented Architecture

A distributed virtual hypercube algorithm for maintaining scalable and dynamic network overlays

Automatic generation of fault-tolerant CORBA-services

Contact Info

Product

Resources

About