Assigning a key to an existing execution

[objectiser]

Have been looking at the javadocs and examples for pvm, and see how a unique key can be associated with an Execution, when created using the startExecution method on ProcessDefinition.

However there is also a startExecution method that does not take a key parameter - does this mean that a key can be associated with an Execution after it has been instantiated (i.e. before it has been persisted)? Cannot see any obvious methods for supporting this.

Also - is it possible to have multiple keys associated with the same Execution?

[kukeltje]

Multiple keys most likely not, unless you make your own tuples by e.g. separating them with a semi-column. But then aain, the default query will probably be '=' and not 'like' so finding them will be more difficult. However, adding your own queries is not that difficult

About assigning one afterwards, I have no info. Looking at the source will probably answer this explicitly.

This reminds me, we maybe have to get a PVM user forum now.... (Tom?)

[objectiser]

I assume at some point the jBPM BPEL runtime will use PVM - from a quick code inspection it does not look like it is at the moment.

In which case, would it not be better to cater for multiple keys directly, as this will be required for BPEL support?

In a related question - if you have two or more sub-processes of the same type being executed concurrently, then the only way to distinguish them would be due to different identities. For example, a process managing 'request for quotes' with a list of suppliers, would possibly use the quote id and supplier id as a composite key.

May be unique identity of sub-executions is not an issue - depends how received messages are routed to an Execution - is this supposed to be handled by specific services made available to the Execution?

So in the case of concurrent rfq executions - each execution may be at a wait state ready to receive a response from the supplier. Would these nodes then be signalled, and check this 'messaging service' to see if the message relates to its particular supplier?

[tom.baeyens]

"objectiser" wrote:
However there is also a startExecution method that does not take a key parameter - does this mean that a key can be associated with an Execution after it has been instantiated (i.e. before it has been persisted)? Cannot see any obvious methods for supporting this.

the key is optional. *if* you supply one, you have to do it in the startExecution method. can't change it after that.

"objectiser" wrote:

Also - is it possible to have multiple keys associated with the same Execution?

then use process variables. the key is like your reference to this execution so that you can look it up based on your key instead of the generated dbid.

[tom.baeyens]

"kukeltje" wrote:
This reminds me, we maybe have to get a PVM user forum now.... (Tom?)

naaaah, then you'll have much too much work in pointing people to the right forum :-)

[tom.baeyens]

"objectiser" wrote:
I assume at some point the jBPM BPEL runtime will use PVM - from a quick code inspection it does not look like it is at the moment.

the bpel code of the new pvm is contributed by Bull. you can find it here: svn://svn.forge.objectweb.org/svnroot/orchestra

"objectiser" wrote:

In which case, would it not be better to cater for multiple keys directly, as this will be required for BPEL support?

how correlation is done is an implementation detail.

"objectiser" wrote:

In a related question - if you have two or more sub-processes of the same type being executed concurrently, then the only way to distinguish them would be due to different identities. ...
May be unique identity of sub-executions is not an issue - depends how received messages are routed to an Execution - is this supposed to be handled by specific services made available to the Execution?

whether you use key's and how you name them is the users' business.

apart from that, there will be a separate link between super and sub process in the activity instance. the class is already there, but that link still needs to be worked out though.

"objectiser" wrote:

So in the case of concurrent rfq executions - each execution may be at a wait state ready to receive a response from the supplier. Would these nodes then be signalled, and check this 'messaging service' to see if the message relates to its particular supplier?

on the PVM level, the link between incoming messages and an API call has to be implented by the user. we will have (note the future tense:-) a set of session facades. a java api session facade, a web service session facade and potentially a message based session facade.

[objectiser]

Thanks for the information.