私は、それを使用するすべての人がそのコンピューター上で計算を実行するクライアントを持っているWebアプリを計画しています（これらの計算はサーバー上で実行できないため、負荷が大きすぎるため...）、結果をに送信しますサーバ。
私のアプリケーションに興味を持っている人はたくさんいると思います。そのため、私のアーキテクチャが優れているかどうか、そして何千人もの人を処理できるかどうか疑問に思っています。
Glassfishサーバーを使用してJNDIを介してリモートEJBを公開することを計画しているので、1000人が同時にこれらのEJBを使用して（1秒あたり5〜50のリクエストがあると思います）、ローカル計算に必要なデータを取得してから、結果を送信します...
EJBを多くのクライアントに公開するのは費用がかかりますか？Webサービス、rmi、別のソリューションを使用する方が良いでしょうか？
私がやろうとしていることのために、私に別のアーキテクチャをお勧めしますか？
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 beans1 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).
1 Using JPA or something else for the data access is left at your discretion.
私の2pは、WebサービスまたはXML / httpクライアントを提供する方が、クライアントの観点からはより簡単で標準的であるということです。1つの利点は、SOAP Webサービスの場合、Javaクライアントである必要がないことです。
プロキシが保持され、トラフィックが生成されるため、クライアントでエンティティを取得することは悪い考えである可能性があることをフォーラムで読みました
1人の男がテストし、300オブジェクトの40koシリアル化リストがwiresharkで3.6moネットワークトラフィックを生成しましたが、EntityManager.clear（）を使用してエンティティをデタッチするか、pojos dを使用してタイプをリモート関数に返す場合は、問題ありません:)