----- Original Message -----
From: "Jim Preston" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 16, 2000 3:21 PM
Subject: Re: EJB and JavaBeans
> I don't want to start an argument,
Neither do I! ;-)
> but I don't see how you can call ordinary
> beans a client-side technology. When a JSP uses a bean for data access or
> storage, that's all strictly server-side. You may be storing
client-related
> data in the bean, but the bean exists and is used only on the server. I'd
> call that a server-side usage myself.
So would I. I don't see where we disagree. "Client" and "Server" are
relative terms. With an ordinary bean accessing a database server through
JDBC, the bean is in fact a client in that role relative to the database.
That doesn't mean the bean isn't wrapped in some other technology that
allows it to turn around and act as a server for some other client. The
notions of "server-side" and "client-side" are becoming more vague all the
time.
> And the examples you give of the
> purposes of EJBs can all be done with ordinary beans, if your server side
is
> not distributed. Indeed, even if your database is on a different machine
> than your web server, there's no reason that you can't use ordinary beans
> with JDBC to allow your JSP/servlet to talk to the database.
No reason at all. In fact, I'll say that there is NOTHING that EJBs do that
regular beans can't. But one nice thing that EJBs provide in this example is
if you write a JavaBean to do this, you have handle all the threading,
transaction, and security mechanisms somehow. EJB servers by definition must
provide these things for you. you do have to configure exactly what the
behavior of those mechanisms are, but this is far simpler than writing all
that yourself. But for a simple appication where these things are not high
priority, I wouldn't mess with EJBs, either.
I was primarily pointing out that they are not directly interchangable as
someone suggested. I emphasized the GUI purposes of regular beans mainly to
show an area filled by regular beans that CANNOT be filled by EJBs. Reread
what I wrote. I said EJB is STRICTLY server side. I also said that regular
beans are MOSTLY client side, not ONLY or STRICTLY client side. Regular
beans have nothing in their defining spec to provide for them to be server
side, though. They rely on the developer to provide added machinery for them
to act in a server role (e.g embed them in a JSP or servlet). EJB defines
all that machinery. The spec for regular beans, on the other hand, is rather
client-side and even GUI heavy, if not for the beans themselves, then for
all the supporting pieces that MAY be used in conjunction with them. (My gut
feeling is that when JavaBeans were first spec'ed, they really weren't
considered as server-side entities. It seems that usage has just sort of
"happened" and I think that's a "good thing".)
Frankly, I think they complement each other very nicely. If you are thinking
ahead in a project that is starting small, you could define an interface for
a bean that initially you use to talk to a JDBC server. As the system needs
to scale, you might replace the backend with EJBs and swap in new JavaBeans
with the same interfaces that talk to the EJBs rather than the JDBC server.
So the JavaBeans layer provides a nice abstraction for the backend.
The message I was replying to was suggesting that due to their greater
rosustness, we might just drop JavaBeans altogether in favor of EJBs. So I
was defending JavaBeans by pointing out purposes they serve that EJBs
cannot, not attacking them.
> I don't see that it's the purpose that distinguishes EJBs from ordinary
> beans, it's the environment in which they're used.
Hmmm. OK, I can agree with that, though I don't think it changes the goal of
my explanation.
> JavaBeans are a component
> model. EJBs are a distributed component model. The basic purpose of both
is
> to encapsulate business logic, to keep it separate from presentation. If
> you're working in a simple environment, with one web server and a database
> server (and your database interactions are simple queries and updates),
you
> have no real need for EJBs; ordinary beans can do the job just fine. You
can
> have ordinary beans that encapsulate business entities and business
> processes. If your environment is distributed, with servers all over the
> place (or you do big database transactions), then EJBs are needed.
Yep, again I agree.
> GUI widgets are just one use of JavaBeans, certainly not the only use.
Which is why I emphasized it. EJBs cannot replace JavaBeans in GUIs, so the
idea that was that EJBs would completely replace JavaBeans can't happen.
However, it's a bit harder to argue that point if you keep strictly to
server side, though not impossible. There are restrictions on EJBs that
might be too prohibitive in some situations - EJBs can't spawn new threads
and can't perform I/O directly, for example.
So I think we can agree to agree, and move on. :-)
Eddie
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
