Jonathan Coogan wrote:
Thanks to Michal for fixing this already.
Thanks for filing bugs :-)
I have another question about Assigns and BPEL 2.0 compliance. I have seen
several comments online about how the 2.0 spec requires that variables be
initialized with literal values before they can be manipulated. I was
looking through the spec for confirmation of this and found the following
passages:
8.1
An attempt during process execution to read a variable or, in the case of a
message type variable, a part of a variable before it is initialized MUST
result in the standard bpel:uninitializedVariable fault. This includes the
<invoke> and <reply> activity, where the presence of an uninitialized part
also results in the standard fault bpel:uninitializedVariable.
The point above deals with runtime semantics of process execution.
I think the best that the designer could do is to check if the variable
which appears in any _expression_ has been on the LHS of any copy rule.
This would be be an addition to the validator that could warn of such
being the case. It is not, however, on the list of mandated static
analysis checks that a design tool ought to perform
It is impossible to enforce these things statically in all cases
(consider conditional or flow cases as possible paths of execution).
8.4.2
Using <copy> to initialize variables
When the destination selected by the to-spec in a <copy> operation is
un-initialized, which is either an entire WS-BPEL variable or a message
part, that destination MUST first be initialized before executing the
replacement rules defined above, as if the following has been applied:
* For complex type and simple type variables or message parts, initialize to
a skeleton structure composed of a DII and an anonymous Document Element
EII.
* For element based variables or message parts, initialize to a skeleton
structure composed of a DII and an Document Element EII with the name
matching the element name used in variable declaration.
Again runtime semantics subject to some of the execution path issues
above.
This talks about initializing variables using the assign + copy and
having un-initialized variables in the to-spec.
I guess it seems confusing in that you are in fact trying to initialize
the variable. To me it means that that in the absence of initialization
being done before, there has to be some default initialization that
will take place before the copy rules are applied.
This is confusing! Are there any plans to add special handling for this to
the BPEL designer?
Thank you.
-Jon
On 7/20/07 5:03 AM, "Simon D Moser" <SMOSER@xxxxxxxxxx> wrote:
Hi Jonathan,
no, this needs to be changed when we want to claim full BPEL2.0 compliance.
I guess that has been overlooked until now.
Can I ask you file a bug for that ?
Thanks
Simon
Simon Moser, M.Eng.
Websphere Integration Mail: IBM Deutschland Entwicklung
Developer Development smoser@xxxxxx. GmbH
Team Lead BPEL Editor com Vorsitzender des
Dept. 4722, Bldg. Phone: Aufsichtsrats: Martin Jetter
71032-01, Room 086 +49-7031-16-43 Geschäftsführung: Herbert
Websphere Solutions and 04 Kircher
Services Fax: Sitz der Gesellschaft:
IBM Deutschland +49-7031-16-48 Böblingen
Entwicklung GmbH 90 Registergericht: Amtsgericht
Schönaicherstr. 220, D Stuttgart, HRB 243294
71032 Boeblingen
Jonathan Coogan
<Jonathan.Coogan@
Attachmate.com> To
Sent by: "BPEL Designer project developer
bpel-dev-bounces@ discussions."
eclipse.org <bpel-dev@xxxxxxxxxxx>
cc
07/19/2007 10:50 Subject
PM [bpel-dev] Query queryLanguage
attribute
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
When I assign from an _expression_ to a variable I get the following BPEL..
<bpws:assign name="Assign" validate="no">
<bpws:copy>
<bpws:from><![CDATA[concat('Hello,',
$input.payload/tns:input)]]></bpws:from>
<bpws:to part="payload" variable="output">
<bpws:query queryLanguage="
http://www.w3.org/TR/1999/REC-xpath-19991116
"><![CDATA[/tns:result]]></bpws:query>
</bpws:to>
</bpws:copy>
</bpws:assign>
The BPEL 2.0 spec leads me to believe that the queryLanguage attribute
should be " urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0².
Does this need to be changed or am I missing something?
Thank you.
-Jon _______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|