RE: BPSS strategic issue: transaction integrity

[John Yunker <JohnY@EDIFECS.COM>]

Bob,

I could not agree more with the importance you place on the integrity of the
transaction model.  I have added some further clarification and respectfully
disagree with items D and E (more work required :-).

A) Lines 420-421:"business transaction realized as document flows":  You are
correct that the legal basis for the "transaction" includes the agreement,
specification, and metastructure referenced by the specification.  The key
word in the statement is "realized", and if the intent is "instance of
transaction" then the statement is sufficient as is, especially given the
reference within the document control structure to the CPP/CPA and
specification.  I agree that the importance of these references to the
"complete transaction" should be clarified in the document.

B)Lines 1672, 2385: I agree that the requesting party must accept the
responding document in order for the transaction to be successful, however
absent a "notification of failure" the responsder must consider the
transaction successful upon receipt ack (if they sent a positive response).
The document should be corrected to say "An expression whose evaluation ...
successful conclusion of a BusinessActivity"  (see acceptance signal
discussion below)

C) Lines 527-528 (Figure 5): I too would like to see the document envelope
retained.  The content is intended for the activities, the envelope is meant
to control delivery.  Two different objectives performed by different
systems.  Only by modeling the envelope can you properly analyze the transit
requirements (including third party access / responsibility)

D) Line 586, 1046-1047, 1215, 2529, 2553: Acceptance Ack:  I would prefer if
the UMM moved this to the superclass.  There are business scenarios where
the responding role would benefit from formal acceptance of the response.
Currently the acceptance of the response by the requestor is "assumed,
absent a notification of failure".  There are certain types of transactions
where this would be sufficient protection for the responder given the
subsequent business investment they are about to make.

E) Lines 1601, 2527, 2551: Similarly for non-repudiation I would prefer
moving this to the superclass.  In RosettaNet it was assumed that if
non-repudiation of receipt was required for the initiating transaction, then
it was also required for the responding transaction (similar rules for
origin and content).  Either that assumption needs to be explicit in ebXML,
or you need the non-repudiation control on both actions / signals.  The
responder will make business decisions based upon his belief that the
requester has received and ACCEPTS THE CONTENT of his response.  The
responder needs the assurance that his response content will stand up
unaltered.

Bob, thank you for your complete and thoughtful examination of the document.

John

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Wednesday, April 11, 2001 3:53 PM
To: 'ebXML-BP@llists.ebxml.org'
Subject: BPSS strategic issue: transaction integrity


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


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org