xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: WS : REST / SOAP
From: Herve AGNOUX (herve.agnoux@diaam-informatique.com)
Date: 14/02/2003 - 08:34
Je ne connais pas REST (et pas très bien SOAP, d'ailleurs...), je réagis juste
à vos remarques concernant le découplage.
Le découplage étant, si je comprends bien, la capacité de deux systèmes
informatiques d'évoluer séparément tout en pouvant continuer de travailler
ensemble.
Mais cette propriété est forcément en rapport avec une action de re-couplage.
Par un racourci de langage, on parle de systèmes découplés lorsque l'action
de re-couplage est faible, mais elle n'est jamais nulle.
Et pour ce recouplage, il me semble que les langages informatiques - java, c,
etc - sont les outils les plus indiqués.
Il me semble donc qu'il est trompeur d'opposer XML et Java, C, ou autre pour
ce qui concerne le découplage. Le premier, XML, est bien pour découpler, les
seconds pour recoupler.
C'est au cours du re-couplage, qui est forcément une action volontaire,
que les langages informatiques autres que le XML peuvent redevenir
interessants, parce qu'ils assurent mieux le fait de savoir si oui ou non on
est bien re-couplés.
J'essaie de détailler un peu ce que je pense dans la suite de votre texte.
Le Jeudi 13 Février 2003 16:16, Jean-Jacques Dubray a écrit :
>
> Je ne pense pas que le decouplage se situe vraiment ici. Le decouplage
> est atteint essentiellement par l'utilisation d'XML qui permet a la meme
> URL de traiter des formats differents ou des versions differentes du
> meme format (on evite ainsi les problemes de recompilation des clients
> lorsque de nouvelles versions apparaissent, le client peu choisir quand
> il evolue d'un format a l'autre sans que son application "casse"). C'est
> tres dur de faire cela avec du CORBA/DCOM/RMI. Ce decouplage est
> indispensable des que le nombre de client passe un certain seuil.
> Comment en effet tous les clients pourraient upgrader au meme moment?
>
Je comprends tout à fait ce que vous voulez dire au sujet des "découplages de
version", et comprends tout à fait qu'il n'est pas question de upgrader tout
le monde au même moment.
Mais cela se fait très bien avec RMI (je ne connais pas les autres techniques
que vous citez). De même qu'avec XML vous pouvez mener une évolution dans vos
documents XML, vous pouvez le faire également avec des objets Java
(heureusement ! ). Pour les évolutions conséquentes, que ce soit XML ou RMI,
il faut de toutes façons des opérations de re-couplage volontaires.
Là où vous gagnez, c'est surtout que le RMI ne peut traiter que des objets
Java. Qu'un des cotés du couple évolue vers une autre technologie, et le
recouplage devient impossible.
Sur cet exemple on voit bien la supériorité du XML quand au... dé-couplage,
mais on voit aussi qu'il faut bien, à un moment ou à un autre, recoupler.
> Un second niveau de decouplage offert par XML c'est que les donnees XML
> sont "semantiquement" accessible, par opposition a structuralement
> accessibles. (e.g. peut acceder a l'information //facture/montant sans
> connaitre le detail du document facture, par contre un programme (C,
> Java, ...) a besoin de connaitre la definition de la structure des
> donnees pour atteindre un attribut). Cela veut dire qu'on peut envoyer
> beaucoup de formats different au meme service tant que les informations
> necessaires sont accessibles.
>
Que ce soit en XML ou en Java, pour atteindre un attribut, vous avez besoin de
la définition de la structure. Si vous l'avez, que ce soit en XML ou en Java,
vous pourrez toujours vous débrouiller. Si vous ne l'avez pas, vous pourrez
être aussi découplés que vous voulez, vous resterez découplés.
> Un troisieme niveau de decouplage service/client existe au niveau de la
> reponse producteur -> consommateur. Les technologies de transformation
> type XSLT qui permettent au service de retourner les donnees dans un
> format 'consommable' par le consommateur. (Notez que les niveaux 1 et 2
> n'aurait pas trop d'utilite si ce troisieme niveau n'existait pas).
>
Ici vous parlez de re-couplage, il me semble ? Le producteur connait le format
consommable, et donc fait la transformation. Cela peut même se faire avec
d'autres technologies que le XSLT - et bien mieux.
> Le quatrieme niveau de decouplage offert par XML est bien sur que le
> verbe et un grand nombre d'adverbes et d'adjectifs qualificatifs peuvent
> etre transmis avec le verbe, voir meme des requetes de traitement tres
> complexes. Ce qui est un peu plus difficile a faire dans un environment
> objet par le bias de methodes.
>
Plus c'est complexe, plus il est préférable d'utiliser des outils simples et
fiables, c'est mon avis.
Là, les environnement objets sont la meilleure réponse connue à ce jour, et
surtout les méthodes de développement. Ce sont elles qui vous permettent de
traiter la complexité, et en aucun cas la faculté de pouvoir multiplier le
nombre de paramètres aux méthodes.
Donc, pour résumer mon intervention : pour le découplage, XML c'est bien, mais
pour le recouplage, en général, les langages informatique c'est mieux.
Quant au "découplage transparent"... No comment.
Cordialement.
--
SARL diaam informatique - 04 50 77 12 60
Ingenierie, développements de systèmes d'information
http://www.diaam-informatique.com
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/02/2003 - 08:02 UTC
webmaster@xmlfr.org
| 
