test

Notes de version de Sun Java System Message Queue 4.1

Nouveautés de la version 4.1

Message Queue 4.1 propose des clusters de courtier haute disponibilité (données et services), la prise en charge de JAAS et d'autres fonctionnalités mineures. Cette section décrit ces nouvelles fonctionnalités et fournit des références supplémentaires pour votre information.

Haute disponibilité

Message Queue 4.1 est équipé de clusters haute disponibilité fournissant la disponibilité des données et des services. Si un client perd sa connexion à un courtier haute disponibilité, celui-ci est automatiquement reconnecté à un autre courtier dans un cluster. Le courtier offrant la nouvelle connexion récupère les données et l'état du courtier en échec et fournit un service continu aux clients de ce courtier. Vous pouvez exécuter des courtiers haute disponibilité sur une connexion sécurisée.

Ceux-ci requièrent l'utilisation d'une base de données hautement disponible (HADB). Si vous ne disposez pas de ce type de base de données ou si vous ne jugez pas la disponibilité des données primordiale, vous pouvez continuer à utiliser des clusters conventionnels, offrant une reconnexion automatique et la disponibilité des services.

La configuration des courtiers haute disponibilité est simple : il vous suffit de spécifier les propriétés suivantes pour chaque courtier du cluster.

Pour utiliser cette fonctionnalité, procédez comme suit :

  1. Installez une base de données hautement disponible.

  2. Installez le fichier .jar du pilote JDBC.

  3. Créez le schéma de base de données pour le magasin persistant hautement disponible.

  4. Définissez les propriétés associées à la fonction de haute disponibilité pour chaque courtier du cluster.

  5. Démarrez chaque courtier du cluster.

Si vous souhaitez consulter une discussion conceptuelle sur la haute disponibilité et obtenir une comparaison de celle-ci par rapport aux clusters conventionnels, reportez-vous au Chapitre 4, Broker Clusters du Sun Java System Message Queue 4.1 Technical Overview. Pour obtenir des informations procédurales et référentielles sur la haute disponibilité, reportez-vous au Chapitre 8, Broker Clusters du Sun Java System Message Queue 4.1 Administration Guide et à la section Cluster Configuration Properties du Sun Java System Message Queue 4.1 Administration Guide.

Si vous utilisiez une base de données HADB avec Message Queue version 4.0 et que vous souhaitez utiliser un cluster haute disponiblité, vous pouvez utiliser l'utilitaire dbmgr pour procéder à une mise à niveau vers un magasin HADB partagé. Consultez la section Clusters de courtier pour plus d'informations.

Prise en charge de JAAS

En plus des mécanismes d'authentification intégrés basés sur les fichiers et le LDAP, Message Queue prend également en charge le JAAS (Java Authentication and Authorization Service), qui permet de connecter divers services au courtier pour authentifier les clients Message Queue. Cette section présente les informations mises à disposition par le courtier à un service d'authentification compatible JAAS et définit la procédure de configuration du courtier pour utiliser ce type de service.

En revanche, l'API JAAS n'est pas décrite dans le présent document. Consultez les sources suivantes si vous avez besoin d'informations détaillées.

L'API JAAS est une API noyau dans J2SE et fait donc partie intégrante de l'environnement d'exécution de Message Queue. JAAS définit une couche d'abstraction entre une application et un mécanisme d'authentification, permettant ainsi de connecter le mécanisme souhaité sans modifier le code d'application. En ce qui concerne le service Message Queue, la couche d'abstraction se trouve entre le courtier (application) et un fournisseur d'authentification. En définissant certaines propriétés du courtier, vous avez la possibilité de connecter n'importe quel service d'authentification compatible JAAS et de mettre à niveau ce dernier sans interruption ou modification du code du courtier.

Vous pouvez utiliser des clients JMX pour gérer le courtier si vous utilisez un service d'authentification JAAS ; en revanche, vous devez configurer manuellement la prise en charge de JAAS (en définissant les propriétés du courtier correspondantes) avant de démarrer le courtier. Vous ne pouvez pas utiliser l'API JMX pour modifier ces propriétés.

Éléments du JAAS

Figure 1–1 : présente les éléments de base du JAAS : un client JAAS, un service d'authentification compatible JAAS et un fichier de configuration JAAS.

Figure 1–1 Éléments du JAAS

Cette figure représente les éléments requis pour une authentification compatible JAAS. Le texte précédant la figure explique son contenu.

La section suivante décrit de quelle manière le service Message Queue utilise ces éléments pour fournir une authentification compatible JAAS.

