[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Manual Operations in BPSS"
Duane, I was not trying to say what's wrong and critique BPSS today saying that only works in a certain way. What we need here is to think outside the box - figure out the use case presented - and come up with the features needed to deliver that. I'm convinced this would be a significant feature if we can develop it. In anycase - its clear this is something that needs more attention and consideration - that's why I think this is something we add to our task items for V3.0/4.0 timeframe. Thanks, DW. ----- Original Message ----- From: "Duane Nickull" <dnickull@adobe.com> To: "David RR Webber" <david@drrw.info> Cc: <martin.me.roberts@bt.com>; <zbarch@rcn.com>; <ebxml-bp@lists.oasis-open.org> Sent: Tuesday, February 17, 2004 12:59 PM Subject: Re: [ebxml-bp] Manual Operations in BPSS" > Comments inline: > > David RR Webber wrote: > > >Duane, > > > >That's one piece - the issue however is the TimeToPerform in the > >BPSS steps themselves. > > > [DN] That MUST be in alignment with the time to persist value in the > messaging layer since there is a dependency (Unless the BP layer is now > looking at duplicating a persistent message store). BP design should be > aware of the fact that it can pass the values for time to persist down > to the messaging layer where it will be enforced. In any instance, the > TTP must be longer than the sum total of all possible time TTP's that > constitute it. > > >The recovery procedure would need to have flagged each step > >as an "abandon", or "re-start" at design time. So somethings > >could be brought back up, otherwise would be just terminated > >anyway if the recovery does not occur before the TimeToPerform > >expires. > > > [DN] If the system does not recover before TTP expires, then it MUST die > (also see above). The rules must be enforced. IMO - BP must be capable > if expressing that logic in a way that both parties clearly understand > where things roll back to in case something does die. > > >Another design feature may be an independent "its alive" check > >that runs in the background - polling each system periodically. > >If this process detects that certain participants are no longer > >reachable - it could automatically alert others - and signal > >that a restart-check-point should be captured. > > > [DN] Wrong! Persistent connections are not required to indicate that > something is still alive. Unless expressly indicated, I doubt that > someone would agree that all their long standing business processes MUST > die if someone cannot ping them. Remember the requirements doc - cater > to SME's. Not all SME's have persistent connections. Also - we do not > want to penalize someone if their ISP screws up for 5 minutes by rolling > back all their BP's. > > I think you were the one who argued for this back in 2000 ;-) You were > right and we all agreed! > > > But then > >in a loosely coupled system - some participants may just > >poll a drop-box periodically - that was the ICE model - where > >delivery windows are agreed. > > > [DN] It makes sense if the same logic is agreed to by the business > rules. "If you cannot reach my system outside of certain windows, then > my transaction with you must die" is not likely to be a business rule I > would enforce. Instead, I would advocate something like "You must > [accomplish this specific task with measurable results] before [this > pre-determined time] or we both agree that we will roll back this > process to [some previous state including state 0]." Being able to > determine exactly where you both roll back to was an issue with BPSS > 1.01. I am assuming that has been fixed ;-) > > Duane > > -- > Senior Standards Strategist > Adobe Systems, Inc. > http://www.adobe.com > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]