nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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

Find more posts tagged with

Comments

jeff1

I wonder why ibatis, too

sebastian_s

It's just a guess but I think iBatis was chosen due to it being just a database abstraction layer but not a object-relational mapper as Hibernate is one for example. By using iBatis they achieve their goal keeping the engine sourcecode more independent of the underlying database abstracton layer implementation as well as having more control over the persistence functionality.

haison

From the ibatis page(http://ibatis.apache.org), we find that it has moved to google code serveral days before,just ike tom left jboss.So the same experience of their leader let the product together.

jeff1

wow MyBATIS. I'm wondering what is going on behind this.
BTW, why iBATIS? maybe tom or joram could say something on this topic 🙂

tombaeyens

first we tried open jpa. but the development cycle was pretty hard with the compile time weaving and stuff like that.

switching to ibatis gave us ease development. but we also found that we had more control. the downside is that you have to code a lot more then when you use hibernate or jpa. we're still in evaluation mode, but so far so good.

akakunin

Tom, thank you for clarification.
Do you think it is possible (with reasonable effort) to write another, custom persistance layer for Activiti? How deep Activiti depends from ibatis?

jeff1

allow me to throw out my point first
maybe it's unnecessary to write a persistence layer for activiti, it's just OK if activiti can integrate with the mainstream persistence solution(jdbc/hibernate/jpa/xbatis/…) with the current mechanism, keep it simple.
for example, the host program and activiti can have consistent transaction whichever persistence way the host program is approached

bernd_ruecker

I discussed that issue with Tom via email already as well. So I will provide the stuff from there here as well:

– BERND
Hi Tom.

You wrote in your blog:

But I would be really interested to find out why you want to plug your own persistence provider. If it is for another storage then JDBC, then I can understand. But if we work with your JDBC connection and your persistence framework also translates to JDBC, does it matter what persistence framework we use internally?

Let me give a quick answer from my side, I see three reasons for JPA against iBatis:

1.) As we promote tu use standards (BPMN) it would be cool to do that where possible
2.) I saw a lot of companies / projects having clear rules which persistence frameworks are allowed. Not sure if that was only a problem with Hibernate, but with jBPM Hibernate was a showstopper for some projects
3.) And this is the most important: If you build big applications you have to know the nuts and bolts of the persistence framework, e.g. for caching, clustering, and so on. This is normally true for Hibernate, but I don’t know many projects or companies using iBatis. But for Hibernate I know excellent experts (and you need them sometimes ;-)).

On the pro side for sure the license is an argument. And it is already too late to change it I guess, so anyway. But just to have said I am not that happy with it as well…
– Tom's answer:
we first tried open jpa but it was too clumsy in development. hibernate is good to work with but its LGPL so no go

switching to ibatis put a bit more burden on us, but it also has a benefit of more control. hibernate is most of the times really good, but still it has these magical flushes. fixing problems related to flushes can be very challenging with hibernate. with ibatis you know what happens, when and how and you're in full control.

but is's not religious for us. but we have to have good arguments. currently i'm quite happy with ibatis.

> 1.) As we promote tu use standards (BPMN) it would be cool to do that where possible

(i agree with some of your argumentation, but it's just quicker if i play devil's advocate here)

JDBC is standard too. using as much standards as possible in your persistence layering shouldn't be a goal 😉

> 2.) I saw a lot of companies / projects having clear rules which persistence frameworks are allowed. Not sure if that was only a problem with Hibernate, but with jBPM Hibernate was a showstopper for some projects

i don't see ibatis being a problem. it's only JDBC that comes out.

> 3.) And this is the most important: If you build big applications you have to know the nuts and bolts of the persistence framework, e.g. for caching, clustering, and so on. This is normally true for Hibernate, but I don’t know many projects or companies using iBatis. But for Hibernate I know excellent experts (and you need them sometimes ;-)).

with ibatis you don't need those experts. it's us in full control and the code is readable and predictable.

– BERND
Another argument, especially for an open source project: A lot of people are not familiar with ibatis.

– BERND
Today I had a discussion with an architect at a big company. He told me that currently no other persistence mechanism as Hibernate is deployed on the machines here, since they invested a lot of money to get that running correctly in a clustered environment, together with JMS, JTA etc…

Normally people ask for JPA, here Hibernate is fixed. So this could be a show stopper to run Activiti 😕
I will have a look into the code base to see how the persistence is pluggable (which I am sure it has to be for being Cloud deployable). It would be really good to have JPA ready in my opinion. Nobody really knows ibatis 😕

– TOM
i think we have to protect those type of architects against themselves 😉

in my jbpm 1 days, i'ld say of course it's pluggable already with the persistence session.

but the argument of their expertise in hibernate does not hold. i can guarantee that they will be working with a debugger and asking for our help which we can't give them. if they follow whatever persistence framework that we use, we will have done our clustering QA and they should not have to use a debugger.

why do they want to organize their architecture on the persistence framework, rather then JDBC. that looks like a broken strategy to me.

when we switched from hibernate over OpenJPA to EclipseLink we had very different errors. and that is switching between *JPA* providers. i don't see the point in spending our time on that. and I think most people will underestimate the work.

