FaDe: RESTful Service for Failure Detection in SOA Environment

Abstract

Abstract. FaDe service is a novel proposal of failure detection service based on REST paradigm for SOA environment. It is fully distributed service. Internal communication between FaDe nodes can be realized using two communication protocols (gossip, Kademlia). It makes the nodes cooperation efficient and provide good level of scalability. The failure monitoring is based on accrual failure detector which provides flexibility in the context of different client expectations considering the speed and accuracy of detections.

The impact of RESTful semantics on reducing the logging overhead in SOA

“…Additionally, the crash-recovery model of failures is assumed, i.e., system components may fail and recover after crashing a finite number of times [2]. Failures may happen at arbitrary moments, and we require any such failure to be eventually detected, for example by a Failure Detection Service [4].…”

Garbage Collection for Service Oriented Distributed Reliable Environment D-ReServE

“…Additionally, the crash-recovery model of failures is assumed [4]. Failures may happen at arbitrary moments, and we require any such failure to be eventually detected, for example by a Failure Detection Service [5].…”

Applying Message Logging to Support Fault-Tolerance of SOA Systems

“…Additionally, the crash-recovery model of failures is assumed, i.e., system components may fail and recover after crashing a finite number of times [1]. Failures may happen at arbitrary moments, and we require any such failure to be eventually detected, for example by a Failure Detection Service [2].…”

“…3. The response contains the information on recovery points and identifiers of the last responses stored in each of them (2). Then SIM obtains from RM U the identifier of last response saved in its stable storage (3,4), and determines which recovery point contains messages not later then the last one saved in the RM U .…”

“…(l. [4][5][6][7][8]. RM U performs only requests, which IncID (specifying the identifier of session to which the request belongs), corresponds to the current session identifier (l. [1][2][3]. If the response to request issued by the client has already been saved in the RM U , then there is no need to send this request to the service once again, as the already saved response can be sent to the client immediately (l. 9-14).…”