There are many ways to compose enterprise applications' business layer. Early EJB version were bit of hard to use since there were many unnecessary (compared to other lightweight frameworks came lately) work/development to be done by the developer. Most recently there have been a huge improvements to the specs similar to that of the lightweight (web/business) frameworks provide.
EJBs are primarily focused on the business layer (and the persistence layer with the JPA support) of an application. There are many other frameworks which can be used to achieve similar results. But it can be a preference of a given project/company to use certain technology provider for their application. And most importantly the ease of use (as EJBs becoming more lightweight and easy to use over time) is a key factor.
You might want to check on some of the new features listed in FAQ for more information.
Also something to consider is that EJB design pattern came about before SOA design pattern. With SOA, the infrastructure is more immediate, and combinable. You can create new applications through composite of other , more granular services. If you contrast EJB with SOA, you'll gain some insight on when to use and not use EJB.
You would need EJBs in a Java EE application when you need services such as transactions, security, pooling, monitoring, asynchronous processing, scheduling and the like. The fist and second chapters of EJB 3 in Action answers this question in detail.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
As Reza mention, pretty much any business logic you have in your application is going to need these services eventually. So it's a good idea to start using EJB's from the beginning. Remember EJB lite runs inside the Web container so if you are "only building a web-app" there is no reason not to use EJBs since @EJB is supported inside a WAR file without the need to deploy them separately. With all this said, it is a great idea to use them.
Java EE Evangelist — Author, EJB 3 in Action 2nd Edition — Java Community Process Member
Roger Sterling wrote:Also something to consider is that EJB design pattern came about before SOA design pattern. With SOA, the infrastructure is more immediate, and combinable. You can create new applications through composite of other , more granular services. If you contrast EJB with SOA, you'll gain some insight on when to use and not use EJB.
I don't really see the contrast. They are not mutually exclusive. In fact, there is much to be said for implementing SOA using EJB, even without exposing your EJB's as WS. Depending on the interoperability requirements and Java EE server availability, I would prefer to implement SOA as Remote EJB's.
I don't see the use of choosing the slowest option by default. Except "everyone's doing it these days".