Java Enterprise is often a topic for many programmers in the free world (non m$ like one, I suppose ..). I don't think it was always a first option. There were and still there are pros and cons discussions. Still, Java Enterprise is an available solution. Thought, with a lot of books and good articles around, I often hear simply "amazing" thoughts about Java Enterprise. What is worst is that many of these are believed by so called Java Enterprise developers.
A lot of people still have some misconceptions about Java Enterprise. How this could happen? Perhaps due to the degree of configuration complexity of the firsts variants of the standard. Maybe because of the rigidity of the Sun guys, who kept in iron hands the previous releases (previous than 3.0). Perhaps because in the past the standard was not under JCP. Maybe none of this. I really don't know. But I will present some thoughts that I heard, and give some opinions on that.
EJB is for web applications
Simply wrong. Java Enterprise has nothing to do with web applications. To be more exact, Java Enterprise has the same link to web applications, as it has with other type of client applications. EJB is about business, about business distributed components and about integration. The consumers of these components can be any type of application that understands JNDI and IIOP, nothing more. Even if we see around a lot of web frameworks that are well integrated with EJB, that does not mean EJB is only for web.
With JPA you don't have to work with databases
I always considered that a good programmer is a lazy person. But a lazy programmer is a programmer which chooses to work less but smart instead of easy but with repeated tasks. If you choose EJB with persistence, than you choose to work with an abstract layer, which models your business. You choose to separate these layers. That does not exclude to improve the performance of database. There are often situations when a proper index can solve a big bottleneck. Don't be extreme on that. Persistence layer let you concentrate more on your functionality, don't exclude tuning database process.
EJB applications are always lazy
That is not true. I agree that Java Enterprise comes with a penalty performance. There is a cost for the ease of design and for generality. My idea is that every design tries to solve some classes of problems in trade of others. The art in application design (if there is one) is to make a good trade on that. It’s like in chess. If you want a benefit you have to leave something. The choices are core of the process. If your choices are good, the penalties are not relevant for your business. Going back to EJB, the initial performance penalties are traded for other benefits. As a sample, putting in place a cluster or a cache is not an easy job in state-of-art systems, in EJB this task is very easy. By choosing what components to be cached, the caching levels, by choosing a proper clustering structure you can benefit a lot. A common thing that is missed is the usage of entity managers. A almost always saw that the entity managers used are the default ones provided by wizards. That’s a bad choice. You must reconsider every opportunity. There are a lot of services for EJB components which can be configured with ease, that's the point. Don't put on work the wizards and consider you work done. You work begun after the wizards. Remember well, the choices are very important, and EJB container makes that job very easy.
Use EJB everywhere, is the best
Nothing is the best for everything. EJB has its place in software fauna. But it’s not best for anything you can think of. Sometimes you must consider using light web frameworks, sometimes is better to use light web scripting languages with fast databases. I can give clear receipts. If I put my two cents in, the rigid thinking does not do you any favors.
EJB is only about components and services for these components
I don’t agree. It’s true that components and container services for these components worth a lot. But there is something more, which I consider at least as important as the previous. This valuable thing is integration with external systems. I lot of people forgot that. But one of the main goals of EJB is the integration of external systems. The integration potential is, sometimes, the main reason to choose EJB in place of others technologies. We can review the times when EJB was put on place. A lot of big software consumers had a lot of big systems provided by different software vendors. It is a usual. Every system produces a part of the big picture. A lot of effort and money and knowledge are buried in those systems. The next step is to obtain the big picture. You can’t rewrite everything from scratch. You have to integrate the existent system. You have to put all the pieces together. EJB is good at that. Did you hear about resource adapters? Did you saw a detailed sample of a CORBA component written in C working with EJB? I bet you don’t. Unfortunately I never saw books with covers well this topic. Three pages from five hundred are not enough, but that is the sad average. I am still waiting for a good book to cover this, to exploit this potential.