test

Notes de Version de Sun Java System Message Queue 4.2

Nouvelles fonctions de Message Queue 4.2 et versions récentes

Les nouvelles fonctions de Message Queue 4.2, versions 4.2 et 4.0 sont décrites dans les sections suivantes :

Nouvelles fonctions de Message Queue 4.2

Sun Java System Message Queue est un service de messagerie complet qui offre des fonctionnalités de messagerie asynchrones et fiables conformes à la spécification de messagerie Java (JMS) 1.1. En outre, Message Queue propose des fonctionnalités supplémentaires par rapport à la spécification JMS pour répondre aux besoins des déploiements d'entreprise à grande échelle.

Message Queue 4.2 est une version mineure apportant un certain nombre d'améliorations de fonctions et de corrections de bogues. Cette section explique comment installer ou mettre à niveau Message Queue 4.2 et décrit les nouvelles fonctions incluses dans cette version :

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

Destinations multiples pour un éditeur ou un abonné

Dans Message Queue 4.2, un éditeur peut maintenant 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 du nom de la destination du sujet symbolique se compose de multiples segments, dans lesquels les caractères génériques (*, **, >) peuvent représenter un ou plusieurs segments du nom. Par exemple, supposons que vous ayez un schéma de nommage de destination comme suit :

taille.couleur. forme

où les segments de nom du sujet avoir les valeurs suivantes :

Message Queue prend en charge les caractères génériques suivants :

Vous pouvez par conséquent indiquer de multiples destinations de sujet comme suit :

grand.*.cercle représenterait :

grand.rouge.cercle
grand.vert.cercle
...

**.carré représenterait tous les noms se terminant par .carré , par exemple :


petit.vert.carré
moyen.bleu.carré
...

petit.> représenterait tous les noms de destination commençant par petit., par exemple :


petit.bleu.cercle
petit.rouge.carré
...

Pour utiliser cette fonction de multiples destinations, vous créez des destinations de sujet à l'aide du schéma de nommage similaire à la description ci-dessus. Les applications client peuvent ensuite créer des éditeurs ou des consommateurs en utilisant des noms de destination symboliques. Exemple :

...
Chaîne DEST_LOOKUP_NAME = "grand.*.cercle";
Sujet t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);
...
Chaîne DEST_LOOKUP_NAME = "**.carré";
Sujet t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

Dans le premier exemple, le courtier placera une copie du message sous une quelconque destination correspondant au nom symbolique grand.*.cercle. Dans le second exemple, un abonné sera créé si au moins une destination correspond au nom symbolique **.carré et il recevra des messages de toutes les destinations correspondant à ce nom symbolique. Si aucune destination ne correspond au nom symbolique, l'éditeur ne sera créé que lorsqu'il existera une destination.

Si un administrateur crée des destinations supplémentaires correspondant à un nom symbolique, alors les éditeurs génériques créés à l'aide du nom symbolique publieront par la suite vers cette destination et les éditeurs génériques créés à l'aide de ce nom symbolique recevront par la suite des messages à partir de cette destination.

De plus, les outils d'administration de Message Queue, outre le fait de signaler le nombre total d'éditeurs (producteurs) et d'abonnés (consommateurs) pour une destination de sujet, signaleront également s'ils existent, le nombre des éditeurs génériques et des abonnés génériques (y compris, pour chacun, leurs noms de destination symboliques).

Validation des schémas des messages de charge utile XML

Cette nouvelle fonction de Message Queue 4.2 permet de valider le contenu d'un message XML texte (pas objet) XML 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.)

Les applications client utilisant cette nouvelle fonction doivent procéder à une mise à niveau de Java version SE à JRE version 1.5 ou supérieure.

Afin d'activer la validation du schéma XML, vous devez définir les propriétés de destination physiques suivantes :

Tableau 1–5 Propriétés de destination physiques pour la validation du schéma XML

Propriétés 

Type 

Valeur par défaut 

Description 

validateXMLSchemaEnabled

Booléen 

false

Validation du schéma XML activée ? 

Si l'option est définie non définie ou définie sur false, alors la validation du schéma XML n'est pas activée pour la destination.

XMLSchemaURIList

String (Chaîne) 

null 

Liste des chaines URI du document (XSD) du schéma XML, séparées par des espaces  

Les URI pointent vers l'emplacement d'un ou plusieurs XSD à utiliser pour la validation du schéma XML, si cette option est activée.  

Mettez cette valeur entre guillemets si plusieurs URI sont spécifiés. 

Exemple : 

