Services Web vs EJB vs RMI, avantages et inconvénients?

Question

Mon serveur web serait rapidement surchargé si tout le travail était fait là-bas. Je vais mettre en place un deuxième serveur derrière lui, pour traiter les données.

Quel est l'avantage des EJB par rapport à RMI, ou vice versa?

Qu'en est-il des services web (SOAP, REST)?

Answer 1

Les EJB sont construits sur RMI. Les deux impliquent des clients et des beans Java. Si vos clients doivent être écrits dans quelque chose d'autre (par exemple, .NET, PHP, etc.), optez pour des services web ou autre chose qui parle un protocole de communication agnostique de la plate-forme, comme HTTP ou XML sur HTTP ou SOAP.

Si vous choisissez RMI, vous n'avez pas besoin d'un serveur d'application Java EE EJB. Vous devez garder les JVM client et serveur en synchronisation ; vous ne pouvez pas mettre à niveau le client sans mettre à niveau le serveur. Vous devez écrire tous les services que le serveur d'application EJB fournit pour vous (par exemple, le pooling de connexions, les services de nommage et d'annuaire, le pooling, l'attente de requêtes, les transactions, etc.).

RMI est très bas niveau quand on y pense. Pourquoi redescendriez-vous jusqu'à CORBA ?

Un meilleur choix est EJB 3.0 par rapport à Spring. Cela dépend si vous aimez le développement POJO, si vous voulez un choix de technologies relationnelles autre que ORM et JPA, entre autres choses.

Vous pouvez payer pour un serveur d'application Java EE (par exemple, WebLogic, WebSphere) ou utiliser un open source (JBOSS, Glassfish et OpenEJB et ActiveMQ), ou vous pouvez rester sur Spring et déployer sur Tomcat, Jetty, Resin ou tout autre moteur servlet/JSP.

Spring offre beaucoup de choix en étant agnostique en termes de technologie : persistance (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), communication distante (HTTP, Hessian, Burlap, RMI, service web SOAP), etc.

EJB 3.0 est une spécification avec de nombreux fournisseurs ; Spring ne peut être obtenu que chez Spring Source.

Je recommanderais Spring. C'est très solide, a beaucoup de traction, et ne va nulle part. Cela laisse toutes vos options ouvertes.

Les services web sont excellents en théorie, mais il y a des pièges auxquels vous devez faire attention :

1. Latence. La première loi des objets distribués de Fowler : "Ne le faites pas !" Une architecture consistant en beaucoup de services SOAP distribués granulaires sera élégante, belle et lente comme la mélasse. Réfléchissez bien avant de distribuer.
2. La sérialisation de l'XML en objets et vice versa consomme des cycles CPU qui ne fournissent aucune valeur commerciale en dehors de permettre à vos clients de parler un protocole agnostique de la plate-forme.
3. SOAP est une norme qui devient de plus en plus gonflée et complexe chaque jour, mais elle bénéficie de beaucoup de support d'outils. Les fournisseurs l'aiment car cela aide à stimuler les ventes d'ESB. REST est simple mais moins bien compris. Il n'est pas pris en charge par les outils.

Le module de services web de Spring est très bon, mais faites attention au choix de déployer de cette manière. Écrivez en termes d'interfaces de service POJO. Celles-ci vous permettront d'obtenir l'isolation conceptuelle que vous souhaitez, de reporter le choix du déploiement jusqu'au dernier moment et de changer d'avis si la première réflexion ne fonctionne pas bien.

Answer 2

Entre EJB et RMI, EJB serait certainement meilleur - il a tout ce que RMI a et bien plus via le conteneur (piscine d'objets, gestion de transactions, etc.)

Entre EJB et les services web, les services web offriraient plus de portabilité si vous voulez être en mesure de les appeler à partir d'applications non-java à l'avenir. EJB vous donne encore des choses comme la gestion des transactions et le regroupement que vous pourriez ne pas obtenir "prêt à l'emploi" avec les services web.

Personnellement, si je le faisais, j'utiliserais probablement EJB ou un autre framework d'objet distant similaire (Spring remoting me vient également à l'esprit). Si vous avez besoin de la possibilité d'appeler les objets à partir d'une application non-java, vous pouvez toujours créer des proxies de services web simples pour vos EJB au besoin.

Answer 3

Re: services web (SOAP, REST) Si vos serveurs back-end ne sont pas exposés publiquement, alors vous ne tirez aucun bénéfice de l'utilisation d'interfaces de services web indépendantes de la plate-forme telles que SOAP/REST.
En fait, vous allez subir une pénalité avec tout le surcoût ajouté par les balises XML enveloppant les données à travers un appel distant, sans parler de l'impact que vous subirez lors du marshalling et du unmarshalling de l'XML vers des objets java.
Bien que tout appel distribué nécessite un certain niveau de sérialisation - même RMI/EJB, mais le prix est plus élevé lors de la sérialisation en XML lisible par l'homme.

Vous n'avez peut-être pas besoin de coder des appels distants en java du tout, vous pourriez mettre en avant votre service avec une instance apache httpd ordinaire, configurée pour équilibrer la charge entre plusieurs serveurs java en utilisant mod_jk ou mod_proxy.
Ces modules peuvent être utilisés pour équilibrer la charge entre des conteneurs servlet tels que tomcat/jetty, ou des conteneurs ejb tels que jboss/glassfish.