Login/Auth strategy for J2EE Application

[Renat Zubairov]

Hi All,
What do you think about following strategies to handle login and auth. process (for Web/Swing clients):
1. After successfull username/password check we create statefull session bean for user and remote interface stored (with Handler) on the client.
2. We have Stateless facade for Entity/DAO with User value object which is stored on the client side.
And also, how we can leverage build-in features of J2EE (1.2) for that purpose?

[Dushy Inguva]

Renat,
For a web client:
I guess you can use the Session mechanism which is already built in. It should give you some amount of control over the user login and auth process (I agree it couldv'e been much more powerful)
For a swing client:
I prefer the second approach for two reasons.
1. As the number of users increase, the number of "live" Stateful session beans makes me feel uncomfortable. (One session bean per user as long as the user is connected.) - I'm skeptic about my comment though !!!
2. You are very tied to the application server in the mechanism in which it connects and maintains the state. (The entire protocol is java based) In case you have to make the communication XML based, you are toast. In the second approach, you can serialize the User value object in XML and send it over to the client.
Any comments anyone?
Dushy

[Renat Zubairov]

Thank you Dushy
I'm also put second one in my solution, but never the less the second approach has a problem with stole data.
For example, we have updatable value object (I mean entity bean should have setData method as well as getData) and under the object complex data tree is stored (agregated). In this case if we are trying to add a new data to VO and we need transactional support for it, we can't do it in VO. We can do it only in Entity bean and the refresh VO representation. Also if we need complex transactional behaviour for Entity beans method (because Entity bean is business object representation, imagine User.addSubscription() or User.addItinerary() ) we are stuck with the CMT.

[Thomas Taeger]

Originally posted by Renat Zubairov:

stole data

... what does "stole data" mean?

... updatable value object ... and under the object complex data tree is stored (agregated). In this case if we are trying to add a new data to VO and we need transactional support for it, we can't do it in VO.

Why can we not add new data to the VO if we need transactional support? I agree that we need additional effort for container managed relationships (CMR, not CMT) for mapping the new VO data to a newly found, newly created or given entity bean, but this does not concern CMT. Right?

... if we need complex transactional behaviour for Entity beans method (... imagine User.addSubscription() or User.addItinerary() ) we are stuck with the CMT.

We were talking about stateLESS SessionBeans/Facades, therefore the CMT transaction normally will not last longer than the one call to one method of that stateless SessionBean anyway, right?
But within that one call a whole workflow of multiple EntityBean-calls may use that same transaction started by the SessionBean.
So as long as we do not need a transaction spanning several sessions (request/response pairs): Why are we stuck with CMT (container managed transactions) for things like User.addItinerary()? We must use CMT wherever we use EntityBeans, because EntityBeans are supported by CMT only. Is it that what you ment?
More important: Is it wise to add things like Itinerary to a User VO that probabely is not needed for web clients? Should we not prefere something like a Response VO carrying a User Object, if needed, and an Itinerary (etc.) object with it (for Java and for web clients)?
- - -
BTW: I guess that most containers will automatically begin a [flat] transaction when accessing a SeesionBeans's method having a "Requires" or "RequiredNew" transaction attribute. What I am not sure by myself is: How could we tell the container to use the same transaction for multiple request/response pairs when using CMT? It would not make much sense, I know, but is that possible at all when using CMT?

[Renat Zubairov]

Hi Thomas,
Stole as far as I understood means that data in EntityBean may be changed since the last time I've got it. Offcource in this case transactional isolation comes into a play, but nevertheless.

We were talking about stateLESS SessionBeans/Facades, therefore the CMT transaction normally will not last longer than the one call to one method of that stateless SessionBean anyway, right?
But within that one call a whole workflow of multiple EntityBean-calls may use that same transaction started by the SessionBean.
So as long as we do not need a transaction spanning several sessions (request/response pairs): Why are we stuck with CMT (container managed transactions) for things like User.addItinerary()? We must use CMT wherever we use EntityBeans, because EntityBeans are supported by CMT only. Is it that what you ment?

Not really. Imagine you need to make more than one modification of VO and therefore EntityBean, and you need to make it in several independent transactions (otherwise it would be one fall everything rolled back).
Also you can't commit transaction inside EntityBean but sometimes it's really needed.

More important: Is it wise to add things like Itinerary to a User VO that probabely is not needed for web clients? Should we not prefere something like a Response VO carrying a User Object, if needed, and an Itinerary (etc.) object with it (for Java and for web clients)?
- - -
BTW: I guess that most containers will automatically begin a [flat] transaction when accessing a SeesionBeans's method having a "Requires" or "RequiredNew" transaction attribute. What I am not sure by myself is: How could we tell the container to use the same transaction for multiple request/response pairs when using CMT? It would not make much sense, I know, but is that possible at all when using CMT?
I think it's impossible to make the same transaction in multiple calls if they are not a subsequent call of one.
[ March 10, 2004: Message edited by: Renat Zubairov ]