Sun Java System Message Queue est un service de messagerie complet offrant 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 3.7 UR1 est une version de maintenance de Message Queue 3.6. Elle inclut des résolutions de bogues et un certain nombre d'améliorations. Cette section présente les informations suivantes :
Message Queue 3.7 UR1 inclut les nouvelles fonctionnalités suivantes :
Combinaison des fonctionnalités Platform et Enterprise dans une édition
Modifications de l'interface dans les programmes client C et C-API
Ces fonctions sont décrites dans les sous-sections suivantes.
Dans un effort de rationalisation de nos sorties produit, nous avons décidé de combiner les éditions Platform et Enterprise de Sun Java Message Queue. Par exemple pour Message Queue 3.7 UR1, il y aura une seule édition disponible, ce qui permet de supprimer efficacement les limitations de fonctionnalités dans la distribution autonome. Nous espérons que cela facilitera l'utilisation de ce produit.
La combinaison d'éditions permet également une meilleure intégration de Message Queue sur Solaris Enterprise System et fournit un droit généralisé continuel d'utiliser les fonctionnalités d'Enterprise Edition sans support, maintenance ou paiement. Comme pour les versions précédentes, nous continuerons d'offrir plusieurs options de licence pour les services de support et de maintenance. Message Queue sera toujours livré avec Java Enterprise System et Application Platform Suite. Consultez la boutique en ligne à l'adresse suivante : http://www.sun.com ou contactez votre représentant pour trouver l'option la mieux adaptée à vos besoins. Le tableau suivant décrit les étapes de mise à niveau jusqu'à l'édition unique actuelle de Message Queue.
Tableau 1–2 Étapes de mise à niveau pour Message Queue 3.7 UR1
Ancienne édition |
Étape de mise à niveau |
Commentaires |
---|---|---|
Platform Edition |
Sun Java System Message Queue 3.7 UR1 |
Toutes les fonctions (Platform et Enterprise) sont maintenant disponibles pour les clients 3.7 UR1. Des options de support sont disponibles à l'achat de la licence. |
Enterprise Edition |
Sun Java System Message Queue 3.7 UR1 |
Aucune modification de fonction. Une gamme d'options de licence et de support est disponible. |
Contrats de prise en charge de Platform Edition |
Mise à niveau sur le contrat de prise en charge Enterprise Edition |
Les contrats de prise en charge existants pour les versions précédentes de Platform Edition continueront à être renouvelés. Aucun nouveau contrat Platform Edition ne sera proposé pour les versions précédentes de Platform Edition. |
Contrats de prise en charge Enterprise Edition |
Aucune modification |
Les contrats existants continueront à être renouvelés. De nouveaux contrats seront proposés. |
Le tableau suivant décrit les modifications dans les sources de distribution pour divers produits Message Queue.
Tableau 1–3 Modifications des sources de distribution pour les produits Message Queue
Produit |
Ancienne source de distribution |
Nouvelle source de distribution |
Commentaires |
Ouvrez Message Queue |
Sans objet |
Page produits du centre de téléchargement Sun |
Téléchargement autonome. Support des communautés uniquement. Aucun contrat de prise en charge disponible. |
Message Queue Platform Edition |
Centre de téléchargement de Sun via la page produits Message Queue |
N'est plus disponible |
Seule l'édition de Message Queue qui combine les fonctions Platform et Enterprise est disponible. |
Version d'évaluation de Message Queue Enterprise Edition (via Platform Edition) |
Centre de téléchargement de Sun via la page produits Message Queue |
La licence d'évaluation n'est plus obligatoire |
N'est plus obligatoire |
Version d'évaluation de Message Queue Enterprise Edition de 90 jours (via le téléchargement ou le CD de Java Enterprise System) |
Centre de téléchargement Java Enterprise System, antérieur à la version 3 GA (Mars 2006) |
Centre de téléchargement de Solaris Enterprise System |
Licence de Solaris Enterprise System. Les options de support sont disponibles avec licence produit. (Une licence de version d'évaluation de 90 jours n'est plus obligatoire.) |
Acquisition de Message Queue Enterprise Edition via SunStore, CD, licence individuelle, licence Java Enterprise System, licence Suite, délivrés par Java Enterprise System |
Java Enterprise System ou centre de téléchargement Suite, média |
Solaris Enterprise System ou centre de téléchargement Suite, gestion des médias |
Aucune modification |
Nouvelle fonction : MQGetDestinationName()
MQGetDestinationName (const MQDestinationHandle destinationHandle, MQString * destinationName); |
Utilisez cette fonction pour obtenir le nom d'une destination. Le destinationName renvoyé est une copie que le programme appelant doit libérer via la fonction MQFreeString().
Paramètres
Un identificateur (handle) vers la destination dont vous souhaitez connaître le nom.
Paramètre de sortie pour le nom.
Cette fonction s'avère pratique lorsque l'on utilise le modèle Répondre à. Vous pouvez utiliser la fonction MQGetMessageReplyTo pour obtenir un identificateur (handle) vers la destination du message. Vous pouvez utiliser la fonction MQGetDestinationName pour obtenir le nom de la destination. Après avoir obtenu le nom de la destination, vous pouvez effectuer le traitement de vos messages selon le nom.
Nouvelle valeur d'énumération : MQ_MESSAGE
La nouvelle fonction MQMessageType, MQ_MESSAGE, permet aux clients C d'échanger des messages JMS de type Message avec d'autres clients Message Queue (C et Java) :
typedef enum _MQMessageType {MQ_TEXT_MESSAGE = 0, MQ_BYTES_MESSAGE = 1, MQ_MESSAGE = 3, MQ_UNSUPPORTED_MESSAGE = 2} MQMessageType; |
Le type MQ_MESSAGE identifie les messages comportant un en-tête et des propriétés mais pas de corps de message. Utilisez la fonction MQCreateMessage () pour créer un message de ce type.
Une nouvelle propriété de connexion, MQ_UPDATE_RELEASE_PROPERTY, qui spécifie la version de mise à jour de la version installée de Message Queue. Utilisez la fonction MQGetMetaData() pour obtenir des informations sur cette version.
Deux modifications ont été apportées au format du magasin persistant de Message Queue pour améliorer les performances. La première modification concerne le magasin de fichiers et la deuxième le magasin JDBC.
Informations de transaction dans le magasin de fichiers
Le format des informations d'état de transaction stockées dans le magasin persistant de fichiers de Message Queue a été modifié afin de réduire l'E/S disque et d'améliorer les performances des transactions JMS.
Magasin JDBC Oracle
Dans les versions précédentes de Message Queue, le schéma de stockage utilisé avec Oracle utilisait le type de données LONG RAW pour stocker les données de message. Dans Oracle 8, le type LONG RAW a fait place aux types de données BLOB. Message Queue 3.7 UR1 a lui aussi opté pour le type de données BLOB pour améliorer ses performances et ses capacités de prise en charge.
Étant donné que ces modifications ont influé sur la compatibilité du magasin, la version du magasin est passée de 350 à 370. Message Queue 3.7 UR1 prend en charge la conversion automatique du magasin persistant des anciennes versions 200 et 350 vers la version 370 - pour les magasins de fichiers et JDBC. Au premier démarrage de imqbrokerd, si l'utilitaire détecte un ancien magasin, il procédera à la migration du magasin vers le nouveau format, en abandonnant l'ancien magasin.
Si vous avez besoin d'annuler cette mise à niveau, vous pouvez désinstaller Message Queue 3.7 UR1 puis réinstaller l'ancienne version que vous utilisiez. Étant donné que l'ancienne copie du magasin est conservée, le courtier peut l'exécuter.
Les configurations matérielle et logicielle requises par Message Queue sont présentées dans le Sun Java Enterprise System Installation Guide.
Une zone représente une technologie de conteneur Solaris fournissant des environnements séparés sur une machine et isolant de manière logique les applications les unes des autres. Les zones vous permettent de créer des environnements du système d'exploitation virtuels au sein d'une instance sur le système d'exploitation Solaris. L'exécution de plusieurs applications dans différentes zones vous permet d'exécuter différentes instances ou différentes versions de la même application sur la même machine tout en conservant une administration centralisée et un partage efficace des ressources.
Cette section propose une brève description des zones et de leur utilisation avec Message Queue 3.7 UR1.
Une environnement de zones inclut une zone globale et une ou plusieurs zones non globales. Lors de la première installation de Solaris 10 sur un système, une seule zone globale est créée. Un administrateur peut créer d'autres zones non globales comme enfants de la zone globale. Chaque zone apparaît comme un système indépendant exécuté sous Solaris. Chaque zone possède sa propre adresse IP, sa propre configuration système, ses propres instances d'applications exécutées et son propre espace sur le système de fichiers.
La zone globale contient des ressources pouvant être partagées entre les zones non globales, ce qui permet une centralisation de certaines fonctions administratives. Par exemple, les packages installés dans la zone globale sont disponibles (propagés) sur toutes les zones non globales. Cela vous permet de centraliser la gestion du cycle de vie, comme l'installation, la mise à niveau et la désinstallation. De plus, l'isolation fournie par les zones non globales apporte une meilleure sécurité et vous permet d'avoir des instances configurées différemment ou différentes versions de la même application exécutées sur la même machine.
Les zones non globales sont soit des zones « whole root », soit des zones « sparse root » : votre choix de zones comme environnement pour une application dépend de la manière dont vous souhaitez équilibrer le contrôle administratif avec l'optimisation des ressources.
Les zones whole root contiennent une copie lecture/écriture du système de fichiers sur la zone globale. Les packages installés dans la zone globale sont automatiquement copiés (avec leurs informations de registre) vers les zones whole root. Cela permet de maximiser le contrôle administratif, aux dépens des ressources.
Les zones sparse root contiennent une copie lecture/écriture d'une partie du système de fichiers sur la zone globale ; les autres systèmes de fichiers sont installés comme systèmes de fichiers en lecture seule. Les packages installés dans la zone globale sont disponibles sur les zones sparse root par le biais des systèmes de fichiers en lecture seule et de la synchronisation automatique des informations de registre. Les zones sparse root optimisent le partage des ressources aux dépens de l'administration centralisée.
Les composants qui forment Java Enterprise System dépendent de certains composants partagés, ce qui entraîne certaines restrictions dans l'utilisation des zones. Dans un environnement de zones, les composants partagés dépendent des règles suivantes.
Tous les composants partagés dans une zone doivent être de la même version JES. Cette obligation entraîne trois conséquences.
Si vous souhaitez installer différentes versions de composants partagés, chaque version doit être installée dans une zone séparée.
Dans une zone, si un composant partagé est mis à niveau ou qu'une version ultérieure est installée, l'ensemble des composants partagés doit être mis à niveau.
Lorsque vous installez des composants partagés dans une zone globale, vous devez vérifier que les composants partagés dans les zones non globales sont mis à niveau au besoin.
Les composants partagés ne peuvent pas être installés dans des zones sparse root à cause du système de fichiers lecture/écriture de ces zones. Vous devez donc les installer dans une zone globale. Ces composants produit qui dépendent des composants partagés doivent d'abord être installés dans la zone globale puis propagés dans les zones non globales.
Ces conditions affectent l'installation de Message Queue car ce dernier est un produit composant de Java Enterprise System et, en tant que tel, est limité dans son utilisation de zones.
Le produit Message Queue est installé dans le répertoire /usr et doit d'abord être installé ou mis à niveau dans la zone globale.
Lorsque Message Queue est installé dans une zone globale, il est défini de manière à se propager dans toutes les zones non globales. Après avoir installé Message Queue dans la zone globale, la même version de Message Queue sera installée dans toutes les zones : si vous vous connectez à une zone et exécutez la commande pkginfo -l SUNWiqu, vous verrez le logiciel installé, de la même version que celle installée dans la zone globale. Vous pouvez ensuite exécuter les instances indépendantes du courtier Message Queue dans chaque zone puisque celles-ci ne partagent pas l'instance et les données de configuration stockées dans les répertoires /var et /etc. (La plupart des autres composants Java Enterprise System ne sont pas propagés s'ils sont installés dans la zone globale.)
Étant donné que Message Queue est propagé dans les zones non globales, l'instance globale est toujours liée aux installations dans les zones non globales. Ainsi, à chaque désinstallation ou mise à niveau de Message Queue dans la zone globale, les instances exécutées dans les zones non globales seront affectées. L'exemple suivant illustre les éventuels résultats inattendus découlant de cette opération.
Installez Message Queue 3.7 UR1 dans la zone globale. Les packages de Message Queue 3.7 UR1 sont également installés dans toutes les zones non globales.
Désinstallez Message Queue 3.7 UR1 dans une zone whole root. Ensuite, vous installez Message Queue 3.6 dans la zone whole root.
Vous possédez désormais différentes versions de Message Queue exécutées dans différentes zones - installation qui peut s'avérer fort utile.
Désinstallez Message Queue 3.7 UR1 dans la zone globale. Cela désinstallera Message Queue de toutes les autres zones - y compris l'instance Message Queue 3.6 dans la zone whole root.
Notez à chaque fois l'effet en cascade de l'installation et de la désinstallation de Message Queue dans la zone globale.
Les deux scénarios suivants vous expliquent comment installer différentes instances et versions de Message Queue dans différentes zones.
Si vous voulez installer Message Queue dans une zone whole root sur Solaris 10, Solaris 10U1, ou Solaris 10U2, vous devez d'abord mettre à niveau Lockhart dans la zone globale. Consultez la solution pour le bogue 645030 pour plus d'informations.
Installez la version souhaitée de Message Queue dans la zone globale.
Ces versions seront propagées dans toute zone non globale existante. Si vous créez des zones non globales supplémentaires, Message Queue sera également propagé dans ces zones. (Vous pouvez installer différentes instances dans les zones whole root ainsi que dans les zones sparse root, cependant, l'utilisation de zones sparse root permet une utilisation plus efficace de l'espace disque et des autres ressources).
Si vous voulez que Message Queue soit propagé dans toutes les autres zones non globales, créez ces zones maintenant.
Exécutez une instance de Message Queue dans chaque zone non globale.
Désinstallez Message Queue de la zone globale.
Créez des zones whole root et configurez chaque zone de manière à ne pas partager le répertoire /usr à l'aide de la directive suivante lors de la création de la zone.
remove inherit-pkg-dir dir=/usr
Installez différentes versions de Message Queue dans chaque zone whole root.
Notez que l'installation et la désinstallation de Message Queue dans la zone globale affectera toutes les instances (et versions) de Message Queue exécutées dans les zones whole root.