¿Qué enfoque remoto para la aplicación Java recomendaría?

Question

Me pregunto cómo es la mejor forma de integrar módulos Java desarrollados como aplicaciones J (2) EE separadas. Cada uno de esos módulos expone las interfaces de Java. Las entidades POJO (Hibernate) se están utilizando junto con esas interfaces Java, no hay objetos DTO. ¿Cuál sería la mejor manera de integrar esos módulos, es decir, un módulo que llama a la otra interfaz del módulo de forma remota?

Estaba pensando en: EJB3, Hessian, SOAP, JMS. hay pros y contras de cada uno de los enfoques.

Gente, ¿cuál es su opinión o su experiencia?

Answer 1

Habiendo incursionado con algunas de las tecnologías remotas y las encontré universalmente desacreditadas, ahora usaría Spring remoting como una abstracción de la implementación. Le permite concentrarse en escribir su funcionalidad y dejar que Spring maneje la parte remota con algunas configuraciones. usted tiene la opción de varias implementaciones (RMI, invocador de HTTP de Spring, Hessian, Burlap y JMS). La abstracción significa que puede elegir una implementación y simplemente cambiarla si sus necesidades cambian. Consulte el SpringSource docs para obtener más información.

Answer 2

Me gustaría ir por SOAP.

JMS sería más eficiente pero necesitaría codificar un bean controlado por mensaje para cada interfaz.

SOAP, por otro lado, viene con muchos kits de herramientas útiles que generarán su definición de mensaje (WSDL) y todos los controladores necesarios (cliente y servidor) cuando se les proporcione un EJB.

Con el jabón puede (pero no es necesario) lidiar con la seguridad del certificado y las conexiones seguras a través de redes públicas. Como el protocolo predeterminado es HTTP sobre el puerto 80, tendrá un mínimo de problemas con los firewalls, etc. SOAP también es ideal para clientes hetrogenious (en su caso cualquier cosa que no sea J2EE) con buen soporte para la mayoría de los lenguajes comunes en las plataformas más comunes.

Answer 3

Si necesita comunicación de red entre aplicaciones solo de Java, Java RMI es el camino a seguir. Tiene la mejor integración, la mayor transparencia y la menor sobrecarga.

Si, sin embargo, algunos de sus clientes no están basadas en Java, probablemente debería considerar otras opciones (RMI de Java en realidad tienen un IIOP-dialecto, lo que le permite interactuar con CORBA, sin embargo - que no recomendaría haciendo esto, a menos que sea para alguna integración de código heredado). Dependiendo de sus necesidades, los servicios web son probablemente su amigo. Si consientes con la carga de red, puedes ir a los servicios web en Hessian.

Answer 4

¿Te refieres literalmente a distancia? ¿Como en correr en un ambiente diferente con diferentes características de disponibilidad? Con los gastos generales de red?

Asumiendo que "sí" mi primer paso sería adoptar un enfoque de servicio, deje de lado la tecnología de invocación por un momento. Solo considere el diseño y el significado de sus servicios. Usted sabe que son relativamente costosas de invocar, por lo tanto, las pequeñas interfaces ocupadas tienden a ser algo malo. Usted sabe que el sistema de servicio puede fallar entre invocaciones, por lo que puede favorecer los servicios apátridas. Es posible que deba volver a intentar las solicitudes después de la falla, por lo que puede favorecer los diseños de servicio idempotentes.

Luego, considere las relaciones de disponibilidad. ¿Puede su cliente trabajar sin el sistema remoto? En algunos casos, simplemente no puede avanzar si el sistema remoto no está disponible (por ejemplo, no puede habilitar al empleado si no puede acceder al sistema de recursos humanos) en otros casos, puede adoptar un "fuego-y-contar" -me-later "filosofía; poner en cola las solicitudes y procesar las respuestas más tarde.

Donde hay una dependencia de la disponibilidad, simplemente parece que exponer una interfaz sincrónica. Puede hacerlo con EJB de SLSB, si todo es Java EE, eso funciona. Tiendo a generalizar esperando que si mis servicios son útiles, los clientes que no sean Java EE también los quieran. Entonces SOAP (o REST) ​​tiende a ser útil. En la actualidad, agregar una interfaz de servicio web a su SLSB es bastante trivial.

Pero mi teoría favorita es que cualquier sistema de TI suficientemente grande termina necesitando comunicaciones aynch: necesita desacoplar las restricciones de disponibilidad.Así que tendería a buscar una relación de estilo JMS. Una fachada de MDB frente a sus servicios, o SOAP/JMS no es demasiado difícil de hacer. Tal enfoque tiende a resaltar los problemas de diseño de caso de falla que probablemente estaban al acecho de todos modos, JMS tiende a hacerte pensar: "¿Supongo que no recibo una respuesta? Supongamos que mi respuesta llega tarde".

Answer 5

El enfoque estándar sería utilizar RMI simple entre los diversos componentes de servicio, pero esto trae problemas de compartir sus interfaces Java y cambios de versiones en su modelo de dominio especialmente si tiene muchos componentes que usan las mismas clases.

¿Realmente está ejecutando cada servicio en una máquina virtual separada? Si estos EJB siempre están hablando entre sí, es mejor que los coloque en la misma VM y evite las llamadas a procedimientos remotos, ya que estos servicios pueden usar sus LocalInterfaces.

La otra cosa que puede morderte es utilizar Hibernate POJOs. Puede pensar que estos son simples POJO pero detrás de escena Hibernate ha estado ocupado con CGLib tratando de hacer cosas como permitir la inicialización lenta. Si estos granos se serializan y se pasan a través de límites remotos, puede terminar con la excepción de Hibernate impar que se obtiene. Personalmente, prefiero crear DTO simples o escribir los POJO como XML para pasar de un componente a otro. Mis colegas darían un paso más y escribirían protocolos de cable personalizados para transferir los datos por motivos de rendimiento.

Recientemente he estado utilizando el ESB de MULE para integrar varios componentes de servicio. Es bastante agradable ya que puedes tener una combinación de RMI, tomas de corriente, servicios web, etc. sin tener que escribir la mayor parte del código de la placa de la caldera.

http://www.mulesource.org/display/COMMUNITY/Home

Answer 6

¿por qué ir con otra cosa que la cosa más simple que funciona algo?

En su caso, suena como EJB3 o JMS, dependiendo de si la comunicación debe ser sincrónica o asincrónica.

EJB3 es el más fácil de construir en la parte superior de RMI con el contenedor que proporciona todas las funciones adicionales que pueda necesitar: seguridad, transacciones, etc. Presumiblemente sus POJO están en un contenedor compartido y por lo tanto pueden pasar simplemente entre EJB, aunque tiendo a pasar objetos de valor yo mismo. El otro beneficio de EJB es, cuando se hace bien, que es el que mejor se desempeña (esa es mi opinión, por cierto ;-).

JMS es un poco más complicado, pero no mucho, y un sistema basado en la comunicación asíncrona ofrece ciertas sutilezas en cuanto a las tareas de paralelización, etc.

La sobrecarga de rendimiento de los servicios web, la configuración adicional inevitable y adicional los puntos de falla hacen que, en mi humilde opinión, no valga la pena a menos que tenga un requisito que obligue su uso. Estoy pensando en la interoperabilidad con clientes que no son de Java o proporcionando datos a partes externas aquí.