topic Re: Why iBatis? in Alfresco Archive

Why iBatis?

akakunin — Fri, 21 May 2010 22:04:18 GMT

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

Re: Why iBatis?

jeff1 — Sat, 22 May 2010 11:42:41 GMT

I wonder why ibatis, too

Re: Why iBatis?

sebastian_s — Mon, 24 May 2010 11:55:56 GMT

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.

Re: Why iBatis?

haison — Mon, 24 May 2010 13:32:18 GMT

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.

Re: Why iBatis?

jeff1 — Tue, 25 May 2010 00:34:31 GMT

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

Re: Why iBatis?

tombaeyens — Tue, 25 May 2010 14:18:21 GMT

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.

Re: Why iBatis?

akakunin — Tue, 25 May 2010 22:59:04 GMT

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?

Re: Why iBatis?

jeff1 — Wed, 26 May 2010 00:52:04 GMT

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

Re: Why iBatis?

bernd_ruecker — Wed, 26 May 2010 07:19:26 GMT

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.

Re: Why iBatis?

tombaeyens — Wed, 26 May 2010 07:39:41 GMT

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?

Re: Why iBatis?

bernd_ruecker — Wed, 26 May 2010 07:49:20 GMT

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…

Re: Why iBatis?

akakunin — Wed, 26 May 2010 11:32:26 GMT

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)

Re: Why iBatis?

tombaeyens — Wed, 26 May 2010 15:32:38 GMT

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.

Re: Why iBatis?

tombaeyens — Wed, 26 May 2010 15:45:27 GMT

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.

Re: Why iBatis?

akakunin — Wed, 26 May 2010 16:38:43 GMT

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

Re: Why iBatis?

soaexpert — Wed, 26 May 2010 18:38:04 GMT

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 :-).

Re: Why iBatis?

sebastian_s — Thu, 27 May 2010 06:03:21 GMT

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.

Re: Why iBatis?

tombaeyens — Thu, 27 May 2010 14:02:03 GMT

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

Re: Why iBatis?

bernd_ruecker — Thu, 27 May 2010 14:41:54 GMT

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.

Re: Why iBatis?

soaexpert — Thu, 27 May 2010 15:32:22 GMT

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.