[jbpm-dev] [Design of JBoss jBPM] - Re: process definition as a resource

[camunda]

Heiko wrote : 
  | 1) a changed pdl file, but classes remain the same
  | 2) same pdl, but classes changed
  | 3) changed pdl and classes changed
  | 
  | IMO 1) and 3) should lead to a new version of that process, i.e. demanding an explicit version increment in the pdl, whereas 2) simply associated a different resource set to with process (i think bernd called it patching/bug fixes) 
  | 

I see the use cases a bit different:

1) Fix a process (patching/bug fixing)
  a) with changed classes
  b) with changed jpdl
  c) or both
2) Deploy a rael new version 
  with changed classes
  and with changed jpdl

The distinction between fix and new version cannot be based dependent on the changed artefacts but has to be made from the user.

1a is simply a redeployment on the server
1b creates a new process version of same process in database
2 creates a new process in database and adds the deployment classes.

I would like to keep process db versioning for use case 1b. If you think of long running processes being forced to release a new version (with classes and stuff as a new deployment artefact) just because one state was forgotten seems unhandy for me. And then you have to develop sophisticated mechanisms to undeploy not longer used processes. With the db versioning it just "fades out".

But maybe I am too used to the current process versioning concept already and like it too much ;-) At least I can say, that it is good for marketing to support it ;-)

@Tom: Classloading work pretty well if you correctly use scoped classloading of AS with different parallel versions if the deployer and service take care of it correctly. The deployer I wrote for jbpm 3 works productive at the customer without problems...

For the execution modes: Yeah, differentiate these and support each of them would be quite interesting! 
Even if I would prefer "persistent dynamic"  for most use cases, because then you have all information together in the database (good for reporting or BI as well, or? In fact BI/ETL tools normally talk to databases not to XML files in the classpath ;-)).

But on the other hand persistent process resource could be really an interesting choice for some scenarios, I have to think more about and play with it a bit... What scares me is to loose the foreign keys to the process definition. And I could imagine implementing all the nuts and bolts of it isn't quite easy. And the question is: where is the big advantage of it? But during writing, I start to like it more and more ;-)

The idea about the embedded execution modes are really very interesting, since you find these kind of customer tables quite often and it could provide a good migration strategy towards jbpm :-)

Cheers
Bernd

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210940#4210940

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210940