This is based on my understanding that a process definition is an immutable entity, which is defined in XML.
process definitions can be considered as immutable, correct.
The state of running processes is persisted in the database. For many a reason It cannot be expected that jBPM can be updated for running proccess.
there are two types of migration
1) migrating a process instance to a new process definition in the same jBPM installation
2) migrating the complete jBPM database to a new major version (3.x to 4)
In the general case, process instance migration is too complex, as you don't know to what extend the new process definition will look like the old one.
However, in the majority of use cases, the updates to the process are fairly limited.
If we provide a process instance migration that takes into account an optional node-name-mapping, then I think we have covered the 80% of the migrations with 20% of the effort.
Migrating the runtime state is doable IMO. The logs and history is always too complex.
What I think we definitely should consider is process instance migration from 3.x to 4. Our users *will* have to do this. With our without our help. This is the feedback that we got at jBPM community day.
I think that should be definitely feasible with serialization to XML. After the clean shutdown, we should be able to provide a tool that serializes a the complete process instance information to XML and load that XML file in the new DB.
IMO, this is mostly a question of resources.
If this feature is required we need to see this reflected in the test suite. In other words, as long as there are no automated tests that verify that an update of jBPM from version X to version Y for a non trivial set of running processes - this feature is not there.
This will allow processes to terminate, while others cannot start. A user is expected to setup a new instance of jBPM version Y that can receive new process requests.
i don't think this is realistic for the complete process instances. think of the legal case taking 3 years to complete and new legislation requiring updates to the process in the meantime. we need some form of process instance migration for that.
but a clean shutdown could make sure that all asynchronous messages get processed before the shutdown is completed. that only leaves the timers to be taken into consideration.
IFrom that perspective, it is unnecessary and not even desired to provide backwards compatibility for database layout.
i agree. backwards compatibility of DB layout is not feasible and not necessary.
What I would really appreciate is a list (short?) of why jBPM is a better workflow tool than MS WF at this time. TIA.
wrong forum, thread-jacking etc...
but I'd give you a (personal) short list anyway Just do not comment on it here. Start a new topic in the user forum then
- it is open source
- it runs on more platforms (including windows)
- it is completely customizable
but those are probably not the ones you'd like to hear. A comparision with pro's and con's is not one I think JBoss is going to provide. Simply because it can never be complete, there are to many products to compare to, it does not yield significant more commercial support contracts etc... Maybe Gartner or Butller will be bold enough to compare jBPM to other products in their magic quadrants
I have trying to integrate jbpm with different databases ,so i wanted to ask is it something like that ....
means ... Does JBPM require any specific Database ?
How to maintain database in JBPM ?
For Example we need execute delete statement, where do we set it? In JBPM or in Hibernate?