As of Java EE 5, EJBs are really just ordinary Java objects with a few additional behaviours added, primarily:
- Dependencies are automatically injected into their fields
- Their methods are automatically exported to remote clients via RMI
- Security checks are automatically applied to invocations of their methods
- Transactions are automatically wrapped around invocations of their methods
There are a few other services that are specifically available to EJBs, such as asynchronous invocations, timers, and coupling to message queues.
If you think any of those things would be useful, then you should consider using EJBs. If you’re learning about Java EE, then you definitely need to learn about EJBs, so that you can make an informed decision about whether to use them or not.
It’s worth noting that in modern Java EE, there is a standard called Contexts and Dependency Injection (CDI) which can be used to obtain many of the benefits of EJBs, and may be preferable. You should definitely also learn about CDI.
Many web applications are built without any EJBs at all. Most web applications user either CDI or some earlier, non-standard, equivalent such as Spring or Guice.
Hibernate is an implementation of the Java Persistence Architecture (JPA) standard. JPA is about persisting objects to a database, and provides completely different services to EJB. You would use JPA for your entity objects (which capture the structure and fundamental behaviour of your data), and EJB or CDI for your service objects (which capture the specific business logic of your application).
Earlier versions of EJB did also provide persistence of EJBs, and so had some overlap with JPA, but that is only of historical interest now.
out of my memory 