-------- Original Message -------- Subject: [DISCUSS] Adding SCA Properties functionality to BPEL implementations Date: Wed, 08 Jul 2009 16:46:34 +0100 From: Mike Edwards <[email protected]> To: tuscany-dev <[email protected]> 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.
