Discussion :

[Claythest]

Bonjour,

Je développe des EJB3 (entity, session,...) qui communiquent avec un (ou plusieurs) client lourd (développé en SWING), et j'aimerai que ce client se mettent automatiquement à jour en fonction des éventuelles modifications qu'il pourrait y avoir sur le serveur...

Par exemple, j'ai des entity beans "Personne", et le client affiche une JList contenant les informations (noms, prénoms, ...) de ces personnes. Etant donné que j'utilise le pattern Value Object (copie des valeurs des entity beans afin de ne pas manipuler les entity beans directement depuis le client), si un autre client modifie une de ces personnes, j'aimerai que ma JList se mette automatiquement à jour sur l'autre client via une technique d'évènements ou autre...

Est-ce possible ?

J'ai cherché du côté des Message Driven Bean, mais apparemment, ce que j'en ai compris, c'est que ça permet uniquement de communiquer dans un sens : du client (qui envoie un message) au serveur (l'EJB Container qui recoit le message)... Est-ce que je me trompe ?

Donc est-ce que quelqu'un peut m'expliquer comment je pourrai gérer des sortes d'évènements déclenchés par mon serveur et transmis aux clients ?

Si je n'ai pas été assez clair, n'hésitez pas à me poser des questions

Merci d'avance pour votre aide

[trimok]

1ère possibilité : simple
Tu mets un timer, dans chaque client.
Le timer lance un ordre HTTP qui va vérifier un flag sur le serveur (données modifiées ou non)
Si le flag est modifié, un autre ordre HTTP pour récupérer les données et les afficher
_______________________________________________________
2ème possibilité (faisabilité à démontrer) : JMS avec les Topics

