¿Alguien sabe si es factible escribir Cliente genérico JMS - es decir. uno que funciona con JMS de diferentes proveedores (por ejemplo, Sonic, IBM SIB, Jboss, etc.)?Cliente JMS genérico
Cada vez que escribo el código de cliente JMS siempre es muy específico de la implementación con JAR dependientes y clases de contexto.
Gracias.
Bueno, una de las mejores prácticas (al menos para mí) es usar el no-arg InitialContext constructor y poner cosas específicas del proveedor (como la fábrica de contexto inicial y la URL del proveedor) en un archivo jndi.properties en la ruta de clase en lugar de Codificando estas cosas. También deberá colocar los JAR del proveedor JMS "correcto" en la ruta de la clase. En otras palabras, puede tener un código genérico pero aún necesita configurar el entorno de ejecución (a menos que ejecute su código de cliente en un contenedor como Spring).
Esto es para lo que Spring es. Tendrás una implementación específica del proveedor, pero el código debería ser el mismo. Consulte 19.6 JMS y 21. JMS (Java Message Service) del Spring 3.0 Reference.
2 buenas respuestas, pero me gustaría añadir un poco de explicación. JMS es un estándar API, no define el protocolo de conexión al servidor. Por lo tanto, todas las implementaciones de JMS tienen diferentes protocolos de cableado; por lo tanto, siempre necesitará los JAR específicos del proveedor. Es imposible crear una biblioteca de cliente JMS que sea compatible con todos los proveedores de JMS.
En su código fuente, debe evitar las características específicas del proveedor (por ejemplo, TIBCO EMS le permite acceder a destinos que no tienen JNDI, nombres nativos y tiene modos de confirmación personalizados). Si siempre usa las búsquedas JNDI, solo la URL JNDI y el nombre de la fábrica de contexto inicial serán específicos para el tipo de servidor.
Para cualquier persona que busca un cliente genérico en el futuro, probar HermesJMS que viene con plugins para los principales proveedores de JMS (ActiveMQ, WebSphere MQ, etc.)