bpel 2 proposal

[tom.baeyens]

after some pinging back and forth and a talk with Charles, we agreed that i was going to build a proposal on how the initial structure of bpel would fit into the pvm. i would take the lead on that initial effort. then charles can take over from there.

that work is underway. that is what you can see in the bpel2 source folder.

the old bpel folder still exists for reference purposes, but it is not included in the eclipse project as a source folder.

i'll keep you posted on the progress. still quite some work to do on my end.

[csouillard]

I had a quick look at bpel2 source folder.
I think some things are not well designed concerning bpel concepts...
For example, all classes hosted in process package should not...
It is written in the spec that a process is a kind of scope and many of process children are the same as scope ones...
In the previous bpel source folder, process was a scope and I think it was a good approach.
I know a class can not extends both pvm.Process and Scope. That's why I chose to inherit from Scope as it is closed to bpel concepts...
I know there are some differences between process and scope but many things are common...
Perhaps Process must have a scope field ? => starting a new process is :
- doing special things for the process
- creating and execution the process scope
Perhaps pvm.Process should be an interface ?

[tom.baeyens]

"csouillard" wrote:
I had a quick look at bpel2 source folder.
I think some things are not well designed concerning bpel concepts...
For example, all classes hosted in process package should not...
It is written in the spec that a process is a kind of scope and many of process children are the same as scope ones...

correct. i have focussed on organising the code on top of the pvm code. i did the simplest thing to resolve the compilation problems that originated from this. sometimes this was just removing the inheritence.

so the inheritence is not changed on purpose or by design like it is now.

"csouillard" wrote:

In the previous bpel source folder, process was a scope and I think it was a good approach.
I know a class can not extends both pvm.Process and Scope. That's why I chose to inherit from Scope as it is closed to bpel concepts...
I know there are some differences between process and scope but many things are common...
Perhaps Process must have a scope field ? => starting a new process is :
- doing special things for the process
- creating and execution the process scope
Perhaps pvm.Process should be an interface ?

i was in doubt there too. switching to inheritence from scope and having the process as aggregation is perfect.

[tom.baeyens]

"csouillard" wrote:
not well designed concerning bpel concepts... It is written in the spec that...

One thing that I would like to point out (maybe an open door) is that the BPEL process structure doesn't *have* to reflect the BPEL process as good as possible. It has to provide the best possible execution environment for a BPEL process.

In between the BPEL source process and the way the process is stored in the repository there is the deployment step. That step can be used to transform the bpel process structures into a format that is optimal for execution.

So starting by modelling the bpel process upfront is not a good approach imo (of course, only to a certain extend). Better it is to wait until you implement the runtime behaviour of a feature. Only then you know how the information is used at runtime. That needs to be optimal. The deployment step can always go through great extends to provide that optimal format.

Of course, the resulting model will probably be very close to the bpel model still.

[tom.baeyens]

the work that i wanted to do in bpel2 is done. the flow test is running up to the point where the handler invokes the correlator. the correlator implementation is still empty.

charles, can you let me know if you have other remarks then the one you gave above about the modelling structure of the bpel process elements ?

is there anything that you want me to do before you take over the development lead "token".

i would suggest to focus on finishing the correlator first and only modify/update/change the bpel process structures to accomodate the correlator implementation. that in order to get a full test scenario working first before we start developing the engine in more depth.

[csouillard]

I am a bit surprised by this commit...
If I remember the starting point of the refactoring, the first goal was to help me understanding/moving current code to stick pvm execution...
Next, you worked on your side on a new xml parsing mechanism. This was the second point we wanted to work on for the refactoring.

By now, if I look at the code, all classes are empty and so no execution is possible (so I can not understand how I have to use pvm api to execute bpel processes...). In addition, the new parsing mechanism seems to be great but I think sequenceBinding current implementation is not enough. Activities standards elements and attributes are not managed... So in this way too it is hard for me to deep into new code...

