aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes How to manage the session for GUI and Web client Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "How to manage the session for GUI and Web client" Watch "How to manage the session for GUI and Web client" New topic
Author

How to manage the session for GUI and Web client

edward zhon
Greenhorn

Joined: Apr 03, 2006
Posts: 2
Hi,

I am under the preparation for the SCEA Part II. I want to use the Session Bean to support both GUI and Web client, however I do not know how to manage the session info for both GUI and Web client. For example, once login use case was executed, where to store the userid session info and how to link this userid to the following user interaction with system. which expert can light me up? Thanks a lot!
B.Sathish
Ranch Hand

Joined: Aug 18, 2005
Posts: 372
I am no expert, but I can tell you this - Usually, you store the user id details in the HttpSession object of the servlet. When the next call comes from the user, you would do a HttpServletRequest.getSession(). This will give you the HttpSession object for that user. The mapping would be done by the web container using cookies / URL rewriting. The request would have a Cookie header that would have the Session Id. This will be extracted by the web container and matched with the session objects in memory. If cookies are not allowed, the session id would be a part of the URL (provided the developer has used URL rewriting in code).

You use a stateful session bean typically to store the client-specific state related to the application's business logic such as the state of an online shopping cart of a customer
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Originally posted by edward zhon:
Hi,

I am under the preparation for the SCEA Part II. I want to use the Session Bean to support both GUI and Web client, however I do not know how to manage the session info for both GUI and Web client. For example, once login use case was executed, where to store the userid session info and how to link this userid to the following user interaction with system. which expert can light me up? Thanks a lot!


Edward,

If you intend to use an Session Bean to manage the users state session, you could use the following approach.

- Your session bean should be an stateful session bean
- In this session bean, you can store an reference of the user ID as an attribute
- In the web portion application, create an Business Delegate for this bean, that access the session bean by remote interfaces.
- In you HTTPSession, you can store the EJB Handle of this Session Bean. If you need to access the Session Bean by another Servlet (or Struts Action), you can retrieve the EJB Handle from HttpSession, instantiate the Business Delegate passing the EJB Handle, and the Business Delegate re-create the remote reference based on the Handle.

So, the simpliest structure should be like this:

[Action or Servlet] --> [StateDelegate] --> [StateBean]

Talking about responsabilities:

- HttpSession
It should store the ejb handle for the SFSB

- Business Delegate
Re-create the enterprise bean reference based on it�s handle
Access the business methods from the bean, and your attribute state

The idea behind this techinique is a quit simple: Do not store any piece of information about user session in the web tier, every kind of data should be stored in the EJB tier, to promove scalability and extensibility.

I hope have helped you !


Ricardo Ferreira,<br /> <br />Sun Certified Enterprise Architect<br />IBM Certified SOA Solution Designer<br />IBM Certified RUP v7.0 Solution Designer<br />IBM Certified Specialist for RUP v2003
s khosa
Ranch Hand

Joined: May 15, 2003
Posts: 72
Ricardo,

Just wanted to clarify. Your suggestion would work fine for web client, but for a desktop client you would need to to JNDI look ups for the Session Bean, right?

Thanks
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Yes, if you use a web client, you should use JNDI lookp�s to recovery the EJBHome interface. But, this process is done only once time, the first access for the bean from an given client.

The seconds access need not to lookup again since the EJB handle are being used. This is the usage for javax.ejb.Handle.
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Complementing my last answer, even if you use a desktop client, you can use the benefits of an Handle. But, instead you store the handle in an HttpSession (that will not be available), you could store this reference in a static attribute of an class.

But, for both approachs, you need, even for once, use the JNDI Look�s, since we�re talking about remote references (javax.ejb.EJBHome)
s khosa
Ranch Hand

Joined: May 15, 2003
Posts: 72
hmm....with static only issue i see is if my mistake u implement a singleton pattern in your controlling component ( or singlethreaded model in case os servlets) which contains this static thingie... you would automatically loose all the benefits of pooling. Am i right?

Thanks
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
khosa,

if you are in an desktop application, you need not to worry about multiple concurrency access, since there is only one application in the JVM. The static reference will be used only to maintain the EJB handle, that is, a reference for an enterprise bean, that is maintained in the EJB tier.

You are using, with this suggested approach, object management too, in the ejb tier. Remember: The static reference will only store the ejb handle for the bean, not the Bean.

I have suggested an static reference, but you can use any other technique (an non static attribute, an database field, whatever), you only need to ensure that this reference are stored during the application lifetime, otherwise, you will need to re-create the remote bean reference.

Ok?
Rama Bhargav
Greenhorn

Joined: Mar 25, 2006
Posts: 25
I am thinking of using an Hybrid model. It work like this.

1) We can use SFSB for storing the customer profile and other application specific state like shoping cart.
2) In the web layer in httpSession use an indicator (for example: isCustomerSignedOn).

This way, when the use requests an operation that requires him to login (for example, Pay an Itinerary), and he has not logged in yet, web layer can present the login screen instead of doing invoking the EJB. This way we could optimize the performance by saving atleast one network call. Any comments ..
B.Sathish
Ranch Hand

Joined: Aug 18, 2005
Posts: 372
Why should you store the user details in the stateful session bean? A stateful session bean is not meant for that. It is meant to store the client-specific state related to the business logic of the application and not the user login details.Doing so would be poor delegation of responsibilities. Why go all the way to the EJB to get the user details? The user details are typically stored in HttpSession of the servlet
Rama Rao Yadlapalli
Greenhorn

