RE: BPSS strategic issue: transaction integrity

["Welsh, David" <David.Welsh@nordstrom.com>]

Larissa,
I'm using Netfish and you're right, we have a super PIP editor. 
Maybe Bob's refering to something else.

But anyway, I do have another question for you, and I'd also appreciate
hearing any other comments. 

It has to do with the run time aspects of BPSS. 
That being, you describe in your email a little how PIP's don't need to be
hard coded, but could you share with me some vision as to how a 'normal
system' (whatever one of things is today!) might be expected to do with a
BPSS at runtime. 
(I know the word causes some debate) but do I imagine BPSS would drive the
'workflow' you have in products today (maybe via a transform to something
like WF-XML or ..) or ?? What about the BP vision of a BPSS relationship to
CPP/CPA which might be housed in a RegRep, or ...

To sort of come back on Bob's comment/concern in his email.

Thanks
Dave




> -----Original Message-----
> From: Larissa Leybovich [mailto:lleybovich@vitria.com]
> Sent: Thursday, April 12, 2001 8:14 PM
> To: 'Bob Haugen'; 'ebXML-BP@llists.ebxml.org'
> Subject: RE: BPSS strategic issue: transaction integrity
> 
> 
> Bob, 
> In response to your statement that:
> 
> "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."
> 
> I would like to comment that not all the RN PIP software is 
> "hard-coded".
> Vitria's RN solution does NOT have any "PIP hard-coded" 
> components.  Our
> software is based on the generic code (which does not have to 
> be changed to
> each new PIP) that is parameter/table driven and is capable 
> of interpreting
> the XML representations of business processes.  
> 
> Please adjust your research notes to reflect more accurately 
> the state of
> the solution provider's progress.
> 
> Larissa Leybovich
> Vitria Technology
> Supply Chain Solutions
> Irvine         949-857-4233
> Cell            949-836-2545
> Sunnyvale  408-212-2716
> 
>  -----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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>