xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: WS : REST / SOAP
From: Jean-Jacques Dubray (jjd@eigner.com)
Date: 14/02/2003 - 12:28
Herve:
Si l'on fait l'historique des techniques de communication interprocess,
on s'apercoit qu'on a d'abord commence 2 a 2, puis augmenter
progressivement le nombre de participant. L'Internet n'a jamais ete
concu comme support de systemes distribute (s'il avait ete concu pour
cela il serait reste un petit projet sur le coin d'un bureau). Par
contre il est bien sur naturel d'explorer comment utiliser l'Internet
pour permettre a des processus distribues de collaborer entre eux et
quelle sont les avantages de l'Internet lorsqu'un grand nombre de
participants interagissent. Bien sur plein d'autres questions se posent
au niveau du B2B: est ce que les protocols type HTTP/FTP suffisent a
faire du B2B? A-t-on besoin d'autres protocols specializes... Je crois
que les web service cherchent a repondre a la question de maniere
generale, alors qu'ebXML a choisi son cadre: un certain type de B2B ou
les transactions métiers sont majoritaires.
Les puristes du Web (RESTifarians) suggerent de conserver religieusement
l'architecture globale du Web sous peine d'en perdre les avantages.
En ce qui concerne Java / C+ et XML. Il n'y a point d'opposition mais
complementarite. Lorsqu'on utilise CORBA on finit toujours par utilise
un pattern qui je crois s'appelle en Anglais, Data Value Object. Il
consiste a implementer des methodes tres simples et tres rigides qui ne
changent jamais et a faire passer des HashMap de donnees qui peuvent
changer sans demander une recompilation automatique. Bien sur
l'evolution doit etre contrainte pour que cela marche. Je vois XML comme
une generalization de ce pattern. XML permet d'envoyer des structures
beaucoups plus fines et complexes qu'un HashMap. Aucune opposition avec
les languages et les methodes de distribution (RMI, CORBA, ...), XML
offre juste une extension.
La partie protocole des web services essaie de passer outre les
limitations de ces techniques de distribution dans le cas des systemes
"fortement-connectes" (highly connected). En fait la problematique des
web services ou Architecture Orientee Service n'est pas la meme que
celle des systemes fortement distribues (n-tier).
Par exemple, c'est vrai que le re-couplage doit intervenir a un moment
ou un autre, mais l'importance c'est que le re-couplage n'a plus besoin
d'etre synchrone. L'architecture Web Service vous permet aussi de
"switcher" de fournisseur de service sans re-investir dans votre
infrastructure ou implementation.
C'est aussi la que le P2P intervient et dont le mode client/serveur ne
devient qu'un cas d'utilisation particulier du P2P. Dans une
architecture fortement connectee on perd le sens de qui est le client ou
serveur. Les process connectes sont autonomes et ne peuvent se limiter a
des interaction de type client / serveur.
Ayant ete un fana des langages Objets depuis 91 date a laquelle je les
ai decouverts, je ne suis pas pres a les jeter a la corbeille
(qu'utiliser a la place?). Si vous avez un peu de temps vous pouvez lire
cet article que j'ai ecrit qui rapproche la notion d'objet de celle de
document, ce qui a mon sens va devenir une evolution naturelle dans les
annees a venir (X# de Microsoft). Java devra s'adapter ou se
marginaliser. Voici le pointeur:
http://www.odx.it/doc/businessobjectmodeling.pdf
Cheers,
Jean-Jacques Dubray____________________
Eigner Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com
>>-----Original Message-----
>>From: xml-decid-bounce@xmlfr.org [mailto:xml-decid-bounce@xmlfr.org]
On
>>Behalf Of Herve AGNOUX
>>Sent: Friday, February 14, 2003 3:35 AM
>>To: xml-decid@xmlfr.org
>>Subject: [xml-decid] Re: WS : REST / SOAP
>>
>>
>>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)
--
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
|
