JMS est un composant essentiel de J2EE et l'asynchronisme est son principal atout.
Pour repondre a ta question, Herve, les Topics sont utilises pour broadcaster un message a plusieurs destinataires, les Queues sont juste pour un seul destinataire. -- C�dric > -----Original Message----- > From: Herve AGNOUX [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 23, 2002 1:10 PM > To: [EMAIL PROTECTED] > Subject: Re: JMS, JXTA et performance > > > 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 >
