The paper assumes that business interactions between trading partners are composed of well defined conversations (tasks), such as issue a purchase order,.
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
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
PIP 3A4: request purchase order conversation seller Purcha seReque stAction
2 hrs
ReceiptAcknowledgem ent
PIP 3C3: notify of invoice conversation seller InvoiceNotification ReceiptAcknowle dgement
gement ReceiptAcknowled
tion nfirmationAc PurchaseCo
buyer
2 hrs
buyer
2 hrs
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.
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.
24 hrs
Abstract
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
to initiate the execution (preferably via an alternate channel) of PIP 0A1 that tells the receiving partner not to continue with the business process until both trading partners are synchronized. However, there is no guarantee that this PIP execution will succeed, so other means requiring manual intervention (phone, fax,..) would be the last resort [3]. 2.2. State synchronization Global synchronization is a fundamental issue in distributed systems and it is all about ensuring that the parties that compose the application have a mutually consistent view of its state despite encountering networking and computational problems (e.g., node failures and recovery, clock skews, unpredictable transmission delays, message loss, corrupted messages, etc.). Cross organizational business processes are not exceptions. Following RosettaNet [3], we assume two classes of failures, (i) temporary: network partitions are assumed to heal eventually, so communication becomes possible, and nodes may crash but they will eventually recover and resume participation in a protocol run, and (ii) permanent: partitions do not heal and nodes do not recover. RosettaNet specifications leave it to business processes of partners to cope with consequences of PIP failures caused by either classes of failures. We term this a corrective approach that is triggered by a trading partner. A preventive approach developed in this paper, employs explicit synchronization mechanisms to mask synchronization errors appearing at the business process level. Preventive synchronization could be implemented either in a peer-to-peer distributed manner or through a third party mediation service. In Sections 3 and 4 we propose synchronization models for both respectively; they are preventive in the sense that they maintain consistency despite temporary failures, but will need recourse to other mechanisms (use of PIP 0A1) to cope with permanent failures. In general a business process might contain scores of business operations that might result in the exchange of several messages; in principle, they can be initiated by either of the two business partners and overlap in their executions. To avoid the complexity of cross talks, in our preventive synchronization models we allow only one initiator and one responder for each business conversation
3. Distributed synchronization The exchange of messages between partners in this model is strictly peer-to-peer. The two finite state machines (FSMs) shown in Fig. 2. contain three types of states: PIP initiation, synchronization and exe PIP, represented by small ellipses, large ellipses and circles, respectively. PIP initiation states are used by the initiator
and the responder to express the intention to initiate, and respond to, the execution of a PIP, respectively. Synchronization states are used to synchronize the trading partners before and after the execution of each PIP. The actual execution of PIPs occurs in the exe PIP states. Initially the initiator (the buyer) and the responder (the seller) are in complementary states (sending and receiving states, respectively). Eventually the buyer will try to send InitPIPi message to invite the seller to execute PIPi; however, if the buyer could not send the message, the seller could not open it, it was sent too late, it was not received before a deadline, etc., the buyer and the seller would disagree on the outcome of the action. The synchronization state following the PIP initiation state guarantees that the buyer and the seller agree on a single outcome, so that they always move from their PIP initiation states to complimentary states. b(uyer) timeout
s(eller)
sending state ! initPIPi
receiving state timeout ? initPIPi
synchronization state failure
synchronization state
success
receiving state
success
exe PIPi
failure sending state timeout
success receiving state ? initPIPj
sending state
exe PIPi
s_outcome
b_outcome synchronization state
failure
synchronization state success sending state ! initPIPj
failure receiving state timeout
Fig. 2. Distributed synchronization The execution of PIPi in exe PIPi states can result in either success or failure (not necessarily shared by both business partners). The synchronization states below the exe PIP states collect the two outcomes and dictate what the single outcome should be so that the two business partners move from their synchronization states to mutually consistent states. As shown in Fig. 3, the middleware that we suggest to provide RosettaNet based business processes with state synchronization, consists of the Business process Execution Layer (BEL) and the PIP Implementation Layer (PIL). The BEL layer implements the business logic of the whole business process. The PIL layer implements individual PIPs and offers interfaces for starting, responding and obtaining results, and state synchronization to the BEL layer. State synchronization can be realized with the help of a state synchronization protocol like the one discussed in [4] which is a signed
two-phase protocol that reaches agreement with nonrepudiable evidence for each partner. Seller
Buyer BEL
BEL
purchase order invoke
results
PIL
process PurchaseOrderRequest ReceiptAcknowledgement
PIP3A4
purchase order
PurchaseOrderConfirmation
results
PIL PIP3A4
ReceiptAcknowledgement
Fig. 3. Middleware As an example, the execution of the PIP 3A4 is shown Fig. 4.
Fig. 4. Synchronized execution of PIP 3A4 In the UML diagram the initiator and the responder are the buyer and the seller, respectively. Prior to the interaction, the responder uses Register(pip, callback) to register with its PIL an object to respond to the execution. The initPIP message begins a synchronization protocol to ensure that the execution is started only if the seller and the buyer are in synchronised states. The actual execution begins when the initiator sends a purchaseOderRequest; if this message is syntactically valid, the responder sends a ReceiptAcknowledgement. processRequest(msg) passes the purchase order request up to the responder’s BEL layer which responds to its PIL layer with the sendRespond(msg) message; this message is used to construct the PurchaseOrderConfirmation message sent by the responder’s PIL to the initiator’s. On receipt of this message, the initiator’s PIL layer sends ReceiptAcknowledgement back to the responder, composes the processResponse(msg) message and passes it up to its BEL layer who decides whether, from its perspective, the PIP completed successfully or failed. The
initiator’s and responder’s outcomes are fed into the second synchronization phase that guarantees that the two partners agree on the outcome of the PIP execution before continuing. The notify(outcome) messages are sent from the PIL layer to their BEL layers to notify of the agreed outcome of the execution.
4. Mediated synchronization The execution model that we present in this section is represented by three FSMs belonging to the buyer, the seller and a mediator (see Fig.5). As discussed in [5], the mediator intercepts some or all the messages that the parties try to send; thus, it can act as a synchronizer. The FSMs have three types of states: PIP initiation (represented by ellipses), message checking (represented by small circles) and exe PIP (represented by large circles). PIP initiation states are labeled as sending and receiving states and used by the initiator and the responder to express the intention to initiate, and respond to, the execution of a PIP, respectively, whereas the mediator uses this state to wait for the initiator to send its initiation message. The message checking state is used by the mediator to validate the legality of the message sent by the initiator. The execution of PIPs takes place in exe PIPi states. In contrast to the model discussed in Section 3, there is no state synchronization here, as synchronization is captured in this model by the states of the mediator. In this example, the mediator performs its job as a synchronizer in the “checking message state” above exe PIPi state. The intention to initiate the execution of PIPi might result in several outcomes (illegal message, message too late, message too early, etc.). The mediator guarantees that only when the initiator sends a legal message, the three parties move to the exe PIPi state. Notice that to keep the FSMs simple, only one possible way out of the top initiation states is shown, a more realistic model would consider a timeout escape to prevent the buyer from blocking the whole system by recurrently sending an illegal message or not sending any at all. The execution of PIPi can result in two possible states (success or failure) not necessarily shared by the buyer and seller; again, the job of the mediator here is to wait until the two business partners declared the execution terminated or until the time to complete it expires, analyze the buyer’s and the seller’s outcome and dictate them what the single outcome should be; the mediator’s decision guarantees that the buyer and seller always produce a single outcome and progress to complementary states from where they can continue or finish the execution of the business process. An in depth discussion of the rules fallowed by the mediator to decide the final single outcome falls out of the interest of this paper, yet common sense suggests that the mediator will declare the
execution of the PIP successful only when the two business partners declare it successful. b(uyer)
m(ediator)
sending state ! initPIPi ? failure
m checking msg
? success
exe PIPi ? failure sending state
receiving state
s(eller)
m checking msg
! success to b, ! InitPIPi to s
! failure to b, ! failure to s
exe PIPi
? initPIPi
exe PIPi ? failure
receiving state
This work is funded in part by UK Engineering and Physical Sciences Research Council (EPSRC), under an e-Science programme, Grant No. GR/S63199/01, “Trusted Coordination in Dynamic Virtual Organisations”, and GOLD: Grid-based Information Models to Support the rapid Innovation of New High Value Added Chemicals, and by EPSRC Platform Grant No. EP/D037743/1, “Networked Computing in Interorganisation Settings”.
receiving state
receiving state ? success
Acknowledgements
receiving state
! initPIPi frm b ! failure to b
the additional complexity posed by synchronization errors.
! success to b, ! success to s receiving state ? InitPIPj frm s m checking msg
? success sending state ! InitPIPj m checking msg
Fig. 5. Mediated synchronization The advantage of this model is that state synchronization can be implemented relatively simply with the help of a single trusted third party.
5. Related work The issue of state synchronization in business interactions is pointed out in [6], however, no solution is suggested. Work that is related to our paper is that presented in [7,8]; the difference lies in the relationship between the business process and the PIP conversations, namely on the level of abstraction of the PIP implementation and execution. In [7,8], PIP operations (such as the four operations involved in PIP 3A4) are explicitly coded in the business process which is described in Business Process Language (BPEL). In our view, this is a daunting job due to the complexity of the protocols (retry counts, exceptions, re-transmissions, etc.); more importantly, we believe that PIPs should not be implemented at the business process level, but at a lower level, so that the implementation can be re-used and the business process can be deployed on top of other standardized conversations. With this view in mind, we described how PIP synchronization can be handled at the PIP implementation level. Synchronization control at this level greatly simplifies the task of programming public business processes. A public business process could be an arbitrarily complex composition of PIPs (sequence, parallel, loop, conditional etc); thus it is sensible to avoid
References [1] RosettaNet implementation framework: core specification, Version V02.00.01, 6 March 2002, http://rosettanet.org. [2] S. Damodaran, “B2B Integration over the Internet with XML – RosettaNet Successes and Challenges”, Proc. of WWW2004, May 17-22, 2004, New York, USA, ACM pp. 188-195. [3] RosettaNet implementation framework, Version V02.00.01: High Availability Features, technical Recommendation, December 2004. [4] N. Cook, S. Shrivastava and S. Wheater, “Distributed Object Middleware to Support Dependable Information Sharing between Organisations”, IEEE/IFIP International Conference on Dependable Systems and Networks (DSN-2002), June 2002, Washington DC, pp.249-258. [5] C. Molina-Jimenez, S. Shrivastava, and J. Warne, “A Method for Specifying Contract Mediated Interactions”, 9th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2005), September 2005, Enschede, The Netherlands, pp. 106-115. [6] Paul Greenfield, Dean Kuo, Surya Nepal and Alan Fekete, “Consistency for Web Services Applications”, In Proc. of the 31st VLDB Conference, Trondheim, Norway, 2005. [7] Suhayl Masud, “Use RosettaNet-Based services (Part 1-4)”, http://www-128.ibm.com/developerworks/ webservices/library/ws-rose1/ [8] Rania Khalaf, “From RosettaNet PIPs to BPEL Processes: A Three Level Approach for Business Protocols”, In Proc. of the Third International Conference on Business Process Management, (BPM 2005); Nancy, France, September 2005.
