Re: [wsbpel] Issue - 11 - Proposed Resolution for 10/19 meeting

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Chris Keller wrote:

Ron,

 

Even if there is no direct must directive in the specification there are implied musts.  The example of an implementation must do something with regard to WSDL and Schema handling is one.  On the level of the expression languages we have an implied must. The expression language handlers must be able to return a list of variables it will access so that a scope can be properly isolated.  This is true because isolated scopes are mandated by the specification.  As for the new transform function call there are many ways to implement this implied contract.  But I think we should be mindful to the fact that isolated scopes are designed to be deadlock free and so implementations which don’t cache the stylesheet it processed for variable identification could be hazardous.  Now as a user if I want to make a change to the stylesheet I have to do it in a way that the BPEL processor knows to refresh itself.

Yes. Years ago I worked on a workflow engine that allowed for dynamic updates to process definitions. Despite many hours of research, we never discovered a general mechanism for on-the-fly upgrading of in-flight process instances. Instead we kept to a strict "version stickiness" scheme, where process instances included the process type & version in their state data.

Even seemingly trivial changes to a process definition gave rise to a host of issues, making on-the-fly upgrades problematic. I'd suggest that dynamic changes to a stylesheet bound to a doXslTransform call would fall into that same category. Likewise dynamically updated WSDL or XML Schema that is used by a BPEL process definition. Such changes should be regarded as process version changes.

 

Ok, so now on to how we make the passing of parameters via the function call better.  I don’t like the naming convention approach (param1, param2, …).  What if instead we alternated the name and the value like so:

 

doXslTransform('urn:sheets:foo.xsl', $PO, 'Item', $Response.detail.item[1],

                                          'Price', 10,

                                          'Qty', 3)

 

So the definition would be:

 

doXslTransform( uri, source [, paramQName, param]*)

I like this variant. In particular, I like the flexibility in introduces, since parameter values can be determined by XPath expressions, including, as you illustrated, literal values. That has a lot to commend itself in terms of usability. And it doesn't complicate dependency analysis. (Should the param names be literals, or could they be string expressions?)

What do others think of this variant? Too cool for words? :-)

-Ron

 

This allows you to pass many parameters and makes it trivial if you are only trying to transform the source which probably represents most of the use cases.

 

- Chris

---

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Tuesday, October 18, 2005 6:05 PM
To: chris.keller@active-endpoints.com
Cc: 'Alex Yiu'; 'wsbpeltc'
Subject: Re: [wsbpel] Issue - 11 - Proposed Resolution for 10/19 meeting

 

Chris,

Chris Keller wrote:

Hi Ron,

 

As you know I have the same reservations that Alex has.

 

I think we all agree that in general BPEL expressions must be analyzed for their variable access in order to properly handle isolated scopes.  So if one builds an expression handler it is part of the contract with that handler.  Now we are saying that part of the XPath expression language handler contract is that it must also parse and potentially store the XSLT referenced by it as part of a function it provides.

If you are saying that this will cause changes in existing implementations of BPEL, you are indeed correct. Given that bpws:doXslTransform, if accepted, will be an architected function of a required expression language (much as bpws:getVariableProperty is), then it must be appropriately supported by tools and run-time. I don't see this as big problem; parsing XSLT documents isn't difficult. You can even use XSLT to help analyse XSLT documents.

 It seems that the contract implemented by the expression language handler has now stepped into the management of outside resources (not to say caching can’t be done, but caching and management are 2 different things).

We are creating a specification, and should not assume or mandate any implementation details. It seems you are worrying about specific implementation issues. Or do you believe these concerns to be generally applicable to all implementations?

 

WSDL and Schema on the other hand are direct BPEL dependencies and even imported as such.  If we want to put XSLT in this same category then we should say it must also be imported so it can be managed by/for the BPEL.

As an architected part of the language, would the XSLT documents referenced in the doXslTransform calls not fall into this category as well? Or do we need to add some explicit "import" for style sheets?

 

I also believe that by passing the variables (or items within variables) as arguments to the transform function one could gain flexibility by being able to reuse the XSLT with different variables.

This would require some renaming between the variables referenced and the XSLT global parameters. Positional naming is the most straightforward. Using Alex's preferred option 1 (a) syntax:

doXslTransform('urn:sheets:foo.xsl', $PO, 'Item', 'Price', 'Qty')

could map Item to parameter "bpws:param1", Price to "bpws:param2", etc. This does make the style sheet less readable, though.

<!-- Item from BPEL process -->
<xsl:param name="bpws:param1>No item</xsl:param>
...
<xsl:copy-of select="$bpws:param1"/> <!-- is really BPEL Item -->

Or something like that. Is that what you had in mind?

Cheers,
-Ron