Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JSP-Servlet-EJB architectures

 
Junilu Lacar
Bartender
Posts: 7570
52
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I am working on my first J2EE project. There are other developers on my team who have more experience with J2EE than me but I still have doubts as to the direction that we are taking. I would like to get feedback about some design issues.
Say I wanted to do a search for customers. What are the pros and cons of each of the following designs?
Design 1:
a. control servlet receives request,
b. control servlet instantiates worker bean,
c. control servlet passes request to worker bean,
d. worker bean accesses database, goes through the result set and builds a results vector of CustomerData objects
e. control servlet gets the results vector from the worker bean
f. control servlet puts the results vector in the session context
g. control servlet forwards request to the view JSP
h. JSP retrieves the vector from session and displays it.
Design 2:
a. control servlet receives request,
b. control servlet instantiates Session EJB,
c. control servlet passes request to Session EJB,
d. Session EJB accesses database, goes through the result set and builds a vector of CustomerData objects
e. control servlet gets the results vector from the session EJB
f. control servlet puts the results vector in the session context
g. control servlet forwards request to the view JSP
h. JSP retrieves the vector from session and displays it.
What are the benefits of using a session bean to do business logic processing as opposed to having it in a plain old worker class? Would using a session bean make the application more scaleable? If I don't have to worry about scalability for now, is the added complexity of a Session EJB worth losing the relative simplicity of having just a worker class?
All feedback will be greatly appreciated.
 
Manjunath Reddy
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first design is good for an EJB system that doesnt implement clustering. When u want to port the code into a scalable clustering system, it will be a pain to take care that all related worker objects are serializable and also cluster-aware.
The second design is kind of de-facto standard most ppl follow.
cheers,
mpr
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personal experience speaking here:

The EJB is *not* worth the added complexity and overhead, if you are relatively certain that you will not at some point in the future require a distributed application.

EJB's are nice in some ways, because your DB Transactions and concurrency issues tend to fade. But if you are merely doing reads on data, we have found that the EJB is a bit overwhelming.

It slows down the entire request/response time. We actually had trouble 'porting' our EJB/Servlet/JSP app from the RI to iPlanet, so I spent two days ripping out all the EJB's, replacing them with 'plain' classes. You would not believe the performance gain.

That's my $0.02
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic