Spring FrameworkJMS

Traducteur:  Thierry TEMPLIER
(Dernière date de traduction:  02/01/2005)
Relecteur:  
(Dernière date de relecture:  )
Index des chapitres

Légende:
       à revoir
       non compris
       à faire
       non traduit ( laissé tel quel )

chapter
+ titleRef.   /chapter[1]/translation[1]
OriginalTraduction
JMSJMS
sect1
+ titleRef.   /chapter[1]/sect1[1]/translation[1]
OriginalTraduction
IntroductionIntroduction
+ paraRef.   /chapter[1]/sect1[1]/translation[2]
OriginalTraduction
Spring provides a JMS abstraction framework that simplifies the use of the JMS API and shields the user from differences between the JMS 1.0.2 and 1.1 APIs. Spring fournit un framework qui permet de s'abstraire de JMS et simplifie l'utilisation de cette API. Il permet également de masquer à l'utilisateur les différences entre les APIs JMS en version 1.0.2 et 1.1.
+ paraRef.   /chapter[1]/sect1[1]/translation[3]
OriginalTraduction
JMS can be roughly divided into two areas of functionality, production and consumption of messages. In a J2EE environment, the ability to consume messages asynchronously is provided for by message-driven beans while in a standalone application this is provided for by the creation of MessageListeners or ConnectionConsumers. The functionality in JmsTemplate is focused on producing messages. Future releases of Spring will address asynchronous message consumption in a standalone environment. Spring peut être divisé en deux types de fonctionnalités, production et consommation de messages. En J2EE, la possibilité de consommer des messages de manière asynchrone est réalisée grâce aux EJBs "Message-Driven" (MDB) alors que, dans une application autonome, cette fonctionnalité est permise par la création de MessageListeners ou de ConnectionConsumers.
+ paraRef.   /chapter[1]/sect1[1]/translation[4]
OriginalTraduction
The package org.springframework.jms.core provides the core functionality for using JMS. It contains JMS template classes that simplifies the use of the JMS by handling the creation and release of resources, much like the JdbcTemplate does for JDBC. The design principal common to Spring template classes is to provide helper methods to perform common operations and for more sophisticated usage, delegate the essence of the processing task to user implemented callback interfaces. The JMS template follows the same design. The classes offer various convenience methods for the sending of messages, consuming a message synchronously, and exposing the JMS session and message producer to the user. Le package org.springframework.jms.core fournit les fonctionnalités de base pour utiliser JMS. Il comprend la classe template JMS qui simplifie l'utilisation de JMS en se chargeant de la création et de la libération des ressources de la même manière que la classe JdbcTemplate le réalise pour JDBC. Le point commun dans la conception des classes de template de Spring est de fournir des méthodes facilitant l'exécution des opérations communes...
+ paraRef.   /chapter[1]/sect1[1]/translation[5]
OriginalTraduction
The package org.springframework.jms.support provides JMSException translation functionality. The translation converts the checked JMSException hierarchy to a mirrored hierarchy of unchecked exceptions. If there are any provider specific subclasses of the checked javax.jms.JMSException, this exception is wrapped in the unchecked UncategorizedJmsException. The package org.springframework.jms.support.converter provides a MessageConverter abstraction to convert between Java objects and JMS messages. The package org.springframework.jms.support.destination provides various strategies for managing JMS destinations, such as providing a service locator for destinations stored in JNDI. Le package org.springframework.jms.support fournit la fonctionnalité de translation des exceptions JMSException. Celui-ci convertit la hiérarchie des exceptions checkées dans une hiérarchie correspondante d'exceptions non checkées. Si un fournisseur a des sous exceptions spécifiques de la classe javax.jms.JMSException, celles-ci seront encapsulées dans l'exception non checkée UncategorizedJmsException. Le package org.springframework.jms.support.converter fournit une abstraction MessageConverter pour convertir des objets java en messages JMS. Le package org.springframework.jms.support.destination fournit différentes stratégies pour gérer les destinations JMS en fournissant, par exemple, un service de localisation des destinations stockées dans JNDI.
+ paraRef.   /chapter[1]/sect1[1]/translation[6]
OriginalTraduction
Finally, the package org.springframework.jms.connection provides an implementation of the ConnectionFactory suitable for use in standalone applications. It also contains an implementation of Spring's PlatformTransactionManager for JMS. This allows for integration of JMS as a transactional resource into Spring's transaction management mechanisms. Pour finir, le package org.springframework.jms.connection fournit une implémentation de l'interface ConnectionFactory utilisable dans les applications autonomes. Il contient également une implémentation de l'interface de Spring, PlatformTransactionManager, pour JMS. Cela permet l'intégration de JMS en tant que ressource transactionnelle dans les mécanismes de gestions des transactions de Spring.
sect1
+ titleRef.   /chapter[1]/sect1[2]/translation[1]
OriginalTraduction
Domain unificationUnification des domaines
+ paraRef.   /chapter[1]/sect1[2]/translation[2]
OriginalTraduction
There are two major releases of the JMS specification, 1.0.2 and 1.1. JMS 1.0.2 defined two types of messaging domains, point-to-point (Queues) and publish/subscribe (Topics). The 1.0.2 API reflected these two messaging domains by providing a parallel class hierarchy for each domain. Consequentially, a client application was domain specific in the use of the JMS API. JMS 1.1 introduced the concept of domain unification that minimized both the functional differences and client API differences between the two domains. As an example of a functional difference that was removed, if you use a JMS 1.1 provider you can transactionally consume a message from one domain and produce a message on the other using the same Session. La spécification JMS a deux versions majeures: 1.0.2 et 1.1. La version 1.0.2 définit deux domaines de messages, point à point (queue) et publication/souscription (sujet). L'API en version 1.0.2 reflète ces deux aspects de messages en fournissant des classes similaires pour chaque domaine. De ce fait, une application cliente est spécifique à un domaine lors de l'utilisation de l'API JMS. JMS en version 1.1 introduit une unification des domaines qui minimisent aussi bien les différences fonctionnelles que les différences au niveau de l'API cliente JMS entre les deux domaines. Pour illustrer ceci, si vous utilisez un fournisseur supportant la version 1.1 de JMS, vous pouvez dans une même transaction récupérer un message d'un domaine et en produire un autre dans un autre domaine tout en utilisant la même Session
+ paraRef.   /chapter[1]/sect1[2]/translation[3]
OriginalTraduction
The JMS 1.1 specification was released in April 2002 and incorporated as part of J2EE 1.4 in November 2003. As a result, most application servers that are currently in use are only required to support JMS 1.0.2. La version 1.1 de la spécification JMS a été publié en avril 2002 et ajoutée à J2EE en novembre 2003. De ce fait, beaucoup de serveurs d'application communément utilisés ne supportent que la version 1.0.2 de JMS.
sect1
+ titleRef.   /chapter[1]/sect1[3]/translation[1]
OriginalTraduction
JmsTemplateJmsTemplate
+ paraRef.   /chapter[1]/sect1[3]/translation[2]
OriginalTraduction
Two implementations of the JmsTemplate are provided. The class JmsTemplate uses the JMS 1.1 API and the subclass JmsTemplate102 uses the JMS 1.0.2 API.Deux implémentations de JmsTemplate sont fournis. La classe JmsTemplate utilise l'API JMS version 1.1 et la sous classe JmsTemplate102 l'utilise en version 1.0.2.
+ paraRef.   /chapter[1]/sect1[3]/translation[3]
OriginalTraduction
Code that uses the JmsTemplate only needs to implement callback interfaces giving them a clearly defined contract. The MessageCreator callback interface creates a message given a Session provided by the calling code in JmsTemplate. In order to allow for more complex usage of the JMS API, the callback SessionCallback provides the user with the JMS session and the callback ProducerCallback exposes a Session and MessageProducer pair. Le code utilisant JmsTemplate doit seulement implémenter des interfaces de rappel qui ont des contrats clairement définis. L'interface MessageCreator crée un message à partir d'une Session fourni par le code appelant de JmsTemplate. Afin de permettre une utilisation plus complexe de l'API JMS, l'interface SessionCallback fournit à l'utilisateur une Session JMS et l'interface ProducerCallback, une Session et un MessageProducer.
+ paraRef.   /chapter[1]/sect1[3]/translation[4]
OriginalTraduction
The JMS API exposes two types of send methods, one that takes delivery mode, priority, and time-to-live as quality of service (QOS) parameters and one that takes no QOS parameters which uses default values. Since there are many send methods in JmsTemplate, the setting of the QOS parameters have been exposed as bean properties to avoid duplication in the number of send methods. Similarly, the timeout value for synchronous receive calls is set using the property setReceiveTimeout. L'API JMS fournit deux types de méthodes d'envoi, une qui prend des paramètres de qualité de service tels que le mode de livraison la priorité et la durée de vie (QOS) et une qui n'en prend aucun et se base sur les valeurs par défaut. Puisque la classe JmsTemplate fournit plusieurs méthodes d'envoi, la configuration des paramètres de qualité de service a été permise par le biais des propriétés de beans pour éviter les duplications. De la même manière, la valeur de délai d'expiration (timeout) pour les appels synchrones est positionné avec la propriété setReceiveTimeout.
+ paraRef.   /chapter[1]/sect1[3]/translation[5]
OriginalTraduction
Some JMS providers allow the setting of default QOS values administratively through the configuration of the ConnectionFactory. This has the effect that a call to MessageProducer's send method send(Destination destination, Message message) will use QOS different default values than those specified in the JMS specification. Therefore, in order to provide consistent management of QOS values, the JmsTemplate must be specifically enabled to use its own QOS values by setting the boolean property isExplicitQosEnabled to true. Certains fournisseurs JMS permettent la configuration des valeurs par défaut de la qualité de service administrativement via la configuration de la ConnectionFactory. Cela implique que l'appel de la méthode send(Destination destination, Message message) de la classe MessageProducer utilisera des valeurs par défaut différentes de celles de la spécification JMS. De plus, pour garantir une gestion conforme des valeurs de qualité de service, la classe JmsTemplate doit être spécifiquement activé pour pouvoir utiliser ses propres valeurs en spécifiant à vrai (true) la valeur de la propriété isExplicitQosEnabled.
sect2
+ titleRef.   /chapter[1]/sect1[3]/sect2[1]/translation[1]
OriginalTraduction
ConnectionFactoryConnectionFactory
+ paraRef.   /chapter[1]/sect1[3]/sect2[1]/translation[2]
OriginalTraduction
The JmsTemplate requires a reference to a ConnectionFactory. The ConnectionFactory is part of the JMS specification and serves as the entry point for working with JMS. It is used by the client application as a factory to create connections with the JMS provider and encapsulates various configuration parameters, many of which are vendor specific such as SSL configuration options. L'utilisation de JmsTemplate nécessite une référence à une ConnectionFactory. L'interface ConnectionFactory fait partie intégrante de la spécification JMS. Elle est utilisée par l'application client comme une fabrique pour créer des connexions avec le fournisseur JMS et encapsuler les différents paramètres de configuration, dont beaucoup sont spécifiques à celui-ci comme ceux de la configuration de SSL.
+ paraRef.   /chapter[1]/sect1[3]/sect2[1]/translation[3]
OriginalTraduction
When using JMS inside an EJB the vendor provides implementations the JMS interfaces so that they can participate in declarative transaction management and perform pooling of connections and session. In order to use this implementation, J2EE containers typically require that you declare a JMS connection factory as a resource-ref inside the EJB or servlet deployment descriptors. To ensure the use of these features with the JmsTemplate inside an EJB, the client application should ensure that it references the managed implementation of the ConnectionFactory. Pour utiliser JMS dans un EJB, le vendeur fournit des implémentations pour les interfaces JMS et, de ce fait, celles-ci peuvent participer dans une gestion transactionnelle déclarative et réaliser un pooling de connexions et de sessions. Pour utiliser cette implémentation, les conteneurs J2EE imposent typiquement la déclaration de la fabrique de connexion JMS en tant que resource-ref dans les descripteurs de déploiment des EJBs et servlets. Pour utiliser cette fonctionnalité avec JmsTemplate dans un EJB, l'application client devrait vérifier qu'il référence bien une implémentation managée de la ConnectionFactory.
+ paraRef.   /chapter[1]/sect1[3]/sect2[1]/translation[4]
OriginalTraduction
Spring provides an implementation of the ConnectionFactory interface, SingleConnectionFactory, that will return the same Connection on all createConnection calls and ignore calls to close. This is useful for testing and standalone environments so that the same connection can be used for multiple JmsTemplate calls that may span any number of transactions. SingleConnectionFactory takes a reference to a standard ConnectionFactory that would typically comes from JNDI. Spring fournit une implémentation de l'interface ConnectionFactory, SingleConnectionFactory, qui retourne toujours la même connexion sur tous les appels à createConnection et ignore ceux sur close.. Cela est très utile pour tester et également dans les environnements autonomes, puisque cette même connexion peut être partagée par différents appels à JmsTemplate.
sect2
+ titleRef.   /chapter[1]/sect1[3]/sect2[2]/translation[1]
OriginalTraduction
Transaction ManagementGestion des transactions
+ paraRef.   /chapter[1]/sect1[3]/sect2[2]/translation[2]
OriginalTraduction
Spring provides a JmsTransactionManager that manages transactions for a single JMS ConnectionFactory. This allows JMS applications to leverage the managed transaction features of Spring as described in Chapter 7. The JmsTransactionManager binds a Connection/Session pair from the specified ConnectionFactory to the thread. However, in a J2EE environment the ConnectionFactory will pool connections and sessions, so the instances that are bound to the thread depend on the pooling behavior. In a standalone environment, using Spring's SingleConnectionFactory will result in a using a single JMS Connection and each transaction having its own Session. The JmsTemplate can also be used with the JtaTransactionManager and an XA-capable JMS ConnectionFactory for performing distributed transactions. Spring fournit une classe JmsTransactionManager qui gère les transactions pour une unique ConnectionFactory JMS. Cela permet aux applications JMS d'utiliser les possibilités de Spring en matière de gestion des transactions comme décrit dans le chapitre 7. La classe JmsTransactionManager associe la paire Connection/Session d'une ConnectionFactory à un thread. Cependant, dans un environnement J2EE, les ConnectionFactory peuvent gérer des pools de connexions et de sessions, et de ce fait, les instances associées au thread dépendent du comportement du pool. Dans un environnement autonome, utiliser SingleConnectionFactory entrainera l'utilisation d'une unique connexion JMS et chaque transaction aura sa propre session. La classe JmsTemplate peut également être utilisée avec la classe JtaTransactionManager et une ConnectionFactory JMS supportant le protocole XA pour effectuer des transactions globales.
+ paraRef.   /chapter[1]/sect1[3]/sect2[2]/translation[3]
OriginalTraduction
Reusing code across a managed and unmanaged transactional environment can be confusing when using JMS API to create a Session from a Connection. This is because the JMS API only has only one factory method to create a Session and it requires values for the transaction and acknowledgement modes. In a managed environment, setting these values in the responsibility of the environments transactional infrastructure, so these values are ignored by the vendor's wrapper to the JMS Connection. When using the JmsTemplate in an unmanaged environment you can specify these values though the use of the properties SessionTransacted and SessionAcknowledgeMode. When using a PlatformTransactionManager with JmsTemplate, the template will always be given a transactional JMS Session. Réutiliser du code sur des environnements autonomes et non autonomes, peut être source de confusion lors de la création d'une Session à partir d'une Connection. Cela vient du fait que l'API JMS a une fabrique unique pour créer une Session et elle nécessite des paramètres pour les modes transactionnel et d'acquittement. Dans un environnement non autonome, positionner ces valeurs... Quand la classe JmsTemplate est utilisée dans un environnement non autonome, il est possible de spécifier ces valeurs par le biais de l'utilisation des propriétés SessionTransacted et SessionAcknowledgeMode. Quand est utilisé une implémentation de PlatformTransactionManager avec la classe JmsTemplate, le template recevra toujours une session JMS transactionnelle.
sect2
+ titleRef.   /chapter[1]/sect1[3]/sect2[3]/translation[1]
OriginalTraduction
Destination ManagementGestion des destinations
+ paraRef.   /chapter[1]/sect1[3]/sect2[3]/translation[2]
OriginalTraduction
Destinations, like ConnectionFactories, are JMS administered objects that can be stored and retrieved in JNDI. When configuring a Spring application context one can use the JNDI factory class JndiObjectFactoryBean to perform dependency injection on your object's references to JMS destinations. However, often this strategy is cumbersome if there are a large number of destinations in the application or if there are advanced destination management features unique to the JMS provider. Examples of such advanced destination management would be the creation of dynamic destinations or support for a hierarchical namespace of destinations. The JmsTemplate delegates the resolution of a destination name to a JMS destination object to an implementation of the interface DestinationResolver. DynamicDestinationResolver is the default implementation used by JmsTemplate and accommodates resolving dynamic destinations. A JndiDestinationResolver is also provided that acts as a service locator for destinations contained in JNDI and optionally falls back to the behavior contained in DynamicDestinationResolver. Les destinations, comme les ConnectionFactory, sont des objets JMS administrés qui peuvent être stockés et récupérés dans JNDI. Au moment de configurer un contexte d'application dans Spring, il est possible d'utiliser la classe de fabrique JndiObjectFactoryBean pour réaliser de l'injection de dépendance sur les références d'objets avec des destinations JMS. Cependant, cette façon de faire est déconseillée s'il y a un grand nombre de destinations dans l'application ou s'il y a des fonctionnalités avancées spécifiques au fournisseur JMS pour la gestion des destinations. Un exemple de gestion de ce type serait la création de destinations dynamiques ou le support d'espaces de nommage hiérarchique pour les destinations. La classe JmsTemplate délègue la résolution du nom de la destination d'un objet JMS à une implémentation de l'interface DestinationResolver. DynamicDestinationResolver est l'implémentation par défaut utilisée par la classe JmsTemplate et qui permet de résoudre les destinations dynamiques. Une classe JndiDestinationResolver est également fournie pour jouer le rôle de service de localisation des destinations contenues dans JNDI et peut également rebasculer sur le comportement de DynamicDestinationResolver.
+ paraRef.   /chapter[1]/sect1[3]/sect2[3]/translation[3]
OriginalTraduction
Quite often the destinations used in a JMS application are only known at runtime and therefore can not be administratively created when the application is deployed. This is often because there is shared application logic between interacting system components that create destinations at runtime according to a well known naming convention. Even though the creation of dynamic destinations are not part of the JMS specification, most vendors have provided this functionality. Dynamic destinations are created with a name defined by the user which differentiates them from temporary destinations and are often not registered in JNDI. The API used to create dynamic destinations varies from provider to provider since the properties associated with the destination are vendor specific. However, a simple implementation choice that is sometimes made by vendors is to disregard the warnings in the JMS specification and to use the TopicSession method createTopic(String topicName) or the QueueSession method createQueue(String queueName) to create a new destination with default destination properties. Depending on the vendor implementation, DynamicDestinationResolver may then also create a physical destination instead of only resolving one. Très souvent, les destinations utilisées dans une application JMS ne sont connues uniquement qu'au moment de l'exécution et, de ce fait, ne peuvent pas être créées administrativement quand l'application est déployée. Ceci est dû au fait que la logique applicative est partagée par les composants intéragissant dans le système qui créent des destinations au moment de l'exécution en suivant une converions de nommage bien définie et connue. Même si la création dynamique de destinations ne fait pas partie de la spécification JMS, la plupart des fournisseurs offrent cette fonctionnalité. Les destinations dynamiques sont créées avec avec un nom défini par l'utilisateur, ce qui les différencient des destinations temporaires et ne sont parfois pas mises dans JNDI. L'API utilisée pour les créer varie d'un fournisseur à l'autre puisque les propriétés associées lui sont spécifiques. Cependant un choix simple d'implémentation qui est souvent fait par les fournisseurs, est de négliger les mises en garde de la spécification JMS et d'utiliser la méthode createTopic(String topicName) de l'interface TopicSession ou la méthode createQueue(String queueName) de l'interface QueueSession pour créer une nouvelle destination avec les propriétés par défaut des destinations. Suivant l'implémentation du vendeur, DynamicDestinationResolver peut aussi créer une destination physique ay lieu de seulement la résoudre.
+ paraRef.   /chapter[1]/sect1[3]/sect2[3]/translation[4]
OriginalTraduction
The boolean property PubSubDomain is used to configure the JmsTemplate with knowledge of what JMS domain is being used. By default the value of this property is false, indicating that the point-to-point domain, Queues, will be used. In the 1.0.2 implementation the value of this property determines if the JmsTemplate's send operations will send a message to a Queue or to a Topic. This flag has no effect on send operations for the 1.1 implementation. However, in both implementations, this property determines the behavior of resolving dynamic destination via implementations of createTopic(String topicName) de l'interface DestinationResolver. La propriété bouléenne PubSubDomain est utilisée pour configurer la classe JmsTemplate en ayant la connaissance du domaine. Par défaut, la valeur de cette propriété est fausse (false) indiquant ainsi que le domaine point à point sera utilisé. Dans l'implémentation relative à la version 1.0.2, la valeur de cette propriété détermine si les opérations d'envoi de JmsTemplate enverront un message à une queue ou une matière. Ce champ n'a aucun effet sur les opérations d'envoi pour l'implémentation relative à la version 1.1. Cependant, dans les deux implémentations, cette propriété détermine le comportement pour la résolution dynamique des destinations via les implémentations de la méthode createTopic(String topicName) de l'interface DestinationResolver.
+ paraRef.   /chapter[1]/sect1[3]/sect2[3]/translation[5]
OriginalTraduction
You can also configure the JmsTemplate with a default destination via the property DefaultDestination. The default destination will be used with send and receive operations that do not refer to a specific destination. Il est possible de configurer également la classe JmsTemplate avec une destination par défaut au moyen de la propriété DefaultDestination. Celle-ci sera utilisée avec les opérations d'envoi et de réception qui ne se réferre par à de destinations spécifiques.
sect1
+ titleRef.   /chapter[1]/sect1[4]/translation[1]
OriginalTraduction
Using the JmsTemplateUtilisation de JmsTemplate
+ paraRef.   /chapter[1]/sect1[4]/translation[2]
OriginalTraduction
To get started using the JmsTemplate you need to select either the JMS 1.0.2 implementation JmsTemplate102 or the JMS 1.1 implementation JmsTemplate. Check your JMS provider to determine what version is supported. Pour débuter avec JmsTemplate, il faut choisir l'implémentation JmsTemplate102 pour la version 1.0.2 ou JmsTemplate pour la version 1.1. Interroger votre fournisseur JMS pour déterminer quelle version est supportée.
sect2
+ titleRef.   /chapter[1]/sect1[4]/sect2[1]/translation[1]
OriginalTraduction
Sending a messageEnvoi d'un message
+ paraRef.   /chapter[1]/sect1[4]/sect2[1]/translation[2]
OriginalTraduction
The JmsTemplate contains many convenience methods to send a message. There are send methods that specify the destination using a javax.jms.Destination object and those that specify the destination using a string for use in a JNDI lookup. The send method that takes no destination argument uses the default destination. Here is an example that sends a message to a queue using the 1.0.2 implementation. La classe JmsTemplate contient beaucoup de méthodes intéressantes pour envoyer un message. Il y a des méthodes d'envoi qui permettent de spécifier la destination en utilisant un objet javax.jms.Destination et celles qui la spécifient en utilisant une chaîne de caractères pour effecture une recherche JNDI. La méthode d'envoi qui ne prend aucune destination utilise celle par défaut. Voici un exemple qui envoie un message à une queue en utilisant l'implémentation relative à la version 1.0.2 de JMS.
+ programlistingRef.   /chapter[1]/sect1[4]/sect2[1]/programlisting[1]
OriginalTraduction
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Queue;
import javax.jms.Session;

