COM,DCOMからCOM+へ

1998/6/2 ニューオリンズにて


COM+とはなにか

COMは、拡張できるアーキテクチュアであるので、時代とともにその機能と能力を広げてきた。そして、それと伴に新しい名称が付与されている。COMは分散に対応した段階でDCOMと呼ばれた。DCOMにトランザクションを取り扱うための各種機能を与えるものがMTSであった。MTSは、DCOMのテクノロジーをラップする事により実現された。そして、COM+とは、DCOMとMTSの機能を統合し、さらに新しい機能を実現するものとして、WindowsNT5.0に搭載される予定のものである。Windows98にはDCOMが搭載されており、COM+の一部機能が搭載されていると言う事はない。しかし、WindowsNT5.0のCOM+が出荷後には、WindowsNT4.0やWindows98のためのCOM+が出荷される予定になっている。
COM+により新たに提供される事を要約すると、以下の3つの点にまとめる事ができる。COMやDCOMであり、それまでのものと完全な互換性を持ったものである。
1. DCOMとMTSの統合
2. IDLコンパイラが一新され、新しい情報を管理できるタイプライブラリになる
3. 新しい標準オブジェクトによるサービスの提供
COM+の機能は、98/6の段階では、2段階に別れて提供される予定になっている。はじめの段階の提供がWindowsNT5.0である。WindowsNT5.0は早ければ99年第一四半期に登場するかもしれない。

DCOMとMTSの統合

DCOMで提供されているプログラミング機能は、基本的なものであり、トランザクション処理を行うためには、いろいろな機能をユーザーが自身で開発する必要がある。それはそれで重要な事ではあるが、ソフトウェアの開発生産性を上げるためには、より高いレベルで機能を統合したものが望ましい。そうした背景からMTSには、本書で解説されているようなパッケージやトランザクション、トランザクションアトリビュート、より包括的なセキュリティモデルといった概念が導入された。しかし、プログラミングモデルはインプロセスサーバーに限定された。
COM+でこういったMTSが実現した概念をより効果的にプログラミングモデルとして取り込んでする。COM+は、すべてのサーバーの形態でMTSのAPIを使用できるようにし、また、アトリビュートと言う概念で、COMクラスのメタデータ、コンテキストの決定、インターフェースのインターセプトの管理を行う事ができるようになる。
このようなアトリビュートの管理は、COMエクスプローラー、記述型のインターフェース、他の専用ツールにより実現される。
こうした方法により、プログラミングモデルはより単純になる。つまりクライアントは、サーバーになるオブジェクトを生成(create)し、使い(use)、解放(release)することだけを明示する。サーバーは、処理をするだけである。その他の必要な事は、COM+がアトリビュートにより判断し処理を行う。このように単純化することでアプリケーション開発に必要な機能の抽象化が進み、使用するAPIを減らす事ができる。目的は、いろいろと苦労して行っていた煩雑なコーディングを「無くす」ことである。

サーバーをMTSのモデルで開発できるようにする

DCOMは、クライアントのコーディング方法は1つだけであったが、サーバーは実現する形態によりコーディング方法が異なると言う、複雑な点があった。これを解決するために、オブジェクトコンテキスト、Surrogateプロセス、スレッドプール、アクティビティ、JITアクティベーションの概念を導入しする。これらの概念はMTSで実現されていたものであり、MTSでのコンテキスト、ロール、アクティビティスレッド(ワーカースレッド)、スレッドプール、トランザクションの概念が、すべてのオブジェクトで利用できるようになる。
このDCOMとMTSの統合は、インターセプトにより実現され、複数のレジストリへの登録を不要にし、複数になっているsurrogateの実現方法を統合する。また、現行では複雑なリソースディスペンサーをより簡単に実現できるようにする。
管理のための様々な機構
DCOMには、開発するためには十分なツールが用意されて異だ、運用管理するための機構は、利用者に委ねられていた。
COM+では、以下のように様々な方法が提供される。
1. COMエクスプローラー
MMC(マイクロソフト マネジメント コンソール)に統合され、開発、設定、コンポーネントの運用への展開、モニタリングを行う事ができる。
2. 管理用SDK
管理者に対するインターフェースを開発できるようにするためのSDKである。
3. 自動コードダウンロード
DrawinやZAWをによりコンポーネントを自動的に配布できるようにする。
4. 自動的な登録システム
新しいタイプライブラリにより自己記述型になっているコンポーネントを自動的にレジストリに登録する。

