RE: [ebxml-bp] 12/7/2003: [Fwd: "Late Binding" of TimeToPerform]

[nagahashi@fla.fujitsu.com]

JJ,

Thanks for making comments on my posting... I know I'm doing terrible in 
discussing subtle points in this kind of work. During phone conference, 
I often get exhausted by following the discussion and get paralyzed when 
I try to speak out X-)

> Kenji:
> 
> *  I prefer the approach that BPSS has only one flow and actual 
> TimeToPerform is specified elsewhere -- in CPA or message header (a la 
> SBDH) etc. 
> <JJ>This is why we have the notions of packages and substitution sets, 
but this is a design time mechanism, not a run-time mechanism</JJ>

<KN> Yes it is a run-time mechanism. and I thought the Lars's original 
point is that there might be the case where user wants to defer the 
actual parameter "binding" to runtime.

> 1)  If we take "branch for different TTP" approach, BPSS engine have 
to 
> detect which branch the process have chosen (this poses another 
problem) 
> and maintain the state for the branch -- just for having different 
> TimeToPerform.
> <JJ>I don't see how this can be anymore complex than any other fork/
join, am I missing something?</JJ>

<KN> point is "just for having different TimeToPerform". If fork/join 
correspond to fork/join in business process flow, it is fine.
Of course you can argue that different TimeToPerform means we have a 
fork/join in the business process, though. It is matter of how people 
wants to model it...

> <JJ>
> Based on the following paragraphs, we have to be very careful in 
introducing run-time dependencies on the BPSS definition (via variable 
or any other means). This could defeat the purpose of "agreements". 
Maybe the agreement would happen on ranges rather than specific values.

<KN> That's a good point (although I can argue, being devil's advocate, 
"TTP is determined at runtime" is a kind of "agreement" --- use of 
variable indicates it.) I agree with you that agreement would happen on 
ranges---then it means specific value should be specified at runtime, 
too.

> I don't see your point about variable, are you suggesting that it is 
better to use rules that overwrite existing values, rather than tie the 
rule to a variable? If this is the case, I agree with you that this kind 
of approach is superior to the variable mechanism.

<KN> I may have gone to far with the paragraph. My point was "whatever 
the overriding (context, as David say) mechanism would be, the mechanism 
should reference BPSS instance, not opposite." I read the CAM draft and 
had an impression that it might require embedding such variable 
references. I'll wait for David to give more information on this.

Best,
Kenji