What exactly is an EJB? Why was it invented? I've tried to go through some Sun tutorials but I wasn't convinced. I have used JSP/Servlets and it seems that it can do the same job (corrections very welcome), along with Struts. This is the only area of J2EE that leaves me bewildered. Is it some way of encapsulating all the business logic into a class? Don't we do that anyway (e.g. ShoppingCart.java for an ecommerce application)? Any simple guides on this?
1. Type of container : EJBs require ejb container and servlets require web server to run.
2. Type of ejb Beans: In ejb you can separate business logic by using session beans. Entity Beans provide for database mapping. You don't need to use database specific sql if using CMP but need to get acquinted with ejb-ql. MDB i.e. Message driven Beans provide for asynchronous messaging. This feature is not available in servlets.
3. All the ejb beans provide for transactional management either thru CMT(Container managed Transactions) or BMT (Bean Managed Transactions.) The Transaction scope can be extended to subsequent beans calls. I don't know how this transaction management is done in servlet.
4. Java Naming & Directory service- which provides for directory service where all different resources like printer,database,ejbs can be referred by unique ID. Hence providing for location transparency.
Ejbs and servlets both can be invoked remotely. Shopping cart example can be implemented by both using jsp and struts. I used servlets long time back so not sure how transaction management is done in servlets. I think the diff. between servlets and ejb lies in location transparency and transaction management.
The example shown is a simple web application which calculates a bonus. A simple client sends the social security number and multiplier via a HTTP Browser. This is made with both Servlets and EJBs, and I compared both.
No problem, everything works, the code is simple to read and you can continue to add more business logic as you need to.
Suddenly, with the EJB variant, all hell breaks loose. You must create SIX different classes. This implements that, an interface for this, a context for that and so on. Remember, the business logic method is 2 lines in the servlet and we finished with one simple class.
On compile with EJB, you get: -BonusCalculationServlet.java -BonusCalculator.java -BonusCalculatorHome.java -LocalBonusCalculator.java -LocalBonusCalculatorHome.java -BonusCalculatorBean.java
So all in all, I know which "method" I would choose. EJB just seems to add an unneccessary tier of more classes and interfaces for very little return. Whats wrong with creating a simple BonusCalculator.java class with "calculate()"? The servlet can then create an instance of this object and invoke the method when it has all the data it needs. Clean simple code that is easy to understand. The business logic is moved outside the servlet, which is what EJBs try to accomplish right?
Now someone convince me that I am wrong.
[ January 30, 2005: Message edited by: Kashif Riaz ] [ January 30, 2005: Message edited by: Kashif Riaz ]
Joined: Oct 18, 2004
You are not wrong to choose servlet for writing a simple task. Here is a link that compares both servlets and EJB. Though its quite old.
If you are just going to develop an application for bonus calculation then servlets would be more appropriate. But EJB's are really useful large distributed applications which requires features transactions, security etc.
Primary goal of EJB is to factor out common services needed by all distributed applications and let EJB container to support them. So that container vendors (who are experts in these services) can provide these services and application developer can concentrate on his own business logic.
Here are few advantages of EJB..
Container takes care of trasaction management (Have you heard of ACID properties that are needed for distributed databases..?)
Container takes care of security.. you easily implement entitlement ie specify which user Role can access which resource..
Provides database transparency.. i.e you can easily port your app. from database to another database..also you can easily handle table name or column name change without modifying your code.. (all just by changing config files) . But you should use CMP to get full advantages of this (Think about implications of porting to different database if you use JDBC within servlets)
Supports BUILD ONCE AND DEPLOY ANYWHERE (one step further to build once and run anywhere principle of JAVA)..so once the application is build you can deploy it in or port it to any container..
Everything is specified declaratively using xml (or any kind of) config files.. you can easily change the behaviour at run-time.
Container can support many optimizations like managing database connection pools..supporting pooling for your stateless session beans etc..
It also supports more advanced features like JMS, JCA (to integrate with any legacy system) , etc..