Joined: May 07, 2003
Posts: 3
Satish,

You are right. When I said user details, I did not mean login credentials, but I meant Customer profile.
edward zhon
Greenhorn

Joined: Apr 03, 2006
Posts: 2
Hi,
Thanks for sharing.

I want to combine 'Sathish' and 'Ricardo' solution in this way, any comment?

1) HttpSession object of Web tier will store a loginFlag = "true" reference once user login
2) A singleton object of GUI client tier will store loginFlag = "true" reference once user login as well.
3) one SLSB handle the behaviors of prepare/change itinerary
4) one SFSB handle the behaviors of confirm/price/payment itineray
5) Before running the operation of " confirm/price/payment itineray " , both web tier and GUI client tier program will check whether "loginFlag = true". If flag is 'true', which means user has logged in. create one SFSB and store this bean's remote reference or EJB handle either in the Httpsession for Web tier or in the sigleton object for Client GUI tier.
If flag is 'false', run login use case.
6) Do not need to store userid in this SFSB because SFSB's remote reference/EJB handle can be retrived by the same user who want to use this SFSB next time either through httpSession object for WEB Tier or through a singleton object for GUI client tier.
B.Sathish
Ranch Hand

Joined: Aug 18, 2005
Posts: 372
There is manual checking in your code for authentication by using a boolean flag etc. I am thinking whether you can make your design better by using the standard servlet authentication mechanisms like BASIC/DIGEST etc. You can configure users, passwords and roles in the web container's security realm .The container will take care of the authentication for u. Such a design will fetch you more marks than manual authentication in code. Just my 2 cents
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Hello,

You can use the declarative container managed security and you will only need to configure this (no code necessary). You can use request.getUserPrincipal() from the web or context.getCallerPrincipal() from the ejb layer.

I have scoured this forum for info on this topic.

My thought is that SFSB are very slow and should not be used for the web client. SFSB could be used for the agent. I would store the shopping cart in the HTTPSession for web customers. The shopping cart would be stored in SFSB for the agents. Is this thinking wrong?

Is it okay to store customer data and shopping cart data in the same session location? I know that one is considered user info and the other is business info.

Another thought is: for the swing client, what about storing the state information (customer profile, shopping cart) in the swing client itself?

Please respond.

Thanks.

-Saha
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Another question is:

is the session object (httpSession or SLSB) shown in the sequence diagrams?

Many thanks for any replies.

-Saha
Rama Bhargav
Greenhorn

Joined: Mar 25, 2006
Posts: 25
Saha,

If you store shopping cart in different places, how would you manage the changes to the state of shopping cart? When a user adds a new flight, removes a flight in the shopping cart, where would you put the code to take care of these additions/deletions to cart? Would n't this lead to code redundancy?
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
hello Rama,

Well, one solution would be to cache the shopping cart in the swing application. Since I persist unpaid itineraries, most of the cases retrieve the itineraries from the db (not the shopping cart). The storing/retrieving from the shopping cart would be done in a servlet controller class and also in a swing controller class.

Am I on the right path? Please respond.

-Saha
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Rama,

One more concern is: can one server handle 620 stateful concurrent session beans? If this doesn't give any performance problems, them SFSB is a good idea.

Any responses are welcome.

Thanks.

-Saha
Rama Bhargav
Greenhorn

Joined: Mar 25, 2006
Posts: 25
I have reservations about storing the shoping cart data in the client/presentation tier. I see two potential issues.

1) If we are to support a new client in future (like Voice Client), they have to take care preserving the shopping cart data. Not that it can not be done, but why do we have to do that when we have the option of not having to worry about it by placing this piece of functionality in Business Tier as this common across clients.

2) If you store this in client specific cache like HttpSession, and if the client access his cart using multiple browser instances, you will end up storing that many copies of the same shopping cart data in the httpSession. Hypothetically speaking, if a client opens 100 new browser instances and accesses his shoppting cart, the httpSession will have 100 copies of the same shopping cart info (unless your client tier restrict 1 user to 1 sesson), while this kind of problem won't occur when we use store it in Business tier.
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Hello Rama,

Thank you for making very good points. I especially think 1) is important point. I want to read more about stateful vs. HTTPSession before deciding. There are many articles on the web. At this time, I am leaning toward SFSB.

-Saha
tony clare
Ranch Hand

Joined: Apr 19, 2006
Posts: 31
My understanding for web tier and EJB tier are:
1) web tier is front desk people to warm up the customers like service waitress.
But
2) EJB tier is professionals to perform the real things for customers while the waitress laughs with the customers.

Based on this, the web tier handles the user sessions (in order to maintain the connection in one visit context) and EJB tier handle the specific state for specific tasks. like saying a customer asks two seperated services from two SFSBs.
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 309
Hi all,

1. Could you please first clarify what kind of architecture you talk about:

- a Java/GUI client (in J2EE's client-side Application Container) directly accessing EJBs (in the EJB container), or

- a Java/GUI client (in J2EE's Application Container, or a Standalone Application without a container) accessing the same servlet as the web frontend and then following the same way as HTML requests?


2. In eighther architecture a simple way to avoid stateful session beens is to just

- pass IDs back to the whatever client within the response DTO (data transfer object), along with any business data to be shown, and then

- pass the usually very few data including (server-side) IDs within the HTTP request or as a parameter of the RMI call to the web server / servlet or (for Java clients) directly to the application server / EJB.

That way you can design pretty independantly of the protocol (GUI vs. web), and this is what you will be mostly given points for. Do you agree?

Thomas


www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to manage the session for GUI and Web client