I can completely agree with Ronald and Joram. <br><br>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 <i>least</i> 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.)<br>
<br>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.<br>
<br><div class="gmail_quote">On Thu, Oct 30, 2008 at 3:09 PM, Joram Barrez <span dir="ltr"><<a href="mailto:joram.barrez@gmail.com">joram.barrez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Agreed,<br><br>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. <br>
<br>eg. give me all the tasks involving documents with author X. With jBPM, this is easy *and* accessible for average developers (who know Hibernate).<br><br>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 ...)<br>
<br><br>But now for the compatibility isues, my opinon:<br><br>- 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.<br>
<br>- 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.<br><br>Regards<br><font color="#888888"><br>
Joram</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Thu, Oct 30, 2008 at 10:46 AM, Ronald van Kuijk <span dir="ltr"><<a href="mailto:ronald@jbpm.org" target="_blank">ronald@jbpm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bernd Rücker schreef:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
I don't get this:<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
the underlying DB should IMO be considered an implementation detail of<div><br>
the iBPM engine. If that is not the case in jBPM3 it needs to get fixed<br>
in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say<br>
there is no DB migration needed.<br>
<br>
</div></blockquote>
<br><div>
The whole state of my processes is in the database. Of course no direct<br>
access should be exposed, <br>
</div></blockquote>
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' .<div>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe we can discuss If I need to migrate existing process instances (I<br>
would tend to say yes), <br>
</blockquote></div>
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.<br>
<font color="#888888">
<br>
Ronald</font><div><div></div><div><br>
_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
<br></blockquote></div><br>