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 fonctionnalité, consultez la section Validation des schémas des messages de charge utile XML.
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 GlassFish Message Queue 4.4 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.