Bon alors c'est quoi ton postulat :
.NET/WCF/Web-Service c'est nul Python/DBus ca rox parcque tu peux faire tout ce que tu fais en WCF/WebServices sauf les trucs inutiles.
Alors comment fais tu aujourd'hui (avec les specs stables de Dbus 1.0) pour : (en terme de web-service)
- exposer un service à des consommateurs (au sens logiciels qui consomme les données) sur internet ?
- comment je consomme un service distant sur internet à partir de mon intranet ?
- comment je gère les transactions dans mes services sans réinventer la roue et de manière standard ?
- comment je gère le cryptage de mes services de manière standards ?
- comment j'implémente les spécifications DBus sur une nouvelle plateforme ? Je dois me coltiner un format qui n'a rien de standard ?
et maintenant pour (en terme de WCF) :
- changere le protocole de communication de mes services sans les modifier, par exemple je veux passer de web-service à com inter-process sur socket par exemple parcque mon client et moi travaillons sur la même machine pour des questions de perf.
- ajouter une couche de cryptage facilement sans toucher au code de mes services.
Les web-services répondent à une problématique bien précise : l'inter-opérabilité (au dépend des perfs souvent). Pour cela ils se basent sur des standards ouverts existant, notamment tous ceux liés au XML et ses dérivés, parcque c'est implémenté dans toutes les plateformes modernes. Au dessus de HTTP pour une raison toute conne : ca passe ces foutus routeurs. Ca résoud pas le problème fondamental, mais ca marche sur le net.
Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Maintenant WCF pourquoi ? Parcque effectivement les web-services c'est pas toujours pertinent quand on a pas les mêmes contraintes d'interopérabilité. Alors avant fallait faire quoi ? Choisir une techno : DCOM ? Socket ? .NET Remoting ? DBus ? Web-Service ?
Et pourquoi devrais-je choisir ? Si demain je dois changer ? Si demain un client veut que je communique par web-service ?
WCF répond à cette problématique : abstraction du protocole de transport mais également abstraction de la manière d'encapsuler les données.
Je peux choisir d'exposer mes services dans différents formats sur différents protocoles simplement en changeant un fichier de conf et en utilisant les formatteurs/channelsupport livrés en standard. Voir j'en rajoute d'autre si j'ai un client chiant qui veut utiliser un truc pas standard (genre DBus).
Tu en conviendras que ca n'a pas grand chose à voir avec DBus, pas les mêmes objectifs, et qu'en l'état des specs de DBus, ce dernier ne répond pas à la moitié des problématique de Services tels qu'exposés par le WCF.
DBus c'est de l'événementiel ultra-simple. Simple parcque tout jeune. Demain ils vont vouloir exposer des services à travers internet (bon courage vu le modèle choisi qui n'est pas toujours client/Serveur) et toute les couches d'abstraction qui vont bien, ils vont vouloir ajouter de l'introspection, ils vont chercher à standardiser la façon d'échanger certains types de données, les normes de cryptage, d'authentification, de transaction, ou alors DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
c'est plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)
Je préfère une techno qui m'expose des services et des données avec des protocoles standards et ouvert qu'un framework libre qui utilise un format proprio d'encapsulation des données.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par TImaniac (site web personnel) . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 2.
.NET/WCF/Web-Service c'est nul Python/DBus ca rox parcque tu peux faire tout ce que tu fais en WCF/WebServices sauf les trucs inutiles.
Alors comment fais tu aujourd'hui (avec les specs stables de Dbus 1.0) pour : (en terme de web-service)
- exposer un service à des consommateurs (au sens logiciels qui consomme les données) sur internet ?
- comment je consomme un service distant sur internet à partir de mon intranet ?
- comment je gère les transactions dans mes services sans réinventer la roue et de manière standard ?
- comment je gère le cryptage de mes services de manière standards ?
- comment j'implémente les spécifications DBus sur une nouvelle plateforme ? Je dois me coltiner un format qui n'a rien de standard ?
et maintenant pour (en terme de WCF) :
- changere le protocole de communication de mes services sans les modifier, par exemple je veux passer de web-service à com inter-process sur socket par exemple parcque mon client et moi travaillons sur la même machine pour des questions de perf.
- ajouter une couche de cryptage facilement sans toucher au code de mes services.
Les web-services répondent à une problématique bien précise : l'inter-opérabilité (au dépend des perfs souvent). Pour cela ils se basent sur des standards ouverts existant, notamment tous ceux liés au XML et ses dérivés, parcque c'est implémenté dans toutes les plateformes modernes. Au dessus de HTTP pour une raison toute conne : ca passe ces foutus routeurs. Ca résoud pas le problème fondamental, mais ca marche sur le net.
Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Maintenant WCF pourquoi ? Parcque effectivement les web-services c'est pas toujours pertinent quand on a pas les mêmes contraintes d'interopérabilité. Alors avant fallait faire quoi ? Choisir une techno : DCOM ? Socket ? .NET Remoting ? DBus ? Web-Service ?
Et pourquoi devrais-je choisir ? Si demain je dois changer ? Si demain un client veut que je communique par web-service ?
WCF répond à cette problématique : abstraction du protocole de transport mais également abstraction de la manière d'encapsuler les données.
Je peux choisir d'exposer mes services dans différents formats sur différents protocoles simplement en changeant un fichier de conf et en utilisant les formatteurs/channelsupport livrés en standard. Voir j'en rajoute d'autre si j'ai un client chiant qui veut utiliser un truc pas standard (genre DBus).
Tu en conviendras que ca n'a pas grand chose à voir avec DBus, pas les mêmes objectifs, et qu'en l'état des specs de DBus, ce dernier ne répond pas à la moitié des problématique de Services tels qu'exposés par le WCF.
DBus c'est de l'événementiel ultra-simple. Simple parcque tout jeune. Demain ils vont vouloir exposer des services à travers internet (bon courage vu le modèle choisi qui n'est pas toujours client/Serveur) et toute les couches d'abstraction qui vont bien, ils vont vouloir ajouter de l'introspection, ils vont chercher à standardiser la façon d'échanger certains types de données, les normes de cryptage, d'authentification, de transaction, ou alors DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
c'est plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)
Je préfère une techno qui m'expose des services et des données avec des protocoles standards et ouvert qu'un framework libre qui utilise un format proprio d'encapsulation des données.