Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
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.
Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Don't get me started about those stupid light bulbs. |