Le 23 May 2002 Nicolas Delsaux a �crit : > Salut, > pour le d�veloppement d'une application industrielle distribu�e, je > cherche des retours d'exp�rience sur l'utilisation des technologies > JMS et JXTA. Donc, si vous vous en �tes servi, que vous �tes > content/pas content des performances, de la facilit� d'utilisation, de > la mise en place,.... n'h�sitez pas Merci >
Hop, je me lance. Le JXTA je connais pas, j'ai juste fait le JMS. Comme en plus c'est une impl�mentation perso, je ne connais rien des impl�ms officielles, je peux juste parler du "framework" g�n�ral. C'est le genre de framework que je n'aime pas beaucoup, � savoir des interfaces qui d�clarent le maximum, � l'impl�menteur de mettre en oeuvre ce dont il a vraiment besoin, renvoyant une SortOfNotImplementedException pour le reste. Deux grands domaines sont tout de m�me d�termin�s, les Queues et les Topics. J'ai pris les Topics. Malgr� ma premi�re r�serve de principe, je le trouve bien fait dans l'ensemble. J'avoue ne pas avoir encore fait ma religion, pour savoir s'il est vraiment utile (je vais peut �tre scandaliser...). Par rapport au RMI, aux b�tes appels de m�thodes, ou probablement au Corba, que je ne connais pas, je ne sais pas. Avec le JMS il faut forc�ment rajouter une couche, c'est � dire la fabrication du "message" et son corrolaire, la reception. A quoi cela sert-il vraiment, par rapport aux appels de m�thodes classiques ?... Je ne sais pas trop, je l'avoue. Je pense que cela est utile lorsque l'on veut mieux controler le fameux appel de m�thode (ex : savoir qui appelle ? ), ou bien lorsque l'on veut mieux contr�ler les couches basses (transmissions en flot de caract�res, par exemple), et par suite que l'un des deux morceaux n'est pas en Java. Le gros avantage est une bien meilleure pris en compte du contexte multithread. En tout cas, chez moi :-) Une boucle lit les messages, et les traitent les uns � la suite des autres, c'est hyper classique, cela fontionne au petit poil et, esp�re-je, aucun gourou de l'orient� objet n'a dit le contraire. (ou alors il l'a dit en anglais, donc j'ai rien compris) Mais c'est un contexte asynchrone, c'est � dire que contrairement aux appels de m�thode tu n'as pas tout de suite la r�ponse, la r�ponse a ta requ�te arrive quand elle le peut, et cela t'oblige d'une fa�on ou d'une autre � m�moriser un contexte, ou alors � forcer une synchronisation en attendant assiduement la r�ponse. Tout cela est un peu plus sioux � g�rer, et ne se justifie que lorsque les ressources sont r�ellement d�synchronis�es (suis-je clair ? ), sinon tout cette jonglerie est compl�tement louf, � mon humble avis. Avec les Topics tu as la notion de... Topic, justement qui est int�ressante, mais je ne sais pas comment ces "sujets" travaillent par rapport aux "objets", conceptuellement parlant. C'est int�ressant, mais j'ai pas la recette exacte. Actuellement lorsque je dois communiquer entre deux applis distantes, j'ai tendance � utiliser JMS, par contre pour communiquer � l'int�rieur d'une m�me appli locale, j'ai tendance � rester classique. -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
