This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Are EJBs overused?  RSS feed

 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have noticed a trend in the Java world to push EJB solutions at every problem. EJB solutions can be quite expensive and difficult to implement. Has this become a case where EJBs are "cool" and that's why we are using them? Are EJBs really worth the extra effort above a servlet/JSP solution? Is this a case where our favorite tool is a hammer so every problem looks like a nail? What are your thoughts on this issue?
 
Randy Coates
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting question. If you consider a good design one where the presentation and business logic layers are separated, the question really translates into a comparison of an EJB-servlet combination to a simple servlet solution. JSPs are really the presentation layer, so they should not contain business logic.
EJBs provide some advantages over a simple servlet solution:
1. They attempt to aid programmers in the separation of the business logic and data layers of their application and in creating a good object-oriented solution. Servlets can also do this, but servlets do not encourage the consideration of division of labor between data access and business rules like EJBs.
2. They are also a more scalable solution than a straight servlet implementation. With most applications, though, the scalability factor probably does not push the solution into the need for an EJB implementation. They do provide flexibility for the future, though, which in some cases adds weight to the EJB side of the decision.
3. EJB2.0 provides some conceptual and design advantages over earlier EJB specs and over servlet solutions -- message-driven beans that allow for asynchronous communications via JMS and relationships between entity beans (data) to name two.
A good book on the topic of EJBs is the O'Reilly Enterprise JavaBeans book by Richard Monson-Haefel, now in it's 3rd edition. The first chapter has a good overview/history of component models/.../EJBs.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, it's not quite that simple -- there are lots of subtle issues here...
Originally posted by Randy Coates:
Interesting question. If you consider a good design one where the presentation and business logic layers are separated, the question really translates into a comparison of an EJB-servlet combination to a simple servlet solution. JSPs are really the presentation layer, so they should not contain business logic.
EJBs provide some advantages over a simple servlet solution:
1. They attempt to aid programmers in the separation of the business logic and data layers of their application and in creating a good object-oriented solution. Servlets can also do this, but servlets do not encourage the consideration of division of labor between data access and business rules like EJBs.
EJB's don't encourage it either. Basically, no technology will encourage good programming. I've seen horrible layering decisions made with EJB's -- I've also seen equally horrible layering decisions made without EJB's.
In other words, it's a moot point. You can do perfectly good layering with standard Java clases. Yes, you don't want to put business logic in a servlet -- butyou can put them in a plain-old-vanilla java class that the servlet calls and achieve the same end...

2. They are also a more scalable solution than a straight servlet implementation. With most applications, though, the scalability factor probably does not push the solution into the need for an EJB implementation. They do provide flexibility for the future, though, which in some cases adds weight to the EJB side of the decision.

The solution is not necessarily more scaleable at all. In fact, you can achieve linear scaling with both pure-Servlet and Servlet-EJB solutions -- it's just that the method of load balancing differs in each. This article for instance discusses servlet scaling. Thus, it's another moot point.
3. EJB2.0 provides some conceptual and design advantages over earlier EJB specs and over servlet solutions -- message-driven beans that allow for asynchronous communications via JMS and relationships between entity beans (data) to name two.
I'll certainly agree that EJB 2.0 provides a lot of advantages over previous specs. However, that's still not enough to warrant using EJB for many applications. My basic set of questions are:
(1) Do you need 2-PC across multiple datasources? If so, then you HAVE to use EJB -- it's the only game in town.
(2) Do you really need object distribution (usually because you have multiple client types)? If so, then EJB's are a good choice, but not the only choice (RMI, CORBA and Web Services jump to mind...)
(3) Do you need method-level security on your objects? If so, then EJB's are a good choice -- otherwise you have a lot of special-purpose security coding ahead of you...
(4) Do you need automated object persistence? If so, then CMP EJB's may be right for you -- however, be aware that there are lots of other persistence solutions that might work better...
Now, if you answer yes to more than one of these questions (or yes to the first one), then EJB is probably a good thing for your application. Otherwise you may be better off without them. EJB's come with some disadvantages you have to consider:
(1) High runtime overhead compared to other Java solutions for similar things (for instance, vs. straight JDBC for persistence)
(2) Steeper learning curve than straight Java
A good book on the topic of EJBs is the O'Reilly Enterprise JavaBeans book by Richard Monson-Haefel, now in it's 3rd edition. The first chapter has a good overview/history of component models/.../EJBs.

I'll certainly second your opinion of Richard's book -- that's why I wrote a workbook for WebSphere on it for him
Kyle
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the larger problem is that there's no "quick-and-dirty" solution when you use EJBs. True, there's a lot of runtime overhead, but that's rarely a killer issue with today's hardware, and a lot of that overhead comes from the multitude of benefits that the EJB architecture
provides.
However, you can't just "hack out" an EJB-based solution. To get even a minimal system to work, you have to produce a whole wagonload of source files, each of which has to be precisely co-ordinated.
That's why I have spent so much time cultivating my EJBWizard tool. The next version out will support generation of Struts classes and JSPs, including the Form Beans and EJB proxies and that will be very useful, I think, but when you try and build REALLY complex scenarios (think of a session EJB managing a parent/child relationship of Entity EJBs), you have to wonder if maybe there couldn't have been a simpler way.
 
