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.