WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Beispielszenarios für die Proxy-Servlet-Konfiguration

Je nach der Konfiguration, in der das Proxy-Servlet implementiert wird, muss es unterschiedlich konfiguriert werden.

Die Proxy-Servlet-Konfiguration hängt von der Implementierung ab, in der das Proxy-Servlet verwendet wird. In den folgenden Abschnitten werden einige häufig vorkommenden Szenarios und die erforderlichen Proxy-Servlet-Konfigurationsparameter beschrieben.

Szenario 1: Der Web-Servlet-Container befindet sich auf demselben Server wie WebSphere Message Broker

In diesem Konfigurationsbeispiel müssen die folgenden Proxy-Servlet-Konfigurationsparameter konfiguriert werden:

  • Legen Sie für useClientMode den Wert false fest.
  • Setzen Sie useQueueManagerDataInsteadOfConfigFile auf "".
  • Legen Sie für configFile die Speicherposition der Konfigurationsdatei fest.

Das Servlet ruft den Namen des Warteschlangenmanagers aus der Konfigurationsdatei ab und versucht dann, eine Verbindung zu diesem Warteschlangenmanager herzustellen.

Szenario 2: Der Web-Servlet-Container befindet sich auf einem anderen Server als WebSphere Message Broker mit einer WebSphere MQ-Clientverknüpfung zum Warteschlangenmanager des Brokers

In diesem Konfigurationsbeispiel müssen die folgenden Proxy-Servlet-Parameter konfiguriert werden:

  • Legen Sie für useClientMode den Wert true fest.
  • Definieren Sie für useQueueManagerDataInsteadOfConfigFile den Wert * oder den Namen des Warteschlangenmanagers des Brokers.
  • Legen Sie für clientModeHostname, clientModeChannelName und clientModePortNumber die korrekten Werte fest, wie im Abschnitt Konfigurationsparameter des Proxy-Servlets beschrieben.

Das Servlet versucht, für den Broker eine Verbindung zum fernen WS-Manager herzustellen und liest dabei die erforderlichen Daten der Knotenkonfiguration aus dem Broker über die WebSphere MQ-Clientverbindung. Damit die Verbindung erfolgreich hergestellt werden kann, muss der Listener 'SYSTEM.DEFAULT.LISTENER.TCP' im fernen Warteschlangenmanager gestartet werden.

Anmerkung: Sie können die Konfigurationsdatei vom Brokerserver auf den Web-Servlet-Container-Server kopieren und dann folgende Proxy-Servlet-Konfigurationsparameter festlegen:
  • Legen Sie für configFile die Speicherposition der Konfigurationsdatei fest, die Sie vom Brokerserver kopiert haben.
  • Setzen Sie useQueueManagerDataInsteadOfConfigFile auf "", damit das Servlet gezwungen ist, die Konfigurationsdatei zu lesen.

Danach müssen Sie jedoch die Konfigurationsdatei jedes Mal kopieren, wenn sie durch den Broker geändert wurde.

Szenario 3: Der Web-Container befindet sich auf einem anderen Server als WebSphere Message Broker mit einem eigenen WS-Manager und einer WebSphere MQ-Kanalverbindung zum Warteschlangenmanager des Brokers

Dieses Konfigurationsszenario ähnelt dem Szenario 1, da der Clientmodus nicht verwendet wird; es müssen jedoch die folgenden Proxy-Servlet-Konfigurationsparameter festgelegt werden:

  • Legen Sie für useClusterMode den Wert true fest.
  • Legen Sie für clusterModeQueueManagerName den Warteschlangenmanager des Web-Servlet-Containers fest.
  • Legen Sie für clusterModeReplyToQ eine Warteschlange auf diesem Warteschlangenmanager fest.

Das Servlet versucht, die Warteschlange 'SYSTEM.BROKER.WS.INPUT' im angegebenen Warteschlangenmanager zu öffnen und verwendet dabei den Namen des WS-Managers aus der Konfigurationsdatei. Daher müssen Sie zuerst Kanäle und Übertragungswarteschlangen festlegen, um sicherzustellen, dass die Nachrichten im Warteschlangenmanager des Brokers eintreffen.

