Mejor publicación/suscripción "Middleware"

Question

Estoy en el mercado para una buena biblioteca de fuente abierta basada en biblioteca Pub/Sub (patrón de observador). No he encontrado ninguna que me gusta:

• JMS - atada a Java, trata el contenido del mensaje como manchas mudos binarios

• NDDS - $$, el uso de IDL

• CORBA/ICE - Pub/Sub-se construye en la parte superior de la RPC, CORBA API no es intuitiva

• JBOSS/ESB - no demasiado familiarizados con

Sería bueno si un paquete de este tipo podría a lo siguiente:

• red basada

• Conscientes de datos de carga útil, los usuarios no deberían tener que preocuparse por endian/serialización emite

• soporte para múltiples idiomas (C++, ruby, Java, Python sería bueno)

• Sin código generado automáticamente (IDL no!)

• intuitiva de gestión de suscripciones/tema

Para la diversión, he created my own. ¿Pensamientos?

Answer 1

Es posible que desee consultar RabbitMQ.

Answer 2

Utilizamos la implementación RTI DDS. Cuesta $$, pero admite muchos parámetros de calidad de servicio.

Hay una implementación gratuita de DDS llamada OpenDDS, pero no la he usado.

No veo cómo puede evitar la necesidad de predefinir sus tipos de datos si el idioma de destino está escrito de forma estática.

Answer 3

Mire un poco más en las distintas implementaciones de JMS.

La mayoría de ellos no solo son Java, también proporcionan bibliotecas de clientes para otros idiomas.

Suns OpenMQ tiene al menos una interfaz C++, Apache ActiveMQ proporciona bibliotecas del lado del cliente para muchos lenguajes comunes.

Cuando se trata de formatos de mensaje, por lo general, están desacoplados del middleware de mensajes en sí. Podrías definir tu propio formato de mensaje. Puede definir su propio esquema XML y enviar mensajes XML. Puede enviar ASN.1 codificado en BER usando alguna biblioteca de terceros si lo desea. O formatee y analice los datos con una biblioteca JSON.

Answer 4

Puede consultar PubSubHubbub. Es una extensión de Atom/RSS para alow pubsub a través de webhooks. La interfaz es HTTP y XML, por lo que es independiente del idioma. Está ganando cada vez más aceptación ahora que Google Reader, FriendFeed y FeedBurner lo están usando.El caso principal de uso son los blogs y esas cosas, pero por supuesto puedes tener cualquier tipo de carga útil.

La única implementación de código abierto que conozco hasta ahora es this one para Google AppEngine. Dicen que viene soporte para autohospedaje.

Answer 5

Puede que le interese la biblioteca MUSCLE (descargo de responsabilidad: la escribí, por lo que podría ser parcial). Creo que cumple con todos los criterios que especificó.

https://public.msli.com/lcs/muscle/

Answer 6

Existe también OpenSplice DDS. Este es similar al DDS de RTI, excepto que es L GPL!

Comprobar it Salida:

Answer 7

Como se señaló, por un post anterior en este hilo, una de las opciones es OpenSplice DDS que es una implementación de código abierto de la DDS estándar OMG (el mismo estándar implementado por NDDS) .

Las principales ventajas de OpenSplice DDS sobre el otro middleware que está considerando se pueden resumir en:

• Rendimiento
• apoyo para Rich QoS (Persistencia, tolerancia a fallos, puntualidad, etc.)
• datos Centricity (por ejemplo, posibilidad de consultar y flujos de datos de filtrado)

Algo que me gustaría entender es cuáles son sus problemas con IDL. DDS utiliza IDL como una forma independiente del lenguaje de especificar tipos de datos de usuario. Sin embargo, DDS no está limitado a IDL, podría estar usando XML, si lo prefiere. La ventaja de especificar los tipos de datos, y el desacoplamiento su representación de un lenguaje de programación específico, es que el middleware puede:

(1) quitar de que la carga de datos de serialización,

(2) generar muy tiempo/espacio serialización eficiente,

(3) garantizar la seguridad de tipo de extremo a extremo,

(4) permitir el filtrado de contenido sobre todo el tipo de datos (no sólo la cabecera como en JMS), y

(5) enabl e interoperabilidad de cable en los lenguajes de programación (p. Java, C/C++, C#, etc.)

Dependiendo del sistema o la aplicación que esté diseñando, algunas de las propiedades anteriores podrían no ser útiles/relevantes. En ese caso, simplemente puede generar uno, unos pocos, "Tipo DDS", que es el titular de sus datos serializados.

Si piensa en JMS, le ofrece 5 tipos de temas diferentes que puede usar para enviar sus datos. Con DDS puede hacer lo mismo, pero tiene la flexibilidad para definir exactamente los tipos de temas.

Por último, es posible que desee comprobar this blog entry en Scala y DDS para una discusión más larga sobre por qué los tipos y la torsión estática son buenos, especialmente en sistemas distribuidos.

-AC

Answer 8

tres que he utilizado:

• IBM MQ Series - Demasiado caro, difícil de trabajar.

• Tico Rendezvous - (renombrado ahora como EMS?) Era muy rápido, usaba UDP, también se podía usar sin servidor central. Mi favorito pero caro y requiere una tarifa de mantenimiento.

• ActiveMQ - Estoy usando esto actualmente pero me parece que se cuelga con frecuencia. También requiere algunos proyectos portados desde Java como spring.net. Funciona, pero no puedo recomendarlo debido a problemas de estabilidad.

También se utiliza MSMQ en un intento de construir mi propio bar/Sub, pero ya que no maneja fuera de la caja de su pegada escribir una cantidad considerable de código.

Answer 9

IBM Webpshere MQ, y la licencia no es demasiado expansiva si trabaja a nivel corporativo.