EJB3 Remote vs Webservices, performances?

Question

Hello

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

My 2p is that offering a Webservice or XML/http client is easier and more standard from the client point of view. One benefit is they do not need to be Java clients if its a SOAP web service.

Answer 2

I read on a forum that it could be a bad idea to retrieve entities in client because proxy is kept and it generates traffic

One guy tested and a 40ko serialised list of 300 object generated 3.6mo network trafic in wireshark, but if you use EntityManager.clear() to detach entities or you use pojos dto return type to remote functions then it's ok :)

Answer 3

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.