[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Re: [ebxml-bp-comment] Public Comment
Radha: I continue as specified to address your questions. 2. ebBP: On specific ebBP possible changes, I will address these individually. This email addresses part of the 2. item. Thanks. > >5.Distinction between Business message and signal and the relation with > BSI may be explicitly mentioned. > > > mm1: The BSI understands both and their relevance to success or failure > (whether technical and/or business). If you look at Section 3.6.3 in the > technical specification (on public web site: > http://www.oasis-open.org/committees/document.php?document_id=16455&wg_abbrev=ebxml-bp > > [pdf in .zip]), it discusses how business messages with an associated > business document and business signals relate to success or failure. If > we link these two discussions in the Appendices, Appendix A, will that > increase your understanding? The specification, appendices, and the > schema and documentation are used together. > >- A single reference will be easier. > >7. Explanation of Relevance of state synchronization and state alignment may need to be mentioned. > mm1: In Section 3.4.2 (see reference above for link), we do describe this. I will go through the specification and see where this is under-specified. We are clear in the specification that the expectations of the parties and their shared understanding is imperative for business collaboration. State alignment is key to enable that. I'll provide further comments once I go through the specification more fully to address your question. ========== mm2: Radha, in looking at this further, it is important in the technical specification to identify the Document Envelope, the Business Signal and the transitions and guards that lead to Success or Failure. Trying to combine these may overload any given section. The same holds true for state alignment. References exist in several of these sections so the capabilities are tied together. How about we try for an optimal solution (reiterate try)? Suggest minor changes to some sections, and to Appendix A (referencing back to these sections and Section 3.6.3). Note: Because there are several mappable references, I've optimized what references are made. We talk about Business Document Flows very early in Section 3.4.3. The same holds true for Business Signals in Section 3.2. I've also tried to, in tandem, introduce some changes relative to your other question on state alignment, Radha. ================================== Section 3.4.2 Change from: A Business Transaction is a very specialized and very constrained protocol used to achieve very precise and support enforceable transaction semantics and achieve state alignment when needed between both parties. (just before we speak in detail about the BT patterns).... For instance, a “reject purchase order” response document would be considered as a Business Failure. In this case, it is the role of the applications to mark the state of the purchase order appropriately. Change to: A Business Transaction is a very specialized and very constrained protocol used to achieve very precise and support enforceable transaction semantics and achieve state alignment when needed between both parties. (just before we speak in detail about the BT patterns).... For instance, a “reject purchase order” response document would be considered as a Business Failure. In this case, it is the role of the applications to mark the state of the purchase order appropriately. Success and failure, the conditions and guards defined, and their relationship to Business Document Flows and Business Signals is detailed later in Section 3 (particularly Section 3.6.3). Section 3.4.9.3 Change from: The Business Signals are important for state alignment, and relate to the characteristics inherent in the BT patterns described earlier in Section 3. Change to: The Business Signals are important for state alignment, and relate to the characteristics inherent in the BT patterns described earlier in Section 3. Business Signals and their relationship to success and failure are outlined in Section 3.6.3. Section 3.6.3 **OPEN** Pend for open question to the TC: Evaluate figures 14 and 15 in Section 3.6.3 to ensure they are comprehensive enough to guide implementers like Radha. Appendix A Change from: Therefore, a BSI is: * A discrete set of business process states (results of Business Transactions) shared and aligned between trading partners. * A discrete set of Business Transactions * A discrete set of transitions between Business Transactions * The business rules governing (1) through (3). Change to: Therefore, a BSI is: * A discrete set of business process states (results of Business Transactions) shared and aligned between trading partners. * A discrete set of Business Transactions * A discrete set of transitions between Business Transactions * The business rules governing (1) through (3). As indicated in the technical specification, this software component recognizes the Business Document Flows and Business Signals, and their relationship to the Business Transaction patterns (and business semantics). These capabilities provide the baseline for shared understanding, state alignment and inherently realization of the expectations of the parties involved.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]