A State Synchronization Mechanism for Orchestrated Processes

Abstract

Two orchestrated processes interacting with each other have to maintain their own states. Messages are used to synchronize states between orchestrated processes. Server crash and network failure may result in loss of messages and therefore result in a state change performed by only one party. Thus, the states of the parties are no longer synchronized, resulting in state inconsistencies and in worst case deadlocks. In this paper, we propose a mechanism for guaranteed state synchronization of orchestrated processes with system and network failures. Our mechanism is based on interaction patterns and process transformations. The basic idea is to redesign the original processes into their state synchronizationenabled counterparts via process transformations that can be automated. The transformation mechanism is formalized based on Colored Petri Nets. We present the formal proof of the correctness of our mechanism and give the overhead analysis to illustrate its practicability.

A Service-System Based Identification of Meta-services for Service-Oriented Enterprise Architecture

“…Some approaches only consider one phase of the lifecycle. The approach in [22] considers only interactions for defining services are considered. On a very technical level, the interactions between software and infrastructure providers are enumerated in [23], but not handled on an abstract level.…”

“…The approach in [22] considers only interactions for defining services are considered. On a very technical level, the interactions between software and infrastructure providers are enumerated in [23], but not handled on an abstract level. The basic problem of lifecycle-based approaches is that the phases of the lifecycle can be set arbitrarily.…”

Robust Client/Server Shared State Interactions of Collaborative Process with System Crash and Network Failures

“…The possible failure points for a synchronization between A1 and B are marked as X f p1 ∼ X f p6 . The failure points X f p1 , X f p3 ∼ X f p6 are discussed in our previous work [2], [3]. We look into failure point X f p2 .…”

“…Our aim is to transform the process at a particular party to provide additional guarantees with regard to system crashes and network failures. In previous work [2], [3] we have considered coordination scenarios where the effects of the state changes in the collaboration do not affect other collaborations. In this paper we are focusing a server instance collaborating with multiple client instances, where one collaboration may affect another collaboration.…”

Robust collaborative services interactions under system crashes and network failures

“…Our idea of recovery is that the initiator resends the request after a system restarts, and that the responder, after receiving the resent request message, uses a cached response message as a reply [89,90]. The transformation of the responder is based on the further interaction, to make the further interaction able to accept the failure resent message and to use the cached response in the reply.…”