UV EJB Message Module Java Expert CURSUS DE FORMATION AUX NOUVELLES TECHNOLOGIES DE DEVELOPPEMENT UV EJB Message

Plan (1/2) Définition d’un Message L’API Java Message Service Comment fonctionne JMS avec J2EE ? Les concepts de base de JMS Modèle de programmation JMS Exemples

Définition des messages Les messages sont un moyen de communication entre les composants ou les applications. Les messages peuvent être envoyés par : N’importe quel composant J2EE : les applications clientes, les enterprises beans, les composants Web, Une application J2EE interne / externe: interconnexion d’applications J2EE distribuées Une autre application externe non J2EE : interconnexion d’applications J2EE et du système d’information : EAI

Définition des messages La communication est point-à-point et faiblement couplé dans des environnements distribués : Un client envoie un message et reçoit un message d’autres clients Les clients se connectent à un agent de messages pour : La création de messages. L’envoie et le réception de messages. La lecture de messages. L’envoie et la réception s’effectue sur la base d’une destination (asynchrone).

L’API Java Message Service JMS est une API, spécifiée en 1998, pour la création, l’envoie et la réception des messages de façon : Asynchrone : un client reçoit les messages dès qu’ils arrivent ou lorsque le client est disponible et sans avoir à demander si un message est disponible. Fiable : le message est délivré une fois et une seule. API ensemble d’interfaces ayant une certaine sémantique et regroupant des services (méthodes) standardisés.

Quand utiliser JMS? JMS peut être utilisé lorsque : les composants n’ont pas besoin de connaître les interfaces des autres composants, mais uniquement transmettre un événement, une information. Exemple : une entreprise automobile Le stock envoie un message à la production lorsque le nombre de véhicule répertorié est en dessous d’un seuil. La production envoie un message aux unités pour assembler des parties d’une automobile. Les unités envoient des messages à leurs stocks internes pour récupérer les parties. Les unités envoient des messages aux gestionnaire de commandes pour commander les parties chez le fournisseur. Le stock peut publier un catalogue pour la force de vente

Comment fonctionne JMS avec J2EE ? JMS peut accéder aux Messaging-oriented middleware (MOM), tels que MQSeries d’IBM, Elle fait partie intégrante de J2EE à partir de la version 1.3. Réception et envoie de messages de type : Synchrones : applications clientes , EJBs, composants Web (sauf applets, hors spécification) Asynchrones : applications clients, les beans orientés messages. Les composants messages participent aux transactions distribuées des autres composants.

L’architecture JMS Une application JMS est composée des parties suivantes : Un JMS provider est un système de gestion de messages qui implémente les interfaces JMS. Une plateforme J2EE v.1.3 incluse un JMS provider. Les clients JMS sont les composants Java, qui produisent et consomment des messages. Les Messages sont les objets qui communiquent des informations entre les clients JMS. Les Administered objects sont des objets JMS pré-configurés créés par un administrateur pour l’utilisation de clients. Les deux types d’objets sont les destinations et les connection factories. Les Native clients sont des programmes qui utilisent une API native de gestion de message à la place de JMS.

L’architecture JMS Les Administrative tools permettent de lier les destinations et les connections factories avec JNDI. Un client JMS peut alors rechercher les objets administrés dans JNDI et établir une connexion logique à travers le JMS Provider.

Les domaines Avant l’arrivée de JMS, les produits proposaient une gestion de messages : Selon un protocole point-à-point, Selon un protocole publier/souscrire Les JMS Provider compatible J2EE 1.3 doivent obligatoirement implémenter ces deux protocoles

Le protocole point-à-point Ce protocole est basé sur le concept de queue de messages, d’envoyeurs et de receveurs. Chaque message est adressé à une queue spécifique et les clients consomment leurs messages. Ce protocole doit être utilisé pour s’assurer qu’un seul client consommera le message.

