Cross Language Messaging

Question

Utilizamos una herramienta centrada en Java que utiliza JMS tanto internamente como para comunicarse con el software java externo. Ahora tenemos que configurar una nueva interfaz para una aplicación C#. Nuestro proveedor de JMS proporciona una implementación de C# que debería funcionar, pero no estoy del todo seguro de que JMS sea el camino a seguir en este caso. Introducirá una nueva dependencia específica del proveedor en una aplicación C# tanto para los detalles de la implementación como para el soporte del cliente.

Algunos google me llevaron a STOMP que parece ser un protocolo establecido de nivel de cable soportado por múltiples intermediarios de mensajes con capacidad JMS (hornetq, activemq, ...) pero parece que hay una clara falta de clientes reales en C# (y Java en cierta medida). Sin profundizar demasiado, tampoco estoy del todo seguro de dónde entra en juego el énfasis en "Texto". ¿No es compatible con objetos binarios?

Otra solución podría ser AMQP, que es otro protocolo de nivel de cable pero la especificación 1.0 aún no se ha lanzado y estamos cansados ​​de implementar la especificación de 0.9.1 de 4 años porque parece que ha cambiado mucho en 1.0.

¿Qué solución sería el mejor para inter-idioma de mensajería asíncrona teniendo en cuenta la seguridad, el apoyo, transaccionalidad, normas compliancy, portabilidad, ... Tenga en cuenta que el jabón con el WS adecuada * no es una opción para esta interfaz en particular.

EDIT1: he visto a preguntas como Cross-platform, cross-language messaging system? pero parecen centrarse en una herramienta específica que funciona en múltiples idiomas. De hecho, estoy buscando un protocolo compatible con los estándares que sea implementado por múltiples proveedores.

Answer 1

Una opción sería la de abstraer el C# cliente del protocolo de notificación específica subyacente y dejar que funcione a nivel de puertos de entrada y fuera de los puertos donde en los puertos y fuera de los puertos se implementan con adaptadores de interoperabilidad comunes - una base de datos relacional, un servicio web, un archivo xml en una carpeta específica.

es su responsabilidad de proporcionar adaptadores y un puente entre los adaptadores y su subsistema de mensajería pero hay beneficios claros: la obligación mutua entre los entornos empresariales se define a nivel muy común. Incluso puede reemplazar el subsistema de mensajería algún día y conservar todos sus puertos de entrada y salida. En otras palabras, el C# cliente no se daría cuenta de que se ha sustituido JMS con otra infraestructura de mensajería, ya que todavía envía/recibe los datos desde el mismo conjunto de adaptadores.

Answer 2

No sé si entendí su pregunta correctamente, pero RabbitMQ es una implementación de AMQP y tiene enlaces para C# y Java.

Para evitar "una nueva dependencia específica del proveedor en una aplicación C#", es posible que desee echar un vistazo al Messaging Component in the Spring.Net framework, así como a su proyecto related AMQP for .Net. Esto le permite tener las POCO y la lógica de negocios separadas del middleware y la infraestructura de mensajería.