java - skeleton - Servicios web vs EJB vs RMI, ventajas y desventajas?

rmi java

Question

Mi servidor web se sobrecargaría rápidamente si todo el trabajo se realizara allí. Voy a poner de pie un segundo servidor detrás de él, para procesar los datos.

¿Cuál es la ventaja de EJB sobre RMI, o viceversa?

¿Qué pasa con los servicios web (SOAP, REST)?

Answer 1

Entre EJB y RMI, EJB ciertamente sería mejor: tiene todo lo que tiene RMI y mucho más a través del contenedor (agrupación de objetos, gestión de transacciones, etc.)

Entre EJB y los servicios web, los servicios web le brindarían mayor portabilidad si desea poder llamarlos desde aplicaciones que no sean Java en el futuro. EJB nuevamente le ofrece cosas como gestión de transacciones y agrupación que es posible que no obtenga "de fábrica" ​​con servicios web.

Personalmente, si lo estuviera haciendo, probablemente usaría EJB u otro marco similar de objetos remotos (también me viene a la mente el relajamiento de primavera). Si necesita la capacidad de llamar a los objetos desde una aplicación que no es de Java, siempre puede hacer frente a sus EJB con proxies de servicios web simples, según sea necesario.

Answer 2

Re: servicios web (SOAP, REST) ​​Si sus servidores back-end no van a estar expuestos públicamente, entonces no obtendrá ningún beneficio del uso de interfaces de servicios web independientes de la plataforma como SOAP / REST.
De hecho, incurrirá en una penalización con todos los gastos generales agregados por las etiquetas XML que envuelven los datos a través de una llamada remota, sin mencionar el impacto que obtendrá al organizar y desasociar el XML de los objetos Java.
Aunque cualquier llamada distribuida va a requerir algún nivel de serialización, incluso RMI / EJB, pero el precio es mayor cuando se serializa en XML legible por humanos.

Es posible que no necesite codificar las llamadas remotas en java, puede acceder a su servicio con una instancia simple de apache httpd, que está configurada para cargar el equilibrio en múltiples servidores Java usando mod_jk o mod_proxy .
Estos módulos se pueden usar para equilibrar la carga entre contenedores de servlets como tomcat / jetty o contenedores ejb como jboss / glassfish.

Answer 3

Los EJB se construyen encima de RMI. Ambos implican clientes y beans de Java. Si sus clientes necesitan estar escritos en otra cosa (p. Ej., .NET, PHP, etc.), acompáñelos con servicios web o cualquier otra cosa que hable un protocolo cableado independiente de la plataforma, como HTTP o XML sobre HTTP o SOAP.

Si elige RMI, no necesita un servidor de aplicaciones Java EE EJB. Debe mantener sincronizadas las JVM de cliente y servidor; no puede actualizar el cliente sin actualizar el servidor. Debe escribir todos los servicios que el servidor de aplicaciones EJB le brinda (por ejemplo, agrupación de conexiones, nombres y servicios de directorio, agrupación, cola de solicitudes, transacciones, etc.).

RMI es bastante bajo nivel cuando lo piensas. ¿Por qué dejarías todo el camino de regreso a CORBA?

Una mejor opción es EJB 3.0 frente a Spring. Depende de si le gusta el desarrollo POJO, quiere una opción de tecnologías relacionales además de ORM y JPA, entre otras cosas.

Puede pagar por un servidor de aplicaciones Java EE (por ejemplo, WebLogic, WebSphere) o usar uno de código abierto (JBOSS, Glassfish y OpenEJB y ActiveMQ), o puede quedarse con Spring y desplegar en Tomcat, Jetty, Resin o cualquier otro servlet / Motor JSP.

Spring ofrece muchas opciones al ser un agnóstico de la tecnología: persistencia (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), remoto (HTTP, Hessian, Burlap, RMI, servicio web SOAP), etc.

EJB 3.0 es una especificación con muchos proveedores; La primavera solo se puede obtener de Spring Source.

Yo recomendaría Spring . Es muy sólido, tiene mucha tracción, no va a ninguna parte. Deja todas tus opciones abiertas.

Los servicios web son geniales en teoría, pero hay algunos errores que debes tener en cuenta:

1. Estado latente. La primera ley de objetos distribuidos de Fowler: "¡No lo hagas!" Una arquitectura que consta de muchos servicios SOAP distribuidos de grano fino será elegante, hermosa y lenta como melaza. Piensa cuidadosamente antes de distribuir.
2. La clasificación de XML a objetos y viceversa consume ciclos de CPU que no proporcionan ningún valor comercial además de permitir que sus clientes hablen un protocolo independiente de la plataforma.
3. SOAP es un estándar cada vez más inflado y complejo, pero tiene mucho soporte de herramientas. A los vendedores les gusta porque ayuda a impulsar las ventas de los ESB. REST es simple pero no tan bien entendido. No es compatible con herramientas.

El módulo de servicio web de Spring es muy bueno, pero tenga cuidado al elegir implementarlo de esta manera. Escribir en términos de interfaces de servicio POJO. Esto te permitirá obtener el aislamiento conceptual que deseas, diferir la opción de implementación hasta el último momento y dejarte cambiar de opinión si el primer pensamiento no funciona bien.