Ofbiz EE: Forgotten but not forgiven
Ahh, I remember it well, that heady spring of 2002. Winter was being chased away by a determined April, intent on reminding us all that life isn’t so bad after all. America still had some some of the world’s sympathy, the mean old Afghans were a thing of the past, and Homeland Security was but a twinkle in Tom Ridge’s eye.
Meanwhile in the Java world, a punk still in school by the name of Patrick Lightbody was merrily stomping all over OpenSymphony projects; Adding his own personal wishlist and useless features all over the place. Getting away with it too, sadly, due to the dubious excuse of being the only one willing to do anything, good or bad. Another committer, Matthias, was busy upsetting the old guard by reformatting their code and checking it in. It was fun and games all round, life was exciting, love and hate both competed for our top emotion of the day.
It was in this crazy spring that the Ofbiz entity engine made a name for itself. Scorched by the false prophet of entity beans, fashion victims everywhere needed a new leader. One that would remove type safety, one that would make them forget anything to do with EJBs; a leader that was simple, yet alluring and sexy; it had to be changing daily, and require cvs versions to be of any use. Stable builds implied stagnation, and lacked that essential danger element.
It was at this time that Ofbiz mania took hold of those ‘in the know’. Support for Ofbiz persistence was popping up everywhere. Time honoured traditions of encapsulation, strong type safety, and abstraction were cruelly cast aside by the rebellious young hotheads.
That is not to say that everyone rushed lemminglike into this uncharted promised land. There was some that dared express some hesitation, and with small fearful voices voiced bafflement at the stripping away of all things OO. Needless to say, they were ruthlessly ignored. After all, the proof is in the pudding, and JIRA quickly became the poster child for the Ofbiz EE, compelling evidence that it is a wonderful and magnificent thing, OO be damned!
Before I lay into poor JIRA, I’d like to point out that Mike is a fabulous guy (hell, I’m having sushi with him next week where we’ll giggle about this). I also bought the first 5 JIRA licenses ever I think, to support this wonderful new app.
All is not well though! JIRA unfortunately fell for the ease and prevalence of Ofbiz’s GenericValue. It is difficult to find an action class or page which somehow does not directly talk to GenericValue. Abstraction has long since been cast aside for convenience. This is all good and well, since it makes life easier for developers, and new features and so on become very easy to add. Sadly, this does come at a cost. The cost is being locked in a death embrace with ofbiz. It is absolutely impossible (well, not impossible, just rather tedious, boring, and difficult) to decouple JIRA from Ofbiz and plug in another entity engine. Why would one want to do that? Well, why not? We integrate JIRA into our big fat portal app (EJB based), and having two orthogonal entity engines seems quite irritating.
Now, I’m not saying JIRA should automatically support EJB’s out of the box. However, I rather like the idea of just allowing for that possibility. 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. Cuss EJB’s all you want, but the session facade pattern works wonders here. Sick of entities? No problem, you can just use the same entity interfaces, and have your session beans use hibernate to persist them. Your business logic won’t have a clue what just happened.
I just feel bad for all those people who committed to Ofbiz, and now don’t get to play with the latest and greatest persistence engine (which changes every few months, mind you). Oh the perils of having a real product to maintain, and being answerable to real customers!
June 26th, 2003 at 1:53 am
Fate,
This is golden. Absolutely golden. You stayed focused and you showed no mercy. You make me so proud.
June 26th, 2003 at 4:41 am
The question is if OFBiz is meant / used as a replacemant for EJBs. OFBiz is IMO the right tool for some special usecases, only some points here:
1. Every technology adding flexibility and decreasing strictness is a candidate for introducing bad architectures - not because you _must_ do a bad design, but because you _can_… Even OFBiz EE gives you to possibility to separate business logic and persistence, but it makes it so very easy to do not.
2. The only stuctures _our_ OFBiz based applications are tied to are List and Map - GenericValue implements Map, and is arranged in Lists when coming along in a pack. We do not use any of the persistence features of the GenericValue in BL, but have a persitence manager architecture takes care of out Maps and what to do with them. I call List and Map extremly generic, do you agree?
3. OFBiz EE does support relational mapping for aggregation / OR without need to know anything about how it ist realized. I define a OFBiz view for the aggregation - eg. User is a Person is a Party, Organization is a Party - and then do inserts, updates and deletes, as if it is a real entity - for any underlying database management system, you are not tied to special features needed.
4. Customization can be done very easy with this architecture, even for a client: Let’s say you want a new field for your company records, eg IANA-registered private enterprise number. You will have to edit two files - the entitymodel.xml to add the ianaId field definition, and the fronstside jsp: (Webwork2 style). That’s it - nothing more needed.
What I want to say is: OFBiz EE is not better or worse than xyz, just another approach…
Regards
June 26th, 2003 at 6:07 am
You know you’ve made it big when you get attacked in the BileBlog. It’s like a socialite making the back pages of People magazine - it almost doesn’t matter if you’re in the ‘badly dressed’ section because it’s good for your PR either way.
A solid response is of course the best rebuttal:
http://blogs.atlassian.com/rebelutionary/archives/000185.html
:)
Mike
June 26th, 2003 at 6:09 am
PS I loved the comments about Pat and Mathias - I’m sure they did too :)
June 26th, 2003 at 8:36 am
“OFBiz Persistence Revisited” http://www.freeroller.net/page/ceperez/20030626#ofbiz_persistence_revisited
June 26th, 2003 at 7:00 pm
Being the author of the Entity Engine I guess I should say _something_ here, even if it does turn out to be inane and useless to everyone reading. But hey, like my good friend who I’ve never met Mr. Cannon-Brookes has said “it’s good for your PR either way.”
Hani, you might be entertained to find out that one of the original design goals of the Entity Engine was to provide a simple persistence interface using multiple back-end techniques. However, after writing a proof-of-concept Entity Bean based implementation of our “GenericHelper” interface, I tossed it because it performed SO poorly and didn’t add anything to the usefulness of the Entity Engine.
So, essentially what I found out through that experience is exactly what Carlos Perez expressed in his recent OFBiz Persistence Revisited blog entry (see link in Carlos’ response to the Hani’s blog entry): a generic persistence layer, without a TON of redundant code, is quite difficult.
I think the closest you could come is to use a code generator or a dynamic proxy to create outer layer classes or implement outer layer interfaces. Hani is correct that this can be done with EJBs, but I DON’T WANT over 500 extra classes with a bunch of otherwise useless code sitting in the OFBiz enterprise applications waiting for someone to unwittingly stick some business logic into it instead of into services where we really want it to go…
Which brings me to my next point: the business logic. No matter what you use for persistence your business logic will have limited portability if it is written in Java, especially if it relies on bulky and/or expensive toolsets. Might be okay for an home grown app, but it’s not good for a commercial enterprise product, and it’s even worse for an open source enterprise product.
This is where I’m sure I would REALLY get flamed if the Service Engine and simple-method (in MiniLang) components of OFBiz were used more. And yet, these components give us SO much flexibility and ease of maintenance in our applications that I would never give them up. Even if we tossed the Entity Engine it wouldn’t matter with the logic written in simple-methods because another persistence engine COULD be plugged in there. However, our code takes advantage of the dynamic nature of the Entity Engine in SO many ways that anything that varied too much from the concept wouldn’t apply very well.
And it gets worse… We now have a “Form Widget” which renders forms described in XML files. The fields for these forms don’t have to be manually defined, although they can be. In most cases it is easier to say “create all fields needed to call this service”, or “create all fields needed to edit this entity”, and that is just what it offers. So, the form the user acutally sees can be an HTML form, an XFORM form, and custom AWT/Swing/SWT/WhateverComesTomorrow form, or whatever. And the best part is, you add a field to your data model and it can show up there with no more effort, or not show up there with a simple XML element in the form def.
So, while our heady Spring (actually mostly Fall 2001 for the Entity Engine) days resulted in some pretty crazy and dynamic ideas, we certainly didn’t stop there, and we WON’T STOP until we have an SAP class (or at least a PeopleSoft/OracleFinancials class…) system built by a few of guys working from home and a network of consulting groups doing commercial implementations of the software. And when I say SAP/PeopleSoft/OracleFinancials class product, I don’t mean one that costs $10-100M to implement, I mean one that offers the same functionality.
Admittedly we may fall flat on our faces and end up collecting garbage (or even worse, helping SCO find more people to litigate against because no one else will work there…) by the time this is over, but the only way to really improve on existing technology is to re-think some of the foundational concepts and practices, so this is where we are going…
Now if THAT isn’t heady flame bait, I’m sure there is more that could be dug up about OFBiz and/or its creators. For instance, as some of you may have already guessed, I am a young upstart who graduated from college as a teenager (okay, maybe just barely, ie with only a year left of that most rightly exalted social status), and no, I never did finish high school.
Of course, that was a few years ago, I’m much more conservative now. Heck, I’ve spent the last couple of days working with Andy on making sure our backorder notifications (and other related inventory issues) are compliant with the FTC requirements and the needs of various current and hopefully future clients.
I guess you have to draw the line somewhere, for me it’s on the business level. Legacy things count for a lot there, but not on the technology level, that changes every day in many good ways.
Later,
-David Jones
June 28th, 2003 at 12:15 am
I have really enjoyed working with ofbiz over the past year. Its refreshing to find a well designed robust and practical frame work. Not to mention very felxible.
I think that there are two problems with ofbiz.
1. Too many organizations followed the false prohpet of EJBs and think that there is some sort of value in supporting and maintaining them. Naturally if they try to take a good little app like JIRA and throw it in with the rest of their stuff they will encounter problems.
2. There is a learning curve to OFBIZ and I hear the same arguments again and again until they actually take the time to use OFBIZ. Then they understand the benifits to the architecture. Its a great frame work and I bet it will be around for quite some time.
OFBIZ is really great and it was written by two really smart practical guys in a garage. EJBs sound good on the surface, but much like Netscape 6 all the great standards don’t seem to apply that well in the real world. In my opinion EJB’s are not good for performance or maintenance and not very practical either. As far as OO goes its not tossed aside it is used where it makes sense.
June 29th, 2003 at 6:20 am
What about TrackStudio (http://www.trackstudio.com) - Hibernate-based issue tracking app. We change or persistence engine form EJB to Hibernate in a month.
July 1st, 2003 at 11:50 pm
Just thought I’d share my less that optimal experience with OFBIZ…
March 23rd, 2004 at 2:02 am
After coming off a run of seven deployed web sites built on OFBiz I’m going to say the approach works. We did our stint with EJBs and the overhead of writing home, interface and bean implementations in addition to declaring persistance policies and other hoo-ha only to find yourself smack dab in the middle of crappy performance is fine grade bullshitey.
I’ll agree that dropping most of the OO features of Java is vexing. It still gives me the willies. But damnit man, we’re getting more done than ever before and I love it!
Maybe its the toolkit. Maybe an OFBiz port to hibernate would be Nirvana. Whatever. If you guys are so hot to trot on OO then get your butts moving and write something to rival OFBiz with your OO persistance layer du jour.
For the time being, we’re Koo Koo for OFBiz here at Brainfood.