Ahi:
This is an interesting test case and it certainly appears to advocate beans over
servlets, but your conclusions assume (or seem to) that the performance and
concurrency bench marks in Weblogic are indicative of the performance obtainable
from all implementations. While I have not performed bench marks on Servlet
engines I think its obvious that, on an architecture level, that Servlets
provide better performance for read-only data-to-presentation scenarios. With
servlets you avoid the overhead of transaction and security control and remote
method invocation that you get with EJB. EJB is critical and absolutely
necessary when you need to support a large user population accessing/mutating
transactional data with access control requirements, but for your situation, I
would suggest investigating more performant Servlet engines.
There may come a day when most EJB servers will out perform the best Servlet
engines this type of scenario, but that seems unlikely since A) Servlets are a
comparatively simply architecture that allows more room for performance gains;
B) most EJB vendors will gravitate to J2EE so any gains in a vendors' EJB
performance should translate into gains for their Servlet performance. As an
architecture, Servlets will always be superior to EJB in the read-only
data-to-presentation scenarios where transactions and fine grained access
control are not necessary. As an architecture, EJB will always be superior to
Servlets in modeling the business logic and providing performant transactional
environment for large user populations.
Note: These lines will blur slightly as the Servlet architecture incorporates
transaction and security access control, but that control will not be as fine
grained as EJB and access will not be through Java RMI (RPC), which is necessary
in many circumstances.
- Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
http://www.EjbNow.com
Ahi Satapathy wrote:
> It maybe a good idea to implement non-transactional read-only stuff
> something other than EJB but in some cases it may not be applicable. Let me
> postmortem something I am working with.
>
> I have 100 Test Library and each TestLib has 20 Test and each Test has 200
> Question and each Question has 5 set of Answers. I need to deliver a Test
> when a TestTaker login to take a Test, here we don't need any transaction
> and we don't write anything to database , everything is read only. so do you
> think, we should implement this using servlet/jsp with the help of few
> dependent classes ??
>
> On the other side we have a TestLibBean, TestBean and QuestionBean and we
> associate them in TestDeliverySessionBean, which will give us the ability to
> reuse plenty of stuff. one particular Question entity can be part of many
> Test, a Test can be a part of many Lib and it is possible that many
> TestTaker might be taking the same Test at a given time. Test and TestLib
> Entity are also reused by other modules.
>
> we were able to go as much as 120 concurrent user with clean servlet for
> delivering Test with weblogic ( no clustering ) , now we are able go more
> than 300 concurrent user after we moved to EJB. FYI we have a target of 1000
> concurrent user. and we are thinking of clustering and replicating.
>
> > From: A mailing list for Enterprise JavaBeans development
> > Sent: Thursday, February 24, 2000 1:57 PM
> >
> > I hate to speak for Richard, but I think his point is that for read-only
> > queries that are basically transaction-free that EJB is perhaps more
> > overhead than is needed. I am working on exactly such a system
> > where we are
> > considering using Servlets for queries that are for read-only purposes and
> > EJB for updates. If the query is for reading / writing, then the
> > "overhead"
> > that EJB comes with is not an issue because of all of the other benefits
> > that come with EJB.
> >
> > DB
>
> > From: Frank D. Greco [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, February 24, 2000 9:26 AM
> >
> >
> > >Ahi Satapathy wrote:
> > >> So when EJB should be used ? what should be the factor one should
> > consider
> > >> before going to implement something with EJB ? If the site is not
> > >> transactional, has no authorization security needs, and is read only,
> > should
> > >> one go for simple Java Objects and use Servlets with direct
> > JDC access
> > ??
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
