Pourquoi CORBA a-t-il perdu sa popularité?

Question

Je n'ai jamais entendu personne parler de CORBA autrement qu'en termes dérisoires, ce qui est étrange compte tenu du fait qu'il y a 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?

Answer 1

Ce n'est pas seulement CORBA, c'est de la RPC en général. Cela inclut des choses comme DCOM, Java-RMI .NET Remoting et tous les autres.

Le problème est essentiellement que le calcul distribué est fondamentalement différente de local informatique. RPC essaie de prétendre que ces différences n'existent pas, et fait des appels à distance regardent comme des appels locaux. Mais, pour construire un bon système distribué, vous devez traiter ces différences.

Bill Joy, Tom Lyon, L. Peter Deutsch et James Gosling identifié 8 Erreurs de Calcul Distribué, c'est à dire des choses que les nouveaux arrivants à la programmation distribuée croyez être vrai, mais qui sont en réalité des faux, ce qui entraîne généralement l'échec d'un projet ou d'une augmentation significative des coûts et des efforts. RPC est l'incarnation parfaite de ces erreurs, car il est construit sur les mêmes hypothèses fausses:

1. Le réseau est fiable.
2. Le temps de latence est de zéro.
3. La bande passante est infini.
4. Le réseau est sécurisé.
5. La topologie ne change pas.
6. Il y a un administrateur.
7. Le coût du Transport est de zéro.
8. Le réseau est homogène.

Tout cela est vrai pour l'informatique locale.

Prendre la fiabilité, par exemple: si vous appelez une méthode en local, puis de l'appel lui-même toujours réussit. Bien sûr, la méthode appelée elle-même peut avoir une erreur, mais l'appel de la méthode sera toujours succed. Et le résultat sera toujours retourné, ou, si la méthode échoue, une erreur sera signalée.

Dans un système distribué, ce n'est pas vrai: la loi de l'appel de la méthode elle-même peut échouer. I. e. à partir de votre fin on dirait que vous avez appelé la méthode, mais l'appel fait s'est perdu sur le réseau et n'ont jamais atteint la méthode. Ou, la méthode avec succès, a reçu l'appel et a réalisé 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 perdu.

Similaires avec des temps de latence: localement, l'appel d'une méthode est essentiellement gratuit. La méthode elle-même peut prendre une quantité arbitraire de temps pour calculer la réponse, mais l' appel est gratuit. Sur un réseau, un appel peut prendre plusieurs centaines de millisecondes.

C'est pourquoi à peu près tous RPC projets, y compris CORBA a échoué.

Notez que l'inverse fonctionne très bien: si vous venez de prétendre que tous les appels sont à distance des appels, puis la pire chose qui puisse arriver est que vous perdez un peu de performance et de votre application contient une erreur de manipulation de code qui ne sera jamais utilisé. C'est comment Erlang travaux, par exemple.

En Erlang, processus de toujours avoir des tas distincts et séparés ramasseurs d'ordures, comme si elles étaient en cours d'exécution sur des machines différentes sur les différents continents, même si ces processus sont exécutés sur la même machine virtuelle sur le même PROCESSEUR dans le même espace d'adressage. Si vous transmettez des données à partir d'un processus à un autre, que les données sont toujours copiés, tout comme il devrait être, si les processus ont été sur des machines différentes. Les appels sont toujours fait comme message asynchrone envoie.

Ainsi, faire local et à distance des appels de regarder le même n'est pas le problème. Faire ressembler à des locaux d'appels est.

Dans CORBA, le problème est en réalité un peu plus complexe que cela. En fait ils ne font appels locaux ressemblent à des appels à distance, mais depuis CORBA a été conçu par le comité, à distance des appels ont été incroyablement complexe, parce qu'ils devaient être en mesure de traiter certaines incroyablement absurde exigences. Et cette complexité s'est imposé à tout le monde, même pour les appels locaux.

De nouveau, la comparant à Erlang, la complexité est beaucoup plus faible. En Erlang, l'envoi d'un message à un processus n'est pas plus complexe que l'appel d'une méthode en Java. L'interface est fondamentalement la même, c'est seulement les attentes sont différentes: les appels de méthode en Java devraient être instantanée et synchrone, en Erlang, envoie des messages devraient être asynchrone et visible de la latence. Mais en réalité, l'aide n'est pas plus impliqué qu'un simple appel de procédure locale.

Une autre différence est que Erlang fait la distinction entre les appels de fonction, qui ne peut se produire à l'intérieur d'un processus, et donc sont toujours locales, et envoie des messages, qui se produisent entre les processus et sont supposés être toujours à distance, même si ils ne le sont pas. Dans CORBA, tous les appels de méthode sont supposés être à distance.

Answer 2

Les technologies d'objets distribués telles que CORBA et DCOM rencontraient des problèmes de granularité - les implémentations avaient tendance à être trop «bavardes» pour fonctionner correctement sur un réseau - et des informations de mise en œuvre généralement divulguées rendaient la solution fragile.

L'orientation service a pris de l'importance en réaction à ces préoccupations.

Answer 3

Il y a une section sur ses problèmes et critiques dans l'article de Wikipédia: http://fr.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture