SOAP Web services vs RMI

Hace tiempo que abandone el «Mantra Web services para todo«, y me horrorizo al escuchar a los que piensan que RMI es cosa del pasado, aunque reconozco que a menudo es fácil tomar la decisión y elegir SOAP, en ocasiones la elección no es tan clara.

Dejo aquí mis criterios para elegir:

– Si algunas de las aplicaciones que se van a integrar no son Java, evidentemente la opción RMI se elimina, ya que salvo casos excepcionales, si soy de los que piensan que RMI/IIOP es cosa del pasado.

– Si el rendimiento, la eficiencia y los tiempos de respuesta son una preocupación, a falta de tener en cuenta otros criterios, RMI es la mejor opción. A modo de ejemplo, nuestra plataforma de Formularios ( Formul@) ofrece ambas implementaciones, y la implementación RMI es un orden de magnitud mas rápida que su homóloga SOAP. En en un bucle de 1000 iteraciones, el cliente basado en web services tardo en promedio un total de 10186ms en renderizar los formularios, mientras que la versión basada en RMI tardo de media 946ms.

– Si ambas aplicaciones son Java y ademas se ejecutan en la misma máquina o subred, la opción RMI es sin duda mi preferida.

– Si se pretende construir o evolucionar en el futuro a un ambiente SOA, aunque SOA no descarta RMI (la mayoría de los ESBs lo contemplan), la mejor opción es implementar un servicio basado en Web Services.

– Si las aplicaciones son desarrolladas por diferentes proveedores, la opción sería Web Services, ya que el desarrollo «primero contrato» se hace imprescindible.

– En otro caso, utilizo mi moneda de la suerte para decidir :), aunque la moneda suele tiene en ambas caras «Web Service».

Comentarios

  1. Hola Félix:
    Recientemente he trabajado en un proyecto aplicando los principios de una «filosofía» SOA y hemos tenido que pasar por el mismo punto, qué opción elegir para implementar nuestros servicios y conseguir la interoperabilidad deseada.

    Cuidado con los resultados que arrojas porque pueden provocar malos entendidos. Cuando uno hace pruebas de benchmarking debe indicar las condiciones de entorno y el objetivo de las pruebas.

    Y sobre elegir RMI cuando las dos aplicaciones son JAVA y se van a desplegar con la misma JVM, ¿no crees que sería mejor JMS?

    Un saludo

  2. Bueno mi objetivo no es hacer ningún benchmarking sobre RMI, ni sobre SOAP, de esos hay cientos en la web. Este mini articulo es solo una nota rápida para elegir, basada en un caso real, solo eso.

    Respecto a si JMS sería mejor opción, JMS tiene muy poco que ver con lo que hablo en el articulo, no es comparable a protocolos como RMI o SOAP. De hecho la mayoría de las implementaciones JMS se basan en RMI, y a su vez la mayoría de los ESBs utilizan JMS internamente.

    Antes de que las pilas Web Services implementadas en Java tuviesen un soporte decente para las invocaciones asíncronas, JMS era la opción para implementar aplicaciones distribuidas que se comunicaban de forma asíncrona.

    A estas alturas, salvo excepciones alejadas de lo que solemos desarrollar, JMS no debería ser una opción, y desde luego en el caso de desplegar dos aplicaciones en la misma JVM, JMS es la peor opción de todas las imaginables.

  3. Hola Félix:
    Tu objetivo no sería hacer una prueba de benchmarking, sin embargo, has proporcionado un dato nada riguroso, sólo eso. Insisto en que cuando uno hace una prueba benchmarking debe proporcionar el objetivo de la prueba y las condiciones de entorno.

    ¿Qué poco tiene que ver JMS? Eso es muy discutible. Sin embargo, en el caso que has comentado sobre que dos aplicaciones se ejecuten sobre la misma JVM, usa como transporte la máquina virtual, verás los resultados de rendimiento. Ojo, si eso es lo que buscas.

    Un saludo

  4. Decididamente estamos hablando de cosas muy distintas, y a niveles muy distintos. Ni era un benchmarking, ni pretendía hablar de JMS, que hace algunos años que no utilizo, y la última vez que lo hice (programando agentes usando ActiveMQ) me resulto demasiado pesado, débil ante errores de comunicación y complejo.

    Por otro lado tienes razón en lo que dices, si las aplicaciones se comunican de forma asíncrona, se ejecuten o no sobre la misma JVM, JMS podría ser una opción muy eficiente.
    Aunque en el caso de dos aplicaciones sobre la misma JVM, salvo casos excepcionales, JMS me sigue pareciendo una opción muy forzada, y mi intención no era hablar de todas las posibilidades REST, COBOL, JMX, JMS, …, solo ayudar a elegir entre SOAP y RMI.

    PD: Para que queden mas claros los criterios, he actualizado el artículo para referirme a máquina hardware y no a JVM, ya que para comunicar dos procesos que se ejecutan en la misma JVM rara vez es necesario recurrir a mecanismos complejos como SOAP, RMI, JMS, etc…

  5. Hola Félix:
    Espero que no lo fuera porque de serlo no tendría valor alguno, simplemente sería válido si se tiene en cuenta como referencia en el caso concreto en el que lo estás realizando. De ser así, no entendería que lo hicieras público.

    Evidentemente, si cambias lo publicado inicialmente, el discurso también debería variar.

    Un saludo

  6. bueno para mi todos estos comentarios son bievenidos al fnal de mi investiagcion hare mi opinion personal pero cada uno tiene su parte buena y mala

Comments are closed.