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 :

• Destinations multiples pour un éditeur ou un abonné

• Validation des schémas des messages de charge utile XML

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

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

• Prise en charge de la base de données MySQL

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.)

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 :

• taille: grand, moyen, petit, ...

• couleur. rouge, vert, bleu, ...

• forme cercle, triangle, carré, ...

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

• * correspond à un seul segment

• ** correspond à un ou plusieurs segments

• > correspond à un nombre quelconque de segments successifs

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 :

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.

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 :

• Nom de la structure xa_switch_t : sun_my_xa_switch

• Nom du gestionnaire de ressources : SUN_RM

• La bibliothèque MQ C-API doit être liée : mqcrt

• La chaîne xa_close et le format : none

• La chaîne xa_open et le format : “;” separated name=value pairs

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

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 :

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 :

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 :

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.