3.2 Execution of Business Conversations
3.2.1 Execution Model
The fulfilment of intended business objectives requires the partners to exercise their rights and their obligations, and this in turn requires them to exchange messages carrying business documents and to act on them. This activity can be viewed as the business partners taking part in the execution of a public business process, that can also be called ashared orcross-organizational business process, where each partner is responsible for performing their assigned part. In Figure 3.1, P ubBizP rocB andP ubBizP rocS are the two halves of the public business process the buyer and the seller share for the execution of the contract discussed in the previous Chapter. To preserve their autonomy, the buyer and the seller conceal behind their public business processes those aspects of their business they do not wish to disclose, theprivate business processes; in Figure 3.1 these arePrivate Business P rocessB andPrivate Business P rocessS respectively for the buyer and the seller.
1 − Functional Requirements
1.1 Buyer is permitted to issue a purchase order...
2.1 Seller is obliged to invoice Buyer within...
4.1 Seller is prohibited from requesting cancellation...
2 − Non−functional Requirements Not specified in this example.
Contract Compliance
Checker
Channel Monitoring
Conversation Channel
B
Private Business Process
PubBizProcB
Business ProcessS
Private
PubBizProcS
derived from Legend:
Purchase Order Conversation
B
Purchase Order Cancellation ConversationB Invoice Notification
Conversation
B
(...)
buyer seller
Purchase Order Conversation Purchase Order
Cancellation Conversation Invoice Notification
Conversation (...)
S
S
S
Conventional Business Contract
Figure 3.1: Private and Public Business Processes.
The shared business process is derived from the contract by mapping each business operation stipulated in the contractual clauses into the two complementary halves of abusiness conversation, as shown in Figure 3.1. For example, the business operationPurchase Order Submissionfrom clause 1.1 is mapped into the two business conversationsPurchase OrderConversationB andPurchase Order ConversationS; likewise, the business operation Invoice from clause 2.1 is mapped into the two business conversationsInvoice NotificationConversationBandInvoice Notification ConversationS. Consequently, executing a business operation results in the execution of the corresponding business conversations.
Business conversations are carried out employing a B2B messaging protocol, and are subject to timing and validity requirements that can be discussed using a model inspired by RosettaNet [54, 61]. There are two kinds of these conversations, shown in Figure 3.2: single-action and double- action. In a single-action conversation a single electronic document is sent, and then its receipt is acknowledged; a double-action conversation involves an exchange of two documents, a request and a response, with each receipt acknowledged.
A document is accepted for processing by its receiver only if the document is received within the set timeout period (if applicable) and the document is valid. There are two validity checks that must be met:
1. Base-validation: the document must be syntactically valid; this involves verification of a static set of syntactical and data validation rules, according to the specification laid down in the standards being used;
2. Content-validation: a base-validated document must also be semantically valid, in the sense
Single action interaction Two−action interaction
t hours
buyer seller
validation Request
RequestAck
buyer seller
validation
validation
validation
RequestAck Request
Response
ResponseAck validation
t hours
validation
Legend: Action Message Signal Message
Figure 3.2: Interaction patterns.
that its contents should satisfy some given, application specific criteria. This validation could vary from trading partner to trading partner and may well be performed within the receiver’s Private Business Process.
The interactions shown in Figure 3.2 depict what should happen logically; in reality, each such interaction maps onto several messages that are required in any protocol implementation (connection establishment, acknowledgements and non-acknowledgements, retries, etc.).
RosettaNet specifies about a hundred Partner Interface Processes (PIPs), that define basic busi- ness conversations such as PIP 3A4,Request Purchase Order, and PIP 3C3,Notification of Invoice.
Each PIP document specifies an element of the vocabulary of the business interaction by dictating the choreography of the message dialogue. As shown in Figure 3.3, this includes business action messages (messages carrying a business document) andbusiness signal (Acks and Nacks) messages.
In RosettaNet, a buyer is expected to use the Request Purchase Order PIP 3A4 to express its desire to pay. Similarly, the seller is expected to use PIP 3C3 (Notification of Invoice) to invoice the buyer. A graphical representation of the two PIPs is shown in Figure 3.3.
As shown in the figure, the receiver of an action message is required to acknowledge it by sending a signal message back within two hours. 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., the seller for PIP 3C3) and its responder, could (e.g., the buyer for PIP 3C3) could end up with contradictory views of the
PIP 3C3: Notify of Invoice
2 hours
buyer seller
validation Receipt Ack
validation
Legend: Action Message Signal Message Invoice Notification
buyer seller
validation
validation
validation
Receipt Ack
validation
PIP 3A4: Request Purchase Order Purchase Order Req
Purchase Order Resp
Receipt Ack
24 hours 2 hours
Figure 3.3: Examples of RosettaNet PIPs.
outcome of the execution of the PIP. For example, in PIP 3C3, if theReceiptAck signal message is lost or arrives after the two hour limit, the buyer’s and the seller’s views of the outcome could be respectively a successful and a failed termination; subsequent executions of public business processes at each end could diverge, causing errors at the business level.
RosettaNet relies on negative acknowledgements to synchronize trading partners at PIP level, and minimize the errors propagated to the business application [61]. A positive acknowledgement is sent to indicate that an action message has been received and successfully base-validated. A negative acknowledgement is sent to indicate that an action message has been received but failed its base-validation. However, some errors inevitably could propagate to the business level. The impact of base and content validation is illustrated in Figure 3.4, illustrating how the states of the buyer and the seller can become mutually inconsistent when the action message is base-valid but content-invalid. When the buyer discovers the error, it signals a failure to alert the seller; for this Rosettanet provides a special Notification of Failure PIP 0A1 to take application specific actions to re-synchronise. At the same time, the seller is convinced that the outcome of the execution of the PIP is successful, and so starts the execution of the next PIP it would normally execute for a success. Thus the two business partners find themselves out of synchrony, and could end up performing mutually inconsistent actions before re-synchronization occurs. A way out of it is to execute an explicit synchronization of the outcomes, as discussed in the next Subsection.
Error found in action message: buyer declares PIP unsuccessfully executed and starts PIP 0A1 for Notification of Failure.
No errors found: seller declares PIP successfully executed, and starts execution of next PIP.
buyer seller
base−validation
validation content
Receipt Ack
base−validation Invoice Notification
Figure 3.4: Diverging views of PIP outcome.