Servlet vs EJB concept question

The chief architect where I work is using Weblogic solely for serving servlets (and jsps). They've written a large jsp tag library for database connections/queries/pooling as well as utilities for mail, etc., etc. At the moment the system is suffereing quite severe performanace problems. We're using Oracle as the database backend and from the looks have several quite competant dba's looking after the database.

I raised the question as to why all the work was being done by servlets when we should be using servlets solely for request handling, jsps simply for display logic and all the real work done by Session beans (Model 2 framework?). His reply (there were some language barriers) was something along the lines of "so much database logic and data", etc which sounded like he basically meant it was too much work. There are around 200 database tables in use.

I've always thought that the idea of the middle tier was to encapsulate all the business logic seperatly from the presentation while also providing significant scalability and performance benefits. But taking a second look at this it also makes sense that coding the queries and logic straight into jsps (esp. with tag libraries) makes it a lot less work for the same results. And in business, less effort = less money + quicker results which is definitely the driver in this organisation.

My question is basically what are the arguments for spending the extra development effort coding session beans to handle all the business logic as well as 200-odd classes to represent the entities, etc. when the same output can be produced by coding jsps just as you would with asp, cold fusion, php, etc.

I'm really looking for a decisive argument where the benefits are tangible and hard to ignore. More comments the better though...


Who is Participating?

Improve company productivity with a Business Account.Sign Up

cooderConnect With a Mentor Commented:
Design Idea:
I have seen this problem before and you ask a very good question.  Let me give the ideal world situation first.  It would be nice if you have JSP pages handling presentation, regular JavaBeans handling the majority of your EJB calls, have session beans that implement your process and use entity beans for your data access. JSP->JavaBean->Session Bean->Entity Bean.  Now to be frank this can be a royal pain so what we did was just use entity beans where we had big time transaction, concurrency, security, etc.. issues and had JavaBeans use the EJBs with JSP pages using the JavaBeans.  Most of our developers were abstracted from a lot of code and just needed to know the api for all the JavaBeans we wrote that call the EJBs.

Your Question:
Hopefully this will answer your question about why EJB and possibly allow you to be able to make good use of EJBs  and be able to know when they are right and wrong. Frankly some of the people I see using EJB are totally missing the point and just using it because it is a hot technology.  

You use Entity Beans when you are doing inserts/updates/deletes for CERTAIN tables in a database.  The reason is because Entity Beans allow you to do
1) Distributed Computing
2) Have major Transaction support
3) Have major Concurrency Control
4) Handles networking
5) Handles security
Think of it like all of these issues are taken care of for you and all you have to do is put in the business logic.

You use Session Beans when you want to code a reusable component that contains a process.  Now I know what you are thinking and the reason this can be good is because of things like platform independence and the main reason is distributed computing.  Ford Motor can deploy a session bean with a certain process all the way over in Michigan and we can use that object on a machine in california and not even know it is depolyed in Michigan.  Now the Session bean takes care of all kinds of things like networking that the Ford engineers never need to worry about because the bean does it for them.   This is only the tip of the iceberg when talking about EJBs but hopefully it will give you some direction.
>>coding the queries and logic straight into jsps (esp.
>>with tag libraries) makes it a lot less work for
>>the same results.

In the short term, this is true. Its quick (and dirty) and it works. In the long term its messy and harder to maintain. The logic should be display independent and the display should be logic independent. Similarly the data and logic should be independent for the same reasons. It's all part of the MVC (Model View Controller) approach.

It means that your business logic has stuff built into it that is specific to the display of the data it retrieves as web pages. If you wanted to use the same logic for B2B, WAP/WML, XML etc it would be a bigger job. If the logic is entirely display independent (i.e the view and controller do not overlap) you can add a new view without having to think about the controller, chnage a view without having to think about the controller and change a controller without having to think about the view.

It is extra work and the benefits are not always immediately apparent.
deal051298Author Commented:
Cool. That's my opinion but it's always hard to pitch for the "we'll benefit in the long term" approach with an organisation that's scrambling to get things done in the short term. What about performance benefits? What sort of performance comparison would I get between 10,000 simultaneous users hitting:

1. A reasonably complicated servlet that ran various db queries, did some business logic and displayed the results


2. A simple servlet that created a Session Bean that did the logic returned the results to the servlet which then forwarded the results to a jsp for display
It depends on the implementation  and deplyment of the bean.

Once the jsp page has been called there is no difference between jsp and a servlet. The first time a jsp page is called it is compiled into a servlet and run exactly like a servlet for the duration of the server's session. It will only be recompiled if the server detects that the source page is newer than the compiled class.

I don't think it makes much differece whether jsp invokes the bean or a servlet invokes the bean.

If the bean had to be instantiated every time the servlet or page was hit then 2 would be slower than 1. I can't remember how a session bean behaves when it is called by a servlet, in terms of its lifecycle.

A servlet that maintained a pool of beans to cope with multiple requests would probably run  better than a servlet where all the logic was internal.
deal051298Author Commented:
Thanks, ozymandias. I agree with your statements but am looking for more information before I close off this question. You've pretty much told me what I knew already.

>A servlet that maintained a pool of beans to cope with
>multiple requests would probably run better
>than a servlet where all the logic was internal

This is the kind of thing where I'd like specific answers as to why and what the preformance differences are.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.