RE: [ebxml-bp] Data / BTA Retries - the tale of two camels

["Yunker, John" <yunker@amazon.com>]

Agree completely, V3 in collaboration with UBAC.

My point was that reliable messaging only removes the need for this capability if there are NEVER NEVER NEVER any system failures (of any kind) that keep partners from being in synch on the business state of a transaction.

John

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Tuesday, September 07, 2004 8:55 AM
To: Yunker, John
Cc: ebXML BP
Subject: Re: [ebxml-bp] Data / BTA Retries - the tale of two camels


John,

This is *most* definately the ICE model.  ICE participants agree to have 
delivery windows, schedules,
conditionals - and known outcomes.

When you join the syndicate you have to abide by the syndicate rules.

This is definately a different model from the classic B2B model - goods 
and services - with pre-defined agreements
on prices and service levels.

I do feel we need to put this to V3 - where we can properly address 
this.  The priority is to get V2.0 for the
largest consituency now - and ability to handle edge conditions.  I feel 
the endsWhen / beginsWhen and variables
give a great deal of flexibility to handle edge conditions.

A whole full-up syndication process though is really not in scope for V2 
- and I fear its confusing to put in a
partial approach - that will only burden us when we tackle this for real 
in V3.

UBAC should look at ICE and tell us if they is what they really want.  
If so - then that's clear.  We should
not be trying to build these things piecemeal here.

DW.

Yunker, John wrote:

>The number of business retries originated with RosettaNet, as a control 
>in uncertain environments.
>
>The business purpose is to formalize an agreement that if the systems 
>involved break down, the behavior of the participants is predictible, 
>both in setting aside the pending agreement and in providing a 
>mechanism for the business to proceed.
>
>The notification of failure is tied in with this as well, so that both 
>parties are protected from assuming the other is going ahead with the 
>transaction.
>
>Remember that both parties are at risk of financial loss if they assume 
>all is well, and because of either protocol or system failure the 
>transaction does not proceed.
>
>Now, if all parties are:
>	1) using reliable reliable messaging (intentional repetition of the word reliable)
>	2) their b2b software has business process capabilities (knows when an owed response is not triggered by their business software)
>	3) have SLA timeouts with notification of partner in their backend or 
>b2b software
>
>Then you can dispense with the retries and NOF.  PLEASE NOTE that if 
>you don't "get" a response to an offer, before just moving on you had 
>better be sure it is not the fault of your own software, or you may be 
>stuck with the merchandise from both the original seller, and the one 
>you moved on to.
>
>These considerations are best considered in the context of business 
>agreements, which is what UBAC is supposed to be working on.  When 
>RosettaNet, the BCF, and early ebXML were being considered, the retries 
>were in the schema to provide a mechanism for the "eventual" business 
>agreements to communicate expected business behavior.
>
>No simple answer here, unless we limit the scope of our considerations.
>
>John
>
>-----Original Message-----
>From: David RR Webber [mailto:david@drrw.info]
>Sent: Tuesday, September 07, 2004 8:18 AM
>To: ebXML BP
>Subject: [ebxml-bp] Data / BTA Retries - the tale of two camels
>
>
>So OK - data validation retries is problematic- but it basically comes 
>down to two strategies -
>
>#1 - if you live in the desert - there is no such thing as an ugly 
>camel.
>
>So you will probably set your system to accept anyones data (eg live 
>new orders for $$$!) - and trap problems at your data handler side - 
>and use something like CAM to tailor transformations to get the order 
>into your order processing system come what may.  You smile and send 
>partners a 'thank you' confirmation.
>
>#2 - you live on the water oasis and you get indundated with people leaving
>        their stinking camels on your front yard and trying to pass off
>their
>        camels on you.  You only want the best camels, with no problems.
>
>So you will probably set your system to automatically warn off bad 
>transactions - so you can deal with real orders from your best 
>customers. You do not have time to fool with one-offs.
>
>In either case a re-try flag is pretty superflous - since neither mode 
>requires retry!
>
>Cheers, DW
>
>  
>