EJB session space

[eike]

Hi!

In a typical EJB scenario, session data (e.g. shopping cart) is stored using a stateful session bean which is referenced within the clients (jsp/servlet/php/what ever) session space.

Is there a way to store session data on the EJB side so that all session beans within the session can access this data? As there is no EJB session space I thought of a stateful session bean singleton approach. Any idea?

Thanks,
Eike

[larsbj]

I assume that what you'd like is to share data between the different sessions?

1. Have you thought about using the application context in the servlet container? It might be all you need.

2. What about making the shared data an entity bean?
(Maybe not a good idea performance wise)

If you could give a concrete example, it would be easier to find a solution to your problem

[eike]

Thanks for your reply!

What I want to do is associate a user object with every client. The user object will be accessed by every bean method the client calls.

My current options:

1.
Pass username and password along with every method call. The called method would then have to query an ejb to retrieve the user object.

Problems:
o performance
o security (passwords being transmitted all the time)
o ugly method signatures (2 extra params)

2.
Get a user object (stateful session bean) when client logs in, keep a reference within the http session and pass it along with every method call.

Problems:
o security (client might fake a user object?)
o ugly method signatures (1 extra param)

BTW I might use clients other than servlets/jsp (like php).

[hstech]

Hi eike,

I'm still not sure what you are trying to achieve with your design. Why do the Session beans need to access the User object?

Let's consider the likely scenario:

You have a presentation tier and an EJB tier. The EJB tier needs to know the active user on the presentation tier so the EJB tier can access the appropriate User object to perform some sort of processing.

Options:

(1) If the processing being implemented by the EJB tier is workflow logic, then consider splitting the workflow logic into the presentation tier, perhaps removing the need for the EJB tier to know about the User object.

(2) Otherwise, the presentation tier must pass something to the EJB tier to tell it which User object to use. This may be at the application level (passing a certificate, or a unique ID, or a username and password, or a serializable data object that represents the User object). Or, it may be at the system level (perhaps you can take advantage of the JAAS sub-system somehow. Once it has a way to reference the User object, it can then get the User object from: a database, an Entity bean (which gets instantiates a record in the database), or maybe from a JNDI directory.

Hope at least one of these ideas help.

Cheers,
Aaron.

[eike]

Hi Aaron,

> I'm still not sure what you are trying to achieve with your design. Why do the Session beans need to access the User object?

what I'm trying to do is to implement INSTANCE level method access permissions. As I understood, the EJB spec only covers CLASS level method access permissions. With my model there can be rules like "A client my call the 'addEntry' method of an 'AddressBook' bean instance if the instance's 'owner' property references the 'User' instance associated with the client" (rules can be much more complex). When a bean method is called, it must check wether the user that is associated with the client has the appropriate permission.


> [...] passing a certificate, or a unique ID, username and password

Does this mean every method has to provide parameters to access this information (ugly method signatures)
and then query a entity bean (low performance)?


> [...] serializable data object that represents the User object).

The User object conatins access permissions. Could a client fake such an object to get more permissions (security)?

If there were a EJB session space then I could create the user object on client login and put it in that session space. Every bean within the session could access the user object in a performant and safe way. No extra method parameters would be needed.


> perhaps you can take advantage of the JAAS sub-system somehow

Integration works with jBoss. Will it also work with other application servers?


There must be lots of people who want to define access permissions on the bean instance level. The problem is probably that the EJB spec seperates security issues and business logic. In my opinion something that should not have been done.


Thanks,
Eike