[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 Your opinion requested
Ron, Thanks for re-visiting this all in more detail. I too missed the present - but you reiterate the points I made some weeks back. Basically I believe the resolution to this is to create an extensible mechanism - not to lock it down to a couple of options. We know this stuff will change, and we know people will want more. And we can expect implementers to agree on what they want to use themselves. While it makes sense to support simple XPath as a base, and then XQuery and XSLT as alternates, the point you raise about extended business transactions is well founded. You simply cannot do these with a few such script commands. The OASIS CAM team has developed a comprehensive solution - including the ability to specify ExternalMapping in the "node" / "target" fashion in your strawman - but going way beyond that in terms of support for context, rules, structure variations, and more. Most importantly CAM templates are re-usable - and that's key. You'd expect the BP engine to externalize this to loosely couple in the transaction handling. So you could for instance have a CAM template call for handling a PIP or a BOD, and simply call it whenever that function is needed (you could of course do it with any local mapping toolset). So we are back to what that action needs to do. A strawman in XML looks like: <action syntax="XPATH | XQUERY | XSLT | CAM | MY-TOOL"> <input source="inline | URL"></input> <output target="here | URL"></output> <command value="verb(s) | URL"> <fail result="continue | abort | report | other"/> </action> The outcomes on this are that the BPEL profile just needs to ensure that the receiver can actually support the type of action that the script expects, or return message accordingly, such as "No XSLT processor available", etc. Thanks, DW. ======================================================== Message text written by Ron Ten-Hove >Danny, I unfortunately missed your presentation, as I was selfishly enjoying my holidays. However, I've spent some time reviewing the materials you provided for the two proposals, and I have to weigh in with an opinion of -A -B. In other words, I'm not happy with either proposal. Allow me to elaborate. Neither solution will be very good at complex transformations; the term painful comes to mind. (I suggest that for such transformations we should use existing solutions like XSLT, and keep in mind emerging ones, like XQuery.) A further consideration is that (complex) assignments ought to be reuseable. While this is of questionable value for a single BPEL process, it is of much greater utility in constructing families of processes that share the same available services. Finally, both solutions embrace a decidely imperative approach to defining the tree structure of a result, when the <assign> activity itself can contain the tree structure desired in a declarative fashion that is far easier to create and read. Something along the lines of <node from=...> <!-- root node --> <node from=.../> <!-- 1st child of root node --> <node from=...> <!-- 2nd child of root node; or following sibling to 1st child --> <attr from=.../> <!-- attribute for 2nd child --> </node> </node> This uses the XML declaration of the assignment operation to declare the structure of the result, rather than depend on DOM-like manipulations to describe how to arrive at the result. I realise that this is just a list of complaints and partial suggestions; this is not a counterproposal. I suspect that not all of us share the same notions about what <assign> will be use for. Will it be used to construct full-blown XML documents needed for requests (and replies), or will it primarily be used to extract document fragments for internal bookkeeping purposes? -Ron <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]