EJB3 Remote vs Webservices, performances?

Question

Je prévois une webapp où chaque mec qui l'utilise aurait un client qui exécuterait des calculs sur son ordinateur (parce que ces calculs ne peuvent pas être faits sur le serveur, trop de charge ...), puis envoyer les résultats au serveur.

Je suppose qu'il y aura beaucoup de gens intéressés par mon application et c'est pourquoi je me demande si mon architecture est bonne et si je serai capable de gérer des milliers de personnes. Je prévois d'exposer EJB à distance via JNDI avec le serveur Glassfish, donc 1000 personnes pourraient utiliser ces EJB en même temps (je suppose qu'il pourrait y avoir 5-50 requêtes/seconde) pour récupérer les données nécessaires au calcul local , puis d'envoyer les résultats ...

Est-il coûteux d'exposer EJB à de nombreux clients? Serait-il préférable d'utiliser webservices, rmi, une autre solution?

Me recommanderiez-vous une autre architecture pour ce que je vais faire?

Answer 1

D'abord, d'un point de vue purement architectural, les EJB sont utilisés pour construire des applications distribuées Les services Web sont une technologie d'intégration et ils ne sont pas vraiment en concurrence les uns avec les autres. Dans votre cas, EJB serait un choix naturel (nous parlons d'EJB3, n'est-ce pas?) Et l'échelle des beans de session est très bonne. Deuxièmement, si le code côté serveur est uniquement utilisé pour extraire des données d'une base de données et pour enregistrer les résultats après le calcul côté client, le serveur de l'application ne sera probablement pas le goulot d'étranglement, la base de données le fera. En d'autres termes, il n'y a pas grand chose à craindre.

Ainsi, étant donné que vos clients sont tous les clients Java 100%, je voudrais juste exposer les beans session sans et éviter la surcharge de SOAP/XML marshaling/unmarshaling et WSDL écrit (si un jour vous avez besoin d'exposer vos services en tant que services web, cela serait encore possible et facile). L'utilisation de JPA ou d'autre chose pour l'accès aux données est laissée à votre discrétion.

Answer 2

Mon 2p est qu'offrir un Webservice ou un client XML/http est plus facile et plus standard du point de vue du client. Un avantage est qu'ils n'ont pas besoin d'être des clients Java s'il s'agit d'un service Web SOAP.

Answer 3

J'ai lu sur un forum que ce pourrait être une mauvaise idée de récupérer des entités dans le client parce que proxy est maintenu et il génère du trafic

Un gars testé et une liste sérialisé de 40ko de 300 objet généré 3.6mo trafic de réseau wireshark, mais si vous utilisez EntityManager.clear() pour détacher des entités ou que vous utilisez pojos dto retourner le type à des fonctions distantes alors c'est ok :)