Providing fault-tolerant execution of web-service-based workflows within clouds

Abstract

With a variety of services rapidly evolving at all architectural levels of cloud computing, there is an increasing demand for a standardized way to coordinate their interactions. Business process management, that is, more general, the management of Web-service-based workflows, could satisfy this demand and, indeed, first corresponding o↵erings have gained instant popularity. While from a functional perspective, these Platform-as-a-Service (PaaS) solutions are already quite mature, their support for fault tolerance is still very limited, making them inapplicable for critical tasks.Concerning the deficiencies of currently existing systems, this paper presents a practical solution for executing critical Web-service-based workflows, particularly within clouds, in a fault-tolerant, highly available and highly configurable manner. We achieve this by actively replicating workflows as well as Web services in a combined architecture, reusing existing standard systems and coordination services. By providing an automated transformation tool, replication is realized transparently to existing systems and workflows. Measurements show that our proposed architecture achieves lower response times than existing systems and that the integration of a coordination service imposes only moderate costs, while simplifying the implementation and leading to a dynamically adaptable solution.

High availability in clouds: systematic review and research challenges

“…Push-based monitoring can also be implemented following a publish/subscribe communication model. This type of monitoring is employed by Behl et al [26] to provide fault-tolerance to web service workflows. The fault monitoring is implemented through ZooKeeper's Watches, which are registered to check if a Zookeper's ephemeral node (an application in this case) is active.…”

“…From this perspective, failure detection can be classified in two categories according to detection mechanisms: reactive [23,26]) and proactive [20]. The first approach waits for KEEP ALIVE messages, but it identifies a failure after a period of time waiting without any KEEP ALIVE message.…”

“…The work presented in [26] proposes a fault-tolerant service through replication processes with BPEL implementation, which means that Zookeeper is responsible for detecting crashed replicas using a callback mechanism called watches. As well [23], authors treat failure detection through heartbeats hosted in each node, and so the absence of heartbeats after a period of time has passed indicates a failure and hence the recovery process begins.…”

FaCETa: Backward and Forward Recovery for Execution of Transactional Composite WS

“…We can distinct two kinds of distributed coordination approach. In the first one, nodes interact directly based on a peer-to-peer application architecture and collaborate, in order to execute a CWS with every node executing a part of it [2,5,16,18,28]. In the second one, they use a shared space for coordination [4,12,19].…”

“…Nodes need to know explicitly which other nodes they will potentially interact with, and when, to be active at the same time. In [2] all replicas of a WS are simultaneously invoked. Only results of the first replica finished are accepted, other executions are halted or ignored.…”