What a fun discussion. There are obviously alot of strong opinions out
there, and here's one more. :)
I come from a DCE/Encina background and have been playing with EJB 1.1
(Orion) for about 2 months now. For those of you not familiar with Encina,
it is a highly distributable RPC environment with very strong security,
transaction support, etc.
My take on EJB is as follows. The biggest benefit I see from EJB is
distribution, transaction management, and security. I still think EJB still
has a long way to go, but it's getting there. 2.0 seems to be another strong
step in the right direction. As far as ease of development, pure enterprise
beans are straight forward. Where I run into complexity is when I start
getting a complex object model (lots of one-to-one and one-to-many
relationships.) Even on this list, it has been strongly recommended that you
don't talk to entity beans directly, but instead, talk via a session bean.
This is almost necessary if you want any kind of decent transactional
control (unless you mess with user transactions). Where I think this gets
nasty is taking you details objects (somtimes called value objects, see
details pattern at www.theserverside.com) and syncing them with your entity
beans. With one-to-many's this is not a trivial task. As far as the OR
mapping features of EJB (even 2.0) they are still weak. There are more
sophisticated solutions for OR mapping (Toplink for Java, Cocobase, etc.).
Unfortunately, the EJB spec doesn't provide a way for vendors of these tools
to write plugins for expanding the functionality of EJB. (Although there is
a Weblogic specific version of Toplink that allows for very sophisticated OR
mappings)
Also, EJBs and servlets are not mutually exclusive. While you don't always
need both, as Russ White pointed out, if you need to be distributed, EJBs
give you that without worrying about what kind of client you have. For web
access to your app, servlets and JSPs can be clients to your EJB app.
Lastly, as far as performance goes, I believe you are going to take a
performance hit (not necessarily significant) with EJBs versus talking to to
your persistence classes directly. This is because you are always going
through the client stub when you use the EJB remote interface. In DCE and
CORBA, when you call the client stub, it is optimized to do an RPC if the
server is on a different machine, an IPC if it's on the same machine, and a
simple method call if in the same process. EJB doesn't offer that kind of
optimization, therefore, you are always serializing what your are passing to
and from the enterprise bean.
As far as the question that kicked of this discussion. If you do not need
the any of the benefits of EJB then don't use it. However, I would recommend
that you separate your data and business layers from your servlets and JSPs.
Have them be presentation only. That way you could always grow into EJB
without having to rewrite your front end.
Bill
-----Original Message-----
From: Robert Krueger [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 10, 2000 7:04 AM
To: Orion-Interest
Subject: RE: EJB vs Servlets
At 10:54 10.10.00 , you wrote:
>Hi Kevin
>
>You seem to be missing the big picture here. With using a Servlet engine
for
>handling all your logic you are putting all your eggs the same basket. You
>may have partitioned your logic up in the servlet container envirionment
>(MVC) but this is only at class level. EJB gives you distinct partioning at
>the component level. If you model all your Data and business logic at the
>EJB level then you create yourself a reuseable component layer. This way
you
>can connect to this EJB layer from any clients, (Java) Servlets, (Java) jsp
>, (java) desktop client , (java) mobile client, (VB) desktop client,
(CORBA)
>client and many more. At the moment you can only access your model layer
>through the servlet contain (or at least you can't easily access the same
>model from servlets and standalone clients, due to classloading etc)
>
>When you are accessing DB's from servlets you find yourself reinventing the
>wheel , for OR mapping, calling frameworks and data caching algorithims all
>the things that the best (like orion) app servers support
>
>:)
>
generally agree here. the point is that you have to make good modelling
decisions WHAT you package as a component because you do pay a price for
modelling something as an ejb (overhead due to copy-by-value semantics,
maintenance of assembly and deployment information etc. and yes, the
development cycle is slower with all ejb server I've uesd including orion)
which you have to justify by the value you get back (declarative
transactions, flexibility to deploy in different environments, remote
usability by non-web-clients). I don't think it's a good question to ask
whether to generally use servlets or ejb (provided you have a working J2EE
implementation at hand). it's like asking:"what's better? a race car or a
jeep". you have to know the trade-offs to make good modelling decisions
(HOW to use those technologies is the key) and that requires experience
(especially having made bad ones ;-).
however, there are many productive applications out there based on proven
technologies like the apache jserv combination because they are rock
stable, clustering is easy and people have had a few years time to find out
the odds and evens of the particular technologies and I would agree that in
many transactional web applications you would not lose too much if you did
it with servlets, a transaction manager like tirex and some other O/R
mapping layer like castor if you have a good architect. the modelling
decisions (the tough part) you have to make are not that different.
just my 2c,
robert
>-----Original Message-----
>From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]
>Sent: Monday, October 09, 2000 6:22 PM
>To: Orion-Interest
>Subject: EJB vs Servlets
>
>
>Hey all,
>
>I know this is a little off-topic, but seeing as how Orion is about the
only
>fully compliant EJB server, I figured this would be a better place to ask.
>
>Lately I have talked to a number of people that have been moving towards
EJB
>and pulled back because they have found it to be more tedious to develop,
as
>well as the end result was slower than just using Servlets.
>
>I ask this because it appears to me that the servlet engine (at least with
>2.2) being able to be failed over, load-balanced, etc, seems to be quite as
>capable for scalability and fault-tolerance as the ejb engine used to be. I
>do realize that the EJB container offers transaction management, but
>connection pooling is available in the servlet engine at the server level
as
>well. So, if you lose speed in development time and performance, what is
the
>real benefits of moving to EJB? I should say this with caution..I am sure
>the EJB engine/container offers some things the servlet container doesn't,
>but I would think its possible to actually put those abilities in the
>servlet container.
>
>Anyways..I'll be interested in hearing any feedback on this.
>
>Thanks.
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