In the previous bpel folder, a lot of work has been done on Message manageent, deployment, correlation (BpelCorrelator), sequential and parallel execution... I can not see that in the current bpel2 folder... Why ? In our previous meeting, we said that before comitting, we must ensure as much as possible that no regression was introcued. I think now, there is one big !

In brief, I was thinking that refactoring would only have updated the current execution (moving/deleting/creating new classes/packages... is not a problem) to make it using correctly pvm api... So all done work was not deleted but updated... The current state is we must restart from scratch for bpel deployment/execution...

As I said in a previous post, I think a process should be a scope and with the current code it is not possible... If we agree on this point, what should we do ? Here we have to make a choice between extending Process or Scope... In that way, I think the initial Node of a process is the process itself (=scope).

[tom.baeyens]

"csouillard" wrote:
By now, if I look at the code, all classes are empty and so no execution is possible (so I can not understand how I have to use pvm api to execute bpel processes...).

imo, we are not there yet. before we can start implementing node behaviours, i think we must have a test strategy in place.

when execution comes up, i can definitely take the lead again to elaborate on that idea.

"csouillard" wrote:
In addition, the new parsing mechanism seems to be great but I think sequenceBinding current implementation is not enough. Activities standards elements and attributes are not managed... So in this way too it is hard for me to deep into new code...

can you be more specific about what you mean with not enough ?

i wanted to add some docs explaining the dry code that is now in the SequenceBinding. is that what you mean or some more things ?

"csouillard" wrote:
In the previous bpel folder, a lot of work has been done on Message manageent, deployment, correlation (BpelCorrelator), sequential and parallel execution... I can not see that in the current bpel2 folder... Why ? In our previous meeting, we said that before comitting, we must ensure as much as possible that no regression was introcued. I think now, there is one big !

that is because i couldn't get the original code refactored to the new design fast. so the approach that i took was to build a proposal from scratch. still the old bpel code is still there in the bpel source folder. we can always switch back.

"csouillard" wrote:
In brief, I was thinking that refactoring would only have updated the current execution (moving/deleting/creating new classes/packages... is not a problem) to make it using correctly pvm api... So all done work was not deleted but updated...

that is how i got started. but i couldn't get the original code refactored to the new xml scheme. also i saw some design decisions for which i wanted to show an alternative.

"csouillard" wrote:
The current state is we must restart from scratch for bpel deployment/execution...

if we opt for going with the new proposal, then some parts will have to be converted/rewritten. but the advantage is that we now have a decent test skeleton. and that the BpelExecution, Executable implementations and parsing are in sync with the pvm approach.

the alternative is that we find a way to do the update of the xml refactoring on the old code.

to avoid this, i'm trying to get a first test case working. and also agree upon the next steps to take. my proposal is now to work on the correlator.

"csouillard" wrote:
As I said in a previous post, I think a process should be a scope and with the current code it is not possible... If we agree on this point, what should we do ? Here we have to make a choice between extending Process or Scope... In that way, I think the initial Node of a process is the process itself (=scope).

this refactoring is ok for me. there is some neuron in my memory that says there was a specific reason why i opted for BpelProcess over the Scope inheritence, but i forgot. I'm ok to go for the scope inheritence approach and we'll bump into the issue again in case that neuron's opinion was based on actual facts.

... ah now i remember. If scope is in the executable hierarchy, scope might not be part of the persisted model but it is stored in descriptor format in the db. ==> it is not an entity, but rather the activities (and hence the scopes) are constructed by the WireScope based on information in the db.

I'm not yet sure how the Scope reusable parts will look like in the light of how executables are stored.

So the best approach to take is the simplest one for now and refactor when we actually start have code to be shared between BpelProcess and Scope.

[csouillard]

I need to have a complete example for using the new xml parsing...
For example, I don't know how I can manage sequence attributes and sequence children to build the object tree...
In the current code, nothing is done in sequenceBinding. Maybe something is done in the general xml parsing but I don't know it very well so it is hard for me to know which things are "automatics" and which have to be done...

