L'eredità CORBA è legacy?

Question

Per un progetto di calcolo distribuito che inizia oggi, con 0 componenti legacy, ci sono buoni motivi per esaminare CORBA?

Answer 1

Ci sono ancora situazioni in cui CORBA potrebbe essere una buona risposta:

• quando stai costruendo un distribuito sistema che prevede una programmazione multipla lingue e piattaforme multiple,
• quando il sistema prevede l'invio strutture dati complesse ... e SOAP non lo taglia,
• quando si hanno alti tassi di messaggistica ... e HTTP non lo taglia, o
• quando devi interagire con client CORBA esistenti e / o servizi.

Ma detto questo, ci sono alternative che fanno ciò che fa CORBA, solo meglio ... o almeno così sostengono. Ad esempio ICE di ZeroC

EDIT @fnieto interviene per dire (o sottintendere) che ICE non è gratuito, ma TAO lo è.

Questo è inaccurato e fuorviante .

1. ICE è un software GPL ed è disponibile per il download gratuito. Dovevi pagare per ICE solo se tu / la tua azienda non siete preparati a rispettare i termini della GPL. (O se hai bisogno di supporto.)
2. Ho usato ICE come esempio di alternativa a CORBA. TAO è CORBA. Gli autori ICE sostengono in modo credibile il motivo per cui possono ottenere prestazioni migliori non essendo conformi a CORBA.
3. TAO non è affatto l'unica implementazione CORBA gratuita / open-source. Posso pensare ad altri 3, dalla cima della mia testa.

Il lato negativo di ICE è la mancanza di interoperabilità con stack di middleware CORBA, ma nella mia esperienza l'interoperabilità di diverse implementazioni CORBA potrebbe anche essere problematica. (Le cose potrebbero essere migliorate in quella zona ... ma non ho fatto alcun lavoro CORBA dal ~ 2002, quindi sono un po 'fuori dal mondo.)

Answer 2

Dalle risposte esistenti, questo arriva a quasi un argomento religioso. Uno può guardare CORBA allo stesso modo del bicchiere mezzo vuoto / mezzo pieno: da un lato, CORBA è un innesto legacy datato, e dall'altro è relativamente stabile con diverse implementazioni disponibili e il "diavolo che conosci".

Nella mia linea di lavoro, vedo CORBA distribuito in sistemi integrati, sistemi in tempo reale (CORBA ha estensioni RT) e simili. Non ci sono molte alternative AFAIK.

Un altro "vantaggio" di CORBA è la disponibilità di diverse implementazioni open source di alta qualità, ad esempio TAO, MICO, JacORB, ecc., con diversi modelli di licenza e supporto. Ci sono anche ancora edizioni commerciali disponibili.

Per quanto riguarda " Most " Le app CORBA in fase di implementazione in Java - non è il caso della mia esperienza. Mentre la mappatura del linguaggio per CORBA su Java è una delle più belle che ci sia (il che potrebbe non dire molto), Java ha già un modello di calcolo distribuito molto bello che offre ricchezza oltre CORBA, e le app all-Java lo usano più di CORBA. La stragrande maggioranza dello sviluppo di CORBA che ho visto è in C ++ (che è anche la peggior mappatura del linguaggio).

Infine, CORBA offre invocazioni standardizzate asincrone sul lato client sotto forma di AMI, ma non ha mai offerto una gestione asincrona sul lato server. TAO offre un'implementazione non standard sul lato server denominata AMH.

Answer 3

Credo che Corba sia stato in qualche modo rianimato dalle specifiche EJB originali, poiché gli EJB possono essere facilmente trasformati in bean CORBA con un po 'di configurazione. Sospetto che la maggior parte delle implementazioni di Corba siano state effettivamente implementate in Java.

Per quanto riguarda la popolarità, penso che potrebbero esserci alcune distribuzioni di fascia alta rimaste per un certo numero di decenni, ma per la maggior parte delle persone Corba è morta.

Ci sono molti modi molto sexy per fare le stesse cose (eccetto la fascia alta di cui sopra).

