J2EE UserSession tracking for application clients

[Tom Zschockelt]

Hi all,

I've the following Business demand for an existing application (Migration from 2-tier to 3-tier).
We use wildfly 10 for the j2ee stack and additional an existing Framework (internal developed over years), which handles the Business logic. Now we faced the following problem.

When calling a servlet, jsp or jsf for the web stuff, we can use "HttpSession" for session tracking. But if we want to do an remote ejb call through JNDI remote calls directly to the EJBs there is no
session tracking at all.

My question : how could we solve a real user session tracking within a j2ee Environment for application Clients (what is best practice?)

How could we replace a static 2-tier call to get a user related database Connection like "MyStaticClass.getDbConnection()" within our existing Framework?

Thanks in advance
Tom

[K. Tsang]

Welcome to the Ranch.

Tom Zschockelt wrote:
My question : how could we solve a real user session tracking within a j2ee Environment for application Clients (what is best practice?)

To handle user session in different tiers: you can use HTTP session in the presentation/web tier, stateful EJB in the business/EJB tier

Now what's the best practice? .... Hmm just know stateful EJB is not very used much. Each method call from web to business to integration tiers and back "can" go like this, say fetch an order:
order.jsp --click button--> front controller (web tier) -> OrderController#getOrder (web tier) -> OrderManager#getOrder (business tier aka EJB) -> OrderDAO#findOrder (integration tier) that uses Order POJO/entity

The OrderManager EJB is most likely stateless EJB. Why? Each transaction (getting an order) is one time thing.

The situations that do require stateful EJB is something like shopping cart or multiple page form input. Yet depending on how you design your app, the so-called stateful EJB can be represented as transfer object.

You should check out the JEE tutorial on EJB http://docs.oracle.com/javaee/6/tutorial/doc/gipjg.html


Apart from the classes/code, the session tracking issue also apply if you use multiple web containers. As you may know a user's transaction first go to web container A then the same user 2nd transaction "may" go the web container B, which does not know that user's session! In such scenarios, the web container can enable sticky session allowing the same web container to server all transactions for that logged in user. Beside web container, sticky session feature also in load balancers.

Tom Zschockelt wrote:
How could we replace a static 2-tier call to get a user related database Connection like "MyStaticClass.getDbConnection()" within our existing Framework?

If your existing app is 2-tier, is it on separate machine? If so the server app is where the DB connection is. All the client needs is the POJOs or transfer objects for the display.

Under the 3-tier design, DB stuff is in the data access object (DAO) which goes in the integration tier.



Hope this helps. Other Ranchers' views may differ.

[Tim Holloway]

EJBs support container-managed security, so if you have secured the EJBs in question then I'd expect that you would have something you can hook into for tracking purposes.

One thing that's a little more problematic is the idea of having a different database connection for each client. The EJB architecture was very much designed to realize efficiencies from caching and pooling. That would seem to mandate BMP beans, which are pretty much out of fashion these days as far as I know. Locally, in fact, the whole town got soured on EJBs because the standard paradigm back then was remote BMP beans driving stored procedures which was a pretty horrible way of doing things.

Unless you must connect to an entirely different database or schema for each user, I'd recommend that all entity bean persistence be managed by session beans that ensure any access restrictions you might have. Generally if I have functions that I'm too paranoid to grant control to a lowest-common-denominator based access framework, I put the whole set of restricted functions in a separate webapp limited to only the users who have need of such rights. Typically, both the functions and the users are working in a space that's fairly distinct from the primary app anyway. For example batch process management or userid database management or something like that.