Transmission de la charge de messages par référence : Scénarios et exemple de code pour des applications de réacheminement

Une application d'acheminement JMS reçoit un message (via une fabrique de connexions ou une spécification d'activation s'il s'agit d'un bean géré par message), puis envoie l'objet message à une autre destination. Analysez les différents scénarios d'utilisation, puis codez les applications de réacheminement JMS afin de transmettre les charges de messages par référence, lorsque vous réacheminez les messages d'une file d'attente vers une autre sur un même serveur.

Lorsque des messages volumineux de type objet ou octet sont envoyés, la quantité de mémoire et le traitement processeur nécessaires pour sérialiser, désérialiser et copier les messages peuvent être importants. Si vous activez les propriétés de transmission de la charge de messages par référence sur une fabrique de connexions ou une spécification d'activation, vous pouvez demander au fournisseur de messagerie par défaut d'ignorer la spécification JMS 1.1 et de limiter fortement ou d'ignorer la copie de ces données.

Dans l'illustration suivante, les messages passent de la file d'attente queue1 d'un moteur de message à une application de réacheminement JMS, via une spécification d'activation de consommateur ou une fabrique de connexions. Ils sont ensuite réacheminés vers la file d'attente queue2 du même moteur de messagerie via une fabrique de connexions émettrice.

ATTENTION :
Les parties de la spécification JMS ignorées par ces propriétés sont définies pour assurer l'intégrité des données. Les applications JMS utilisant ces propriétés doivent respecter rigoureusement les règles décrites. Dans le cas contraire, l'intégrité des données risque d'être altérée.
Figure 1. Réacheminement des messages
La figure illustre le flux de messages entre deux files d'attente. De la file d'attente queue1, les messages sont transmis à l'application de réacheminement JMS via la propriété de spécification d'activation de consommateur ou de fabrique de connexions. De l'application de réacheminement JMS, les messages sont ensuite réacheminés vers la file d'attente queue2 via la propriété de fabrique de connexions émettrice.
Pour comprendre les scénarios d'utilisation et l'exemple de code associé décrits dans cette rubrique, vous devez prendre en compte les principales caractéristiques d'une application de réacheminement JMS :
  • Une application de réacheminement ne remplace pas l'objet message. Ce mécanisme est utile si l'application consigne ou enregistre uniquement le message avant de le réacheminer et indique également que le message réacheminé conserve certaines propriétés de message utiles, comme JMSCorrelationID, JMSReplyTo et JMSType.
  • Une application de réacheminement peut modifier ou remplacer la charge de messages. S'il remplace la charge, il définit la nouvelle charge dans l'objet message et modifier la référence à la charge afin qu'elle indique la nouvelle charge de messages.
  • Pour une application de réacheminement, le message réacheminé est "créé" et configuré par la fabrique de connexions ou la spécification d'activation destinataire. La fabrique de connexions émettrice est utilisée uniquement pour acheminer les messages réacheminés et n'a pas d'effet sur le contenu du message réacheminé.

Le tableau suivant décrit les quatre scénarios d'utilisation d'une application de réacheminement qui déterminent comment vous définissez les propriétés de "transmission de la charge de messages par référence". Comme la fabrique de connexions émettrice n'a pas d'incidence sur le contenu du message réacheminé, vous définissez à la fois les propriétés du destinataire et les propriétés du composant destinataire/réacheminement dans la fabrique de connexions ou la spécification d'activation destinataire.

Tableau 1. Effet des paramètres de la propriété de "transmission de la charge de messages par référence" sur les scénarios d'utilisation d'une application de réacheminement. La première colonne du tableau décrit les quatre scénarios d'utilisation d'une application de réacheminement. La deuxième colonne indique le paramètre de la propriété de consommateur pour ces scénarios d'utilisation. La troisième colonne affiche le paramètre de propriété de la connexion ou de la spécification d'activation pour les scénarios d'utilisation.
Scénario d'utilisation d'une application de réacheminement

consumerDoesNotModify
PayloadAfterGet

paramètre de propriété

producerDoesNotModify
PayloadAfterSet

(pour les fabriques de connexions) ou

forwarderDoesNotModify
PayloadAfterSet

(pour les spécifications d'activation)
Scénario 1 : L'application reçoit un message, examine la charge sans la modifier et réachemine le message sans modifier ni remplacer la charge. Activé Facultatif mais peut être activé
Scénario 2 : L'application reçoit un message, examine la charge sans la modifier, remplace la charge du message par une nouvelle charge et réachemine le message sans modifier la charge après l'appel demandant sa définition dans le message. Activé Activé
Scénario 3 : L'application reçoit un message, examine et modifie la charge, définit la charge modifiée ou d'autres données dans le message et réachemine le message sans modifier davantage la charge après l'appel demandant sa définition dans le message. Pas activé Activé
Scénario 4 : L'application reçoit un message, examine et modifie la charge, puis définit la charge modifiée ou d'autres données dans le message et modifier une nouvelle fois la charge après l'appel demandant sa définition dans le message. Pas activé Pas activé

Pour des scénarios 1, 2 et 3, vous pouvez activer une ou plusieurs propriétés de "transmission de la charge de messages par référence" dans la mesure où l'application de réacheminement peut avoir le comportement décrit dans le scénario. Pour vous aider à effectuer cette opération, voici un exemple de code que vous pouvez adapter pour l'utiliser dans vos applications.

Application de réacheminement : Scénario 1

L'application reçoit un message, examine la charge sans la modifier et réachemine le message sans modifier ni remplacer la charge.

public void onMessage (Message message)
{
   ObjectMessage oMessage = (ObjectMessage) message;
   DataObject data = oMessage.getObject();
   System.out.print(data.getXXX());
   System.out.print(data.getYYY());

   // obtenir une session pour acheminer le message reçu
   
   producer.send(message);
   session.close();
}

Application de réacheminement : Scénario 2

L'application reçoit un message, examine la charge sans la modifier, remplace la charge du message par une nouvelle charge et réachemine le message sans modifier la charge après l'appel demandant sa définition dans le message.

public void onMessage (Message message)
{
   ObjectMessage oMessage = (ObjectMessage) message;
   DataObject data = oMessage.getObject();
   System.out.print(data.getXXX());
   System.out.print(data.getYYY());

   // obtenir une session pour acheminer le message reçu
   
   message.setObject(newData);

   producer.send(message);
   session.close();
}
Pour les messages de type octet, l'application doit également veiller à n'écrire qu'un seul tableau d'octets complet dans le message.
byte [] data = myByteData; 
BytesMessage message = session.createBytesMessage(); 
message.writeBytes(data); 
data = null;	 
producer.send(message);

Application de réacheminement : Scénario 3

L'application reçoit un message, examine et modifie la charge, définit la charge modifiée ou d'autres données dans le message et réachemine le message sans modifier davantage la charge après l'appel demandant sa définition dans le message.

public void onMessage (Message message)
{
   ObjectMessage oMessage = (ObjectMessage) message;
   DataObject data = oMessage.getObject();
   System.out.print(data.getXXX());
   System.out.print(data.getYYY());

   // obtenir une session pour acheminer le message reçu

   data.setXXX(xxx);
   data.setYYY(yyy);
   message.setObject(data);

   producer.send(message);
   session.close();
}
Pour les messages de type octet, l'application doit également veiller à n'écrire qu'un seul tableau d'octets complet dans le message.
byte [] data = myByteData; 
BytesMessage message = session.createBytesMessage(); 
message.writeBytes(data); 
data = null;	 
producer.send(message);

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjn_passbyref_forward
Nom du fichier : cjn_passbyref_forward.html