See comments below:
Regards,
Murali Krishna Devarakonda
e: [EMAIL PROTECTED]
----- Original Message -----
From: Chip Wilson <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 11, 1999 8:16 PM
Subject: Re: Design Issue
> see comments below
>
> "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
Is this SSB storing the data for a single user or ALL users?
> > 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.
Depends on what you mean by "business code". For even modestly complex
tasks, chances are the business code belongs in your stateful session bean
methods, which in turn interact with one or Entity Beans or other components
in your system.
> > Kindly let me know if this approach is possible?
>
> This is an excellent approach.
And this is what pretty much everone does, EXCEPT:
Did I understand correctly that you want a single stateful session bean for
all clients(users)?
I don't think that's wise. You should have one Stateful Session Bean per
user.
You could have a Stateful Session Bean that has two create methods: one for
creating a new account, and one for login. So, the SSB represents the
current user, and caches all data that makes sense there.
BTW, you must take a good look at what data you need to cache and where- in
the Servlet, Stateful Session Bean, the Entity Bean, or elsewhere. This
could get hairy if not well thought out.
[...snip...]
> > 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
If you have multiple SSBs, what do they represent(how are they distinct from
each other), if they aren't each one per user?
> > 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
You should probably think about state that the entity bean represents, but
is also cached in the Stateful Session Bean or the Servlet's Session.
> > 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.
A typical design, ie. a Stateful Session Bean per user, wouldn't require the
userId/password with each request(and then again, it may).
So, again, what is your SSB storing? Only the userId and password for each
user?
>> 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.
Your password should not normally be in the EB Primary Key unless your req
says it cannot be changed(thanks Rickard:~).
> > 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.
>
> This would probably work, but is less desirable from an application
> architecture perspective. If you do this, the session beans can probably
be
> stateless.
[...chop...]
===========================================================================
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".