although i'm very convinced that there is no valid argumentation for us to support multiple persistence providers, i think might still can consider it because embeddablility is in our core values. and if 80% of developers consider persistence framework as part of the app environment that we have to embed into, then at least we should consider it.

but my current belief is that supporting multiple persistence implementations is 1) it's a waste of our time and 2) not feasible with the resources we have.

tombaeyens

Here's the summary of how I see the tradeoff:

on the one hand: "although i'm very convinced that there is no valid argumentation for us to support multiple persistence providers, i think might still can consider it because embeddablility is in our core values. and if 80% of developers consider persistence framework as part of the app environment that we have to embed into, then at least we should consider it."

on the other hand, supporting multiple persistence frameworks will be a very big challenge to get the QA set up. it's not only just providing an implementation of the persistence session interface. it's also figuring out how to deal with the differences between persistence providers without breaking the other providers. and imagine the build scripts for continuous integration when we want to test the matrix of {servers like tomcat versions, jboss, genronimo} x {transaction demarcation technologies like Spring, JDBC, JTA} x {persistence providers} x {databases like oracle, mysql, postgresql,…}

i think the work involved to support different persistence providers is underestimated big time. and it's not adding any functional features.

probably the point why i currently tip over to not supporting multiple DB persistence providers: i don't see the value. i can see that an architect thinks it's cooler that all of his application is build on the same persistence provider. but i think that is only a small aspect compared to the bigger issue of QA and the immense amount of work that will go into it. that extra effort of building the pluggability and the QA effort will come at the expense of more interesting features that we could build.

thoughts?

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.

soaexpert

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.

And to keep the state of process, don´t we need of a hard relation base. If we work with models (OOP), they can be stored by a key-value system.

More distribute computation, more SOA architecture, because normally the bases noSQL have rest interface 🙂

activiti-admin

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

sebastian_s

Hello Bernd, hello Felipe,

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.

thanks for clarifyfing on this. For everyone capable of the German language there is an article on heise.de which gives a good overview about the different types of noSQL-databases:

http://www.heise.de/open/artikel/NoSQL-im-Ueberblick-1012483.html

Regards
Sebastian

sebastian_s

Here's the summary of how I see the tradeoff:

on the one hand: "although i'm very convinced that there is no valid argumentation for us to support multiple persistence providers, i think might still can consider it because embeddablility is in our core values. and if 80% of developers consider persistence framework as part of the app environment that we have to embed into, then at least we should consider it."

on the other hand, supporting multiple persistence frameworks will be a very big challenge to get the QA set up. it's not only just providing an implementation of the persistence session interface. it's also figuring out how to deal with the differences between persistence providers without breaking the other providers. and imagine the build scripts for continuous integration when we want to test the matrix of {servers like tomcat versions, jboss, genronimo} x {transaction demarcation technologies like Spring, JDBC, JTA} x {persistence providers} x {databases like oracle, mysql, postgresql,…}

i think the work involved to support different persistence providers is underestimated big time. and it's not adding any functional features.

probably the point why i currently tip over to not supporting multiple DB persistence providers: i don't see the value. i can see that an architect thinks it's cooler that all of his application is build on the same persistence provider. but i think that is only a small aspect compared to the bigger issue of QA and the immense amount of work that will go into it. that extra effort of building the pluggability and the QA effort will come at the expense of more interesting features that we could build.

thoughts?

What about providing the possibility to switch the persistence provider while limiting the coverage through the QA-matrix? Or we could commit on providing a persistence layer allowing the use of 2 different persistent providers. If I understood you right there will be a kind of persistence layer anyway to make it possible to use noSQL-databases, right?

I would have excpected the project to go the JPA-way but it seems there are quite some obstacles. I am not sure what to think about iBatis/MyBatis since I have not known the project before it was mentioned in relation to Activiti.

just my 2 cents

Sebastian

yury_h

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.

tombaeyens

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.

exactly. same for a number of other entities that might be referenced. like e.g. non-jpa-hibernate entities, JCR nodes, records in a table,…

chrisc

on the other hand, supporting multiple persistence frameworks will be a very big challenge to get the QA set up. it's not only just providing an implementation of the persistence session interface. it's also figuring out how to deal with the differences between persistence providers without breaking the other providers

We created a lightweight, high performance 'wrapper' for persistence frameworks, exPOJO to achieve the very goals you mention above. It allows developers of libraries/frameworks that require persistence to write their code to a persistence framework agnostic API which is a very thin wrapper over other APIs like JDO, JPA or direct Hibernate.

This allows users of frameworks written with exPOJO to plug in their favourite (or company mandated) persistence implementation. It also allows code to be easily ported from one persistence framework to another with very little code changes.

It's all made possible by building upon the Exposed Domain Model Pattern detailed in Chris Marshall's book 'POJOs in Action'.

exPOJO comes with a very lightweight servlet filter than 'can', if required, help out with exPOJO's dependency injection which requires no annotations but that's not mandatory as you could just as easily use it with Spring.

ronald_van_kuij

Sorry, but I honestly hate wrappers of tese kinds. They almost always limit you in what you can do, are not a (defacto) standard, often not maintained for a long time etc…