HTTPSession is not available to WebServices. At least I don't know how to use them.
But following circumstances should be very typical
When WebServices is called some proprietary "session" class should be created and some information should be stored in session to keep information about current state. When successive request comes to the server some information is attached to identify the session corresponded to this request. Server extracts information about this session and uses it to fulfill the
Request. EJB Statefull bean is good candidate to keep session information. Some singleton java class interface keeps references to all statefull beans and provides reference to particular EJB Statefull bean by request.
Ok. It probably works in the single server environment.
But how does it work in cluster?
Tomcat does not support EJB but supports some
Can I use tomcat session replication to synchronize some pool of Java Beans that are not stores inside the HTTPSession?
Do commercial APP servers like a WebSphere
support Statefull bean replication?
Definitely they should do.
Assuming that you tried and it's impossible to redesign the interaction so sessions are no longer required...
If client is guaranteed to be java, and stateful EJBs fulfil the scalability and fault tolerance requirements of project I'd go ahead and use them.
If you need web services you will probably have to roll out concept of custom session in your business logic. Kind of like shopping cart that is backed by the database. Client would explicitly pass session ID in the body as part of request. Operations that need session information would load and store them to db. If you are concerned about performance - benchmark it (databases are optimized to scale up extremely well, so it's unlikely that other cluster-wide session storage solutions will be faster).
Format of this forum is not allowed me to put here a pictures.
But let me put them on the internet and make here a link.http://sakalou.users.mcs2.netarray.com/webservices/web/clustermodel.jsp
Correct please if some of these assumtions are wrong.
However diagrams imply that "sessions" will be pooled in memory. It would be much more hassle-free to always keep them in the database. Especially if your requests are big and granular. It will add some latency to time it takes to handle single request, but entire system should scale. Databases are optimized extremely well for fast cached lookups. Updates should be fast enough too (measure it).
What's your scenario that absolutely requires "sessions in web services"?
It is not required but optional. I am currently working on
the architectural design of a new system so just want to be sure
that all possible issues are covered at least theoretically
in the design phase because we could not return back when
start implementation. We have not received all possible business
scenarios yet. So I assume that it theoretically some business scenario
can assume session support. But I agree with you that sessions
with WebServices should be very rear case.
Thank you for your help.
I've used read-mostly entity beans in BEA to accomplish this. They are replicated across the cluster. We needed to insure session state persistence and failover and this solution was appropriate.
This is not part of EJB standart ? Right ?
Right. That's why I specifically cited BEA. For more info, go to this link
and search/scroll down to "Read-Mostly Pattern".http://e-docs.bea.com/wls/docs81/ejb/entity.html