SOAP, oui mais...

[Herve AGNOUX]

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