Thoughts on Orion 2.0.x?

Hi,

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".