Si tout était sur le même serveur, tu pourrais utiliser sans problème JMS / Topic
JMS est une API J2EE correspondant à une messagerie asynchrone.
Le Topic correspond à une utilisation de style mail-list (one-to-many)
(par opposition à la Queue, qui correspond à un envoi one-to-one)
JMS comprend des fournisseurs de messages (publishers) et des souscripteurs de messages (ceux qui s'abonnent à un Topic ou une Queue).

Dans ton cas, tu peux, à chaque modification de données, fournir un nouveau message au Topic (côté serveur).
Ensuite, les clients lourds peuvent s'abonner, et recevoir le message de modification

Mais dans ton cas, cela est plus compliqué, il faut, à mon avis, que le réseau supporte RMI/IIOP (et en plus, il faut donner une adresse précise (URL du serveur) dans le lookup JNDI, pour obtenir des références sur les objets JMS/ Topic). Donc à tester....

[Claythest]

La première possibilité me paraît en effet simple, cependant moins propre.

La seconde : je suis justement en train de regarder JMS, cependant je ne pense pas avoir tout compris...

Mais dans ton cas, cela est plus compliqué, il faut, à mon avis, que le réseau supporte RMI/IIOP (et en plus, il faut donner une adresse précise (URL du serveur) dans le lookup JNDI, pour obtenir des références sur les objets JMS/ Topic). Donc à tester....

Etant donné que mon serveur est un serveur J2EE (JBoss) qui déploie des EJB, ces EJB sont récupérés par mes clients lours, le réseau doit supporter RMI/IIOP non ? (JNDI et RMI/IIOP sont étroitement liés je me trompe ?)

Donc je pense que les JMS pourraient me rendre service (). Cependant je ne trouve pas de tutoriels simples permettant de mettre rapidement en place un publisher et un suscriber... Du coup je tatonne et j'arrive pas à faire fonctionner JMS...

Enfin, je vais chercher du coté de JMS, car je pense que le résultat sera plus propre (surtout que le nombre de requetes de mises a jour sera réduit au strict minimum, pas besoin de questionner un flag toutes les x secondes), cependant, si tu vois le code que je vais devoir écrire côté serveur (le TopicPublisher, qui va générer mes "évènements") et côté client (le TopicSuscriber, qui vont lire ces "évènements") n'hésite pas à en montrer quelques bouts

Pour info, voila le code que j'ai écrit sur le coté serveur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
	private void sendMessage () {
		try {
			Hashtable<String, String> env = new Hashtable<String, String>();
			env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
			env.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
			env.put(Context.PROVIDER_URL, "localhost:1099");
			Context ctx = new InitialContext(env);
 
			ConnectionFactory connectionFactory = (ConnectionFactory) ctx.lookup("ConnectionFactory");
			Destination destination = (Destination) ctx.lookup("topic/test");
			Connection cnx = connectionFactory.createConnection();
			Session session = cnx.createSession(false, Session.AUTO_ACKNOWLEDGE);
			MessageProducer producer = session.createProducer(destination);
			TextMessage message = session.createTextMessage();
			producer.send(message);
			cnx.close();
		} catch (NamingException e) {
			e.printStackTrace();
		} catch (JMSException e) {
			e.printStackTrace();
		}
	}

Cette méthode sendMessage est envoyé à chaque modification de mon entity bean...

Cote client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private void receiveMessage () {
		try {
			Hashtable<String, String> env = new Hashtable<String, String>();
			env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
			env.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
			env.put(Context.PROVIDER_URL, "localhost:1099");
			Context ctx = new InitialContext(env);
 
			ConnectionFactory connectionFactory = (ConnectionFactory) ctx.lookup("ConnectionFactory");
			Destination destination = (Destination) ctx.lookup("topic/test");
			Connection cnx = connectionFactory.createConnection();
			Session session = cnx.createSession(false, Session.AUTO_ACKNOWLEDGE);
 
			MessageConsumer consumer = session.createConsumer(destination);
			consumer.setMessageListener(new MessageListener() {
 
				public void onMessage (Message message) {
					System.out.println(message);
				}
			});
			cnx.start();
		} catch (NamingException e) {
			e.printStackTrace();
		} catch (JMSException e) {
			e.printStackTrace();
		}
 
	}

L'objet qui va écouter le topic...

Y a-t-il quelque chose de plus à faire pour que ce message soit réceptionné ?

Puisque actuellement, dès que l'une des deux méthodes est exécutée, je me prend une exception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

javax.naming.NameNotFoundException: test not bound

Si quelqu'un pouvait m'aider... Merci d'avance

Et merci trimok pour t'intéresser à ce topic

[Claythest]

Je crois comprendre que je dois modifier un fichier xml de mon serveur JBoss, mais lequel, et je dois y ajouter quoi ?

[Claythest]

Ca y est ! J'ai enfin réussi !

J'ai modifié le fichier dans le répertoire JBOSS_HOME/server/xxx/deploy/jms/jbossmq-destinations-service.xml

J'y ai rajouté un élément mbean suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
  <mbean code="org.jboss.mq.server.jmx.Topic"
	 name="jboss.mq.destination:service=Topic,name=test">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
    <depends optional-attribute-name="SecurityManager">jboss.mq:service=SecurityManager</depends>
    <attribute name="SecurityConf">
      <security>
        <role name="guest" read="true" write="true"/>
        <role name="publisher" read="true" write="true" create="false"/>
        <role name="durpublisher" read="true" write="true" create="true"/>
      </security>
    </attribute>
  </mbean>

En fait, JBoss traite les queues et les topics comme des Message Driven Bean, et il faut donc les préciser dans ce fichiers. Ainsi, j'ai créé un topic accessible via jndi sous le nom de "topic/test".

J'ai pas encore compris (ni réflléchi ) le role des paramètres dans cet élément xml, mais toujours est-il qu'avec le code que j'ai montré plus haut, ça marche

Voila, grâce à JMS, je vais pouvoir gérer mes évènements entre le serveur et LES clients

Topic Résolu, merci trimok (le seul particpant de ce topic avec moi )

(source où j'ai trouvé la réponse à ma question : http://docs.jboss.org/jbossas/gettin...ingle/#d0e1627)

[trimok]

Le code me semble OK.
Je note l'info pour le fichier de configuration XML (Merci...)
A priori, les rôles de sécurité devraient pouvoir être utilisés dans le cas où
tu te connecte à JMS, en passant une identité/et/ou des rôles
(ce qui permettrait de savoir si l'intervenant a le droit
d'écrire un message ou de lire un message)
C'est à creuser....

A priori tu as raison, si tu peux récupérer les EJB par tes clients lourds, le réseau doit supporter RMI/IIOP.

Néanmoins, fais un test réél en modifiant le PROVIDER_URL, pour
mettre l'url du serveur distant