Pourquoi CORBA a-t-il perdu sa popularité?
Je n'ai jamais entendu personne parler de CORBA en des termes dérisoires, ce qui est étrange étant donné qu'il y a plus de 10 ans, c'était les genoux de l'abeille. Pourquoi CORBA est-il tombé en disgrâce? Était-ce purement que les implémentations étaient mauvaises ou y avait-il quelque chose de plus fondamental?
Ce n'est pas seulement CORBA, c'est RPC en général. Cela inclut des éléments comme DCOM, Java-RMI, .NET Remoting et tous les autres.
Le problème est fondamentalement que l'informatique distribuée est fondamentalement différente de l'informatique locale. RPC essaie de prétendre que ces différences n'existent pas et fait ressembler les appels distants aux appels locaux. Mais, pour construire un bon système distribué, vous devez faire face à ces différences.
Bill Joy, Tom Lyon, L. Peter Deutsch et James Gosling ont identifié 8 sophismes de l'informatique distribuée , c'est-à-dire des choses que les nouveaux venus dans la programmation distribuée croient vrais, mais qui sont en fait faux, ce qui entraîne généralement l'échec du projet ou une augmentation significative des coûts et des efforts. Le RPC est l'incarnation parfaite de ces erreurs, car il est construit sur ces mêmes hypothèses erronées:
- Le réseau est fiable.
- La latence est nulle.
- La bande passante est infinie.
- Le réseau est sécurisé.
- La topologie ne change pas.
- Il y a un administrateur.
- Le coût du transport est nul.
- Le réseau est homogène.
Tout cela est vrai pour l'informatique locale.
Prenez la fiabilité, par exemple: si vous appelez une méthode localement, alors l'appel lui-même réussit toujours . Bien sûr, la méthode appelée elle-même peut avoir une erreur, mais l'appel réel de la méthode réussira toujours. Et le résultat sera toujours renvoyé ou, si la méthode échoue, une erreur sera signalée.
Dans un système distribué, ce n'est pas vrai: l'acte d'appeler la méthode elle-même peut échouer. C'est à dire. de votre côté, il semble que vous ayez appelé la méthode, mais l'appel s'est en fait perdu sur le réseau et n'a jamais atteint la méthode. Ou bien, la méthode a bien reçu l'appel et effectué l'opération, mais le résultat s'est perdu sur le chemin du retour vers vous. Ou la méthode a échoué, mais l'erreur s'est perdue.
Similaire à la latence: localement, l'appel d'une méthode est essentiellement gratuit. La méthode elle-même peut prendre un temps arbitraire pour calculer la réponse , mais l'appel est gratuit. Sur un réseau, un appel peut prendre des centaines de millisecondes.
C'est pourquoi presque tous les projets RPC, y compris CORBA, ont échoué.
Notez que l'inverse fonctionne très bien: si vous prétendez simplement que tous les appels sont distants appelle, alors la pire chose qui puisse arriver est que vous perdez un peu de performances et que votre application contient du code de gestion des erreurs qui ne sera jamais utilisé. C'est ainsi que fonctionne Erlang, par exemple.
Dans Erlang, les processus ont toujours des tas et des collecteurs de déchets distincts, comme s'ils fonctionnaient sur différentes machines sur différents continents, même si ces processus s'exécutent sur le même VM sur le même CPU dans le même espace d'adressage. Si vous passez des données d'un processus à un autre, ces données sont toujours copié, comme cela devrait être le cas, si les processus étaient sur des machines différentes.Les appels sont toujours effectués comme des envois de messages asynchrones.
Ainsi, rendre les appels locaux et distants identiques n'est pas le problème. Les faire ressembler à appels locaux est.
À CORBA, le problème est en fait un peu plus compliqué que cela. En fait , les appels locaux ressemblaient à des appels à distance, mais comme CORBA a été conçu par le comité, les appels à distance étaient incroyablement complexe, car ils devaient être capables de gérer certaines exigences incroyablement absurdes. Et cette complexité a été imposée à tout le monde , même pour les appels locaux.
Encore une fois, par rapport à Erlang, la complexité est beaucoup plus faible. Dans Erlang, envoyer un message à un processus n'est pas plus complexe que d'appeler une méthode en Java. L'interface est fondamentalement la même, seules les attentes sont différentes: les appels de méthode en Java devraient être instantanés et synchrones, à Erlang, les envois de messages devraient être asynchrones et avoir une latence visible Mais en réalité les utiliser n'est pas plus compliqué qu'un simple appel de procédure locale.
Une autre différence est qu'Erlang fait la distinction entre les appels de fonction, qui ne peuvent se produire qu'à l'intérieur d'un processus et sont donc toujours locaux, et les envois de messages, qui se produisent entre les processus et sont supposés toujours distants, même s'ils ne le sont pas. Dans CORBA, tous les appels de méthode sont supposés être distants.
Les technologies d'objets distribués comme CORBA et DCOM ont eu des problèmes de granularité - les implémentations avaient tendance à être trop "bavardes" pour bien fonctionner sur un réseau - et ont généralement divulgué des détails d'implémentation qui ont rendu la solution fragile.
L'orientation vers le service a pris de l'importance en réaction à ces préoccupations.