連載

スキルアップのための分散オブジェクト入門

第5回　分散オブジェクト技術としてのHORBとCOM＋

COM+に見る分散オブジェクトの特徴

　当初からプラットフォーム非依存の分散オブジェクト・アーキテクチャとして設計されたCORBAと異なり、COM+（用語解説2）は、最初はWindowsの複合ドキュメント間の連携手段（例えばWordドキュメントへのExcelスプレッドシートの埋め込みやリンク）であるOLE（Object Linking and Embedding：オーレと読む）としてスタートしました。その後、次々と進化を遂げて現在のCOM+に至っています。

　最初の大きな進化は、COM（Component Object Model）の登場です。ここでは、複合ドキュメント連携のアーキテクチャが、ソフトウェア・コンポーネント連携のアーキテクチャへと進化しました。誕生直後のCOMは、ローカル・マシン上のコンポーネント連携がサポートされていただけでしたが、まもなくRPC（リモート手続き呼び出し）機能を取り込んだDCOM（Distributed COM）によって、異なるマシン上のコンポーネント連携が実現しました。

　その後、DCOM上でトランザクション・サービスやセキュリティ機能を提供するMTS（Microsoft Transaction Server）が登場し、さらに、これらのランタイム環境を統合して、COM+が誕生しました（図3）。

用語解説2　 COM+（Component Object Model Plus）

マイクロソフトの分散コンポーネント・オブジェクト・モデル。バイナリ・レベルでのコンポーネント間の呼び出し規則、スレッド・モデル、オブジェクトの永続化や活性化、トランザクション、セキュリティ、メッセージ・キューなどのランタイム・サービスまでを包含しています。

図3 COM+登場の背景

　このようにCOM+は分散オブジェクト技術にとどまらず、高度なソフトウェア・コンポーネントを開発するためのサービス・スイートですが、本稿ではCOM+の分散オブジェクト技術としての側面にフォーカスして解説を行います。

■COM+の分散オブジェクト技術としての特徴

　まず最初にCOM+の分散オブジェクト技術としての特徴を簡単にまとめておきましょう。COM+も分散オブジェクトとしての側面で見ると、CORBAと非常によく似ていますので、以下では、CORBAと異なる点を中心に説明します。

●特定のプログラミング言語に依存しない
　COM+では、オブジェクト間の呼び出し規則をバイナリ・レベルで定めているため、この規則に従う限り、原理的にはプログラミング言語を選びません。現在、Visual C++、Visual Basic、Visual J++、Visual FoxPro、Delphi、PowerBuilder、VBA、VBScript、JScriptなどの言語がCOM+をサポートしています。JavaでCOM+のプログラミングができるというのに驚かれる方もいらっしゃるでしょう。

●オートメーションのサポート
　連載第2回にスタブとスケルトンの話をしました（COM+ではそれぞれプロキシとスタブと呼んでいますが……）。COM+でもCとC++の場合には、MIDL（Microsoft IDL）コンパイラが生成するプロキシとスタブが実行時にマーシャリング処理を行ってくれます。ところが、Visual BasicあるいはVBAのようなスクリプト言語の場合にはこの方法は使えません。その代わりに用意されているのがオートメーションと呼ばれる機能です。オートメーションを使用することで、実行時にインターフェイス情報を取得して動的にオブジェクトを呼び出すことが可能になります。

●コンポーネント・モデル
　再利用可能なソフトウェア部品であるコンポーネントは、単一のインターフェイスをサポートすることもありますが、多くの場合、複数のインターフェイスを含む、より大きな単位で作成します。COM+では、こうした複数のインターフェイスをサポートするコンポーネントを構成するために便利なIUnknownと呼ばれるインターフェイスが用意されています。

　以下では、これらの特徴をさらに詳しく解説していくことにします。

■IUnknownインターフェイスとCOM+オブジェクト

　COM+オブジェクトの最も際立った特徴は、すべてのインターフェイスがIUnknownインターフェイスを継承している点です。逆にいうと、IUnknownインターフェイスをサポートしていることが、COM+オブジェクトの必要条件になります。Visual BasicやJavaでプログラムを書く場合には、このインターフェイスはそれぞれのバーチャル・マシンが隠ぺいするため表面には現れませんが、COM+の仕組みを理解するうえで避けて通れないので、簡単に説明しておきます。

　IUnknownインターフェイスは、AddRef、Release、およびQueryInterfaceの3つのメソッドを含むだけの簡単なインターフェイスです。

■参照カウントとオブジェクトのライフサイクル

　このうち、AddRefとReleaseメソッドは、オブジェクトの参照カウントを増減させるためにクライアントが呼び出すメソッドです。COM+ではCORBAとは異なり、オブジェクトはクライアント主導で作成され、どのクライアントからも参照されなくなったところで自動的に削除されます。

