Bonjour, Comme j'en ai parl� � l'occasion de ma question "Client / Serveur, ou en sommes nous ? ", je vais essayer de faire une synth�se des r�ponses, de fa�on � la publier sur http://xmlfr.org, site o� je d�ploie une petite activt� de r�dacteur.
Merci de lire ce texte, et de me dire ce que vous en pensez (� commencer par le titre) ! Dans la version finale je m'astreindrai � mettre des URL et tout le d�corum. ==> Les abonn�s de la liste [EMAIL PROTECTED] ont recemment fait le point sur les techniques de communication entre applications sur un r�seau, particuli�rement dans un cadre client / serveur. Il est remarquable, dans un milieu globalement acquis au d�veloppement Java, de constater que les solutions uniquement bas�es sur cette plate-forme (comme RMI) ont globalement �t� rejet�es. Personne ne semble r�ellement contester la valeur de Corba comme base technologique pour les applications r�parties. Que ce soit au niveau de l'interop�rabilit�, de la portabilit�, de la fiabilit�, de l'ensemble des services disponibles (tol�rance aux pannes, persistance...), Corba semble �tre une valeur s�re, et m�me LA valeur s�re. Corba est n�anmoins contest� pour des raisons externes � une approche strictement technique. Sa faible implantation aux Etats-Unis, par exemple, est un probl�me. Et son abord un peu ardu laisse le champ ouvert � des technologies plus r�centes, � d�faut d'�tre r�ellement novatrices, comme SOAP. SOAP a pour elle un avantage de taille : de nombreux clients la r�clame. Cela suffit � ce que la communaut� des d�veloppeurs Java se penche dessus avec s�rieux. Mais les budgets qui la poussent en avant masquent, comme souvent, une v�ritable r�flexion � son endroit. D'abord, si l'on compare de fa�on plus fine les technologies SOAP et Corba, on s'aper�oit que ce qui est simple avec SOAP l'est aussi avec Corba, et que ce qui est compliqu� avec SOAP l'est aussi avec Corba : il n'y a aucun miracle, ni m�me aucun apport technologique. Et cela est vrai aussi bien au niveau de l'apprentissage que de la mise en oeuvre de ces technologies. Ensuite, il apparait que l'interoperabilit� affirm�e de SOAP est pour l'instant peu convaincante. Elle est bas�e sur une formalisation XML de types simples, qui revient � les convertir en cha�nes de caract�res calibr�es. Or, toute application s�rieuse manipule des donn�es que l'on pourrait qualifier de compliqu�es, pour lesquelles un simple mapping vers des cha�nes de caract�res ne suffit pas � garantir le passage fid�le d'un environnement informatique � un autre. Heureusement, il arrive sur le march� des outils fiables et puissants pour soutenir un d�veloppement SOAP. Dans le monde Java, le plus abouti semble �tre pour l'instant GLUE, �valu� aussi performant que les solutions .net. Avec ces outils, pour des applications client / serveur simple sur le web, SOAP est une excellente alternative. Une troisi�me voie est utilis�e avec r�ussite, bas�e sur la souplesse propre au XML. Il existe en effet de nombreuses solutions quant au mapping des objets logiciels vers leur repr�sentation XML. Et comme les outils de lecture / ecriture des flots XML sont de plus en plus performants, malgr� leur cot� verbeux, on gagne en performance ce que l'on peut perdre en interop�rabilit�. De toutes fa�ons, il reste � prouver que SOAP apporte une interop�rabilit� sup�rieure � n'importe quel document XML. Ainsi, le d�bat reste tr�s ouvert. Parmi toutes les voies possibles, il est clair que les budgets ont choisi SOAP. Mais quel sera le verdict de la r�alit� ?... <== Voil� ! Des commentaires, des pr�cisions, des oublis ? -- SARL diaam informatique - 04 50 77 12 60 Ingenierie, d�veloppements de syst�mes d'information http://www.diaam-informatique.com
