Pourquoi et quand exécuter cette tâche
Vous pouvez utiliser le fournisseur de messagerie par défaut ou le fournisseur IBM MQ pour la messagerie entre des serveurs d'applications, avec une interaction avec un système IBM MQ. Aucun de ces deux fournisseurs n'est meilleur que l'autre. Le
choix des fournisseurs dépend principalement des facteurs liés à votre
environnement métier et aux modifications planifiées pour cet environnement,
mais également des besoins de chaque application JMS.
En outre, ces deux types de fournisseurs de messagerie ne s'excluent pas l'un l'autre :
- Vous pouvez les configurer tous les deux dans une cellule.
- Plusieurs applications peuvent utiliser le même fournisseur ou des fournisseurs différents.
Les facteurs liés à votre environnement professionnel sont les suivants :
- les exigences envers la messagerie,
- l'ensemble de compétence existant,
- l'infrastructure de messagerie existante,
- les changements prévus sur cette infrastructure.
La configuration et la gestion de votre infrastructure de messagerie est plus simple si vous n'utilisez qu'un fournisseur.
Si votre messagerie se trouve en premier lieu dans IBM MQ, il est préférable de sélectionner le fournisseur de messagerie IBM MQ. De même, si votre messagerie se trouve en premier lieu dans WebSphere
Application Server, il est préférable de choisir le fournisseur de messagerie par défaut.
Si votre environnement professionnel n'indique pas
clairement que vous devez n'utiliser qu'un fournisseur, vous devez envisager
d'utiliser un mélange des deux fournisseurs et de choisir le plus approprié
pour chaque application. Un excellent moyen de définir ces besoins consiste à identifier les types de
destinations utilisés par l'application (bus d'intégration de services ou file d'attente ou rubrique
IBM MQ). Si l'application utilise uniquement les destinations de bus, il est logique d'utiliser le fournisseur de messagerie par défaut (solution
"DMP"). Si l'application doit dialoguer avec une ou plusieurs destinations de
IBM MQ, sélectionnez l'une des solutions suivantes selon votre environnement de travail, les scénarios d'utilisation et les topologies du système :
- Utilisez le fournisseur de messagerie IBM MQ (solution "MQP").
- Utilisez le fournisseur de messagerie par défaut pour intégrer un serveur IBM MQ (un gestionnaire de file d'attente IBM MQ ou un groupe de partage de file d'attente) comme membre de bus (solution "Membre de bus interop DMP").
- Utilisez le fournisseur de message par défaut pour intégrer un réseau à IBM MQ comme bus externe en utilisant des liens IBM MQ (solution "interop DMP, bus externe").
Pour plus de détails sur ces solutions, voir Interaction avec IBM MQ : Comparatif des fonctionnalités clés.
Pour faciliter
la sélection entre ces solutions, plusieurs des étapes suivantes contiennent des
tableaux dans lesquels chaque ligne représente une configuration requise ou une exigence de travail et les
astérisques (*) indiquent les solutions probablement les plus efficaces pour remplir ces exigences. Ces tableaux sont conçus pour apporter des informations générales plutôt que pour identifier des solutions exactes. La plupart des exigences entraînent
plusieurs possibilités de solutions et l'absence d'astérisque ne veut pas forcément dire que
cette solution n'est pas utilisable pour vous. Pour obtenir la meilleure déduction
de chacun de ces tableaux :
- mettez en évidence les lignes reflétant au mieux vos exigences les plus importantes,
- additionnez le nombre d'astérisques pour chaque solution dans toutes les lignes prises en considération.
Les solutions comptant le plus grand nombre d'astérisques seront probablement les plus efficaces.
- Si vous n'avez pas suffisamment d'expérience avec IBM MQ ou WebSphere
Application Server pour déterminer lequel de ces produits répondra au mieux à vos besoins de messagerie, voir Comparaison des services de messagerie de WebSphere Application Server et d'IBM MQ.
Remarque : Quel que soit
le produit que vous sélectionnerez pour votre messagerie, vous pourrez
toujours utiliser le fournisseur de messagerie par défaut ou le fournisseur IBM MQ pour interagir entre les produits.
- Etudiez votre environnement métier pour déterminer si vous pouvez n'utiliser qu'un seul fournisseur.
Pour cela, prenez en compte les contraintes suivantes :
- les exigences actuelles et futures par rapport à la messagerie,
- l'infrastructure de messagerie existante,
- l'ensemble des compétences réunies dans votre organisation.
Si aujourd'hui la majorité de votre messagerie est réalisée dans IBM MQ,
conservez cette approche et configurez IBM MQ en tant que fournisseur JMS externe
(c'est-à-dire, utilisez le fournisseur de messagerie IBM MQ) dans WebSphere
Application Server. Si les exigences JMS de vos applications WebSphere
Application Server sont restreintes,
l'avantage de l'utilisation d'un bus d'intégration de services serait discutable.
Si certaines applications de messagerie dans WebSphere
Application Server n'exigent pas d'interopérabilité avec le réseau IBM MQ, utilisez le fournisseur de messagerie par défaut (le bus d'intégration de services). Si vos exigences de messagerie WebSphere
Application Server nécessitent une intégration plus élevée dans WebSphere
Application Server, le bus d'intégration de services apporte les avantages suivants :
- l'administration intégrée,
- les fonctions de haute disponibilité WebSphere
Application Server ;
- l'évolutivité WebSphere
Application Server.
L'utilisation du fournisseur de messagerie par défaut pour l'interopérabilité
entre l'intégration de services et IBM MQ impliquera des frais supplémentaires
lors de la conversion des messages du format d'intégration de services au
format de IBM MQ.
Etudiez également les scénarios de messagerie suivants :
- Un grand réseau principal de gestionnaires de files d'attente de IBM MQ,
avec éventuellement le produit Message Broker.
Si vous souhaitez utiliser WebSphere
Application Server pour exécuter une nouvelle application de messagerie, vous pouvez déployer une application de messagerie WebSphere
Application Server (JMS) qui échangera des messages avec une application existante qui utilise une file d'attente ou un sujet IBM MQ.
- Une installation WebSphere
Application Server, éventuellement avec des applications d'entreprise et Web existantes, mais pas d'application de messagerie WebSphere
Application Server.
Si vous ne disposez pas d'une infrastructure de messagerie,
vous pouvez déployer une application de messagerie WebSphere
Application Server (JMS) pour échanger des messages avec une application de messagerie WebSphere
Application Server existante qui utilise une destination de bus d'intégration de services.
- Une infrastructure qui utilise WebSphere
Application Server pour se connecter aux applications de messagerie WebSphere
Application Server.
Introduisez la messagerie WebSphere
Application Server (JMS) entre deux applications WebSphere
Application Server.
- Une infrastructure comprenant à la fois IBM MQ et des bus d'intégration de services. Cette situation peut résulter d'une fusion
ou se produire lorsque les messages sont transmis principalement de WebSphere
Application Server à WebSphere Application
Server, ou de IBM MQ à IBM MQ, et non pas entre WebSphere
Application Server et IBM MQ.
Déployez une application de messagerie WebSphere
Application Server (JMS) pour échanger des messages avec une application qui utilise une file d'attente ou un sujet IBM MQ.
- Si votre environnement de travail n'indique pas clairement l'utilisation d'un seul fournisseur de messagerie,
utilisez un mélange des deux et sélectionnez le fournisseur de messagerie le mieux adapté
à chaque application, selon le type de destination utilisé par l'application.
Il
se peut que l'application ait besoin d'échanger des messages avec des
services ou des applications partenaires existants qui utilisent une ou
plusieurs destinations connues de type connu. Les services ou les
applications partenaires peuvent aussi ne pas encore être déployés et le choix du
type de destination peut encore être effectué, auquel cas l'architecte de la
solution doit déterminer le moyen le plus approprié de connecter les
applications ou les services ensembles.
Si l'application
utilise plusieurs destinations, quatre résultats sont possibles :
Remarque : Si aucune raison technique ou métier n'est clairement définie, pour laquelle l'application
utiliserait des destinations IBM MQ plutôt que des destinations de bus et si l'application associée est également une application WebSphere
Application Server JMS, pensez à migrer les destinations existantes vers une intégration de services, de sorte que l'application n'utilise plus que des destinations de bus.
- Si l'application n'utilise que des destinations de bus,
configurez l'application et ses ressources JMS pour qu'elles utilisent le
fournisseur de messagerie par défaut.
- Si l'application utilise uniquement des destinations (files d'attente ou sujets) de IBM MQ, la liste de contrôle suivante permettra de déterminer quel fournisseur de solution utiliser.
Tableau 1. Liste de contrôle pour le choix d'un fournisseur lorsqu'une application n'utilise que des destinations de IBM MQ.. La première colonne de ce tableau répertorie les questions de la liste de contrôle pour les exigences métier ou système d'une application utilisant uniquement des destinations IBM MQ. Dans la deuxième colonne, les exigences satisfaites par la solution de messagerie de fournisseur IBM MQ (MQP) sont signalées à l'aide d'un astérisque.
Dans la troisième colonne, les exigences satisfaites par la solution de membre de bus de fournisseur de messagerie par défaut (interop DMP, membre de bus) sont signalées à l'aide d'un astérisque. Dans la quatrième colonne, les exigences satisfaites par la solution de bus externe de fournisseur de messagerie par défaut (interop DMP, bus externe) sont signalées à l'aide d'un astérisque. Dans les colonnes deux à quatre, toutes les exigences non satisfaites par la solution présentée dans cette colonne ne sont pas signalées à l'aide d'un astérisque.Question : |
MQP |
interop DMP, membre de bus affecté |
interop DMP, bus externe affecté |
Les performances sont-elles primordiales ? (Si tel est le cas, utilisez directement IBM MQ, plutôt que d'exécuter une conversion de messages.)
|
* |
|
|
L'application doit-elle envoyer ou recevoir de longs message (> 500 ko, par exemple)? |
* |
|
|
La transparence de l'emplacement est-elle souhaitable
pour simplifier la programmation et le déploiement des applications ? |
|
* |
* |
L'application doit-elle effectuer une réception à partir d'une file d'attente de IBM MQ ? (Autrement dit, la file d'attente
ne peut pas être déplacée vers une intégration de services et vous ne voulez pas déployer une application de style de poussée IBM MQ pour envoyer des messages à une destination de bus.)
|
* |
* |
|
L'application associée est-elle une application JMS qui s'exécutera en dehors de WebSphere
Application Server, tel un bus ou un client IBM MQ ? (Ne combinez pas l'intégration de services avec IBM MQ sauf si vous ne pouvez pas faire autrement ; une solution d'intégration de services ou IBM MQ fondamentale est plus simple et évite les frais de conversion des messages entre l'intégration de services et les formats de IBM MQ.)
|
* |
|
|
L'application partenaire est-elle une application non JMS
(autre que WebSphere Application Server) ? (Sélectionnez autant que possible une solution d'intégration de services ou IBM MQ fondamentale. Utilisez le client d'interface MQI IBM MQ, le client XMS IBM MQ ou le client de bus XMS selon la préférence de l'API.)
|
* |
|
|
Préférez-vous que le passage du trafic entre le réseau IBM MQ et les applications WebSphere
Application Server se fasse en entonnoir vers une seule connexion à longue durée ? |
|
|
* |
Souhaitez-vous utiliser les fonctions à haute disponibilité de WebSphere
Application Server ? |
|
|
* |
La validation en 2 phases XA (2PC) est-elle nécessaire entre l'application et un groupe de partage de files
d'attente IBM MQ ? |
* Voir 1 |
* |
Voir 2 |
La validation en 2 phases XA (2PC) est-elle nécessaire entre l'application et un cluster IBM MQ ? |
|
* |
|
Utilisez-vous le bus de service d'entreprise de WebSphere pour négocier les messages à partir de ou pour les distribuer vers une file d'attente
de IBM MQ ? (Par exemple,
l'utilisation des adaptateurs de WebSphere Business
Integration ou la connexion à un fournisseur de services tel que CICS.)
|
* |
|
|
L'application doit-elle effectuer une réception à partir d'une file d'attente de IBM MQ ? (Autrement dit, la file d'attente
ne peut pas être déplacée vers une intégration de services et vous ne voulez pas déployer une application de style de poussée IBM MQ pour envoyer des messages vers une destination de bus.)
|
* |
* |
|
Remarque : - 1 Sous réserve que IBM MQ version 7.0.1 soit utilisé.
- 2 La validation en deux phases XA peut être utilisée avec le lien IBM MQ, mais elle ne couvre que l'envoi du message au lien IBM MQ. Elle ne couvre pas l'envoi suivant du message entre le lien IBM MQ et un gestionnaire de files d'attente IBM MQ à l'aide d'opérations ne stockage et de retransmission.
- Si l'application utilise un mélange de bus et de destinations de IBM MQ, par exemple, la réception à partir d'une intégration de services et l'envoi vers IBM MQ, l'un des modèles d'interopérabilité du fournisseur de messagerie par défaut peut alors prendre cela en charge
en utilisant une fabrique de connexions ou une spécification d'activation unique. Utilisez la liste de contrôle suivante pour la prise de décision entre une solution de bus externe ou de membre de bus.
Tableau 2. Liste de contrôle pour le choix d'un fournisseur lorsqu'une application utilise un mélange de bus et de destinations IBM MQ.. La première colonne de ce tableau répertorie les questions de la liste de contrôle pour les exigences métier ou système d'une application utilisant des destinations IBM MQ. Dans la deuxième colonne, les exigences satisfaites par la solution de membre de bus de fournisseur de messagerie par défaut (interop DMP, membre de bus) sont signalées à l'aide d'un astérisque. Dans la troisième colonne, les exigences satisfaites par la solution de bus externe de fournisseur de messagerie par défaut (interop DMP, bus externe) sont signalées à l'aide d'un astérisque. Dans les colonnes deux et trois, toutes les exigences non satisfaites par la solution présentée dans cette colonne ne sont pas signalées à l'aide d'un astérisque.Question : |
interop DMP, membre de bus affecté |
interop DMP, bus externe affecté |
L'application doit-elle effectuer une réception à partir d'une file d'attente partagée IBM MQ ? |
* |
|
Préférez-vous que le passage du trafic entre le réseau IBM MQ et les applications WebSphere
Application Server se fasse en entonnoir vers une seule connexion à longue durée ? |
|
* |
Avez-besoin des versions de IBM MQ réparti antérieures à WebSphere
Application Server version 7 et à IBM MQ version 7 ? |
|
* |
Souhaitez-vous disposer de fonctions de stockage et de retransmission pour permettre à l'application de continuer d'envoyer des messages lorsque le gestionnaire de files d'attente de IBM MQ n'est pas disponible ? |
|
* |
Souhaitez-vous ne pas configurer les canaux de connexion
serveur ? (Ceux-ci
ouvrant un port, cela pourrait représenter un risque de sécurité).
|
|
* Voir 1 |
Préférez-vous définir un canal de connexion serveur,
plutôt qu'une paire de canaux émetteur et récepteur ? |
* |
|
Souhaitez-vous utiliser uniquement des connexions de liaisons ? |
* |
|
Remarque : - 1 S'applique uniquement si vous souhaitez envoyer des messages de IBM MQ vers le bus d'intégration de services via le lien IBM MQ. Pour cela, il est nécessaire d'ouvrir un port sur votre serveur d'applications. L'envoi de messages depuis le bus d'intégration de services vers IBM MQ via le lien IBM MQ nécessite qu'un port soit ouvert vers le gestionnaire de files d'attente via votre pare-feu.
- Si les types de destination ne sont pas encore connus,
déterminez les priorités relatives des difficultés connues, puis utilisez la
liste de contrôle ci-après pour évaluer le traitement de chacune d'elles par
les solutions de fournisseur possibles.
Le choix sous-jacent est
quel type de destinations cette application utilisera. Les types de destination n'étant pas encore fixes, chacune des quatre solutions
est possible, mais en règle générale vous devriez tendre vers une solution "DMP" ou "MQP", car une solution d'intégration de services ou de IBM MQ fondamentale est plus simple et évite les frais de
conversion des messages entre l'intégration de services et les formats de IBM MQ.
Tableau 3. Liste de contrôle du fournisseur pour une application pour laquelle les types de destination ne sont pas encore connus. La première colonne de ce tableau répertorie les questions de la liste de contrôle pour les exigences métier ou système d'une application pour laquelle les types de destination ne sont pas encore connus. Dans la deuxième colonne, les exigences satisfaites par la solution de messagerie de fournisseur par défaut (DMP) sont signalées à l'aide d'un astérisque. Dans la troisième colonne, les exigences satisfaites par la solution de messagerie de fournisseur IBM MQ (MQP) sont signalées à l'aide d'un astérisque.
Dans la quatrième colonne, les exigences satisfaites par la solution de membre de bus de fournisseur de messagerie par défaut (interop DMP, membre de bus) sont signalées à l'aide d'un astérisque. Dans la cinquième colonne, les exigences satisfaites par la solution de bus externe de fournisseur de messagerie par défaut (interop DMP, bus externe) sont signalées à l'aide d'un astérisque. Dans les colonnes deux à cinq , toutes les exigences non satisfaites par la solution présentée dans cette colonne ne sont pas signalées à l'aide d'un astérisque.Question : |
DMP |
MQP |
interop DMP, membre de bus affecté |
interop DMP, bus externe affecté |
Possédez-vous une base de fortes compétences en gestion de IBM MQ ? |
|
* |
* |
* |
Désirez-vous que la gestion de toute la messagerie soit gérée par l'équipe de IBM MQ ? |
|
* |
|
|
Avez-vous des administrateurs compétents en gestion de WebSphere
Application Server, mais pas en gestion de IBM MQ ? |
* |
|
|
|
Souhaitez-vous un produit de messagerie avec une grande
base installée et un grand choix d'outils ISV ? |
|
* |
|
|
Vous n'êtes peut-être pas très enclin à acheter un nouveau produit sous licence en plus de WebSphere
Application Server ? |
* |
|
|
|
Vous n'êtes peut-être pas très enclin à installer et à gérer un produit différent
en plus de WebSphere
Application Server ? |
* |
|
|
|
Utilisez-vous déjà IBM Integration Bus, connu sous le nom WebSphere Message Broker dans les versions antérieures ? (Si oui,
vous avez de toute façon besoin de IBM MQ.)
|
|
* |
* |
* |
L'application doit-elle envoyer ou recevoir de longs message (> 500 ko, par exemple)? |
|
* |
|
|
La transparence de l'emplacement est-elle souhaitable
pour simplifier la programmation et le déploiement des applications ? |
* |
|
* |
* |
Le débit exigé requiert-il plusieurs canaux ou routes
parallèles ? |
|
* |
* |
* |
L'application associée est-elle une application JMS qui s'exécutera
aussi dans WebSphere
Application Server ? (L'intégration de service s'exécute dans le serveur d'applications WebSphere
Application Server. Sur les plateformes réparties, l'exécution a lieu dans la région du "processus-en-cours". Sur la plateforme z/OS, il s'agit d'une autre région. C'est pourquoi l'utilisation du fournisseur de messagerie par défaut permet de meilleures performances sur les plateformes réparties, mais pas sur la plateforme z/OS).
|
* |
|
|
|
L'application associée est-elle une application JMS qui s'exécutera en dehors de WebSphere Application Server,
tel un bus ou un client IBM MQ ? (Ne combinez pas l'intégration de services avec IBM MQ sauf si vous ne pouvez pas faire autrement ; une solution d'intégration de services ou IBM MQ fondamentale est plus simple et évite les frais de conversion des messages entre l'intégration de services et les formats de IBM MQ.)
|
* |
* |
|
|
L'application partenaire est-elle une application non JMS
(autre que WebSphere
Application Server) ? (Sélectionnez autant que possible une solution d'intégration de services ou IBM MQ fondamentale. Utilisez le client d'interface MQI IBM MQ, le client XMS IBM MQ ou le client de bus XMS selon la préférence de l'API.)
|
* |
* |
|
|
Un ordre strict des messages est-il important ? |
* |
|
|
|
L'application exige-t-elle la flexibilité et la grande diffusion d'un cluster IBM MQ ? (La fonction de mise en cluster IBM MQ simplifie l'administration et fournit un parallélisme sélectif des files d'attente de cluster. C'est-à-dire que des instances d'une file d'attente mise en cluster peuvent être créées
sur n'importe quels gestionnaires de files d'attente (mais pas nécessairement sur tous) dans le cluster de IBM MQ. Des messages envoyés à la
file d'attente mise en cluster peuvent être adressés à une instance spécifique de la file d'attente ou
avoir le droit de sélectionner une instance activement basée sur des statistiques de gestion de charge de travail. La mise en cluster de WebSphere
Application Server fournit une partie de cette flexibilité, mais ne peut pas créer de partitions d'une destinations de bus sur un sous-ensemble des moteurs de messagerie dans un membre de bus de cluster.)
|
|
* |
* |
* |
L'application a-t-elle besoin du niveau à haute disponibilité fourni
par les files d'attente partagées de IBM MQ for z/OS ? |
|
* |
* |
* |
Souhaitez-vous utiliser les fonctions à haute disponibilité ou évolutivité de la mise en cluster de WebSphere
Application Server ? |
* |
|
* |
* |