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


David,

    +1, especially on externalising the mapping. We already attempt to 
loosely couple the process definition to the document types, via properties.

    Is the CAM ExternalMapping solution sufficiently stand-alone that we 
could adopt it for use in BPEL? (I suspect not, but optimism springs 
eternal.)

    With an extensible mechanism, we will have to establish which 
particular mapping types MUST be supported in order to assure 
portability of definitions. It shouldn't be too difficult to come up 
with such a list; I'd suggest XSLT 1.0 and XPath 1.0 for starters. The 
list can be expanded in future versions of BPEL as things like XQuery 
and XSLT/XPath 2.0 are adopted, but not lock implementors into a 
restricted universe of options.

-Ron

David RR Webber - XML ebusiness wrote:

>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.
>=======================================================
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]