I would like to kindly get your insights with regards to EJB (version 3.x) used as Business Layer in the Application. What are the advantages and disadvantages of considering it in the architecture? And in the case of not considering it, what are the best alternatives to achieve such like features or convenience? This may be in all phases of software development like iterative changes, updates/upgrades, testing, maintenance, interoperability, and deployment.
The short answer is that there can be a strong case for EJB when you need distribution, transactions or messaging. Of course, a lot depends on where you are coming from. For instance, if you and your department already have a lot of experience of EJB development, then you won't be having much of a debate about this. But if you are new to EJB, then you would be faced with a steep learning curve if you adopt this technology.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Joined: Apr 01, 2007
We are using EJB Technology for quite awhile, but my team & I would like to get some insights of where we are heading. Because most of the latest architecture out there do not use EJB, instead they are using DAOs, POJOs, and the likes.
Thanks again, and we really appreciate you guys sharing your comprehensions, and insights.
Joined: Sep 29, 2002
DAO and POJOs are often used with EJBs, not instead of. Of course, the recent EJB 3 specification is much more POJO-based than the previous specs.
Some people have been using other frameworks such as Spring. As Spring can also be deployed in a WebLogic Server container, then you can get the benefits of a heavyweight J2EE server with Spring's reusable business and data access objects. This does seem to be an approach that some developers like a lot.