JAAS et Message Queue

La figure suivante montre de quelle manière JAAS est utilisé par le courtier Message Queue. Elle illustre une implémentation plus complexe du modèle JAAS représenté sur la figure précédente.

Figure 1–2 Comment Message Queue utilise JAAS

La figure montre de quelle manière l'authentification compatible JAAS est utilisée avec Message Queue. Le texte suivant la figure explique son contenu.

Comme le montrait la figure simplifiée, la couche du service d'authentification est séparée du courtier. Le service d'authentification comprend un ou plusieurs modules de connexion (LoginModule), ainsi que des modules d'authentification supplémentaires si nécessaire. Les modules de connexion s'exécutent sur la même machine virtuelle Java que le courtier. Le courtier Message Queue apparaît au module de connexion sous forme de LogInContext et communique avec celui-ci au moyen d'un CallBackHandler , faisant partie du code d'exécution du courtier.

Le service d'authentification fournit également un fichier de configuration JAAS comprenant des entrées vers les modules de connexion. Le fichier de configuration spécifie l'ordre d'utilisation des modules ainsi que certaines conditions d'utilisation. Lorsque le courtier démarre, JAAS localise le fichier de configuration à l'aide de la propriété système Java java.security.auth.login.config ou du fichier de propriétés de sécurité Java. Il sélectionne ensuite une entrée dans le fichier de configuration JAAS, selon la valeur de la propriété du courtier imq.user_repository.jaas.name . Cette entrée spécifie quels modules de connexion seront utilisés pour l'authentification. Comme le montre la figure, le courtier peut utiliser plusieurs modules de connexion. (La relation existant entre le fichier de configuration, le module de connexion et le courtier est représentée sur la Figure 1–3.)

Le fait que le courtier utilise un service d'authentification de plug-in JAAS reste entièrement transparent pour le client Message Queue. Ce dernier continue de se connecter au courtier comme avant, à l'aide d'un nom d'utilisateur et d'un mot de passe. En réponse, le courtier utilise un gestionnaire de rappels pour transmettre ces informations au service d'authentification et ce dernier utilise ces données pour authentifier l'utilisateur et retourner les résultats correspondants. Si l'authentification réussit, le courtier autorise la connexion, sinon l'exécution client retourne une exception de sécurité JMS devant être gérée par ce dernier.

Une fois le client Message Queue authentifié, si une autorisation plus complexe est nécessaire, le courtier reprend une activité normale ; il consulte alors le fichier de contrôle d'accès pour déterminer si le client authentifié est autorisé à exécuter les actions suivantes : accéder à une destination, consommer un message, parcourir une file d'attente, etc.

Configuration de l'authentification compatible JAAS

La configuration de l'authentification compatible JAAS implique la définition des propriétés du système et du courtier pour pouvoir sélectionner ce type d'authentification, spécifier l'emplacement du fichier de configuration et spécifier les entrées vers les modules de connexion qui seront utilisés.

Cette section illustre les liens existant entre le client JAAS, les modules de connexion et le fichier de configuration JAAS, puis décrit le processus requis pour configurer une authentification compatible JAAS. La figure suivante illustre la relation existant entre le fichier de configuration, le module de connexion et le courtier.

Figure 1–3 Configuration de la prise en charge de JAAS

Cette figure illustre la relation existant entre les fichiers associés au JAAS. Le texte suivant la figure explique son contenu.

Comme indiqué, le fichier de configuration JAAS, MyJAASCFile.config, contient des références à plusieurs modules de connexion, regroupés dans un point d'entrée. Le courtier localise le fichier de configuration en consultant la propriété système Java java.security.auth.login.config ou le fichier de propriétés de sécurité Java. Les modules de connexion à utiliser sont déterminés par la consultation de la propriété du courtier imq.user_repository.jaas.name , spécifiant l'entrée souhaitée dans le fichier de configuration. Les classes de ces modules se trouvent dans le répertoire lib/ext.

