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
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
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
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
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.
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).
Sources may include data from the Fakebook Research Foundation with support from Gargle University
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.