From: redacteurs@xmlfr.org
Date: 29/11/2002 - 12:58
SOAP , oui mais...
Les abonnes de la liste java@u-strasbg.fr ont recemment fait le point
[1] sur les techniques de communication entre applications sur un
reseau, particulierement dans un cadre client / serveur.
Par Herve AGNOUX [2] , de la SARL diaam informatique [3] .
---------------
Retrouvez cet article en ligne
(http://xmlfr.org/actualites/tech/021129-0001).
Donnez votre avis !
mailto:xml-tech@xmlfr.org?subject=Re:%20INFO%20:%20SOAP,%20oui%20mais...
---------------
Il est remarquable, dans un milieu globalement acquis au developpement
Java , de constater que les solutions uniquement basees sur cette
plate-forme (comme RMI ) ont globalement ete rejetees.
Personne ne semble reellement contester la valeur de Corba comme base
technologique pour les applications reparties. Que ce soit au niveau de
l'interoperabilite, de la portabilite, de la fiabilite, de l'ensemble
des services disponibles (tolerance aux pannes, persistance...), Corba
semble etre la valeur sure.
Corba est neanmoins conteste pour des raisons externes a une approche
strictement technique. Sa faible implantation aux Etats-Unis, par
exemple, est un probleme. Et sa reputation d'un abord un peu ardu
laisse le champ ouvert a des technologies plus recentes comme SOAP .
SOAP a pour elle un avantage de taille : de nombreux clients la
reclame. Cela suffit a ce que la communaute des developpeurs Java se
penche dessus avec serieux. Mais les budgets qui la poussent en avant
masquent, comme souvent, une veritable reflexion a son endroit.
Un second avantage est qu'elle est un prolongement des services Web .
Elle beneficie donc de la tolerance - ou de l'aveuglement - des
pare-feu.
Mais si l'on compare de facon plus fine les technologies SOAP et Corba
, on s'apercoit que ce qui est simple avec SOAP l'est aussi avec Corba
, et que ce qui est complique avec SOAP l'est aussi avec Corba . Et
cela est vrai aussi bien au niveau de l'apprentissage que de la mise en
oeuvre technologique.
Ensuite il apparait que l'interoperabilite affirmee de SOAP est pour
l'instant peu convaincante. Elle est basee sur une formalisation XML de
types simples, qui revient a les convertir en chaine de caracteres
calibrees. Or, toute application serieuse manipule des donnees que l'on
pourrait qualifier de compliquees, pour lesquelles un simple mapping
vers des chaine de caracteres ne suffit pas a garantir le passage
fidele d'un environnement informatique a un autre.
Heureusement il arrive sur le marche des outils fiables et puissants
pour soutenir un developpement SOAP . Dans le monde Java , le plus
abouti semble etre pour l'instant GLUE [4] , evalue aussi performant
que les solutions .NET .
Avec ces outils, pour des applications client / serveur simples dans la
tradition des scripts CGI , SOAP est une excellente alternative. Les
experiences de Google ou Amazon, relatees dans un article de ZDNet
(Google, Amazon take lead in Web services [5] ), le demontrent
largement.
Une troisieme voie est utilisee avec reussite, basee sur la souplesse
propre au XML . Il existe en effet de nombreuses solutions quant au
mapping des objets logiciels vers leur representation XML . Et comme
les outils de lecture ecriture des flots XML sont de plus en plus
performants, malgre leur cote verbeux, on gagne en performance ce que
l'on peut perdre en interoperabilite. De toutes facons, il reste a
prouver que SOAP apporte une interoperabilite superieure a celle donnee
par n'importe quel document XML .
Ainsi, le debat reste tres ouvert. Les budgets ont choisi SOAP . Quel
sera le verdict de la realite ?...
Parmi les interventions remarquables de ce fil de discussion, on trouve
en particulier (les titres sont du redacteur de cette note) :
- Vive Corba, pour SOAP il est urgent d'attendre, la preuve. [6]
- Vive SOAP, les preuves (avec une analyse des offres du marche). [7]
- Corba est aussi facile a apprendre que SOAP. [8]
- Une comparaison ligne de code par ligne de code de Corba et SOAP.
[9]
Autres articles:
- Services Web: SOAP ou REST? [10]
- Services Web: batis sur une contradiction [11]
Copyright 2002 , Herve AGNOUX .
---------------------------------------------------------
References:
[1] http://www.mail-archive.com/java%40u-strasbg.fr/msg02677.html
[2] mailto:herve.agnoux@diaam-informatique.com
[3] http://www.diaam-informatique.com
[4] http://www.themindelectric.com/glue/
[5] http://zdnet.com.com/2100-1104-966546.html
[6] http://www.mail-archive.com/java%40u-strasbg.fr/msg02679.html
[7] http://www.mail-archive.com/java%40u-strasbg.fr/msg02687.html
[8] http://www.mail-archive.com/java%40u-strasbg.fr/msg02703.html
[9] http://www.mail-archive.com/java%40u-strasbg.fr/msg02705.html
[10] http://xmlfr.org/documentations/articles/021115-0002
[11] http://xmlfr.org/actualites/decid/021115-0001
---------------------------------------------------------
Mail genere par FormatedTextOutputHandler pour XT
(http://4xt.org/downloads/examples/outputhandlers/formatedtext/).
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:06 UTC
webmaster@xmlfr.org
| 
