「Distributed Component Object Model」の版間の差分
編集の要約なし |
Claw of Slime (会話 | 投稿記録) |
||
33行目: | 33行目: | ||
* [http://j-interop.sourceforge.net/ j-Interop] |
* [http://j-interop.sourceforge.net/ j-Interop] |
||
{{Computer-stub}} |
{{Computer-stub}} |
||
{{Microsoft APIs}} |
|||
{{Windows Components}} |
{{Windows Components}} |
||
2014年10月9日 (木) 11:44時点における版
Distributed Component Object Model(DCOM)は、ネットワーク上に分散配置されたコンピュータ上のソフトウェアコンポーネント間通信(分散オブジェクト技術)のためのマイクロソフト独自の技術。
概要
DCOM は当初 "Network OLE" と呼ばれ、マイクロソフトのCOMを拡張したものであり、マイクロソフトの COM+ サーバ基盤上での通信基盤となっていた。その後、.NET Framework の登場とともに廃れていった。
頭に "D" と付いたのは、DCE/RPC (正確に言えば、DCE/RPC をマイクロソフトが拡張した MSRPC)を採用したことからである。
COM から DCOM への拡張では以下の問題を解決しようとした:
- マーシャリング - リモートのメソッド呼び出しでのシリアライズ
- 分散ガベージコレクション - 例えば、クライアントプロセスが壊れたり、ネットワーク接続が失われたとき、インタフェースのクライアントが保持する参照が解放されることを保証する。
これらを解決するため、DCOM の基盤となる RPC 機構としてDCE/RPCが使われた。DCE/RPCでは、マーシャリングやメモリ解放の責任について厳密な規則が規定されていた。
DCOM は CORBA と対抗する規格であった。これらの技術は、インターネット上でのコードとサービスの再利用のためのモデルとなると考えられていた。しかし、これらの技術をファイアウォール上で利用する際の困難さや、セキュリティの確保されていないマシン上で使用する際の問題のため、HTTP とウェブブラウザの組合せがこれらの技術に勝利した。マイクロソフトは "ncacn_http" (Network Computing Architecture, Connection-based, over HTTP) と呼ばれるHTTPトランスポートを DCE/RPC に追加することでこの流れを止めようとして失敗した(後にこの手法は HTTP 上で Exchange 2003 接続をサポートするために復活した)。
派生のバージョンと実装
The Open Group は COMsource という DCOM 実装を開発した。このソースコードは The Open Group から入手可能であり、完全な文書も付属している。この文書によれば、COMsource のソースはWindows NT 4.0 のソースコードから直接持ってきたものであり、Windows NT Registry Service のソースコードもそれに含まれている。
WineのチームもDCOMを実装している。バイナリ互換性を確保する目的であり、DCOM をネットワーク上で使用するためではない。マイクロソフトのAPIを通してNDR(Network Data Representation)を実装するに留まっているが、可能な限り MSRPC と互換性を保とうとしている。
j-Interop は、Java上での MSRPC のオープンソース(LGPL)実装であり、DCOMサーバとやり取りするDCOMクライアントをJavaで作成することができる。
関連項目
- ActiveX
- Component Object Model (COM)
- 動的データ交換 (DDE)
- .NET Framework
- .NET Remoting
- Object Linking and Embedding (OLE)