L’inheritance CORBA?

Pour un projet d’informatique dissortingbuée commençant aujourd’hui avec 0 composants hérités, existe-t-il de bonnes raisons de se pencher sur CORBA?

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

    • lorsque vous créez un système dissortingbué 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 réduit pas,
    • lorsque vous avez un taux élevé de messagerie … et que HTTP ne le coupe pas, ou
    • lorsque vous devez interagir avec des clients et / ou des services CORBA existants.

    Mais cela dit, il existe des alternatives qui font ce que fait CORBA, seulement mieux … ou du moins, prétendent-ils. Par exemple , ICE de ZeroC

    EDIT @fnieto retentit pour dire (ou impliquer) que ICE n’est pas gratuit, mais que TAO l’est.

    Ceci est inexact et trompeur .

    1. ICE est un logiciel GPL, et est disponible en téléchargement gratuit. Vous deviez seulement payer pour ICE si vous / votre entreprise n’êtes pas prêts à vivre avec les termes de la GPL. (Ou si vous avez besoin d’aide.)
    2. J’ai utilisé l’ICE comme exemple d’ alternative à CORBA. TAO est CORBA. Les auteurs de l’ICE font un cas crédible pour expliquer pourquoi ils peuvent obtenir de meilleures performances en ne respectant pas CORBA.
    3. TAO n’est en aucun cas la seule implémentation CORBA gratuite / open-source. Je peux penser à 3 autres, de ma tête.

    L’inconvénient de l’ICE est le manque d’interopérabilité avec les stacks de middleware CORBA, mais selon mon expérience, l’interopérabilité de différentes implémentations CORBA pourrait également poser problème. (Les choses se sont peut-être améliorées dans ce domaine… mais je n’ai pas fait de travail sur CORBA depuis 2002, alors je suis un peu déconnecté.)

    À partir des réponses existantes, cela devient presque 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 obsolète 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 a des extensions RT), 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 encore 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. Bien que le mappage de langage pour CORBA vers Java soit l’un des plus intéressants (ce qui n’est peut-être pas beaucoup), Java dispose déjà d’un très bon modèle d’informatique dissortingbuée qui offre plus de richesse que CORBA. La grande majorité du développement de CORBA que j’ai vu est en C ++ (qui est également le pire mapping de langage).

    Enfin, CORBA propose des invocations asynchrones standardisées sous 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 originales, car les EJB peuvent être facilement transformés en beans CORBA par un peu de configuration. Je pense que la plupart des déploiements Corba ont été implémentés en Java.

    En ce qui concerne la popularité, je pense qu’il pourrait restr des déploiements haut de gamme pendant plusieurs décennies, mais pour la majorité des gens, Corba est morte.

    Il y a beaucoup de manières très sexy de faire la même chose (excepté le haut de gamme mentionné ci-dessus).

    • Cloud computing (services Web, calcul évolutif, couplage libre, mise en queue).
    • Services REST (services web lite).
    • Services SOAP (services Web lourds).
    • Grid / Cluster computing (mise en queue, réduction de carte et similaire)

    Mais bien sûr, votre Milage 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 aspects positifs du Corba.

    Notre application a utilisé CORBA (Orbix) pendant plus de 10 ans, c’est donc un inheritance maintenant. Et pour ce qui 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, par conséquent tous les problèmes difficiles leur incombent.
    • Recruter du personnel peut être un problème. CORBA n’est tout simplement plus cool et ne devient pas plus cool Bien qu’en Irlande, les développeurs C ++ soient un peu moins exigeants.
    • La plupart des cabinets de conseil veulent utiliser les services Web pour le travail d’intégration, donc si vous voulez que les tiers fassent l’intégration, vous aurez probablement besoin d’un API de services Web.

    Maintenant, selon le type de communication que je voulais, je considérerais probablement:

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

    Ceci est davantage basé sur la recherche de personnel et d’expertise, le support tiers et l’exploitation de bibliothèques open source que sur la qualité technique de CORBA, que j’utilise tous les jours et qui est solide si elle est un peu lourde.

    CORBA est certainement démodé, mais il fournit également certaines fonctions de haut niveau prêtes à l’emploi (voir ici ). Cette fonctionnalité peut être réalisée à l’aide de services Web modernes, mais probablement pas de manière standard, et ce, sans beaucoup de travail supplémentaire.

    Cependant, pour 99% des services dissortingbués, CORBA n’est pas souhaitable. C’est moche, complexe et difficile à utiliser.

    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 de la seule norme de livre blanc ouvert. La norme ne dépend d’aucune technologie d’entreprise. RMI (Sun / Oracle), DCOM (maintenant disparu – Microsoft). Il est complètement neutre en termes de fournisseur et de langue. Hormis SOAP, aucune des autres technologies DOS (Dissortingbuted Object Technology) n’est disponible.

    Je suis un architecte de logiciels et je dois régulièrement choisir quel DOS doit être utilisé dans une conception de système. S’il n’y avait pas eu la guerre religieuse à laquelle je fais face à chaque fois, ce serait soit une maman ou un corba.

    Regardez comme ça, si c’était mort, aucun des réseaux 3 / 4G ne fonctionnerait. 3GPP est totalement spécifié CORBA. Le système de satellite européen est tout CORBA spécifié. Demandez-vous pourquoi? C’est parce qu’ils doivent être basés sur des architectures neutres pour les fournisseurs et les langages!

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

    Je vous conseillerais d’examiner attentivement le degré d’interaction asynchrone dont vous avez besoin dans votre système dissortingbué. Je postule que tout système dissortingbué à une échelle non sortingviale 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 de WebServices (ou même de CORBA), mais il met en évidence un aspect de votre sélection de produits qui peut être négligé lors de l’excitation initiale de traitement dissortingbué.