Why learn EJB? It adds a layer of complexity to you app's especially statefull session beans. Seems as if the java world just loves to drive up cost of development by complicating things. Sun clean up your act, get rid of EJB before dot net takes over Java's market share.
I think by saying this you are challenging the 3-Tier or multi tier architecture and not the EJBs...Becoz Ejbs are meant for implementing n tier architecture in applcations and there by utilizing all the advantages presented by these kind of Architectures i.e. modularity,load sharing etc.....
I may not be the best person to answer this but I do believe those who wrote EJB specification are not idiots.
Have you thought of puting multiple databses in one transaction?
Have you thought of 20K concurrent transactions/sec.
Just think of maintaining transactions across Operating System/Physical systems?
In case you are microsoft champ then hope, meet you in .NET section too.
I think EJB is a technology that people need to understand. Its one of the few remote technologies that can participate in a distributed transaction.
However, I suggest you learn techniques for creating a modern J2EE application without using EJB "just because". I would explore a much simpler approach first as recommended in the Spring Framework (www.springframework.org). A good book which covers this technologies as well as compare it to other similar technologies check out "Expert One-on-One J2EE Development without EJB" by Rod Johnson, Juergen Hoeller. There are also other Dependency Injection containers like PicoContainer and HiveMind.
Here are three reasons:
1. Separation between Model, Control and Views (MVC Pattern)
2. Standardization between vendors
3. Declarative services permits you to concentrate on business logic(use of distribuited transactions, declarative Security)
There are EJB things I don't like (e.g. entity beans) but the most of EJB help in building high scalable enterpise application easier to maintain.
P.s. are stateless session beans so complicated and hard to understand? :-)
You dont need EJB to implement the MVC paradigm in the J2EE tier. Have you ever heard of Struts or simply using servlets as forwarders.
What about the transactions ,two phase commit, Concurrency and asynchronous calls.
and if you want expose the business logic of that struts application with a GUI interface, or on portable devices, or as XML/web serverices? (i.e. you want to renderize the model in different manners). Probably in that case you need some kind of application server containing the business logic (the model)...:-D
You always need not use EJB as part of your model. If your application has to deal with concurency, transaction, persistence, session management etc, go for EJB these things will be taken care of by the container.If you hate Sun and EJB, if you are good enough to manage everything your self, forget abt EJB, use your own model. But container does this services in optimized way. EJB is complex but it will pay you ultimately.
For short, you shouldn't.
Developing EJB's is a very time consuming process which is can be very error prone. The invasive nature of EJB's in your current application makes it hard to manage. Testing an EJB costs alot of time since you have to deploy the EJB for even the most simple test.
All these facts have lead to more lightweight frameworks including the two most common: Springframework and Hibernate.
MVC is nice, but in combination with AOP (standard functionality of spring) it becomes far more powerfull. But still easy to maintain and test.