Hi Ron,
The problem
with the statement: “Note that
analysis of dependencies is trivially accomplished at run-time, even if
style
sheet names are dynamically determined.” Is that it
may be too late to apply the information correctly. The
problem cases are isolated scopes in that they must lock variables so
they won’t
be changed by other logic executing in parallel. In order to do that
you
have to proactively prevent other activities from executing which may
change
the accessed variables once you enter the scope. And I believe a
reactive
runtime based analysis wont work. Given that someone can change a
stylesheet outside of the BPEL engine, even a constant for the URI may
not be
sufficient. So that leads us to option 1 if we want to handle isolated
scopes correctly.
- Chris
From: Ron
Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Monday, October
17, 2005
10:12 AM
To: Alexandre Alves
Cc: wsbpeltc
Subject: Re: [wsbpel]
Issue - 11 -
Proposal (after off-line discussions)
Based on this, and some
off-line conversations, we
seem to have two paths shaping up for conveying BPEL variable values to
the
XSLT processor (via global parameters) for read-only access:
Add BPEL-based Declaration of BPEL Variables
This might look like the
following (based on the
second example in the proposal, with a message variable part thrown in
for
fun):
bpws:doXslTransform('urn:stylesheets:AddToPO.xsl',
$PO,
$OutVar,
$MsgVar.PartName)
Only the named variables (in
parameters 3 and up) can
be mapped to like-named XSLT global parameters (e.g., "OutVar"
or "MsgVar.PartName").
Advantages:
- Explicit
control of variables made available to the XSLT engine.
- Improved
readability; the reader need not consult the style sheet to discover
which variables will be read by the XSLT engine
- Static
analysis of the process can facilitate optimized implementations of
both atomic assignment and serialized scopes (as applicable)
Disadvantages:
- More
verbose.
- Violates
the DRY (Don't Repeat Yourself) principle. Adding or removing a BPEL
variable from the XSL style sheet requires two co-ordinated changes
(style sheet global parameters and BPEL process).
Leave Proposed XSLT-based Declaration of BPEL
Variables
This is what was proposed last
week. This depends on
name matching between the style sheet's global parameters and in-scope
BPEL
variables.
Advantages:
- Less
verbose
- Conforms
to DRY principle. Adding or removing a BPEL variable from the XSL style
sheet requires a single change to the style sheet only..
Disadvantages:
- Static
analysis of variable dependencies depends on the assumption that style
sheets are named using literals, and the named style sheet doesn't vary
(i.e, the URI used to name the style sheet indicates an non-varying
resource).
- Decreased
readability
Note that analysis of dependencies is trivially accomplished at
run-time, even
if style sheet names are dynamically determined. If style sheet names
are not
dynamic (that is, they are literals) then this analysis can be done
earlier.
Worrying about dynamic changes (during run-time) to resources indicated
by URIs
is a problem that applies to WSDL, XML Schema, and BPEL already; our
specification is deliberately silent about how such issues are handled
(leaving
it to implementations to address this as they wish).
-Ron
Alexandre Alves wrote:
Hi
Ron,
I think that
not only it affects the
‘atomic assign’ requirement, but it also can potentially prevent
implementations from optimizing for isolated scopes. If I am not
mistaken, one
of the benefits of issue 103 was to facilitate static analyses of
variable
usage (i.e. by removing the getVariableData() function, etc).
In light of
that, I am in favor of some
explicit option. If we were to go with option (2), I would suggest also
allowing the user to specify a message part (OutVar.partA), as we’ve
defined them to be (conceptually) separate documents.
Best regards,
From: Ron
Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Wednesday,
October 12, 2005
9:32 AM
To: wsbpeltc
Subject: Re: [wsbpel]
Issue - 11 -
Proposal (after off-line discussions)
Folks,
Following up on this morning's TC meeting, Danny pointed out that we
need to
address the issue of how this proposal affects the "atomic
assign" requirement of WS-BPEL. The problem reduces to the question:
how
and when can the BPEL processor determine which WS-BPEL variables are
to be
read for transfer to XSLT global parameters? This is an interesting
question,
touching on run-time semantics of the WS-BPEL data model.
The following approaches occur to me:
- Say
nothing explicit about how doXslTransform fits into this; let
implementations figure out how to honour the "atomic assign"
requirement. A processor can do one or more of the following
- be
pessimistic (lock all variables in scope),
- analyse
the style sheet at run-time, determining all process variable name
matches,
- if
static analysis is possible, analyse the style sheet at compile or
deployment time,
- find some other means of ensuring the
atomicity requirement.
- Be
explicit about how implementations shall behave:
- We
could include a list of process variables that can be mapped to XSLT
parameters, eg:
bpws:doXslTransform('urn:stylesheets:AddToPO.xsl',
$PO,
'OutVar FooBar')
which
declares that only
BPEL variables "OutVar" and "FooBar"
can be read by the XSLT processor (via the global parameter mechanism).
I'm sure there are other
approaches. Ideas? Thoughts?
Best regards,
-Ron
Ron Ten-Hove wrote:
Folks,
Last week I sent out a message outlining three related variants to
a solution for issue 11. This message details one of those variants
(the XPath
extension function), as further developed by a subgroup of our TC. This
serves
as an update to the proposal I made last week, amending Ugo's proposed
solution
for issue 11.
This proposal has two parts: proposed changes to the
specification, and a couple of illustrative examples.
My thanks to all those who helped develop this proposal. (All
the good stuff came from them; the typos are all mine. :-)
Best regards,
-Ron
P.S. A warning: this is best viewed using an HTML-enabled mail reader.
Plain
text will likely be a bit messy, and harder to read.
Section 9.4: append the following:
The above copy mechanism, when
combined with the
default XPath 1.0 expression language, cannot perform complex XML
transformations. To address this restriction in a portable fashion, a
WS-BPEL
processor MUST support the bpws:doXslTransform()
XPath 1.0
extension function, as described in the following paragraphs.
Function signature: Object
bpws:doXslTransform(String,
node-set)
where:
- The
first parameter (an XPath String) provides a URI naming the style sheet
to be used by the WS-BPEL processor.
- The
second parameter (an XPath node set) provides the source document for
the transformation to be performed by the WS-BPEL processor. This set
must contain a single EII (i.e. an element node in XPath 1.0 data
model); if it does not, the WS-BPEL processor MUST throw a bpws:invalidXsltParams
fault. The single EII as specified by this parameter MUST be treated as
the single child of the root node of the source tree for XSLT
processing.
- The
result of the function MUST provide the result of the transformation.
It will be one of the following infoset items, depending on the XSLT
output method employed by the selected style sheet:
- A
single TII (an XPath 1.0 text node), created by the "text" or "html"
output methods, or
- A
single EII (an XPath element node that is the single child of the root
of the result tree), which is created by the "xml" output method.
The WS-BPEL processor MUST
execute the bpws:doXslTransform
method such that all of the following apply:
- The
first parameter, naming the style sheet to be used, MUST be used to
find the style sheet corresponding to the given URI. This is
accomplished in an implementation-dependent fashion. If the style sheet
corresponding to the given URI cannot be found, the WS-BPEL processor
MUST throw a bpws:invalidXsltParams
fault.
- The
processor MUST perform an XSLT 1.0 transformation, as described in
section 5.1 (Processing Model) of the XSLT 1.0 specification, using the
named style sheet as primary sheet sheet, the provided root node as the
source document, and the result tree as the result of the
transformation.
- Global
parameters (section 11.4 of [XSLT 1.0]) are used to pass BPEL variables
to the XSLT processor. XSLT global parameters are matched to BPEL
variables by name.1 The WS-BPEL processor MUST map BPEL
variables that are accessible in the scope of the activity containing
the bpws:doXslTransform
function call to the global parameters declared in the style sheet. A
global parameter that does not have a matching BPEL variable name MUST
retain its default value, as declared in the style sheet. A WS-BPEL
processor MAY warn users of any top-level parameters in the named style
sheet not matched by in-scope WS-BPEL variables.
- Any
XSLT processing faults that occur during the transformation MUST result
in a bpws:subLanguageExecutionFault
being thrown.
Note that because XSLT is a
side effect-free language,
execution of the transformation cannot (by definition) cause any
changes to
BPEL variables referred to in the style sheet.
1 Note that XSLT global parameters must use NCNames to
order to
match the NCNames used for BPEL variable names; QNames will not match.
Section A (Standard Faults):
add the following faults
to the table:
|
Fault Name
|
Reason
|
|
invalidXsltParams
|
An invalid parameter was
provided for a bpws:doXslTransform
function call
|
bpws:doXslTransform Example
Complex
document transformation. A
common pattern in BPEL processes involves a sequence of receiving an
XML
document from one service, converting it to a different schema to form
a new
request message, and sending the new request to another service. Such
documentation conversion is easier accomplished using XSLT, using the
doXslTransform function For example:
<variables>
<variable name="A"
type="foo:AType"/>
<variable name="B"
type="bar:BType"/>
</variables>
...
<sequence>
<invoke ...
inputVariable="..." outputVariable="A"/>
<assign>
<from>
<expression>
bpws:doXslTransform("urn:stylesheets:A2B.xsl",
$A)
</expression>
</from>
<to
variable="B"/>
</assign>
<invoke ...
inputVariable="B".../>
</sequence>
In the sequence, a service is
invoked, and the result (of
type foo:AType) copied to variable A. The assign activity is used to
transform
the contents of variable A to type bar:BType, and copy the result of
that
transformation to variable B. Variable B is used to invoke another
service.
The style sheet A2B.xsl would contain the XSL rules for converting
documents of
schema foo:AType to schema bar:BType.
Iterative document construction
and BPEL
variable access. Suppose that we are constructing a document
by
repeatedly calling a service, and accumulating the result in an XML
variable.
The loop might look something like this:
<variables>
<variable name="PO"
type="foo:POType"/>
<variable
name="OutVar" type="foo:ItemType"/>
</variables>
<!-- ... PO is initialized ... -->
<!-- Iteratively add more items to PO until
complete -->
<while>
<condition>...not
done...</condition>
<sequence>
<!--
Fetch next chunk into OutVar -->
<invoke ...
inputVariable="..." outputVariable="OutVar"/>
<assign>
<from>
<expression>
bpws:doXslTransform("urn:stylesheets:AddToPO.xsl",
$PO)
</expression>
</from>
<to variable="PO"/>
</assign>
</sequence>
</while>
To allow the XSLT style sheet
access to the OutVar
variable from the BPEL process, it must contain a global (top-level)
parameter
with the same name:
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- OutVar variable from
BPEL process; defaults to empty
item
-->
<xsl:param name = "OutVar"><item/></xsl:param>
...
</xsl:transform>
The style sheet would contain
a template similar to the
following, responsible for appending OutVar
(the new item) to the existing list of items in the PO variable.
<xsl:template
match="item">
<!-- line 1 -->
<xsl:copy-of
select="."/>
<!-- line 2 -->
<xsl:if test="position()=last()">
<!-- line 3 -->
<xsl:copy-of select="$OutVar"/>
<!-- line 4 -->
</xsl:if>
<!-- line 5 -->
</xsl:template>
<!-- line 6 -->
This template copies all
existing items in the source
document (lines 1 & 2), and appends the contents of the BPEL
variable OutVar
to the list of items (line 3 tests to see if the current node is at the
end of
the item list; line 4 copies the result-tree fragment from the BPEL
variable OutVar
to follow the the last item. Thus, if PO
has a value of:
<po><item>item
1</item></po>
at the beginning of an
iteration of the the above
loop, and the <invoke> activity
returns a
value of <item>FooBar</item>,
evaluation of the <from> expression
will result in a value of:
<po><item>item
1</item><item>FooBar</item></po>
which, when the BPEL copy
activity is complete, will become the new value of the PO
variable.