deployment in JBoss

[bill.burke]

I would like to write a JBoss Deployer for jBPM. Basically it would work like this:

1) Create a table:

create table PROCESS_DEF_HASHES(
name VARCHAR,
hashcode long
);

2) Read the XML file. Create a MD5 hash of the file.
3) select * from PROCESS_DEF_HASHES where name="pd name of file" AND hashcode = MD5 hash
4) If query returns anything, do nothing and return
5) Create new Process Definition
6) Search to see if any old Process Definitions have Instances. If not, delete all the old ones, keep the ones that have process instances.

Sound cool? Then you wouldn't have to have an ANT step and could create bundled, scoped .jbpm archives like we do for EJB, EAR, WAR, ESB, HAR, etc...

[kukeltje]

Yep, sounds cool. afaik, there even is a jira issue for this and some discussion, see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77743&postdays=0&postorder=asc&start=0

Some things to keep in mind or explicitly rule out in the docs:
- whitespace does not necessarily make a process different, but does so for a hash. Normalize?
- different order of elements does not make a process be have different

[bill.burke]

"kukeltje" wrote:
Yep, sounds cool. afaik, there even is a jira issue for this and some discussion, see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77743&postdays=0&postorder=asc&start=0

Some things to keep in mind or explicitly rule out in the docs:
- whitespace does not necessarily make a process different, but does so for a hash. Normalize?
- different order of elements does not make a process be have different

Does really matter as usually redeployment is development phase anyways. Right?

[perrylucas]

Continual Improvement is one of the main benefits you achieve by having a BPM, right? So, I'd say that the deployment and redeployment of process definitions should be encouraged in production, not just during development!

[kukeltje]

Nope, not specifically. Continuous improvement shout happen regardless of BPM. BPM as a process (e.g. supported by six-sigma) achieves this. The consequences for technical redeployment of processes and al that surrounds this, should not be underestimated. Things like: should the already started processes keep running against the version they were started with? Or the new one? What if there are certain incompatibilities, like processvariables needed in the new version are not filled. You can get complex 'migration' projects then where the simple deployment of a process, regardless of the way how to do it, is one of the least issues.