bpel4people message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause anLPG to evaluate?
- From: Matthias Kloppmann <matthias-kloppmann@de.ibm.com>
- To: "Mark Ford" <mark.ford@activevos.com>
- Date: Fri, 23 May 2008 12:34:30 +0200
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]