Le protocole publier/souscrire Les clients sont anonymes et adressent les messages selon certaines rubriques. Le système distribue le message à l’ensemble des souscripteurs puis l’efface. Ce protocole est efficace lorsqu’un message doit être envoyé à zéro, un ou plusieurs clients.

La consommation de messages Un client consomme les messages de façon : Synchrone : en appelant la méthode receive, qui est bloquante jusqu’à ce qu’un message soit délivré, ou qu’un délai d’attente soit expiré. Asynchrone : un client peut s’enregistrer auprès d’un écouteur de message (listener). Lorsqu’un message arrive, JMS le délivre en invoquant la méthode onMessage du listener, lequel agit sur le message.

Le modèle de programmation JMS

Les Connection Factories Une connection factory est l’objet qu’un client utilise pour créer une connexion avec un JMS provider. Chaque connection factory est une instance de l’interface QueueConnectionFactory ou de TopicConnectionFactory. Pour créer de nouvelles connexions : j2eeadmin -addJmsFactory jndi_name queue j2eeadmin -addJmsFactory jndi_name topic

Les Connection Factories Au début d’un programme JMS, le client réalise une opération de recherche de connexion via JNDI : Context ctx = new InitialContext(); QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx.lookup("QueueConnectionFactory"); TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) ctx.lookup("TopicConnectionFactory");

Les destinations Une destination est un objet qu’un client utilise pour spécifier la cible des messages produits et la source des messages consommés. Dans le protocole point-à-point : les queues sont les destinations; dans les publications/souscriptions : les topiques sont les destinations. Pour créer de nouvelles destinations : j2eeadmin -addJmsDestination queue_name queue j2eeadmin -addJmsDestination topic_name topic

Les destinations Un client doit rechercher sa destination via JNDI, en plus de la connection factory : Topic myTopic = (Topic) ctx.lookup("MyTopic"); Queue myQueue = (Queue) ctx.lookup("MyQueue");

L’objet connection Un objet connection encapsule une connexion virtuelle avec le JMS Provider (i.e. socket TCP/IP avec le démon). L’objet connection permet de créer une ou plusieurs sessions. QueueConnection queueConnection = queueConnectionFactory.createQueueConnection(); TopicConnection topicConnection = topicConnectionFactory.createTopicConnection(); //fermeture sessions, producteurs et consommateurs queueConnection.close(); topicConnection.close();

L’objet session L’objet session est un contexte transactionnel pour produire et consommer des messages. Il permet de créer : un producteur de messages, un consommateurs de messages, les messages. QueueSession queueSession = queueConnection.createQueueSession(true, 0); TopicSession topicSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE); Non spécifié pour les transactions Transactionnelle Non- transactionnelle

Les producteurs de messages Un producteur de message est un objet créé par une session et utilisé pour envoyer des messages à une destination. QueueSender queueSender = queueSession.createSender(myQueue); TopicPublisher topicPublisher = topicSession.createPublisher(myTopic); L’envoi de message est réalisé par : queueSender.send(message); topicPublisher.publish(message);

Les consommateurs de messages synchrones Un consommateur de message est un objet créé par une session et utilisé pour recevoir des messages provenant d’une destination. QueueReceiver queueReceiver = queueSession.createReceiver(myQueue); TopicSubscriber topicSubscriber = topicSession.createSubscriber(myTopic); La réception de message débute : queueConnection.start(); Message m = queueReceiver.receive(); topicConnection.start(); Message m = topicSubscriber.receive(1000); // time out d’une seconde La méthode close() permet de rende inactif un consommateur

Les consommateurs de messages asynchrones Un consommateur de message asynchrone doit être connecté à un listener de message, qui agit comme un gestionnaire événementiel asynchrone. TopicListener topicListener = new TopicListener(); topicSubscriber.setMessageListener(topicListener); //idem pour QueueListener La réception de message débute : queueConnection.start(); topicConnection.start(); Dans J2EE 1.3, le bean orienté message est un type spécial de message listener.

