Minutes
Agenda bashing
approval of 2009-08-20 minutes
meeting minutes approved for Aug 20th call.
Resolution: minutes of 2009-08-20 telcon located at http://lists.oasis-open.org/archives/sca-bpel/200908/msg00041.html
approved
AI review
New issues
Danny moves to open issue #56; anish seconds.
<Mike Edwards>
The discussion is absolutely about whether the issue is an issue
Resolution: issue 56 is now open
Danny:
Initialization of properties needs to extended to multi reference variable initialization.
Danny moves to open #57; Najeeb seconds
Resolution: issue 57 is now open
issue 52
Anish:
Change SBPEL2004.2 to use "sca:reference" @name attribute
Mike Edwards:
Always, use partner link name as the name of the multi-valued reference.
<anish>
30004 is a little convoluted
<Mike Edwards>
one way to model the multi-ref initialization would be to represent the extension as a) a simple extension attribute on the
variable declaration element
<Mike Edwards>
and b) the initialization of the variable be represented by an extension child element of the variable declaration that in
effect is an extended <from/> element, similar in form to the standard <from/> element
<Mike Edwards>
which I think addresses one of the points made by Danny in our earlier discussion
<Mike Edwards>
since the idea of the SCA initialization of these variables is precisely that of an extended form of initialization, where
the data for the initialization is coming from a source outside the process
<anish>
this is making me think, are multiRefs such a mismatch to BPEL?
<anish>
if so, what if we didn't support them in BPEL C&I?
<Mike Edwards>
they are not a mismatch to BPEL at all
<Mike Edwards>
BPEL spec describes the assignment of an EPR to a partnerLink variable
<Mike Edwards>
so the EPR had to come from somewhere - and the somewhere is a variable of some kind
<Mike Edwards>
the BPEL spec even has a datastructure type to hold these EPRs
<anish>
k, understood. I was mostly thinking aloud. It seems like multiRefs stumps everyone. I had to explain to some of our devs
how they work, as they were completely baffled about it
<Mike Edwards>
we *could* make it illegal
<Mike Edwards>
ie multirefs for BPEL
<anish>
that is what I was pondering
<anish>
whether that makes more sense
<anish>
and simplifies the spec quite a bit
<Mike Edwards>
but you might ask your devs to think about the case where a process needs to get some data from a set of equivalent services
- eg a set of prices for some widgets
<Mike Edwards>
from a whole series of suppliers
<anish>
i don't think the problem is the usecase
<Mike Edwards>
that looks to me like a sequence of calls
<Mike Edwards>
using the same partnerlink in a loop, with the target EPR changing each time you go round the loop
<anish>
the problem is that everyone seems to stumble on it and the BPEL-centric folks certainly don't get it right away
<Mike Edwards>
so then, where did the list of EPRs come from?
<Mike Edwards>
if we use the wired-by-Impl paradigm, the list *could* have been sent to the process in a service invocation
<Mike Edwards>
ie it arrives as the value of a message variable on a receive, say
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-BPEL TC...' was assumed
statistics: Schreiber found 113 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 140: anish: s/then/them/
citation-detection-irc1: Line 4: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 12: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 24: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 27: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 34: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 35: Check for possible unrecognized nick 'Initial proposal'
citation-detection-irc1: Line 42: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 44: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 45: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 46: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 47: Check for possible unrecognized nick 'Proposal'
citation-detection-irc1: Line 48: Check for possible unrecognized nick 'Proposal v2'
citation-detection-irc1: Line 52: Check for possible unrecognized nick 'BPEL Process'
citation-detection-irc1: Line 53: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 54: Check for possible unrecognized nick 'Proposal'
citation-detection-irc1: Line 57: Check for possible unrecognized nick 'sca-bpel'
citation-detection-irc1: Line 58: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 59: Check for possible unrecognized nick 'Proposal'
citation-detection-irc1: Line 63: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 64: Check for possible unrecognized nick 'Proposal'
citation-detection-irc1: Line 68: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 73: Check for possible unrecognized nick 'http'
command-scribe: Line 86: Najeeb Andrabi recognized
command-scribe: Schreiber detected that this section was scribed online
edit-substitute: command on line 140 succeeded, changed line 138 from 'then' to 'them'
edit-delete: Line 140 was deleted
system: Transformer: SAXON 9.0.0.2
[End of Schreiber diagnostic output]