“http://foo/flap.xsd http://test.com/test.xsd”

Si cette propriété n'est pas définie ou null et si la validation XML est activée, la validation XML est effectuée à l'aide d'un DTD spécifié dans le document XML. 

reloadXMLSchemaOnFailure

Booléen 

false

Rechargement du schéma XML en cas d'échec activé ? 

Si l'option est définie non définie ou définie sur false, alors le schéma n'est pas rechargé en cas d'échec de la validation. 

Lorsque la validation XML est activée, l'exécution du client Message Queue tentera de valider un message XML par rapport aux XSD spécifiés(ou par rapport au DTD, si aucun XSD n'est spécifié) avant de l'envoyer au courtier. S'il est impossible de localiser le schéma spécifié ou si le message ne peut pas être validé, le message n'est pas envoyé et une exception est émise.

Les propriétés de validation XML peuvent être définies lors de la création de la destination ou au moment de la mise à jour en utilisant la commande imqcmd create dst ou imqcmd update dst, respectivement. Les propriétés de validation XML doivent être définies lorsqu'une destination est inactive : c'est-à-dire lorsqu'il n'y a ni consommateurs ni producteurs et lorsqu'il n'y a pas de messages dans la destination.

Remarque –

Si un XSD n'est pas accessible lors de l'exécution, il peut s'avérer nécessaire de modifier la XMLSchemaURIList pendant qu'une destination est active.

Si l'une quelconque des propriétés de validation XML alors qu'une destination est active (par exemple, si un producteur est connecté à la destination), ce changement prendra effet lors de la prochaine connection du producteur au courtier. De même, si un XSD est modifié, à la suite d'un changement des configurations requises de l'application, toutes les applications client produisant des messages XML sur la base du XSD modifié doivent se reconnecter au courtier.

Si la propriété reloadXMLSchemaOnFailure est définie comme true que la validation XML échoue, alors l'exécution du client Message Queue tentera de recharger le XSD avant d'essayer à nouveau de valider un message. L'exécution du client émettra une exception si la validation échoue en utilisant le SXD rechargé.

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, le C-API de Message Queue prend désormais en charge l'interface XA (entre un gestionnaire de transactions distribuées et Message Queue sous forme de gestionnaire de ressources conforme à XA), permettant aux clients 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.

Informations publiques

La spécification de l'interface X/Open XA requiert les informations publiques suivantes concernant le gestionnaire de ressources conforme à XA de Message Queue :

Les paires de nom/valeur suivantes sont prises en charge :

Tableau 1–6 Paires de nom/valeur du gestionnaire de ressources de Message Queue

Nom 

Valeur 

Description 

Par défaut 

adresse 

hôte:port

L'hôte :port du service Portmapper du courtier. 

localhost:7676

Identifiant (username) 

chaîne 

L'identifiant (username) de connexion au courtier 

hôte (guest)

mot de passe (password) 

chaîne (string) 

Le mot de passe de l'identifiant 

hôte

conntype 

TCP ou SSL 

Le type de protocole de la connexion au courtier 

TCP

Hôte sécurisé 

true/false 

détermine si l'hôte du courtier est sécurisé ou non (uniquement applicable pour conntype=SSL) 

true

certdbpath 

chaîne 

Le chemin complet vers le répertoire qui contient un certificat NSS et des fichiers de base de données clé 

non défini 

clientid 

chaîne 

Requis uniquement pour les abonnements JMS durables 

non défini 

se reconnecte 

entier 

Le nombre de tentatives de reconnexion au courtier (0 signifie aucune reconnexion) 

0

Exemples de programmation

Pour programmer une application utilisant des transactions distribuées, vous créez un service côté serveur qui s'exécute dans l'environnement du gestionnaire de transactions un code côté client appellant les API du gestionnaires de transactions. Message Queue 4.2 fournit des exemples de programmation sur la base du gestionnaire de transactions Tuxedo. Ces exemples sont situés dans le répertoire de programmes d'exemples sur chaque plate-forme, dans le répertoire ./C/tuxedo.

Ce répertoire comprend un fichier README qui explique comment paramétrer Tuxedo pour utiliser le gestionnaire de ressources de Message Queue et comment développer les programmes d'exemples suivants dans l'environnement Tuxedo :

Programme d'exemples 

Description 

jmsserver.c

Implémente les services Tuxedo qui envoient et reçoivent des messages à l'aide de Message Queue. 

jmsclient_sender.c

Client Tuxedo qui utilise le service de génération de messages dans le programme jmsserver.c .

