RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause anLPG to evaluate?

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

Ah, interesting -- I have to admit I
hadn't thought of that -- but you are right of course, if there are parameters
and this is the first resolution, there must be a way to bind them. Admittedly,
I don't like the associated complexity for a capability that I consider
a pretty special case (IMO, you'd typically use an assign from logicalPeopleGroup
clause to explicitly trigger LPG resolution, at least in a BPEL process,
and there you already can specify the arguments) ... but still, if we want
the full capability to access LPGs in XPath, too (which was a design goal),
then we need the overloading you describe. So, yes, I agree.

Regarding resolution and re-resolution
vs. running the people query: Not sure whether we agree 100% here or not.
IMO, and I think you are saying the same: When accessed, the LPG should
always provide a "meaningful value", so that means its resolved
on first touch _at_the_latest_ (could in theory be resolved at deployment
time, during process instantiation or at any other time before being accessed).
Whether it is allowed to change its value after that through re-resolution
(such as running a people query) is out of scope in general -- however,
when the LPG received its value through an explicit assignment, the assumption
should be that this value is retained. In all other cases, when you want
to make sure you get a specific set of user IDs, either assign the LPG
into a variable, or use a function such as getPotentialOwners(), but don't
assume the LPG returns the same set of userIDs when accessed at a later
point in time.
  
Viele Grüße/Kind regards, 
-Matthias

From:	"Mark Ford" <mark.ford@activevos.com>
To:	Matthias Kloppmann/Germany/IBM@IBMDE
Cc:	<bpel4people@lists.oasis-open.org>, "'Trickovic, Ivana'" <ivana.trickovic@sap.com>, "'Martin Chapman'" <martin.chapman@oracle.com>
Date:	23.05.2008 15:23
Subject:	RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause an LPG to evaluate?

---

Matthias,
 
Would you agree then that the
function needs to have optional arguments in order to behave the same way
that accessing an LPG in a task would?
 
Something along the lines of:
 
ht:getLogicalPeopleGroup( 'Salesperson',
'region', getInput()/region, 'orderAmount', getInput()/orderAmount )
 
The first argument is required
and it is the name of the LPG. The additional arguments are optional but
if present must come in pairs of literal/expression in the same way that
the bpel:doXslTransform works.
 
I think the spec should clarify
exactly when an LPG should be resolved or re-resolved but it should be
up to the underlying implementation whether or not to re-run the underlying
people query. For example, if you assign to an LPG then you never re-resolve
it. This gives the process designer total control over the value of that
LPG. All other decisions about whether or not to re-resolve the LPG should
be an implementation detail that is under the control of the deployer of
the process which is outside of our scope.

---

From: Matthias Kloppmann [mailto:matthias-kloppmann@de.ibm.com]
Sent: Friday, May 23, 2008 6:35 AM
To: Mark Ford
Cc: bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'; 'Martin Chapman'
Subject: RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup()
cause an LPG to evaluate?


Mark, Martin, all, 

(Unfortunately, I couldn't participate in the 5/14 meeting, so don't know
exactly what was discussed ...) 

However, from my point of view the intention of that function was the ability
to explicitly retrieve the user IDs associated with an LPG, _in_the_same_way_
that using that LPG in a task would do. Specifically, that means that if
the LPG hadn't been resolved yet, it is resolved. 

Also, our original intention was to leave it open (i.e., out of scope for
the spec, as an implementation/optimization detail) when an LPG would actually
be resolved or re-resolved, so whether or not accessing that function (or
using the LPG in a task, which is the same) triggers re-resolution or not
is out of scope. I can see why people would not be happy with leaving that
out of scope, but personally I still think it's a good idea. (As an analogy:
Does BPEL state when a partnerLink is bound to an EPR, or whether it could
be re-bound during execution of a process instance because of changed information
in a registry? Readers of the spec will make their assumptions, but I doubt
[i.e., hope] that it's specified, leaving implementor's and users of BPEL
with different options.)
 
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:	"Mark Ford" <mark.ford@activevos.com>
To:	"'Martin Chapman'" <martin.chapman@oracle.com>, <bpel4people@lists.oasis-open.org>, "'Trickovic, Ivana'" <ivana.trickovic@sap.com>
Date:	15.05.2008 16:24
Subject:	RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause an LPG to evaluate?

---

Martin,

Technically it's not the function's behavior that's different but rather
the
LPG's behavior. Once an LPG is assigned to it is sticky. Therefore any
request for its data will return the value previously assigned, ignoring
any
arguments passed into the LPG for its evaluation.

Based on your comment, I would expect you would raise a similar concern
over
the ht:from and bpel:from logicalPeopleGroup variations since they exhibit
the same behavior.




-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Thursday, May 15, 2008 9:47 AM
To: 'Mark Ford'; bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
Subject: RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup()
cause an LPG to evaluate?

Mark,

A function that behaves differently depending on context, as suggested
in
the last paragraph, is always a bad idea in my opinion.
I'd rather see two different functions, or a parameter requesting evaluation
or not.

Martin.


>-----Original Message-----
>From: Mark Ford [mailto:mark.ford@activevos.com]
>Sent: Wednesday, May 14, 2008 8:54 PM
>To: bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
>Subject: [bpel4people] ISSUE 6: Title: Does
>ht:getLogicalPeopleGroup() cause an LPG to evaluate?
>
>
>The discussion at today's conference call clarified that the 
>original intent for this custom function was to provide a 
>means for getting a value from an LPG without triggering an 
>evaluation of the LPG. The assumption is that the LPG would 
>have been previously evaluated and the process or task 
>definition wants to reference the same value from that LPG to 
>ensure that it doesn't change with another evaluation. 
>
>I don't see the use case for this implementation. If a user 
>wants to ensure that they're getting the exact same values 
>from an LPG then they can use a local variable to store those 
>values and read from that variable. If the function is going 
>to be used within a task definition then the caller would more 
>likely want to pull organizational entities from one of the 
>task's generic human roles as opposed to pulling directly from 
>the LPG. The same would apply if someone were building a four 
>eyes pattern with people activities. It's better to use the 
>b4p functions to pull the values from the generic human roles 
>rather than to try and reuse a value from an LPG. 
>
>The simpler approach is to have one way of accessing LPG data. 
>Each call into an LPG triggers an evaluation of the LPG. The 
>only exception is if the LPG was previously assigned. With 
>this model, an LPG has two states: unassigned and assigned. 
>LPG's are in the assigned state when they are the target of a 
>copy operation. In this state they always returns the same 
>value. An LPG in the unassigned state always evaluates. In 
>this approach, there is no difference between the custom function
>ht:getLogicalPeopleGroup() and the ht:from or bpel:from.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS 
>TC that generates this mail.  You may a link to this group and
>all your TCs in OASIS
>at: 
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

S/MIME Cryptographic Signature