Re: [bpel4people] ISSUE BP-23: Title: (Re-)Evaluation and instantiation oflogical people groups

[Matthias Kloppmann <matthias-kloppmann@de.ibm.com>]

Alessandro,

I complete agree you here and that the
draft text below is a bit misleading. My *intention* certainly was to only
enforce re-resolution per "value set" of parameters that "has
not been seen before", but not mandate re-resolution for the same
set. Then, "no parameters" are just a special case where re-resolution
is never mandated. In your example, (re-) resolution would be required
for 1) and for 2), and never after.

So, here is a modified version of the
text that reflects that more appropriately:

PROPOSAL: Instances of an LPG are
per set of values for the parameters. Consequently, an LPG MUST be re-evaluated/re-resolved
for each set of parameter values. For the same set of parameter values,
it MAY be re-evaluated/re-resolved.
(Motivation: Allow a modeler to reuse a logical people group, e.g., in
a loop, with different bindings -- the example we discussed was regionalSalesPeople("Wales"),
regionalSalesPeople("Sussex") -- you want to be sure the second
one does not retrieve the former result, unless they are really the same.
Allow in implementation for caching: When regionalSalesPeople("Wales")
is called several times, the result could be cached, because re-resolution
is not mandated.) 
  
Viele Grüße/Kind regards, 
-Matthias

Matthias Kloppmann		E-Mail:	Matthias-Kloppmann@de.ibm.com			Address:	IBM Deutschland Entwicklung GmbH		Vorsitzender des Aufsichtsrats: Martin Jetter
IBM Distinguished Engineer		Phone:	+49 7031 16-3771	(office)			Schönaicher Straße 220		Geschäftsführung: Herbert Kircher
Chief Architect, Business Process Technology			+49 7031 413110	(home office)			71032 Böblingen		Sitz der Gesellschaft: Böblingen
Member, Technical Expert Council CR			+49 160 9060 7676	(mobile)			Germany		Registergericht: Amtsgericht Stuttgart, HRB 243294
"Wisdom begins in wonder." – Socrates

From:	"Alessandro Triglia" <sandro@oss.com>
To:	Matthias Kloppmann/Germany/IBM@IBMDE, <bpel4people@lists.oasis-open.org>
Date:	20.06.2008 05:39
Subject:	[bpel4people] ISSUE BP-23: Title: (Re-)Evaluation and instantiation of logical people groups

---

Here are some thoughts about this
issue and the proposed resolution.
 
The distinction between the two
cases ("function called with same parameters as last time" and
"function called with different parameters") seems artificial
to me.  
 
On one hand, if the standard does
not mandate reevaluation of the people query in the "same parameters"
case, and if the underlying data changes, two different processors may
behave very differently when presented with two identical scenarios (including
timing).  The text proposed below implies that a process that lasts
several days is allowed to ignore changes in the underlying people data
that occur over a period of multiple days, and I don't think this is a
desirable behavior in general.
 
On the other hand, if the standard
mandates reevaluation of the people query in the "different parameters"
case, this may adversely affect performance.  Caching may be useful
both in the case of "same parameters as last time" and in the
case of "different parameters".  For example, a process
could contain the following (unrolled) sequence of invocations:
 
    1) regionalSalesPeople("Wales")
    2) regionalSalesPeople("Sussex")

    3) regionalSalesPeople("Wales")
   
    4) regionalSalesPeople("Sussex")

    5) regionalSalesPeople("Wales")
   
    6) regionalSalesPeople("Sussex")

 
and in a case like this, a processor
could remember the result of query #1 and reuse it (avoiding an expensive
reevaluation) for query #3 and #5, and do the same for query #2 #4 and
#6 respectively.  There is no reason that caching should be limited
to a single set of parameters (and corresponding result) being remembered
by the processor.  I would, in fact, consider this case as the general
case, and the "same parameters as last time" case as being a
special case of a sequence of invocations.  I regard caching as being
a pure internal optimization tactic used by the processor, whenever the
processor deems that the result of a query will be the same as one of those
that occurred in the past, for a given set of parameters, and which it
still remembers.  When a processor knows or suspects that a query
would now produce a result different from the one it produced the last
time it was invoked with a given set of parameters, the processor should
reevaluate the query, and should not reuse the old results (and therefore
the standard should be worded in such a way to disallow the reuse of the
old results in this case; the statement proposed below does not do this).
 
Summarizing, I think that the
"MAY" in the second sentence below is too weak (it may cause
undesirable visible behavior) and the "MUST" in the first sentence
is too strong (it prevents certain optimizations).  My suggestion
is to state that a people query invoked by a processor MUST return a result
that is correct at the time of the invocation (or something like this),
with no distinction between the "same parameters as last time"
case and the "different parameters" case.  This formulation
would allow a processor to use caching whenever it believes that the result
hasn't changed since the last invocation of the query with a particular
set of parameters which it still remembers, and would require evaluation
(or reevaluation) of the query in all the other cases.
 
Alessandro Triglia
OSS Nokalva

---

From: Luc Clement [mailto:luc.clement@activevos.com]
Sent: Tuesday, June 10, 2008 10:27
To: 'Matthias Kloppmann'; bpel4people@lists.oasis-open.org
Subject: [bpel4people] BP-23: Title: (Re-)Evaluation and instantiation
of logical people groups

Assigned: http://www.osoa.org/jira/browse/BP-23

 
From: Matthias Kloppmann
[mailto:matthias-kloppmann@de.ibm.com]
Sent: Tuesday, June 10, 2008 10:22
To: bpel4people@lists.oasis-open.org
Subject: [bpel4people] NEW ISSUE: (Re-)Evaluation and instantiation
of logical people groups
 

TARGET: BPEL4People Working Draft 02

DESCRIPTION: When are logical people groups re-evaluated, in particular
for parameterized logical people groups.

Resolution of logical people groups happens on several occasions: When
referenced from an htd:from clause, or when referenced from a getLogicalPeopleGroup
XPath function. When accessed the first time through either means, a logical
people group is evaluated. In a BPEL4People process, the same logical people
group may be referenced again, possibly with a different set of arguments
values. The specification needs to state what the rules are for re-evaluating
(re-resolving) the logical people group.

PROPOSAL: Instances of an LPG are per set of values for the parameters.
Consequently, when arguments of parameters are changed between referencing
an LPG the first time and the second time, it MUST be re-evaluated/re-resolved.
When parameters are not changed between referencing an LPG the first time
and the second time, it MAY be re-evaluated/re-resolved.
(Motivation: Allow a modeler to reuse a logical people group, e.g., in
a loop, with different bindings -- the example we discussed was regionalSalesPeople("Wales"),
regionalSalesPeople("Sussex") -- you want to be sure the second
one does not retrieve the former result, unless they are really the same.
Allow in implementation for caching: When regionalSalesPeople("Wales")
is called several times, the result could be cached, because re-resolution
is not mandated.) 

Regards,
Matthias