Afin de configurer la prise en charge de JAAS pour Message Queue, vous devez suivre les étapes suivantes. (Dans un environnement de développement, l'ensemble de ces étapes peut être pris en charge par le développeur. Dans un environnement de production, l'administrateur peut effectuer certaines de ces tâches.)

  1. Créez une ou plusieurs classes de module de connexion chargées d'implémenter le service d'authentification. Les types de rappel JAAS pris en charge par le courtier sont répertoriés ci-dessous.

    javax.security.auth.callback.LanguageCallback

    Le courtier utilise ce rappel pour transmettre au service d'authentification la langue dans laquelle il est exécuté. Cette valeur peut être utilisée pour la localisation.

    javax.security.auth.callback.NameCallback

    Le courtier utilise ce rappel pour transmettre au service d'authentification le nom d'utilisateur spécifié par le client Message Queue à la demande de connexion.

    javax.security.auth.callback.TextInputCallback

    Le courtier utilise ce rappel pour spécifier la valeur de imq.authentication.type au service d'authentification lorsque TextInputCallback.getPrompt() est imq.authentication.type. Pour l'instant, la seule valeur possible pour ce champ est basic. Celle-ci indique un codage de mot de passe en Base64.

    javax.security.auth.callback.PasswordCallback

    Le courtier utilise ce rappel pour transmettre au service d'authentification le mot de passe spécifié par le client Message Queue à la demande de connexion.

    javax.security.auth.callback.TextOutputCallback

    Le courtier utilise ce rappel pour fournir des services de journalisation au service d'authentification en consignant la sortie texte vers son propre fichier journal. Les paramètres MessageType de rappel ERROR, INFORMATION, WARNING sont mappés respectivement vers les niveaux de journal du courtier ERROR, INFO, et WARNING.

  2. Créez un fichier de configuration JAAS avec des entrées faisant référence aux classes de module de connexion et spécifiez l'emplacement de ce fichier à l'administrateur Message Queue. (Ce fichier peut être stocké à distance et son emplacement peut être spécifié à l'aide d'un URL.)

  3. Notez le nom de l'entrée (faisant référence aux classes d'implémentation de connexion) dans le fichier de configuration JAAS.

  4. Archivez ces classes dans un fichier jar, puis stockez ce dernier dans le répertoire Message Queue lib/ext.

  5. Configurez les propriétés du courtier associées à la prise en charge de JAAS. Celles-ci sont présentées dans le Tableau 1–2.

  6. Définissez la propriété système suivante pour spécifier l'emplacement du fichier de configuration JAAS.

    java.security.auth.login.config= Emplacement_Fichier_Config_JAAS

    Par exemple, vous pouvez spécifier le fichier de configuration au démarrage du courtier.

    imqbrokerd -Djava.security.auth.login.config=Emplacement_Fichier_Config_JAAS

    Il existe également d'autres procédures pour spécifier l'emplacement du fichier de configuration JAAS. Pour de plus amples informations, consultez :

    http://java.sun.com/j2se/.1.5.0/docs/guide/security/jaas/tutorials/LoginConfigFile.html

Le tableau suivant répertorie les propriétés du courtier requises pour configurer la prise en charge de JAAS.

Tableau 1–2 Propriétés du courtier pour la prise en charge de JAAS

Propriété 

Description 

imq.authentication.type

Définie sur basic pour indiquer un codage de mot de passe Base64. Il s'agit de l'unique valeur autorisée pour une authentification JAAS.

imq.authentication.basic.user_repository

Définie sur jaas pour spécifier une authentification JAAS.

imq.accesscontrol.type

Définie sur file.

imq.user_repository.jaas.name

Définie sur le nom de l'entrée souhaitée (dans le fichier de configuration JAAS), faisant référence aux modules de connexion choisis comme mécanisme d'authentification. Il s'agit du nom spécifié à l'étape 3.

imq.user_repository.jaas.userPrincipalClass

Cette propriété, utilisée par le contrôle d'accès Message Queue, spécifie la classe d'implémentation java.security.Principal dans le ou les modules utilisés par le courtier pour extraire le nom principal destiné à représenter l'entité utilisateur dans le fichier de contrôle d'accès Message Queue. Si celle-ci n'est pas spécifiée, le nom d'utilisateur transmis par le client Message Queue à la demande de connexion est utilisé.

imq.user_repository.jaas.groupPrincipalClass

Cette propriété, utilisée par le contrôle d'accès Message Queue, spécifie la classe d'implémentation java.security.Principal dans le ou les modules de connexion utilisés par le courtier pour extraire le nom principal destiné à représenter l'entité groupe dans le fichier de contrôle d'accès Message Queue. Si celle-ci n'est pas spécifiée, les règles de groupe sont ignorées dans le fichier de contrôle d'accès Message Queue, le cas échéant.

Modification du format du magasin persistant

La version 4.1 de Message Queue modifie le magasin JDBC pour prendre en charge la fonction de haute disponibilité. La version du magasin JDBC a donc été portée à 410. Les versions 350, 370 et 400 sont automatiquement migrées vers le format de la version 410.

