On State Synchronization of Business Conversations Carlos Molina-Jimenez, Santosh Shrivastava and Simon Woodman School of Computing Science, University of Newcastle upon Tyne, UK {Carlos.Molina, Santosh.Shrivastava, s.j.woodman}ncl.ac.uk Abstract The paper assumes that business interactions between trading partners are composed of well defined conversations (tasks), such as issue a purchase order, process payment, refund money, cancel purchase order, etc. Using RosettaNet Partner Interface Processes (PIPs) as an example of these conversations, the paper discusses a method that guarantees that trading partners have a mutually consistent view of the state of business interactions despite encountering software and hardware related problems (e.g., clock skews, unpredictable transmission delays, message loss etc.). The paper develops centralized as well as distributed execution models and outlines the middleware functionality required for maintaining consistency. 1. Introduction We assume that trading partners (e.g., a buyer and a seller) wish to conduct business by executing shared (cross-organizational) business processes over the Internet. Such a process can be regarded as composed out of basic and well defined conversations (also called tasks, activities or dialogs), such as issue a purchase order, notify of invoice, cancel purchase order, refund money, etc. A particularly difficult problem, addressed in this paper, is ensuring that trading partners have a mutually consistent view of the state of business interactions despite encountering software and hardware related problems (e.g., clock skews, unpredictable transmission delays, message loss, corrupted messages, node crashes, etc.). Using RosettaNet Partner Interface Processes (PIPs) as an example of these conversations [1,2] we propose a preventive approach which employs explicit synchronization mechanisms to mask synchronization errors appearing at the business process level. We develop centralized as well as distributed execution models and outline the middleware functionality required for maintaining consistency. 2. Consistency Issues 2.1. RosettaNet Partner Interface Processes RosettaNet is a standards organization that has published several documents known as Partner Interface Processes (PIPs) that define basic business conversations such as request purchase order and notify of invoice. As shown in Fig. 1, each PIP document specifies the vocabulary and choreography of the message dialog. 2 hrs PIP 3A4: request purchase order conversation Purchas eR e ques t A c tion Rec eipt Ac knowledg ement P urchaseC onfi rmati onA ct i on Rec eiptAck no wl e dge ment buyer seller 2 hrs 24 hrs PIP 3C3: notify of invoice conversation Invoice Noti f icati o n Rec ei pt Acknowledgem ent buyer seller 2 hrs 2 hrs PIP 3A4: request purchase order conversation Purchas eR e ques t A c tion Rec eipt Ac knowledg ement P urchaseC onfi rmati onA ct i on Rec eipt Ack no wl e dge ment buyer seller 2 hrs 24 hrs PIP 3C3: notify of invoice conversation Invoice Noti f icati o n Rec ei pt Acknowledgem ent buyer seller 2 hrs PIP 3C3: notify of invoice conversation Invoice Noti f icati o n Rec ei pt Acknowledgem ent buyer seller 2 hrs Fig. 1. RosettaNet PIP3A4 and PIP3C3 Although each PIP performs a conceptually simple action, in an asynchronous environment, such as the Internet (where communication and processing delays can be unpredictable), we face the problem that the PIP initiator (e.g., seller, PIP 3C3) and responder (buyer, PIP 3C3) could end up with contradictory views of a PIP execution. For example, in PIP 3C3, if the ReceiptAcknowledgement message is lost or arrives after the 2 hrs limit, the buyers and sellers views could be successful and failed termination, respectively; subsequent executions of the public process at each end could diverge, causing business level errors. PIP implementations are therefore expected to contain a variety of features to minimize the occurrences of conflicting views [3]. RosettaNet provides two mechanisms (negative acknowledgement and notification of failure) to bring the trading partners back into synchrony whenever they are suspected to be in inconsistent states. Negative acknowledgement messages (also called exception messages) are used for synchronization within a PIP; an exception is sent to inform a trading partner that something is wrong with their action message and ask for a re-send. Notification of failure is a PIP (PIP 0A1) that is used for synchronization above a PIP level when synchronization failure within PIP level is suspected and impossible (reasons could be that a trading partner is unreachable, or has finished the execution of the PIP, etc.). Synchronization here is enforced above PIP level as notification of failure implies the abandonment of the execution of the problematic PIP