[ebBP] 3/28/2004: WI-31 BPSS Executability [RSD]

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

Discussion|OASIS.ebBP.WI31-BSI and executability of BPSS;
Topic|;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200311/threads.html;
Point|Solidify v2.0 boundaries and explanation;

mm1@
Work Item 31:  BSI and executability of BPSS;
Description: Scope what execution entails in the context of BPSS.  Need 
to be capable of describing more fully the execution sequence of 
messages and signals.

|| See BPSS Executability discussion in November 2003 archive: 
http://www.oasis-open.org/archives/ebxml-bp/200311/threads.html.

Discussion points:

    * There are multiple practical ways to produce the BPSS for runtime. 
    * BPSS is a deployable configuration describing the public process
      and specifications that are defining the binding to back-end
      systems should be considered/recommended but not anchored.
    * How does this scope map to the ebXML vision? Parties agreeing on
      the same BPSS only agree on the format and data to be exchanged
      and not the behaviors associated with the data.
    * This is an area that Business Entity Types was supposed to
      partially address, by allowing the BPSS to reference named states
      of business objects (e.g. Shipment is Delivered), and then
      layering the definition of "Delivered" (rule expression) in the
      business agreement (being addressed by UBAC).
          o Note that you could still put the BET state expression on
            the BPSS transitions (e.g. Invoice.is_Paid AND
            Product.in_Shipment AND Shipment_is_Delivered), and provide
            an element in the BPSS where the states could have their
            complete definition (e.g. < 5% scrap).
          o In part this can be addressed today. In BPSS 1.01 has the
            concept of a "logical" business document and transitions can
            be guarded by these documents. A logical business document
            is a physical document with a condition. For example, the
            BSI could execute a "Invoice_is_paid" business document
            which is a Process payment message with a payment amount
            equal to the order amount.
          o By allowing conceptual "business" state to guard the
            transitions, and then allowing both standard and partner
            specific definition of those states, the BPSS could be
            extended to be "business process" and not just "message
            exchange choreography" happen up to some level like MSH [2].

Potential recommendation
Partly addressed by handling signals in 59, 60, 61, and 62 [1]
Add more text in description of Figure 17 for non-repudiation 
(ReceiptAck) and QoS (AcceptanceAck).

For v2.0, I would like to understand what other functionality is 
required. I would encourage the original participants on this item in 
the F2F and late last year to share their thoughts so we can establish 
any other boundaries.

Thanks.

[1] Note that we have accepted a direction with WI 59 and I have 
proposed to combine 60-62.
[2] To be discussed in v3.0.

Contributions from Serm Kulvantunyou, JJ Dubray, John Yunker, Jussi 
Lemmetty and others. Thanks.
@mm1