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.
Martin Schulz
-
Surviving competing approaches to EJB? (5 messages)
- Posted by: Martin Schulz
- Posted on: December 20 2001 20:18 EST
Threaded Messages (5)
- Surviving competing approaches to EJB? by Race Condition on December 21 2001 12:00 EST
- Surviving competing approaches to EJB? by Suresh Kumar on December 26 2001 12:15 EST
- Surviving competing approaches to EJB? by Pranab Ghosh on December 26 2001 17:21 EST
-
Surviving competing approaches to EJB? by Martin Schulz on December 27 2001 03:34 EST
- Surviving competing approaches to EJB? by Suresh Kumar on December 29 2001 07:44 EST
-
Surviving competing approaches to EJB? by Martin Schulz on December 27 2001 03:34 EST
- Surviving competing approaches to EJB? by Pranab Ghosh on December 26 2001 17:21 EST
-
Surviving competing approaches to EJB?[ Go to top ]
- Posted by: Race Condition
- Posted on: December 21 2001 12:00 EST
- in response to Martin Schulz
. -
Surviving competing approaches to EJB?[ Go to top ]
- Posted by: Suresh Kumar
- Posted on: December 26 2001 12:15 EST
- in response to Martin Schulz
Hi Martin,
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....
D.S.Suresh -
Surviving competing approaches to EJB?[ Go to top ]
- Posted by: Pranab Ghosh
- Posted on: December 26 2001 17:21 EST
- in response to Suresh Kumar
Most j2ee/ejb containers provide the following infrastructure services.
1. Distributed computing
2. Transaction management
3. Persistence
4. Security
5. Resource pooling
6. Thread safety and synchronization
7. Client state management
8. Messaging
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.
Pranab
-
Surviving competing approaches to EJB?[ Go to top ]
- Posted by: Martin Schulz
- Posted on: December 27 2001 15:34 EST
- in response to Pranab Ghosh
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.
-
Surviving competing approaches to EJB?[ Go to top ]
- Posted by: Suresh Kumar
- Posted on: December 29 2001 19:44 EST
- in response to Martin Schulz
HI martin,
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.
D.S.Suresh