Tom, please fw to JSP-INTEREST if you like...
>
>
> Hi all:
> Thank you all very much for your replies!
> I'm currently in the process of deciding "to EJB or not to
> EJB" for my new
> project. My web page uses JSP to generate dynamic web pages
> and it uses
> JavaBean to talk to a backend database server to issue all
> kinds of SQL
> statements such as select/insert/update etc.. I feel this
> kind of design
> (without using any EJB) will serve the purpose. However, the
> potential users
> of the Web page are huge. I'm concerned about the
> "scalability" problem. My
> questions are:
> 1) Will my web application run into trouble if the number of
> users increases
> to a certain point?
Any system has a breaking point. The real question is: how much your
system can handle? You should test this, using Apache's JMeter or
Microsoft Web Stress App tool.
>
> 2) Will I not have the same problem if I use EJB instead?
Yes, but it might not impact as much.
> If
> so, I can use a
> session bean instead of a JavaBean to issue the same set of
> SQL statements.
Yup.
> However, I don't see much of a difference between the two
> approaches. For
> example, after I have instantiated a session bean in the JSP
> web page,
Well, the trick is that if it is a Stateless Session Bean(SLSB), you
never instantiate it. You'll have an object pool and objects will be
reused. The most harming performance issue with Java today is garbage
collection(and it impacts directly on scalability). When a web page
finishes using a SLSB, it returns to the pool and will be reused. If it
were a JavaBean, it would be derreferenced, and would remain in memory
until the gc mechanism kicks in. And when it does, your app freezes for
a while. This hurts your performance. It impacts scalability too
depending on the load and the freeze time.
In an extreme circumstance, this is what would happen:
Current web requests are stalled, and more web requests come in and are
queued. Eventually your machine hangs (much like a DOS attack).
This can happen with both EJBs and JSP, but on heavy concurrent load,
it's more likely an EJB based server can handle more load, even more
when the hardware is more powerful as the cost of using EJBs becomes
marginal.
> I
> call methods defined in the remote interface to issuing all
> kinds of SQL
> queries/updates. The methods I call are exactly the same as
> those defined in
> the JavaBean. The only difference is that one is defined in a
> JavaBean while
> the other is defined in a session bean. So if I make this
> change and I can
> say "I am now using EJB", will that solve my problem of
> "scalability" if I
> have any? As I said above, I am very concerned about my web
> application
> running into trouble when the number of users increases to a
> certain point.
> Will the design without using EJB inherently be vulnerable to
> this trouble?
All designs are inherently vulnerable to this trouble. The idea is that
you cluster machines to accommodate for increased load.
> Will the design using EJB (such as session bean) be immune to
> this trouble
> or at least be easier to deal with this trouble?
I'd think overall EJB makes it easier. How easy? Is it really worth it?
It depends on each project. How many machines will you be placing in the
web cluster? How will you balance load? What's your expected
load(concurrent users)? How many concurrent web requests your machines
can handle? How does concurrency slow down single web request handling
performance? How much?
> Could
> someone please give
> some specific scenarios to help me understand the difference
> between the
> two?
> 3) It is said that "EJB design is N-Tired and N-Tiers allow you to
> redistribute load more efficiently". In my case, how do I
> re-distribute the
> load if needed? I can put the database server on a different
> machine than
> the one running the EJB application server to distribute the
> load, but the
> same thing can be done with the JSP/JavaBean (with EJB)
> design, i.e., I can
> put the database server on a different machine than the one
> running the
> servlet engine such as TomCat.
WM = WebMachine.
EM = EJBMachine.
DM = Database Machine.
Tomcat Cluster:
WM ----+-----DM
WM ----|
WM ----|
WM ----|
WM ----|
WM ----|
WM ----|
This is known as "scaling up".
EJB Cluster:
WM-----+----EM--+
WM-----| |
DM
WM-----| |
WM-----+----EM--+
This is known as "scaling out". Since most of the computing time of the
WM are used in sending dynamic HTML out, one single EM machine can
handle more than one WM, so you use the hardware more efficiently.
Scaling out works where the cost of network traffic is really low, like
a Gigabit Ethernet, but hopefully it'll give you an idea of how you can
scale differently by having tiers.
> I know EJB has lots of
> advantages. But I may
> not need them in this project. The "scalability" problem is
> really what will
> determine whether I should "to EJB or not to EJB". Could
> someone please give
> me some advice? Thanks in advance!
>
> Tom
>
>
> >From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: FW: JSP/JavaBean compared with EJB
> >Date: Tue, 25 Feb 2003 04:59:52 -0000
> >
> >
> >
> >Ok, all inline.
> >
> > > > 1) You would have to use a heavy weight EJB application server
> > > > such
> > > WebLogic
> > > > or WebSphere, which are kind of more difficult to learn and
> > > certainly
> > > > more expensive to buy than using just a light weight
> servlet/JSP
> > > > engine like TomCat.
> >
> >Jboss (http://www.jboss.org) is as expensive as Tomcat. Orion
> >(http://www.orionserver.com) and Resin (http://www.caucho.com) are
> >cheaper than Tomcat(unless the hardware you run them on top of is
> >really inexpensive < 100 U$S, or your app doesn't handle an
> important
> >load). Both of these containers are free for non-commercial
> >applications, I think, and for commercial applications
> there's a fee,
> >but since they're a lot faster(one order of magnitude average in the
> >apps I've tested) than current Tomcat implementations, it's
> cost when
> >compared with the hardware cost is marginal
> >
> >
> > > >
> > > > 2) When you use EJB, you would have to follow the
> strict rules of
> > > > programming, such as defining the interfaces for each EJB.
> > > With just
> > > > using JavaBean, you don't have this problem.
> >
> >There are a lot of free tools that aid you in this process, and you
> >could also roll out your own. Depending on the methodology
> of work you
> >use this will be either a burden or a bless.
> >
> > > >
> > > > 3) Each Entity Bean corresponds to a database table. When
> > > the database
> > > table
> > > > is changed, such as adding/renaming/deleting columns, the
> > > > corresponding
> > > EJB
> > > > file would also have to be changed. Compared with using just a
> > > > JavaBean to do the database work, the changes involved will
> > > be minimal
> > > > - usually, just changing the SQL statements querying the table.
> >
> >Altough most EJB/table mappings are 1..1, this could be
> altered. It's
> >not usual that mappings aren't 1..1. But at least you'll know if the
> >underlying data structure has changed. It also depends on how you're
> >using the table. To accommodate for a new field you have to add 2
> >methods anywhere in the EJB file and touch the constructors
> a little. I
> >don't perceive this to be much more work than tracing SQL statements
> >that need changing (and I presume the code is neatly
> arranged). If you
> >own the tables, some EJB servers will generate as much SQL as they
> >can(Orion does this with inserts, simple finders, even create the
> >tables for you). This helps to develop quickly and eases initial
> >deployment. Changes on the underlying data structure are
> bound to be as
> >harmful regardless of the technology used.
> >
> > > >
> > > > 4) Deploying the EJB is certainly much more complicated
> > > than deploying
> > > > the JSP/JavaBean files in TomCat. With the former, you
> have to go
> > > > through all the steps creating the .jar, .war, .ear files
> > > and define
> > > > the jndi names etc., while with the latter all you need to
> > > do is just
> > > > drop the files into the correct folder.
> >
> >Both apps will need a web.xml file placed correctly.
> >Both will also need .jar files available to the web app.
> >
> >The extra steps are building of EJB jars (which can be reused in
> >different applications, like a backend), and building the
> ear (simple
> >even in complex applications). They're just zip files, so it's not
> >extremely difficult to do, even automate.
> >
> >Use ant to automate the build of .jar, .war and .ear files.
> >
> > > >
> > > > 5) With using the EJB, the .ear file created for one
> application
> > > > server often doesn't work with another application server
> > > (I tried to
> > > > put the
> > > .ear
> > > > file which works for one EJB application server onto another
> > > > application server and it didn't work. Other people had similar
> > > > experiences like
> > > mine).
> > > > I ended up having to re-create the .ear files for the new
> > > application
> > > server
> > > > which cost me quite a bit of time. However, with using just
> > > a servlet
> > > > engine, I would think you can just move the source code to
> > > the correct
> > > > folders if you change the engine and it will work.
> >
> >This is because:
> >A) You made a mistake.
> >B) You didn't make a mistake (and your server vendor did, or
> Sun when
> >writing the spec).
> >
> >On B, I can tell you that basically, this is one of the
> biggest flaws
> >in the EJB spec. The gap, however, narrows on each release,
> and there
> >are tools available to make the whole thing even more pleasant(like
> >XDoclet, EJBDoclet, etc.). This is a problem with Servlet/JSP specs
> >too, and the specs aren't carved in stone either(for
> instance, I recall
> >that Tomcat didn't implement HTTPRequest.getPath() as per the spec;
> >instead of fixing Tomcat "The golden reference", the spec
> was patched
> >to match Tomcat's behavior, and this meant a lot of apps will break
> >when moved from Tomcat to another JSP Engine working with the *same*
> >Servlet/JSP spec).
> >
> >But this is THE major open flank on J2EE today. It's not a perfect
> >world.
> >
> > > >
> > > > 6) I heard people say "EJB provides almost transparent
> > > scalability". What
> > > > does "scalability" mean exactly? Does it mean when
> > > the number of
> > > > users of my application written using only JSP/JavaBean
> > > (without EJB)
> > > > increases to a certain point, my application will run into the
> > > "scalability"
> > > > trouble? If so, what kind of trouble is called
> > > "scalability" exactly?
> >
> >A JSP/JavaBean app isn't inherently n-Tiered(you'd have to do that
> >yourself). That means that under heavy load & complex operation it's
> >likely not to be able to scale as linealy as an n-Tiered app.
> >
> >N-Tiers allow you to redistribute load more efficiently, and
> also help
> >reuse. Again, this may or may not be needed by your app.
> >
> >Before I get flamed over this, yes, I know RMI, and N-Tiers aren't
> >exclusive of EJBs, and you can achieve it with
> JSP/JavaBeans, but you'd
> >have to write a lot of the plumbing yourself. Mounting RMID is a lot
> >worse than deploying an ear. Distributing load must be manually
> >handled. And these implementations are bound to be less efficient
> >except in a very few cases.
> >
> > > >
> > > > 7) Another advantage of EJB I heard was "transaction
> > > management". Why
> > > > do I need that? I can use JSP/JavaBean to issue all
> kinds of SQL
> > > > statements and commit or rollback any transaction as
> > > needed. Why do I
> > > > need EJB's "transaction management"?
> >
> >Think about accessing and modifiying 8 or more tables. You'd have to
> >write all the code serially, commit or rollback the transaction
> >manually. Think about 20 or so similar operations: reuse
> could become
> >more difficult. Then think about continuous improvement: you
> might need
> >to add a simple insert before a lot of these operations, manually.
> >Altough it's completely possible using JavaBeans, EJBs provide a
> >cleaner, more object-oriented approach, since they're fully blown,
> >transactional, secured business objects. When you add teams, and
> >possibly changes in teams and requirements, the benefits are more
> >clear. On top of all this, EJBs guarantee handling some
> "special" cases
> >more effectively (like a server crashing, for instance).
> >
> > > >
> > > > 8) Another advantage of EJB I heard was "security". My
> application
> > > currently
> > > > uses username and passwords to authenticate users. If the
> > > user provide
> > > > the correct username and password, then he/she can
> access the Web
> > > > page. If
> > > not,
> > > > then he/she cannot access the Web page. Is this kind of
> > > authentication
> > > > inferior to the one EJB would provide?
> >
> >Web pages show content. EJBs encapsulate business processes and
> >business data. An EJB(like a JavaBean) may be used by
> something other
> >than a Web page; an EJB(unlike a regular JavaBean) may be located
> >anywhere, and it's security requirements may differ from the ones
> >governing whether a web page must be displayed or not.
> >
> > > >
> > > > Having said above, my questions are:
> > > >
> > > > Is there anything EJB can do but using just JSP/JavaBean
> > > cannot?
> >
> >No, there's nothing you cannot do without EJBs that you can
> do with it.
> >
> >And that's not the point.
> >
> >The point is that there's a lot you will need to do when using just
> >JSP/JavaBeans that you won't need to do when you use EJBs to achieve
> >equal results, under certain scenarios.
> >
> > > What
> > > > are the advantages of using EJB compared with just using just
> > > > JSP/JavaBean?
> >
> >The advantages are many, but the spirit could be expressed
> like this:
> >EJBs allow you to worry less about the plumbing(like object usage,
> >memory, replication, scalability, reliability, SQL execution
> >performance, load balancing, etc.) and focus on the business
> problem at
> >hand. It also gives a common standard to work on top of to all
> >developers, and sort of a common language to communicate with each
> >other. Other choices give more freedom (and perhaps a faster time to
> >market in small projects) at the expense of networking.
> >
> >On ocasions EJBs either don't handle these properly or are overkill.
> >This aren't the majority of the ocasions, in fact it’s a small
> >percentage on very specific situations. You can switch back to
> >JSP/JavaBeans(or any other alternative) to handle special cases.
> >
> > > Why
> > > > are people so enthusiastic about using EJB? So far, I
> feel I can
> > > > do
> > > anything
> > > > without using EJB and I do feel using EJB just complicates the
> > > > work unnecessarily.
> >
> >Maybe. Maybe the sort of work you've done so far is simple
> enough for
> >JSP to handle it properly, therefore making EJBs an
> unnecessary burden.
> >Maybe you're just starting with EJBs and you're not as
> profficient with
> >EJBs as you might be with JSP. Maybe you work alone or within a very
> >small team. Maybe you haven't got to modify a JavaBean a
> programmer who
> >just left the company created. You haven't mentioned Message Queues,
> >Asynchronic Transactions, non-relational or exotic Persitence
> >Subsystems(no JDBC support for instance), etc.
> >
> >I use EJBs in projects where EJBs are needed. I don't build
> a Ferrari
> >when asked for a bycicle. And when the strictness of EJBs harms my
> >ability to deliver, I switch back to technologies that
> provide greater
> >freedom(proefficiency with EJBs isn't a concern to me anymore). EJB
> >eases, more often than not, the amount of work of my team has to do,
> >both now and in the future.
> >
> >My 2c,
> >
> >JP
> >
> >PS: Could somebody FW this to JSP-INTEREST?
>
>
> _________________________________________________________________
> Tired of spam? Get advanced junk mail protection with MSN 8.
> http://join.msn.com/?page=features/junkmail
>
>
==========================================================================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".