Rick Salsa
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Depends on what you need to do? I personally like EJB's a lot!! I agree for simple sites that they are absolutely over kill. You could just make helper classes to accomplish some of the same things. When it comes down to building enterprise level stuff, I don't find all the classes needed a big hindrance. If you think about everything you get for free from the EJB container just by extending some interfaces, I think that's great!! I personally don't want to, or have the time to write things like transaction systems, etc. Especially since nowadays, everything has to be done like yesterday.
EJB's are no way the answer to all our prayers. A lot of people are using them because they think that it will auto magically make everything better. A lot of design work needs to be done for it to work right. I agree with Tim, you can't just hack something out and expect it to work well.
So in the end, you really have to ask yourself, what do you want it to do? You could design the application in a way that uses JSP/Servlets/JDBC and refactor it to use EJB's in the future.
Just my 2 cents,
/rick
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My concerns are that EJB servers are very expensive and that most sites don't need all the functionality that an EJB server provides. Transaction processing is a good example. If you are accessing a single database then you can simply use JDBC commit/rollback and forget about the complexities of EJBs.
 
Kirt Henrie
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have used EJB's in a number of projects and have found their performance to be acceptable. I think misuse of EJB's is probably the most common problem.
I always use JDBC to retrieve read only result sets (for master views), and only use entity beans for inserts and updates where transactions and security can easily be configured. Using stateless session beans as a facade to entity beans gives you an excellent place to manage transactions and security without compromising performance.
A well Architected EJB application can reduce coding time making it more comparable to a less robust architecture.
As for cost, offerings like JBoss (free), and Orion (inexpensive) have made EJB alot more viable.
KJ
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A well Architected EJB application can reduce coding time making it more comparable to a less robust architecture.
I don't see how using EJBs can reduce coding time as compared to a common framework like Struts. In fact, the complexity of an EJB solution would probably make the coding time greater. And it would certainly make the debugging much more difficult especially for a low end solution like JBoss.
 
Kirt Henrie
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not real familiar with Struts, however I have developed my own frameworks that are more tailored to the organization I work for.
In addition, I have developed a couple of tools that make generating entity beans, dictionary classes, and lists from simple property files quick.
As for debugging, I use Log4J for logging, and have integrated Orion into JBuilders VM so I can debug EJB's, Servlets, and JSP's (generated source). Because Orion is hot deployable I have simple scripts that build the application with any additions/modifications and deploy it without even restarting the server. I have done the same thing with JBoss in the past and it works excellent.
The combination of tools and methods above has allowed me to develop applications quite quickly without limiting flexibility in the application.
KJ
 
Rick Salsa
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the issue here is where is the drawing line? How small is too small for EJB? Any framework when used properly is going to save you a lot of time. At what point do you say to yourself, are EJB's overkill. If your application is simple, like the example that Thomas mentioned, it is overkill. If you need to build something quickly, you could probably build it faster without EJB's. It also depends on your existing skillset.
If you don't need all the features of EJB's like distributed transactions, container managed persistance, etc, then don't bother. There are a lot of good java apps out there that don't rely on EJBs.
If you're not going to use it because of the cost, then I don't think that's a very good reason. With open source servers like JBoss and Orion, not to mention OpenEJB (whenever it releases something), EJB's should be in everyone's sites.
Debugging ejb code is simple when using a build tool like ant. I use ant, junit and a framework called WebWork. Putting applications together quickly are simple once you get to know the tools. I haven't used it yet, but XDoclet, does a lot of the mundane EJB stuff for you. Supposedly, XDoclet will build your EJB's and WebWork action classes for you when used properly.
Again, where do you draw the line? That is the question. EJB's aren't complex, unless you make them so.
/rick
 
Kirt Henrie
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rick, I agree with what your saying.
For me, I really do find it easier to look up an entity bean and modify it than to use jdbc. With my entity builder tool I was able to build and deploy 36 BMP entity beans within 4 hours (xml dd's, interfaces, and bean classes). These entity beans are reused in several applications and therefore reduce the amount of required code. Also because the inserts and updates are handled in one place its easier to maintain.
Having said that, the key words are -- for me --.
Coding EJB's by hand and the overall learning curve of EJB's make them less desirable for some people.
Again, for me, the line is drawn at:
Whenever I use the database for inserts and updates.
KJ
 
Ravi Veera
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's an articlehttp://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html? that addresses some of the issues here. Apart from mauling Hamlet the article makes a lot of good points.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!