• 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

few doubts in MVC design pattern and EJB Concepts

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Java experts...
I have few doubts in EJB, wolud like to share it with you people... Few of my doubts are from MVC Design pattern and other doubts are from EJB concepts. First MVC doubts...
(1) In a MVC design pattern, normally JSPs are used for rendering the EIS data to the client, and hence they are part of View tier in MVC.My doubt is Can i use a servlet instead of JSP?? Will that violate the MVC concepts??
(2) I have seen one J2EE architecture of a project which was based on MVC design pattern. The architecture was as follows...
Client loads the JSP page( which is view in MVC) , jsp calls one normal java bean(which is model i guess, correct r not???) n then java bean calls one session bean(acting as a controller n session facade i guess, plz clarify this one too), which then further calls an entity bean( acting as Model in MVC), and this entity bean interacts with DB.
So communication from client to BD happens as follows
<b>JSP--->>>Java Bean--->>Session Bean---->>> Entity Bean---->>DB(Oracle8i)</b>
First question abt this .. (a)Is this architecture really based on
MVC?? why i m asking is because, i found
servlet missing here n sessions beans are
used in place of servlets as controller.
(b)what is the reason for using session
bean in between Java Bean and Entity
bean?? Can't i use Java Bean inplace of
Session bean?? Coz what i guess is Session
beans are little heavy as compared to
normal java bean. Ultimately a session
bean will be having a method which will be
calling a bunch of entity bean's method,
and i guess the same thing can be achieved
using java bean also.Plz explain this..
(c) If session beans are used as session
facade which are excellent way to minimise
the network level calls, then where is the
network call happening??? Since java bean
is communicating with Session bean, n both
of them are on the same application
server. Java bean is in web container part
of application serevr and session being in
ejb container. so i don't find any network
level calls happening over here. So why
session facade here??
(d) One good reason i find in using
session bean over here is...maintainance
of transaction. If normal java bneans are
used in place of sesssion beans, then we
need to use JTA to handle transaction, but
since we are using session bean, so we can
have container managed transactions here,
so more transaction has to be maintained
by the programms himself, rather he will
be using containers capability to use
transaction, which would not had been
possible if v were using normal java bean.
Is this correct???
Few doubts from EJB Concepts---
(3) In case of stateful session bean, when container passivates then bean, then where does the container saves the client specific data?? PLz tell me in context of weblogic serevr.Few ppl say that, weblogic server maintains the cache, n it stores there, but other say like, it stores in a file which will beon local hard disk, n it uses java's seriliazation mechanism to do this?? which 1 is correct???
(4) How does the container recognises the previous client in caseof stateful session bean?? Let me explain this point in little detial.
Lets say a client C1 is calling one stateful session bean, n that client times out, so container will passivate that bean in order to conserve the resources. So during passivation it will store client specific data to somehere(may be in cache or in a flat file (3rd doubt)). Now lets say the same client C1 again comes so container will activate that bean. and during activation container will actually read the client specific data (from the place where it earlier stored those data may be cache or flat file), and then it will populate the instance variable with client related information. Am i correct upto this point??? If not then plz clarify.So my doubt here is .. how does the server/conrtainer recognizes the previous client C1, i mean if it would had been a different client lets say C2, in that case, the container would had picked brand new bean instace, to service the client, but doesn't do this if the client is C1. I hope i have explained my problem/doubt properly.
Thats it...I hope good answers to these doubts will really be healpful to others as well
Hoping to get the answers soon..
Thanx in advance.
Jam
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The answers to quite nearly every single one of your questions could be found by reading the Sun Java Blueprints, or Deepak Alur's book "Core J2EE Patterns". I'd probably start there and then come back and see which of these questions you can answer on your own.
Kyle
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello :
In Fact they should be arranged/designed
with MVC:
Model contain Enterprise Bean (Entity ),
View include JSP pages and Java Bean,
Controller include Session Bean and Controller classes.
Rgds
George
 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello !
Kyle I appreciate that you always give some input on queries on which one can build up and learn on his/her own.
Here is what I feel about this.
For web server layer -
Model - JavaBean
Controller - Servlet
View - JSP
For app server level -
Model - Entity Bean (with the DB)
Controller - Session Bean
View - no view.. send it to the webserver level
Please correct me..
About the network call, think of the middle tier.. the app server will be somewhere else.. webserver separate and also.. a diff location for the DB. This is what the game is about.. if you cannot visualise where a network call comes into picture.. you need to get the idea behind 3 tier arch.
Thanks and Regards,
Leena
 
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Leena,
App Server Implementation of The Controller:
I am not sure if there needs to be a controller at that level. The App Server is too tied to the Model to do that. As per the MVC Pattern, the controller has to be the one that handles the business of delegating requests so i would definately feel that that job is best left to the Servlets in the Web Server layer itself.
Session Beans are still thinkable as business logic handlers but still, i would rather have the Servlets work as controllers for me.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, TRUE MVC isn't possible under anything using HTTP to get components talking to each other, since HTTP can't send unsolicited messages and a View needs them to update itself when the model is changed internally. Which is why the most popular adaptation of MVC to the HTTP/Java Server platform is known as Model 2 (the 2 is because the first "MVC" they tried didn't quite accomplish eveything desired).
 
Leena Diwan
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
umm.. aaa..
controller is a term.. not restricted to Servlets only.
My perception is, the component that has a controlling logic, is a controller.
Leena
 
sandy gupta
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You guys are abs right. Both Tim and Leena. MVC2 or JSP Model 2 is supposed to be the closest we can get to an ideal implementation of an MVC pattern. And Controller is just a name and can be anybody, a Bean or a Servlet.
reply
    Bookmark Topic Watch Topic
  • New Topic