JMS comerciales / implementaciones de MOM con soporte al cliente no Java?

Question

Hasta ahora he visto soporte al cliente no sólo para Java de código abierto como Apache intermediarios de mensajes ActiveMQ, JBoss HornetQ y Open Message Queue (OpenMQ).

¿Hay también productos de código cerrado como WebSphere, WebLogic o Tibco que ofrecen acceso no Java a sus corredores de MOM, utilizando un protocolo de conexión documentado (frente a una biblioteca de cliente binario de código cerrado) que permite a los clientes de escritura en otra idiomas?

Esto es cada vez más interesante como productos (como WebLogic) están disponibles en el (EC2) de nube para que los desarrolladores pueden utilizar la instancia de la nube para desarrollar y probar una aplicación cliente sin la necesidad de adquirir e instalar la versión completa.

Answer 1

No tengo una respuesta definitiva porque me especializo en WMQ exclusivamente. Sin embargo, creo que la respuesta es "no" en su mayor parte. (Más sobre esto en un minuto.)

En cuanto a WMQ IBM hace que los puntos de salida disponibles para adaptar el comportamiento de los canales, llamadas a la API y autorizaciones. Las salidas están muy bien documentados y realizan funciones estrechos dentro del alcance de una acción particular - es decir, recibe un mensaje, iniciar una conexión, etc. Estos están escritos en C y, más recientemente, Java. En la mayoría de estos son utilizados y los clientes que hablan citar general complejidad. Ellos quieren algo personalizable a través de la configuración y no a través de código de bajo nivel. Sospecho otros proveedores de MOM experimentan requisitos similares de los clientes.

¿Qué tiene esto que ver con su pregunta? Mi opinión sobre esto es que si los clientes son reacios a código de arriba salidas con funciones limitadas, parece muy improbable que iban a codificar hasta un cliente con todas las funciones y robusto que permite la entrega fiable de mensajes, de uno y confirmación en dos fases, cliente- salidas laterales, diagnósticos, y toda la otra funcionalidad que los canales WMQ proporcionan.

Si se asume que esta tarea se llevó a cabo por un equipo de código abierto capaz de ese nivel de código, que lo apoyaría? Actualmente el MOM vendedores proporcionar soporte de extremo a extremo cuando se utilizan sus clientes propietarios. La noción de cómo un ticket de problema podría resolverse cuando se utiliza un cliente de terceros que es apoyado por la comunidad es un poco de miedo a muchos clientes. Por ejemplo, IBM proporciona complementos para WMQ llamados SupportPacs. Aunque hay SupportPacs que son totalmente compatibles y se consideran extensiones de productos, algunos de los SupportPacs están dentro como está. Muchos de mis clientes no se ejecutará como está el código incluso cuando es suministrado por el proveedor .

Por último, existe la noción del contrato interfaz. WMQ soporta unos verbos con una gran cantidad de opciones. El protocolo de canal subyacente es mucho más compleja. Cuando WMQ v7 salió, los canales tenían una considerable nueva funcionalidad y puesta a punto. esto fue posible a esta escala debido a que los componentes internos no están expuestos a los clientes de IBM y así fue capaz de hacer cambios masivos sin temor a consecuencias negativas para los clientes de 3 ª parte. La exposición de todo eso crearía dependencias de una orden o dos magnitud mayores que existen con sólo la API expuesta.

Por lo tanto, según mi teoría (no pretendo hablar en nombre del equipo de desarrollo MQ aquí) los grandes proveedores de MOM tienen un interés personal en no exponer sus protocolos de canal para desarrolladores independientes. La nueva arruga aquí es AMQP la que he aludido anteriormente. Se define el protocolo de alambre y permite a cada proveedor para código de un producto compatible. Aunque esto proporciona la oportunidad para que usted describe soluciones de código abierto, la capacidad de cualquier aplicación para mejorar el producto está limitada por el hecho de que ellos no son dueños del protocolo. Por el momento, aunque no espero que encontrará alguno de los grandes proveedores de MOM que exponen sus protocolos de alambre para el desarrollo tercera parte. Dicho esto, esto es sólo una suposición, y si estoy equivocado, estoy seguro de que alguien aquí va a saltar en y dar el ejemplo contrario.