Java: RMI vs servicios web

Question

Necesito crear una aplicación distribuida que consta de varios clientes que envían archivos (más información sobre archivos) a un servidor, también consulta ese servidor.

Los clientes deben acceder a ese servidor web desde el interior de la empresa para enviar los archivos. Pero, ocasionalmente, algunas consultas específicas deben ejecutarse fuera de la empresa.

Creo que, dado lo que sé, RMI es una forma más rápida (rendimiento operativo) de conectar el cliente de escritorio con el motor de indexación más el motor de almacenamiento. Y creo que hacer un servicio web que brinde una capa de acceso al motor de búsqueda también es una buena decisión, ya que se ejecutará fuera de la red de la empresa.

¿Qué opina sobre eso? Es un buen enfoque o tienes algunas alternativas deben ser consideradas.

Gracias de antemano.

Answer 1

RMI se puede tunelizar a través de HTTP (ver here), así que no dejes que eso influya demasiado en tu decisión.

Si ambos extremos pueden hablar RMI, entonces RMI es probablemente lo que debe usar; es mucho más fácil trabajar que un servicio web.

Answer 2

¿Qué le hace pensar que RMI es más rápido? Desde mi experiencia, puede ser lento, difícil de configurar, difícil de asegurar y, en general, desagradable de trabajar.

Dado que los servicios web generalmente son solo XML sobre HTTP, generalmente puede diseñar una solución que escale mejor.

Answer 3

Si la API quieres apoyar con el servicio no se asigna muy bien a HTTP, probablemente elegiría para RMI (pero cuidado con idas y vueltas innecesarias.)

Si no mapa en HTTP muy bien, volvería a elegir para ir con REST, que es esencialmente Servlets HTTP que implementan su API como acciones. Si la mayor parte del tráfico es la carga/descarga de los archivos que menciona junto con algunas llamadas a la API, este es probablemente el camino a seguir.

Por cierto, su experiencia de que RMI es más rápido que los servicios web coincide con el mío. (Ambos pueden implementarse con un rendimiento lento como resultado, principalmente para hacer con recorridos de ida y vuelta en una API mal diseñada.)

Answer 4

Tenga cuidado aquí, desarrollé una solución similar recientemente y descubrí que los enchufes eran la forma más eficiente y eficaz de transferir archivos, mientras que RMI era bueno para llamadas a métodos simples (como consultas). También tuve dificultades para configurar RMI, la configuración puede ser confusa a veces y no hay mucha documentación sobre el tema.

Ciertamente creo que RMI le dará mejor rendimiento que los servicios web; pero los servicios web probablemente serán más fáciles de mantener y flexibles para los requisitos futuros.

Answer 5

De todos modos, nunca termina el debate. Esta es mi humilde opinión:

• Los servicios web permiten una arquitectura acoplada suelta. Con RMI, debe compilar todo incluso si hubo un cambio mínimo (debido a los UUID de serie de la clase y lo que sea).
• WS permite una coexistencia más fácil con otros componentes de la empresa (ESB, SSO, gestión de identidad, equilibrio de carga, filtros de seguridad, certificados de seguridad), ya que HTTP es el protocolo de red subyacente.
• La reflexión en RMI (y en EJB) parece ser más costosa que el protocolo HTTP en sí.

Si usted está pensando en EJB como más conveniente para el ambiente servidor de aplicaciones y más facil de comparar con WS y CORBA según su artículo, (EJB soporta la gestión de transacciones, gestión de frijol; SW tienen WS + extensiones (seguridad, transacciones)) :

• EJB son más lentos que WS según el artículo: Remote EJB is 3x slower than WebService in 7.1
• EJB al compilar/edificio que tuvimos que usar exactamente la misma versión del servidor de aplicaciones incluyendo parches en dev y la producción para evitar la producción de dudosa errores de tiempo de ejecución (esto solo parece fácil: el equipo de producción (centro de datos) no siempre es sa y qué parche tienen, cuando hacemos correcciones para la aplicación siempre tenemos que volver a pedir la versión exacta del servidor).
• Las correcciones parciales de la aplicación no son tan sencillas, si EJB se reconstruye debido a una pequeña corrección, las jarras del cliente deben reconstruirse, por lo tanto, las aplicaciones que usan tarros del cliente deben volver a implementarse.

(Estos eran los problemas de mi experiencia, tal vez otras personas eran más suerte)

llego a la conclusión de que WebServices son más flexibles, utilizan menos reflexión, y es de esperar más rápido si se diseñan cuidadosamente. Si RESTful se utiliza en el controlador MVC como resultado, ESB puede ayudar tanto con la oferta de transformaciones (menos código, solo transformación) como con inyección de seguridad directamente en encabezados HTTP (por ejemplo, ivheader, ivgroup - si se usa ibm web seal, Tivoli access manager). El uso de SAML XACML solo es posible cuando se usa WS, ya que las aserciones funcionan con XML. Por lo tanto, para las aplicaciones empresariales distribuidas y dislocadas, WS es más flexible debido a lo mencionado anteriormente.

El artículo que refiere dice que WS no tiene transacciones sino solo propuestas. El artículo es incorrecto o demasiado viejo. Ver OASIS WSAT 1.0 and WSAT 2.0. Microsoft, JBoss, Oracle y algunos otros soportan la tecnología de forma inmediata en sus servidores de aplicaciones. Apache Metro parece apoyar que estaba bien (por favor verifique).

Answer 6

RMI es básicamente para pequeñas aplicaciones. Sí, es más rápido, pero con el tiempo sentirá que para hacer más mejoras en su aplicación cuando el tráfico aumenta, el servicio web es más fácil de mantener que RMI y si elige el servicio web RESTFull será la mejor opción.

Gracias