　COM+オブジェクトを作成するために、クライアントはCoCreateInstanceExと呼ばれるメソッドを呼び出します。すると、SCM（用語解説3）と呼ばれるCOM+のサービスが、該当オブジェクトの実装を含むDLLまたはEXEファイルをメモリにロードします。

　クライアントはオブジェクトを使用し終えると、Releaseメソッドを呼び出します。これにより、サーバ側ではオブジェクトの参照カウントが1つ減少し、最終的に参照カウントがゼロになったところで、オブジェクトが削除される仕組みになっています。

用語解説3　SCM（Service Control Manager）

スカムと読みます。このサービスは、CoCreateInstanceExメソッドの裏で、インスタンス化対象のクラスを実装するEXEファイルまたはDLLファイルをWindowsレジストリから探し出し、それをメモリにロードします。リモート・マシンでオブジェクトをインスタンス化する場合には、ローカル・マシン上のSCMとリモート・マシン上のSCMが連携して同様の処理を行います。

図4 SCMの役割

TIPS2　分散ガーベッジ・コレクション

本文中で説明したように、COM+オブジェクトは自分を参照しているクライアントの数を監視し、参照カウントがゼロになったところで自らを削除します。これは、CORBAやEJBにはない、COM+の特徴です（ただし、RMI over IIOP以前のJRMP（Java Remote Method Protocol）を使用したJavaRMIでは、同様の分散ガーベッジ・コレクションが行われていました）。 　クライアントはオブジェクトを使用し終えるとIUnknownインターフェイスのReleaseメソッドを呼び出す約束なのですが、中にはこれを忘れてしまったり、Releaseを呼び出す前にクラッシュしてしまうケースもあります。そこで、COM+ではReleaseとともにpingメカニズムを併用して、参照カウントを管理します。つまり、クライアントは一定時間ごとにpingメッセージをサーバに送信し、自分が生きていることを通知します。そしてサーバ側では、一定のpingサイクルが経過してもメッセージを送信してこないクライアントを死んだものと判断して、参照カウントを減少させます。このpingメカニズムは、クライアントが増加してもネットワーク負荷が増大することがないように最適化されています。 　 サーバ側に常駐するようなアプリケーションのように、ガーベッジ・コレクションが必要のないケースもあります。この場合には、Releaseメソッドの送信やpingメカニズムを抑止することも可能です。

■QueryInterfaceによるインターフェイス間のナビゲーション

　QueryInterfaceは、コンポーネントの複数のインターフェイスの間をクライアントが渡り歩くためのメソッドです。クライアントが取得したいインターフェイスの識別子を引数として渡すと、そのインターフェイス・ポインタ（ターゲット・オブジェクトまたはプロキシへの参照）を返却してくれます。このメソッドにより、クライアントはコンポーネントのいずれか1つのインターフェイス・ポインタを取得することができれば、残りのすべてのインターフェイス・ポインタを取得することができます。さらに、あるコンポーネントが目的のインターフェイスをサポートしているかどうかを調べることもできます。

　例として、ICalculatorとIPrinterの2つのインターフェイスを実装するオブジェクトを考えてみましょう（図5）。CoCreateInstanceExメソッドでオブジェクトを作成すると、まずIUnknownのインターフェイス・ポインタがクライアントに返却されます。そこで、クライアントはIUnknownのQueryInterfaceメソッドを呼び出すことで、ICalculatorのインターフェイス・ポインタを取得することができますし、さらにICalculatorのQueryInterfaceメソッド*1を呼び出すことで、IPrinterのインターフェイス・ポインタも取得することができます。

*1：ICalculatorはIUnknownを継承していたことを思い出してください。ここでもちろん元のIUnknownのQueryInterfaceを使っても構いません

図5 すべてのCOM+オブジェクトはIUnknownインターフェイスを実装する

■インターフェイス定義の例

　リスト2はCOM+のインターフェイス定義の例です。IUnknownインターフェイスをきちんと継承していることがお分かりいただけますね。

リスト2　COM+のインターフェイス定義例

import "unknwn.idl"; [object, uuid(ECDD6310-5441-11d6-B656-00010386104F)] interface ICalculator : IUnknown {   HRESULT Sun([in] int a, [in] int b, [out, retval] int* retval);   HRESULT Multiply([in] int a, [in] int b, [out, retval] int* retval); };};

■オートメーション

　オートメーションを使用することで、実行時にオブジェクトのインターフェイス情報を取得して、動的にオブジェクトを呼び出すことができます。ほかの分散オブジェクト技術に慣れている方には、「動的起動」という呼び方をした方が分かりやすいかもしれません。オートメーションという名前は、普通はユーザーが直接操作するWordのようなアプリケーションの機能を、外部のクライアント・プログラムからこのインターフェイスを通じて操作することで、ユーザーの介入なしに処理を自動化できるところからきています。

