Hi Pravin,
1. I like this approach, I have done something similiar myself,
however my stateful session beans act on domain objects - stored
as objects in Versant ODBMS instead of accessing Entity Beans.
On the subject of keeping the stateful session bean alive outside
the scope of the client. This can be done by serializing the beans
Handle and deserializing when required. However, in this case, one
variation I would like to try is, once the user has been
authenticated and the stateful session bean reference obtained,
have a high-level servlet which is responsible for keeping a
refernce to all stateful session beans. This servlet keeps a hash
of stateful session beans<->userId(\password). All client requests
will come in through this servlet. This servlet will then delegate
the request to the appropriate business servlet passing the ejb
reference. This business servlet will then execute the business method
on the session bean, which will in turn act on the entity bean. Also
I would use the session bean to carry out the business operation.
Leaving the entity bean to represent the underlying data and responsible
for carrying out any underlying data operations.
Some points to keep in mind here, is the session bean timing out;
to keep tranactions short - ensuring a transaction does not transcend
multiple client calls, and house-keeping session bean references
between servlets.
- having said that, I'm not sure if this is possible. One issue being,
servlets are normally loaded by different class loaders. But this is one
approach I would like to consider had I been writing a similiar app.
I'm sure there's a lot more to take into account.
2. I think I would go for approach one. However, if I was using an
object database - which I do. I would consider this approach, a change
I would make though ( depending on the app of course ) is to remove
entity beans and use session beans which act directly on my domain objects.
This would not be a problem as my domain model can map directly to my
persistent model. I think entity beans help define a good component model
as they allow the developer to focus on the domain, while taking
away\isolating
any mapping-to-database distractions. This is done at a cost though. With
an
object database there are no mapping issues and so less distractions.
Thanks,
Jazz.
-----------------------------------
Jasbinder Singh Gill (Consultant)
Versant LTD
Tel: ++44 (0)1256 366540
Mobile: +44 (0)958 904 536
Pravin S. Tiwari wrote :
>
> Application Logic : The first activity is login where the client gives his
> UserID and Password. This request is validated and for a valid request the
> other details ( i.e. customer no , account types and account no) were
> fetched in the background. Now after this a new page is sent back to the
> user with a menu with different options available to him. Selection of any
> option (i.e. Balance checking, Amount Transfers) will generate a new
> request by invoking a new servlet and this request will refer the
> same data
> fetched earlier, through login process (i.e. customer no , account types
> and account no) and process the request. It is required to maintain the
> user specific data through out the session till the user terminates the
> session.
>
> Technical Approach : we are calling a specific servlet for a specific
> client request with the required parameters and the servlet, which also
> acts as a client for a session bean, will create a stateful session bean.
> The parameter passed (i.e. UserId and Password) to this bean through the
> servlet client will be used to get the detailed data from main database
> where the necessary information is stored. We want all this information to
> be alive till the user terminates the session.
>
> We are considering two possible approaches for session / User Data
> management on the EJB layer:
> 1. one stateful bean will maintain all the data throughout session.
> In this approach we are having one centralized session bean which
> holds the user/ session data and forwards the request to different Entity
> beans after proper validations and with required request parameters. The
> actual business operation will be done through the Entity Beans,
> which also
> takes care of database specific jobs also.
> Here, we need to maintain all the data alive in the
> stateful bean.
> Every new request (i.e. every new servlet invoked form same client within
> same session) needs to refer to specific instance of the bean (created
> earlier with login process) for the additional data, which needs to be
> added to the request and does the required process by invoking different
> Entity beans where we are putting actual business code.
> Kindly let me know if this approach is possible? If yes, then
> a) Is it possible to keep the state of a stateful bean even if it's client
> is not alive? If yes,
> Then how do this and also how the instance of this stateful bean will be
> made available to different requests ( new servlets)?
> b) Can we use the Entity Beans for the purpose said above? If yes, then is
> there any limitation on the instances, which can be created for Entity
> beans within a container? how to design this so that the container can
> hold the data/ entity beans instances for very large number of internet
> users accessing the site ?
>
> 2. On a valid request we will create an entity bean, which will hold all
> the data, fetched from the database for a specific user.
> In this approach we have different Stateful beans with corresponding
> servlet clients. Here the first process of login will invoke a stateful
> bean specifically for login activity through a login servlet client. This
> stateful bean will fetch the details from the main database. On a valid
> request it will create an Entity bean containing all the user specific
> data. We need to maintain userID or UserID& Password at the servlet level,
> which will be passed with any request through servlet to new stateful
> session bean, which will handle the client and bean state only.
> The user id
> and password supplied with the request will be used as the
> primary key for
> finding the Entity bean already created after login process.
> Here the entity beans will be used for referencing user details only. The
> interaction with the Main database is handled by different Session EJBs
> depending upon their business logic.
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
