Why iBatis?

[akakunin]

Hi friends!
really great to see new project and hope it expected great future.

I'm looking into activity, because I did not like in jBPM close relation to hibernate for persistence.
Really, in these days I was sure new projects use JPA by default for ORM (since JPA is standard) - and expected to see it in Activiti. For me it was one of the advantage comparing to jBPM, since allow closer integration into environment I'm going to use bpm engine.

But - I found Activiti used ibatis. are any big reason for it? Do you think it is hard to implement JPA persistence layer for Activiti (as part of contribution into project) or any other Persistence layer? As far as I understand - Activiti also supports (planned to support) nosql, so, looks like persistence layer are pluggable.

===
Alexey Kakunin
EmForge: Liferay Based project hosting services

[bernd_ruecker]

I think it is not an aspect of being "cooler". Setting up a clustered environment with JTA, XA-Transactional JMS, Hibernate, maybe caching, etc. in a broader scale is not an easy task. Hence bringing a new component into this battle (ibatis) is real effort. So it is understandable, that this is not taken lightly. That's said from the user perspective.

On the other hand I agree: Providing multiple persistence implementations is a lot of work without new functionality (I wouldn't say without value ;-)). And I agree it should not be first priority. That's said from the team perspective.

A pitty that Hibernate is not Apache licensed…

[akakunin]

Hi!
Just one comment about iBatis and JDBC. Now all the system has SQL and JDBC - simple example is Google App Engine. It has (even limited) JPA or JDO - but not JDBC as persistence layer. If somebody will want to try Activiti to be deployed into GAE - with iBatis - no chance. With JPA - probably  (since JPA is really limited in GAE) it will be possible. With fully plugable persistance layer - it will be defenetly will be possible.

Also - I thing one of the major advantage of jBPM was embedding. It was really very easy embed jBPM into project, close integrate it with your project infrastructure (Spring Context, Hibernate Session Factory, Transaction Managment) and use it like one of the component in your system.
Storng relation to Hibernate (not JPA) sometimes produced problems - for example in project used Glassfish as deployment platform and EclipseLink as JPA provider we had to switch whole project from EclipseLink to Hibernate to use jBPM (since jBPM was one of the core and most important service in the app).

I think supporting JPA in Activiti will be really big advantage in terms of embedding - people will able to use same JPA provider and JPA setting as they use for whole app, and configure things like caching and support for clustering for whole app (own code and embeded activiti).
Fully pluggable persistence will be extremely great - since may enable using of Activiti in some specific encironment (GAE for example)

[tombaeyens]

I think it is not an aspect of being "cooler". Setting up a clustered environment with JTA, XA-Transactional JMS, Hibernate, maybe caching, etc. in a broader scale is not an easy task. Hence bringing a new component into this battle (ibatis) is real effort. So it is understandable, that this is not taken lightly. That's said from the user perspective.

On the other hand I agree: Providing multiple persistence implementations is a lot of work without new functionality (I wouldn't say without value ;-)). And I agree it should not be first priority. That's said from the team perspective.

A pitty that Hibernate is not Apache licensed…

You make it sound like Activiti should just do the basic non clustered version.  Then users should take it and try to make it work for clustered solutions.  When we want to allow clustering or cloud, it has an impact on more then just the persistence framework.  So we should offer that kind of capability inside the project.  Either we support it, in which case users should just turn on the feature in the configuration (or out of the box).  Or we don't support it, in which case users should not even try going there.

[tombaeyens]

Hi!
Just one comment about iBatis and JDBC. Now all the system has SQL and JDBC - simple example is Google App Engine. It has (even limited) JPA or JDO - but not JDBC as persistence layer. If somebody will want to try Activiti to be deployed into GAE - with iBatis - no chance. With JPA - probably  (since JPA is really limited in GAE) it will be possible. With fully plugable persistance layer - it will be defenetly will be possible.

We have a pluggable PersistenceSession in our architecture.  We could and will target other persistence stores.  NoSQL DB's being high on our target list.  For those completely different environments, which give a totally different feature perspective to the whole engine, I think it is worth building another persistence implementation.  But I don't want to do that kind of work to switch from one DB impl to another DB impl.

Also - I thing one of the major advantage of jBPM was embedding. It was really very easy embed jBPM into project, close integrate it with your project infrastructure (Spring Context, Hibernate Session Factory, Transaction Managment) and use it like one of the component in your system.
Storng relation to Hibernate (not JPA) sometimes produced problems - for example in project used Glassfish as deployment platform and EclipseLink as JPA provider we had to switch whole project from EclipseLink to Hibernate to use jBPM (since jBPM was one of the core and most important service in the app).

Activiti will be more embeddable then jBPM. 

Seems strange that you couldn't integrate transactions of an eclipse link persisted domain model with hibernate persisted jbpm model.  On JDBC level that should be doable in multiple ways: having them use the same JDBC connection or in appserver like glassfish, JTA should also be an option.

I think supporting JPA in Activiti will be really big advantage in terms of embedding - people will able to use same JPA provider and JPA setting as they use for whole app, and configure things like caching and support for clustering for whole app (own code and embeded activiti).
Fully pluggable persistence will be extremely great - since may enable using of Activiti in some specific encironment (GAE for example)

There is an API, but think only in very rarely situations, users will actually be able to provide their own implementation of that.  And it will be much less QA-ed then what we're able to do on persistence implementations that we support.

What I learned already from this thread is that we actually should try to set up example projects that show how Activiti JDBC persistence should be combined with hibernate, openJPA, eclipse link and potentially others.

[akakunin]

Thank you Tom for clarification. Having pluggable persistance layer is enough for me - I will try to see how to implement totally different (no JDBC, no NoSQL) persistence layer to achieve my targets

[soaexpert]

My suggestion for this problem is to create a persistance layer like Akka Framework from Jonas Boner - http://github.com/jboner/akka/tree/master/akka-persistence that keep complice with different solutions of noSQL.

Im studing the framework and ideas relationship with noSLQ approach. If you want a little help, i can spend time with this :-).

[sebastian_s]

There was a discussion on NoSQL related to the jBPM5 roadmap on the jBPM developers' mailing list a few days or weeks ago. There were also voices asking to support non-relational databases. I don't see the point in using a document-oriented database to store process states.

[tombaeyens]

in our SVN, we can set up a branch as kind of a laboratory for such experiments.

[bernd_ruecker]

I don't see the point in using a document-oriented database to store process states.

Sebastian, deploying everything in the cloud, e.g. EC2 or the like, is the reason for this requirement.

[soaexpert]

There was a discussion on NoSQL related to the jBPM5 roadmap on the jBPM developers' mailing list a few days or weeks ago. There were also voices asking to support non-relational databases. I don't see the point in using a document-oriented database to store process states.

Hi Sebastian, so noSQL isn´t only document based. You can have another approach like key-value ( Redis is my choice) or MongoDB ( was developed by DoubleClick team) that use both concepts.