[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 2/9/2005: Batch Processing v2.0 Scope
In our TC call yesterday, we discussed v2.0-scoped text on how to handle batch processing. I've proposed incremental changes, as agreed, for Sections 4.6.6.5 and 4.6.7.1. Further redress will occur in a later version. Section 4.6.6.5 FROM: . In the actual execution of the purchase order transaction, however, only one of the defined possible responses SHOULD be sent and the others SHOULD NOT occur. In the case of PartialPurchaseOrderAcceptance, multiple partial responses may be handled separately via the choreography. TO: . In the actual execution of the purchase order transaction, however, only one of the defined possible responses SHOULD be sent and the others SHOULD NOT occur. In the case of PartialPurchaseOrderAcceptance, multiple partial responses may be handled separately via the choreography. [add] CHOREOGRAPHY IS DISCUSSED IN MORE DETAIL IN SECTION 4.6.7.1. [end-add] Section 4.6.7.1 FROM: Since a /Business Transaction /is atomic in nature, the performing of a single /Business Transaction /through a /Business Transaction Activity /is also atomic in nature. If the desired semantic is not atomic, and then the task should be split over multiple business transactions. For instance if it is desired to specify several partial acceptances of a request, then the request should be specified as one transaction within a Binary (Business) Collaboration and the partial acceptance(s) as separate transactions, thus handling the partial acceptances within the choreography. The choreography can also support multiple requests in the same manner. More requirements will be solicited to evaluate what other mechanisms are needed to support business collaboration. TO: Since a /Business Transaction /is atomic in nature, the performing of a single /Business Transaction /through a /Business Transaction Activity /is also atomic in nature. If the desired semantic is not atomic, and then the task should be split over multiple business transactions. For instance if it is desired to specify several partial acceptances of a request, then the request should be specified as one transaction within a Binary (Business) Collaboration and the partial acceptance(s) as separate transactions, thus handling the partial acceptances within the choreography. The choreography can also support multiple requests in the same manner. [add] SIMILAR OR MORE COMPLEX CIRCUMSTANCES MAY APPLY. FOR EXAMPLE, THE DOCUMENT ENVELOPE MAY CONTAIN MULTIPLE EDI PAYLOADS OR PERTAIN TO SEPARATE BUSINESS TRANSACTIONS. IN THIS CASE, IT IS RECOMMENDED THAT CHOREOGRAPHY BE USED TO LOGICALLY HANDLE THESE, SIMILAR TO HOW MULTIPLE REQUESTS OR RESPONSES. [end-add] More requirements will be solicited to evaluate what other mechanisms are needed to support business collaboration [add] AND CONDITIONS SUCH AS THOSE THAT MAY APPLY TO BATCH PROCESSING. [end-add]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]