I need the parsing stuff to be OK to start working on the correlator as it depends on what we found in the process definition... So I am OK to write both if you give me a complete example...

Concerning BpelProcess/Scope inheritence, I am not sure to understand what you mean about persistence... You said we have to take the simplest approach. Which one it is for you ?

[tom.baeyens]

"csouillard" wrote:
I need to have a complete example for using the new xml parsing...
For example, I don't know how I can manage sequence attributes and sequence children to build the object tree...
In the current code, nothing is done in sequenceBinding. Maybe something is done in the general xml parsing but I don't know it very well so it is hard for me to know which things are "automatics" and which have to be done...

i see. indeed that makes sense.

how much time can i take for this ? do you get in trouble when you have to wait until i deliver this only next week ?

this brings up the question in general. i'm starting to realize that i will be the bottleneck for the comming days/weeks is it a big problem for you if -until then- you can only work on low speed on pvm ? if you have suggestions on how this could be improved, let me know.

"csouillard" wrote:

I need the parsing stuff to be OK to start working on the correlator as it depends on what we found in the process definition... So I am OK to write both if you give me a complete example...

what if i start with creating the parser for the receive ? if we have 1 single receive with the initial attribute set, then we can start moving forward on the correlator.

it would be a great help if you could add some comments in the correlator that explain a little bit the bpel side of things. E.g. in the getNewBpelExecutionStartNode method in the TestCorrelator. That method is invoked when there is no running execution found that matches an incoming message. Could you explain in comments how the actual node should be found and which input data is necessary for that. E.g. scan all nodes for receives with initial set to true. Take the one...

"csouillard" wrote:
Concerning BpelProcess/Scope inheritence, I am not sure to understand what you mean about persistence... You said we have to take the simplest approach. Which one it is for you ?

What i mean is that it doesn't really matter now. We make a choice and move forward until the taken approach needs to be revisited.

Then I tried to look forward and predict where the Inheritence from Scope would lead to a potential problem. We can always refactor at that time (if at that time the predicted problem still exists), so i'm ok with either approach now.

On the persistence side of things, i probably was a bit too optimistic when i said we shouldn't care at all. The way that executables are wired together and also the process variables things that i have already prototyped a bit, are both mechanisms to make generic user code persistable in a fixed process definition schema. So those things are indeed designed with persistence in mind and they should not be so complicated if there was no persistence involved.

Having that said, a lot of that kind of base infrastructure is in place. So I would like to rephrase the initial statement 'never mind persistence' as 'for the most critical parts of the persistence problem, i have proposals solutions ready based on wiring and the process variables component. Apart from that, there are no big issues to be expected. So you guys can develop without persistence in mind and I will keep an eye out for things that might need different treatment to support persistence.'

[csouillard]

This is very good if you can start with the receive activity parsing.
In my side, I will fill the correlator in with the bpel mechanism.

Then with one example, I will be able to do other activities.

[mvaldes]

Lets say so that as soon as Charles get a first sample including both parsing and execution behaviour for a single BPEL element, he can start working on new ones.

imo, this is definitely the first thing to focus right now ! This will indeed allow Charles to challenge the PVM current implementation during each BPEL element implementation.

Basically I see the XPDL development following the same approach...

regards,
Miguel Valdes

[csouillard]

I had a look into ReceiveBinding class and I don't understand how the created descriptors (e.g. portTypeDescriptor) are linked to the current Descriptor (receiveDescriptor).
Is it an automatic link ? If yes how is it done ? Is there something missing in the code ?

[tom.baeyens]

oversight because i just typed in the code without having a test for it...

the link is in the sequenceOperations (just renamed operations to sequenceOperations). All the FieldOperations are injections of configuration values in the in the sequence object. That list of operations is then set in the ObjectDescriptor that builds the sequence object.

[tom.baeyens]

and those additions to the operations list are the things that i initially have forgotten. they are added now.

still untested code, though.

[csouillard]

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 :




...


...





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 ?