Hani is now taking pot shots at the OFBiz Entity Engine. Actually, he could of saved a lot of time if he bothered to read my blog 8 months ago.  That's when I wrote this "OFBiz Turning OO on its Head or Programming in the Large?".  Hani, finally goes out on a limb by making this remark:

In my opinion, persistence these days has become so orthogonal to business functionality and concerns that it should be as decoupled as possible. One should be able to merrily switch functionality without much knowledge of the persistence mechanism, and vice versa.

However, I think that's just plain sheer ignorance on his part. A persistent API like EJB, Hibernate, Toplink or OFBiz EE essentially allows you to replace the underlying relational database with another implementation, matter of fact you can to an extent refactor the database, and if you got put the right views still have everything work without code changes.  That's what these persistence API affords you, and yes it to some extent makes business logic orthogonal to the persistence mechanism.

However, Hani is seems to be wishing for functionality that doesn't exist in any of the known persistence APIs.  I seriously doubt you can move from EJB to Hibernate to TopLink with a flip of the switch.  In all cases you are already tightly coupled to the object model and transaction model that these API's provide.  I know, I did a port from ODMG to TopLink to OJB and it wasn't a pretty sight.  Products that provide a universal abstract model on top of persistence layers as far as I know don't exist, however one promising solution may be the XQuery apis.

Finally with regards to OFBiz Entity Engine, I explored it 8 months ago, times have indeed change since then with Hibernate becoming the dominant open source persistence API.  However,  as much as I'm impressed with Hibernate, I wouldn't be so quick to abandon the approach taken by OFBiz. 

Based on what I do know about the different implementations,   I would choose Hibernate if I had a complex object model with complex interactions.  On the otherhand, I would choose OFBiz for the usual form based business applications, which incidentally covers 90% of most applications.  In fact, if one of my top priorities were data migration between different version, I would choose OFBiz.  I've used JIRA and I've seen this in action, migrating data to a new version was completely painless.  Hani who is so enamored by Entity Beans, I also wouldn't touch it with a ten foot pole.

What boggles my mind though, is how does a company like Formicary (I guess Hani works there), a company that specializes in Enterprise Portal Integration (EIP), a technology that requires integration with a multitude of data sources, do it with such a cumbersome API like Entity Beans?  I would expect some other kind of universal abstraction layer, but it appears he's unaware of it.   I guess one day Hani can explain that to all of us.