Thanks, Mark, for that elaboration.
I'd just like to clarify something for folks still new to this. You wrote in
point 1: "If the client is on a different machine than the back-end logic
then EJBs are the obvious choice because ..."
We should clarify (or correct me if I misunderstand you) that you mean if
the client "calling the EJB" is on a different machine that the EJB
container. This must be clarified because in a typical JSP/servlet
environment, the statement is true that "the client is on a different
machine than the back-end logic", but that shouldn't lead to the conclusion
that EJBs are the obvious choice.
Same goes for the statement in point 3 "EJBs are better if you may need to
use non-Java clients". In both cases, you're referring to the client as "he
who's calling the EJB".
Many of us will know what you mean, but those getting started will tend to
think of the "client" as the web browser user. In the JSP/servlet scenario,
the jsp/servlet is the EJB client, calling upon the EJB for the benefit of
the web browser client.
It may sound like I'm being pedantic, but it's exactly these sort of
statements that can be misinterpreted which are the root of much
misunderstanding, I think (I'm glad you agree that the books can be
misleading).
I certainly don't mean to embarrass you by pointing this out. Just trying to
help folks who are still trying to get their arms around it all.
The rest of your points are much appreciated.
Indeed, this is another one of those topics that can be all the more easily
misinterpreted by web programmers who don't come from a java background. In
non-web programs in java, when one refers to a client it generally means the
class/program that's calling upon another library/class written by another
programmer. In this case, your class/program is a client to the other
library/class. It doesn't mean the person running the program.
Oh, it can be a tangled web (pardon the mixed metaphors). :-)
/charlie
-----Original Message-----
From: Mark Phelps [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 1:39 PM
To: JRun-Talk
Subject: RE: beans vs ejb's (was "RE: Ist it possible to seperate EJB
and Servlet Server?")
I have done projects using regular beans and EJBs. I definately believe
that there are times when both are appropriate. Here are my thoughts on the
differences.
1. If the client is on a different machine than the back-end logic then
EJBs are the obvious choice because they make the communication between
client and server much easier than it would be if you had to write the
communication code yourself. Applications that need to scale to a high
degree should go this route so that the time spent rendering the user
interface and the time spent doing back-end processing can be separated onto
multiple CPUs.
2. If your application is going to run on one machine now but may need to
be split up later, then it may still be advantageous to use EJBs so that you
are prepared. It isn't impossible to turn regular beans into EJBs later on
but it is better to do it up front if you ever do it.
3. The EJB container provides services such as transaction handling, thread
safety, container managed persistence, etc. that you will have to code
yourself if you don't use EJBs. This may or may not be a big deal.
Sometimes you can be more efficient if you control these services yourself.
4. EJBs are sometimes slower than regular java beans because of the
communication overhead, but not always. Sometimes the container can
optimize the communication when the EJB is local. Version 2.0 of the EJB
spec includes a concept called local interfaces which are used when an EJB
is known to be local. A local interface bypasses the remote communication
overhead. This if future stuff, of course.
If you know that you will never need the remote, or transaction capabilities
of EJBs then I would say that performance would probably be on the side of
regular java beans.
5. EJBs are definately more complex to code and deploy than regular Java
beans.
6. EJBs are better if you may need to use non-Java clients. If the app
server supports it, EJBs can be accessed via CORBA clients which can be
written in many languages.
7. There are some limitations that EJBs are subject to. For example, the
spec says that they should not use the file system because it is not
transactional. See the spec for more details. These limitations may affect
your decsion.
I hope these tips are helpful. I agree that many Java books are misleading
when they say that Java Beans and EJBs are totally different. They can
often be used for the same thing. There is no single answer about which one
is right. Using Java Beans can be bad if you need to scale the app later
but using EJBs can be an unnecessary waste of time if you never need the app
to be bigger than a single box can handle.
One comment: I attended JavaOne recently. There was a significant
anti-entity bean backlash at that conference. Many people said that entity
beans were overloading there server because they commited data to the
database too often. There was even an engineer from Sun's IS team that said
she hated entity beans. Many people were saying that you should use session
beans as your logic interface but use regular beans or Java Data Objects for
modifying the database. The addition of local interfaces is Sun's attempt
to answer these criticisms but I still think there is evidence that entity
beans aren't always worth the effort.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
