EJB design: When to use EJB?
I know it is a bad question, but if my application use only stateless and statefull session bean. Do I still need to use EJB and app. server, instead of using servlet with Tomcat??
Why EJB is more scaleable and cluster friendly? Someone said if I want a 24/7 server (which I do), I need to use an app. server. Is it true?
If I use Tomcat, I can still cluster it and failover etc..., what is the true benifit of using app server than just web container?
any help will be appreciated
- When to use EJB? by Bob Lee on November 24 2004 01:43 EST
- When to use EJB? by lam yue on November 24 2004 23:27 EST
- When to use EJB? by Jaise George on December 02 2004 04:28 EST
- You need EJB container by Namik Aloglu on November 29 2004 03:02 EST
- When to use EJB? by Prabhudatt Rana on November 29 2004 07:34 EST
- RE:: When to use EJB? by Anirban Basu on November 29 2004 10:20 EST
- RE:: When to use EJB? by Namik Aloglu on November 30 2004 06:58 EST
- RE:: When to use EJB? by Anirban Basu on November 30 2004 07:30 EST
- RE:: When to use EJB? by Namik Aloglu on November 30 2004 06:58 EST
- When to use EJB? by Bob Lee on November 24 2004 01:43 EST
You don't need EJB if you're only developing a web client.
really? if I want to support pda, mobile phone etc... do I need to use EJB?
Still you don't need EJB
When one uses EJB, the application becomes multi-tired. Because of this presentation and business logics are separated. Besides, for huge applications, one can rely on the services like security, transaction and persistance provided by application servers. The developer needs to concentrate on the implementation of business logic.
Some time back, I read an article by Ed Roman on the same subject. I think it is available in the archives of theserverside.com. The key points from that article and some other places are given below:
The definition of EJB states that it is a distributed, transactional, persistent software component written in Java Programming Language. From this definition, it can be derived that EJBs are required in the following scenarios.
i. When the application is distributed: When the resources and data are distributed across multiple sites, then it is ideal to go for an application that is based on EJBs. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
ii. When the application is performance-centric, use of EJBs and the application server provide high performance and very good scalability.
iii. Declaratively manage transactions. When transaction management is required to ensure data integrity, EJBs may be used. In EJB, you merely specify whether a bean's methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you'll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple DataSources.
iv. Declaratively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean.
v. Separation of Business Logic. The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This can be achieved using Servlets and DAO also
Hope it helps.
I have my points and questions :
When the application is distributed:
What does it really mean a distributed application ? Does it mean multiple users use one application connecting to a multiple database spread across network or something else ?
When the application is performance-centric
I think performance-centric has nothing to do with EJB.
Declaratively manage transactions
Hibernate and XA can do this as well.
Declaratively manage security
I agree at this point.
Separation of Business Logic
Spring + Hibernate + Struts do that as well.
This can be achieved using Servlets and DAO also
So, I think the only thing you use EJB is only when you have a security feature. Other than that, Hibernate is a good alternative to use.
Hi,I have my points and questions :When the application is distributed: What does it really mean a distributed application?That the application consists of multiple (physical) components. And note that database is not part of the application.
When the application is performance-centricI think performance-centric has nothing to do with EJB.EJB (when correctly applied) make your application scalable, as they can be clustered. Of course you can achieve scalability by clustering whole application and load-balance incoimng client requests (e.g. HTTP) instead of intermediate, intra-application requests (e.g. RMI/IIOP). Also EJB are thread-safe so it's rather trivial to avoid any contentions due to locking in the application.
Another thing EJB have with performance is that they can greatly increase latency due to overhead, if their use is too fine-grained or if the app server sucks...
Declaratively manage transactionsHibernate and XA can do this as well.Actually, Spring (Spring AOP to be exact) can. With Hibernate and XA you can do it only programmatically.
Declaratively manage securityI agree at this point.Again, this could be done with Spring AOP. But as far as I know there are no pre-made "aspects".
To me this thread shows exactly what is wrong with our profession. Too many people read the marketing literature and take it as gospel.
You use EJB when and only when you need the container services. That is, transaction, persistence and security. Now if you follow the advice of most and don't use Entity beans that leaves you with security and transaction. Very few people use the security features on EJB so that leaves you with transactions. There are many other often easier ways to deal with transactions though so it is still questionable if you ever need EJB.
Let us examine some of the comments made so far.
1. Scalability - Why is it more scalable? If you are using Stateless session beans you are scalable because you are stateless. But if you are stateless it is just as easy to use POJOs (Plain old Java Objects) . Stateless design leads to better scalability but EJBs are not necessary to make your application stateless. Again the only advantage is the container services provides - otherwise it is just code folks - and your code will work just fine.
While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server. Servlets and stateless Session beans are essentially equivalent ( keep in mind that HTTPServlets are only one type of Servlet). In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.
2. Performance - ??? What are they doing to improve performance. I can either call an object directly or go through layers of infrastructure - which do you think would be faster. Again only if we need the infrastructure is it an advantage (and NONE of the EJB infrastructure is to help with performance).
3. Maintainability - If I use OO programming methodology instead of the procedural based EJB I will be better off not worse off here. Why do people think that only EJB will get you modularity? Also testability is more difficult with EJB then POJOs and by decreasing testability I decress maintainability.
4. Different clients - Granted you need a server to handle the different clients but you don't need EJB for them to all call the same code. You just need the same object to call. Objects themselves don't care about who your client is. If I have some object Foo with method bar and that method is such that I can have copies of it in different app servers that are all the same ( a requirement for clustering) then all I have to do is have each client create a Foo and call foo.bar(). Why is it better to do the JNDI lookup to find the Foo (when they are all the same) and then use an RMI layer to call the bar. Even if we are calling the database here it is the conection pooling and the database that gives you your advantages - and there were connection pools long before there were app servers and you can use them in an AppServer even if you are a POJO.
5. Database access - One poster said if you use your JSP/Servlets to access the database all the time it will be slower because you don't get help from the container. This is a false dichotomy. I can still have an object layer and a data access layer and never have my JSP/Servlets directly make SQL calls. I don't need EJB for that and unless you are using Entity beans which means you have an extremely simple domain model, the container is doing nothing for you here.
History is important here. EJB arose out of a desire to make CORBA easier to deal with. The reason you would use CORBA is as an integration technology. You had a system (maybe an old batch system) that you wanted to access from an OO or other program. With a CORBA interface you could make it more object like to the client. When doing this properly there were some cross cutting concerns that crop up like Transaction management, Security etc that people designed frameworks to get around. EJB was supposed to help here. The problem is that the context - a wrapper for older technology or across system boundaries was lost and now people advocate using EJB when it is all one system, you don't distribute, and it is a brand new app. But why? I love JMS for integration but I don't think you should endlessly send messages to yourself within an application.
Most projects should have at most one or two EJBs but I see people create systems with hundreds of them. This is stupid and wasteful. You have made your build times longer, your deployments more complex, and your code harder to test. What would be better for our industry is for people to actually learn about OO Design and stop with trying to shove procedural technology in the way and calling that progress.
Q. When to use EJB?
A. When your management thinks if you are not on the IBM boat your project is already doomed.
A. But, Seriously,
Use it when you need distributed processing (not just when dealing with multiple data sources or hetrogenous data sources) You will never regret it.
A. Performance comes from a good design not from using the container provided services.
A. "Declaratively manage transactions": Yeah right...Just because it is one of the things you can do declaratively. Your transaction scope rarely changes to really take advantage of this. Even if it does their are other ways of doing managing it. Use a good Framework or if your project can afford it, "build" it.
A. "Declaratively manage security" Make sure this is really the requirement. Again a framework or AOP can decouple security management for you. You can even provide single sign-on, integrate with AD(LDAP) etc. with the help of a good framework.
A. "Separation of Business Logic" True that! But what about separation of infrastructure code from business logic. I mean the clean kind. You may delegate BizLogic to a POJO from by SLSB facade. But do you need local interface or remote. Since, you would never arrange for both. If you need local might as well go with POJOs and provide a remote facade later if the need arises (only when you need remote invocation).
A. Either ways, EJB or POJOs one needs immense exposure to other architectural skills to give your application a good health and longevity (by virtue of scalability and maintainability).
So, focus on building those skills rather than. Hinging your projects success on this choice. Better projects can be built either way hence use other considerations to make this choice. Whether you have the budget, commitment to a single vendor(to take advantage of the features that makes one container better than the other you need to use container specific capabilities), development resources etc.
Praxis Strategies LLC.
You use EJB when and only when you need the container services. That is, transaction, persistence and security.What about lifecycle? Request throttling? Load-balancing?
Anyway, the best persistence "container" is a good UPS or Flash RAM. If you think you need more than that, you don't need just persistence...
Very few people use the security features on EJB so that leaves you with transactions.From what I've seen so far, very few people use any kind of security features besides custom login dialog...
There are many other often easier ways to deal with transactions though so it is still questionable if you ever need EJB.Can they propagate over VM boundaries? But if you don't need that, then "other ways" are quite equivalent to EJB transactions.
Scalability - Why is it more scalable? If you are using Stateless session beans you are scalable because you are stateless. But if you are stateless it is just as easy to use POJOs (Plain old Java Objects) . Stateless design leads to better scalability but EJBs are not necessary to make your application stateless. Again the only advantage is the container services provides - otherwise it is just code folks - and your code will work just fine.Problem is, just using a SLSB or saying that this POJO is stateless does not make the application stateless. Various caches, resources such as conenction pools, JMS conn. factories, (dynamic) configuration creep in very fast. And as creating and destroying them on each request is rather wastefull. EJBs give you an option of "any state will do", something between (completely) stateless component and a statefull component.
In order to support this "intermediate" statelessnes, lifecycle (activate/passivate, ejbCreate/ejbRemove) must be defined.
While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server.Lifecycle won't help you directly with multithreading. What helps you with it is the guarantee that only one thread can enter a component at any time. Now as a global lock would not scale at all, copies of the component must be made. Lifecycle is then brought in to reduce the number of components.
In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.Hasn't been the first way deprected for servlets?
Maintainability - If I use OO programming methodology instead of the procedural based EJB I will be better off not worse off here. Why do people think that only EJB will get you modularity?Plain OO regulary result you a tangled web of objects, patterns and refactoring notwithstanding. EJB at least force programmers and architects to think a bit about components/modules, and with some luck they design them so that they expose as small interface as possible.
Also testability is more difficult with EJB then POJOs and by decreasing testability I decress maintainability.In my experience:
testing an EJB: deploy EJB, run each method on edge inputs and a few regular cases
testing POJO: initialize object and all its dependencies, test all tricky sequences of calls, execute all mehtods, hope that bugs in dependant objects don't affect tested one too much
Different clients - Why is it better to do the JNDI lookup to find the Foo (when they are all the same) and then use an RMI layer to call the bar.That's the way all remote calls are done (CORBA, RMI, DCOM...). Think of lookup as a fancy constructor.
Most projects should have at most one or two EJBs but I see people create systems with hundreds of them.Doh. People like that deserve to have their job outsourced. EJBs are primarily a component (reusable, physical (deployment-level) chunks of software) technology. If tehy can't design a simpler interface to the application than all the classes (usually too many EJBs come from wrapping each "business" class with an EJB), then maybe an interface to the application shouldn't exist in the first place.
What would be better for our industry is for people to actually learn about OO Design and stop with trying to shove procedural technology in the way and calling that progress.Unfortunately "OO Design" fails big time in quite some areas.
Witness SOAP (formerly Simple Object Access Protocol), which is a "transport"-agnostic RPC (Remote Procedure Call) in XML and is as OO as Pascal. Same goes for CORBA with OO Design style (there's an anecdote floating around that novices regulary made String remote).
Witness the failure of OO in data management, where OODBMSes are still a niche player (some would say they have even lost market- and mindshare) even after 10 years. And OO extensions are mostly ignored by users of RDBMSes, even when they are Java programmers.
If u need to use statelees/statefull enterprise beans in your project then u have to use a EJB container so called app server.
a)scalability (horizontal) is not important
b)Just HTTP is the access technology for your application
c)your design is small size
then u can realize your design around a servlet/JSP container like Tomcat.
If you think that you will have different clients apart from just web browser (like PDAs) then you should go for EJBs. Because on TOMCAT your session trecking is mechanisim is HTTP protocol dependennt , and in case of session bean session is maintained irrespective of our protocol. So no matter whichever client u have your application will work.
I hope i am clear.
Just saw the debate going on EJB. But it seems that somebody is not clear about the requirement he/she has to fullfil. Obviously you can ommit the third layer of apps(EJB) from your application and make a 2 tire one. But that has some limitations, friends.
If you need:
1) scalability in a larger sense,
2) cluster support from an application server,
3) more distributable architechture,
4) modular approach to the solution.
You have to use EJB. And to go for an EJB approach you need to have an app server., anything u choose. EJB is not only concerned with session. Its primary usage, I would say persisitence. No other way u can easily implement that.
Without EJB, ur apps will be:
2) difficult to maintain,
3) less modular,
and some more bad qualities...
Hope this gives you all some focus.
About your assertions:
1) slower : How can a J2EE project without EJB be slower then one with EJB? ( serialization,call-by value trasnmisiion etc)
2) difficult to maintain / less modular : Being simpler (just using servlet/JSP container+framework/struts) doesnt leads unmodularity but being complex (servlet/jsp container+framework/struts+EJB Container) means diffucult mantainablity.
Most of the project we dont need EJB :)
Obviously slower. If your servlet and JSP is going to access database all the time, u r not going to get any help from the application container.
Using struts u can achieve that sure..but any change in apps will cause much rework. which is not the case with EJB.
Ya. sure in most of the projects u dont need EJB. Where simplicity is of greater importance than performance, security, etc. there forget about EJB. and where thats not then u have to use EJB.
When to use EJB, I think you should use it, when you have a client server environement where some client are not Web client, and your business logic therefore should be implemented in the EJB components (and your state).
If its just for web I have trouble (taken the EJB complexity into concern) seeing where you need EJB. Use IoC instead its much simpler.
my 2 cents.
i am in the same boat as Koon Yue Lam. What is IoC?
Ioc is a light weight container framework. The most wellknown is Spring. (see www.springframework.org).
Ioc is a light weight container framework. The most wellknown is Spring. (see www.springframework.org)./Per
A litlle fix to my last post.
Actually IoC is a pattern which again is used by frameworks like Struts.