Juan, it's good to hear from you again. It's also good to hear that you are still using Orion. I am still running on an old version of Orion (1.5.3), and thinking about starting a project to convert to the latest 2.0.x version. Do you have any opinion on if I should bother staying with Orion or moving to JBoss? The last time I tried converting, I ran into some issues with Local interfaces (that was a while back). Are there any nasty bugs running around the latest version of Orion? The current version I am using, works fine for everything I am doing, but I would like to get "standard" EJB 2.0 support and start using EJBQL.
Any thoughts on this?
Thanks.
-- -AP_ http://www.myprofiles.com/member/profile/apara_personal http://www.myprofiles.com/member/profile/apara_business
Juan Pablo Lorandi wrote:
Hi ,
Can anyone suggest on the debate going on, that EJB is an overhead since its actual features are rarely used and for the purpose which we use EJB,we can always use some other things also.Your opinion on this.
That debate isn't going on anymore :-).
Using EJBs depends on the purpose. If you have to code stuff that solves problems that the EJB container solves for you if you use EJBs, then you're reinventing the wheel. If you get sick and need to be replaced, instead of calling in a guy with EJB skills, you'll need a guy that is familiar with your kind-of-EJB code. Best of luck finding them.
The debate isn't going on anymore because EJBs will never "improve performance" per se. Assembler and C++ will improve performance. Usually, what you care about is scalability, and while performance has a close relationship to scalability, under a number of situations improved performance might have a negative impact on scalability or zero impact. It doesn't boil down to performance, but to TCO. With EJBs, performance overhead is minor, and scalability doesn't involve coding... It's more of an administrative matter. Buy a new box, jack in, configure the load balancer. You've scaled. You've got code that's simpler to maintain. You can port your application to a different app server with only so much effort, in case your support has run out, or parts of your deployed application have reached "EOL".
Nowadays I use EJBs for almost anything that needs to call a DB, not because of performance, but because of speed of development and ease of use. I code with IntelliJ IDEA, and the app server usually is Orion. Under these, coding an CMP-EJB bean is faster than coding direct JDBC. I'd only revert to JDBC if very specific performance optimizations are needed. Of course, if I was to use, say, Websphere, I'd be stuck with writing DAO's. This isn't Sun's fault, but IBM's. That said, the J2EE compliance test suite should make them NOT to endorse Websphere. Orion makes it really easy in practice to have DB-transparency, so I guess that different deployment scenarios may make EJBs more or less desirable.
There's a lot about EJBs that I'd like to be changed. But the bottom line is: it's very existence makes MY life easier. If you want performance, drop Java altogether and learn some Assembler. Best of luck going about it.
My 2c,
Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED]
Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
