CORBAが良い答えになる可能性がある状況がまだあります。
- 複数のプログラミング言語と複数のプラットフォームを含む分散システムを構築する場合、
- システムが複雑なデータ構造の送信を伴う場合...およびSOAPはそれをカットしませんが、
- メッセージング率が高い場合...そしてHTTPはそれをカットしない、または
- 既存のCORBAクライアントやサービスとやり取りする必要がある場合。
しかし、そうは言っても、CORBAが行うことを実行する代替策はありますが、それよりも優れているだけです...例 ZeroCのICE
[〜＃〜] edit [〜＃〜]@fnietoは、ICEは無料ではないがTAOは無料であると言う（または示唆する）ためにチャイムします。
これは不正確で誤解を招く可能性があります。
- ICEはGPL対応のソフトウェアであり、無料でダウンロードできます。あなた/あなたの会社がGPLの条件を守る準備ができていない場合にのみ、ICEを支払う必要がありました。 （または、サポートが必要な場合。）
- CORBAの代替の例としてICEを使用しました。 TAOはCORBAです。 ICEの作成者は、CORBAに準拠しないことでパフォーマンスが向上する理由について、信頼できる主張をしています。
- TAOは、唯一のフリー/オープンソースCORBA実装ではありません。私は頭の上の3人を考えることができます。
ICEのマイナス面は、CORBAミドルウェアスタックとの相互運用性の欠如ですが、私の経験では、異なるCORBA実装の相互運用性にも問題がある可能性があります。 （その領域では状況が改善された可能性があります...しかし、2002年以降、CORBAの作業を行っていないため、少し連絡が取れません。）
既存の回答から、これはほとんど宗教的な話題に入ります。 CORBAは、ハーフエンプティ/ハーフフルグラスと同じように見ることができます。一方、CORBAはレガシークルーフトと呼ばれ、もう一方では、いくつかの実装が利用可能で「知っている悪魔」と比較的安定しています。
私の業務では、組み込みシステム、リアルタイムシステム（CORBAにはRT拡張機能）など）にCORBAが展開されているのがわかります。AFAIKに代わるものは多くありません。
CORBAのもう1つの「利点」は、ライセンスとサポートモデルが異なるTAO、MICO、JacORBなど、いくつかの高品質なオープンソース実装が利用できることです。まだ商用版もあります。
Javaで実装されている「ほとんど」のCORBAアプリに関しては、私の経験ではそうではありません。 CORBAからJavaへの言語マッピングは、最も良いものの1つですが（あまり言わないかもしれません））、Javaにはすでに非常に優れた分散コンピューティングがありますCORBAを超えた豊富さを提供するモデル、およびすべてのJavaアプリは、CORBAよりもそれを使用します。私が見たCORBA開発の大部分はC++（これは最悪の言語マッピングでもあります）で行われています。
最後に、CORBAは標準化された非同期のクライアント側呼び出しをAMIの形式で提供しますが、サーバー側で非同期処理を提供することはありません。 TAOは、AMHと呼ばれる非標準のサーバー側実装を提供します。
EJBは簡単な構成でCORBA Beanに簡単に変換できるため、Corbaは元のEJB仕様によって復活したと思います。ほとんどのCorbaデプロイメントは実際にはJavaで実装されていたと思います。
人気に関しては、何十年もの間ハイエンドの展開が残っている可能性があると思いますが、大多数の人にとって、Corbaは死んでいます。
同じことを行うには非常にセクシーな方法がたくさんあります（上記のハイエンドを除く）。
- クラウドコンピューティング（Webサービス、スケーラブルコンピューティング、疎結合、キューイング）。
- RESTサービス（web-services lite）。
- SOAPサービス（Webサービスの負荷が高い）。
- グリッド/クラスターコンピューティング（キューイング、マップ縮小など）
しかし、もちろんあなたのMilageは変化します。
明らかにそれはあなたが検討しているサーバーとプロセス間通信のタイプに依存します。そして、Stephen CとChris Cleelandは、Corbaの良い点を非常によくカバーしていると思います。
私たちのアプリケーションは10年以上にわたってCORBA（Orbix）を使用しているため、現在はレガシーです。そして、それがどのように書かれるかに関して、CORBAは良い技術です。ただし、最初からやり直した場合は、おそらくCORBAを使用しません。
- それは複雑であり、私の組織のごく少数の人々だけがそれを非常によく知っているので、すべての難しい問題は解決する必要があります。
- 採用スタッフが問題になることがあります。 CORBAはもはやクールではなく、クールになりません。アイルランドでは、C++開発者も地面が少し薄いです。
- ほとんどのコンサルティング会社は、統合作業にWebサービスを使用したいので、サードパーティに統合を実行させたい場合は、とにかくおそらくWebサービスAPIが必要になります。
今私が望んでいたコミュニケーションの種類に応じて、私はおそらく考えます：
- 多数の小さなメッセージ用のプロトコルバッファ（トランスポートを提供する必要があることはわかっています）
- 大きなメッセージを減らすためのWebサービス
これは、スタッフと専門知識の検索、サードパーティのサポート、オープンソースライブラリの活用に基づいています。CORBAの技術的な品質は、私が日常的に使用しているもので、少し面倒でも強力です。
CORBAは確かに古い形式ですが、すぐに使用できる特定の高水準関数も提供します（ ここ を参照）。この機能はすべて最新のWebサービスを使用して実行できますが、おそらく標準的な方法ではなく、大量の追加作業なしでは実行できません。
ただし、99％の分散サービスでは、CORBAは望ましくありません。醜くて複雑で使いにくい。
ここで誰も言及していないことの1つは、OPEN、OPEN STANDARDSです。存在するすべてのテクノロジー（SOAPを除く）の中で、それは唯一の真のオープンホワイトペーパー標準です。この規格は、1つの組織のテクノロジーに依存していません。 RMI（Sun/Oracle）、DCOM（現在は非難-マイクロソフト）。それは完全にベンダーと言語に中立です。 SOAPを除き、他のDOS（分散オブジェクトテクノロジ）テクノロジはどれも
私はソフトウェアアーキテクトであり、システム設計でどのDOSを使用するかを定期的に選択する必要があります。それが私が毎回直面する宗教戦争のためでなければ、それはMOMかCORBAのどちらかでしょう。
このように見てください、もしそれが死んでいるとしたら、3/4Gネットワークはどれも機能しません。 3GPPは完全にCORBA仕様です。欧州衛星システムは、すべてCORBAで指定されています。なぜだと思う？それは、ベンダーと言語に依存しないアーキテクチャに基づいている必要があるためです。
Webサービス（RESTを含む）の現在の成熟度レベルとJava世界のEJB（内部でCORBAを使用することさえあります））は、分散型エンタープライズシステムに必要なものをカバーしていると思います。
注意深く検討する必要のある側面の1つは、分散システムで必要な非同期相互作用の程度です。重要な規模の分散システムには非同期通信が必要であり、選択したインフラストラクチャは非同期処理をサポートする必要があると私は仮定します。これは通常、キューを意味します。
これはWebServices（または実際にCORBA）の使用と矛盾しませんが、いくつかの分散処理を実行する最初の興奮で見落とされる可能性がある製品選択の側面を示しています。