test

Notes de version de Sun GlassFish Message Queue 4.4

Nouvelles fonctions de Message Queue 4.4 et versions récentes

Les nouvelles fonctions de Message Queue 4.4 et des versions précédentes de la gamme Message Queue 4.x sont décrites dans les sections suivantes :

Nouvelles fonctions de Message Queue 4.4

Message Queue 4.4 est une version mineure apportant un certain nombre d'améliorations de fonctions et de corrections de bogues. Cette section décrit les nouvelles fonctions de cette version :

Service de pont JMS

La spécification JMS ne définissant pas un protocole câblé pour la communication entre les courtiers et les clients, chaque fournisseur JMS (y compris ceux de Message Queue) a défini et utilise son propre protocole propriétaire. Cette situation a mené à une non-interopérabilité entre les fournisseurs JMS.

Le service de pont JMS dans Message Queue 4.4 met fin à cette désynchronisation en activant un courtier Message Queue destiné à mapper ses destinations à celles de fournisseurs JMS externes. Concrètement, ce mappage permet au courtier de Message Queue de communiquer avec des clients du fournisseur JMS externe.

Le service de pont JMS prend en charge les destinations de mappage des fournisseurs JMS externes :

De nombreux fournisseurs JMS open source et commerciaux répondent à ces exigences, de sorte que le service de pont JMS permet d'intégrer efficacement Message Queue dans un environnement de messagerie existant qui utilise d'autres fournisseurs JMS.

Pour plus d'informations sur le service de pont JMS, voir :

Service de pont STOMP

Comme indiqué précédemment, la spécification JMS ne définit pas de protocole câblé pour la communication entre les courtiers et les clients. Le projet open source STOMP (Streaming Text Oriented Messaging Protocol), disponible à la page http://stomp.codehaus.org, définit un protocole câblé simple que les clients écrits dans n'importe quel langage peuvent utiliser pour communiquer avec un fournisseur de messagerie prenant en charge le protocole STOMP.

Message Queue 4.4 prend en charge le protocole STOMP via le service de pont STOMP. Ce service permet à un courtier Message Queue de communiquer avec les clients STOMP.

Pour plus d'informations sur le service de pont STOMP :

Améliorations supplémentaires

Les améliorations supplémentaires suivantes sont également disponibles dans Message Queue 4.4 :

Nouvelles fonctions UMS (Universal Message Service)

Le service UMS fournit maintenant des fonctions qui utilisent HTTP GET pour offrir plusieurs services :

Pour une présentation des UMS, reportez-vous à la section Universal Message Service (UMS). Pour la documentation de l'API UMS, consultez le site https://mq.dev.java.net/4.3-content/ums/protocol.html. Pour obtenir des exemples de programmation dans plusieurs langages, consultez la page https://mq.dev.java.net/4.3-content/ums/examples/README.html.

Package IPS pris en charge

