CORBA est-il hérité?
Pour un projet informatique distribué commençant aujourd'hui, avec 0 composants hérités, y a-t-il de bonnes raisons de se pencher sur CORBA?
Il existe encore des situations où CORBA pourrait être une bonne réponse:
- lorsque vous créez un système distribué impliquant plusieurs langages de programmation et plusieurs plates-formes,
- lorsque votre système implique l'envoi de structures de données complexes ... et SOAP ne le coupe pas,
- lorsque vous avez des taux élevés de messagerie ... et HTTP ne le coupe pas, ou
- lorsque vous devez interagir avec les clients et/ou services CORBA existants.
Mais cela dit, il existe des alternatives qui font ce que CORBA fait, mais en mieux ... ou du moins c'est ce qu'ils prétendent. Par exemple ICE ZeroC
[~ # ~] modifier [~ # ~] @fnieto se met à dire (ou impliquer) que ICE n'est pas gratuit, mais TAO l'est.
C'est inexact et trompeur.
- ICE est un logiciel sous GPL et est disponible en téléchargement gratuit. Vous n'avez dû payer pour ICE que si vous/votre entreprise n'êtes pas prêt à respecter les conditions de la GPL. (Ou si vous avez besoin d'assistance.)
- J'ai utilisé ICE comme exemple d'une alternative à CORBA. TAO est CORBA. Les auteurs de l'ICE démontrent de manière crédible pourquoi ils peuvent obtenir de meilleures performances en n'étant pas conformes à CORBA.
- TAO n'est en aucun cas la seule implémentation CORBA gratuite/open-source. Je peux penser à 3 autres, du haut de ma tête.
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é des différentes implémentations CORBA pourrait également être problématique. (Les choses se sont peut-être améliorées dans ce domaine ... mais je n'ai effectué aucun travail CORBA depuis ~ 2002, donc je suis un peu déconnecté.)
D'après les réponses existantes, cela entre dans un sujet presque religieux. On peut regarder CORBA de la même manière que le verre à moitié vide/à moitié plein: d'une part, CORBA est une ancienne cruauté, et d'autre part il est relativement stable avec plusieurs implémentations disponibles et le "diable vous savez".
Dans ma ligne de travail, je vois CORBA déployé dans des systèmes embarqués, des systèmes en temps réel (CORBA a RT extensions), etc.) Il n'y a pas beaucoup d'alternatives AFAIK.
Un autre "avantage" de CORBA est la disponibilité de plusieurs implémentations open source de haute qualité, par exemple TAO, MICO, JacORB, etc., avec différents modèles de licence et de support. Il existe également des éditions commerciales disponibles.
En ce qui concerne "la plupart" des applications CORBA mises en œuvre en Java - ce n'est pas le cas dans mon expérience. Alors que le mappage de langage pour CORBA à Java est l'un des plus agréables qui soit (ce qui ne veut pas dire grand-chose), Java a déjà un très bon calcul distribué) modèle qui offre une richesse au-delà de CORBA, et les applications tout Java utilisent plus que CORBA. La grande majorité du développement CORBA que j'ai vu est en C++ (qui est également le pire mappage de langage).
Enfin, CORBA propose des invocations côté client asynchrones standardisées sous la forme d'AMI, mais n'a jamais proposé de gestion asynchrone côté serveur. TAO propose une implémentation côté serveur non standard appelée AMH.
Je crois que Corba a été en quelque sorte relancé par les spécifications EJB d'origine, car les EJB peuvent être facilement transformés en beans CORBA par un peu de configuration. Je soupçonne que la plupart des déploiements Corba ont été réellement implémentés en Java.
En ce qui concerne la popularité, je pense qu'il pourrait y avoir des déploiements haut de gamme restants 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 (sauf le haut de gamme mentionné ci-dessus).
- Cloud computing (services Web, informatique évolutive, couplage lâche, file d'attente).
- Services REST (web-services lite).
- Services SOAP (services Web lourds).
- Grid/Cluster computing (mise en file d'attente, réduction de carte et similaire)
Mais bien sûr, votre kilométrage peut varier.
Évidemment, cela dépend du type de serveur et de la communication interprocessus que vous envisagez. Et je pense que Stephen C et Chris Cleeland couvrent très bien les points positifs de la Corba.
Notre application utilise CORBA (Orbix) depuis plus de 10 ans, elle est donc désormais héritée. 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 dans mon organisation le savent très bien, par conséquent tous les problèmes difficiles leur incombent à résoudre.
- Le recrutement de personnel peut être un problème. CORBA n'est tout simplement plus cool et ne se refroidit pas Bien qu'en Irlande, les développeurs C++ sont également un peu minces sur le terrain.
- La plupart des sociétés de conseil souhaitent utiliser les services Web pour les travaux d'intégration, donc si vous souhaitez que des tiers effectuent l'intégration, vous aurez probablement besoin d'une API de services Web de toute façon.
Maintenant, selon le type de communication que je voulais, je considérerais probablement:
- tampons de protocole pour beaucoup de petits messages (je sais que je devrais fournir le transport)
- services Web pour moins de gros messages
Cela repose davantage sur la recherche de personnel et d'expertise, le support tiers et l'exploitation des bibliothèques open source que la qualité technique de CORBA, que j'utilise tous les jours et qui est forte mais un peu lourde.
CORBA est certainement démodé, mais il fournit également certaines fonctions de haut niveau hors de la boîte (voir ici ). Cette fonctionnalité pourrait être réalisée à l'aide de services Web modernes, mais probablement pas de manière standard, et non sans beaucoup de travail supplémentaire.
Cependant, pour 99% des services distribués, CORBA n'est pas souhaitable. C'est moche, complexe et difficile à utiliser.
Personne n'a mentionné ici les NORMES OUVERTES OU OUVERTES. De toutes les technologies existantes (à l'exception de SOAP), c'est la seule véritable norme de livre blanc ouvert. La norme ne dépend pas des technologies d'une organisation. RMI (Sun/Oracle), DCOM (aujourd'hui disparu - Microsoft). Il est complètement neutre vis-à-vis du vendeur et de la langue. À l'exception de SOAP, aucune des autres technologies DOS (Distributed Object Technology) n'est
Je suis architecte logiciel et je dois régulièrement faire le choix du DOS à utiliser dans la conception d'un système. S'il n'y avait pas eu la guerre religieuse à laquelle je fais face à chaque fois, ce serait soit une MOM soit une CORBA.
Regardez-le de cette façon, s'il était mort, aucun des réseaux 3/4G ne fonctionnerait. 3GPP est totalement spécifié par CORBA. Le système satellite européen est entièrement spécifié par CORBA. Demandez-vous pourquoi? C'est parce qu'ils doivent être basés sur des architectures indépendantes du vendeur et du langage!
Je dirais que le niveau de maturité actuel des services Web (y compris REST) et dans les Java EJB mondiaux (qui peuvent même utiliser CORBA sous les couvertures) couvrent ce qui est nécessaire pour les systèmes d'entreprise distribués .
Je conseillerais qu'un aspect que vous devriez examiner attentivement est 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 a besoin de communications asynchrones, et l'infrastructure choisie devrait prendre en charge le traitement asynchrone, généralement des files d'attente.
Ce n'est pas incompatible avec l'utilisation de WebServices (ou même de CORBA), mais cela met en évidence un aspect de votre sélection de produits qui peut être négligé dans l'excitation initiale d'obtenir un traitement distribué.