トランザクションの概念の導入

DCOMにはトランザクションの概念が無かった。これはMTSで実現されていたが、これをすべてのCOMオブジェクトで利用できるようにする。この為に、新しいアトリビュートである、AutoComplete, AutoAbortが用意され、自動的なトランザクション処理が実現できるようになる。また、トランザクションバックアウトのために、OLEx,XA,LU6.2 Sync2がサポートされる。

セキュリティの概念の拡張


DCOMのセキュリティは、アプリケーションの努力によるセキュリティであった。これをMTSと同様にアトリビュートとして、Rolls(ロール)、Caller identity(呼び出し元の識別)、Channel(チャンネル)を用意し解決する。これによりロールごとにACLの設定ができる。この設定は、アプリケーション、クラス、インターフェース、メソド、インパーソネーション、チャンネル、セキュリティコールコンテキストに対して行う事ができる。
したがって、ロールは、スコープやアクセスモデルの複雑さ、IDispatchに含まれるメソドレベルの管理の困難さが、解決される。また、コンテキストをより高度にする事ができるので、セキュリティスタックの開示、呼び出し側のセキュリティコールコンテキストの提示が可能になる。セキュリティコンテキストには、すべての呼び出し側の識別情報と認証サービス/レベル、承認が含まれる。

コンポーネントのキュー


分散アプリケーションは、同期型だけで開発する事は困難である。常にサーバーが起動できなければならないが、それは保証できる事ではないからである。この問題を解決するために、アトリビュートにQueueが導入され、オブジェクト(プレーヤー)の生成と実行をトランザクションキューを経由して、遅延型でトランザクション処理ができるようにする。このトランザクションキューはMSMQにより実現されているものである。この際に、当然ではあるが、プレーヤーが利用できるパラメーターはINだけに限定され、IN/OUTやOUTパラメーターは使用できない。また、インターフェースポインターも(はじめのバージョンでは)パラメーターに使用できない。サーバーは起動され停止する処理となる。プレーヤーは、新しく提供されるイベントサービスにより起動する事もできる

イベントサービス

パブリッシャーよりもサブスクリプターが遅延した動作を、イベントデータベースにより実現する。


この時に、サブスクリプターが1つか複数かは、イベントサービスにより管理され、アプリケーションが意識する事はない。また、イベントは同期/非同期のいずれかでも実現できる。この時に、サブスクリプターは、OUT,IN/OUTパラメーターを使用する事はできない。
イベントのフィルターをパブリッシャー、サブスクリプターのいずれにも設定する事ができる。このようなイベントの配信は保証される。

ロードバランス

DCOMには、動的なロードバランスを行う機能が無かった。COM+には、これが用意される。この実現のために、Load BalancedとApplication Clusterのアトリビュートが用意される。クライアントからは、サーバーのロードバランスは意識されない。サーバーは、アプリケーションクラスターとして管理され、自動的なリプリケーション(複製の生成)なども実現できる。ただし、リファレンスカウンターの管理のために、CoCreateInstance毎に接続を管理すると言う単純な方法で行われる。

IMDB

MTSで高性能なデータベースアプリケーションを開発する際に、データベース処理のキャッシュが必要であるが、これをアプリケーションで実現する事は大きな負荷が伴っていた。この問題を解決するためにCOM+には、インプロセスのメモリ上にデータのキャッシュを実現するサービスを提供する。これがIMDB(インメモリーデーターベース)である。テーブルのロードは動的にも起動時にも行う事ができ、インデクスの生成は自動的に行われる。APIはADO/OLE DBの提供するシンプルなもの(IOpenRowset)である。また、Win64のメモリアクセスにも互換性が取られている。トランザクションのサポートも行われており、自動的なエンリストがサポートされ、DTCフェーズ0の機能、そして、洗練されたロック管理機構が実装される。管理にはCOMエクスプローラーを使用する事ができる。

Google
  Web www.calvadoshof.com