• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is SessionBean really required ?

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi guys,
I know this seems to be a vague question, I really want to find out the scenarios where session bean is really required ?
I have an e-commerce application wherein we are required to provide interfaces for customers, retailers, and manufactures to transact. This involves searching for products that match a particular criteria, adding new products, updating catalogs, deleting products, shopping , etc.
I'll explain in brief about our architechture.
We have used JSPs for the View which take in the search criteria. Servlets as the controller which takes in the request parameters, constructs a serializable object (Value Object) from these parameters and passes it to the stateless session bean. THe session bean get a database connection and fires the SQL on it, gets the result and gives it back to the servlet. THe servlet then forwards to the JSP file which provides the presentation logic to display the search results.
Now the question here is, do I really need a session bean here.
I do not use any container services such as transactions, security, etc.
So i decided to write a simple java class and do the same thing that my session bean does.
If instance pooling is a consideration, I can increase the size of the servlet pool in weblogic.
What are the trade offs in both my approaches ?
1. Using stateless session beans.
2. Using simple java classes in place of session beans.
This alternate approach was used for searches, which have a simple SELECT statement.
I decided to get rid of session beans for my update and inserts (creation) as well.
Is it a feasible solution in my kind of application that allows dirty reads, that does not have a heavy hit count.
Deepak
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Deepak Mahbubani:
hi guys,
I know this seems to be a vague question, I really want to find out the scenarios where session bean is really required ?
I have an e-commerce application wherein we are required to provide interfaces for customers, retailers, and manufactures to transact. This involves searching for products that match a particular criteria, adding new products, updating catalogs, deleting products, shopping , etc.
I'll explain in brief about our architechture.
We have used JSPs for the View which take in the search criteria. Servlets as the controller which takes in the request parameters, constructs a serializable object (Value Object) from these parameters and passes it to the stateless session bean. THe session bean get a database connection and fires the SQL on it, gets the result and gives it back to the servlet. THe servlet then forwards to the JSP file which provides the presentation logic to display the search results.
Now the question here is, do I really need a session bean here.
I do not use any container services such as transactions, security, etc.
So i decided to write a simple java class and do the same thing that my session bean does.
If instance pooling is a consideration, I can increase the size of the servlet pool in weblogic.
What are the trade offs in both my approaches ?
1. Using stateless session beans.
2. Using simple java classes in place of session beans.
This alternate approach was used for searches, which have a simple SELECT statement.
I decided to get rid of session beans for my update and inserts (creation) as well.
Is it a feasible solution in my kind of application that allows dirty reads, that does not have a heavy hit count.
Deepak


Absolutely. If you don't need the 2PC cross-datasource transactions, security or distribution, you don't need EJB's at all.
I've discussed that at length here:
http://www-106.ibm.com/developerworks/library/ibm-ejb/
However, you might want to consider an architecture where you have the option to put Session beans back if you need them later.
See http://www7.software.ibm.com/vad.nsf/Data/Document4359?OpenDocument&p=1&BCT=1&Footer=1
and especially
http://www7b.boulder.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades.html
for more information.

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Deepak Mahbubani
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx a ton . It was really informative
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic