This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
A typical Enterprise Java Bean consists of a -EJB Home, -EJB Interface -EJB bean class
In a client-server environment that's NOT an Enterprise Java Bean or running on an Application Server but instead just a java application that runs on the server, why would someone follow a similiar structure in designing their classes to have a Home, Interface, and bean class?
For instance if a client application (non ejb) was designed utilizing the Model of the MVC design pattern, when creating the Modeling classes one would typically create 1 class modeling the data. But instead utilizing the EJB design, you could create a bean class modeling the data, and have an interface, and also a home class that instantiates a singleton of the bean class or home. This is one scenario.
What would be the reasoning for using a similiar approach to the way EJB has a Home, Interface, and Bean class in a java application (non-ejb app)? Is it because of possible future migration from a traditional client-server environment to an EJB like environment?
Please give some thughts about the same.Also if i am migrating my application which is in JSP servelets to EJB, what will be cons for that.It is going fine with JSP and servelets.Experts please give some suggestions. [ December 30, 2006: Message edited by: Neetika Sood ]
Neetika, Let's map EJB to the parts of a non-EJB call to get the business data. 1) Home interface - Factory to create class or a simple constructor call 2) Remote/local interface - An interface describing the available methods. (This isn't required in non-EJB code, but it is good practice.) 3) Bean - The implementation
In non-EJB code, it may make sense to combine 1 & 3 into one class.
Originally posted by Neetika Sood: Also if i am migrating my application which is in JSP servelets to EJB, what will be cons for that.It is going fine with JSP and servelets.Experts please give some suggestions.
Not all applications need EJB. If you aren't using security/transactions/etc, using EJB is overkill. This is probably the case for you since you note that it is going fine with JSP and servlets.
First a client-server application is two ties. The Client tier which has pretty much everything, and the second tier is the backend database.
When you include "but instead just a java application that runs on the server" means that it is now three tier.
You can create such an application, but you will have to code all the services that an App Server gives you with EJBs. In order to get those services in EJB 2.x those Home, Interface classes etc were needed. In EJB 3.0 you only need your interface and implementation classes.
Why you need these? Cleaner seperation, translates into easier maintenance. In you "non-ejb" application, I wouldn't create a Home object myself.
If you are building a web application, you will need Servlets and JSP, it wouldn't be those classes being converted into EJBs, EJBs would be used in conjunction with them when you really need transactions and the other services EJBs might provide for you.
Thanks for responding and clearing my doubts.Now I understand that EJB can be used where I need transactions and the other services EJBs might provide.and as per Jeanne if I am not using security/transactions/etc, using EJB is overkill.
If you people can still clarify me...how EJB is overkill for a simple Web application(cons of EJB), it will be really helpful for me. Actually I was thinking to replace my service layer(containing interactions with DAO and business logic)in my simple Web application with EJB.
Hope to hear some explanation from you:-) [ December 30, 2006: Message edited by: Neetika Sood ]
author & internet detective
Suppose I have a simple web application that displays the classes offered in a semester. Its read only, so I don't need transaction support. Its public knowledge so I don't need security. EJB wouldn't provide me with much benefit here. Meanwhile it would introduce unnecessary complexity (a con), so I would go without it.
Now suppose I have a more complicated web application that allows me to register for courses. I do need transaction support to provide "all or nothing" operations so students can drop one course and add another. And I need security because I don't want people dropping the courses of others. So EJB could be of use. (Of course it doesn't require EJB. Some other way of providing these services is fine too.)