Les messages Les messages JMS ont un format standard : Un entête, comportant des champs dont les valeurs sont déterminées par les clients et les providers (automatique) Des propriétés (optionnel), pour filtrer les messages Un corps (optionnel) parmi cinq prédéfinis : TextMessage : chaîne de caractère (java.lang.String) MapMessage : couple nom(String) / valeur (type primitif), accédé via une énumération BytesMessage : suite d’octets (encodage du message) StreamMessage : suite de valeurs primitives remplies et lues de façon séquentielle ObjectMessage : un objet Java serializable Message : rien, vide (comme void pour les méthodes).

Les valeurs des champs de l’entête de message champs modifié par JMSDestination méthode send ou publish // la queue ou le topique JMSDeliveryMode méthode send ou publish // type de reception JMSExpiration méthode send ou publish //time out JMSPriority méthode send ou publish // niveau de priorité JMSMessageID méthode send ou publish // ID unique de message JMSTimestamp méthode send ou publish //estampillage JMSCorrelationID Client JMSReplyTo Client JMSType Client JMSRedelivered JMS provider

Création, envoi et réception d’un message Selon le type de message, la procédure est la suivante : TextMessage message = queueSession.createTextMessage(); message.setText(msg_text); // msg_text est une chaîne (String) queueSender.send(message); La consommation d’un message est réalisée : Message m = queueReceiver.receive(); if (m instanceof TextMessage) { TextMessage message = (TextMessage) m; System.out.println("Reading message: " + message.getText()); } else { // gérer l’erreur }

Gestion des exceptions dans JMS Toutes les exceptions JMS héritent de JMSException : IllegalStateException InvalidClientIDException InvalidDestinationException InvalidSelectorException JMSSecurityException MessageEOFException MessageFormatException MessageNotReadableException MessageNotWriteableException ResourceAllocationException TransactionInProgressException TransactionRolledBackException

Exemple point-à-point synchrone Écriture des programmes clients : SimpleQueueSender.java : Effectue une recherche JNDI du QueueConnectionFactory et d’une queue (destination) Création d’une connexion et d’une session Création d’un QueueSender Création d’un TextMessage Envoi un ou plusieurs messages à la queue Envoi un a message de contrôle pour indiquer la fin de du flux de messages Fermeture de la connexion dans un bloc finally

Exemple point-à-point synchrone Écriture des programmes clients : SimpleQueueReceiver.java Effectue une recherche JNDI du QueueConnectionFactory et d’une queue (destination) Création d’une connexion et d’une session Création d’un QueueReceiver Démarre la connexion, permettant la réception de messages Réception des messages de la queue jusqu’au message de contrôle pour indiquer la fin de du flux de messages Fermeture de la connexion dans un bloc finally

Compilation, exécution Compilation classique : javac SimpleQueueSender.java javac SimpleQueueReceiver.java Démarrage du JMS Provider : j2ee -verbose Attendre le message « J2EE server startup complete » Créer les objets administrés : j2eeadmin -addJmsDestination MyQueue queue j2eeadmin -listJmsDestination Exécution de l’exemple : java -Djms.properties=%J2EE_HOME%\config\jms_client.properties SimpleQueueSender MyQueue 3 SimpleQueueReceiver MyQueue Suppression des objets administrés et arrêt du serveur J2EE: j2eeadmin -removeJmsDestination MyQueue j2ee -stop

Automatiser JMS dans J2EE À partir de J2EE v1.3, l’API JMS est incluse dans les archives du serveur d’applications. Sun conseille de ne pas utiliser la méthode receive() avec les enterprises beans, du fait de la monopolisation des ressources et de blocage. Il est préférable d’utiliser : un time out : receive(time out), avec time out > 0 (synchrone) Un bean orienté message (asynchrone) Pour les objets administrés, Sun définit un sous contexte java:comp/env/jms pour stocker les noms JNDI. Les ressources, telles que les connections et les sessions doivent être gérées de la manière suivante : Création dans ejbCreate() et ejbActivate() Libération / fermeture dans ejbRemove() et ejbPassivate() avec affectation à la valeur null

