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

[tom.baeyens@jboss.com]

"heiko.braun at jboss.com" wrote : I am very much in favor of what you call "Persistent Process Resource", which basically means just storing execution state and history in the DB. 
  | Anything else, and most importantly, all class resources should be retrieved through the classloader. This already answers your question regarding the clustering: Leave it to the deployment/classloading framework of the AS. 
  | 

downside is that this would not support process versioning as we're used to.  (at least not without hacks)  maybe we should consider support this as a separate execution mode.

so if we assume that versioning is done by the client in the process file, then this would really fit the jboss deployer architecture.  (finally !)

"heiko.braun at jboss.com" wrote : But in general we should aim at the plain non clustered AS integration first
  | and then worry about clustering when we need it. You can easily relay questions like this if you leverage the AS infrastructure too a large degree. 
  | 

if possible, we should look at the DB for clustering.  if we stick with that, they our clustering works in any environment.  so those type of solutions are preferrable.

but on top of that, we can always look at how we can improve jboss specific clustering. (like described above)

"heiko.braun at jboss.com" wrote : I do actually have uncommitted AS integration code on my disk, that installs the process engine as a service and adds the corresponding deployers so that you can drop *.par archives into the deploy folder. Quiet similiar to what Bernd described in his Blog, just for AS 5. 
  | 

loading versioned classes lead to real complex solutions.  and i'm not sure if those tricky things are justified.

if a user deploys a new version of a process, it's always possible to update the classnames that are referenced and append _V2 or something to the classname.  users can always reference new classes by pointing to different classnames.  and then we don't have to come up with the very complex classloading to load similarly named classes in different process definition scopes.

"heiko.braun at jboss.com" wrote : I would say, to begin with we should aim at
  | 
  | 1) Persistent Process Resource as execution mode inside the AS
  | 2) Add a service and deployer
  | 3) Fix the classloading (classloader registry, reassociation upon reboot)
  | 4) Deal with different versioning strategies upn deployment and server boot.
  | 
  | We need to get this sorted before diving into clustering topics.

you're forgetting the basic BPM Suite use case: if you want the process versioning to work on every platform to give a non-coding-only-poin-and-click demo, then you need the dynamic persistent use case.  so that should be 0) and for the next efforts, i indeed agree with your list

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

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