Re: [ebxml-bp] Manual Operations in BPSS"

[Duane Nickull <dnickull@adobe.com>]

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