[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Call for Discussion
Danny, Good thoughts. Where are we in all this? Does it make sense to have the linkage section merely declare an item line as repeatable - and then in a receive you can assign to linkageItem[next] so it gets slotted in - without having to have this <while> device - which seems so 1960's COBOLesque... Then the linkage area would have the raw content in it. This avoids the need to manipulate too much - even for a simple approach. If you get stuff you don't want you could set an "ignore" flag - so that part of the linkage section does not get piped out. You could even use XPath into the linkage section itself if you want fine resolution there. Next up is the external call itself. If you use the regular <retrieve> mechanism and a WSDL binding - BPEL has no idea this is not just another BPEL engine it is talking to for that step - so that leaves the notion of some "external" call as not external at all... That would be my rough proposal here - for handling external processing of content - ie. write an interface section of the BPEL spec' that allows this provided the external processor is BPEL conformant. DW. ----- Original Message ----- From: "Danny van der Rijn" <dannyv@tibco.com> To: <wsbpel@lists.oasis-open.org> Sent: Monday, February 23, 2004 5:53 PM Subject: Re: [wsbpel] Issue 11 - Call for Discussion > david - > > as i have said before, if you would like to propose a CAM binding, please do > so. > > of course this was a lightweight PO structure - it was an example. that is > NOT to say that the real world doesn't use lightweight PO structures. or > other lightweight structures. i'm trying to fix the deficiency wherein BPEL > needs to call out to CAM or XSLT or other engines for *simple* things that > should be able to be handled internally. > > as i said in the most recent conference call, it is an interesting position > to think about removing assign altogether. but if we're not going to do > that, our mickey mouse set of tools should at least be consistent. > > danny > > ----- Original Message ----- > From: "David RR Webber" <david@drrw.info> > To: "Danny van der Rijn" <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org> > Cc: "Rob Bartel" <Rob.Bartel@igrafx.com> > Sent: Monday, February 23, 2004 2:41 PM > Subject: Re: [wsbpel] Issue 11 - Call for Discussion > > > > Danny, > > > > All I can say is that IMHO your example may work for a mickey mouse > > PO structure like yours - but for real industrial strength PO processing > > this set of 6 or 7 functions in BPEL is laughable. > > > > Go look at the OAGi PO schema for an example or even the UBL > > OP70 one - which is relatively "simple". There's just too many > > interdependencies - and then the kicker is - what do you do > > if when the output XML is supposed to look does not exactly > > match the chunks you have in memory....? > > > > I've said all along here that the real answer is to call a proper > > transaction assembly process like OASIS CAM that has > > all the predicates and functions to handle this. > > > > You still have an issue of how you pass the external process > > the information that BPEL has garnered into memory in its > > simple chunk XML structure variables from its various > > <receive> actions. > > > > At least the six or seven functions may suffice to get you > > a raw block of XML that you can then pipe to that > > external assembly process - so it can complete the > > job for you - but that again still feels clumsy. > > > > On the other hand - if you had a neater way - say via > > the linkage section - to already group these together > > as you get them - then it would be trivial to simply > > pipe that memory collection out - to the assembly > > service for completion. > > > > CAM has the means for you to describe that > > BPEL input layout to it - and then map that > > with a bunch of rules - to the required output > > layout(s) - yes there may be more than one > > depending on who the trading partner is.... > > > > I'm seeing the CAM processor being a web service > > itself - so you'd just call it via WSDL, pass the linkage > > and then the reply back would be the completed > > transaction ready for dispatch. > > > > The V1.0 RC of CAM is now available BTW > > on Kavi. > > > > DW > > Chair OASIS CAM TC. > > > > ----- Original Message ----- > > From: "Danny van der Rijn" <dannyv@tibco.com> > > To: <wsbpel@lists.oasis-open.org> > > Cc: "Rob Bartel" <Rob.Bartel@igrafx.com> > > Sent: Monday, February 23, 2004 5:15 PM > > Subject: Re: [wsbpel] Issue 11 - Call for Discussion > > > > > > > rob - > > > > > > here's a very common example. i have a PO. i need to go through it > line > > by > > > line to construct a PO Response. > > > > > > Variable: PO > > > Part: PO > > > Schema: > > > <PurchaseOrder> > > > <LineItem/> > > > </foo> > > > > > > Variable: POResponse > > > Part: POResponse > > > Schema: > > > <PurchaseOrderResponse> > > > <LineItemResponse/> > > > </foo> > > > > > > <while "there are line items, loop over them"> > > > > > > <assign> > > > <append> > > > <from variable="PO" part="PO" > > > query="/PurchaseOrder/LineItem[loopIndex]" /> > > > <to variable="LineIn"/> > > > </copy> > > > </assign> > > > > > > <invoke operation="ProcessOrderLine" inputVariable="LineIn" > > > outputVariable="LineOut"/> > > > > > > <assign name="AssignResponseLine"> > > > <append> > > > <from variable="LineOut"/> > > > <to variable="POResponse" part="POResponse" > > > query="/PurchaseOrderResponse/LineItemResponse"/> > > > </append> > > > </assign> > > > > > > </while> > > > > > > > > > ----- Original Message ----- > > > From: "Rob Bartel" <Rob.Bartel@igrafx.com> > > > To: "Danny van der Rijn" <dannyv@tibco.com> > > > Sent: Monday, February 23, 2004 12:30 PM > > > Subject: RE: [wsbpel] Issue 11 - Call for Discussion > > > > > > > > > Danny, I think it may be because my return email address is > > > rob.bartel@igrafx.com instead of (in addition to) rob.bartel@corel.com, > > > and Corel (our parent company) is the member, but I tried to post a > > > question last week and it apparently isn't going to come through. > > > > > > I still feel a bit XPATH challenged, and would appreciate an example or > > > two of use. I think I understand what's going on, but an example would > > > help cement it for me. > > > > > > Note, I mean syntax of the use rather than use case. I think you (or > > > someone) made a decent argument for *why* we'd want to do this a few > > > weeks ago. > > > > > > Please feel free to post this to the group if you feel it appropriate. > > > > > > Rob > > > > > > -----Original Message----- > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > Sent: Monday, February 23, 2004 10:29 AM > > > To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' > > > Subject: [wsbpel] Issue 11 - Call for Discussion > > > > > > > > > maybe people are as tired of discussing issue 11 as I am, but if it > > > stays this quiet, I may just have to put up a proposal for vote. Here's > > > the current proposal, which includes additions inspired by Glenn Mi. > > > > > > > > > under the <assign> element, there will be 6 possible > > > elements, where now there is only 1. > > > > > > <copy> > > > <from/> > > > <to/> > > > </copy> > > > as current. > > > ----------------------------- > > > <insertBefore> > > > <from/> > > > <to select="XPath Expression evaluates to one node"/> </insertBefore> > > > > > > creates a sibling before the select expression > > > ----------------------------- > > > <insertAfter> > > > <from/> > > > <to select="XPath Expression evaluates to one node"/> </insertAfter> > > > > > > creates a sibling after the select expression > > > ----------------------------- > > > <append> > > > <from/> > > > <to select="XPath Expression evaluates to one node" > > > child="integer XPath expression"? /> > > > <append> > > > > > > creates a child of select expression at the child-th position. child > > > defaults to last(). > > > ----------------------------- > > > <remove select="XPath expression evaluates to one node"?> > > > > > > removes a node > > > > > > ----- Original Message ----- > > > From: "Danny van der Rijn" <dannyv@tibco.com> > > > To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'" > > > <wsbpel@lists.oasis-open.org> > > > Sent: Wednesday, February 18, 2004 5:10 PM > > > Subject: Re: [wsbpel] Issue 11 - It's Baaaack > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Glenn Mi" <gmi@collaxa.com> > > > > To: "Danny van der Rijn" <dannyv@tibco.com>; "'Wsbpel@Lists. > > > Oasis-Open. > > > Org > > > > (E-mail)'" <wsbpel@lists.oasis-open.org> > > > > Sent: Wednesday, February 18, 2004 4:54 PM > > > > Subject: RE: [wsbpel] Issue 11 - It's Baaaack > > > > > > > > > > > > > Danny: > > > > > > > > > > I start to like your proposal more now. Two points I want to add: > > > > > > > > > > 1) In your <to> construct, it seems that we can just use one of > > > > > > > > > > <to variable="ncname" property="qname"/> and > > > > > <to variable="ncname" part="ncname"? query="queryString"?/> > > > > > > > > > > Or does your select="XPath Expression evaluates to one node" > > > > > actually mean the normal to-spec construct ? > > > > > > > > yes. the normal to-spec, but restricted to variables, and their > > > > parts. i.e. not partnerlinks, etc. in the spec, this is the "first" > > > > form of the to-spec referred to in 9.3, and extended for executable > > > > processes in 14.3 > > > > > > > > > > > > > > 2) And there are cases to insert and remove part of a message > > > > > variable (varable defined as <variable name="abc" > > > > > messageType="ns:xyz"/>). In > > > those > > > > > cases you don't need query string and you don't care about the > > > > > order. So it make sense to have something like: > > > > > > > > > > <insert> > > > > > <from .../> > > > > > <to variable="abc" part="def"/> > > > > > </insert> > > > > > > > > unless i'm mistaken, <copy> can be used here. > > > > > > > > > > > > > > and > > > > > > > > > > <remove variable="abc" part="def"/>. > > > > > > > > you are correct. this should be added. i believe that this is the > > > > only > > > one > > > > of the new 4, though, that should have "select" be optional. > > > > > > > > > > > > > > > > > > > > > > > Glenn > > > > > > > > > > -----Original Message----- > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > > > > Sent: Wednesday, February 18, 2004 3:19 PM > > > > > To: 'Wsbpel@Lists. Oasis-Open. Org (E-mail)' > > > > > Subject: Re: [wsbpel] Issue 11 - It's Baaaack > > > > > > > > > > > > > > > to preempt the pedantic among us, there's a copy/paste error in the > > > > > proposal. it should read: "under the <assign> element, there will > > > > > be 5 possible elements, where > > > now > > > > > there is only 1." > > > > > > > > > > ----- Original Message ----- > > > > > From: "Danny van der Rijn" <dannyv@tibco.com> > > > > > To: "'Wsbpel@Lists. Oasis-Open. Org (E-mail)'" > > > > <wsbpel@lists.oasis-open.org> > > > > > Sent: Wednesday, February 18, 2004 3:16 PM > > > > > Subject: [wsbpel] Issue 11 - It's Baaaack > > > > > > > > > > > > > > > > during today's conference call, we took a straw poll, where > > > > approximately > > > > > > 2/3 voted to attempt to resolve issue 11. (i'll leave the exact > > > > > > count > > > > to > > > > > > the minutes). i would like to resurrect a large part of my > > > > > > previous proposal (i'll drop "rename"). to me, this is a viable > > > > > > proposal, and > > > i > > > > > > would be satisifed if it ended up being adopted into the spec. > > > however, > > > > > > maybe in the months since we last thought about it, someone else > > > > > > has a reasonable alternative. > > > > > > > > > > > > danny > > > > > > > > > > > > My proposal: under the <assign> element, there will be 6 possible > > > > > > > > > elements, where now there is only 1. > > > > > > > > > > > > <copy> > > > > > > <from/> > > > > > > <to/> > > > > > > </copy> > > > > > > as current. > > > > > > ----------------------------- > > > > > > <insertBefore> > > > > > > <from/> > > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > > </insertBefore> > > > > > > > > > > > > creates a sibling before the select expression > > > > > > ----------------------------- > > > > > > <insertAfter> > > > > > > <from/> > > > > > > <to select="XPath Expression evaluates to one node"/> > > > > > > </insertAfter> > > > > > > > > > > > > creates a sibling after the select expression > > > > > > ----------------------------- > > > > > > <append> > > > > > > <from/> > > > > > > <to select="XPath Expression evaluates to one node" > > > > > > child="integer XPath expression"? /> > > > > > > <append> > > > > > > > > > > > > creates a child of select expression at the child-th position. > > > > > > child defaults to last(). > > > > > > ----------------------------- > > > > > > <remove select="XPath expression evaluates to one node"> > > > > > > > > > > > > removes a node > > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the > > > > > > roster > > > of > > > > > the OASIS TC), go to > > > > > > > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > > oup. > > > > > php. > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the > > > > > roster of > > > > the > > > > > OASIS TC), go to > > > > > > > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > > oup. > > > > > php. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the > > > > > roster of > > > > the OASIS TC), go to > > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > > oup.php. > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster > > > > of > > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > > oup.php. > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > > oup.php. > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]