Messaging-Provider für eine heterogene Umgebung auswählen

Wenn Ihre vorhandene oder geplante Messaging-Umgebung IBM MQ-Systeme und WAS-Systeme (WebSphere Application Server) enthält, entscheiden Sie, ob Sie den Standard-Messaging-Provider, den IBM MQ-Messaging-Provider oder eine Kombination aus beiden verwenden möchten. Dazu müssen Sie Ihre Messaging-Anforderungen, Ihre Geschäftsumgebung und die Anforderungen der einzelnen Messaging-Anwendungen berücksichtigen.

Informationen zu diesem Vorgang

Für das Messaging zwischen Anwendungsservern, bei dem möglicherweise eine gewisse Interaktion mit einem IBM MQ-System stattfindet, können Sie den Standard-Messaging-Provider oder den IBM MQ-Provider verwenden. Die beiden Provider stehen sich in nichts nach. Die Auswahl des Providers richtet sich hauptsächlich nach Faktoren, die sich auf Ihre Geschäftsumgebung und die geplanten Änderungen an dieser Umgebung beziehen, und danach, welche Aktionen die einzelnen JMS-Anwendungen ausführen müssen. Darüber hinaus schließen sich diese beiden Typen von Messaging-Providern nicht gegenseitig aus.

  • Sie können beide Providertypen in derselben Zelle konfigurieren.
  • Verschiedene Anwendungen können entweder denselben oder verschiedene Provider verwenden.

Im folgenden sind verschiedene Faktoren aufgelistet, die sich auf Ihre Geschäftsumgebung beziehen:

  • Messaging-Anforderungen
  • Vorhandenes Qualifikationsprofil
  • Vorhandene Messaging-Infrastruktur
  • Geplante Änderungen an dieser Infrastruktur

Die Konfiguration und Verwaltung Ihrer Messaging-Infrastruktur ist einfacher, wenn Sie einen einzigen Provider verwenden. Wenn das Messaging hauptsächlich in IBM MQ stattfindet, sollten Sie eher den IBM MQ-Messaging-Provider auswählen. Analog sollten Sie eher den Standard-Messaging-Provider auswählen, wenn das Messaging hauptsächlich in WebSphere Application Server stattfindet.

Wenn Ihre Geschäftsumgebung keine klaren Vorgaben bezüglich der Beschränkung auf einen einzigen Provider macht, können Sie eine Kombination der beiden Provider verwenden und für jede Anwendung den am besten geeigneten Provider auswählen. Es empfiehlt sich, die Zieltypen (Service Integration Bus, IBM MQ-Warteschlange oder -Topic) anzugeben, die von der Anwendung verwendet werden. Wenn die Anwendung nur Busziele verwendet, bietet sich die Verwendung des Standard-Messaging-Providers (Lösung "Standard-Messaging-Provider") an. Wenn die Anwendung mit einem oder mehreren IBM MQ-Zielen kommunizieren muss, können Sie je nach Geschäftsumgebung, Einsatzszenario und Systemtopologie eine der folgenden Lösungen auswählen:
  • Verwenden Sie den IBM MQ-Provider (Lösung "MQ-Provider").
  • Verwenden Sie den Standard-Messaging-Provider, um einen IBM MQ-Server (IBM MQ-Warteschlangenmanager oder Gruppe mit gemeinsamer Warteschlange) als Busmember zu integrieren (Lösung "Interoperation über den Standard-Messaging-Provider, Busmember")
  • Verwenden Sie den Standard-Messaging-Provider, um ein IBM MQ-Netz mit IBM MQ-Links als fremden Bus zu integrieren (Lösung "Interoperation über den Standard-Messaging-Provider, fremder Bus")

Weitere Informationen zu diesen Lösungen finden Sie im Artikel Interoperation mit IBM MQ: Vergleich der Schlüsselkonzepte.

