How to share conversational state between various session facades?
Hi all,
We have a big problem with designing a bigger J2EE Application using the J2EE Pattern. We have to develope an big workbench application for accounting clerks.
The Problem is that there are so many BP's and functions, that one session facade is not enough, so we need 5 or 6. The Problem is that for example all the login stuff is placed in one session facade. If the user logs in, his data is stored in these session facade (stateful session bean). The Problem is that some of the other session facades needs some user information, too. So whats the right way to get the user information stored in one stateful session to another stateful session bean. For our application it is not possible to use Entity Beans.
Our frontend is an web-client. But it should be changeable.
thanks & regards
Rene G.
[847 byte] By [
Rene-Ga] at [2007-9-29 8:48:24]
It is highly recommanded to use StateLess Sessions Beans (SLSB) whenever it is possible.
Can't you store user data in a session variable, replacing all your SFSB by SLSB?
In our site, the only SFSB we have is used to communicate between webapps.
In your example, you would avoid to access the data of a SB from another : the bean's "clients" (web part) would manage the shared data.
/Stephane
Hello,
thanks for the hint, but what do you mean with "store user data in a session variable", do you mean the http session for example?
I read in some papers from Sun, that it is recommended to store conversational state in an stateful session bean, if you use EJB's in your Application, it is only recommended to use the http session for example, if you don't use EJB's in your application. The sateful session facade would call servicecomponents, which are implemented as stateless session beans, maye be over local interfaces.
Are you sure, that i should store the conversational state at the client side?
thanks & regards
Ren?G.
> I read in some papers from Sun, that it is recommended
> to store conversational state in an stateful session
> bean, if you use EJB's in your Application, it is only
> recommended to use the http session for example, if
> you don't use EJB's in your application.
No, I would recommend using HTTPSession over SFSBs. In spite of Sun's 'recommandations', SFSBs (along with Entity beans..) should be avoided when possible. The only resons not to do so would be :
- You need stateful objs that are transaction-aware. In that case, you'll use SFSBs because they can implemnt the SessionSynchronization interface.
- You have both web-based and non-web-based clients that both require state.
> In> spite of Sun's 'recommandations', SFSBs (along with> Entity beans..) should be avoided when possible.Avoid making blanket statements - this is not true "globally" for either SFSBs or EntityBeans.
> Avoid making blanket statements - this is not
> true "globally" for either SFSBs or EntityBeans.
Yes , it is. And please do not tell me how to formulate my statements.
Anybody who has been through a full EJB project (and apparently, you have not) knows what I'm talking about.
Come back with something that tells me you know what you're talking about.
Obviously, your experiences and mine differ. Anything beyond that would obviously be pointless to pursue.
I read in some papers from Sun, that it is recommended to store conversational state in an stateful session bean
You'll find some papers that will tell you the opposite, too.
I did meant Http session objects. It seems a bit more "dirty" but it is more efficient.
BTW, have a look to Rod Johnson's book "J2EE design and development".
/Stephane
But i have written in my first post that the client is in the moment web-based, but it should be changeable. So in the future there could be a swing client, too. And we need transactions.
So it would be better to store conversational state at the application server side, or i am wrong?
But how to share this state between various session facades?
thanks & regards
Rene G.
So?
It is even better to store conversational state on the client side and call your SLSB at the end of your process.
If you need many session facades for one transcation, that means that there is something wrong with your facades : they should provide high-level methods only.
You call your SLSB only when you have collected enough information on the client size to go to the database. For istance, if you have 3 forms to collect data for one database record, then you must have only one call (for update).
/Stephane
You are right, in my opinion the design is wrong, too. But i don't know how to design the application in the right way.
We have to design a big application for an insurance company.
For example we have an workbench web applcation to handle insurance applications and contracts. For chances of personaldata in insurance applications your solution with collecting all the data and after then send the data to the application server sounds good. But every insurance application can have a lot of states (for example Contract, in risk analysis, on hold,....). So the session facade needs a lot of methods for all the state transistions, or how would you do it? The problem is that on every state transistion an email is sent and some other functions must be called, so it is not enough to change the values of the dataobject. I think it would not be a good solution, to have all the state transition function on the webserver side, and only call the function for sending emails and so on on the application server. Then all the logic of the workflow is implemented on classes at the webserver side, and that isn't a good design, isn't it? If i would do so, it would be very hard to change the client to a not webbased client.
Some ideas?
thanks & regards
Rene G.
I changed the design of my application, so the problem are solved now.Thanks for all the hints.Bye Ren?
Can u tell me the design u used to solve ur problem..Thanks!regards,Mathan
