Est-ce que CORBA est un héritage?

Question

Existe-t-il de bonnes raisons d'examiner CORBA pour un projet d'informatique distribuée débutant aujourd'hui, avec 0 composant hérité?

Answer 1

Il existe encore des situations où CORBA pourrait être une bonne réponse:

• lorsque vous construisez un environnement distribué système impliquant une programmation multiple langues et plates-formes multiples,
• lorsque votre système implique l'envoi structures de données complexes ... et SOAP ne le coupe pas,
• lorsque le taux de messagerie est élevé ... et HTTP ne le coupe pas, ou
• lorsque vous devez interagir avec clients CORBA existants et / ou services.

Cela dit, il existe des alternatives qui font ce que CORBA fait, mais en mieux ... ou du moins le prétendent-ils. Par exemple, l'ICE de ZeroC

.

MODIFIER @fnieto vous explique (ou implique) que ICE n'est pas libre, mais que TAO l'est.

Ceci est inexact et trompeur .

1. ICE est un logiciel sous GPL, disponible en téléchargement gratuit. Vous ne devez payer ICE que si vous / votre entreprise n'êtes pas prêts à respecter les conditions de la GPL. (Ou si vous avez besoin d'aide.)
2. J'ai utilisé ICE comme exemple d'une alternative à CORBA. TAO est CORBA. Les auteurs de ICE expliquent de manière crédible pourquoi ils peuvent obtenir de meilleures performances en ne respectant pas la norme CORBA.
3. TAO n'est en aucun cas la seule implémentation CORBA libre / open-source. Je peux penser à trois autres personnes qui me viennent à l’esprit.

L'inconvénient d'ICE est le manque d'interopérabilité avec les piles de middleware CORBA, mais d'après mon expérience, l'interopérabilité de différentes implémentations de CORBA pourrait également poser problème. (Les choses se sont peut-être améliorées dans ce domaine ... mais je n'ai pas travaillé à CORBA depuis ~ 2002, alors je suis un peu en retrait.)

Answer 2

À partir des réponses existantes, cela entre presque dans un sujet religieux. On peut regarder CORBA de la même manière que le verre à moitié vide / à moitié plein: d’une part, CORBA est daté d’un cratère hérité, et d’autre part, il est relativement stable avec plusieurs implémentations disponibles et le "diable que vous connaissez".

Dans mon travail, je vois CORBA déployé dans des systèmes embarqués, des systèmes temps réel (CORBA possède des extensions RT), etc. Il n'y a pas beaucoup d'alternatives autant que je sache.

Un autre " avantage " CORBA repose sur la disponibilité de plusieurs implémentations Open Source de haute qualité, telles que TAO, MICO, JacORB, etc., avec des modèles de licence et de support différents. Il existe également des éditions commerciales disponibles.

En ce qui concerne "plus" Les applications CORBA implémentées en Java - ce n'est pas le cas selon mon expérience. Bien que le mappage linguistique de CORBA à Java soit l’un des plus agréables qui soient (ce qui n’en dit peut-être pas beaucoup), Java dispose déjà d’un très beau modèle d’informatique distribuée offrant une richesse allant au-delà de CORBA, et les applications tout Java l’utilisent davantage que CORBA. La grande majorité du développement CORBA que j’ai vu se fait en C ++ (qui est également le pire mappage de langage).

Enfin, CORBA offre des appels asynchrones normalisés côté client sous la forme d’AMI, mais n’a jamais offert de traitement asynchrone côté serveur. TAO propose une implémentation côté serveur non standard appelée AMH.

Answer 3

Je pense que Corba a été en quelque sorte relancé par les spécifications EJB d'origine, car les EJB peuvent facilement être transformés en beans CORBA grâce à un peu de configuration. Je soupçonne que la plupart des déploiements Corba ont effectivement été implémentés en Java.

En ce qui concerne la popularité, je pense que certains déploiements haut de gamme pourraient rester pendant plusieurs décennies, mais pour la majorité des gens, Corba est mort.

