To me this thread shows exactly what is wrong with our profession. Too
many people read the marketing literature and take it as gospel.
You
use EJB when and only when you need the container services. That is,
transaction, persistence and security. Now if you follow the advice of
most and don't use Entity beans that leaves you with security and
transaction. Very few people use the security features on EJB so that
leaves you with transactions. There are many other often easier ways to
deal with transactions though so it is still questionable if you ever
need EJB.
Let us examine some of the comments made so far.
1.
Scalability - Why is it more scalable? If you are using Stateless
session beans you are scalable because you are stateless. But if you are
stateless it is just as easy to use POJOs (Plain old Java Objects) .
Stateless design leads to better scalability but EJBs are not necessary
to make your application stateless. Again the only advantage is the
container services provides - otherwise it is just code folks - and your
code will work just fine.
While we are at it lets address
another common misconception. Lifecycle management. It is often claimed
that EJB gives you some necessary lifecycle management and object
pooling. It also is supposed to help you in a multi threaded
environment. The trouble with this claim is that if you are stateless
there are no threading issues and you only need one instance to handle
all of your clients on a server. Servlets and stateless Session beans
are essentially equivalent ( keep in mind that HTTPServlets are only one
type of Servlet). In the world of Servlets the spec allowed you to
either create a new Servlet for every client or to use one and make it
thread safe. Every servlet container does it the second way and yet EJB
only allows containers to do it the first way.
2. Performance -
??? What are they doing to improve performance. I can either call an
object directly or go through layers of infrastructure - which do you
think would be faster. Again only if we need the infrastructure is it an
advantage (and NONE of the EJB infrastructure is to help with
performance).
3. Maintainability - If I use OO programming
methodology instead of the procedural based EJB I will be better off not
worse off here. Why do people think that only EJB will get you
modularity? Also testability is more difficult with EJB then POJOs and
by decreasing testability I decress maintainability.
4.
Different clients - Granted you need a server to handle the different
clients but you don't need EJB for them to all call the same code. You
just need the same object to call. Objects themselves don't care about
who your client is. If I have some object Foo with method bar and that
method is such that I can have copies of it in different app servers
that are all the same ( a requirement for clustering) then all I have to
do is have each client create a Foo and call foo.bar(). Why is it
better to do the JNDI lookup to find the Foo (when they are all the
same) and then use an RMI layer to call the bar. Even if we are calling
the database here it is the conection pooling and the database that
gives you your advantages - and there were connection pools long before
there were app servers and you can use them in an AppServer even if you
are a POJO.
5. Database access - One poster said if you use your
JSP/Servlets to access the database all the time it will be slower
because you don't get help from the container. This is a false
dichotomy. I can still have an object layer and a data access layer and
never have my JSP/Servlets directly make SQL calls. I don't need EJB for
that and unless you are using Entity beans which means you have an
extremely simple domain model, the container is doing nothing for you
here.
History is important here. EJB arose out of a desire to
make CORBA easier to deal with. The reason you would use CORBA is as an
integration technology. You had a system (maybe an old batch system)
that you wanted to access from an OO or other program. With a CORBA
interface you could make it more object like to the client. When doing
this properly there were some cross cutting concerns that crop up like
Transaction management, Security etc that people designed frameworks to
get around. EJB was supposed to help here. The problem is that the
context - a wrapper for older technology or across system boundaries was
lost and now people advocate using EJB when it is all one system, you
don't distribute, and it is a brand new app. But why? I love JMS for
integration but I don't think you should endlessly send messages to
yourself within an application.
Most projects should have at
most one or two EJBs but I see people create systems with hundreds of
them. This is stupid and wasteful. You have made your build times
longer, your deployments more complex, and your code harder to test.
What would be better for our industry is for people to actually learn
about OO Design and stop with trying to shove procedural technology in
the way and calling that progress.
source: http://www.theserverside.com/discussions/thread.tss?thread_id=30165
