ムの種類や場所に関係なく連動可能である。すなわち、エンドユーザーは、自分の使っているシステムだけではなく、広くそれ以外の社内や社外のシステムのソフトウェアコンポーネント及びアプリケーションを利用することが可能となる。
(エ) 流通ソフトウェアの活用によるアプリケーション構築費用の削減
今後CORBAのようなオープンな規格に準拠した各種のソフトウェアコンポーネント(ファシリティ)が流通し、市場を形成していくと考えられる。それらのうち適切なものを購入して積木のように組み立てるだけで、必要な機能をもつアプリケーションを安価に構築することが可能となる言われている。
一方、短所として次のものがある。
(オ) 開発、実行環境におけるオーバーヘッドの増大
前述のようにCORBA環境における全てのプログラム群は、互いにIDLを介してそのインタフェースを公開することになっている。それで、開発時にはIDLコンパイラーを介して得られるサーバー側ではスケルトンファイル、クライアント側ではスタブファイルを、それぞれの側のプログラムに入れ込む必要がある。実行時においては、特にネットワークを介してのCORBAコンポーネントの連携について速度面から十分な事前検証が必要とされる。
(カ) ベンダー各社のCORBAに縛られること
CORBA規格はあくまでも論理上の統一規格であり、実装面に関してはベンダー各社の提供するCORBA製品は、完全な意味での互換性が保証されていない。従って、統一仕様に準拠しているとは言っても、やはりあるベンダーのCORBA製品から他の同等品への切替えには手間がかかることが懸念される。
(2) DCOMの概要
(a) DCOMの特徴
DCOMは、CORBA同様分散オブジェクト技術であり、その目標とは「コンポーネント利用によるソフトウェア品質及び生産性の向上」である。CORBAとの比較においてDCOMは次のような特徴を持っている。
(ア) 仕様の独自性
CORBAが業界全体の協調によって仕様決定がなされているのに比べ、DCOMはマイクロソフト社の製品として同社が独自にその仕様を決定し、かつ実装してきた。ただし、最近になってDCOMのこの閉鎖性が解消しつつある。
(イ) バイナリー互換性の確保
前述のようにCORBAではIDLコンパイラーを通して生成されたソースコードを介して、クライアント側とサーバー側のコンポーネントがインタフェースの整合を取る仕組みになっている。それに対し、DCOMでは実行形式(バイナリーファイル)で直接クライアント側とサーバー側のコンポーネントがインタフェースの整合を取る仕組みになっている。
