Comunicación Java / Python a través de Message Broker

¿Cuál es una buena solución para la comunicación a través de Message Broker que admite aplicaciones (C) Python y Java / JMS? Mis requerimientos particulares son:

  • solución de código abierto
  • Disponible en sistemas basados ​​en Linux
  • No se requiere cita entre el remitente y el destinatario (es decir, utiliza un intermediario de mensajes)
  • Varios productores y consumidores admitidos para una única cola de eventos (solo un consumidor recibe cada mensaje)
  • Soporte de unidad de trabajo con confirmación en dos fases (es bueno tener soporte XA)
  • Soporte para mensajes persistentes (es decir, que sobreviven al reinicio del intermediario)
  • Soporta JMS para clientes Java
  • Ningún componente es “marginal”, lo que significa que se corre el riesgo de quedarse fuera de mantenimiento debido a la falta de apoyo / interés de la comunidad
  • Si hay un cliente de Python que se las arregla para “hablar JMS” sería increíble, pero una respuesta que incluya una tarea para escribir mi propia capa de Python JMS es aceptable

Me ha resultado sorprendentemente difícil encontrar una solución para esto. ActiveMQ de Apache no tiene soporte de Python fuera de la caja. ZeroMQ requiere una cita. RabbitMQ no parece ser compatible con JMS. El mejor candidato que he encontrado es una combinación de ActiveMQ y la biblioteca pyactivemq. Pero la primera y última versión de pyactivemq fue en 2008, por lo que parece que eso no cumple con mi requisito de “no flecos”.

La respuesta ideal serán los nombres de uno o más paquetes de código abierto bien soportados y bien documentados, que ha utilizado personalmente para comunicarse entre una aplicación Java / JMS y Python, y que no requieren mucho trabajo de integración para obtener empezado. Una respuesta que incluya una implementación “fácil” (hasta unos pocos días de trabajo) de un código de pegamento adicional para cumplir con todos los requisitos anteriores, sería aceptable. Una solución comercial, en ausencia de un buen candidato de código abierto, también sería aceptable.

Además, Jython está fuera. (Si solo pudiera …) Las mismas aplicaciones de Python necesitarán usar módulos solo disponibles en CPython.

    Me ha resultado sorprendentemente difícil encontrar una solución para esto. ActiveMQ de Apache no tiene soporte de Python fuera de la caja.

    Los corredores ActiveMQ son totalmente compatibles con el uso del protocolo Stomp fuera de la caja. Stomp es un protocolo basado en texto para mensajería que tiene clientes para muchas plataformas e idiomas.

    La documentación de ActiveMQ debe contener información sobre cómo configurar un conector para stomp. En su forma más simple, habilitar un conector sería algo así como:

       

    Una vez habilitado en el lado del agente, puede usar cualquier biblioteca de Python que admita stomp. Luego puede usar Stomp en el lado de Python y JMS en el lado de Java para comunicarse con el agente y enviar / recibir desde destinos específicos.

    JMS es una especificación no implementación. RabbitMQ es una opción realmente.

    También con mucho gusto he utilizado HornetQ http://www.jboss.org/hornetq de Jboss, ya que con cada cosa está más alineada con Java EE, pero RabbitMQ sería una elección especial si usted también está usando Spring

    Es posible que desee echar un vistazo a OpenAMQ y otra mirada a RabbitMQ .

    La tecnología de mensajería subyacente utilizada por RabbitMQ y OpenAMQ es AMQP . Debería poder encontrar fácilmente clientes Python y Java que funcionen contra estos dos corredores (y aparentemente cualquier otro agente que cumpla con las especificaciones).

    Si es necesario tener JMS, es posible que pueda encontrar un cliente JMS implementado en la parte superior de AMQP (OpenAMQ proporcionó dicho cliente al mismo tiempo, pero no estoy seguro de su estado actual).

    Habíamos estado usando GlassFish Message Queue (anteriormente Sun Java MQ) – se hereda de OpenMQ

    Satisface la mayoría de sus requisitos, si no todos. Habíamos estado utilizando intermediarios en clúster en Red Hat Linux (RHEL), es confiable para uso intensivo. Aunque algunas ‘peculiaridades’ se esconden aquí y allá.