WebSphere MQ mit JMS

Ich habe eine Anwendung, die WebSphere MQ Java API zusammen mit einer Konfigurationsdatei (xml) für den Zugriff auf MQ verwendet. Ich möchte auf die WebSphere JMS API migrieren. Dazu versuche ich 1) WebSphere MQ Warteschlange Verbindung Fabrik und 2) WebSphere MQ Warteschlange Destinationen von meinem lokalen WAS. Wenn ich meine Warteschlangenziele konfiguriere und versuche, meine MQ Config-Parameter einzustellen, erhalte ich eine Fehlermeldung wie "WMSG0316E: Sie haben versucht, eine Warteschlange anzuzeigen, die keine lokale Warteschlange war. Es wird nur die Verwaltung lokaler Warteschlangen unterstützt."WebSphere MQ mit JMS

Die Botschaft ist richtig in dem Sinne, dass ich an eine entfernten Warteschlange zu verbinden versuchen. Kann ich jetzt meinen WAS nicht als MQ-Client konfigurieren, der versucht, sich mit einer Remote-Warteschlange zu verbinden? Der MQ-Client verfügt über die erforderlichen MQ-JMS-JAR-Dateien im Klassenpfad des Servers.

Würde mich freuen, wenn jemand etwas Licht in dieses werfen könnte.

Quelle

2009-05-25 Subramanian

Ich arbeite an dem gleichen Problem - Ich habe Artikel gefunden, wo die Autoren bestätigen, dass WebSphere muss gesagt werden, dass "Client zu Remotewarteschlange" -Modus gewünscht wird, aber ich habe noch Details zu finden, wie zu tun dass über einen Autor eine Umgebungsvariable erwähnt wird.

Noch auf der Suche ... Ich werde die Lösung posten, wenn ich eine finde.

Quelle

2010-02-14 00:48:16

Die Lösung bestand darin, die Einstellung "Transport type" in der JMS-Warteschlangenverbindungs-Factory-Konfiguration auf "client" statt auf "Bindings" zu setzen.Dieser befindet sich in der WAS-Admin-Konsole unter "Ressourcen" -> "JMS-Provider" -> "WebSphere MQ" -> "Zusätzliche Eigenschaften". Dort befindet sich ein "WebSphere MQ Queue Connection Factories" -Element, mit dem Sie zu einem Liste Ihrer Warteschlangenverbindungsfactorys. In der von Ihnen verwendeten Warteschlange (wie in Ihren Listener-Port-Einstellungen angegeben) befinden sich die zu ändernden Einstellungen. Hope this hilft, Matt –

Sie können es auch wie MQQueueConnectionFactory sehen cf = new MQQueueConnectionFactory(); cf.setTransportType (JMSC.MQJMS_TP_CLIENT_MQ_TCPIP); // Client-Modus – jim

Ich schneide & Ihre Fehlermeldung in Google eingefügt. In ihrem unnachahmlichen Stil sind here die IBM Dokumente zu Ihrem Problem. Hilfreich, nein?

Wo haben Sie die Warteschlange eingerichtet, die Sie kontaktieren möchten? Wird es auf demselben Server ausgeführt wie die WebSphere-Instanz, auf der Sie die Bereitstellung durchgeführt haben, oder handelt es sich um einen Remoteserver? Wenn es Letzteres ist, frage ich mich, ob Sie eine Bridge oder einen Proxy benötigen, damit Sie die Nachricht scheinbar lokal senden, aber auf dem Remote-Server über einen Proxy anzeigen lassen können.

UPDATE: Ich weiß es nicht, aber eine Möglichkeit, dies zu umgehen, ist, eine lokale Warteschlange einzurichten, ähnlich wie Sie es nennen, und einfach alle Nachrichten an die ferne Warteschlange weiterleiten.

Quelle

2009-05-25 12:00:18 duffymo

Der MQ wird auf einem Remote-Server ausgeführt. Dies ist, wo ich stecke - "..erscheint, um die Nachricht lokal zu senden .." Ich habe versucht, MQ 6 und WAS auf dem gleichen System zu installieren, und das JMS hat gut funktioniert. Wenn sich MQ jedoch in einem Remote-System befindet, dessen IP-Adresse ich beim Konfigurieren von JMS-Ressourcen angeben, erhalte ich diese Ausnahme. – Subramanian

Können Sie etwas klären. Sie sagen, dass Sie die Verbindungsfactory und das Warteschlangenziel von Ihrem lokalen WAS erstellen. Meinst du, du konstruierst die Objekte selbst?

Wenn dies der Fall ist, sollten Sie die Ressourcen als Teil Ihrer Anwendungskonfiguration konfigurieren und dann über JNDI nachschlagen. In der Konfiguration sind die lokalen JMS-Ressourcen an die tatsächliche Implementierung gebunden, in Ihrem Fall an den Remote-MQ-Server. Ihr Code sollte nur an JMS gebunden sein, nicht an die spezifische Implementierung.

Quelle

2009-05-25 13:39:21 Robin

Ich "konfiguriere" WebSphere JMS-Ressourcen, nämlich die MQ-Warteschlange ConnectionFactory und das MQ-Warteschlangenziel in WAS. Der Code ist nur an JMS gebunden und nicht an die Implementierung - das war ein sehr wichtiger Grund, diese Änderung vorzunehmen. Ich baue die Objekte nicht selbst. Entschuldigung für den Wortlaut - "create" - wenn das etwas Verwirrung verursacht hat. – Subramanian

@Subramanian - Das Problem lag eher in der Verwendung von MQ bei der Verwendung von JMS-Ressourcen. (d. h. MQ Queue ConnectionFactory statt Queue ConnectionFactory). Ich dachte, dass Sie sich auf MQ-spezifische Artefakte anstelle von JMS bezogen haben. – Robin

Antwort

Verwandte Themen