Les beans orientés messages dans J2EE Un bean orienté message est un listener de messages, possédant une méthode onMessage(). Le conteneur EJB réalise automatiquement les tâches : Création d’un consommateur de messages (QueueReceiver ou TopicReceiver), le bean message aura une destination et une connection factory lors du déploiement (assemblage) L’enregistrement du listener de messages (pas besoin d’appeler setMessageListener) La spécification du mode d’accusé réception des messages.

Spécification d’un bean message Le bean message doit implémenter les interfaces javax.ejb.MessageDrivenBean et javax.jms.MessageListener Les méthodes : public void onMessage(Message m), public void ejbCreate() {} public void ejbRemove() {} public void setMessageDrivenContext(MessageDrivenContext mdc) {} pour les aspects transactionnels Le bean message ne doit pas disposer de : L’interface Home L’interface Remote

Cycle de vie du bean message

Le bean message et les transactions Le bean message peut participer aux transactions distribuées : Utiliser le container-managed transactions Spécifier l’attribut Required pour la méthode onMessage : Démarrage d’une transaction avant l’exécution de la méthode Commit de la transaction à la fin de l’exécution de la méthode Le contexte de la transaction (MessageDrivenContext) est passée au bean via la méthode setMessageDrivenContext et permet les opérations suivantes: setRollbackOnly : à utiliser pour spécifier une exception dans le bean getRollbackOnly : permet de tester si une transaction est déjà marquée en rollback