import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.JmsTemplate102;
import org.springframework.jms.core.MessageCreator;

public class JmsQueueSender {

  private JmsTemplate jt;

  private ConnectionFactory connFactory;

  private Queue queue;

  public void simpleSend() {
    jt = new JmsTemplate102(connFactory, false);
    jt.send(queue, new MessageCreator() {
      public Message createMessage(Session session) throws JMSException {
        return session.createTextMessage("hello queue world");
      }
    });
  }

  public void setConnectionFactory(ConnectionFactory cf) {
      connFactory = cf;
  }

  public void setQueue(Queue q) {
      queue = q;
  }

}
      
 
+ paraRef.   /chapter[1]/sect1[4]/sect2[1]/translation[3]
OriginalTraduction
This example uses the MessageCreator callback to create a text message from the supplied Session object and the JmsTemplate is constructed by passing a reference to a ConnectionFactory and a boolean specifying the messaging domain. A zero argument constructor and a setConnectionFactory/Queue method are also provided and can be used for constructing the instance using a BeanFactory. The method simpleSend modified to send to a topic instead of a queue is shown below Cette exemple utilise l'interface de rappel MessageCreator pour créer un message de type texte à partir d'une session fournie. JmsTemplate est construit avec une référence à une ConnectionFactory et un bouléen spécifiant le domaine de messagerie. Un constructeur sans argument et une méthode setConnectionFactory/Queue est aussi fournie et peut être utilisée égalemet pour construire un instance en utilisant un BeanFactory. La méthode simpleSend modifiée pour envoyer sur une matière plutôt que sur une queue est montrée ci-dessous:
+ programlistingRef.   /chapter[1]/sect1[4]/sect2[1]/programlisting[2]
OriginalTraduction
public void simpleSend() {
  jt = new JmsTemplate102(connFactory, true);
  jt.send(topic, new MessageCreator() {
     public Message createMessage(Session session) throws JMSException {
        return session.createTextMessage("hello topic world");
     }
  });
}     
      
 
+ paraRef.   /chapter[1]/sect1[4]/sect2[1]/translation[4]
OriginalTraduction
When configuring the 1.0.2 in an application context it is important to remember setting the value of the boolean property PubSubDomain property in order to indicate if you want to send to Queues or Topics. Au moment de configurer le version 1.0.2 dans une contexte d'application, il est important de ne pas oublier de positionner la propriété bouléenne PubSubDomain pour indiquer quelle destination utiliser, queues ou matière.
+ paraRef.   /chapter[1]/sect1[4]/sect2[1]/translation[5]
OriginalTraduction
The method send(String destinationName, MessageCreator c) lets you send to a message using the string name of the destination. If these names are registered in JNDI, you should set the DestinationResolver property of the template to an instance of JndiDestinationResolver. La méthode send(String destinationName, MessageCreator c) permet d'envoyer un message en utilisant le nom d'une destination. Si ces noms existent dans JNDI, la propriété du template DestinationResolver doit être positionnée avec une instance de JndiDestinationResolver.
+ paraRef.   /chapter[1]/sect1[4]/sect2[1]/translation[6]
OriginalTraduction
If you created the JmsTemplate and specified a default destination, the send(MessageCreator c) sends a message to that destination. Si vous avez créé une classe JmsTemplate et lui avez spécifié un destination par défaut, la méthode send(MessageCreator c) envoie un message à celle-ci.
sect2
+ titleRef.   /chapter[1]/sect1[4]/sect2[2]/translation[1]
OriginalTraduction
Synchronous ReceivingRéception synchrone
+ paraRef.   /chapter[1]/sect1[4]/sect2[2]/translation[2]
OriginalTraduction
While JMS is typically associated with asynchronous processing, it is possible to consume messages synchronously. The overloaded receive methods provide this functionality. During a synchronous receive the calling thread blocks until a message becomes available. This can be a dangerous operation since the calling thread can potentially be blocked indefinitely. The property receiveTimeout specifies how long the receiver should wait before giving up waiting for a message. Bien que JMS soit typiquemebt associé avec de la messagerie asynchrone, il est possible de consommer les messages de manière synchrone. Les méthodes surchargées receive offre cette fonctionnalité. Durant la reception synchrone, le thread réalisant l'appel se bloque jusqu'à ce qu'un message devienne disponible. Cela peut s'avérer être une opération dangereuse ce thread peut potentiellement être bloqué indéfiniment. La propriété receiveTimeout spécifie la durée au cours de laquelle le receveur doit attendre avant de mettre de continuer.
sect2
+ titleRef.   /chapter[1]/sect1[4]/sect2[3]/translation[1]
OriginalTraduction
Using Message ConvertersUtilisation des Message Converters
+ paraRef.   /chapter[1]/sect1[4]/sect2[3]/translation[2]
OriginalTraduction
In order to facilitate the sending of domain model objects the JmsTemplate has various send methods that take a Java object as an argument for a message's data content. The overloaded methods convertAndSend and receiveAndConvert in JmsTemplate delegate the conversion process to an instance of the MessageConverter interface. This interface defines a simple contract to convert between Java objects and JMS messages. The default implementation, SimpleMessageConverter supports conversion between String and TextMessage, byte[] and BytesMesssage, and java.util.Map and MapMessage. By using the converter, you your application code can focus on the business object that is being sent or received via JMS and not bother with the details of how it is represented as a JMS message. Afin de faciliter l'envoi d'objets de domaine, la classe JmsTemplate a différentes méthodes qui prennent des objets Java en arguments pour les données du message. Les méthodes surchargées convertAndSend et receiveAndConvert de la classe JmsTemplate délègue le traitement de conversion à une instance de l'interface MessageConverter. Cette interface définit un contrat simple pour convertir les objets Java en messages JMS (et inversement). L'implémentation par défaut, SimpleMessageConverter, supporte les conversions entre String et TextMessage, byte[] et BytesMesssage, et java.util.Map et MapMessage. En utilisant le convertisseur, le code de l'application peut se focaliser sur l'objet métier qui va être envoyé ou reçu via JMS et ne plus se soucier des détails de sa représentation en tant que message JMS.
+ paraRef.   /chapter[1]/sect1[4]/sect2[3]/translation[3]
OriginalTraduction
The sandbox currently includes a MapMessageConverter which uses reflection to convert between a JavaBean and a MapMessage. Other popular implementations choices you might implement yourself are Converters that bust an existing XML marshalling packages, such as JAXB, Castor, XMLBeans, or XStream, to create a TextMessage representing the object. La "sandbox" (bac à sable) contient actuellement une classe MapMessageConverter qui utilise la réflexion pour convertir un JavaBean en MapMessage (et réciproquement). D'autres choix populaires d'implémentations sont les convertisseurs tels que des packages existants de sérialisation XML comme JAXB, Castor, XMLBeans, ou XStream, pour créer un TextMessage représentant l'objet.
+ paraRef.   /chapter[1]/sect1[4]/sect2[3]/translation[4]
OriginalTraduction
To accommodate the setting of a message's properties, headers, and body that can not be generically encapsulated inside a converter class, the interface MessagePostProcessor gives you access to the message after it has been converted, but before it is sent. The example below shows how to modify a message header and a property after a java.util.Map is converted to a message. Pour faciliter le positionnement des propriétés, entêtes et corps du message qui ne peuvent pas être encapsulés de manière générique dans une classe de conversion, l'interface MessagePostProcessor donne accès au message après qu'il ait été converti mais qu'il ne soit envoyé. L'exemple ci-dessous montre comment modifier une propriété et une entête de message après qu'il ait été converti à partir d'une java.util.Map.
+ programlistingRef.   /chapter[1]/sect1[4]/sect2[3]/programlisting[1]
OriginalTraduction
public void sendWithConversion() {
    Map m = new HashMap();
    m.put("Name", "Mark");
    m.put("Age", new Integer(35));
    jt.convertAndSend("testQueue", m, new MessagePostProcessor() {

         public Message postProcessMessage(Message message)
            throws JMSException {
            message.setIntProperty("AccountID", 1234);
            message.setJMSCorrelationID("123-00001");

            return message;
        }
    });
}
      
 
+ paraRef.   /chapter[1]/sect1[4]/sect2[3]/translation[5]
OriginalTraduction
This results in a message of the form Le message résultat sera de la forme
+ programlistingRef.   /chapter[1]/sect1[4]/sect2[3]/programlisting[2]
OriginalTraduction
MapMessage={ 
  Header={ 
    ... standard headers ...
    CorrelationID={123-00001} 
  } 
  Properties={ 
    AccountID={Integer:1234}
  } 
  Fields={ 
    Name={String:Mark} 
    Age={Integer:35} 
  } 
}
      
 
sect2
+ titleRef.   /chapter[1]/sect1[4]/sect2[4]/translation[1]
OriginalTraduction
SessionCallback and ProducerCallbackSessionCallback et ProducerCallback
+ paraRef.   /chapter[1]/sect1[4]/sect2[4]/translation[2]
OriginalTraduction
While the send operations cover many common usage scenarios, there are cases when you want to perform multiple operations on a JMS Session or MessageProducer. The SessionCallback and ProducerCallback expose the JMS Session and Session/MessageProducer pair respectfully. The execute() methods on JmsTemplate execute these callback methods. Bien que les opérations d'envoi couvre beaucoup de scénarios d'utilisaition, il y a des cas où de multiples opérations doivent être exécutées sur une session JMS ou un MessageProducer. Les interfaces SessionCallback et ProducerCallback exposent respectivement la session JMS et la paire Session/MessageProducer Les méthodes execute() de JmsTemplate exécutent ces méthodes de rappel.


Index des chapitres