[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [sca-bpel] Raw Chat SCA BPEL Telcon Aug 27, 2009
anonymous morphed into anish anish: agenda -- anish: 1. Roll Call http://www.oasis-open.org/apps/org/workgroup/sca-bpel/members/roster.php
2. Appointment of scribe Scribe list attached below
3. Agenda bashing
4. Approval of Aug 20, 2009 minutes http://lists.oasis-open.org/archives/sca-bpel/200908/msg00041.html
5. Action Items review
#0103 create alternate proposal for Issue 52 -- Najeeb DONE
#0104 send new proposal for issue 41 -- Anish PENDING
6. New Issues a) Issue 56 - No scoping rules specified to resolve variable name referred by sca-bpel:multiRefForm extension for the partner link http://www.osoa.org/jira/browse/BPEL-56
b) Issue 57 - No initialization mechanism specified for the variable with sca-bpel:multiReference extension http://www.osoa.org/jira/browse/BPEL-57
7. Issue Discussion 7 open issues
a) Issue 52 CT generation (section 2.1.1) does not take into consideration the multRefFrom attribute http://osoa.org/jira/browse/BPEL-52 Initial proposal: http://lists.oasis-open.org/archives/sca-bpel/200907/msg00037.html Addendum to the proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00014.html Proposal from Anish: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00035.html Alternate proposal from Najeeb: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00049.html
b) Issue 41 SBPEL2022 has an incorrect 'MAY' and is not applied recursively http://www.osoa.org/jira/browse/BPEL-41 Email discussion - http://lists.oasis-open.org/archives/sca-bpel/200905/msg00035.html http://lists.oasis-open.org/archives/sca-bpel/200905/msg00041.html http://lists.oasis-open.org/archives/sca-bpel/200905/msg00044.html Proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00011.html Proposal v2: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00036.html Awaiting proposal v3 from Anish
c) Issue 53 BPEL Process: References with Multiplicity 0..1 - how are they supposed to work? http://osoa.org/jira/browse/BPEL-53 Proposal: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00021.html
d) Issue 54 sca-bpel:multiReference/@partnerLinkType and sca-bpel:multiReference/@partnerRole cardinality http://osoa.org/jira/browse/BPEL-54 Proposal: in Jira
e) Issue 55 Co-occurrence constraints on sca-bpelroperty attribute and sca-bpel:multiReference element http://osoa.org/jira/browse/BPEL-55 Proposal: in Jira
f) Issue 46 SBPEL3006 isn't deterministic http://osoa.org/jira/browse/BPEL-46 no proposal
g) Issue 50 Need more examples in the specification http://osoa.org/jira/browse/BPEL-50 no proposal
8. AOB anish: Chair: Sanjay Patil anish: Date: 2009-08-27 anish: Agenda: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00050.html anish: ScribeNick: Najeeb Andrabi anish: Scribe: Najeeb Andrabi Najeeb Andrabi: Agenda approved. Najeeb Andrabi: meeting minutes approved for Aug 20th call. Najeeb Andrabi: AI 103 and 104 done. Najeeb Andrabi: Danny moves to open issue #56; anish seconds. Najeeb Andrabi: Issue #56 is now open. Najeeb Andrabi: motion passed. Mike Edwards: The discussion is absolutely about whether the issue is an issue Najeeb Andrabi: Danny: Initialization of properties needs to extended to multi reference variable initialization. Najeeb Andrabi: Danny moves to open #57; Najeeb seconds Najeeb Andrabi: motion passed. Najeeb Andrabi: Issue #57 is now open. Sanjay: Alternate proposal from Najeeb: http://lists.oasis-open.org/archives/sca-bpel/200908/msg00049.html Najeeb Andrabi: Anish:Change SBPEL2004.2 to use "sca:reference" @name attribute Najeeb Andrabi: 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 then in BPEL C&I? anish: s/then/them/ 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 Mike Edwards: that variable then contains a list of EPRs and I assign them one at a time to the partnerLink Mike Edwards: I think that our SCA multi-ref variables are the exact parallel to this Mike Edwards: except that SCA provides the set of EPRs on a plate rather than having to use a receive anish: i don't disagree Mike Mike Edwards: ok, good anish: i think we'll have to do a better job of explaining this in teh spec anish: cause readers get stumped on it Mike Edwards: oh, I can agree with that Mike Edwards: it may be useful to start with a scenario just like the one I described here anish: +1 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]