Re: [ebxml-bp] Re: [ebxml-bp-comment] Public Comment

[Monica J Martin <Monica.Martin@Sun.COM>]

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.