I can completely agree with Ronald and Joram. 

My project's initial roll out, taking place next month, has been a year in the making.  I've built a significant amount of functionality around jBPM, and that includes quite a bit of code that, out of necessity, directly uses the Hibernate session--for every one of the reasons mentioned, plus five or six more.  In one way or another, the end user UI is tied to it, our own admin application is tied to it, utility classes, etc.  Sure, most (if not all) useage of the lower level jbpm code/data is well encapsulated in utility classes and such, but there are still at least a few thousand lines of code affected, including a few customizations to jBPM itself.  There are also a few "clever" solutions that were possible based on certain nuances of the jBPM 3 implementation (in 4, the same ideas might not even be present.)

From a business perspective, any solution other than a "weekend migration" of all running processes, database, UI, MDBs, etc., simply would not be an option.  I can't help but think that our usage of jBPM is somewhat typical.

On Thu, Oct 30, 2008 at 3:09 PM, Joram Barrez <joram.barrez@gmail.com> wrote:
Agreed,

It depends on how you look at it. In some use cases, it is conceptually correct to see tasks, processes, etc as being part of the domain model. The main advantage then of having direct access to a Hibernate sessions allows to create queries that take in account own domain models and the bpm model.

eg. give me all the tasks involving documents with author X. With jBPM, this is easy *and* accessible for average developers (who know Hibernate).

IMO, it is impossible to create an API that covers all these kinds of use cases. It will be too complex and still be restrictive for some. In my experience, people tend always tend to need that functionality that is not supported out of the box (and the next customer finds another one ...)


But now for the compatibility isues, my opinon:

- When frameworks change, people understand that some code will need to be rewritten. People understand that there is a price for the newer features. eg. Hibernate code configured with XML -> annotations. I do believe that there should be a  'compatibility mode', which means that jBPM3 process definitions should be able to run on the jBPM4 engine. If this is feasible, I think it will solve most of the people's problem with upgrading.

- DB conversions is, I think, more needed: some of the people I have worked with have processes that an run up to 5 years. So for me conversion of DB state is the most important.

Regards

Joram


On Thu, Oct 30, 2008 at 10:46 AM, Ronald van Kuijk <ronald@jbpm.org> wrote:
Bernd Rücker schreef:
I don't get this:

 
the underlying DB should IMO be considered an implementation detail of

the iBPM engine. If that is not the case in jBPM3 it needs to get fixed
in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say
there is no DB migration needed.
   

The whole state of my processes is in the database. Of course no direct
access should be exposed,
What we should *not forget* is that there are users out there that use hql (or even sql) via the hibernate session which can be retrieved from a jBPM session. They do this since the api does not support everything but a kitchensink. e.g. retrieval of taskinstances or processintstances based on values of variables is not possible in jBPM. Implementing this and keeping it performant requires many indexes. The jBPM database is in fact (as the docs say) not optimized (index wise) for all kinds of usecases, so a dba should tune this. Besides that, jBPM supports injecting a hibernate session to be used for the tables, so direct access is always 'exposed' .


Maybe we can discuss If I need to migrate existing process instances (I
would tend to say yes),
If we don't, but allow just convert processdefinitions, run old instances in jBPM 3 and new instances in jBPM 4, all kinds of BAM/BI implementation by customers will break (they have to adapt for querying 2 databases) Retrieving tasklists will be more difficult, signalling instances etc.... So I tend to say yes as well.

Ronald

_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev


_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev