Question

I’m planning to a webapp where every guy using it would have a client that would run computations on its computer (because these computations can’t be done on the server, too much load…), and then send results to the server.

I guess there will be lot of people interested in my application and that’s why i’m wonder if my architecture is good and if i’ll be able to handle thousands of people.

I’m planning to expose remote EJB through JNDI with Glassfish server, so 1000 people could use these EJB at the same time (i guess there could be 5-50 requests / second) to retrieve the data needed for local computation, and then to send the results…

Is it expensive to expose EJB to many clients?
Would it be better to use webservices, rmi, another solution?

Would you recommend me another architecture for what i’m going to do?

Answer 1

First, from an pure architectural point of view, EJBs are used for building distributed applications, Web services are an integration technology and they do not really compete with each others. In your case, EJB would be a natural choice (we are talking about EJB3, right?) and session beans scale very well.

Second, if the server-side code is only used to retrieve data from a database and to save results after client-side computation, then the app server will very likely not be the bottleneck, the database will. In other words, there is not much to worry about.

So, since your clients are all 100% Java clients, I would just expose stateless session beans¹ and avoid the overhead of SOAP/XML marshaling/unmarshaling and writing WSDL (if one day you need to expose your services as web services, this would still be possible, and easy).

¹ Using JPA or something else for the data access is left at your discretion.