• Cloud computing (servizi web, calcolo scalabile, accoppiamento lento, accodamento).
• Servizi REST (web-services lite).
• Servizi SOAP (servizi Web pesanti).
• Calcolo griglia / cluster (accodamento, riduzione mappe e simili)

Ma ovviamente il tuo Milage può variare.

Answer 4

Ovviamente dipende dal tipo di server e dalle comunicazioni tra processi che stai prendendo in considerazione. E penso che Stephen C e Chris Cleeland coprano molto bene gli aspetti positivi della Corba.

La nostra applicazione utilizza CORBA (Orbix) da oltre 10 anni, quindi è ormai un'eredità. E per come è scritto CORBA è una buona tecnologia. Tuttavia, se stessi ricominciando, probabilmente non userei CORBA:

• È complicato e solo un piccolo numero di persone nella mia organizzazione lo sa molto bene, di conseguenza tutti i problemi difficili ricadono su di loro da risolvere.
• Il reclutamento del personale può essere un problema. CORBA non è più cool e non sta diventando più cool Anche se in Irlanda gli sviluppatori C ++ sono anche un po 'magri sul campo.
• La maggior parte delle società di consulenza desidera utilizzare i servizi Web per il lavoro di integrazione, quindi se si desidera che terze parti facciano l'integrazione, probabilmente sarà necessario un API dei servizi Web comunque.

Ora, a seconda del tipo di comunicazione che volevo, probabilmente prenderei in considerazione:

• buffer di protocollo per molti piccoli messaggi (so che dovrei fornire il trasporto)
• servizi web per meno messaggi di grandi dimensioni

Questo si basa più sulla ricerca di personale e competenza, sul supporto di terze parti e sull'utilizzo delle librerie open source che sulla qualità tecnica di CORBA, che uso quotidianamente ed è forte se un po 'ingombrante.

Answer 5

CORBA è sicuramente vecchio stile, ma offre anche alcune funzioni di alto livello fuori dalla scatola (vedi qui ). Questa funzionalità potrebbe essere eseguita utilizzando i moderni servizi Web, ma probabilmente non in modo standard e non senza una grande quantità di lavoro extra.

Per il 99% dei servizi distribuiti, tuttavia, CORBA è indesiderabile. È brutto, complesso e difficile da usare.

Answer 6

Una cosa che nessuno ha menzionato qui è APERTA, APERTA STANDARD. Di tutte le tecnologie esistenti (tranne SOAP) è l'unico vero standard di white paper aperto. Lo standard non dipende dalle tecnologie di nessuna organizzazione. RMI (Sun / Oracle), DCOM (ora dismesso - Microsoft). È completamente indipendente dal venditore e dalla lingua. Ad eccezione di SOAP, nessuna delle altre tecnologie DOS (Distributed Object Technology) è

Sono un architetto del software e devo fare regolarmente la scelta del DOS da utilizzare nella progettazione del sistema. Se non fosse per la guerra religiosa che devo affrontare ogni volta, sarebbe una mamma o un CORBA.

Guardalo in questo modo, se fosse così morto, nessuna delle reti 3 / 4G funzionerebbe. 3GPP è totalmente specificato da CORBA. Il sistema satellitare europeo è tutto specificato da CORBA. Chiedetevi perché? È perché devono essere basati su architetture neutre di Vendor e Language!

Answer 7

Direi che l'attuale livello di maturità dei servizi Web (incluso REST) ??e dei bean EJB nel mondo Java (che possono persino usare CORBA sotto le coperte) copre ciò che è necessario per i sistemi aziendali distribuiti.

Consiglierei che un aspetto da considerare attentamente è il grado di interazione asincrona di cui hai bisogno nel tuo sistema distribuito. Ho postulato che qualsiasi sistema distribuito di scala non banale necessita di comunicazioni asincrone e che l'infrastruttura scelta dovrebbe supportare l'elaborazione asincrona, in genere ciò significa code.

Questo non è in contrasto con l'uso di WebServices (o effettivamente CORBA) ma evidenzia un aspetto della selezione del tuo prodotto che può essere trascurato nell'eccitazione iniziale di avviare l'elaborazione distribuita