una que puerto programa introduccion hilos ejercicio ejecutar con aplicacion java jms rmi rpc master-slave

que - ¿Qué es un buen mecanismo de comunicación basado en Java Master-Slave?



que es una aplicacion rmi (11)

Bueno, sugiero JMS si buscas algo basado en Java. Tiene todas las características que busca más un servidor de aplicaciones sólido como JBoss. Sin embargo, otra opción que no está completamente basada en java y no está utilizando colas estaría usando el protocolo HTTP y JAXB (servicios web RESTful). Esta es una manera muy ligera de comunicarse entre dos lados. Sus objetos se transformarían a XML mediante el uso de JAXB, y se transferirían al otro lado, y luego lo vuelve a convertir en objeto una vez que lo recibe.

Estoy creando una aplicación Java que requiere comunicación maestro-esclavo entre las JVM, posiblemente residiendo en la misma máquina física. Habrá un servidor "maestro" ejecutándose dentro de un servidor de aplicaciones Java EE (es decir, JBoss) que tendrá clientes "esclavos" conectados a él y se registrará dinámicamente para la comunicación (es decir, el maestro no sabrá las direcciones IP / puertos del servidor). esclavos por lo que no se pueden configurar de antemano). El servidor maestro actúa como un controlador que repartirá el trabajo a los esclavos y los esclavos responderán periódicamente con notificaciones, por lo que habría comunicación bidireccional.

Originalmente pensaba en sistemas basados ​​en RPC donde cada lado sería un servidor, pero podría complicarse, así que prefiero un mecanismo donde haya un socket abierto y hablen de un lado a otro.

Estoy buscando un mecanismo de comunicación que sea de baja latencia donde los mensajes serían principalmente tipos primitivos, por lo que no es necesaria una serialización seria. Esto es lo que he visto:

  • RMI
  • JMS: integrado en Java, los clientes "esclavos" se conectan a la ConnectionFactory existente en el servidor de aplicaciones.
  • JAX-WS / RS: Tanto el maestro como el esclavo serían servidores que exponen una interfaz RPC para comunicación bidireccional.
  • JGroups / Hazelcast: Utilice estructuras de datos distribuidos compartidos para facilitar la comunicación.
  • Memcached / MongoDB: Utilícelos como "colas" para facilitar la comunicación, aunque los clientes tendrían que hacer una encuesta para que hubiera algo de latencia.
  • Thrift: Esto parece mantener una conexión persistente, pero no está seguro de cómo integrar / integrar un servidor Thrift en JBoss
  • WebSocket / Raw Socket: esto funcionaría, pero requeriría mucho más código personalizado del que me gustaría.

¿Hay alguna tecnología que me esté perdiendo?

Editar: También miró a:

  • JMX: haga que el cliente se conecte al servidor JMX de JBoss y reciba notificaciones JMX para comunicaciones bidireccionales.

Dependiendo de sus requisitos, puede encontrar que Raw Socket tiene menos código que otros enfoques. Sin duda tendrá la menor latencia. Puede reducirlo a unos 20 microsegundos en el bucle de retorno.

Cuantos más requisitos tenga, más probabilidades tendrá de encontrar una solución de alto nivel. Sin embargo, si todo lo que desea es algo liviano, los enchufes en bruto pueden ser los más simples.

Es posible que desee echar un vistazo a Activatable. Si los esclavos están respondiendo cuando el trabajo está completo, entonces rmi y Activatable podrían ser una buena solución en este caso. Si utiliza el rmiregistry en el controlador, todos los esclavos pueden registrarse fácilmente en el controlador, y estos pueden activarse cuando sea necesario.

Honestamente, me quedaría con JMS. Tienes una cola de la que tus esclavos pueden recibir mensajes, y una cola en la que los vuelven a colocar. Puede establecer propiedades sobre quién procesó cada mensaje (para contabilidad) directamente en el sobre. Obtiene persistencia con muchos proveedores de J2EE (glassfish, jboss).

Además, puede pasar fácilmente a JVM distribuido de múltiples servidores sin necesidad de programación adicional.

Sin embargo, puede que no se ajuste a la definición de "baja latencia" en algunos casos.

Para Thrift puede usar TServlet como el punto de entrada para su servicio Thrift. Lo que describiste, aunque suena como un problema más a resolver con activemq o zookeeper.

Si busca rendimiento y ambas aplicaciones son java, sin un firewall en medio, entonces puede excluir inmediatamente todos los protocolos basados ​​en XML. Si la comunicación es sincrónica (el maestro espera a que el esclavo complete el trabajo), use RMI, de lo contrario, JMS. También puede utilizar TCP directamente para obtener el máximo rendimiento. Si hay muchos esclavos que reciben el mismo mensaje, puede buscar en kits de herramientas de comunicación de grupo como JGroups o Spread (más rápido pero no 100% java). En última instancia, es posible que otras personas ya hayan creado lo que intentas construir. Echa un vistazo a Gridgain.

También puede consultar Mule. Siento que es la solución perfecta para su problema.

También puede echar un vistazo al proyecto Redisson que tiene publicación / suscripción y otras estructuras de datos distribuidos compartidas para sus necesidades.

Tenemos una aplicación similar, y solo usamos Servlet en JBoss con "esclavos" que lo golpean de manera temporizada. Esto está bien, pero no es óptimo para baja latencia.

Ahora estamos buscando en Netty. Puedes usar el protocolo que quieras usar ... Probablemente usaremos HTTP y JAXB. Supongo que esto podría categorizarse como "WebSocket / Raw Socket", pero es mucho mejor que usar uno sin procesar ...

WebSockets le ayudará con la comunicación entre el servidor web y el cliente, no entre dos JVM. Si de hecho eso es lo que desea, http://fermiframework.org proporciona un RMI de java a JavaScript (de servidor a cliente).