[jbpm-dev] jbpm 5 feedback

Andrea Zoppello zoppello at tiscali.it
Thu May 13 03:55:26 EDT 2010


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
>
>    



More information about the jbpm-dev mailing list