Ressources

Création des ressources d'une application Java EE

Pour fonctionner dans un serveur d'application Java EE comme Glassfish, une application utilisant l'API JMS, une application EJB ou un composant web a besoin de ressources. Les ressources pour les applications utilisant l'API JMS sont les "fabriques de connexion" via l'interface "javax.jmx.ConnectionFactory" et les "Destinations" via l'interface "javax.jmx.Destination".
On peut accéder à ces ressources en se servant d'annotations ou de fichiers descripteurs. Dans ces applications on ne doit pas se servir à la fois de fichier descripteur et des annotions car les fichiers descripteurs sont masquées par les ressources définies par annotation.

Destination

Une application Cliente utilisant l'API JMS dépose ses messages à une destination (si l'application est émettrice de messages (producer)) ou elle récupère les messages à une destination (si l'application est consommatrice de messages (consummer); Si on travaille dans un serveur d'application Java EE, la ressource Destination peut être définie en utilisant une annotation comme suit:

 @JMSDestinationDefinition(
 name = "java:app/jms/myappTopic",
 interfaceName = "javax.jms.Topic",
 destinationName = "MyPhysicalAppTopic"
 )

L'annotation @JMSDestinationDefinition permet d'avoir la destination des messages; la destination est soit un Topic soit une Queue (voir définition) ; dans notre cas c'est une "Topic" dont le nom est "myappTopic", l'Interface qui sera utilisée par l'application est "javax.jms.Topic" et le nom de la destination est "MyPhysicalAppTopic".

Exemple:(à venir...)

ConnectionFactory

On a vu qu'une "fabrique de connexions" (Connection Factory) est un objet ConnectionFactory utilisé pour créer une connexion d'avec un fournisseur JMS (JMS Provider); on utilise dans un serveur d'application une annotation pour créer une "connection factory" comme suit:

@JMSConnectionFactoryDefinition(name="java:app/jms/MyConnectionFactory")

"MyConnectionFactory" est le nom de la ConnectionFactory; on définit les "Connections factories" par:

• java:global: Rend la ressource disponible pour toutes les applications déployées
• java:app: Rend la ressource disponible pour tous les composants dans tous les modules de l'application
• java:module: Rend la ressource disponible pour tous les composants des modules donnés (par exemple, tous les EJB avec un module EJB)
• java:comp:

Exemple :(à venir...)

Injection des ressources ConnectionFactory Queue ou Topic

Normalement, on utilise l'annotation @Resource si on injecte l'interface ConnectionFactory Queue ou Topic dans une application Java EE. Dans ce cas ces objets doivent être créés par configuration avant le déploiement de l'application. Dans certain cas on peut se servir de la "connnection factory" par défaut; elle se trouve dans l'annuaire JNDI (java:comp/DefaultJMSConnectionFactory).
Quand on utilise l'injection des ressources dans un composant d'une application cliente on déclare static les ressources JMS comme suit:

@Resource(lookup = "java:comp/DefaultJMSConnectionFactory")
private static ConnectionFactory connectionFactory;
@Resource(lookup = "jms/MyQueue")
private static Queue queue;

Par contre si on utilise l'injection des ressources JMS dans un java bean session, un Message-driven-Bean ou un composant web, on ne les déclare pas "static":

@Resource(lookup = "java:comp/DefaultJMSConnectionFactory")
private ConnectionFactory connectionFactory;
@Resource(lookup = "jms/MyTopic")
private Topic topic;

(à venir...)

Injection de l'objet JMSContext

Un composant web ou un EJB peut accéder aux ressources de l'interface "javax.jms.JMSContext" de deux façons; soit par injection des ressources de l'objet ConnectionFactory soit en utilisant les annotations @Inject ou @JMSConnectionFactory. Par contre pour utiliser la connexion par défaut on procède tout simplement comme suit:

@Inject
private JMSContext context1;

Si on se sert d'une "connexion Factory" personnelle on procède comme suit:

@Inject
@JMSConnectionFactory("jms/MyConnectionFactory")
private JMSContext context2;

Exemple: (à venir...)

Utiliser l'API JMS dans une application Java EE

Généralités

Une application qui produit des messages ou qui les reçoit de façon asynchrone peut utiliser une application Java web ou un composant EJB comme, un manged-Bean, une Servlet ou une session pour exécuter ses opérations. Par exemple, on peut utiliser un Java Bean Session Stateless pour envoyer un message à un MDB. On peut avoir un exemple d'application qui envoie ou qui reçoit des Messages par une application Web utilisant des managed Beans pour produire ou consommer des messages.

Exemple: (à venir...)

Gérer des ressources JMS dans un composant web ou EJB

Les ressources de JMS sont les connexions (objet Connection), les sessions (objet Session) combinées avec les objets JMSContext.

Gérer des Transactions dans une Session Bean

Au lieu d'utiliser une transaction locale on se sert d'une transaction JTA ; on peut, soit utiliser les fonctionnalités du conteneur et dans ce cas le conteneur prend le contrôle de la transaction sans aucune intervention du développeur, ou bien, on utilise les méthodes de l'interface javax.transaction.UserTransaction; celles-ci gèrent les transactions du managed-bean par programmation (intervention du développeur bien sûr); on procède ainsi si vraiment on a des raisons spéciales qui font qu'on ne puisse pas laisser le conteneur prendre tout en charge.

Exemple: (à venir...)

Utiliser MDB pour recevoir des Messages de façon asynchrone

(à venir...)

Gestion des JTA (Java Transaction API) transaction

JMS local transactions

Une transaction groupe une série d'opérations et les traite en même temps; si une seule de ces opérations échoue toute la transaction échoue; c'est une fois que toutes les opérations présentes dans la transaction se terminent sans erreur que la transaction se termine.
Dans une application cliente Java EE ou Java SE, on peut se servir des transactions pour envoyer ou recevoir des messages. On se sert alors des méthodes JMSContext.commit (ici on doit avoir toutes les opérations traitées avec succès) et JMSContext.rollback. Pour créer une session transactionnelle on peut procéder comme suit:

JMSContext context = connectionFactory.createContext(JMSContext.SESSION_TRANSACTED);

Tant qu'une Session transactionnelle est en cours de traitement, on ne peut pas l'interrompre; soit elle se termine et on "commit" soit elle échoue et dans ce cas on a un rollback.

Exemple: (à venir...)

....

Transaction de messages

L'utilisation dans des applications clientes Java EE ou Java SE, de transactions locales JMS permet de grouper l'envoi ou la réception de messages dans une Session spécifique JMS. Une application cliente Java EE qui s’exécute dans un conteneur Web ou un conteneur EJB généralement utilisent des transactions JTA pour être sures de l'intégrité de l'accès à des ressources externes auxquelles elles accèdent. La différence entre les transactions JTA et les transactions locales et que les transactions JTA sont contrôlées par le serveur d'application dans lequel s'exécutent l'application Cliente. les transactions JTA encapsulent plusieurs ressources dans la même transaction.

Exemple: (à venir...)

Transactions managées dans le conteneur d'EJB

Le conteneur d'EJB contrôle l' intégrité des transactions sans qu'on ait à faire des "commit" ou des "rollback". IL est facile de se laisser le conteneur de traiter les transactions plutôt que de les gérer par managed bean.

Exemple: (à venir...)