I'd suggest the requirement of having pluggable persistence engine will detract from what your setting out to achieve i.e a BPM engine, so steer clear of it! The ORM debate tends to do this from what I can see.
That said have you thought about implementing the Active Record pattern. There are a couple of Java implementations that have taken the Ruby implementation as a basis.
http://www.javalobby.org/articles/activeobjects/
http://arjava.sourceforge.net/
We (like many organisations) have/ are having this debate and it always appears that JPA is to complex, Ibatis is great but doesn't reduce code and that all we really need is a simple Active Record type mechanism.
Good Luck
That said have you thought about implementing the Active Record pattern. There are a couple of Java implementations that have taken the Ruby implementation as a basis.
http://www.javalobby.org/articles/activeobjects/
http://arjava.sourceforge.net/
We (like many organisations) have/ are having this debate and it always appears that JPA is to complex, Ibatis is great but doesn't reduce code and that all we really need is a simple Active Record type mechanism.
Good Luck
I just found this discussion. After browsing through the source code to see what the guys were using in their persistance layer, I was (at first) very surprised to have found iBatis. This led to the discussion started in Tom's blog posted by Bernd here.
But after giving it a second thought, I think what Activiti is using internally is not a big deal. In your spring configuration you can define 1 DataSource which will be used by your JPA configuration in the EntityManagerFactory bean and by Activiti/iBatis. If the project is configured like that using JTA, there shouldn't be a problem.
For me another strong argument to support JPA was the possibility to plug in my JPA domain model, specifically in case I want to reference/update my Business Domain Objects as process variables. In jBPM we have options like having to use Hibernate directly, no JPA (not nice if your own project uses JPA…), save objects like BLOBs (that's ugly too), or just use references of primitive types like String or Long being normally ID's of your BO's and load your BO's in the Java code. Instead if I could reference a JPA entity directly, it would be really nice.
Of course you may argue, why use JPA entities directly, one should better call services instead which encapsulate those objects. Well the use case I think about is when I use the process to manage the state of my business process in a "process-driven" service. Example: a service called CreateInsuranceClaim starts internally a workflow which in turn may orchestrate several other services but also have its own domain objects. For the clients using that service all those details would still remain hidden.
For what I understood, Tom was going to provide variable JPA persistence independantly from how their internal persistance is managed. If that's the case, I don't see a problem with iBatis. But if in the meantime they have decided to support JPA for their own persistence too, even better for me.
But after giving it a second thought, I think what Activiti is using internally is not a big deal. In your spring configuration you can define 1 DataSource which will be used by your JPA configuration in the EntityManagerFactory bean and by Activiti/iBatis. If the project is configured like that using JTA, there shouldn't be a problem.
For me another strong argument to support JPA was the possibility to plug in my JPA domain model, specifically in case I want to reference/update my Business Domain Objects as process variables. In jBPM we have options like having to use Hibernate directly, no JPA (not nice if your own project uses JPA…), save objects like BLOBs (that's ugly too), or just use references of primitive types like String or Long being normally ID's of your BO's and load your BO's in the Java code. Instead if I could reference a JPA entity directly, it would be really nice.
Of course you may argue, why use JPA entities directly, one should better call services instead which encapsulate those objects. Well the use case I think about is when I use the process to manage the state of my business process in a "process-driven" service. Example: a service called CreateInsuranceClaim starts internally a workflow which in turn may orchestrate several other services but also have its own domain objects. For the clients using that service all those details would still remain hidden.
For what I understood, Tom was going to provide variable JPA persistence independantly from how their internal persistance is managed. If that's the case, I don't see a problem with iBatis. But if in the meantime they have decided to support JPA for their own persistence too, even better for me.
