OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]