Il y a beaucoup de façons très sexy de faire la même chose (à l'exception du haut de gamme mentionné ci-dessus).

• Informatique en nuage (services Web, informatique évolutive, couplage souple, mise en file d'attente).
• Services REST (Web-Services Lite).
• Services SOAP (services Web lourds).
• Informatique en grille / en cluster (mise en file d'attente, réduction de carte et similaire)

Mais bien sûr, votre Milage May peut varier.

Answer 4

Évidemment, cela dépend du type de serveur et de la communication interprocessus envisagés. Et je pense que Stephen C et Chris Cleeland couvrent très bien les aspects positifs du Corba.

Notre application utilise CORBA (Orbix) depuis plus de 10 ans, de même que son héritage. Et pour la façon dont il est écrit CORBA est une bonne technologie. Cependant, si je recommençais, je n’utiliserais probablement pas CORBA:

• C’est compliqué et seul un petit nombre de personnes de mon organisation le savent très bien car tous les problèmes difficiles doivent alors être résolus.
• Le recrutement du personnel peut être un problème. CORBA n’est tout simplement plus cool et ne refroidit pas. En Irlande, les développeurs C ++ sont également un peu maigres.
• La plupart des sociétés de conseil souhaitent utiliser des services Web pour le travail d'intégration. Par conséquent, si vous souhaitez que des tiers effectuent l'intégration, vous aurez probablement besoin d'une API de services Web.

Maintenant, selon le type de communication que je voulais, je prendrais probablement en considération:

• tampons de protocole pour de nombreux petits messages (je sais que je devrais fournir le transport)
• services Web pour moins de gros messages

C’est davantage basé sur la recherche de personnel et d’expertise, le soutien d’une tierce partie et sur l’exploitation de bibliothèques open source, puis sur la qualité technique de CORBA, que j’utilise tous les jours et qui est solide même si elle est un peu lourde.

Answer 5

CORBA est certes un peu démodé, mais il fournit aussi certaines fonctions de haut niveau prêtes à l'emploi (voir ici ). Toutes ces fonctionnalités pourraient être réalisées à l'aide de services Web modernes, mais probablement pas de manière standard et sans beaucoup de travail supplémentaire.

Pour 99% des services distribués, cependant, CORBA n'est pas souhaitable. C'est moche, complexe et difficile à utiliser.

Answer 6

Une chose que personne n’a mentionnée ici est OPEN, OPEN STANDARDS. De toutes les technologies existantes (à l’exception de SOAP), il s’agit du seul véritable standard de papier blanc ouvert. La norme ne repose pas sur les technologies d'une seule organisation. RMI (Sun / Oracle), DCOM (maintenant supprimé - Microsoft). Il est complètement neutre vis-à-vis du fournisseur et de la langue A l'exception de SOAP, aucune des autres technologies DOS (Distributed Object Technology) n'est

Je suis un architecte logiciel et je dois régulièrement choisir le type de DOS à utiliser dans une conception de système. Si ce n’était la guerre de religion à laquelle je suis confronté à chaque fois, ce serait soit une maman, soit un corba.

Si vous êtes mort, aucun des réseaux 3 / 4G ne fonctionnera. 3GPP est totalement spécifié par CORBA. Le système européen de satellites est spécifié par CORBA. Demandez-vous pourquoi? C’est parce qu’elles doivent reposer sur des architectures neutres en termes de fournisseurs et de langues!

Answer 7

Je dirais que le niveau de maturité actuel des services Web (y compris REST) ??et du monde Java (qui peuvent même utiliser CORBA sous les couvertures) couvre ce qui est nécessaire pour les systèmes d'entreprise distribués.

Je vous conseillerais d'examiner attentivement le degré d'interaction asynchrone dont vous avez besoin dans votre système distribué. Je postule que tout système distribué d’une échelle non triviale nécessite des communications asynchrones et que l’infrastructure choisie doit prendre en charge le traitement asynchrone, ce qui signifie généralement des files d’attente.

Cela n’est pas incompatible avec l’utilisation des WebServices (ou bien de CORBA), mais il indique un aspect de votre sélection de produits qui peut être négligé lors de l’expérience initiale liée à la mise en place d’un traitement distribué

.