Um Sie bei der Wahl zwischen diesen Lösungen zu unterstützen, sind in mehreren der folgenden Schritte Tabellen enthalten, in denen jede Zeile eine Geschäfts- oder Systemanforderung darstellt. Sterne (*) kennzeichnen die Lösungen, die sich für die jeweilige Anforderung wahrscheinlich am besten eignen. Diese Tabellen dienen als allgemeine Anleitung und nicht dazu, präzise Lösungen auszuweisen. Für die meisten Anforderungen gibt es mehrere mögliche Lösungen und das Fehlen eines Sterns bedeutet nicht zwingenderweise, dass Sie diese Lösung nicht verwenden können. Verwenden Sie die folgenden Ratschläge, um den besten Nutzung aus der Verwendung dieser Tabellen zu ziehen:
  • Konzentrieren Sie sich auf die Zeilen, die die Anforderungen darstellen, die für Sie am wichtigsten sind.
  • Ermitteln Sie für die von Ihnen ausgewählten Zeilen die Anzahl der Sterne pro Lösung.
Die Lösungen, die die meisten Sterne haben, sind wahrscheinlich am effektivsten.

Vorgehensweise

  1. Wenn Sie wenig Erfahrung mit IBM MQ oder WebSphere Application Server haben und Sie zu entscheiden versuchen, welches Produkt Ihre Anforderungen an das Messaging am besten erfüllt, ziehen Sie den Artikel Vergleich von WebSphere Application Server und IBM MQ-Messaging zu Rate.
    Anmerkung: Auch wenn Sie sich für eines dieser Produkte als Hauptprodukt für das Messaging entscheiden, können Sie trotzdem noch den Standard-Messaging-Provider bzw. den IBM MQ-Provider für die Interoperation zwischen den Produkten verwenden.
  2. Untersuchen Sie Ihre Geschäftsumgebung, um festzustellen, ob Sie nur einen einzigen Provider verwenden können.
    Beachten Sie bei Ihrer Entscheidung für den zu verwendenden Provider die folgenden Vorgaben:
    • Aktuelle und künftige Messaging-Anforderungen
    • Vorhandene Messaging-Infrastruktur
    • Qualifikationen in Ihrer Organisation

    Wenn der Großteil des Messaging momentan in IBM MQ stattfindet, verfolgen Sie diesen Ansatz, und konfigurieren Sie IBM MQ als externen JMS-Provider (d. h., verwenden Sie den IBM MQ-Messaging-Provider) in WebSphere Application Server. Wenn die JMS-Anforderungen Ihrer WebSphere Application Server-Anwendungen begrenzt sind, bleibt zu diskutieren, ob die Verwendung eines Service Integration Bus für diese Anwendungen genügend Vorteile bietet.

    Wenn Sie Messaging-Anwendungen in WebSphere Application Server haben, die nicht mit Ihrem IBM MQ-Netz interagieren müssen, verwenden Sie den Standard-Messaging-Provider (den Service Integration Bus). Wenn die Messaging-Anforderungen von WebSphere Application Server eine engere Integration in WebSphere Application Server erfordern, bietet der Service Integration Bus die folgenden Vorteile:

    • Integrierte Verwaltung
    • Funktionen für hohe Verfügbarkeit in WebSphere Application Server
    • Skalierbarkeit von WebSphere Application Server

    Wenn Sie den Standard-Messaging-Provider für die Interoperation zwischen Serviceintegration und IBM MQ verwenden möchten, müssen Sie bedenken, dass erhöhte Kosten für die Konvertierung der Nachrichten aus dem Serviceintegrationsformat in das Format von IBM MQ und umgekehrt entstehen.

    Beachten Sie außerdem die folgenden Messaging-Szenarien:

    • Ein großes installiertes Backbone mit IBM MQ-Warteschlangenmanagern, eventuell mit einem Nachrichtenbrokerprodukt.

      Wenn Sie WebSphere Application Server für die Ausführung einer neu eingeführten Messaging-Anwendung verwenden möchten, können Sie eine WebSphere Application Server-(JMS)-Messaging-Anwendung implementieren, die Nachrichten mit einer vorhandenen IBM MQ-Warteschlange oder einem vorhandenen IBM MQ-Topic austauscht.

    • Eine Installation von WebSphere Application Server und möglicherweise vorhandene Web- und Unternehmensanwendungen, aber keine WebSphere Application Server-Messaging-Anwendung.

      Wenn keine Messaging-Infrastruktur existiert, können Sie eine WebSphere Application Server-(JMS)-Messaging-Anwendung implementieren, um Nachrichten mit einer vorhandenen WebSphere Application Server-Messaging-Anwendung auszutauschen, die ein SIB-Ziel verwendet.

    • Eine Infrastruktur, die WebSphere Application Server verwendet, um eine Verbindung zu WebSphere Application Server-Messaging-Anwendungen herzustellen.

      Sie können WebSphere Application Server-(JMS)-Messaging zwischen zwei WebSphere Application Server-Anwendungen einrichten.

    • Eine Infrastruktur, die IBM MQ und SIBs enthält. Dies kann das Ergebnis eines Zusammenschlusses sein oder daraus resultieren, dass die Nachrichtenübertragung normalerweise von WebSphere Application Server zu WebSphere Application Server oder von IBM MQ zu IBM MQ, aber nicht zwischen WebSphere Application Server und IBM MQ stattfindet.

      Implementieren Sie eine WebSphere Application Server-(JMS)-Messaging-Anwendung, um Nachrichten mit einer Anwendung auszutauschen, die eine IBM MQ-Warteschlange oder ein IBM MQ-Topic verwendet.

  3. Wenn Ihre Geschäftsumgebung keine klaren Vorgaben bezüglich der Beschränkung auf einen einzigen Messaging-Provider macht, können Sie eine Kombination der beiden Provider verwenden und für jede Anwendung den am besten geeigneten Provider auswählen.

    Die Anwendung muss möglicherweise Nachrichten mit vorhandenen Partneranwendungen oder Services austauschen, die eine oder mehrere Ziele eines bekannten Typs verwenden. Unter Umständen sind die Partneranwendungen oder Services auch noch nicht implementiert, und die Wahl des Zieltyps ist noch offen. In diesem Fall muss der Lösungsarchitekt entscheiden, wie die Verbindungen oder Services am besten verbunden werden.

    Wenn die Anwendung mehrere Ziele verwendet, gibt es vier mögliche Resultate:

    Anmerkung: Wenn es keinen klaren geschäftlichen oder technischen Grund dafür gibt, dass die Anwendung IBM MQ-Ziele anstelle von Buszielen verwenden sollte, und die Partneranwendung ebenfalls eine JMS-Anwendung von WebSphere Application Server ist, können Sie die vorhandenen Ziele auf die Serviceintegration migrieren, so dass die Anwendung nur Busziele verwendet.
  4. Wenn die Anwendung nur Busziele verwendet, konfigurieren Sie die Anwendung und ihre JMS-Ressourcen für die Verwendung des Standard-Messaging-Providers.
  5. Wenn die Anwendung nur IBM MQ-Ziele (Warteschlangen oder Topics) verwendet, verwenden Sie die folgende Prüfliste, um die zu verwendende Providerlösung zu bestimmen.
    Tabelle 1. Providerprüfliste für eine Anwendung, die nur IBM MQ-Ziele verwendet. In der ersten Spalte der Tabelle sind die Fragen der Prüfliste aufgeführt, die die Geschäfts- oder Systemvoraussetzungen für eine Anwendung betreffen, die nur IBM MQ-Ziele verwendet. In der zweiten Spalte sind die Voraussetzungen, die vom IBM MQ-Messaging-Provider erfüllt werden, mit einem Stern markiert. In der dritten Spalte sind die Voraussetzungen, die vom Busmember des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, Busmember) erfüllt werden, mit einem Stern markiert. In der vierten Spalte sind die Voraussetzungen, die vom Fremdbus des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, fremder Bus) erfüllt werden, mit einem Stern markiert. In der zweiten bis vierten Spalte sind alle Voraussetzungen, die von der in der betreffenden Spalte gezeigten Lösung nicht erfüllt werden, mit einem Stern markiert.
    Frage: MQ-Provider Interoperation über den Standard-Messaging-Provider, Busmember Interoperation über den Standard-Messaging-Provider, fremder Bus
    Ist die Leistung ein kritischer Faktor?

    (Falls ja, verwenden Sie IBM MQ direkt, anstatt die Nachrichtenkonvertierung zu verwenden.)

    *
    Muss die Anwendung große Nachrichten (d. h. Nachrichten mit einer Größe von mehr als 500 KB) senden oder empfangen? *
    Ist die Positionstransparenz wünschenswert, um die Programmierung und Implementierung der Anwendungen zu vereinfachen? * *
    Muss die Anwendung Nachrichten aus einer IBM MQ-Warteschlange, deren Konfiguration fest definiert ist, konsumieren?

    ("Fest definiert" bedeutet, dass die Warteschlange nicht in die Serviceintegration verschoben werden kann und Sie keine IBM MQ-Anwendung im Push-Verfahren verwenden möchten, um Nachrichten an ein Busziel zu senden.)

    * *
    Ist die Partneranwendung eine JMS-Anwendung, die außerhalb von WebSphere Application Server als Bus oder IBM MQ-Client ausgeführt wird?

    (Kombinieren Sie die Serviceintegration und IBM MQ nur, wenn dies unbedingt erforderlich ist. Eine reine IBM MQ- oder Serviceintegrationslösung ist einfacher und vermeidet Kosten für die Konvertierung von Nachrichten vom Serviceintegrationsformat in das IBM MQ-Format und umgekehrt.)

    *
    Ist die Partneranwendung keine JMS-Anwendung (keine Anwendung von WebSphere Application Server)?

    (Entscheiden Sie sich, sofern möglich, immer für eine reine IBM MQ- oder Serviceintegrationslösung. Verwenden Sie in Abhängigkeit von den API-Vorgaben den IBM MQ-Client MQI, den IBM MQ-Client XMS oder den XMS-Busclient.)

    *
    Bevorzugen Sie die Einschleusung des Datenverkehrs zwischen Ihrem IBM MQ-Netz und WebSphere Application Server-Anwendungen in eine einzige Verbindung mit langer Laufzeit? *
    Möchten Sie die Features für hohe Verfügbarkeit von WebSphere Application Server verwenden? *
    Ist ein XA mit zweiphasiger Festschreibung zwischen der Anwendung und einer IBM MQ-Gruppe mit gemeinsamer Warteschlange erforderlich? * Siehe 1 * Siehe 2
    Ist ein XA mit zweiphasiger Festschreibung zwischen der Anwendung und einem IBM MQ-Cluster erforderlich? *
    Verwenden Sie WebSphere Enterprise Service Bus, um Nachrichten aus einer IBM MQ-Warteschlange zu vermitteln bzw. dieser zuzustellen?

    (Verwenden Sie beispielsweise Adapter für WebSphere Business Integration oder stellen Sie Verbindungen zu einem Service-Provider wie CICS her.)

    *
    Muss die Anwendung Nachrichten aus einer IBM MQ-Warteschlange, deren Konfiguration fest definiert ist, konsumieren?

    ("Fest definiert" bedeutet, dass die Warteschlange nicht in die Serviceintegration verschoben werden kann und Sie keine IBM MQ-Anwendung im Push-Verfahren verwenden möchten, um Nachrichten an ein Busziel zu senden.)

    * *  
    Anmerkung:
    • 1 Voraussetzung ist, dass IBM MQ Version 7.0.1 verwendet wird.
    • 2 Die zweiphasige Festschreibung kann mit dem IBM MQ-Link verwendet werden, deckt aber nur das Senden der Nachricht an den IBM MQ-Link ab. Sie deckt nicht das nachfolgende Senden der Nachricht an einen IBM MQ-Warteschlangenmanager ab, das über den IBM MQ-Link im Store-and-forward-Verfahren erfolgt.
  6. Wenn die Anwendung eine Kombination von Bus- und IBM MQ-Zielen verwendet, d. h., wenn sie beispielsweise Nachrichten der Serviceintegration konsumiert und an IBM MQ sendet, können die Interoperationsmodelle des Standard-Messaging-Providers durch Verwendung einer einzigen Verbindungsfactory oder Aktivierungsspezifikation unterstützen. Verwenden Sie die folgende Prüfliste, um sich zwischen einer Lösung mit einem Busmember und einer Lösung mit einem fremden Bus zu entscheiden.
    Tabelle 2. Providerprüfliste für eine Anwendung, die eine Kombination von Bus- und IBM MQ-Zielen verwendet. In der ersten Spalte der Tabelle sind die Fragen der Prüfliste aufgeführt, die die Geschäfts- oder Systemvoraussetzungen für eine Anwendung betreffen, die eine Kombination von Bus- und IBM MQ-Zielen verwendet. In der zweiten Spalte sind die Voraussetzungen, die vom Busmember des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, Busmember) erfüllt werden, mit einem Stern markiert. In der dritten Spalte sind die Voraussetzungen, die vom Fremdbus des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, fremder Bus) erfüllt werden, mit einem Stern markiert. In der zweiten und dritten Spalte sind alle Voraussetzungen, die von der in der betreffenden Spalte gezeigten Lösung nicht erfüllt werden, mit einem Stern markiert.
    Frage: Interoperation über den Standard-Messaging-Provider, Busmember Interoperation über den Standard-Messaging-Provider, fremder Bus
    Muss die Anwendung Nachrichten aus einer gemeinsam genutzten IBM MQ-Warteschlange konsumieren? *
    Bevorzugen Sie die Einschleusung des Datenverkehrs zwischen Ihrem IBM MQ-Netz und WebSphere Application Server-Anwendungen in eine einzige Verbindung mit langer Laufzeit? *
    Benötigen Sie verteiltes IBM MQ in früheren Versionen als WebSphere Application Server Version 7 und IBM MQ Version 7? *
    Möchten Sie Speicher- und Weiterleitungsfunktionen (Store-and-forward) verwenden, um der Anwendung zu ermöglichen, weiterhin Nachrichten zu senden, wenn der IBM MQ-Warteschlangenmanager nicht verfügbar ist? *
    Bevorzugen Sie es, dass keine Kanäle für die Serververbindung erstellt werden?

    (Weil diese einen Port öffnen und dies ein Sicherheitsrisiko darstellen könnte.)

    * Siehe 1
    Bevorzugen Sie es, einen einzigen Kanal für die Serverbindung zu definieren anstelle eines Paars aus Sender- und Empfängerkanal? *
    Möchten Sie nur Bindungsverbindungen verwenden? *  
    Anmerkung:
    • 1 Dies gilt nur, wenn Sie Nachrichten von IBM MQ über den IBM MQ-Link an den Service Integration Bus senden möchten, obwohl Sie einen Port zum Anwendungsserver öffnen müssen. Voraussetzung dafür, dass Sie Nachrichten vom Service Integration Bus über den IBM MQ-Link an IBM MQ senden können, ist, dass ein Port durch die Firewall zum Warteschlangenmanager geöffnet wird.
  7. Wenn die Zieltypen noch nicht bekannt sind, legen Sie die relativen Prioritäten der bekannten Problemstellungen fest und verwenden Sie anschließend die folgende Prüfliste, um festzustellen, inwieweit jede dieser Problemstellungen in den möglichen Providerlösungen adressiert wird.

    Im Grunde wird festgelegt, welche Zieltypen diese Anwendung verwenden soll. Die Zieltypen sind noch nicht festgelegt, also sind alle vier Lösungen möglich. Es empfiehlt sich jedoch generell, die Lösung "Standard-Messaging-Provider" oder "MQ-Provider" auszuwählen. Eine reine IBM MQ- bzw. Serviceintegrationslösung ist einfacher und vermeidet die Kosten für die Konvertierung von Nachrichten vom Serviceintegrationsformat in das IBM MQ-Format und umgekehrt.

    Tabelle 3. Providerprüfliste für eine Anwendung, für die die Zieltypen noch nicht bekannt sind. In der ersten Spalte der Tabelle sind die Fragen der Prüfliste aufgeführt, die die Geschäfts- oder Systemvoraussetzungen für eine Anwendung betreffen, deren Zieltypen noch nicht bekannt sind. In der zweiten Spalte sind die Voraussetzungen, die vom Standard-Messaging-Provider erfüllt werden, mit einem Stern markiert. In der dritten Spalte sind die Voraussetzungen, die vom IBM MQ-Messaging-Provider erfüllt werden, mit einem Stern markiert. In der vierten Spalte sind die Voraussetzungen, die vom Busmember des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, Busmember) erfüllt werden, mit einem Stern markiert. In der fünften Spalte sind die Voraussetzungen, die vom Fremdbus des Standard-Messaging-Providers (Interoperation über den Standard-Messaging-Provider, fremder Bus) erfüllt werden, mit einem Stern markiert. In der zweiten bis fünften Spalte sind alle Voraussetzungen, die von der in der betreffenden Spalte gezeigten Lösung nicht erfüllt werden, mit einem Stern markiert.
    Frage: Standard-Messaging-Provider MQ-Provider Interoperation über den Standard-Messaging-Provider, Busmember Interoperation über den Standard-Messaging-Provider, fremder Bus
    Haben Sie eine starke Qualifikationsbasis für die Verwaltung von IBM MQ? * * *
    Soll die gesamte Messaging-Verwaltung vom IBM MQ-Team übernommen werden? *
    Haben Sie Administratoren, die im Umgang mit WebSphere Application Server, aber nicht im Umgang mit IBM MQ erfahren sind? *
    Möchten Sie ein Messaging-Produkt mit einer umfangreichen Installationsbasis (einschließlich Referenzen) und einer großen Auswahl an ISV-Tools verwenden? *
    Zögern Sie, zusätzlich zu WebSphere Application Server ein gesondertes Lizenzprodukt zu erwerben? *
    Zögern Sie, zusätzlich zu WebSphere Application Server ein gesondertes Produkt zu installieren und zu verwalten? *
    Verwenden Sie bereits IBM Integration Bus (aus früheren Releases unter dem Namen WebSphere Message Broker bekannt)?

    (Wenn ja, benötigen Sie IBM MQ ohnehin).

    * * *
    Muss die Anwendung große Nachrichten (d. h. Nachrichten mit einer Größe von mehr als 500 KB) senden oder empfangen? *
    Ist die Positionstransparenz wünschenswert, um die Programmierung und Implementierung der Anwendungen zu vereinfachen? * * *
    Machen die Durchsatzanforderungen die Verwendung mehrerer paralleler Kanäle oder Routen erforderlich? * * *
    Ist die Partneranwendung eine JMS-Anwendung, die ebenfalls in WebSphere Application Server ausgeführt wird?

    Die Serviceintegration wird im WebSphere Application Server-Anwendungsserver ausgeführt. Auf verteilten Plattformen bedeutet dies, dass die Serviceintegration prozessintern ist. [z/OS]Auf der Plattform z/OS wird sie in einer anderen Region ausgeführt. Deshalb bietet der Standard-Messaging-Provider einen potenziellen Leistungsvorteil auf verteilten Plattformen, aber nicht auf der Plattform z/OS.

    *
    Ist die Partneranwendung eine JMS-Anwendung, die außerhalb von WebSphere Application Server als Bus oder IBM MQ-Client ausgeführt wird?

    (Kombinieren Sie die Serviceintegration und IBM MQ nur, wenn dies unbedingt erforderlich ist. Eine reine IBM MQ- oder Serviceintegrationslösung ist einfacher und vermeidet Kosten für die Konvertierung von Nachrichten vom Serviceintegrationsformat in das IBM MQ-Format und umgekehrt.)

    * *
    Ist die Partneranwendung keine JMS-Anwendung (d. h. keine Anwendung von WebSphere Application Server)?

    (Entscheiden Sie sich, sofern möglich, immer für eine reine IBM MQ- oder Serviceintegrationslösung. Verwenden Sie in Abhängigkeit von den API-Vorgaben den IBM MQ-Client MQI, den IBM MQ-Client XMS oder den XMS-Busclient.)

    * *
    Ist eine strikte Einhaltung der Nachrichtenreihenfolge erforderlich? *
    Erfordert die Anwendung die Flexibilität und den Komfort eines IBM MQ-Clusters?

    (Das Clustering von IBM MQ vereinfacht die Verwaltung und unterstützt die selektive Parallelität von Clusterwarteschlangen. Das bedeutet, dass Instanzen einer Clusterwarteschlange in jedem beliebigen Warteschlangenmanager im IBM MQ-Cluster (doch nicht unbedingt in allen) erstellt werden können. An die Clusterwarteschlange gesendete Nachrichten können an eine bestimmte Instanz der Warteschlange adressiert werden, oder es kann eine Instanz dynamisch auf der Basis von Workload-Management-Statistiken ausgewählt werden. Das Clustering von WebSphere Application Server bietet einen Teil dieser Flexibilität, aber es ist nicht möglich, Partitionen eines Busziels in einem Teil der Messaging-Engines eines Busmembers vom Typ "Cluster" zu erstellen.)

    * * *
    Benötigt die Anwendung die Stufe der Hochverfügbarkeit, die von Warteschlangen von IBM MQ for z/OS bereitgestellt wird? * * *
    Möchten Sie die Features für hohe Verfügbarkeit oder Skalierbarkeit des Clustering von WebSphere Application Server verwenden? * * *

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tmj_jmsp_mixed
Dateiname:tmj_jmsp_mixed.html