　オートメーションは、通常IDispatchと呼ばれるインターフェイスをオブジェクトが実装することによって実現されています。IDispatchインターフェイスには、オブジェクトのインターフェイス情報を取得するためのGetTypeInfoメソッドや、汎用的なメソッド呼び出しのためのinvokeメソッドなどが用意されています。これらのメソッドを使用して、クライアントはインターフェイスに関する事前の知識なしに、オブジェクトの任意のメソッドを呼び出すことが可能になります。

用語解説4　デュアル・インターフェイス

オブジェクトがIDispatchインターフェイスしか実装していない場合（この場合にも、もちろんIUnknownインターフェイスは実装しています）、クライアントはオートメーション経由でしかオブジェクトを呼び出すことができなくなってしまいます。そこで通常は、IDispatchインターフェイスと、ICalculatorのようなカスタム・インターフェイスの両方を実装するという手法を取り、通常のCOM+クライアントからでもオブジェクトにアクセスできるようにしておきます。このようなインターフェイスをデュアル・インターフェイスと呼んでいます。

用語解説5　タイプライブラリ

タイプライブラリは、インターフェイス定義情報を実行時にプログラムに提供するためのバイナリ・ファイルです。マイクロソフトは、新たなプログラミング言語が登場するたびにMIDLコンパイラにコード生成機能を追加する代わりに、すべてのプログラミング言語から共通にアクセスすることのできる統一フォーマットとして、タイプライブラリを導入しました。タイプライブラリは、MIDLコンパイラによって生成されます。オートメーション・クライアントは、タイプライブラリがなくてもIDispatchインターフェイスのGetTypeInfoメソッドなどを通じてサーバから直接インターフェイス情報を取得できるため、オートメーションを実現するためにタイプライブラリは必須ではありませんが、タイプライブラリを用いることにより、簡単にしかも効率的にオートメーションを実現することが可能になります。

TIPS3　 COM+と.NET

.NETは、アプリケーションの開発環境から実行環境までを含む包括的なフレームワークです。COM+の後継というよりは、まったく新たなフレームワークと考えてください。もちろん、.NETの設計においては随所でCOM+の経験が生かされています。.NETのオブジェクト間の通信には、DCOMではなく、Remotingと呼ばれるプロトコルが使用されます。Remotingでは、バイナリ・エンコーディングとSOAPのいずれかを選択できます。一般的に、性能が重視される密結合システム内ではバイナリ・エンコーディングが、疎結合システム間やほかのシステムとの相互運用性が要求される場合にはSOAPを使用します。 　.NETのオブジェクトにはIUnknownインターフェイスは必要ありませんし、オブジェクトを呼び出すためにタイプライブラリやレジストリの情報も必要としません。 .NETアプリケーションと従来のCOM+アプリケーションを連携させるためには、ラッパーを経由します。.NETクライアントからCOM+サーバにアクセスする場合にはRCW（Runtime Callable Wrapper）を、逆にCOM+クライアントから.NETサーバにアクセスする場合にはCCW（COM Callable Wrapper）を使用することで、双方向の相互運用性を実現します。

　次回最終回は「分散オブジェクト技術とWebサービス」と題して、分散オブジェクトとWebサービスが共存する将来のコンピューティングモデルについて解説します。

2/2

第5回 分散オブジェクト技術としてのHORBとCOM＋
	Page1 HORBの特徴 開発手順からHORBを知る
	Page2 COM+に見る分散オブジェクトの特徴

INDEX
スキルアップのための分散オブジェクト入門
	第1回　分散オブジェクト技術が必要なわけ（2002/3/19)
	第2回　分散オブジェクトのしくみを理解する（2002/4/4）
	第3回　開発手順からCORBAを理解する（2002/4/25）
	第4回　開発手順から分かるEJBとJavaRMI（2002/6/25）
	第5回　分散オブジェクト技術としてのHORBとCOM+（2002/8/21）
	第6回　現実モデルはWebサービスとの共存（2002/10/4）

筆者プロフィール

小野沢 博文（おのざわ ひろふみ） 現在、日本アイオナテクノロジーズ株式会社にて分散オブジェクト・システムの技術コンサルタントを務める。 1991年まで富士通株式会社にてプラズマ実験データ処理システムの開発やシステム運用に携わった後、1996年以前は日本DECにてCORBA準拠のObjectBrokerおよびDCEの開発を担当。また、MIA、NMF SPIRITなどの標準化活動にも参加する。 1997年1月から1999年8月までは、TCSIにて分散オブジェクト技術を適用したテレコム向けの大規模ネットワーク管理システムの開発に携わる。 [著書一覧] 『CORBA完全解説 基礎編』（ソフト・リサーチ・センター）、『CORBA完全解説 応用編』（ソフト・リサーチ・センター）、『分散オブジェクト指向技術CORBA』（ソフト・リサーチ・センター）、『イントラネットのためのオブジェクト指向データベース技術』（共著、ソフト・リサーチ・センター）、『分散コンピューティング環境 DCE』 （監著、共立出版）、『トランザクション処理システム入門』（共訳、日経BP）

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）