Message Queue est désormais fourni pour distribution avec le système IPS (Image Packaging System, système de conditionnement d'image) open source, également appelé système pkg(5). Cette méthode de conditionnement a été ajoutée afin que Message Queue puisse être intégré à Sun GlassFish Enterprise Server 2.1.1.

Nouvelles fonctions de Message Queue 4.3

Message Queue 4.3 était une version mineure apportant un certain nombre d'améliorations de fonctions et des corrections de bogues. Cette section décrit les nouvelles fonctions incluses dans cette version :

Universal Message Service (UMS)

Message Queue 4.3 introduit un nouveau service UMS (Universal Messaging Service, service de messagerie universelle) et une API de messagerie qui permet d'accéder à Message Queue à partir de n'importe appareil compatible http. Par conséquent, la plupart des applications peuvent communiquer avec toute autre application et profiter de la fiabilité et de l'envoi garanti de messages JMS. En outre, le service UMS offre une évolutivité améliorée pour la messagerie JMS, permettant d'augmenter le nombre de clients de messagerie à l'échelle d'Internet.

Architecture

La figure suivante illustre l'architecture UMS de base :

Figure 1–1 Architecture UMS

Illustration indiquant que l'UMS est un pont entre des clients non JMS et un fournisseur JMS.

Le service UMS, qui s'exécute sur un serveur Web, est un langage neutre et indépendant de la plate-forme. Le service UMS sert de pont entre une application cliente non JMS et un fournisseur JMS. Il reçoit les messages envoyés via l'API UMS, les transforme en messages JMS, puis les envoie aux différentes destinations dans le fournisseur JMS par le biais du protocole natif du fournisseur. De même, il extrait les messages des destinations du fournisseur JMS, les transforme en texte ou en messages SOAP, puis envoie les messages aux clients non JMS comme demandé par les clients via l'API UMS.

L'API UMS, basée sur un protocole simple, non dépendant d'un langage, prend en charge les applications basées sur le Web et non basées sur le Web, et peut être utilisée avec les langages de script et de programmation. L'API est proposée dans deux styles : une API de messagerie simple qui utilise un protocole de type REST (Representational State Transfer) et une API de messagerie XML qui incorpore le protocole dans les en-têtes de messages SOAP. Dans les deux cas, cependant, l'API ne requiert qu'une seule requête http pour envoyer ou recevoir un message.

La simplicité et la flexibilité de l'API UMS signifie que AJAX, .NET, Python, C, Java et bien d'autres applications peuvent envoyer un message texte et/ou des messages SOAP (avec pièce jointe) aux destinations JMS ou recevoir de messages de destinations JMS. Par exemple, les applications Python peuvent communiquer avec les applications .NET, les applications iPhone avec les applications Java, etc.

Pour Message Queue 4.3, le service UMS prend uniquement en charge Message Queue en tant que fournisseur JMS.

Autres fonctions

Le service UMS est plus que le simple pont décrit ci-dessus. Il prend en charge les sessions client avec ou sans état. Si le client le demande, le service UMS conservera l'état de la session pour l'application client sur plusieurs requêtes de service. Le service UMS peut utiliser l'authentification par conteneur, être configuré pour authentifier les clients à l'aide du courtier Message Queue, ou les deux. Le service UMS prend également en charge les transactions, permettant ainsi aux applications clientes de valider ou répéter plusieurs requêtes de service comme une seule unité atomique.

Le service UMS pouvant prendre en charge un grand nombre de clients sur une connexion unique avec le courtier Message Queue, il facilite la charge des services de connexion du courtier, pour une évolutivité optimale. En outre, la capacité UMS peut être augmentée par mise à l'échelle horizontale, ce qui permet des charges de messagerie de niveau Internet.

Côté client, en raison de la simplicité de l'API UMS basée sur protocole, aucun client de bibliothèque n'est requis. Par conséquent, l'API peut être étendue à l'avenir pour mettre en œuvre des fonctions JMS sans mettre à niveau les applications clientes.

Utilisation du service UMS

Pour utiliser le service UMS, vous devez le déployer dans un conteneur Web prenant en charge les spécifications Servlet 2.4 ou version ultérieure, démarrer le courtier Message Queue, créer les destinations appropriées et écrire une application de messagerie qui utilise l'API UMS pour envoyer ou recevoir des messages.

Le fichier UMS imqums.war, contenu dans la distribution de Message Queue 4.3, est installé à l'emplacement suivant, en fonction de la plate-forme :

Vous pouvez renommer le fichier .war.

Tableau 1–5 Emplacement du fichier imqums.war

Plate-forme 

Emplacement du fichier imqums.war

Solaris 

/usr/share/lib/imq

Linux 

/opt/sun/mq/share/lib

AIX 

IMQ_HOME/lib

Windows 

IMQ_HOME\lib

Après avoir déployé le fichier imqums.war dans un conteneur Web à localhost:port, vous pouvez trouver la documentation UMS disponible à l'adresse suivante :

http://localhost:port/imqums

Sinon, vous pouvez trouver la documentation UMS comme suit :

Conteneurs Web pris en charge

Le service UMS est actuellement pris en charge sur les conteneurs Web suivants :

Prise en charge de la plate-forme AIX

Message Queue 4.3 fournit des packages pour la plate-forme AIX et un programme d'installation pour les installer.

L'implémentation AIX de Message Queue prend en charge les logiciels suivants :

Pour obtenir des instructions sur la procédure d'installation, reportez-vous au Chapitre 4, AIX Installation du Sun GlassFish Message Queue 4.4 Installation Guide.

Sur la plate-forme AIX, les fichiers Message Queue sont installés sous un répertoire de base Message Queue unique, IMQ_HOME. IMQ_HOME indique le répertoire mqInstallHome/mq, où mqInstallHome est le répertoire d'installation de base que vous avez spécifié lors de l'installation du produit (par défaut, home-directory /MessageQueue).

La structure du répertoire de Message Queue qui en résulte est identique à celle de la plate-forme Windows (reportez-vous à la section Windows de l'Annexe A, Platform-Specific Locations of Message Queue Data du Sun GlassFish Message Queue 4.4 Administration Guide).

La prise en charge de Message Queue pour la plate-forme AIX comprend la prise en charge de la C-API de Message Queue. Pour obtenir des instructions sur la création et la compilation d'applications C sur la plate-forme AIX, reportez-vous à XREF.

Nouveau programme d'installation à partir de zip

Message Queue 4.3 introduit un nouveau programme d'installation pour les distributions basées sur des zips, par opposition aux distributions de packages natifs. Le programme d'installation permet d'installer les nouvelles distributions .zip de Message Queue pour la plate-forme AIX.

Le nouveau programme d'installation extrait les fichiers .zip de Message Queue vers tout répertoire pour lequel vous disposez de droits d'accès en écriture (il n'est pas nécessaire de disposer de droits d'accès de superutilisateur), et il vous permet également d'enregistrer votre installation de Message Queue avec Sun Connection.

Pour réduire la taille de téléchargement des bundles, Java Runtime n'est plus inclus dans le zip de la distribution (la plupart des sites en sont déjà équipés). Par conséquent, la commande installer nécessite de spécifier un JDK ou un JRE, soit à l'aide de la variable d'environnement JAVA_HOME, soit à l'aide de l'option -j de la ligne de commande, comme suit :

$ installer -j JDK/JRE-path

où JDK/JRE-path correspond au chemin d'accès au JDK ou JRE spécifié.

Prise en charge d'une plate-forme étendue

La prise en charge de la plate-forme mise à jour suivante sera certifiée pour Message Queue 4.3 :

Améliorations supplémentaires

Les améliorations supplémentaires suivantes sont incluses dans Message Queue 4.3 :

Nouvelle structure de répertoires sur les plates-formes Windows

La structure de répertoires installée pour Message Queue sur la plate-forme Windows a été modifiée par rapport aux versions précédentes pour la rendre identique à celle de la plate-forme AIX. Cette structure de répertoires sera également appliquée aux plates-formes Solaris et Linux dans le futur, afin de faciliter les installations multiples sur seul ordinateur et la mise à jour automatique de Message Queue via Sun Connection, un service hébergé par Sun qui vous aide à suivre, organiser et entretenir le matériel et les logiciels Sun (reportez-vous à la section Prise en charge du programme d'installation pour l'enregistrement à Sun Connection).

Nouvelles propriétés de courtier

Les nouvelles propriétés suivantes sont disponibles pour la configuration d'un courtier :

Tableau 1–6 Routage du courtier et propriétés de distribution

Propriétés 

Type 

Valeur par défaut 

Description 

imq.transaction.producer.maxNumMsgs

Entier 

1000

Nombre maximal de messages qu'un producteur peut traiter en une seule transaction. Il est recommandé que la valeur soit inférieure à 5 000 pour éviter d'épuiser les ressources. 

imq.transaction.consumer.maxNumMsgs

Entier 

100

Nombre maximal de messages qu'un consommateur peut traiter en une seule transaction. Il est recommandé que la valeur soit inférieure à 1 000 pour éviter d'épuiser les ressources. 

imq.persist.jdbc.connection.limit

Entier 

5

Nombre maximal de connexions qui peuvent être ouvertes à la base de données. 

Améliorations de l'API d'administration JMX

Un nouvel attribut et des clés de données composites ont été ajoutés à l'API JMX, comme suit :

Pour de plus amples informations, reportez-vous au Chapitre 3, Message Queue MBean Reference du Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.

Liste des abonnements durables pour les abonnés de messages génériques

La commande permettant de dresser une liste des abonnements durables :

list dur [-d topicName]

a été améliorée afin que la spécification du nom de la rubrique soit facultative. Si la rubrique n'est pas spécifiée, la commande crée une liste de l'ensemble des abonnements durables pour toutes les rubriques (y compris ceux comportant des conventions d'attribution de noms avec des caractères génériques)

Nouvelles fonctions de Message Queue 4.2

Message Queue 4.2 était une version mineure apportant un certain nombre d'améliorations de fonctions et des corrections de bogues. Cette section décrit les nouvelles fonctions de la version 4.2 et fournit de plus amples références destinées à votre usage :

Pour de plus amples informations sur les fonctions introduites dans Message Queue 4.1 et 4.0, reportez-vous respectivement aux sections Nouvelles fonctions de Message Queue 4.1 et Nouvelles fonctions de Message Queue 4.0.

Destinations multiples pour un éditeur ou un abonné

Dans Message Queue 4.2, un éditeur peut publier des messages vers de multiples destinations de sujet et un abonné peut recevoir des messages provenant de multiples destinations de sujet. Cette capacité est obtenue en utilisant un nom de destination de sujet incluant des caractères génériques, permettant ainsi de multiples destinations. L'utilisation de noms symboliques de ce type permet aux administrateurs de créer des destinations de sujet supplémentaires, selon le cas, de façon cohérente avec le schéma de nommage générique. Les éditeurs et les abonnés publient et consomment automatiquement à partir des destinations ajoutées. (Les abonnés de sujet générique sont plus courants que les éditeurs.)

Remarque –

Cette fonction ne s'applique pas aux destinations de files d'attente.

Le format des noms de destination de sujet symboliques et d'autres exemples de leur utilisation sont décrits à la section Supported Topic Destination Names du Sun GlassFish Message Queue 4.4 Administration Guide.

Validation des schémas des messages de charge utile XML

Cette fonctionnalité, introduite dans Message Queue 4.2, permet de valider le contenu d'un message XML texte (pas objet) par rapport à un schéma XML au moment où le message est envoyé au courtier. L'emplacement du schéma XML (XSD, XML Schema Directory) est spécifié comme une propriété d'une destination de Message Queue. Si aucun emplacement XSD n'est spécifié, la déclaration DTD du document XML est utilisée pour exécuter une validation DTD. (La validation XSD, qui comprend la validation du type de données et de la fourchette de valeurs, est plus rigoureuse que la validation DTD.)

Pour plus d'informations concernant l'utilisation de cette fonctionnalité, consultez la section Validation des schémas des messages de charge utile XML.

Prise en charge de C-API pour les transactions distribuées

Selon le modèle de transaction distribuée X/Open, la prise en charge pour les transactions distribuées dépend d'un gestionnaire de transactions distribuées qui suit et gère les opérations exécutées par un ou plusieurs gestionnaires de ressources. Dans Message Queue 4.2, la C-API de Message Queue prend désormais en charge l'interface XA (entre un gestionnaire de transactions distribuées et Message Queue en tant que gestionnaire de ressources conforme à XA), permettant aux clients de la C-API de Message Queue s'exécutant dans un environnement de traitement des transactions distribuées (comme BEA Tuxedo) de participer aux transactions distribuées.

Cette prise en charge des transactions distribuées se compose des nouvelles fonctions C-API suivantes (et de nouveaux paramètres et codes d'erreur) utilisées pour implémenter la spécification de l'inferface XA : 

MQGetXAConnection()
MQCreateXASession()

Si une application client C doit être utilisée dans le contexte d'une transaction distribuée, alors elle doit obtenir une connexion à l'aide de MQGetXAConnection() et créer une session pour produire et consommer des messages à l'aide de MQCreateXASession(). Le lancement, la validation et la répétition de toute transaction distribuée sont gérés via des API fournies par le gestionnaire de transactions distribuées.

Pour plus de détails sur l'utilisation des fonctions de transaction distribuée, reportez-vous à la section Working With Distributed Transactions du Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.

Message Queue  4.2 fournit des exemples de programmation sur la base du gestionnaire de transactions Tuxedo. Pour plus d'informations sur l'utilisation de ces programmes échantillons, reportez-vous à la section Distributed Transaction Sample Programs du Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.

Remarque –

La fonctionnalité de transaction distribuée est prise en charge sous Solaris, Linux et Windows. Cependant, à ce jour, elle a uniquement été certifiée sur la plate-forme Solaris.

Prise en charge du programme d'installation pour l'enregistrement à Sun Connection

Le programme d'installation de Message Queue a été amélioré pour permettre l'enregistrement de Message Queue avec Sun Connection, un service hébergé par Sun qui vous aide à suivre, organiser et mettre à jour votre matériel et vos logiciels Sun.

Dans le cadre de l'installation de Message Queue, vous pouvez choisir d'enregistrer Message Queue avec Sun Connection. Les informations concernant le programme Message Queue installé, comme la version, le nom d'hôte, le système d'exploitation, la date d'installation et d'autres informations de base du même type, sont transmises de façon sécurisée à la base de données de Sun Connection. Le service d'inventaire de Sun Connection peut vous aider à organiser vos logiciels et votre matériel Sun, tandis que le service de mise à jour peut vous informer des dernières corrections de sécurité disponibles, des mises à jour recommandées et des améliorations de fonctions.

Pour plus d'informations sur l'enregistrement de Message Queue avec Sun Connection, reportez-vous au Sun GlassFish Message Queue 4.4 Installation Guide.

Prise en charge de la base de données MySQL

Message Queue 4.2 a introduit la prise en charge de la base de données MySQL en tant que magasin de données basé sur JDBC. MySQL Cluster Edition peut être utilisé comme base de données JDBC pour un courtier autonome et comme magasin de données partagées hautement disponible nécessaire à un cluster de courtier amélioré. Pour de plus amples informations sur la configuration de Message Queue pour utiliser MySQL, reportez-vous aux sections Configuring a JDBC-Based Data Store du Sun GlassFish Message Queue 4.4 Administration Guide du Enhanced Broker Cluster Properties du Sun GlassFish Message Queue 4.4 Administration Guide.

Améliorations supplémentaires

En plus des fonctions décrites ci-dessus, Message Queue 4.2 inclut les améliorations suivantes :

Nouvelles fonctions de Message Queue 4.1

Message Queue 4.1 était une version mineure apportant un certain nombre de nouvelles fonctions, des améliorations de fonctions et des corrections de bogues. Cette section décrit les nouvelles fonctions de la version 4.1 et fournit de plus amples références destinées à votre usage :

Pour obtenir des informations sur les nouvelles fonctions de Message Queue 4.0, reportez-vous à la section Nouvelles fonctions de Message Queue 4.0.

Clusters de courtiers haute disponibilité

Message Queue 4.1 a introduit un nouveau cluster de courtiers amélioré. Comparés aux clusters de courtiers traditionnels assurant la disponibilité du service de messagerie (si un courtier échoue, un autre courtier est disponible pour fournir un service de messagerie), les clusters de courtiers améliorés assurent eux la disponibilité des données (si un courtier échoue, ses messages persistants et données d'état sont disponibles pour qu'un autre courtier puisse le relayer et délivrer les messages).

L'implémentation de haute disponibilité introduite dans Message Queue 4.1 utilise un magasin de données basé sur JDBC partagé : plutôt que tous les courtiers d'un cluster de courtiers disposent de leur propre magasin de données persistantes, tous les courtiers du cluster partagent la même base de données compatible JDBC. Si un courtier particulier échoue, un autre courtier du cluster prend sa relève pour acheminer et livrer ses messages. Le courtier de basculement utilise alors les données et les informations d'état du magasin de données partagées. Les clients du courtier défaillant ayant émis les messages se reconnectent au courtier de basculement, et le service de messagerie est ininterrompu.

Le magasin partagé basé sur JDBC utilisé dans l'implémentation haute disponibilité de Message Queue 4.1 doit être lui-même hautement disponible. Si vous ne possédez pas de base de données hautement disponible ou si la livraison ininterrompue de messages n'est pas importante pour vous, vous pouvez continuer à utiliser les clusters traditionnels qui fournissent une disponibilité de service sans disponibilité de données.

Pour configurer un cluster de courtiers amélioré pour Message Queue 4.1, vous devez spécifier les propriétés de courtier suivantes pour chaque courtier du cluster :

L'implémentation de clusters de courtiers améliorés se fait selon les étapes suivantes :

  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 de données persistant hautement disponible.

  4. Paramétrez des propriétés haute disponibilité pour chaque courtier du cluster.

  5. Démarrez chaque courtier du cluster.

Si vous souhaitez consulter une discussion conceptuelle sur les clusters de courtiers améliorés et obtenir une comparaison de ceux-ci par rapport aux clusters conventionnels, reportez-vous au Chapitre 4, Broker Clusters du Sun GlassFish Message Queue 4.4 Technical Overview. Pour obtenir des informations procédurales et référentielles sur les clusters de courtiers améliorés, reportez-vous au Chapitre 10, Configuring and Managing Broker Clusters du Sun GlassFish Message Queue 4.4 Administration Guide et à la section Cluster Configuration Properties du Sun GlassFish Message Queue 4.4 Administration Guide.

Si vous avez utilisé une base de données hautement disponible avec Message Queue 4.0 et si vous souhaitez passer à un cluster de courtiers amélioré, vous pouvez utiliser l'utilitaire Gestionnaire de base de données (imqdbmgr) pour une conversion vers un magasin de données persistant partagé. Reportez-vous également à Clusters de courtiers pour plus de problèmes et restrictions connus.

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 introduit également la prise en charge de JAAS (Java Authentication and Authorization Service), qui vous permet de connecter un mécanisme d'authentification au courtier pour authentifier les clients Message Queue.

Pour obtenir une description des informations qu'un courtier met à disposition d'un service d'authentification conforme à JAAS et une explication sur la façon de configurer le courtier pour utiliser un tel service, reportez-vous à la section Using JAAS-Based Authentication du Sun GlassFish Message Queue 4.4 Administration Guide.

Modification du format du magasin de données persistant

Message Queue 4.1 a modifié le magasin de données basé sur JDBC pour prendre en charge des clusters de courtiers améliorés. Pour cette raison, le format du magasin de données basé sur JDBC est passé à la version 410. Les versions aux formats 350, 370 et 400 sont automatiquement migrées vers la version 410.

Veuillez noter que le format du magasin de données persistant basé sur les fichiers reste à la version 370 car aucun changement n'a été apporté à cette version.

Configuration de l'environnement du courtier

La propriété IMQ_DEFAULT_EXT_JARS a été ajoutée au fichier de configuration de l'environnement Message Queue 4.1 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 .jar externes peuvent faire référence aux pilotes JDBC ou aux modules de connexion JAAS. L'exemple de propriété 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 Java ES Monitoring Framework

Message Queue 4.1 a introduit la prise en charge de Sun Java Enterprise System (Java ES) Monitoring Framework, qui permet de surveiller les composants Java ES à l'aide d'une interface graphique commune. Cette interface est implémentée par une console basée sur le Web, Sun Java System Monitoring Console. Les administrateurs peuvent utiliser la console pour visualiser les statistiques de performance, créer des règles de surveillance automatique et accuser réception des alarmes. Si vous exécutez Message Queue en même temps que d'autres composants Java ES, vous trouverez peut-être plus pratique d'utiliser une seule interface pour tous les gérer.

Pour obtenir des informations sur l'utilisation de Java ES Monitoring Framework pour surveiller Message Queue, reportez-vous à XREF.

Gestion améliorée des transactions

Auparavant, seules les transactions à l'é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 à un état qui ne pouvait pas être nettoyé par un administrateur. Dans Message Queue 4.1, vous pouvez désormais utiliser l'utilitaire Commande (imqcmd) pour nettoyer (annuler) des transactions dont l'état est l'un des suivants : STARTED, FAILED, INCOMPLETE, COMPLETE et PREPARED.

Pour vous aider à déterminer si une transaction particulière peut être annulée ou pas (en particulier son état n'est pas PREPARED), l'utilitaire Commande fournit des données supplémentaires dans la sortie imqcmd query txn : il fournit l'ID de connexion pour la connexion à l'origine de la transaction et indique l'heure à laquelle la transaction a été créée. À l'aide de ces informations, un administrateur peut alors décider d'annuler ou non 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

Dans Message Queue 4.1, les clients C, comme les clients Java, peuvent maintenant se connecter à un port de courtier fixe plutôt qu'à un port affecté de façon dynamique par le service du courtier Port Mapper. Les connexions de port fixe sont utiles si vous essayez de franchir un pare-feu ou si avez besoin de contourner le service Port Mapper pour d'autres raisons.

Pour configurer une connexion de port fixe, vous devez configurer à la fois l'exécution du courtier et du client C (les deux extrémités de la connexion). 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é reportée dans Message Queue 3.7 Mise à jour 2.

Nouvelles fonctions de Message Queue 4.0

Message Queue 4.0 est une version mineure visant essentiellement à prendre en charge Application Server 9 PE. Elle comprend de nouvelles fonctions, des améliorations de fonctions et des corrections de bogues. Cette section inclut une description des nouvelles fonctions de cette version :

Attention – Attention –

Parmi les modifications mineures mais radicales de la version 4.0, on peut souligner la désapprobation de l'option de ligne de commande pour spécifier un mot de passe. Désormais, vous devez stocker tous les mots de passe dans un fichier, comme décrit dans Option de mot de passe désapprouvée ou les saisir lorsque vous y êtes invité.

Prise en charge de l'API d'administration JMX

Une nouvelle API a été ajoutée dans Message Queue 4.0 pour la configuration et le contrôle des courtiers Message Queue conformément à la spécification Java Management Extensions (JMX). A l'aide de cette API, vous pouvez configurer et contrôler les fonctions de courtier, à l'aide de programmes, depuis une application Java. Dans les anciennes versions de Message Queue, ces fonctions étaient uniquement accessibles à partir des utilitaires d'administration de la ligne de commande ou de la console d'administration.

Pour de plus amples informations, reportez-vous au Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.

Journalisation à l'exécution client

Message Queue 4.0 a introduit la prise en charge de la journalisation de l'exécution du client des événements liés aux connexions et aux sessions.

Pour obtenir des informations sur la journalisation de l'exécution client et la façon de la configurer, reportez-vous au Java Dev Guide page 137.

API de notification des événements de connexion

Message Queue 4.0 a introduit un API de notification des événements qui permet l'exécution du client pour informer une application des changements dans l'état de connexion. Les notifications d'événements de connexion permettent à un client Message Queue d'écouter les événements de fermeture et de reconnexion et d'entreprendre l'action appropriée selon le type de notification et l'état de connexion. Par exemple, lorsqu'un basculement se produit et que le client est reconnecté à un autre courtier, une application peut vouloir nettoyer l'état de transaction correspondant et utiliser une nouvelle transaction.

Pour obtenir des informations sur les événements de connexion et la façon de créer un listener d'événements, reportez-vous au Guide Java Dev, page 96.

Améliorations de l'administration du courtier

Dans Message Queue 4.0, une nouvelle sous-commande et plusieurs options de commande ont été ajoutées à l'utilitaire de Commande (imqcmd) pour permettre aux administrateurs de mettre en attente un courtier, de fermer un courtier après un intervalle spécifié, de détruire une connexion ou de paramétrer les propriétés du système java (par exemple, les propriétés liées à la connexion).

Pour de plus amples informations sur la syntaxe de la commande imqcmd, reportez-vous au Chapitre 16, Command Line Reference du Sun GlassFish Message Queue 4.4 Administration Guide.

Affichage des informations concernant le magasin de données basé sur JDBC

Dans Message Queue 4.0, une nouvelle sous-commande de requête a été ajoutée à l'utilitaire du Gestionnaire de base de données, imqdbmgr. Cette sous-commande est utilisée pour afficher les informations relatives au magasin de données basé sur JDBC persistant, notamment la version de la base de données, l'utilisateur de la base de données et la création ou non de tables de base de données.

Voici un exemple des informations affichées par la commande.


imqdbmgr query
 

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

Prise en charge du fournisseur JDBC

Dans Message Queue 4.0, Apache Derby Version 10.1.1 est désormais pris en charge comme fournisseur de magasin de données basé sur JDBC.

Modifications du format du magasin de données persistant

Message Queue 4.0 a introduit des modifications au magasin de données basé sur JDBC à des fins d'optimisation et pour prendre en charge des améliorations futures. Pour cette raison, le format du magasin de données JDBC est passé à la version 400. Notez que dans Message Queue 4.0, la version du magasin de données basé sur les fichiers reste la version 370 car elle n'a subi aucune modification.

Propriétés supplémentaires des messages

Message Queue 4.0 a ajouté deux nouvelles propriétés paramétrées sur tous les messages placés dans la file d'attente bloquée.

Prise en charge de SSL

À partir de Message Queue 4.0, la valeur par défaut pour la propriété de fabrique de connexion des clients imqSSLIsHostTrusted est false. Si votre application est basée sur la valeur par défaut précédente true, vous devez reconfigurer et définir explicitement la propriété sur true.

Vous pouvez choisir de faire confiance à l'hôte lorsque le courtier est configuré pour utiliser des certificats autosignés. Dans ce cas, en plus d'indiquer que la connexion doit utiliser un service de connexions SSL (à l'aide de la propriété imqConnectionType), vous devez définir la propriété imqSSLIsHostTrusted sur true.

Par exemple, pour exécuter de manière sécurisée les applications clientes lorsque le courtier utilise des certificats autosignés, utilisez une commande similaire à l'exemple suivant.

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

Pour utiliser l'utilitaire de Commande (imqcmd) de façon sécurisée lorsque le courtier utilise des certificats auto-signés, utilisez une commande semblable à l'une des commandes suivantes (pour répertorier les services de connecteur).

imqcmd list svc -secure -DimqSSLIsHostTrusted=true