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.
- 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.
- 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.
- 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.
- Wenn die Anwendung nur Busziele verwendet, konfigurieren Sie die Anwendung und ihre
JMS-Ressourcen für die Verwendung des Standard-Messaging-Providers.
- 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.
- 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.
- 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. 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? |
* |
|
* |
* |