-
15. Re: bpel 2 proposal
I have troubles with partnerLink management in the parsing. By now, partnerLinks are stores in a Map in BpelProcess class. This is compliant with bpel 2.0 spec which associates partnerLinks to a scope... It is the same case for many other elements (variables, correlationSets, faultHandlers, eventHandlers...).
I want to create these maps into the Scope class. The problem I have is at the parsing time, I do not have access to the real object... I know that thanks to injection mechanism, if I set these maps in the parsing, they will be available at runTime. My problem is I need this king of information at runTime.
Let me take an example : I have a process which has two enclosing scopes :
process
scope name="scopeA"
scope name="scopeB"
partnerLinks
...
/partnerLinks
receive
...
/receive
/scope
/scope
/process
I am trying to build a Map of all startActivities (pick + receive with createInstance=yes).
Let me take the receive example. portType attribute is not mandatory. If it is not defined, we must take the portType designed by the partnerLink... So I need to access the partnerLink list of ScopeB. If I can't find the searched partnerLink, I must look into scopeA and then into the processElement...
How can I have :
1) access to these lists at parsing time ?
2) access a scope father ? -
16. Re: bpel 2 proposal
i didn't work the partnerLinks out completely yet. my proposal is to start with only partnerLinks on the BpelProcess. that way, we can finish the FlowTest first without implementing the complete structure of partner links upfront.
We could implement the partnerlinks model completely upfront, but then the partnerlink and object structure will be based on the spec (=static process definition information) only. While for us it is important that the datastructures are efficient at runtime. Probably they will be the same but I think that taking one use case at a time is a good approach.
i know that the bpel process will need a set of partner links, so that is why i started with putting it there. i also know that probably this will have to be refactored later when scopes and other things will be implemented. but then, we will have a test suite that includes checks for partnerlinks on the bpel process level.
to show the point: i am even ok with --for now-- some hard coded partner link resolution where the partner link name of the flow test example is in the BpelProcess implementation. since we have only one test, this will work and we get the single test running quickly. when we start implementing another process with a different partlink name, that is when we *need* to replace the hard coded partnerlink with a real resolution mechanism. that even doesn't have to be the full spec resolution.
this is just background on my motivation for only starting to implement the partnerlinks on a bpel process level only.
the only thing i wish is that the flow test gets running as quick as possible. we don't need all of bpel implemented fror that. once we have the first test running, we can start building features incrementally or doing refactorings.