Banning EJB!

[Rafael Lee]

At present can EJBs be avoided in ANY application including mission-criticals? Have any open-source/commercial non-ejb tools already matured enough to do the advantages of EJBs? I'm not really inclined to using ejbs but my mind's open to opinions and experiences on this matter, including alternate tools. Thanks.

[Nathaniel Stoddard]

You could always develop something from scatch that does exactly the same thing as ejb, but name is something different.

[Andres Gonzalez]

 

Originally posted by Nathaniel Stoddard:
You could always develop something from scatch that does exactly the same thing as ejb, but name is something different.

ditto. You can always manage persistance, transactions (keeping in my the ACID), concurrency, etc. And, if you want more performance, you can develop it using pure C++. How does that sound?
I haven't found any tools that avoid EJB. there are probably generators, but they end up doing ejb stuff internally. if you don't mind leaving java, Have you checked .NET?

[Amol Takate]

Have any open-source/commercial non-ejb tools already matured enough to do the advantages of EJBs?

EJB/J2EE are the specification , which are based on open standard and not any commercial implementation.
If you want Open source implementation of EJB , you can use JBOSS App. Server which is a open source implementation of J2EE Specifications.

[Rafael Lee]

I am thinking along the lines of using alternate tools. For example, there are some who have used Hibernate extensively to say that it can ably fill in the shoes of Entity Beans., etc. How about the other EJB's?
[ December 11, 2003: Message edited by: Rafael Lee ]

[Joel McNary]

Session EJBs (especially the stateless ones) are the real powerhorse of the J2EE architecture. They provide for distibuted computing in an easy-to-use fashion. (Well, OK, their "ease-of-use" can vary depending on the App Server they're running on and how well you, the programmer, understand JNDI and RMI...)
I find that Entity EJBs are a pain to work with, but the benefits of working with them (concurrency/transaction management) outweighs their pains. If there's another tool that provides the same benefits but without the annoyances, then I don't see why you couldn't use that. But then, I wouldn't really see the difference between that tool and EJBs.
Yes, it is possible to develop without EJBs. In some cases, it is preferable (small applications almost never need them; the overhead involved outweighs the benefits. In that case you can skip the EJBs altogether and just work in a Servlet/JSP/JDBC paradigm, instead of the Servlet/JSP/EJB paradigm...).