Exemple MessageBean.java public class MessageBean implements MessageDrivenBean, MessageListener { private transient MessageDrivenContext mdc = null; private Context context; public MessageBean() { System.out.println("In MessageBean.MessageBean()"); } public void setMessageDrivenContext(MessageDrivenContext mdc) { System.out.println("In " + "MessageBean.setMessageDrivenContext()"); this.mdc = mdc; public void ejbCreate() { System.out.println("In MessageBean.ejbCreate()"); public void ejbRemove() { System.out.println("In MessageBean.remove()");

Exemple MessageBean.java public void onMessage(Message inMessage) { TextMessage msg = null; try { if (inMessage instanceof TextMessage) { msg = (TextMessage) inMessage; System.out.println("MESSAGE BEAN: Message " + "received: " + msg.getText()); } else { System.out.println("Message of wrong type: " + inMessage.getClass().getName()); } } catch (JMSException e) { System.err.println("MessageBean.onMessage: " + "JMSException: " + e.toString()); mdc.setRollbackOnly(); } catch (Throwable te) { System.err.println("MessageBean.onMessage: " + "Exception: " + te.toString());

Exemple

Création du code client Vous ne spécifiez par le nom de la queue name. Le client obtiendra le nom de la queue name à travers une recherche JNDI. Vous ne spécifiez pas le nombre des messages; par défaut il est positionné à 3, et pas de fin de message ne sera envoyée au MDB (Message-driven bean). La recherche JNDI s’effectuera dans le sous contexte java:/comp/env/jms.

Compilation et déploiement Compiler les fichier à l’aide de la commande : javac *.java Démarrer le serveur J2EE et l’outil de déploiement Création d’une queue : Dans l’outil de déploiement : Menu tools -> Server Configuration -> JMS -> Destinations Sélectionner JMS Queue Destinations Cliquer sur Add puis insérer le texte jms/MyQueue Vérifier à l’aide de la commande j2eeadmin -listJmsDestination

Création de l’application EAR La création de l’application EAR est réalisée : Dans l’outil de déploiement File->New Application Donner un nom et clic sur Browse pour sélectionner le répertoire contenant les fichiers Java de l’application Dans le champs File Name : MDBApp Clic New Application Clic OK

Packager l’application cliente Utiliser l’assistant pour créer votre application cliente : Menu File -> New -> Application Client Clic Next Dans la liste déroulante : sélectionner MDBApp Clic sur Edit : Choisir le répertoire contenant les fichiers clients Sélectionner uniquement les fichiers .class : SimpleClient.class puis Add Clic Ok Vérifier que le nom affiché et la classe principale sont SimpleClient Vérifier que l’authentification Container-managed est sélectionnée Clic Next jusqu’à Resource References

Spécifier les ressources de l’application : Resource References Dialog Box Associer le nom JNDI pour la connection factory dans le code SimpleClient.java avec le nom de la QueueConnectionFactory. Vous devez spécifier l’ authentification conteneur pour la ressource connection factory, en définissant le nom de l’utilisateur et le mot de passe afin de pouvoir créer une connexion. Les étapes sont les suivantes : Clic Add. Dans le champs Coded Name, saisir jms/MyQueueConnectionFactory (SimpleClient). Dans le champs Type, choisir javax.jms.QueueConnectionFactory. Dans le champs Authentication, choisir Container. Dans le champs Sharable, vérifier que la case est activée. Ceci permet au conteneur d’optimiser les connexions. Dans le champs JNDI Name, saisir jms/QueueConnectionFactory. Dans le champs User Name, saisir j2ee. Dans le champs Password, saisir j2ee. Clic Next.

Les tâches sont les suivantes : Spécifier les références aux destinations JMS: JMS Destination References Associer le nom JNDI pour la queue définie dans SimpleClient.java avec le nom de la queue créée à l’aide de j2eeadmin. Les tâches sont les suivantes : Clic Add. Dans le champs Coded Name, saisir jms/QueueName (SimpleClient). Dans le champs Type, choisir javax.jms.Queue. Dans le champs JNDI Name, saisir jms/MyQueue. Clic Next. Finalement clic sur Finish

Packager le bean message Utiliser l’assistant pour créer votre application cliente : Menu File -> New -> Enterprise Bean Clic Next Dans la liste déroulante : sélectionner MDBApp Clic sur Edit : Choisir le répertoire contenant les fichiers du bean Sélectionner uniquement les fichiers .class : MessageBean.class puis Add Clic Ok

Sélectionner le type du bean : General Dialog Box Dans le Bean Type, choisir le Message-Driven. Dans le champs Enterprise Bean Class, choisir MessageBean. Les listes déroulantes pour les interfaces locales et remote sont grisées. Dans le champs Enterprise Bean Name, saisir MessageBean. Click Next.

Spécifier le type de transaction : Transaction Management Dialog Box Vous spécifier la manière dont les transactions pour la méthode onMessage seront gérées. Un enterprise bean ordinaire dispose de six attributs possibles, un bean orienté messages n’en a que deux. Les tâches sont les suivantes : Choisir Container-Managed. Dans le champs Transaction Attribute, vérifier que la valeur Required est sélectionnée pour la méthode onMessage. Clic Next.

Les tâches sont les suivantes : Spécifier les paramètres du bean: Message-Driven Bean Settings Dialog Box Vous spécifiez les propriétés du déploiement du bean. Du fait que les transactions soient gérées par le conteneur, le champs Acknowledgment est grisé. Les tâches sont les suivantes : Dans la liste Destination Type, choisir Queue. Dans le champs Destination, choisir jms/MyQueue. Dans le champs Connection Factory, choisir jms/QueueConnectionFactory. Clic Next. Finalement clic sur Finish.

Déploiement de l’application Pour déployer l’application, réaliser les tâches suivantes : A partir du menu File, sauvegarder l’application. A partir du menu Tools, choisir Deploy. Clic Next. Dans la boîte de dialogue JNDI Names, vérifier que les noms corrects. Clic Finish. Lorsque le message "Deployment of MDBApp is complete" apparaît cliquer sur OK.

Exécuter le client Pour exécuter le client, il faut se positionner dans le répertoire contenant les fichiers clients. runclient -client MDBApp.ear -name SimpleClient Lorsque la demande de Login apparaît : Saisir j2ee pour le nom de l’utilisateur Saisir j2ee pour le mot de passe. Cliquer sur OK.