Folks,
In order for the Tuscany BPEL implementation to conform to the requirements of the OASIS SCA BPEL
Implementation specification, it is necessary for the BPEL implementation to support SCA properties
in the BPEL process.
For the SCA BPEL implementation spec, a BPEL process variable is marked as an SCA Property (which
then forms part of the component type of the BPEL implementation), using an @sca-bpel:property="yes"
attribute:
<variable name="testName" type="xsd:string" sca-bpel:property="yes"/>
...where sca-bpel is the prefix referring to an SCA namespace:
xmlns:sca-bpel="http://docs.oasis-open.org/ns/opencsa/sca-bpel/200801";
So far, so good. Recognising the presence of SCA Properties in a BPEL process is a simple task of
introspection and merely involves extending the BPELDocumentProcessor code to introspect <variable/>
elements in the BPEL Process document.
The far more tricky part is the handling of actually injecting the SCA Property values at runtime,
when the component is initialized.
The problem is basically that ODE provides no straightforward hooks for the Tuscany code to use in
order to inject the value data that it has for the variables that are identified as SCA properties.
So what possible design points are there for providing the property values?
1) Modify the BPEL Process code on-the-fly and add an initializer <from/> statement to the variable
declaration for the variable corresponding to the SCA property.
This would mean something like this:
Starting with a variable declaration like this:
<variable name="testName" type="xsd:string" sca-bpel:property="yes"/>
This would be modified on the fly to something like this:
<variable name="testName" type="xsd:string" sca-bpel:property="yes">
<from><literal>Some_String</literal></from>
</variable>
... where "Some_String" is the value supplied by the component for the property.
PROBLEM: Initializers of this kind are only supported in the latest SNAPSHOT version of ODE, even
though variable initializers are a mandatory part of the BPEL specifications :-(
2) Modify the BPEL Process code on-the-fly and add an <assign/> statement at the start of the
activities in the BPEL process, assigning the SCA property value to the corresponding variable in
the BPEL process.
So, with a variable declaration like:
<variable name="testName" type="xsd:string" sca-bpel:property="yes"/>
...this would mean adding an assign operation like this:
<sequence>
<assign name="SCAProperty_Initialization">
<copy>
<from><literal>ASM_4001</literal></from>
<to variable="testName"/>
</copy>
</assign>
...
This should work OK, with the small fly in the ointment in that the first Activity within a BPEL
process is not guaranteed to be a <sequence/> (although it will be in most cases)
3) Modify ODE to accept Tuscany extension code for the sca-bpel:property
attribute.
In the latest ODE SNAPSHOT code, there is provision for extension ELEMENTS of some kinds, causing
external (non-ODE) code to get invoked at appropriate points when those extension elements turn up
in the BPEL process definition.
We could work with ODE folk to extend this idea to allow for invocation of extension code when the
presence of extension attributes is detected. Effectively, this would imply invoking some Tuscany
code when the BPEL process variables come into scope at runtime - and then the Tuscany code would
use ODE interfaces to assign a value to the variable in question.
This is probably the best design in the long run but depends on unstable ODE code and also depends
on getting agreement from our friends in the ODE project to accommodate a few changes in their core
runtime code (and probably also in their BPEL Compiler code too).
PROPOSAL
I'd like to get Option 2) running immediately since it requires no use of ODE
SNAPSHOT code.
It may have some limitations in the short run while we work through the various possible initial
activity sequences for BPEL processes, but in principle it should be workable for all possible
activity sequences.
In the longer run, I'd like us to go with Option 3), assuming we can get the agreement of the ODE
folks. Failing that, then we can migrate to Option 2) at the point we decide the current ODE code
(2.x) is stable enough for us to use.
Yours, Mike.
