DCOM に対して多くの敵意があるようで、その理由が知りたいです。まだ C++ を使用して Win32 SKD を作成している企業にとって、現在または将来の開発で DCOM を使用しない本当の理由はありますか? Windows の将来のバージョンではサポートされないのでしょうか? 壊れやすく、頻繁に機能しませんか? 他のテクノロジーに比べて実装が複雑すぎますか? どうしたんだ?
6 に答える
- セキュリティモデル。特に、コンピューターが同じドメインにない(またはドメインにまったくない)場合。
- Visual Basic(.NETではなくオリジナル)用にモデル化された自動インターフェイスは、廃止されており、他の言語からの使用には適していません。
C ++で開発し、制御されたネットワークにデプロイするだけの場合でも、それは良い選択かもしれません。
COM/DCOM"Catastrophic failure"
は、エラー メッセージの歴史の中で最も役に立たないエラー メッセージであるため、嫌いです。
DCOM は COM の分散バージョンであり、COM はそれ自体が非常に複雑であり、意図せず間違ったことをするのは非常に簡単です (例については、この最近の質問とそれに対する回答を参照してください)。DCOM を使用すると、自分を傷つける方法がさらに増えます。
それ以外は機能し、たとえば、インプロセス COM コンポーネントを別のプロセスでホストするための良い方法です。
クライアント サーバー アプリケーションを構築しようとしていて、ネットワーク境界 (インターネットなど) を越えて通信したい場合、ファイアウォールが原因で DCOM が問題になる可能性があります。
私は、DCOM を使用して配布された非常に成功したサーバー アプリケーションに取り組んでいました。COM+ サーバー アプリケーションを作成し、アプリケーション プロキシをエクスポートすることで、システムが複雑さのほとんどを処理できるようにしました。この場合、すべてのバージョンが同期されている限り、非常にうまく機能しました。
90 年代後半に DCOM を使用して大規模なシステムを実装しました。かなりうまく機能しましたが、いくつかの問題がありました。手始めに、通信に予測できないポート番号を使用します。スケーラブルではなく、DCOM よりも WCF を使用する方がはるかに優れています。
SOAP やその他の Web サービス技術に勢いが移ったと思います。その理由は次のとおりです。
- ファイアウォールの存在下でのシステムの展開が容易
- ベンダーロックインなし
私は DCOM を自分で使用したことがないので、その一般的な品質や適合性についてコメントすることはできません。