Notez toutefois que la version du magasin persistant basé sur les fichiers demeure à 370 car celui-ci n'a fait l'objet d'aucune modification.

Configuration du courtier

La propriété IMQ_DEFAULT_EXT_JARS a été ajoutée au fichier imqenv.conf. Vous pouvez définir cette propriété pour spécifier les noms de chemin des fichiers .jar externes à inclure dans CLASSPATH au démarrage du courtier. Si vous utilisez cette propriété pour spécifier l'emplacement des fichiers .jar externes, il ne vous sera plus nécessaire de copier ces fichiers dans le répertoire lib/ext. Ces fichiers peuvent faire référence aux pilotes JDBC ou aux modules de connexion JAAS. L'exemple de commande suivant spécifie l'emplacement des pilotes JDBC.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Prise en charge de la structure de contrôle JES

Message Queue prend en charge la structure de contrôle Sun Java Enterprise System (JES), permettant un contrôle des composants Java Enterprise System à l'aide d'une interface graphique standard. Cette interface est implémentée par une console basée sur le Web, Sun Java System Monitoring Console. Si vous exécutez Message Queue en même temps que d'autres composants JES, vous trouverez peut-être plus pratique d'utiliser une seule interface pour la gestion de tous ces composants.

La structure de contrôle JES définit un modèle de données commun (CMM) pouvant être utilisé par tous les composants JES. Ce modèle propose un aperçu centralisé et uniforme de tous les composants JES. Message Queue expose les objets suivants à la structure de contrôle JES :

Chacun de ces objets est mappé vers un objet CMM dont les attributs peuvent être contrôlés à l'aide de la console de contrôle JES. Au cours de l'exécution, les administrateurs peuvent utiliser la console pour afficher les statistiques de performance, créer des règles de contrôle automatique et accuser réception des alarmes. Pour de plus amples informations sur le mappage des objets Message Queue vers les objets CMM, reportez-vous au manuel Sun Java Enterprise System Monitoring Guide.

Pour activer le contrôle JES, procédez comme suit :

  1. Installez et configurez tous les composants de votre déploiement (Message Queue et autres) en suivant les instructions données dans le Guide d'installation de Sun Java Enterprise System.

  2. Activez et configurez la structure de contrôle pour l'ensemble de vos composants sous contrôle, comme décrit dans le manuel Sun Java Enterprise System Monitoring Guide.

  3. Installez la console de contrôle sur un hôte séparé, démarrez l'agent maître, puis le serveur Web, comme décrit dans le manuel Sun Java Enterprise System Monitoring Guide.

L'utilisation de la structure de contrôle JES n'a aucun effet sur les performances du courtier car le travail de rassemblement des mesures est effectué par la structure de contrôle, qui récupère les données à partir de l'infrastructure de données de contrôle existante du courtier.

Gestion des transactions

Auparavant, seules les transactions en état PREPARED pouvaient être annulées administrativement. Par exemple, lorsqu'une session, faisant partie d'une transaction distribuée, ne s'arrêtait pas normalement, la transaction était conservée dans un état qui ne pouvait pas être nettoyé par l'administrateur du courtier. Dans Message Queue 4.1, vous pouvez utiliser l'utilitaire imqcmd pour nettoyer (annuler) les transactions se trouvant dans les états suivants : STARTED, FAILED, INCOMPLETE, COMPLETE, PREPARED.

Pour vous aider à déterminer si une transaction particulière peut être annulée ou pas (en particulier lorsque celle-ci n'est pas en état PREPARED), l'utilitaire imqcmd fournit des données supplémentaires dans la sortie imqcmd query txn : il fournit l'ID de connexion pour la connexion ayant démarré la transaction et spécifie l'heure de création de cette dernière. À l'aide de ces informations, l'administrateur peut alors décider d'annuler ou pas la transaction. En règle générale, il est préférable que l'administrateur évite d'annuler une transaction prématurément.

Ports fixes pour les connexions de clients C

Les clients C peuvent utiliser la propriété de connexion MQ_SERVICE_PORT_PROPERTY pour spécifier un port fixe auquel se connecter. Cela peut s'avérer pratique si vous essayez de passer au travers d'un pare-feu ou si vous avez besoin de contourner le service de mappage de ports du courtier (chargé d'assigner les ports dynamiquement).

Veillez à configurer le port du service JMS également du côté courtier. Par exemple, si vous souhaitez connecter votre client via ssljms au port 1756, il vous faut procéder comme suit.

Remarque –

La propriété de connexion MQ_SERVICE_PORT_PROPERTY a été introduite avec la version 3.7 Update 2 de Message Queue.