Servicios web vs EJB vs RMI, ventajas y desventajas?

Question

Servicios web vs EJB vs RMI, ventajas y desventajas?

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

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

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

54

java web-services rmi distributed ejb

Author: Dean J , 2010-01-06

Source

3 answers

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

Entre EJB y servicios web, los servicios web le darían más portabilidad si desea poder llamarlos desde aplicaciones que no sean java en el futuro. EJB de nuevo le da cosas como la gestión de transacciones y la agrupación que usted podría no obtener "fuera de la caja" con los servicios web.

Personalmente, si lo estuviera haciendo, lo haría probablemente use EJB o algún framework de objetos remotos similar (spring remoting viene a la mente también). Si necesita la capacidad de llamar a los objetos desde una aplicación que no sea java, siempre puede mostrar sus EJB con proxies de servicio web simples según sea necesario.

10

Author: Eric Petroelje,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-01-06 15:11:50

Re: servicios web (SOAP, REST) Si sus servidores back-end no van a ser expuestos públicamente, entonces no está obteniendo 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 toda la sobrecarga agregada por las etiquetas XML que envuelven los datos a través de una llamada remota, por no mencionar el golpe que tomará de marshalling y desmashalling del XML a objetos java.
Aunque cualquier llamada distribuida va a requerir algunos nivel de serialización-incluso RMI / EJB, pero el precio es mayor cuando se serializa a XML legible por humanos.

Es posible que no necesite codificar llamadas remotas en java, podría mostrar su servicio con una instancia apache httpd simple, que está configurada para equilibrar la carga entre varios servidores java utilizando mod_jk o mod_proxy.
Estos módulos se pueden utilizar para equilibrar la carga entre contenedores servlet como tomcat/jetty o contenedores ejb como jboss/glassfish.

4

Author: crowne,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-19 07:25:27

score 115 · Accepted Answer

Los EJB se construyen sobre RMI. Ambos implican clientes Java y beans. Si sus clientes necesitan ser escritos en otra cosa(por ejemplo,. NET, PHP, etc.) ir con servicios web o algo más que habla un protocolo de alambre 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 las JVM de cliente y servidor sincronizadas; no puede actualizar el cliente sin actualizar el servidor. Usted tiene que escribir todos los servicios que el EJB app server le proporciona (por ejemplo, agrupación de conexiones, servicios de nombres y directorios, agrupación, colas de solicitudes, transacciones, etc.).).

El RMI es bastante bajo cuando lo piensas. ¿Por qué volverías a CORBA?

Una mejor opción es EJB 3.0 versus Spring. Depende de si te gusta el desarrollo de POJO, quieres una opción de tecnologías relacionales además de OR y JPA, entre otras cosas.

Puede pagar por un servidor de aplicaciones Java EE (por ejemplo, WebLogic, WebSphere) o use uno de código abierto (JBOSS, Glassfish y OpenEJB y ActiveMQ), o puede apegarse a Spring e implementarlo en Tomcat, Jetty, Resin o cualquier otro motor servlet/JSP.

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

EJB 3.0 es una especificación con muchos proveedores; el resorte solo se puede tener de la Fuente del resorte.

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 puntos que debes tener en cuenta:

Latencia. La primera ley de objetos distribuidos de Fowler: "¡No!"Una arquitectura que consiste en una gran cantidad de servicios de jabón distribuidos de grano fino será elegante, hermosa y lenta como la melaza. Piense cuidadosamente antes de distribuir.
Marshalling from XML to objects and back consume ciclos de CPU que no proporcionan ningún valor empresarial, además de permitir que sus clientes hablen un protocolo independiente de la plataforma.
SOAP es un estándar que se está volviendo más hinchado y complejo cada día, pero tiene un montón de soporte de herramientas. A los proveedores les gusta porque ayuda a impulsar las ventas de ESBs. EL descanso 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 con elegir implementar de esta manera. Escriba en términos de interfaces de servicio POJO. Esto le permitirá obtener el aislamiento conceptual que desea, aplazar la elección de implementación hasta el último momento y le permitirá cambiar de opinión si el primer pensamiento no funciona bien.