Tu attaques en disant les Web Services ca sert à rien et DBus fait déjà tout ça en mieux et plus simple.
On t'explique que les problématiques à résoudre ne sont pas les mêmes puisque pour l'un il s'agit de faire communiquer des architectures différentes et pour l'autre d'une architecture de communication particulière et que l'interêt réside dans cette différence et après tu débarques
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). comme si tu allais nous l'apprendre.
Alors effectivement sa conception ne peut être que plus simple puisqu'il ne traite l'intéropérabilté qu'avec les composants d'une même architecture. Aucun mérite donc . Heureusement qu'il n'ont pas cheché la complication. Donc tes remarques du style
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN.
sont hors sujet
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
Non différentes architectures qu'elles soient à base de composants ou simplement RPC ou encore orientée services ou que sais-je encore peuvent commmuniquer grâce aux Web Services.
Si je veux communiquer entre du DCOM et du DBUS je devrai prévoir une passerelle particulière en se basant sur un pont) et pareil avec une impléméntation de CORBA sur un quelconque ORB ou encore du RMI ou même du simple RPC.
Je devrai attaquer des réferentiels d'objets qui n'utilisent pas les même façon d'exposer leur composant/services qui n'adoptent pas les mêmes conventions, les même structures ni protocoles d'échanges, ni les même paradigmes (procédural, SOA, architecture à base de composant)..... Bref dès qu'on souhaite communiquer en dehors de l'entreprise il faut tout remettre à plat avec chaque nouveau partenaire et redévelopper ou bien imposer à ses partenaires une migration.
Donc l'idée qui n'a rien de magique certes , c'est de se dire: Adoptons un standard de communication "inter" architecture commun. Ce standard c'est les Web Services. Tu aurais pu le comparer avec CORBA qui avait été une tentative de l'OMG de le réaliser. L'erreur qu'ils ont fait était de ne vouloir se limiter qu'a des architectures à base de composants en mode synchrone alors que si je veux m'interconnecter avec ton système d'information Je me fous de savoir quelle est ton architecture. Pour connaitre tous les comptes d'un client ca ne m'interesse pas de parcourir tous les comptes de ta banque en vérifiant qu'il appartiennent bien au client rechercher dans ta banque alors qu'un autre partenaire à décidé que ses objets clients référencaient directement leur compte ou encore que celui ci a implémenté une facade pour se faire.
Ce qui m'interesse c'est
"Quelle est la liste des RIBs du client "Duchmoll Jean Pierre" dans la banque.
J'attend qu'on renvoie un simple liste de RIB et je ne veux pas savoir comment c'est foutu dans DBUS, DCOM, CORBA ou chez toi avec ton protocole personnalisé au dessus de RPC.
Moi je comprend mais surtout mes AMOs comprenent et là ils se disent que cette requête peut servir dans des autres procesus métiers ou que ce processus peut être amélirié si je la place à un autre endoit . Il peuvent faire des simulation et moi en tant qu'architecte je peux enfin capitaliser sur un catalogue de services réutilsable sans m'arracher les cheveux à chaque evolution du besoin.
Et là on commence à comprendre l'intérêt de WCF puisqu'il unifie tout dans une approche orientée service que ce soit dans mon réseau d'entreprise ou sur internet.
Voilà lorsque tu auras déjà admis ca et la compléxité inhéhente qui en découle (y'a pas d'appproche saine ou pas saine à avoir) tu pourras te pencher sur l'implémentation et comprendre l'interêt de celle de M$ et comparer sa compléxité avec des autres approches du même type. Pas en comparant avec l'API de DBUS comme tu le fais.
Quand ca t'arrange la comparaison vaut le coup et quand ca ne t'arrange pas il faut pas mélanger les torchons et les serviettes.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo_le_clown . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 1.
Tu attaques en disant les Web Services ca sert à rien et DBus fait déjà tout ça en mieux et plus simple.
On t'explique que les problématiques à résoudre ne sont pas les mêmes puisque pour l'un il s'agit de faire communiquer des architectures différentes et pour l'autre d'une architecture de communication particulière et que l'interêt réside dans cette différence et après tu débarques
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). comme si tu allais nous l'apprendre.
Alors effectivement sa conception ne peut être que plus simple puisqu'il ne traite l'intéropérabilté qu'avec les composants d'une même architecture. Aucun mérite donc . Heureusement qu'il n'ont pas cheché la complication. Donc tes remarques du style
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN.
sont hors sujet
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
Non différentes architectures qu'elles soient à base de composants ou simplement RPC ou encore orientée services ou que sais-je encore peuvent commmuniquer grâce aux Web Services.
Si je veux communiquer entre du DCOM et du DBUS je devrai prévoir une passerelle particulière en se basant sur un pont) et pareil avec une impléméntation de CORBA sur un quelconque ORB ou encore du RMI ou même du simple RPC.
Je devrai attaquer des réferentiels d'objets qui n'utilisent pas les même façon d'exposer leur composant/services qui n'adoptent pas les mêmes conventions, les même structures ni protocoles d'échanges, ni les même paradigmes (procédural, SOA, architecture à base de composant)..... Bref dès qu'on souhaite communiquer en dehors de l'entreprise il faut tout remettre à plat avec chaque nouveau partenaire et redévelopper ou bien imposer à ses partenaires une migration.
Donc l'idée qui n'a rien de magique certes , c'est de se dire: Adoptons un standard de communication "inter" architecture commun. Ce standard c'est les Web Services. Tu aurais pu le comparer avec CORBA qui avait été une tentative de l'OMG de le réaliser. L'erreur qu'ils ont fait était de ne vouloir se limiter qu'a des architectures à base de composants en mode synchrone alors que si je veux m'interconnecter avec ton système d'information Je me fous de savoir quelle est ton architecture. Pour connaitre tous les comptes d'un client ca ne m'interesse pas de parcourir tous les comptes de ta banque en vérifiant qu'il appartiennent bien au client rechercher dans ta banque alors qu'un autre partenaire à décidé que ses objets clients référencaient directement leur compte ou encore que celui ci a implémenté une facade pour se faire.
Ce qui m'interesse c'est
"Quelle est la liste des RIBs du client "Duchmoll Jean Pierre" dans la banque.
J'attend qu'on renvoie un simple liste de RIB et je ne veux pas savoir comment c'est foutu dans DBUS, DCOM, CORBA ou chez toi avec ton protocole personnalisé au dessus de RPC.
Moi je comprend mais surtout mes AMOs comprenent et là ils se disent que cette requête peut servir dans des autres procesus métiers ou que ce processus peut être amélirié si je la place à un autre endoit . Il peuvent faire des simulation et moi en tant qu'architecte je peux enfin capitaliser sur un catalogue de services réutilsable sans m'arracher les cheveux à chaque evolution du besoin.
Et là on rentre dans le SOA.
http://en.wikipedia.org/wiki/Service-oriented_architecture
Et là on commence à comprendre l'intérêt de WCF puisqu'il unifie tout dans une approche orientée service que ce soit dans mon réseau d'entreprise ou sur internet.
Voilà lorsque tu auras déjà admis ca et la compléxité inhéhente qui en découle (y'a pas d'appproche saine ou pas saine à avoir) tu pourras te pencher sur l'implémentation et comprendre l'interêt de celle de M$ et comparer sa compléxité avec des autres approches du même type. Pas en comparant avec l'API de DBUS comme tu le fais.
Quand ca t'arrange la comparaison vaut le coup et quand ca ne t'arrange pas il faut pas mélanger les torchons et les serviettes.