Which approach would you take for web based system that is suppose to support a lot of clients at a time(>2000 simultaneous accesses).The clients basically will be viewing large volumes of data that is consumed from a myriad of systems , by the back end webservices. A propOsed solution was a SFSB that talks to a webservice.The webservice brings back large volumes of data.The data never needs to be persisted.It's just viewed(read only) by many many clients at a time.A client can open a session to view the data and leave the session running for many hours at a time.When they (the client) need to view the data again after some passive time , then data has to be refreshed, so that they see up-to-date data. The caching for that data would be done using either ehcache or OSCache, in the SFSB.
However , due to the large number of clients , it does seem the choice of SFSB as a way to manage client sessions is NOT GOOD , because for each client , an SFSB has to be created , and this will drastically degrade the performance and scalability of the application.At the same time , having a solution that uses SLSB and HttpSession , where the data is cached in an HttpSession would also place a heavy load on the HttpSession because of the large volumes of data.
How would you design /architect solution for such a scenario?