[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Data / BTA Retries - the tale of two camels
John, +1 - we cannot leave this hanging. The good news is that we have really good work like ICE to draw on. Oddly enough during the whole of the original ebXML effort - I wondered where ICE should fit - now we know ; -) ! Cheers, DW Yunker, John wrote: >One more point, if we fail to provide a general mechanism for business set-aside of failed transactions, then each process must explicitly provide for each possible failure case (that contains unacceptable business risk). > >This can make BP difficult to construct, maintain, and understand (seeing the forest for the trees). > >Once again, just making the argument for this staying in the BPSS requirements. > >Thanks, >John > >-----Original Message----- >From: Yunker, John [mailto:yunker@amazon.com] >Sent: Tuesday, September 07, 2004 9:00 AM >To: David RR Webber >Cc: ebXML BP >Subject: RE: [ebxml-bp] Data / BTA Retries - the tale of two camels > > >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 >> >> >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]