jmsclient_receiver.c

Client Tuxedo qui utilise le service de réception de messages dans le programme jmsserver.c .

async_jmsserver.c

Implémente un service Tuxedo qui consomme de façon asynchrone des messages en utilisant Message Queue. 

jmsclient_async_receiver.c

Client Tuxedo qui utilise le service de consommation de messages asynchrones dans le programme jmsserver.c .

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 maintenir votre logiciel et matériel Sun.

Lors 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 transmis 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 votre logiciel et 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 des fonctions.

L'écran suivant du programme d'installation a été ajouté à Message Queue 4.2 pour l'enregistrement à Sun Connection :

Écran d'enregistrement à Sun Connection.

Pour vous enregistrer, vous devez avoir un compte Sun Online ou en créer un. Si vous n'avez pas encore de compte, le programme d'installation affiche l'écran suivant pour créer un compte Sun Online :

Écran de création de compte Sun Online.

Vous pouvez enregistrer Message Queue au cours de l'installation en utilisant les écrans ci-dessus, ou attendre que l'installation soit terminée pour exécuter le programme d'installation sous le mode enregistrement uniquement, comme suit :

# installer -r

Le mode enregistrement uniquement nécessite que Message Queue 4.2 soit déjà installé et affichera uniquement les écrans du programme d'installation liés à l'enregistrement.

Prise en charge de la base de données MySQL

Message Queue 4.2 prend en charge la base de données MySQL comme un 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 le magasin de données partagées hautement nécessaire à un cluster de coutiersà haute disponibilité. Pour de plus amples informations sur la configuration de Message Queue pour utiliser MySQL, reportez-vous à Configuring a JDBC-Based Data Store du Sun Java System Message Queue 4.2 Administration Guide et également aux High-Availability Cluster Properties du Sun Java System Message Queue 4.2 Administration Guide.

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 fonctionnalités 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 des clusters de courtiers haute disponibilité. 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 haute disponibilité 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 les utilise pour le relayer et délivrer les messages).

La nouvelle 'implémentation haute disponibilité de Message Queue 4.1 utilise un magasin de données basé sur JDBC partagé : Le courtier d'un cluster n'a plus de magasin de données persitantes propre mais partage la même base de données (conforme à JDBC) avec tous les autres courtiers du cluster. Si un courtier particulier échoue, un autre courtier du cluster prend sa relève pour acheminer et livrer ses message. 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 coutiers haute disponibilité de 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 haute disponibilité 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 courtier haute disponibilité et obtenir une comparaison de ceux-ci par rapport aux clusters conventionnels, reportez-vous au Chapitre 4, Broker Clusters du Sun Java System Message Queue 4.2 Technical Overview. Pour obtenir des informations procédurales et référentielles sur les clusters de courtiers haute disponibilité, reportez-vous au Chapitre 8, Managing Broker Clusters du Sun Java System Message Queue 4.2 Administration Guide et à la section Cluster Configuration Properties du Sun Java System Message Queue 4.2 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 haute disponibilité, 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 à un service d'authentification conforme à JAAS et une explication sur la façon de configurer le courtier pour utiliser un tel service, reportez-vous à Using JAAS-Based Authentication du Sun Java System Message Queue 4.2 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 haute disponibilité. Pour cette raison, le format du magasin de données basé sur JDBC— est augmenté pour passer à la version 410. Les versions de format 350, 370 et 400 sont migrées automatiquement 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 changements n'ont été apportés à 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 usuelle. 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 d'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 qui sont à l'état suivant : STARTED, FAILED, INCOMPLETE, COMPLETE et 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 à l'état 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 ayant démarré la transaction et spécifie l'heure de création de cette dernière. À l'aide de ces informations, un 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

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'aministration.

Pour de plus amples informations, reportez-vous au Sun Java System Message Queue 4.2 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 13, Command Line Reference du Sun Java System Message Queue 4.2 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 sa version 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.


requête imqdbmgr
 

[04/Oct/2005:15:30:20 PDT] Utilisation du magasin persistant intégré :
        version=400
        id du courtier=Mozart1756
        url de connexion à la base de données=jdbc:oracle:thin:@Xhome:1521:mqdb
        utilisateur de la base de données=scott
Exécution en mode autonome.
Les tables de base de données ont déjà été créées.

Prise en charge du fournisseur JDBC

Dans Message Queue 4.0, Apache Derby Version 10.1.1 est désormais supporté 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 basé sur JDBC a été augmenté vers 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 subit 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