OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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]