Not sure if this is the right forum, apologies if it isn't :)
I have a very large data set which a thick (Swing) client wants to access. It is all RO, but too big to transfer in one go.
The GUI will traverse this object model and define a query tree with references to elements within this model, it will then send this query back to the server and get the results.
There are expected to be around 5000 users, with about 300-500 concurrent users.
The GUI people also have no concept of client server (they are VB6 devs) and want to treat the entire object model as a single, connected set of objects.
In theory, the solution would be the server exposing the object model as entity beans with a SSB facade for the reporting. Whether the Query object is built on the client and passed into the server, or whether it too is built up on the server isn't such a big issue as it will be relatively small.
Theory is all well and good, but how scalable is exposing a RO entity bean to the client?
If it really wouldn't scale up to the load I have described then I could go with another SSBFacade exposing serialized DTO (or VO) and wrap them in proxies on the client side so the network calls are transparent to the user (i.e. Object.getX() is in the VO, but Object.getChildren() loads the data behind the scenes).
Where do I go from here? I keep hearing about how eveil and unscalable Stateful Session Beans are, and exposing an Entity bean to a Swing client would be just as bad?
P.S. I have done a lot of J2EE work but with web front ends.