My last point was a joke. Hence the ";-)" emoteicon. Obviously making a
design decision based on the marketability of a skill is a bad idea.
Unfortunately, people sometimes do this, as you have doubtless experienced
given your comment.
As far as the thread issue goes, the spec says that an EJB should not ever
create threads or use the threading API. The container, however, can and
should create multiple threads to handle EJB requests. EJBs would not scale
worth a darn if they always handled one request at a time. The container is
responsible for making sure that EJBs are threadsafe. In order to do this
the container will surely limit connections in some, but not all cases.
-----Original Message-----
From: Haseltine, Celeste [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 12:12 PM
To: JRun-Talk
Subject: RE: beans vs ejb's (was "RE: Ist it possible to seperate EJB
and Servlet Server?")
Mark,
Be careful with your last point. When interviewing candidates, I always ask
why/how the design on their last project came about. You raised many
technical pro/cons regarding EJB's, but if I get the impression that someone
came up with a more "complicated" design than the project required just to
enhance their resume, at the expense of the long term costs for the company
to maintain and enhance the product, I would think twice about hiring them.
On the other hand, if they choose that technology because if was one of the
top "best" three choices of the technology that could be used for that
product on their list, then the consideration of "enhancing their resume" is
OK by me. It should NOT be the primary factor in the design decision
though.
Also, to my knowledge, EJB's are a single threaded model, i.e.. they do not
support multi-threading. Or did I miss something in my reading of EJB's?
Celeste
-----Original Message-----
From: Mark Phelps [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 12:48 PM
To: JRun-Talk
Subject: RE: beans vs ejb's (was "RE: Ist it possible to seperate EJB
and Servlet Server?")
Oh, one other point. Using EJBs is better for your resume. ;-)
-----Original Message-----
From: Mark Phelps [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 11:39 AM
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.
-----Original Message-----
From: Charles Arehart [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 10:28 AM
To: JRun-Talk
Subject: beans vs ejb's (was "RE: Ist it possible to seperate EJB and
Servlet Server?")
Oo, looks like the makings of a good debate. :-) OK, maybe it's been done
before, but for the benefit of the current audience (yours truly included),
can we hear the arguments again?
Scott just wrote: "One question is why are you separating the EJB and
Servlet engine on the same machine? For testing purposes? The
communication between Servlet and EJB will be much faster if they are in the
same JVM, so I am just wondering why separate them out?"
Yes Celeste asked Friday "why you are using an EJB design on the same
physical server? I had always understood that the purpose of using an EJB
design is to communicate across different physical server/system boundaries
and/or platforms. Otherwise, the overhead and performance "hit" of using an
EJB design would not be justifiable."
Ah, two sides of the same coin, and an issue about which I'm sure many often
wonder as they get started. Can we open the floor?
I've felt, too, that the discussion of EJB's seemed to make more sense when
the client talking to the EJB was on a different machine (either
client-to-server, or jsp/servlet-to-EJB container on another machine).
Like Celeste, I've wondered if those advantages were as apparent in the
latter case (JSP/servlet-to-EJB container) when those are on the same
machine (indeed, when they're in the same container--JRun-as they are for
many of us).
Indeed, it hit me one day that much of the initial excitement about EJB's
may have come from writers whose perspective was that of client developers:
those building applets that were talking to enterprise databases. Sure, for
them, the benefit of talking to an EJB instead made imminently more sense
over putting a bunch of DB code in the client.
But when all code is on the server side, is there still clear benefit?
I suppose one could make an argument that putting "all that DB code" in a
JSP/servlet is just as bad, but then others will counter that they solve
that problem with regular beans. One rarely hears this approach debated over
EJBs. Of course, it's often clarified in EJB books that "EJB's ARE NOT THE
SAME as regular JavaBeans", but again I think when they say that they're
talking to client developers for whom beans are different in concept
(indeed, many trying to learn about beans themselves are thrown off by books
that discuss beans only in the context of "gui development" tools.) They
rarely go on to say when beans on the server may make sense over ejbs.
Indeed, when one looks even more closely at EJB's, one is left wondering
what the difference would be between a bean-managed (BMP) entity bean (where
the developer is responsible for all the db/transaction coding) and a
regular javabean (where, again, the developer is responsible for all the
db/transaction coding). Is it just a matter of roles (who's doing the
work), then?
Of course, if one is leveraging container-managed persistence (CMP) in an
entity bean, then indeed it's less work than a developer creating a javabean
of their own to do that work.
But if they eschew CMP for BMP, then is there still a benefit of a BMP
entity bean over a javabean doing equivalent work?
/charlie
-----Original Message-----
From: Scott Stirling [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 9:58 AM
To: JRun-Talk
Subject: RE: Ist it possible to seperate EJB and Servlet Server?
Vijay mentions some good things to check. It might also help to set the
classServer host in local.properties to the real IP of the machine, rather
than 127.0.0.1. You set this on the EJB server, not the Servlet server.
The Servlet engine server should have the EJB and JMS services disabled, and
your Servlets must have the ejipt_client.jar or ejipt.jar in their classpath
so they can load Ejipt's JNDI Context factory. Also make sure you are not
overriding settings in local.properties by setting them again in
deploy.properties.
One question is why are you separating the EJB and Servlet engine on the
same machine? For testing purposes? The communication between Servlet and
EJB will be much faster if they are in the same JVM, so I am just wondering
why separate them out?
Scott Stirling
JRun QA
Macromedia
> -----Original Message-----
> From: Vijay Menon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 03, 2001 3:08 AM
> To: JRun-Talk
> Subject: Re: Ist it possible to seperate EJB and Servlet Server?
>
>
> When u set up servers in JRun, each server is completely
> independent. It
> looks like the servlet is trying to locate the ejbs by
> looking on the same
> port as itself. Check which port the servlet is using to
> connect to the ejb
> server because that would be the most likely reason
>
> Also, if the site is protected by a firewall, check that the
> port is open
> for the second server but of course, in that case, a naming
> exception will
> not be thrown.
>
> Vijay
>
> ----- Original Message -----
> From: "Alexander Sommer" <[EMAIL PROTECTED]>
> To: "JRun-Talk" <[EMAIL PROTECTED]>
> Sent: Friday, August 03, 2001 4:39 PM
> Subject: AW: Ist it possible to seperate EJB and Servlet Server?
>
>
> > Yes, I have two server in the server directory of jrun. One is
> > configured as servlet/jsp server with no ejb-service enabled in
> > the local.properties. The other one is the ejb server with no
> > web-app enabled, so it hosts only the ejb's. The are deployed
> > on that server and all loaded (the event-log) says that.
> > But when I call an servlet on the servlet server, I get an
> > naming exception. I think thats because the two server do not
> > have the same jndi-context! But the question is how to go around
> > that?
> >
> > Alex
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Vijay Menon [mailto:[EMAIL PROTECTED]]
> > Gesendet: Freitag, 03. August 2001 08:26
> > An: JRun-Talk
> > Betreff: Re: Ist it possible to seperate EJB and Servlet Server?
> >
> >
> > If I get it right, u r trying to set up 1 server jvm
> process listening on
> > port A trying to talk to another server process on a
> different port B?
> What
> > error is it throwing? is it a javax.naming exception or
> what? Maybe the
> 2nd
> > server is not actually hosting the ejbs, so to speak?
> >
> > ----- Original Message -----
> > From: "Alexander Sommer" <[EMAIL PROTECTED]>
> > To: "JRun-Talk" <[EMAIL PROTECTED]>
> > Sent: Friday, August 03, 2001 4:04 PM
> > Subject: AW: Ist it possible to seperate EJB and Servlet Server?
> >
> >
> > > Yes, I want to have the two servers on the same machine! So as I
> > understand,
> > > I don't need to change anything, because I turned off at
> one machine the
> > > EJB-Engine so the call to 127.0.0.1:2323 goes to the
> second VM. But
> > > it doesn't work for me!
> > >
> > > Alex
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Mark Phelps [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Donnerstag, 02. August 2001 19:25
> > > An: JRun-Talk
> > > Betreff: RE: Ist it possible to seperate EJB and Servlet Server?
> > >
> > >
> > > Are you talking about having the two servers separate but
> on the same
> > > machine or do you mean two JRun servers running on
> different machines.
> > >
> > > It should be simple to have JRun on one machine running
> the JSPs while a
> > > second machine hosts the EJBs. You would just have to
> make sure that
> the
> > > code that looks up the EJBs uses the right URL.
> > >
> > > -----Original Message-----
> > > From: Alexander Sommer [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 02, 2001 9:42 AM
> > > To: JRun-Talk
> > > Subject: Ist it possible to seperate EJB and Servlet Server?
> > >
> > >
> > > Hi,
> > >
> > > Is it possible to seperate the ejb and servlet server?
> > > I want to create two server instances, one for servlets and
> > > jsp and one for the ejb's. At the moment all works if i use
> > > one server, but if I seperate the ejb's, the EJB-server doesn't
> > > find the ejb's!
> > >
> > > thanks,
> > >
> > > Alex
> > >
> > > Dipl. Ing. Alexander Sommer
> > > Software Development Manager
> > >
> > > TIScover - Travel Information Systems
> > > http://www.TIScover.com - the travel network
> > >
> > > Softwarepark Hagenberg, Hauptstr. 99
> > > A-4232 Hagenberg/Austria
> > > +43(7236)3343-777 (phone)
> > > +43(7236)3343-782 (fax)
> > > e-mail: [EMAIL PROTECTED]
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/jrun-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
