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
