Herve AGNOUX wrote:
Bonjour,<<ici un point , SOAP ne peut en aucun cas rvivaliser avec corba dans le cas d'application mutitiers,securisé , transactionelle,très performante etc...
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.
du moins dans l'état actuell de la norme, il s'agit juste d'un RPC de base>>
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 ?
