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

["David RR Webber" <david@drrw.info>]

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
>
>
>
>