Les nouvelles fonctions de Message Queue 4.4 Mise à jour 1 et des versions précédentes de la gamme Message Queue 4.x sont décrites dans les sections suivantes :
Message Queue 4.4 Mise à jour 1 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 :
Message Queue 4.4 Mise à jour 1 fournit un nouveau programme d'installation multiplate-formes basé sur le système pkq(5), également appelé IPS ou Image Packaging System. Pour plus d'informations sur ce programme d'installation, reportez-vous au document Sun GlassFish Message Queue 4.4 Update 1 Installation Guide.
Message Queue 4.4 Mise à jour 1 ajoute un mécanisme de persistance des transactions destiné aux magasins de données basés sur les fichiers et qui prend en charge les clusters de courtiers. Ce mécanisme fournit d'autres fonctionnalités décrites à la section Optimizing File-Based Transaction Persistence du Sun GlassFish Message Queue 4.4 Administration Guide.
Message Queue 4.4 Mise à jour 1 prend en charge l'exécution d'un courtier au sein d'un client Java. Ce courtier, appelé courtier en cours ou intégré, s'exécute dans la même JVM que le client Java qui le crée et le démarre. Pour plus d'informations, reportez-vous au Chapitre 6, Embedding a Message Queue Broker in a Java Client du Sun GlassFish Message Queue 4.4 Developer’s Guide for Java Clients.
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 :
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 :
Compatibles JMS1.1
Prenant en charge les objets administratifs JNDI
Utilisant des fabriques de connexion de type javax.jms.ConnectionFactory ou javax.jms.XAConnectionFactory
Dans le cadre d'un mappage transactionnel, prenant en charge les interfaces XA comme un gestionnaire de ressources
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 :
Pour plus d'informations sur l'architecture, les sous-composants et les capacités du service de pont JMS, reportez-vous à la section JMS Bridge Service du Sun GlassFish Message Queue 4.4 Technical Overview.
Pour plus d'informations sur la configuration et la gestion des ponts JMS dans un courtier, reportez-vous à la section Configuring and Managing JMS Bridge Services du Sun GlassFish Message Queue 4.4 Administration Guide .
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 :
Pour plus d'informations sur l'architecture et les capacités du service de pont STOMP, reportez-vous à la section STOMP Bridge Service du Sun GlassFish Message Queue 4.4 Technical Overview.
Pour plus d'informations sur la configuration et la gestion d'un pont STOMP dans un courtier, reportez-vous à la section Configuring and Managing STOMP Bridge Services du Sun GlassFish Message Queue 4.4 Administration Guide.
Les améliorations supplémentaires suivantes sont également disponibles dans Message Queue 4.4 :
Le service UMS fournit maintenant des fonctions qui utilisent HTTP GET pour offrir plusieurs services :
getbrokerinfo: récupérer des informations sur le courtier.
getconfiguration : récupérer les informations relatives à la configuration UMS.
debug : activer ou désactiver l'enregistrement de débogage sur le serveur UMS.
ping : communiquer avec le courtier pour confirmer qu'il est en cours d'exécution.
Pour plus d'informations sur ces nouvelles fonctions, reportez-vous à la section Query and utility functions using HTTP GET de la page https://mq.dev.java.net/4.4-content/imqums/protocol.html.
Pour une présentation des UMS, reportez-vous à la section Universal Message Service (UMS). Pour la documentation de l'API UMS, consultez la page https://mq.dev.java.net/4.4-content/imqums/protocol.html. Pour obtenir des exemples de programmation dans plusieurs langages, reportez-vous à la page https://mq.dev.java.net/4.4-content/ums/examples/README.html.
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.
Message Queue 3.7 fournissait une fonction de journalisation d'audit qui a été supprimée dans la version 4.0. Cette fonction a été réintégrée dans Message Queue 4.4. Pour plus d'informations sur cette fonction, reportez-vous à la section Audit Logging du Sun GlassFish Message Queue 4.4 Administration Guide.
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 :
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.
La figure suivante illustre l'architecture UMS de base :
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.
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.
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 :
Pour plus d'informations sur la configuration du service UMS, reportez-vous à la page https://mq.dev.java.net/4.3-content/ums/config.html.
Pour la documentation de l'API UMS, consultez la page https://mq.dev.java.net/4.3-content/ums/protocol.html.
Pour obtenir des exemples de programmation dans plusieurs langages, reportez-vous à la page https://mq.dev.java.net/4.3-content/ums/examples/README.html.
Le service UMS est actuellement pris en charge sur les conteneurs Web suivants :
Sun GlassFish Enterprise Server, Version 2.1 et Version 3 Prelude
Tomcat, Versions 5.5 et 6.0
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 :
AIX v 6.1 ou version supérieure (les versions précédentes de AIX sont prises en charge via l'ensemble Unix/Java uniquement)
Prise en charge de DB2
IBM XL C/C++ V9.0
JDK 1.5 ou supérieur
Pour obtenir des instructions sur la procédure d'installation, reportez-vous au Chapter 4, AIX Installation, du document Sun GlassFish Message Queue 4.3 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, Distribution-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.
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é.
La prise en charge de la plate-forme mise à jour suivante sera certifiée pour Message Queue 4.3 :
Oracle 11g
Windows Server 2008
Les améliorations supplémentaires suivantes sont incluses dans Message Queue 4.3 :
Nouvelle structure de répertoires sur les plates-formes Windows
Liste des abonnements durables pour les abonnés de messages génériques
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).
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. |
Un nouvel attribut et des clés de données composites ont été ajoutés à l'API JMX, comme suit :
Un attribut NextMessageID a été ajouté au MBean de contrôle de destination afin de fournir l'ID de message JMS du prochain message envoyé à un consommateur.
Une clé NextMessageID pour date composite a été ajoutée au MBean de contrôle du gestionnaire de consommateurs pour fournir l'ID de message JMS du prochain message envoyé au consommateur.
Une clé NumMsgsPending pour date composite a été ajoutée au MBean de contrôle du gestionnaire de consommateurs pour fournir le nombre de messages distribués au consommateur.
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.
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)
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.
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.)
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.
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 fonction, reportez-vous à la section Schema Validation of XML Payload Messages du Sun GlassFish Message Queue 4.4 Developer’s Guide for Java Clients.
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.
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.
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 Java System Message Queue 4.3 Installation Guide.
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.
En plus des fonctions décrites ci-dessus, Message Queue 4.2 inclut les améliorations suivantes :
Métriques de messages produites à distance
Message Queue 4.2 comprend de nouvelles métriques de destination pouvant être utiles lors de la surveillance des destinations dans un cluster de courtiers. Dans un cluster de courtiers, les messages stockés dans une destination donnée sur un courtier donné du cluster se composent de messages produits directement vers la destination et de messages envoyés à la destination à partir de courtiers distants dans le cluster. L'analyse de l'acheminement et de la livraison des messages dans un cluster de courtiers est parfois utile pour savoir, dans une destination, combien de messages sont locaux (produits localement) et distants (produits à distance).
Deux nouvelles quantités métriques de destination physique sont incluses dans Message Queue 4.2 : Nb de messages à distance et Nbre total d'octets de message à distance. Les nouvelles quantités métriques sont disponibles via les commandes imqcmd list dst et imqcmd query dst (voir la section Viewing Physical Destination Information du Sun GlassFish Message Queue 4.4 Administration Guide) et via de nouveaux attributs JMX (voir la section Destination Monitor du Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients).
Informations relatives aux producteurs et consommateurs de messages génériques
Des informations relatives à la prise en charge de l'utilisation de caractères génériques dans les noms de destination (voir la section Destinations multiples pour un éditeur ou un abonné) sont fournies par le biais de nouvelles données de contrôle. Par exemple, le nombre de producteurs ou consommateurs de messages génériques associé à une destination est accessible via la commande imqcmd query dst (voir la section Viewing Physical Destination Information du Sun GlassFish Message Queue 4.4 Administration Guide) et via de nouveaux attributs JMX (voir la section Destination Monitor du Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients). Les informations relatives aux messages génériques sont également disponibles via les MBeans de contrôle du gestionnaire de consommateurs et de contrôle du gestionnaire des producteurs.
Prise en charge du format de nom d'utilisateur dynamique pour l'authentification client
Message Queue 4.2 a introduit la prise en charge du format de nom d'utilisateur dynamique dans l'authentification de connexion client par rapport au répertoire utilisateur LDAP. La prise en charge implique la nouvelle propriété suivante de courtier (et sa valeur) :
imq.user_repository.ldap.usrformat=dn
Cette propriété permet au courtier d'authentifier un utilisateur client par rapport à une entrée dans un répertoire utilisateur LDAP en extrayant du format du nom d'utilisateur dynamique la valeur de l'attribut spécifiée par la propriété suivante :
imq.user_repository.ldap.uidattr
Le courtier utilise la valeur de l'attribut ci-dessus comme nom de l'utilisateur dans les opérations de contrôle d'accès.
Par exemple, si imq.user_repository.ldap.uidattr=udi et un nom d'utilisateur dynamique d'authentification client est au format udi=mquser,ou=People,dc=red,dc=sun,dc=com , alors “mquser” doit être extrait pour effectuer un contrôle d'accès.
Amélioration de l'authentification JAAS
Message Queue 4.2 a introduit l'authentification JAAS par adresse IP ainsi que par nom d'utilisateur.
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.
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 :
Propriétés d'appartenance au cluster : spécifient l'appartenance du courtier à un cluster de courtiers amélioré, l'ID de ce cluster et l'ID du courtier dans le cluster.
Propriétés de base de données hautement disponible : spécifient le modèle de données persistantes (JDBC), le nom du fournisseur et les propriétés de configuration spécifiques au fournisseur.
Propriétés de détection d'échecs et de basculement : spécifient comment un échec de courtier est détecté et géré à l'aide d'un courtier de substitution.
L'implémentation de clusters de courtiers améliorés se fait selon les étapes suivantes :
Installez une base de données hautement disponible.
Installez le fichier .jar du pilote JDBC.
Créez le schéma de base de données pour le magasin de données persistant hautement disponible.
Paramétrez des propriétés haute disponibilité pour chaque courtier du cluster.
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.
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.
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.
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
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.
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.
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 :
Côté client, paramétrez les propriétés suivantes :
MQ_SERVICE_PORT_PROPERTY=1756
MQ_CONNECTION_TYPE_PROPERTY=SSL
Côté courtier, paramétrez la propriété imq.serviceName.protocolType .port comme suit :
imq.ssljms.tls.port=1756
La propriété de connexion MQ_SERVICE_PORT_PROPERTY a été reportée dans Message Queue 3.7 Mise à jour 2.
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 :
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é.
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.
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.
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.
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).
La mise en attente du courtier place ce dernier dans un état silencieux, permettant ainsi une purge des messages avant la fermeture ou le redémarrage de celui-ci. Il est impossible de créer une nouvelle connexion vers un courtier mis en attente. Pour mettre le courtier en attente, saisissez une commande similaire à l'exemple suivant.
imqcmd quiesce bkr -b Wolfgang:1756
Pour fermer le courtier après un intervalle spécifié, saisissez une commande similaire à l'exemple ci-dessous. (L'intervalle de temps spécifie le nombre de secondes à attendre avant la fermeture du courtier.)
imqcmd shutdown bkr -b Hastings:1066 -time 90
Si vous spécifiez un intervalle de temps, le courtier journalisera un message indiquant l'heure de fermeture. Par exemple :
Fermeture du courtier dans 29 secondes (29996 millisecondes)
Alors que le courtier est en attente de fermeture, son comportement est affecté de diverses manières :
Les connexions JMS administratives sont encore acceptées.
Aucune nouvelle connexion JMS n'est acceptée.
Les connexions JMS existantes continuent de fonctionner.
Le courtier n'est pas en mesure de remplacer un autre courtier dans un cluster de courtiers améliorés.
L'utilitaire imqcmd ne s'interrompt pas, il envoie la requête de fermeture au courtier et reprend directement une activité normale.
Pour détruire une connexion, saisissez une commande similaire à l'exemple suivant.
imqcmd destroy cxn -n 2691475382197166336
Utilisez la commande imqcmd list cxn ou imqcmd query cxn pour obtenir l'ID de connexion.
Pour définir une propriété système à l'aide de imqcmd, utilisez l'option -D. Ceci s'avère pratique pour définir ou ignorer des propriétés de fabrique de connexion JMS ou des propriétés système Java liées à la connexion. Exemple :
imqcmd list svc -secure -DimqSSLIsHostTrusted=true imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore -Djavax.net.ssl.trustStorePassword=mytrustword
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.
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. |
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.
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.
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.
JMS_SUN_DMQ_PRODUCING_BROKER indique le courtier dans lequel le message a été créé.
JMS_SUN_DMQ_DEAD_BROKER indique le courtier ayant marqué le message comme bloqué.
À 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