Re: [jbpm-dev] jbpm 5 feedback
Hi All,
First off all thank you comments here some further clarifications /
response:
1) OSGi... i think that this is a prirority... there's a lot of interest
around it and a lot
of companies are moving towards OSGi powered applications. BTW with
regards to jbpm it could be not only a JBPM problems but also on it's
dependencies..
2) About the persistence layer i perfectly agree tha JPA is the right
choice but what
i really would like to see is the layer implementing the engine core to
be separated from
the persistence one.
3) Regard NoSQL i think that in some situations it could fit very well
( for example
grid system as salaboy suggested ). I'm not suggesting to drop the
realtional persistence layer
but to support also other based on NoSQL.
Andrea
Il 12/05/2010 18:01, Sebastian Schneider ha scritto:
Hello Andrea!
Am 12.05.2010 10:00, schrieb Andrea Zoppello:
> Hi all,
>
> I'm a jpm 3.X version and i want ( if possible ) give my two cents
> about what i would like to expect from JBPM Release 5.
>
jBPM 3.x itself speaking? I feel honored. ;)
Sorry for the typo :-)
> 1) Ability to use JPM within an OSGi container, so i would like to have
> bundles for engine and to have jbpm services exposed as OSGi services.
>
This is something Tom has been aiming for with jBPM 4.x as well. I think
it's a good thing but it does not have that much priority in my eyes but
maybe it's good to keep this in mind to ease a later implementation.
> 2) A better separation between the engine and the persistence layer. In
> my opinion the> jbpm3.X code is too much coupled with hibernate, i'd really
like to have
> a separation to be able for example to use JPA or ( for example a NoSQL database )
for persistence.
>
I partly agree. In the future jBPM should be more independent of the
underlying database layer and I think JPA is the way to go. But IMHO
extending this to document-oriented databases is not possible and does
not make any sense. Document-oriented databases serve a speecial
purpose: serving documents which are schema-free and being able to
retrieve them very quickly. When it comes to jBPM or a process engine in
general you don't work schema-free but you have a big amount of
homogeneous data to deal with: process instances, task lists etc.
Regards
Sebastian