I recently had an interview with a government organization
who want to custom build a Java database access layer.
I couldn't help but point out all the long the crucial features of EJB containers. Apparently they had done their
homework and rejected that option (and I didn't get the contract).
I realize that one can fairly easily build or even generate a database access layer using JDBC and a OR-mapping tool. However adding remote access, security,
transactions, roles etc. for an enterprise-class layer
is a different story.
Such approaches have certainly existed and some may have
survived. I would be interested in war stories about
abandonned and still existing approaches - general satisfaction, additional and missing features compared to EJB, learning curve.
I am only interested in actual efforts of some size which
have either been abandonned or are ongoing, let's say > 5 man-years.
Thanks for your patience. Happy holiday to all.
Some time back I was in the same situation as yours.. But I found an alternative feasible and yet robust and competetive solution.
Most of the times we dont use the Trasaction controls effectively( defined by EJB) we do commit or roll back on a specific set of operations and it is most of the times atomic...so bulding Transaction control ourselves does not matter much.
Coming to CMP stuff.. its fairly easy to build our own XML mapping mechanism like the TopLink( a mapping tool)'s projects..
I dont think building a easy to use and easy to control tool should take more than couple of months...
I do have a customized solution which I use currently for all my projects... If you are interested I can share that with you....
Most j2ee/ejb containers provide the following infrastructure services.
1. Distributed computing
2. Transaction management
5. Resource pooling
6. Thread safety and synchronization
7. Client state management
9. Object life cycle management.
All these services can be built from scratch. But is it worth reinventing the wheel. I don't think so, unless time to market does not matter to you.
Based on my experience, unless the application is very simple e.g., simply viewing bunch of data from the database, it pays off in terms of saving of time and resource to use a j2ee container.
OK, for small scale persistence frameworks you don't have
to use J2EE EJB containers. In fact persistence tools and EJB can be used together, if you have a complex OR mapping
situation or need a better handle on performance.
But my initial question was whether there are any existing,
large scale frameworks (commercial or custom built) with
functionality comparable to J2EE application containers which are arguably not inferior to J2EE?
Basically that's what the guys were suggesting to build
and I was reluctant to concede economically feasible.
Hypothetically, I would play mind games as follows:
: Remove a feature from J2EE EJB containers and see if
: it would make sense to implement the remaining features
: independantly of J2EE.
Now the only 'feasible' scenario I could imagine would be
to remove the remote accessiblity feature from the J2EE EJB
features. That would warp the picture enough to warrant
an independant implementation. On the other hand, it would
affect other key enterprise features (connectivity, scalability) in major ways, and I wouldn't like the end result.
Bottom line: I'm not convinced that something 'better than J2EE EJB' can be built; but I am intrigued enough by the idea to ask if anybody has seen such a beast.
Yes I do agree with you in terms of project size and cost issues. But taking off distributed aspect would not be desirable when scalability is in consideration and todays environment you never know when a company gets bouth or buys a new company...
SO I would still keep distributed aspect of the application but would like to leverage persistance mechanism that can be built with simple J2EE based components ( Not necessarily be EJB).
There are lot of persistance engines available one of them is TOPLink that gives more flexibility to hanlde database persistance.
Expresso ramework seems to be really good it can be EJB compliant as well as independent of EJB stuff.