BPSS strategic issue: transaction integrity

[Bob Haugen <linkage@interaccess.com>]

This is the discussion of one of the three strategic issues
with the ebXML Business Process Specification Schema V0.99
that I believe are highest priority for ebXML BP right now.

2. Integrity of transaction model, or, the ability to form
    legally binding contracts and enact legal events.

    The firm agreement I seek is that the BPSS must
    conform to the requirements for the commercial use
    of electronic document interchange of UN/ECE and
    the ABA.  If the BPSS conforms to the business
    transaction semantics of the UMM Metamodel,
    then I believe this issue should be resolved as well.
    But I want to raise it in particular because I believe
    it is the most important business requirement on the
    BPSS.  If we get the transactions right, the rest is
    gravy.  If not, the rest doesn't work either.

Here are the relevant rules for legally-binding electronic commerce:
1. PART 2 UNIFORM RULES OF CONDUCT FOR INTERCHANGE OF TRADE DATA BY
TELETRANSMISSION (UNCID), CHAPTER 2 - Text of the Uniform Rules of Conduct,
http://www.unece.org/trade/untdid/texts/d220_d.htm
2. UN/ECE RECOMMENDATION No.26, THE COMMERCIAL USE OF INTERCHANGE
AGREEMENTS FOR ELECTRONIC DATA INTERCHANGE,
http://www.unece.org/trade/untdid/texts/d240_d.htm
3. The Commercial use of Electronic Data Interchange, Section of Business
Law American Bar Association, A report and model trading partner agreement,
http://www.abanet.org/buslaw/catalog/5070258.html.

ebXML business transactions may be not just exchanges of electronic
documents; they often will be also exchanges of legal and financial
commitments between trading partners. In order for these legal 
commitments to be binding, there are rules of engagement or interaction 
that must be followed, outlined in the above references.

These references make clear that legally-binding electronic
transactions are as much dependent on business process
behavior as document content.

The UMM Metamodel complies strictly with the above-cited rules for
business transactions.  In particular, this is:
* why the UMM transaction metamodel makes distinctions between business
  activities and documents (BTV) and business signals (FSV),
* why each of the UMM business signals were included,
* why the transactions must be considered as whole models of
  interactional behavior (process interaction, not just document interchanges), 
  and
* why the business transaction patterns were formulated to make this
  interactional behavior predictable.
  (Predictable behavior is necessary to legally-binding transactions.)

The UMM transaction model is different from database-oriented
transaction models like two-phase-commit, and also different from
collaboration-level transaction models like compensating transactions.
The design starts from legal and business requirements rather than
technical requirements (not to deny technical requirements).

The UMM transaction model is derived from and compatible with previous
work on RosettaNet PIPs.  However, one distinction between ebXML use
of this transaction model is that PIP software tends to be hard-coded
(new PIPs require new software code) whereas ebXML wants business
service software to be able to interpret XML representations of business
processes, that is, new processes should either require no new code 
or at least less new code.  This more-flexible software should be a 
great benefit for ecommerce standards, but will also up the ante for 
a predictable transaction model to give predictable results.

The BPSS v 0.99 deviates from the UMM transaction metamodel in
the following ways that must be considered in terms of legal and
business requirements, not just technical niceties:

Lines 420-421:
A) "A business transaction is realized as Business Document Flows 
between the requesting and responding activities." This is a very
misleading statement. As stated above, documents and document
flows alone cannot effect a legally-binding business transaction
according to the UMM transaction model (and the cited authorities).
Only the structure and rules of the whole transaction model can
effect a transaction.  (This is the distinction that Jim Clark sometimes
calls "process interaction semantics, instead of message exchange
semantics".

Lines 1672, 2385:
B)  The "isSuccess" property on DocumentFlow appears to pay off
the misconception of issue #1. "An expression whose evaluation 
results in TRUE or FALSE as the determination of whether this 
DocumentFlow should be considered the successful initiation or 
conclusion of a BusinessTransaction."  The Document Flow
cannot determine success or failure of the transaction; only
the Requesting Activity has the right to declare success or
failure.

Lines 527-528 (Figure 5):
C) The Document Envelope has been removed.  A Document Envelope
can support party-to-party security, and can preserve security through
multiple "hops" until it reaches the intended party.  The Document Flow 
is not an adequate replacement, because it only goes from one activity
to another.  For example, the Chemical Industry Data Exchange 
Association (CIDX) has adopted RosettaNet PIPs but has introduced
a Marketplace mode, with the Marketplace as a mediator:  trading 
partners do not deal with each directly, but post and get documents
from the mediator.  Document Envelopes would preserve security
through the Marketplace; it is not clear that Document Flows would
do the same.  The CIDX business process models have the
Marketplace performing activities in the process, that is, a
terminator of a Document Flow (but not a Document Envelope).

Line 586, 1046-1047, 1215, 2529, 2553:
D) The parameter that requires Acceptance Acknowledgements - 
"timeToAcknowledgeAcceptance" - has been moved from 
Requesting Activity to Business Action, a superclass, which means
that Responding Activities may also specify this parameter. This 
parameter should only be specified by the Requesting Activity, 
otherwise the Responding Activity could set the parameter differently, 
defeating the purpose.  In fact, the Requesting Activity has no
Acceptance Acknowledgement signal to return in the same
transaction, so the Responding Activity has no valid use for
the parameter.

One aspect of the UMM transaction model that is sometimes
misunderstood is that it provides atomic (all or nothing) transactional
behavior *only* from the viewpoint of the Requesting Activity.  For the
Requesting Activity to abort a transaction that the Responding
Activity expects to succeed, the Requesting party must send
a Notification Of Failure in a separate Notification transaction.

Lines 1601, 2527, 2551:
E) Similarly, Non Repudiation of Receipt has been moved to Business
Action, and should only be on Requesting Activity (and not on
Responding Activity) for the reasons given under Issue #D above. 

There may well be other issues related to transaction integrity;
those above were the most critical in my opinion.

Respectfully,
Bob Haugen