In diesem Szenario müssen die Konfigurationsdateien aus dem Brokerserver kopiert werden.

Szenario 2: Der Web-Servlet-Container befindet sich auf einem anderen Server als WebSphere Message Broker mit einer WebSphere MQ-Clientverknüpfung zum Warteschlangenmanager des Brokers, verwendet jedoch eine Netzlastausgleichsfunktion, um die Arbeit auf mehrere Broker zu verteilen

Die Konfiguration ist dieselbe wie in Szenario 2, wobei der Brokerserver durch die IP-Adresse der Netzlastausgleichsfunktion ersetzt wird. In diesem Fall können grundsätzlich keine Konfigurationsdateien verwendet werden, da hinter einer virtuellen IP-Adresse mehrere Broker stehen, von denen jeder eine andere Konfigurationsdatei hat. Das Servlet lädt die Informationen jeweils mit einer eigenen Verbindung und nutzt für jeden Broker die richtigen Konfigurationsdaten.

In diesem Konfigurationsbeispiel müssen die folgenden Proxy-Servlet-Konfigurationsparameter konfiguriert werden:

  • Legen Sie für useClientMode den Wert true fest.
  • Definieren Sie für useQueueManagerDataInsteadOfConfigFile den Wert * oder den Namen des Warteschlangenmanagers des Brokers.
  • Legen Sie für clientModeHostname, clientModeChannelName und clientModePortNumber die korrekten Werte fest, wie im Abschnitt Konfigurationsparameter des Proxy-Servlets beschrieben.

Wenn die Failover-Funktion einer der Gründe für die Implementierung dieser Konfiguration ist, wird empfohlen, zusätzlich die folgenden Proxy-Servlet-Konfigurationsparameter zu konfigurieren.

  • Legen Sie für clientModeConnectRetryCount einen Wert fest, der mit der Anzahl der Broker identisch oder höher ist. Mit dieser Einstellung wird sichergestellt, dass ein einzelner fehlgeschlagener Server keine Unterbrechungsfehler verursacht, und zwar selbst dann, wenn die Lastausgleichsfunktion eine einfache Taskzeitzuteilung vornimmt. Das Servlet verwendet immer den ersten verfügbaren Broker.
  • Legen Sie für reconnectActiveLinksAge einen Wert fest, der kleiner als das Firewall-Zeitlimit ist. Mit dieser Einstellung wird die Wiederverwendung alter Verbindungen verhindert, die möglicherweise mittlerweile zwischen dem Servlet und der Lastausgleichsfunktion (bzw. zwischen der Lastausgleichsfunktion und den Brokern) von Firewalls gelöscht wurden.

Sie können für testConnectionBeforeReuse den Wert true festlegen, als eine weitere Möglichkeit zur Handhabung gelöschter WebSphere MQ-Verknüpfungen zwischen dem Web-Servlet-Container und den Warteschlangenmanagern des Brokers. In diesem Fall wird jedoch vor dem Senden von Daten an den Broker ein MQINQ-Aufruf ausgegeben. Wenn der MQINQ-Aufruf fehlschlägt, wird eine neue Verbindung hergestellt und die Daten werden über die neue Verbindung gesendet. Da durch diese Konfiguration bei dem MQPUT- und MQGET-Aufruf zusätzliche Schritte anfallen, erhöht sich der Systemaufwand bei allen Nachrichten beträchtlich. Daher sollte diese Option nur verwendet werden, wenn alle anderen Möglichkeiten ausgeschöpft sind.

Im Abschnitt Proxy-Servlet konfigurieren finden Sie Informationen zum Abschluss der Proxy-Servlet-Konfiguration:

Informationen zu allen Proxy-Servlet-Konfigurationsparametern finden Sie im Abschnitt Konfigurationsparameter des Proxy-Servlets.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:38


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac69431_