3:55 p.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev