JP4528742B2 - 分散コンポーネントアプリケーションでの待機メソッド呼び出し方法 - Google Patents

Description

本発明は、分散コンポーネントをベースとするコンピュータソフトウェアアプリケーションに関し、より詳細には、かかるアプリケーションでの待機メソッド呼び出しに関する。

多くの情報処理アプリケーションでは、分散ネットワーク内のホストまたはサーバコンピュータ上で稼動しているサーバアプリケーションは、多数のユーザによって操作される、ネットワークの端末またはワークステーション上で稼動しているクライアントアプリケーションのために処理サービスを提供している。このようなサーバアプリケーションの一般的な例としては、大学でのクラス登録、旅行予約、銀行での振込みや他のサービス、およびビジネスでの販売を処理するソフトウェアがある。これらの例では、サーバアプリケーションによって提供される処理サービスは、クラススケジュール、ホテル予約、勘定残高、注文品発送、支払い、または在庫品のデータベースを、それぞれのステーションで個々のユーザによってとられたアクションを受けて更新している。これは、クライアント／サーバコンピューティングとも呼ばれている。

「分散オブジェクト」として知られるクライアント／サーバコンピューティングの形態では、サーバアプリケーションは、マイクロソフトコンポーネントオブジェクトモデル（ＣＯＭ ： Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）や分散コンポーネントオブジェクトモデル（ＤＣＯＭ ： Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）、ＩＢＭシステムオブジェクトモデル（ＳＯＭ ： Ｓｙｓｔｅｍ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）、Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐの共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ ： Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）などの、オブジェクト指向プログラミング（ＯＯＰ ： Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ｐｒｏｇｒａｍｍｉｎｇ）モデルに準拠するコンポーネントの集まりとして開発されている。オブジェクト指向プログラミングには、一般的に、プログラミングの容易性、拡張容易性、コードの再利用、および異なるベンダや（ある種のオブジェクト指向プログラミングモデルでは）異種プログラミング言語にまたがるソフトウェアの統合化、といった利点がある。

オブジェクト指向プログラミングでは、プログラムはオブジェクトクラスの集まりとして書かれ、各クラスは実世界をモデル化し、あるいはアイテムの属性を表すデータを、アイテムの作用を表すメソッド（例えば、プログラムの関数やプロシージャ）と結合することによってアイテムを抽象化している。具体的に説明すると、オブジェクトは、クラスと呼ばれるプログラマ定義の型のインスタンスであり、これはデータカプセル化、多形性および継承という特性を示している。

データカプセル化とは、データ（オブジェクトの属性とも呼ばれる）を、そのデータに作用を及ぼすメソッド（オブジェクトのメンバ関数とも呼ばれる）と結合して単一のソフトウェアコンポーネント（つまり、オブジェクト）にし、オブジェクトがその内部構成、構造およびオペレーションを隠し、１つまたは２つ以上のインタフェースを通してオブジェクトを利用するクライアントプログラムにだけその作用が見えるようにすることである。オブジェクトのインタフェースは、そのオブジェクトの意味的に関連をもつメソッドの集まりである。言い換えれば、クライアントプログラムは、オブジェクトのデータに直接にアクセスするのではなく、オブジェクトのインタフェースからメソッドを呼び出してデータの操作を行わなければならない。

多形性とは、２つの類似オブジェクトを共通インタフェースから表示できる（つまり、オブジェクトとやりとりできる）能力のことであり、これによって、２つのオブジェクトを区別しないで済むことになる。継承とは、オブジェクトの異なるクラスを基底クラスから派生することであり、そこでは派生クラスは基底クラスの属性と特性を継承している。

「分散オブジェクト」によるクライアント／サーバコンピューティングでは、ユーザのコンピュータ側のクライアントプログラムは、「リアルタイム」または同期処理メカニズムを使用して、サーバコンピュータ側に常駐するサーバアプリケーションのオブジェクトでリモートプロシージャコール（ＲＰＣ ： ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌ）などの、メソッドを遠隔で呼び出しているのが代表的である。代表的なリモートプロシージャコールでは、オペレーティングシステムのオブジェクトサービスは、サーバアプリケーションオブジェクトをインタフェース定義言語で記述したものをコンパイルし、クライアントコンピュータ側のサーバアプリケーションオブジェクトのためにローカル「プロキシ」を生成している。クライアントソフトウェアは、通常のローカルプロシージャコールをプロキシに対して直接に出すことによって、リモートサーバアプリケーションオブジェクトのメソッドを呼び出している。他方、プロキシの方はＲＰＣサービスを利用して、プロシージャコールをリモートサーバコンピュータ側の実際のサーバアプリケーションオブジェクトに伝達している。ＲＰＣサービスは、コールパラメータの値をマーシャル（ｍａｒｓｈａｌ）してネットワークメッセージに変換し、そのメッセージをネットワークプロトコルでサーバコンピュータに送信している。サーバコンピュータ側では、ＲＰＣサービスは、コールパラメータをアンマーシャル（ｕｎｍａｒｓｈａｌ）し、正しいサーバアプリケーションオブジェクトメソッドへのコールを出している。ＲＰＣサービスは、サーバアプリケーションオブジェクトメソッドからの戻り値もマーシャリングとアンマーシャリングを行って、ネットワークメッセージでクライアントプログラムに送り返している。

従って、ＲＰＣサービスは、ネットワークコミュニケーションがもつすべての複雑さを、「シーンの背後」で効果的に処理し、クライアントプログラムがローカルプロシージャコールを行うのと同じようにリモートメソッドを呼び出すようにしている。ローカルプロシージャコールと同じように、クライアントプログラムの実行は、ＲＰＣメソッド呼び出しの間、そのメソッドが完了して、送り返されるまで一時中止（「ブロッキング」とも呼ばれる）される。このようにして、クライアントプログラムとサーバアプリケーションオブジェクト間の実行の流れを同期化している。

多くのアプリケーションに適しているとはいえ、ＲＰＣのようなリアルタイムメソッド呼び出しモデルは、可用性、ネットワーク伝送コスト、プライオリティの欠如、オブジェクトの寿命、参照局所性に関していくつかの制約があるために、他のアプリケーションの要求を十分に満足していない。

可用性に関しては、リアルタイムメソッド呼び出しモデルでは、クライアントプログラムがオブジェクトのメソッドのいずれかへのコールを出す時点で、サーバアプリケーションオブジェクトが利用可能になっていることが要求される。利用可能になっていなければ、リアルタイムメソッド呼び出しは行うことができない。しかし、実際には、サーバアプリケーションオブジェクトは、ネットワーク障害が原因で、あるいは、サーバコンピュータの過負荷処理が原因で利用できない場合がある。ある場合には、サーバコンピュータは一定の期間の間オフラインにされることもあれば（例えば、アップグレードやメインテナンスために）、一日のある時間だけオンラインになっていることもある。さらに、いずれかのサーバアプリケーションオブジェクトが「リアルタイム」で使用できない場合には、作業のどの部分も（利用可能なサーバアプリケーションオブジェクトによる作業も含む）完了できないことになる。この問題は、多数のノード（つまり、ネットワーク上のコンピュータ）が係わりもつ複雑なオペレーションの場合にはさらに深刻である。例えば、各々が時間にすると約９０％利用可能になっている、別々のノードに置かれた４つの独立オブジェクトへのアクセスを要求しているプロセスは、実際に利用可能になっているのは時間にすると約６６％だけである（つまり、９０％^４ ＝ ６５．６１％）。

さらに、いくつかのクライアントコンピュータは、たまにしかネットワークに接続されていないために、リアルタイムメソッド呼び出しを出すことができる時間が限られている。このようにたまにしか接続されていないクライアントコンピュータの良い例として、モバイルユーザのラップトップ型、ノートブック型およびハンドヘルド型コンピュータがあるが、現在では、これらのコンピュータは推定で新規コンピュータ購入の５０％以上を占めている。

リアルタイムメソッド呼び出しモデルに要求される可用性は、サーバアプリケーションの対話型ユーザによるピーク要求量を処理できるだけの十分な容量を持つようにサーバコンピュータを構成しなければならないことも意味している。その結果として、代表的なシステムは、大部分の時間の間利用されないままになっているが、他の時間には利用過剰になっている（負荷が予想を越えるとき）サーバコンピュータを含む構成になっている。

以上のような理由から、リアルタイムメソッド呼び出しモデルは、可用性が制限され、モバイルユーザと大多数のノードが存在し、対話型ユーザの負荷に大幅なばらつきのあるようなコンピューティング環境には不向きである。

ネットワーク伝送コストに関しては、各リアルタイムメソッド呼び出しをＲＰＣで行うためには、ラウンドトリップネットワークコミュニケーションが必要になるため、コールパラメータのマーシャリングとアンマーシャリングの処理時間、ネットワークプロトコルスタックでの処理、および伝送時間といったように、ネットワーク伝送コストが大きくなっている。さらに、クライアントは、有用な仕事を実行するためにサーバアプリケーションコンポーネントの多数のメソッドを呼び出す必要があるため、ネットワーク伝送コストが倍になる場合がある。特に、最新のオブジェクト指向設計手法では、各コールでのパラメータ数が相対的に少ないのに、多数のプロシージャコールが行われる傾向がある。このようなオブジェクトの代表例では、クライアントは、まず、オペレーションをセットアップするためにいくつかの「プロパティセット」メソッドをコールし、そのあとオペレーションを処理するためにメソッドを呼び出す設計になっている。その結果、ネットワークオーバヘッドに大量の時間が消費される可能性がある。これらのネットワーク伝送コストは、リアルタイムメソッド呼び出しを、ある種のアプリケーションに適しないものにしている。

プライオリティに関しては、代表的なリアルタイムメソッド呼び出しモデルに準拠するコールは、プライオリティという考え方とは関係なく、「先着順サービス （ｆｉｒｓｔ−ｃｏｍｅ， ｆｉｒｓｔ−ｓｅｒｖｅｄ）」方式で到着した時点で処理されている。

オブジェクト寿命に関しては、サーバアプリケーションオブジェクトは、リアルタイムメソッド呼び出しモデルでは寿命が長くなる傾向がある。代表的な分散オブジェクトクライアント／サーバコンピューティングでは、サーバアプリケーションオブジェクトは、クライアントによる作成時からオブジェクトが解放されるまでサーバコンピュータに存在している。オブジェクトは、クライアントがオブジェクトのメソッドを呼び出すのを待つだけでも大くの時間を消費し、メソッドから結果が戻されてからクライアントによる次のメソッド呼び出しまでに大量のネットワーク伝送コストを消費している。他方、オブジェクトはサーバコンピュータリソースを消費し、この中には、メモリと実行環境の処理オーバヘッドが含まれている。サーバアプリケーションオブジェクトが、実際に「目覚め （ｗａｋｅ ｕｐ）」、「休眠 （ｓｌｅｅｐ）」するのは、メソッドコールごとに少なくとも一回である。このサーバアプリケーションオブジェクト「占有時間」は、サーバオブジェクトの高速サイクリングの妨げとなっており、サーバアプリケーションのスケーラビリティを制限している。

参照局所性に関しては、コンピュータシステムの多くの部分（例えば、プロセッサキャッシュや仮想メモリワーキングセット）は、パフォーマンス向上を達成するために参照局所性に頼っている。局所性の高いアプリケーション、例えば、ローカルに利用可能なデータの使用を通してストレートに実行されるオブジェクトまたはアプリケーションコードは、従って、パフォーマンス向上をもたらす参照パターンをもっている。これとは対照的に、オブジェクトが、ＲＰＣのようなリアルタイムメソッド呼び出しを使用する複数のサーバコンピュータに分散されているアプリケーションは、参照局所性が劣っている。例えば、サーバオブジェクトは最初のリアルタイムメソッドコールによって作成され、その寿命の大半は後続のリアルタイムメソッドコールを待つことに消費されることがよくある。各メソッドコールを処理した後、サーバオブジェクトは、プロセッサキャッシュから移動されるのが代表的であるため、コール間のシステムの仮想メモリワーキングセットから外されることがある。従って、リアルタイムメソッド呼び出しはアプリケーションのトランザクション処理量を制限している。

リアルタイムＲＰＣメソッド呼び出しの可用性の制約のいくつかを解決する、「分散オブジェクト」に代わるものとして、「メッセージ指向ミドルウェア （ＭＯＭ ： ｍｅｓｓａｇｅ ｏｒｉｅｎｔｅｄ ｍｉｄｄｌｅｗａｒｅ）」とも呼ばれている形態のクライアント／サーバコンピューティングがある。ＭＯＭでは、クライアントアプリケーションは、メッセージをメッセージキューに送ることによってリモートサーバアプリケーションと通信している。サーバアプリケーションは、クライアントアプリケーションよりも遅い時期に実行されることがあるため、そのメッセージキューからメッセージを取り出して、処理している。サーバアプリケーションは、メッセージを同一または別のメッセージキューに送信することによって処理結果をクライアントアプリケーションに戻し、クライアントアプリケーションが処理できるようにしている。この待機メッセージング（ｑｕｅｕｅｄ ｍｅｓｓａｇｉｎｇ）には、クライアントアプリケーションとサーバアプリケーションが同時に利用可能になっている必要がなく、同じ寿命である必要はないという利点がある。

しかし、従来のＭＯＭプロダクトには、いくつかの制約もある。１つの制約は、クライアントアプリケーションとサーバアプリケーションが、メッセージを独自にリニアストリームとしてフォーマットしていることである。具体的に説明すると、クライアントアプリケーションとサーバアプリケーションは、このストリームからのデータのマーシャリングとアンマーシャリングを独自に行わなければならない。このマーシャリングサポートは、待機メッセージングの機構には用意されていない。

従来のＭＯＭのもう１つの制約は、クライアントアプリケーションとサーバアプリケーションが、ベンダ固有のメッセージキューイングアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して待機メッセージング機構と通信していることである。言い換えれば、クライアントアプリケーションとサーバアプリケーションは、メッセージキューイングＡＰＩへの明示的コールを通してメッセージキューにメッセージを送っている。これは、クライアント／サーバアプリケーションの開発者が学ばなければならない、他のＡＰＩセットになっている。例えば、ＭＱＩ（ＭＱ Ｓｅｒｉｅｓ ＡＰＩを意味する）は、ＩＢＭ社のＭＱＳｅｒｉｅｓメッセージ指向ミドルウェアプロダクトである。その他のＭＯＭプロダクトベンダ、例えば、Ｍｉｃｒｏｓｏｆｔ社（Ｍｉｃｒｏｓｏｆｔ Ｍｅｓｓａｇｅ Ｑｕｅｕｅ（ＭＳＭＱ））、Ｃｏｖｉａ社（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｔｅｇｒａｔｏｒ）、Ｐｅｅｒｌｏｇｉｃ社（ＰＩＰＥＳ）、Ｈｏｒｉｚｏｎ Ｓｔｒａｔｅｇｉｅｓ社（Ｍｅｓｓａｇｅ Ｅｘｐｒｅｓｓ）、およびＳｙｓｔｅｍ Ｓｔｒａｔｅｇｉｅｓ社（ｅｚＢｒｉｄｇｅ）は、異なるメッセージキューイングＡＰＩを提供している。

ＭＯＭプロダクトのカストマ（情報テクノロジ （ＩＴ） 企業など）は、さまざまな理由で、ベンダ提供メッセージキューイングＡＰＩの上に別のＡＰＩ層を構築している。その理由の１つは、ＩＴ企業はメッセージキューイングＡＰＩのどの部分を使用し、ＡＰＩをどのように使用するかをアプリケーション開発者に判断させることを望んでいないからである。第２の理由は、ベンダのメッセージキューイングＡＰＩが余りに高価で、複雑であり、アプリケーション開発者に提供するオプションが多すぎるからである。そのために、ＩＴ企業は、アプリケーション開発者用のＡＰＩを単純化する試みとして独自のＡＰＩ層を構築している。その結果として、開発者の大部分は、ベンダのメッセージキューイングＡＰＩとＩＴ提供のＡＰＩの両方を学習せざるを得なくしている。第３の理由は、ＩＴ企業はアプリケーションを、ある特定のベンダのメッセージキューイングＡＰＩまたはＭＯＭプロダクトに依存させることを望んでおらず、将来他のベンダにスイッチする柔軟性を残しておきたいことを望んでいるからである。このことは、しばしばＩＴ企業がＭＯＭプロダクトの機能を十分に活用する妨げとなっている。この現象は、ＭＯＭプロダクトを使用するアプリケーションの実現を遅らせ、ときには、ＩＴ企業がＭＯＭプロダクトの新開発機能を活用することを困難にしている。

従来のＭＯＭプロダクトのもう１つの制約は、構成によってはパフォーマンスが最適状態に及ばないことである。具体的には、アプリケーションおよびアプリケーションオブジェクトは、特に同じプロセス内にあるときは、処理時間コストを極めて低くして、メソッドコールでローカルに通信することができる。アプリケーションとアプリケーションオブジェクトがメッセージキューイングＡＰＩを通して通信するためには、アプリケーションまたはオブジェクトが同一プロセスといったように、同一または類似の環境内にある場合であっても、キューマネージャを通した処理が必要になる。

本発明は、オブジェクトのクライアントが、メッセージキューイングＡＰＩを使用することなく、オブジェクトモデルの通常のコールセマンティックス（ｃａｌｌ ｓｅｍａｎｔｉｃｓ）を使用して待機方式（ｑｕｅｕｅｄ ｂａｓｉｓ）でメソッド呼び出しをオブジェクトが出し、および受けるようにしている。具体的に説明すると、クライアントはオブジェクトモデルの通常のセマンティックスを使用して、オブジェクトを作成し、オブジェクトのメソッドをコールし、オブジェクトを解放する。オブジェクトフレームワークまたは実行環境は、メソッド呼び出しを自動的にキューに置いて待機させ、その後の適当な時刻に、この待機メソッド呼び出し（ｑｕｅｕｅｄ ｍｅｔｈｏｄ ｉｎｖｏｃａｔｉｏｎ）をオブジェクトに対して出すようにするサービスを提供している。その間に、クライアントは、呼び出されたメソッドとは非同期に実行を継続することが許されている。オブジェクトの方は、待機メソッド呼び出しが通常のコールセマンティックスごとにそのインタフェースに対して出され、そのあと、プロセスは、通常のコールセマンティックスを使用してメソッドからの値を返している。従って、アプリケーション開発者は、従来のメッセージ指向ミドルウェアによる待機処理のために、メッセージキューイングＡＰＩを使用するようにクライアントとオブジェクトをプログラムする必要がなくなるので、このようなＡＰＩを学習しないで済むことになる。

本発明のある側面によれば、オブジェクトは、リアルタイムと待機の両方のメソッド呼び出しを共通インタフェースから受信することができる。リアルタイムメソッド呼び出しは、インタフェースへのローカルプロシージャコールまたはリモートプロシージャコールを通してオブジェクトに渡される。待機メソッド呼び出しは、待機メソッド呼び出し機能内のキューに置かれた後、この機能からのローカルプロシージャコールを通してオブジェクトのインタフェースに渡される。リアルタイムメソッド呼び出しと待機メソッド呼び出しの区別は、オブジェクトからは見えないようになっている。従って、オブジェクトは、修正しなくても、リアルタイム同期環境でも、待機非同期環境でも実行させることができる。オブジェクトは、比喩的表現を使用すると、その環境がリアルタイム方式であるか、キュー方式であるかには「無関心」であり、そのインタフェース上のメソッドがどのような呼び出し方をされるかについては「寛大」である。

本発明の別の側面によれば、オブジェクトフレームワークまたは環境は、待機メソッド呼び出しに対して自動マーシャリングもサポートしている。クライアントは、システムに用意されたプロキシとスタブまたはラッパ （ｗｒａｐｐｅｒ） を通してオブジェクトに対する待機メソッド呼び出しを出すが、プロキシとスタブまたはラッパは、インタフェース定義言語でオブジェクトのインタフェースを記述したものからコンパイルされ、待機メッセージとの間でコールパラメータと関連データを正しくマーシャリングする機能を実装している。

本発明のさらに別の側面によれば、メソッド呼び出しキューイング機能は、クライアント側のメソッド呼び出しレコーダと、クライアントとオブジェクトの間でやりとりするオブジェクト側のメソッド呼び出しプレーヤとを含んでいる。メソッド呼び出しレコーダは、可能な限り２つ以上のメソッド呼び出しをクライアントから受信し、バッチでメソッド呼び出しプレーヤに転送される。例えば、レコーダは、トランザクションの一部としてオブジェクトでクライアントによって行われた、複数の待機メソッド呼び出しを収集し、そのトランザクションがコミットされるまでメソッド呼び出しを転送しないようにすることができる。メソッド呼び出しプレーヤは、待機メソッド呼び出しをメソッド呼び出しキューから順番に取り出していき、オブジェクトに対するメソッド呼び出しを、おそらくは、そのオブジェクトが係わりを持つトランザクションの一部として出すことになる。

本発明のさらに別の側面によれば、待機メソッド呼び出しをサポートするオブジェクトは、そのメソッドが入力パラメータだけをもつため、アプリケーション固有情報を戻さないとする制約に適合している。この場合、待機メソッド呼び出しは、クライアントからオブジェクトへ一方向通信として出すことができるので、クライアントはメソッド呼び出しの結果を、リアルタイム実行でも、同期実行でも待たないで済むようになっている。オブジェクトは、待機メソッド呼び出しの処理結果を、クライアントからの入力パラメータで指定された結果オブジェクトに対するリアルタイムまたは待機メソッド呼び出しを出すことによって提供することができる。

本発明のその他の特徴および利点については、添付図面を参照して以下に記載されている図示実施形態の詳細説明の中で明らかにする。

本発明は、待機コンポーネントメソッド呼び出しのための方法およびシステムを目的としている。以下に説明する一実施形態では、本発明は、”Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ Ｓｅｒｖｅｒ ５．０”という名称で、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ（米国ワシントン州Ｒｅｄｍｏｎｄ）によって販売されているオペレーティングシステムの、”ＣＯＭ＋”という名称のオブジェクトサービスコンポーネントに組み込まれている。要約して説明すると、このソフトウェアはスケーラブルで、ハイパフォーマンスなネットワークおよびコンピュータオペレーティングシステムであり、分散クライアント／サーバコンピューティングをサポートすると共に、マイクロソフトコンポーネントオブジェクトモデル（ＣＯＭ）に準拠するコンポーネントアプリケーションに対してオブジェクト実行環境を提供している。ＣＯＭ＋コンポーネントは、以前のオブジェクトシステムから引き継いだオブジェクトサービスを取り入れており、その中には、マイクロソフトコンポーネントオブジェクトモデル、マイクロソフトオブジェクトリンキング・エンベッディング（ＯＬＥ ： Ｍｉｃｒｏｓｏｆｔ Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ）、マイクロソフト分散コンポーネントオブジェクトモデル（ＤＣＯＭ）、およびマイクロソフトトランザクションサーバ（ＭＴＳ ： Ｍｉｃｒｏｓｏｆｔ Ｔｒａｎｓａｃｔｉｏｎ Ｓｅｒｖｅｒ）が含まれている。

（動作環境の例）
以下では、本発明を実装するのに適しているコンピューティング環境の概要を、図１を参照して要約して説明することにする。以下では、本発明は、コンピュータ上で稼動するコンピュータプログラムのコンピュータ実行可能命令を広い意味でとらえて説明されているが、この分野の当業者ならば理解されるように、本発明は、他のプログラムモジュールと組み合わせて実装することも可能である。一般的に、プログラムモジュールとしては、ルーチン、プログラム、コンポーネント、データ構造などがあり、これらは特定のタスクを実行し、あるいは特定の抽象データ型を実装している。さらに、この分野の当業者ならば理解されるように、本発明は他のコンピュータシステム構成でも実施可能であり、そのようなものとしては、ハンドヘルド型デバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータなどがある。本発明の図示実施形態は、分散コンピューティング環境でも実施されており、そこで、タスクは、通信ネットワークを通してリンクされたリモート処理デバイスによって実行されている。しかし、本発明のいくつかの実施形態は、スタンドアロンコンピュータで実施することが可能になっている。分散コンピューティング環境では、プログラムモジュールはローカルとリモートの両方のメモリストレージデバイスに常駐させておくことができる。

図１に、本発明を実装した例示的なシステムは、従来のコンピュータ２０（パーソナルコンピュータ、ラップトップ、セットトップ、サーバ、メインフレーム、および他の様々なコンピュータ）を含む。コンピュータ２０は、処理装置２１、システムメモリ２２、およびシステムメモリを含むさまざまなシステムコンポーネントを処理装置２１に相互接続するシステムバス２３を含む。演算ユニットは、様々な市販されている利用可能なプロセッサのいずれかである。Ｉｎｔｅｌ ｘ８６，ＰｅｎｔｉｕｍおよびＩｎｔｅｌ社やＣｙｒｉｘ社、ＡＭＤ社、Ｎｅｘｇｅｎ社を含む他の互換性のあるプロセッサ、Ｄｉｇｉｔａｌ社からＡｌｐｈａ、ＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｙ社からＭＩＰＳ、ＮＥＣ社、ＩＤＴ社、Ｓｉｅｍｅｎｓ社など、ＩＢＭ社およびＭｏｔｏｒｏｌａ社からＰｏｗｅｒ ＰＣなどが含まれる。

システムバスは、メモリバスまたはメモリコントローラ、周辺バス、および、例えばＰＣＩ、ＶＥＳＡ、Ｍｉｃｒｏｃｈａｎｎｅｌ、ＩＳＡおよびＥＩＳＡ等のバス構成を使用したローカルバスを含むいくつかの種類のいずれかのバス構造を含むことができる。システムメモリは、リードオンリーメモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。スタートアップ中など、コンピュータ２０内の要素間の情報転送を手助けする基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、ＲＯＭ２４に記憶される。

コンピュータ２０はさらに、ハードディスクドライブ２７、例えばリムーバブルディスク２９に書込みまたは読取りを実施する磁気ディスクドライブ２８、および例えばＣＤ−ＲＯＭディスク３１を読んだり、あるいはその他の光学的媒体から読取りまたは書込みを実施する光ディスクドライブ３０を含む。ハードディスクドライブ２７、磁気ディスクドライブ２８および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３および光ディスクドライブインタフェース３４によってシステムバス２３に接続される。これらのドライブおよびその関連するコンピュータが読取り可能な媒体は、データ、データ構造、コンピュータ実行可能命令などの不揮発性の記憶をパーソナルコンピュータ２０に提供する。以上に述べたコンピュータが読取り可能な媒体の記述は、ハードディスク、リムーバブル磁気ディスクおよびＣＤについてのものだが、さらに、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ等の、コンピュータが読取り可能な他の種類の媒体を含めることができる。また、典型的な実行環境で使用することができる。

いくつかのプログラムモジュールは、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール１３７およびプログラムデータ３８を含む、ドライブおよびＲＡＭ２５に記憶することができる。その他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナ等がある。これらおよびその他の入力装置は、システムバスに結合されたシリアルポートインタフェース４６を介して処理装置２１に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースによって接続することもできる。モニタ４７またはその他の種類のディスプレイ装置が、ビデオアダプタ４８等のインタフェースを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは一般に、スピーカやプリンタ等の、その他の周辺出力装置（図示せず）を含む。

コンピュータ２０は、リモートコンピュータ４９等の１つまたは複数のリモートコンピュータへの論理接続を使用したネットワーク環境で動作することができる。リモートコンピュータ４９は、サーバ、ルータ、ピア装置、またはその他の一般的なネットワークノードであり、図１には記憶装置５０のみを示したが、一般にはコンピュータ２０に関して説明した要素の全てまたは多くを含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１およびワイドエリアネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットに普通に見られる。

ＬＡＮネットワーキング環境で使用されるとき、コンピュータ２０は、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用されるとき、コンピュータ２０は一般に、モデム５４、またはインターネット等のワイドエリアネットワーク５２上で通信を確立するその他の手段を含む（例えば、ＬＡＮ５１およびゲートウェイまたはプロキシサーバー５５を経由して）。モデム５４は、内部モデムでもまたは外部モデムでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。ネットワーク化された環境では、コンピュータ２０に関して図示したプログラムモジュールまたはそれらの部分を、リモートメモリ記憶装置に記憶することができる。図示のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立するその他の手段を使用することもできることを理解されたい。

コンピュータプログラミング分野の当業者が行うプラクティスに従って、以下では、本発明は、別段の断りがない限り、コンピュータ２０によって実施される動作とオペレーションの記号表現に関連付けながら説明されている。このような動作とオペレーションは、コンピュータで実行される（ｃｏｍｐｕｔｅｒ−ｅｘｅｃｕｔｅｄ）とも呼ばれている。当然に理解されるように、動作およびオペレーションの記号表現には、データビットを表す電気信号を処理ユニット２１が操作し、その結果として電気信号の表現を変換（ｔｒａｎｓｆｏｒｍａｔｉｏｎ）または変形（ｒｅｄｕｃｔｉｏｎ）すること、メモリシステム（システムメモリ２２、ハードドライブ２７、フロッピディスク２９、およびＣＤ−ＲＯＭ３１を含む）内のメモリロケーションにデータビットを保存しておくことによって、コンピュータシステムのオペレーションを再構成するか、さもなければ変更することのほかに、他の信号処理も含まれている。データビットが保存されているメモリロケーションは、データビットに対応する特定の電気的、磁気的、または光学的特性をもつ物理ロケーションである。

（コンポーネントアプリケーション実行環境）
次に、図２を参照して説明すると、上述したように、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ ５．０オペレーティングシステムのＣＯＭ＋コンポーネントは、サーバコンピュータ８４側にランタイムオブジェクト実行環境を生成するためのランタイムサービスまたはシステムサービスを提供し、この実行環境からオブジェクト８６に対し待機メソッド呼び出しが自動的に提供されるようにしている（以下、待機コンポーネントと呼ぶ）。ＣＯＭ＋コンポーネントは、ダイナミックリンクライブラリ（”ＤＬＬ” ： ｄｙｎａｍｉｃ ｌｉｎｋ ｌｉｂｒａｒｙ）として実装されている（ＤＬＬは周知の実行可能ファイルフォーマットであり、実行可能コードを動的にまたはランタイムにリンクして、アプリケーションプログラムのプロセスに組み入れることを可能にしている）。ＣＯＭ＋ ＤＬＬは、コンポーネントアプリケーションオブジェクトのホストの働きをするアプリケーションサーバプロセス（例えば、”ＡＳＰ”９０）に直接にロードされ、これらのプロセスのバックグランドで透過的に実行される。

図示のＡＳＰ９０は、待機コンポーネント８６を含めて、コンポーネントアプリケーションオブジェクトの実行をホストするシステムプロセスである。各ＡＳＰ９０は、「ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎ」と呼ばれるコレクション（以前のＭｉｃｒｏｓｏｆｔ Ｔｒａｎｓａｃｔｉｏｎ Ｓｅｒｖｅｒのオブジェクト実行環境では「パッケージ」とも呼ばれていた）にグループ化された複数のコンポーネントオブジェクトをホストすることができる。また、マルチスレッド、マルチタスキングオペレーティングシステム（例えば、図示実施例におけるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ）のもとで、サーバコンピュータ８４上で、複数のＡＳＰ９０を実行させることも可能である。各ＡＳＰ９０は、サーバアプリケーションオブジェクトのために別々のトラスト境界 （ｔｒｕｓｔ ｂｏｕｎｄａｒｙ） と障害隔離領域 （ｆａｕｌｔ ｉｓｏｌａｔｉｏｎ ｄｏｍａｉｎ） を提供している。言い換えれば、別々のＡＳＰで実行されているとき、あるサーバアプリケーションオブジェクトで障害が起こると、そのＡＳＰは終了するのが一般であるが、別のＡＳＰ内のサーバアプリケーションオブジェクトはその障害に影響されないようになっている。図示の実施形態では、コンポーネントアプリケーションオブジェクトはＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎとしてグループ化され、”ＣＯＭ＋ Ｅｘｐｌｏｒｅｒ”と呼ばれる管理ユーティリティを使用して１つのＡＳＰ９０内で一緒に実行されるようになっている。このユーティリティは、コンポーネントアプリケーションオブジェクトと関連付けられた属性値を管理するためのグラフィカルユーザインタフェースを提供しているが、この中には、オブジェクトをＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎにグループ化することも含まれている。

図２に示す代表的な設備では、実行環境８０はサーバコンピュータ８４側に置かれており、このサーバコンピュータ（例えば、上述したコンピュータ２０）は、実行環境８０でコンポーネントアプリケーションオブジェクトにアクセスする多数のクライアントコンピュータ９２を収容している、分散コンピュータネットワーク９１内に接続されている。別の方法として、実行環境８０をシングルコンピュータ上に置いておき、そのコンピュータにも置かれているクライアントプロセスによってアクセスされるコンポーネントアプリケーションオブジェクトのホストとなることも可能である。

（コンポーネントアプリケーションオブジェクトの概要）
図２に示すように、コンピュータ８４は、コンポーネントアプリケーションオブジェクト群を収容しているＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎとして開発されたコンポーネントアプリケーションを実行する。例えば、ＡＳＰ９０の実行環境８６でホストされるコンポーネントアプリケーションオブジェクト（待機コンポーネント８６など）は、大学の登録アプリケーションでのクラス登録やオンラインセールスアプリケーションでの注文を管理するためのコードなどのように、クライアント／サーバアプリケーションのビジネスロジックを実装することが可能である。代表例として、各コンポーネントアプリケーションは、複数のコンポーネントを含み、各コンポーネントは、そのアプリケーションの作業の一部に対してプログラムコードを収めている。

図３を参照して説明すると、図示実行環境８０（図２）内のコンポーネントアプリケーションオブジェクトは、マイクロソフトコンポーネントオブジェクトモデル（ＣＯＭ）仕様に準拠し（つまり、「ＣＯＭオブジェクト」１００として実装されている）、上述したようにＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ Ｓｅｒｖｅｒ ５．０オペレーティングシステムのＣＯＭ＋サービスを使用して実行されているが、別の方法として、他のオブジェクト標準（Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ ＧｒｏｕｐのＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔ）の仕様、およびＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ， Ｉｎｃ．のＪａｖａ Ｂｅａｎｓを含む）に準拠して実装し、別のオペレーティングシステムのオブジェクトサービスを使用して実行させることも可能である。ＣＯＭ仕様は、オブジェクトとそのインタフェースに関するバイナリ標準を規定し、ソフトウェアコンポーネントをアプリケーションに統合化することを容易にしている（ＣＯＭおよびＯＬＥの詳しい解説は、Ｋｒａｉｇ Ｂｒｏｃｋｓｃｈｍｉｄｔ著「Ｉｎｓｉｄｅ ＯＬＥ・第２版」、Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ， Ｒｅｄｍｏｎｄ， Ｗａｓｈｉｎｇｔｏｎ （１９９５） に記載されている）。

ＣＯＭによれば、ＣＯＭオブジェクト１００は、インスタンスデータ構造１０２、仮想関数テーブル１０４、およびメソッドまたはメンバ関数１０６−１０８によってコンピュータ８４（図２）内で表されている。インスタンスデータ構造１０２は、仮想関数テーブル１０４を指すポインタ１１０とデータ１１２（データメンバとも、オブジェクトのプロパティとも呼ばれている）を収めている。ポインタは、メモリ内のデータのアドレスを保持しているデータ値である。仮想関数テーブル１０４は、メソッド１０６−１１８のエントリ１１６−１１８をもっている。エントリ１１６−１１８の各々は、対応するメソッドを実装しているコードへのレファレンス（参照）を収めている。

ポインタ１１０、仮想関数テーブル１０４、およびメソッド１０６−１０８は、ＣＯＭオブジェクト１００のインタフェースを実装している。規則により、ＣＯＭオブジェクトのインタフェースは、図２に待機コンポーネント８６について示されているようにプラグインジャックとしてグラフィカルに示されている。また、インタフェースは、従来から、大文字の ”Ｉ” から始まる名前が付けられている。ＣＯＭによれば、ＣＯＭオブジェクト１００は、複数のインタフェースを含むことが可能であり、これらのインタフェースは、１つまたは２つ以上の仮想関数テーブルで実現されている。インタフェースのメソッドは、
”ＩＩｎｔｅｒｆａｃｅＮａｍｅ：：ＦｕｎｃｔｉｏｎＮａｍｅ”
で表されている。

ＣＯＭオブジェクト１００の仮想関数テーブル１０４とメソッド１０６−１０８は、コンピュータ２０（図１）にダイナミックリンクライブラリファイル（ファイル名のエクステンション ”．ｄｌｌ” で示されている）としてストアされているオブジェクトサーバプログラム１２０（以下、「オブジェクトサーバＤＬＬ」と呼ぶ）によって提供される。ＣＯＭによれば、オブジェクトサーバＤＬＬ１２０は、これがサポートするクラスの仮想関数テーブル１０４とメソッド１０６−１０８のためのコードを含み、そのクラスのオブジェクトのためのインスタンスデータ構造１０２を生成するクラスファクトリ１２２も含んでいる。

他のオブジェクトとプログラム（ＣＯＭオブジェクト１００の「クライアント」と呼ぶ）は、ＣＯＭオブジェクトのインタフェースからメソッドを呼び出すことによってＣＯＭオブジェクトの機能にアクセスする。しかし、最初に、ＣＯＭオブジェクトは、インスタンス生成されなければならず（つまり、クラスファクトリにオブジェクトのインスタンスデータ構造１０２を生成させることによって）、また、クライアントはＣＯＭオブジェクトを指すインタフェースポインタを取得しなければならない。

ＣＯＭオブジェクト１００が例示される前に、オブジェクトが最初にコンピュータ２０にインストールされる。代表例として、このインストールは、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎに含まれる関連オブジェクト群をインストールすることにより行われる。ＣＯＭオブジェクト１００は、オブジェクトを提供するオブジェクトサーバＤＬＬファイル（１つまたは複数）１２０を、コンピュータ２０がアクセスできるデータストレージ（代表例として、図１に示すハードドライブ２７）に保存することによってインストールされ、ＣＯＭオブジェクトのＣＯＭ属性（例えば、クラス識別子、オブジェクトサーバＤＬＬファイル１２０のパスと名前など）をシステムレジストリ、カタログ、または類似のコンフィギュレーションデータベースに登録することによって行われる。

クライアントは、システム提供サービスおよび標準のセットを使用して、ＣＯＭオブジェクトのインスタンスを生成を要求し、システム定義コンポーネントインタフェース群は、ＣＯＭオブジェクトのクラスとインタフェースに割り当てられたクラスとインタフェース識別子に基づいている。具体的には、サービスは、ＣＯＭ＋ライブラリに用意されているアプリケーションプログラミングインタフェース （ＡＰＩ） 関数としてクライアントプログラムに利用可能になっている。なお、ＣＯＭ＋ライブラリは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ Ｓｅｒｖｅｒ ５．０オペレーティングシステムのコンポーネントであり、”ＯＬＥ３２．ＤＬＬ” と名付けられたファイルに入っている。また、ＣＯＭ＋では、ＣＯＭオブジェクトのクラスは、クラス識別子 （“ＣＬＳＩＤ”） と一意的に関連付けられ、そのＣＬＳＩＤによって「レジストリ」と呼ばれるシステムコンフィギュレーションデータベースに登録されている。ＣＯＭオブジェクトクラスのレジストリエントリは、クラスのＣＬＳＩＤを、クラスを提供する実行可能ファイル（例えば、クラスのインスタンスを生成するクラスファクトリを収めているＤＬＬファイル）を識別する情報と関連付けている。クラス識別子は、グローバルにユニークな１２８ビット識別子 （“ＧＵＩＤ”） であり、これは “ＣｏＣｒｅａｔｅＧＵＩＤ” と名付けたＣＯＭ＋サービス（またはグローバルにユニークな識別子を作るために使用される、他の複数のＡＰＩとユーティリティのいずれか）を使用して、プログラマが作成し、それぞれのクラスに割り当てられる。さらに、コンポーネントのインタフェースがインタフェース識別子 （“ＩＩＤ”） と関連付けられている。

具体的には、ＣＯＭ＋ライブラリは、ＡＰＩ関数を提供する。割り当てられたＣＬＳＩＤおよび必要とするインタフェースのＩＩＤを使用してコンポーネントの生成を要求するためにクライアントプログラムによってコールすることができる、例えば、“ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” および “ＣｏＧｅｔＯｂｊｅｃｔ（）” である。クライアントのインスタンス生成要求に応答して、”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩは、レジストリ内の要求されたＣＬＳＩＤのレジストリエントリを調べ、そのクラスの実行可能ファイルを特定する。次に、”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩ関数は、そのクラスの実行可能ファイルをロードし、実行可能ファイル内のクラスファクトリを使用してＣＯＭオブジェクト１００のインスタンスを作成する。最後に、”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩ関数は、要求されたインタフェースのポインタをクライアントプログラムに戻してくる。”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩ関数は、システムレジストリの中でＣＯＭオブジェクト１００に対して登録された属性に応じて、実行可能ファイルをクライアントプログラムのプロセスにロードすることも、サーバプロセスの中にロードすることも可能である（つまり、同じコンピュータに置かれていても、分散コンピュータネットワーク内のリモートコンピュータに置かれていても構わない）。この場合、サーバプロセスはローカルでも、リモートでも構わない。他方、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩは、ＣＯＭ Ｍｏｎｉｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅを使用して、サーバオブジェクトクラスを特定しているストリングを解析し、モニカ （ｍｏｎｉｋｅｒ） オブジェクトを作成する。このモニカオブジェクトは、サーバオブジェクトクラスのインスタンスを作成するために使用される。

ＣＯＭオブジェクト１００のクライアントが、ＣＯＭオブジェクトの最初のインタフェースポインタを取得した後、クライアントはコンポーネントの他の必要とするインタフェースのポインタを、必要とするインタフェースに関連付けられたインタフェース識別子を使用して取得することができる。ＣＯＭ＋は、”ＩＵｎｋｎｏｗｎ” インタフェースを含めて、ＣＯＭオブジェクトによって一般にサポートされているいくつかの標準インタフェースを定義している。このインタフェースは、”ＱｕｅｒｙＩｎｔｅｒｆａｃｅ（）”と名付けたメソッドを含んでいる。”ＱｕｅｒｙＩｎｔｅｒｆａｃｅ（）” 関数は、インタフェース識別子を引数としてコールすることができ、そのインタフェース識別子に関連付けられたインタフェースを指すポインタを戻してくる。各ＣＯＭオブジェクトの ”ＩＵｎｋｎｏｗｎ” インタフェースも、ＣＯＭオブジェクトへのレファレンス（例えば、インタフェースポインタ）を保持しているクライアントプログラムのカウントをとるためのメソッド、”ＡｄｄＲｅｆ（） と ”Ｒｅｌｅａｓｅ（）” を含んでいる。規則により、”ＩＵｎｋｎｏｗｎ” インタフェースのメソッドは、ＣＯＭオブジェクト上の各インタフェースの一部として含まれている。従って、ＣＯＭオブジェクト１００のインタフェースを指すものとしてクライアントが取得するインタフェースポインタは、ＱｕｅｒｙＩｎｔｅｒｆａｃｅ関数をコールするために使用できる。

（トランザクション処理の概要）
図２に戻って説明すると、ＣＯＭ＋コンポーネントは、図示実行環境８０におけるコンポーネントアプリケーションオブジェクトのための自動トランザクション処理も実装している。自動トランザクション処理は、１９９７年１０月２８日に出願され、１９９９年３月３０日に特許交付された米国特許第５，８９０，１６１号、「Ａｕｔｏｍａｔｉｃ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｏｆ Ｃｏｍｐｏｎｅｎｔ−Ｂａｓｅｄ Ｓｅｒｖｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ」Ｈｅｌｌａｎｄ他に詳しく説明されている（以下、「自動トランザクション特許出願」と呼ぶ）。要約して説明すると、自動トランザクション処理は、実行環境８０におけるコンポーネントアプリケーションオブジェクトの処理動作を自動的に調整し、一般にトランザクションと呼ばれている、単一の分割不能作業単位として効力をもつようにオペレーションの各部分を形成している。

実行環境８０におけるトランザクションは、トランザクションマネージャ１２８によって管理される。トランザクションマネージャ１２８は、データベースやファイルシステムなどの、複数の管理対象トランザクションリソースが係わっているトランザクションを調整するシステムサービスである。トランザクションマネージャ１２８は、あるトランザクションに関係するすべての処理作業（例えばデータベースの更新）が、ＡＣＩＤプロパティ（アトミック性（Ａｔｏｍｉｃｉｔｙ）、一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）、隔離（Ｉｓｏｌａｔｉｏｎ）、持続性（Ｄｕｒａｂｉｌｉｔｙ））に従って行われることを保証する。これは、周知の２フェーズコミットプロトコルを使用し、障害（例えば、コンピュータまたはネットワークのハードウェアまたはソフトウェア障害や、リソースマネージャまたはアプリケーションの誤った振る舞いが原因で起こるエラー）、競合状態（例えば、あるリソースマネージャがアボートを出している間にコミットを開始するトランザクション）、あるいは利用可能性（リソースマネージャはトランザクションを準備しているが、リターンすることがない）に関係なく、行われる。図示のトランザクションマネージャ１２８は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ ６．５の一部としてリリースされたマイクロソフト分散トランザクションコーディネータ（ＭＳＤＴＣ ： Ｍｉｃｒｏｓｏｆｔ Ｄｉｓｔｒｉｂｕｔｅｄ Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｏｒｄｉｎａｔｏｒ）である。トランザクション処理に関するバックグランド情報の詳細は、特に、Ｊｉｍ Ｇｒａｙ、Ａｎｄｒｅａｓ Ｒｅｕｔｅｒ共著「Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｃｏｎｃｅｐｔｓ ａｎｄ Ｔｅｃｈｎｉｑｕｅｓ」、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ， １９９３に記載されている。

（待機コンポーネントランタイムアーキテクチャ）
ここでも図２に示すように、待機コンポーネントランタイムアーキテクチャ１３０（以下、「ＱＣアーキテクチャ」と呼ぶ）は、通常のＣＯＭコールセマンティックスを使用して、待機メソッド呼び出しをサポートしている。具体的に説明すると、クライアントコンピュータ９２側のプロセス１３４内のクライアント１３２は、処理中のＣＯＭオブジェクトとリアルタイムで同期してやりとりするための通常のＣＯＭ規則を使用して、待機コンポーネント８６のインタフェース８７からメソッドを呼び出す。この中には、例えば、”ＣｏＧｅｔＯｂｊｅｃｔ（）”または”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）”コールなどでオブジェクトを作成すること、例えば、”ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩコールや”ＱｕｅｒｙＩｎｔｅｒｆａｃｅ（）”コールでインタフェース識別子（ＩＩＤ） を指定して、インタフェースポインタを取得すること、その仮想関数テーブルまたはディスパッチインタフェース（動的バインディングの場合）を通してオブジェクトへのコールを出すこと、最後に、例えば、オブジェクトの”Ｒｅｌｅａｓｅ（）” メソッドをコールすることによってオブジェクトを解放することが含まれる。（本発明のいくつかの実装形態では、ここに図示のＱＣアーキテクチャ１３０におけるように、クライアントは、リアルタイムメソッド呼び出しの場合とは異なるオブジェクト作成メカニズムを、待機メソッド呼び出しに対して使用することができる（つまり、以下で説明する “ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩとキューモニカ）が、その場合でも、共通コールセマンティックスを使用してオブジェクトのメソッドを呼び出すようになっている。）他方、待機コンポーネント８６は、ローカルメソッドコールの場合と同じように、そのメソッドがその仮想関数テーブルまたはディスパッチインタフェースを通して呼び出されるようになっている。言い換えれば、クライアント１３２と待機コンポーネント８６は、いずれかのメッセージキューイングＡＰＩを使用するように書かれていなくても、待機コンポーネントのメソッドの待機メソッド呼び出しを出したり、受け取ったりすることができる。

待機コンポーネント８６でのクライアントのメソッド呼び出しは、クライアントとオブジェクトとがやりとりするクライアント側１４０に記録され、後刻にプレイバックされ、このやりとりのサーバ側１４２の待機コンポーネント８６に対して出される。図示のＱＣアーキテクチャ１３０は、待機コンポーネント８６でのクライアントのメソッド呼び出しをすべて記録するが、メソッド呼び出しをプレイバックするのは、クライアント１３２が待機コンポーネント８６の使用を完了してからである（つまり、クライアントが待機コンポーネントを解放した後である）。さらに、クライアント１３２があるトランザクションに関与している場合、メソッド呼び出しは、そのトランザクションが正常完了に到達するまでプレイバックされない。

図示のＱＣアーキテクチャ１３０は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ ５．０オペレーティングシステムのＣＯＭ＋コンポーネントに実装されている。ＣＯＭ＋コンポーネントは、コンピュータシステム２０上で実行されるＣＯＭオブジェクトに種々のランタイムオブジェクトサービスを提供している。ランタイムサービスは、レコーダ１５０、リスナ１５２およびプレーヤ１５４を提供し、これらはクライアント１３２による待機メソッド呼び出しを、通常のコールセマンティックスを通して待機コンポーネント８６で実行する。レコーダ１５０は、待機コンポーネントのプロキシの働きをして、コールパラメータおよびメッセージの中の関連データとともに、クライアントのメソッド呼び出しのマーシャリングを行い、さらに、メッセージキューイングＡＰＩ（”Ｍｉｃｒｏｓｏｆｔ Ｍｅｓｓａｇｅ Ｑｕｅｕｅ” または ”ＭＳＭＱ” など）を使用して、そのメッセージを待機コンポーネント８６と関連付けられているメソッド呼び出しメッセージキュー１５８に入れる。（ＭＳＭＱの詳細は、「Ｍｉｃｒｏｓｏｆｔ Ｄｅｖｅｌｏｐｅｒ Ｎｅｔｗｏｒｋ （ＭＳＤＮ） Ｌｉｂｒａｒｙ Ｅｄｉｔｉｏｎ」Ｊｕｌｙ １９９８、ＳＤＫ Ｄｏｃｕｍｅｎｔａｔｉｏｎ、Ｐｌａｔｆｏｒｍ ＳＤＫ、Ｎｅｔｗｏｒｋｉｎｇ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｅｒｖｉｃｅｓ、Ｍｉｃｒｏｓｏｆｔ Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｓｅｒｖｅｒ （ＭＳＭＱ） に記載されている。）リスナ１５２は、メッセージがキュー１５８に到着するのを待ち、メッセージがプレーヤ１５４に到着するとメッセージをディスパッチする。プレーヤ１５４は、メッセージからのメソッド呼び出しをアンマーシャリングし、待機コンポーネント８６に対してメソッド呼び出しを出す。

図示のＱＣアーキテクチャ１３０における上述した各部分について、以下詳しく説明する。

（待機コンポーネント）
図示のＱＣアーキテクチャ１３０における待機コンポーネント８６は、上述し、図３に示す構造をもつＣＯＭオブジェクトである。待機コンポーネント８６は、属性（”ＱＵＥＵＥＡＢＬＥ”属性）をコンポーネントのインタフェースと関連付けることによって、待機メソッド呼び出しをサポートするものとして特定される。コンポーネントの開発者は、インタフェース属性マクロ（つまり、”ＱＵＥＵＥＡＢＬＥ” という語）を、インタフェース記述言語でコンポーネントのクラスを記述しているインタフェースセクションに追加することによって、ＱＵＥＵＥＡＢＬＥ属性をコンポーネントのインタフェースに割り当てる。別の方法として、上述した ”ＣＯＭ＋ Ｅｘｐｌｏｒｅｒ” には、オブジェクトに関連付けられた属性を、図示の実行環境８０でセットするためのグラフィカルコントロールがオブジェクトプロパティシートダイアログに用意されているので、これを使用してＱＵＥＵＥＡＢＬＥ属性をセットすることもできる。本発明のいくつかの実施形態では、ＱＵＥＵＥＡＢＬＥ属性は、カタログ１６５、オペレーティングシステムレジストリ、またはオペレーティングシステムや特定アプリケーションソフトウェアに関連する他のコンフィギュレーションデータベースに保存しておくことができる。

待機コンポーネント８６がパッケージされているＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎと関連付けられた属性もいくつかある。”Ｑｕｅｕｅｄ Ａｐｐ” 属性は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのオブジェクトを待機メソッド呼び出しを通して呼び出せるかどうかを示している。”Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎにリスナ１５２（図２）のような、キューリスナを始動させるかどうかを示している。また、”Ｑｕｅｕｅ ＢＬＯＢ” 属性は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎに関連するキュー群のＭＳＭＱ名（グローバルにユニークな識別子 （ＧＵＩＤ） 形式の名前）を収めている。（”ＢＬＯＢ” は”Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ” を表す頭字語である。）図示のアーキテクチャ１３０では、”Ｑｕｅｕｅ Ａｐｐ” 属性と ”Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性はブール代数フラグとして保存され、これは「オン」か「オフ」のどちらかにセットされる。”Ｑｕｅｕｅ ＢＬＯＢ” 属性は、５つの異なるキューのＭＳＭＱ名をストアしている。”Ｑｕｅｕｅ Ａｐｐ” 属性と “Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性は、”Ｑｕｅｕｅ Ａｐｐ” 属性と “Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性をＣＯＭ＋Ａｐｐｌｉｃａｔｉｏｎのプロパティシートでセットするためのチェックボックスコントロールが用意されている、ＣＯＭ＋ Ｅｘｐｌｏｒｅｒユーティリティを使用すると、アプリケーションインテグレータが表示し、指定することができる。”Ｑｕｅｕｅ Ａｐｐ” 属性と “Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性が「オン」にセットされると、これを受けてこのユーティリティは “Ｑｕｅｕｅ ＢＬＯＢ” 属性を生成する。

ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎが初めて作成されるとき、”Ｑｕｅｕｅ Ａｐｐ” 属性と “Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性はオフにセットされ、”Ｑｕｅｕｅ ＢＬＯＢ” 属性はヌルになっている。”Ｑｕｅｕｅ Ａｐｐ” 属性がオンにされると（例えば、ＣＯＭ＋ Ｅｘｐｌｏｒｅｒでチェックボックスコントロールを選択することにより）、ＣＯＭ＋ ＥｘｐｌｏｒｅｒはＣＯＭ＋ランタイムサービスの中のＡＰＩ関数を初期化し、ＣＯＭ＋ ＡｐｐｌｉｃａｔｉｏｎのためのＭＳＭＱキュー群を作成し、そのＭＳＭＱ名を “Ｑｕｅｕｅ ＢＬＯＢ” 属性にストアする。さらに、”Ｑｕｅｕｅ Ａｐｐ” 属性と “Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性は共にオンにされる。その後、アプリケーションインテグレータは、ＣＯＭ＋ Ｅｘｐｌｏｒｅｒでこれらの属性のどちらかのチェックボックスを選択解除して属性をオフにすることができる。このことは、待機コンポーネントとなることができるオブジェクトを含んでいる場合であっても、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎにリアルタイムメソッド呼び出しだけを使用させることを意味する。

図示のＱＣアーキテクチャ１３０では、待機コンポーネントのインタフェースは、開発者によって “ＱＵＥＵＥＡＢＬＥ” 属性のマークが直接に付けられる。ＣＯＭオブジェクトは、少なくとも１つのインタフェースに“ＱＵＥＵＥＡＢＬＥ” のマークが付けられていれば、キュー可能なコンポーネントであるとみなされる。”Ｑｕｅｕｅｄ Ａｐｐ” と指定されたＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎに置かれていれば、そのオブジェクトは待機コンポーネントとみなされる。しかし、本発明の代替実施形態では、コンポーネント自体に“ＱＵＥＵＥＡＢＬＥ” 属性のマークを付けることができる。マークされたコンポーネントのインタフェースは、そのメソッドが［ｉｎ］ パラメータだけをもっていれば、いずれもＱＵＥＵＥＡＢＬＥとみなされる。

（待機コンポーネントのアクティベーション）
上述したように、クライアント１３２は、リアルタイムメソッド呼び出しでも使用されている通常のＣＯＭコールセマンティックスを使用して待機コンポーネント８６を作成する。具体的には、図示ＱＣアーキテクチャ１３０のクライアントは、ＣＯＭの標準インスタンス生成ＡＰＩである、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩ（またはＶｉｓｕａｌ ＢａｓｉｃまたはＶｉｓｕａｌ Ｊａｖａプログラミング言語のセマンティックスに準拠する同等の “ＧｅｔＯｂｊｅｃｔ” ＡＰＩ）へのコールで待機コンポーネント８６を作成する。クライアントは、生成しようとする待機コンポーネントが、待機メソッド呼び出しで使用されることを、”ｑｕｅｕｅ：／ｎｅｗ：” の後に、待機コンポーネントのプログラムＩＤまたはストリング形式のグローバルにユニークな識別子（ＧＵＩＤ） を続けたものを、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩコールの “ｄｉｓｐｌａｙｎａｍｅ” パラメータとして指定することによって規定する。これを受けて、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩはこのストリングを“ｎｅｗ” モニカと”ｑｕｅｕｅ” モニカに変換し、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩは待機コンポーネントとこれらモニカとバインドさせる。ｎｅｗモニカは、”ＣｏＧｅｔＯｂｊｅｃｔ（）” ＡＰＩと類似した処理を実行して、サーバオブジェクトのインスタンスを作成する。ｑｕｅｕｅモニカは、クライアントが待機コンポーネントで待機メソッド呼び出しを使用できるように、図４に示すレコーダ構造をセットアップする処理を実行する。

代替実現形態では、クライアントは、待機コンポーネントが該当属性（つまり、そのインタフェースまたはクラスに関連付けられたＱＵＥＵＥＡＢＬＥ属性）をもっていれば、インスタンス生成要求での待機メソッド呼び出しを明示的に指定しなくても、待機コンポーネント８６を生成することができる。クライアントは、”ＣｏＧｅｔＯｂｊｅｃｔ（）”または “ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（）” ＡＰＩを通して待機コンポーネントインスタンスの作成を要求するだけでよく、そうすれば、これらの関数がその属性に基づいて、オブジェクトを待機コンポーネントとして作成する。

オブジェクトインスタンス生成コールの例は、図７のプログラムリスティング１５９に示されている。

（レコーダ）
図４を参照して具体的に説明すると、図示ＱＣアーキテクチャ１３０のレコーダ１５０は、ＣＯＭ＋ ＤＬＬに用意されているＣＯＭオブジェクトである。レコーダＤＬＬは、”ｄ：？Ｐｒｏｇｒａｍ Ｆｉｌｅｓ？Ｍｉｃｒｏｓｏｆｔ？ＣＯＭ＋” のようなセットアッププログラムによって、インストール時に、コンポーネント２０のＣＯＭ＋関連ディレクトリに入れられる。このセットアップは、レコーダＤＬＬに自己登録もさせる。この中には、レコーダ１５０を特定する構成情報（クラス識別子、ＤＬＬパス名、属性など）をカタログや他のコンフィギュレーションデータベースにストアすることも含まれている。

図示ＱＣアーキテクチャでは、プロキシオブジェクト１６０は、プロキシマネージャの働きをするレコーダ１５０から構成されている。このレコーダは１つまたは複数のインタフェースプロキシ１６６と１６７を管理しているが、これらのプロキシは、クライアントプロセス１３４で待機コンポーネント８６のプロキシとなるように待機コンポーネント８６のインタフェース８７の実装を提供し、待機コンポーネント８６でのクライアント１３２のメソッド呼び出しをプロキシインタフェースへの直接メソッドコールとして受信する。インタフェースプロキシ１６６−１６７は、Ｍｉｃｒｏｓｏｆｔ ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャに従って生成されるか（つまり、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ （ＭＩＤＬ） による待機コンポーネント８６の記述）、あるいはＭｉｃｒｏｓｏｆｔ Ａｕｔｏｍａｔｉｏｎ Ｔｙｐｅ Ｌｉｂｒａｒｙのマーシャラ（Ｍａｒｓｈａｌｅｒ）に従って生成される。（Ｍｉｃｒｏｓｏｆｔ ＣＯＭ ＲＰＣの詳細は、Ｂｒｏｃｋｓｃｈｍｉｄｔ著「Ｉｎｓｉｄｅ ＯＬＥ第２版」、２７７−３３８ （Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ １９９５） に記載されている。）

さらに具体的に説明すると、プロキシマネージャの働きをするレコーダ１５０は “ＩＵｎｋｎｏｗｎ” インタフェース１６２を実装している。コンポーネントアプリケーションオブジェクトの概要の個所で上述したように、クライアント１３２は、ＩＵｎｋｎｏｗｎインタフェース１６２の “ＱｕｅｒｙＩｎｔｅｒｆａｃｅ（）” メソッドへのコールの中で、インタフェースのインタフェース識別子 （ＩＩＤ） を指定することによってインタフェースポインタを要求する。指定されたＩＩＤが、カタログ１６５（図２）にリストされている “ｉｍｍｕｔａｂｌｅ ＩＩＤ ｓｅｔ” の一部であることを条件として、レコーダ１５０は、インタフェースプロキシ（１６６−１６７）（”ｆａｃｅｌｅｔ” とも呼ばれる）をロードし、集約する。インタフェースプロキシは、そのＩＩＤがクライアントの要求の中で指定されている、それぞれの待機コンポーネントインタフェースのために、プロキシインタフェース１６８−１６９を実装するための、標準マーシャリングアーキテクチャのＭＩＤＬコンパイラによって生成されている。プロキシインタフェース１６８−１６９は、待機メソッド呼び出しを受信するように最終的にインスタンス生成された待機コンポーネントのインタフェースと一致している。

レコーダ１５０は、 “ＩＲｐｃＣｈａｎｎｅｌＢｕｆｆｅｒ” インタフェース１７０および “ＩＯｂｊｅｃｔＣｏｎｔｒｏｌ” インタフェース１７２も実装している。ＩＯｂｊｅｃｔＣｏｎｔｒｏｌインタフェース１７２は、Ｍｉｃｒｏｓｏｆｔ Ｔｒａｎｓａｃｔｉｏｎ Ｓｅｒｖｅｒ （ＭＴＳ） に従って定義され、ＭＴＳのＪｕｓｔ−Ｉｎ−Ｔｉｍｅ Ａｃｔｉｖａｔｉｏｎ機能（この機能はＣＯＭ＋に組み込まれている）に従って、オブジェクトデアクティベーションの通知を受信するためにレコーダ１５０によって使用されるインタフェースである。ＩＲｐｃＣｈａｎｎｅｌＢｕｆｆｅｒインタフェースは、ＣＯＭ ＲＰＣ標準マーシャリングアーキテクチャに定義されているインタフェースである。

インタフェースプロキシ１６６−１６７は、クライアントプロセス１３４のメモリからの該当コールパラメータと関連データを含んでいる、クライアントのメソッド呼び出しをマーシャリングして、バッファに入れるためにＭＩＤＬコンパイラによって生成される。Ｍｉｃｒｏｓｏｆｔ ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャによれば、インタフェースプロキシ１６６−１６７は、“ＩＲｐｃＣｈａｎｎｅｌＢｕｆｆｅｒ” インタフェース１７０（これは標準マーシャリングアーキテクチャに定義されているＣＯＭインタフェースである）を使用して、バッファを待機コンポーネントのＡＳＰ９０に転送している。しかし、リアルタイムＲＰＣでメソッド呼び出しを転送する代わりに、レコーダ１５０の“ＩＲｐｃＣｈａｎｎｅｌＢｕｆｆｅｒ” インタフェース１７０の実装では、待機コンポーネント８６でのクライアントのメソッド呼び出し（ＩＵｎｋｎｏｗｎインタフェースのメソッドへの呼び出しを除く）のすべてを、１つの連続したバッファに記録している。レコーダは、これらのＩＵｋｎｏｗｎメソッドをローカルに実装しているので、このようなメソッド呼び出しはバッファに記録しない。

クライアントが待機コンポーネントの使用を完了すると（つまり、クライアントが待機コンポーネントへのレファレンスを解放すると）、ＭＳＭＱリソースディスペンサ１７６は、メソッド呼び出しのバッファをＭＳＭＱに引き渡す。クライアントのトランザクションが正常に完了すると、ＭＳＭＱは記録されたメソッド呼び出しを収めている連続バッファを、待機コンポーネント８６が置かれているＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージキュー１５８にメッセージとして送信する。他方、クライアントのトランザクションがアボートしたときは、ＭＳＭＱはバッファを破棄し、メッセージを送信しないので、記録されたメソッド呼び出しはキャンセルされる。（トランザクションがアボートする「運命にある」いくつかの場合には、ＭＳＭＱリソースディスペンサ （ｒｅｓｏｕｒｃｅ ｄｉｓｐｅｎｓｅｒ） は、いずれにしろアボート処理のときバッファが破棄されるので、バッファをＭＳＭＱに渡さないだけである。）ＭＳＭＱリソースディスペンサ１７６は、レコーダの要求を受信してバッファされたメソッド呼び出しをメッセージキュー１５８に送信するためのインタフェース１７８を有している。ＭＳＭＱリソースディスペンサ１７６は、オープンＭＳＭＱキューのキャッシュを備え、ＭＳＭＱ ＡＰＩを使用してメソッド呼び出しのバッファを、ＭＳＭＱを経由してメッセージキュー１５８に送信する。

（リスナ）
再び図２に戻って説明すると、リスナ１５２は、待機コンポーネント８６が置かれているＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージキュー１５８をモニタするＣＯＭ＋提供のオブジェクトである。リスナ１５２は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎがその “Ｑｕｅｕｅ ＢＬＯＢ” 属性で指定されたメッセージキューをもち、”Ｑｕｅｕｅ Ｌｉｓｔｅｎｅｒ” 属性がオンにセットされていれば、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのスタートアップ時に生成される。リスナ１５２は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージキュー１５８をオープンし、メッセージが到着するのを待つ。メッセージが到着すると、リスナ１５２は、メッセージを消費し、処理するプレーヤ１５４のインスタンスを実行するためのスレッドをディスパッチする。図示ＱＣアーキテクチャ１３０では、ＡＳＰ９０ごとに１つのリスナ１５２がある。

リスナ１５２のセットアップ時に、メッセージキュー１５８は、多数のクライアント１３２の待機メソッド呼び出しからの多数のメッセージを収容できる潜在能力を持っている。さらに、リスナ１５２は、複数のメッセージキューをモニタして、ＡＳＰ９０内のＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎｓを調べることができる。従って、リスナ１５２は、好ましくは、適度のサイズのスレッドプールを使用し、そこからプレーヤスレッドをディスパッチするようにすると、メッセージ処理スループットが最大になる。スレッドの数を適度にすると、サーバコンピュータプロセッサの過負荷が回避される。さらに、待機メソッド呼び出しはリアルタイム応答を必要としないので、新規スレッドを待機メッセージ用に即時にスケジュールする必要がなくなる。別の方法として、プールされるオブジェクトインスタンスの数に上限と下限を設けると、待機コンポーネントにプーリングされたオブジェクトインスタンスは、過負荷が防止される。複数のメッセージキューの場合には、リスナ１５２は、プレーヤスレッドディスパッチングをキューの間で公平に配分することが好ましく、そのようにすれば、別のキューのディスパッチを開始する前にあるキューからのメッセージが消費されることはない。

（プレーヤ）
図５に示すように、プレーヤ１５４は、ＣＯＭ＋ Ｕｔｉｌｉｔｙライブラリに用意されている（ＣＯＭ＋ディレクトリ内のＤＬＬファイルにも入っている）ＣＯＭオブジェクトに実装されている。上述したように、リスナ１５２は、待機コンポーネント８６のメソッド呼び出しが入っているメッセージが到着したとき、リスナのＡＳＰ９０にプレーヤ１５４を作成し、呼び出す。プレーヤ１５４は、「トランザクション要求（ｔｒａｎｓａｃｔｉｏｎ ｒｅｑｕｉｒｅｄ）」にセットされたトランザクション属性をもっている。このようにセットされていると、ＣＯＭ＋実行環境８０は、そこでプレーヤが生成されるトランザクションを、上掲の自動トランザクション特許出願に記載されている自動トランザクションアーキテクチャに従って自動的に開始する。待機コンポーネント８６に対してプレーヤ１５４によってプレイバックされるメソッド呼び出しも、自動的に関連付けられてこのトランザクションに入れられる。

作成されると、プレーヤ１５４は、リスナ１５２内のルーチンをコールして、待機コンポーネント８６のメッセージ呼び出しを収めている待機メッセージを取り出す。プレーヤ１５４は、最初にバッファを獲得し、次にリスナのルーチンを使用して、”ＭＱＲｅｃｅｉｖｅＭｅｓｓａｇｅ” ＡＰＩ（標準ＭＳＭＱ ＡＰＩ）オペレーションを通してメッセージをバッファにロードする。”ＭＱＲｅｃｅｉｖｅＭｅｓｓａｇｅ” ＡＰＩオペレーションは、プレーヤのトランザクションの一部にされる。

次に、プレーヤ１５４は、ＡＳＰ９０内の待機コンポーネントのインスタンスを生成し、スタブオブジェクト１８０でスタブマネージャの働きをする。つまり、Ｍｉｃｒｏｓｏｆｔ ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャによって生成された（つまり、Ｍｉｃｒｏｓｏｆｔ インタフェース定義言語 （ＭＩＤＬ） による待機コンポーネントの記述から生成された）またはＭｉｃｒｏｓｏｆｔ Ａｕｔｏｍａｔｉｏｎ Ｔｙｐｅ Ｌｉｂｒａｒｙのマーシャラに従って生成されたインタフェーススタブ１８２−１８３を管理する。スタブマネージャとして、プレーヤ１５４は、それぞれのインタフェース識別子 （ＩＩＤ） がメッセージに見つかったとき、待機コンポーネントのインタフェース８７のインタフェーススタブ１８２−１８３（「スタブレット（ｓｔｕｂｌｅｔ）」とも呼ばれる）をロードする。プレーヤ１５４は、スタブレット１８２−１８３を使用して、メッセージからのメソッド呼び出しデータをアンマーシャリングし、アンマーシャリングされたメソッド呼び出しを待機コンポーネント８６に対して出す。また、プレーヤ１５４は、レコーダ１５０によって挿入されたセキュリティヘッダを、該当セキュリティサービスをコールすることによってインターセプトする。

（持続的サーバ側アボート）
リスナ１５２とプレーヤ１５４は協力し合って、「有害メッセージ（ｐｏｉｓｏｎ ｍｅｓｓａｇｅ）」と「持続的サーバ側アボート」を処理する。（ここで言う有害メッセージとは、待機コンポーネントにプレイバックされたときトランザクションアボートを持続的に引き起こすようなメソッド呼び出しを収めているメッセージのことである。）具体的に説明すると、メソッド呼び出し群が待機コンポーネント８６にプレイバックされるときプレーヤのトランザクションがアボートすると、待機コンポーネントの作業はロールバックされる。また、トランザクションがアボートすると、ＭＳＭＱは、そのトランザクションアボート処理の一部として、メソッド呼び出しメッセージをＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージキュー１５８に戻し、再試行する。図示のＱＣアーキテクチャ１３０では、プレーヤ１５４は、エラーまたは障害を示す戻り値（例えば、障害ＨＲＥＳＵＬＴ値）を待機コンポーネント８６から受信すると、トランザクションをアボートさせるようになっている。待機コンポーネントでのメソッド呼び出しの処理がアボートを保証している場合には、待機コンポーネント８６は “ＳｅｔＡｂｏｒｔ（）” メソッドをコールして（上掲の自動トランザクション特許出願に記載されているように）トランザクションをアボートさせることも可能である。

図示のＱＣアーキテクチャ１３０では、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎと関連付けられたメッセージキューは５つある。つまり、通常の入力キュー、「第１回再試行」キュー、「第２回再試行」キュー、「第３回再試行」キュー、および「最終休止」キューである。ＱＣアーキテクチャでは、これらのキューを使用して持続的サーバ側アボートを処理している。具体的には、待機コンポーネント８６に対するメソッド呼び出しを繰り返した結果、トランザクションにアボートが起こると、ＱＣアーキテクチャ１３０では、次のシーケンスをサイクルする。つまり、（１） プレーヤ１５４は、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのキューからメソッド呼び出しメッセージを取り出し、（２） プレーヤ１５４は、待機コンポーネント８６のインスタンスを生成し、待機コンポーネントに対しメソッド呼び出しをプレイし、（３） トランザクションはアボートし、ロールバックされ、（４） ＭＳＭＱはメッセージを、そのメッセージが取り出されたＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージキューの先頭に戻す。

連続的アボートが起こると、プレーヤ１５４は、戻された「有害メッセージ」を、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの再試行キューのシーケンスを通って移動させていく。ＱＣアーキテクチャの代替実施形態では、図示アーキテクチャについて後述するものとは異なる数の再試行とインターバルを使用することが可能である。具体的には、アボートの後通常の入力キューに戻ると、プレーヤ１５４は、戻されたメッセージを第１回再試行キューに移動する。リスナ１５２は、毎分１回ごとに第１回再試行キューが尽きるまでサービスし、ほぼ１分のインターバルでプレーヤ１５４を通して待機コンポーネント８６にメッセージをリプレイする。

メッセージが３回目に第１回再試行キューに戻されると、プレーヤ１５４は、メッセージを第２回再試行キューに移動する。リスナ１５２は、３分ごとに第２回再試行キューが尽きるまでサービスする。ここで再び、このインターバルでメッセージはプレーヤ１５４を通して待機コンポーネント８６にリプレイされる。

メッセージが３回、第２回再試行キューに戻されると、プレーヤ１５４は、メッセージを第３回再試行キューに移動する。リスナ１５２は、５分ごとに第３回再試行キューが尽きるまでサービスし、ここで再び、メッセージは、このインターバルでプレーヤ１５４を通して待機コンポーネント８６にリプレイされる。

メッセージが５回目に第３回再試行キューに戻されると、プレーヤ１５４は、メッセージをＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの最終休止キューに移動する。しかし、この最終休止キューは、リスナ１５２によってサービスされない。メッセージは、手作業で移動されるか（以下で説明するＱｕｅｕｅｄ Ｃｏｍｐｏｎｅｎｔｓ Ｍｅｓｓａｇｅ Ｍｏｖｅｒユーティリティを使用して）、あるいはＭＳＭＱ Ｅｘｐｌｏｒｅｒ（ＭＳＭＱを管理するユーティリティプログラム）によって除去されるまで最終休止キューに残っている。

アボートが起こるたびに、プレーヤ１５４は、イベントログメッセージを書き出す。プレーヤ１５４は、メッセージがあるキューから別のキューに移されたとき、別のイベントログメッセージを書き出す。メッセージが最終休止キューに移されると、さらに別のイベントログメッセージを１つだけ書き出す。プレーヤ１５４は、メッセージを診断情報で補足するといった目的で、キューからキューに移動する前にメッセージを修正することも可能である。

待機コンポーネント８６は、オプションとして、関連の例外ハンドラ１８８をもつことも可能であり、これは、カタログ１６５に登録されている待機コンポーネント８６の “Ｅｘｃｅｐｔｉｏｎ＿ＣＬＳＩＤ”エントリによって指定されている。この例外ハンドラは “ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０をサポートするＣＯＭオブジェクトである。例外ハンドラ１８８が待機コンポーネント８６に対して登録されていれば、プレーヤ１５４は、メッセージからのメソッド呼び出しをプレイする前に、まず例外ハンドラの“ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０をコールする。待機コンポーネント８６は、自身が“ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０をもち、自身を“Ｅｘｃｅｐｔｉｏｎ＿ＣＬＳＩＤエントリに例外ハンドラとして指定することもできる。“Ｅｘｃｅｐｔｉｏｎ＿ＣＬＳＩＤエントリの指定がなければ、プレーヤ１５４も、待機コンポーネント８６の“ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０があるかどうかを問い合わせをし、コールして例外処理を行う。

“ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０は、メッセージが最終休止キューに置かれる寸前にあることを例外ハンドラ１８８に知らせ、持続的アボートで別の方法で処理できるようにすることを目的としている。例外ハンドラは、問題診断情報を収集したり、プレーヤによるこのインタフェースへのコールに応答して、持続的で重大な問題があることをクライアントに知らせるオブジェクトまたはメッセージを生成したりする機能を実装することも可能である。待機コンポーネント８６が、関連の例外ハンドラをもっていなければ、「有害メッセージ」は、その再試行が上述したように尽きたとき、最終休止キューに入れられるだけである。しかし、例外ハンドラが存在していれば、プレーヤ１５４は、メッセージが最終休止キューに移される前に最後の１回だけ“ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェースのメソッドをコールする。待機コンポーネント８６へのメソッド呼び出しプレイバックがこの最終回でもアボートを引き起こしたときは、「有害メッセージ」は最終休止キューに入れられる。

他方、クライアント側では、ＭＳＭＱは、ＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの入力メッセージキューをまたがってメッセージが移動できない場合がある。このようなことが起こるのは、例えば、キューアクセスコントロールがメッセージをクライアントからサーバに移動することを許していないときである。このような場合は、ＭＳＭＱはメッセージをクライアント側キューマネージャの “Ｘａｃｔ Ｄｅａｄ Ｌｅｔｔｅｒ” キューに移動する。ＱＣアーキテクチャ１３０には、配達不能 （ｄｅａｄ ｌｅｔｔｅｒ） キューモニタ１９４が用意されている（図６参照）。このモニタ１９４は、クライアントコンピュータ９２側の待機コンポーネント８６の “Ｅｘｃｅｐｔｉｏｎ＿ＣＬＳＩＤ” カタログエントリで指定された例外ハンドラ１８８のインスタンスを生成し、”ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェース１９０のＩＩＤを指定して “ＱｕｅｒｙＩｎｔｅｒｆａｃｅ（）” コールを出す。これが成功すると、モニタは “ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ：：ＦｉｎａｌＣｌｉｅｎｔＲｅｔｒｙ（）” メソッドを呼び出し、メッセージからのメソッド呼び出しを、クライアント側の待機コンポーネント８６の実装に対してプレイバックする。このクライアント側の待機コンポーネントは、オプションとして、診断情報を保存しておくことも、以前のトランザクションの効果を逆に戻す（補償する）アクションをとることもできる。プレイバックがコミットされたときは、メッセージは配達不能キューから除去される。プレイバックがアボートするか、あるいは例外ハンドラ１８８とＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌインタフェース１９０が利用可能でないときは、メッセージは手作業による処理のために配達不能キューに残されている。

（待機コンポーネントメッセージムーバ）
ＱＣアーキテクチャ１３０には、システム管理者や他の人がメッセージをあるＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎキューから別のキューに手作業で移動できるようにする、「待機コンポーネントメッセージムーバ（Ｑｕｅｕｅｄ Ｃｏｍｐｏｎｅｎｔｓ Ｍｅｓｓａｇｅ Ｍｏｖｅｒ）」と呼ばれる管理ツールが用意されている。上述したように、ＱＣアーキテクチャ１３０は、メッセージを最終休止キューに移すことによって持続的サーバ側アボートを処理し、リスナ１５２とプレーヤ１５４がメッセージで継続的に「ループ」するのを防止している。ある場合には、持続的アボートの原因は、サーバコンピュータ側で訂正することができる。例えば、アボートは、リソース（例えば、データベース）が利用可能でないと起こることがある。この事態が手作業で訂正された後、待機コンポーネントメッセージムーバユーティリティを使用して、以前の有害メッセージをＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの入力メッセージキューに戻しておけば、追加の再試行が可能になる。待機コンポーネントメッセージムーバユーティリティは、メッセージをトランザクションとして移動することが好ましく、そのようにすれば、移動期間中に障害が行ったときメッセージが紛失したり、重複したりすることがない。待機コンポーネントメッセージムーバは、Ｖｉｓｕａｌ Ｂａｓｉｃを使用するといったように、ＯＬＥオートメーションを通してプログラムで動作させることも可能である。

（インタフェース）
図８は、”ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ”インタフェース１９０を定義しているプログラムリスティング２００を示す図である。上述したように、このインタフェースは、例外ハンドラ１８８によって実装され、例外ハンドラは、持続的サーバ側アボートとクライアント側ＭＳＭＱ配達障害の異常処理に参加するように待機コンポーネント８６のカタログ１６５に登録されている。インタフェース１９０は、 ”ＦｉｎａｌＣｌｉｅｎｔＲｅｔｒｙ（）”メソッドと“ＦｉｎａｌＳｅｒｖｅｒＲｅｔｒｙ（）”メソッドを含んでいる。

”ＦｉｎａｌＣｌｉｅｎｔＲｅｔｒｙ（）”メソッドは、ＭＳＭＱを通してメッセージをサーバコンピュータ８４に配達しようとする、すべての試みが拒否され、メッセージが”Ｘａｃｔ Ｄｅａｄ Ｌｅｔｔｅｒ”キュー上で終了したことを、クライアントコンピュータ９２側の例外ハンドラ１８８（定義されている場合）に通知する。例えば、キューのパーミッションは、メッセージがキューに配達されることを許可していない場合がある。メッセージがＸａｃｔ Ｄｅａｄ Ｌｅｔｔｅｒキューに到着すると、ＱＣアーキテクチャ１３０は、”ＦｉｎａｌＣｌｉｅｎｔＲｅｔｒｙ（）”メソッドをコールして、例外ハンドラにそのように通知する。これを受けて、例外ハンドラは、待機コンポーネントクラスに関係する例外アクションをとることができる。そのようなアクションとしては、その障害をアプリケーション固有の用語で記録したり、メールメッセージをエンドユーザや管理者に送信したりすることがあり、あるいは以前のトランザクションの効果を逆に戻すといった、クライアント側の補償アクションをとることさえもある。待機コンポーネントクラスのために特定された例外ハンドラが、このインタフェースを実装していないか、あるいはその”ＦｉｎａｌＣｌｉｅｎｔＲｅｔｒｙ（）”メソッドコールから障害結果が戻された場合には、メッセージはＸａｃｔ Ｄｅａｄ Ｌｅｔｔｅｒキューに残されままになっている。

“ＦｉｎａｌＳｅｒｖｅｒＲｅｔｒｙ（）” メソッドは、据え置かれたアクティベーションを待機コンポーネント８６にプレイバックするすべての試みが失敗し（例えば、エラーＨＲＥＳＵＬＴまたはトランザクションアボートによって）、メッセージがＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの「最終休止」キューに移される寸前にあることを、サーバコンピュータ８４側の待機コンポーネントの例外ハンドラに通知する。サーバ側例外ハンドラは、待機コンポーネントクラスに固有の例外アクションをとることができる。そのようなアクションとしては、その障害をアプリケーション固有の用語で記録したり、メールメッセージをエンドユーザや管理者に送信したりすることがあり、あるいは以前のトランザクションの効果を逆に戻すといった、クライアント側の補償アクションをとることさえもある。好ましくは、待機コンポーネントは、このトランザクションを正常に完了させるための、あらゆる努力をする必要があり、さもなければ、メッセージを再処理するための手作業による介入が必要になる。待機コンポーネントクラスのために登録された例外ハンドラが、”ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ”インタフェースを実装していないか、あるいは”ＦｉｎａｌＳｅｒｖｅｒＲｅｔｒｙ（）”メソッドの実装から障害結果が戻されたか、トランザクションがアボートしたときは、メッセージは「最終休止」キューに移される。

（待機メソッド呼び出しメッセージ）
次に、図９および図１０を参照して説明すると、クライアントのメソッド呼び出しを収めていて、ＱＣアーキテクチャ１３０のレコーダ１５０によって記録されるメッセージ２２０は、図１０に示すフォーマットになっており、このフォーマットは、図９に示すプログラムリスティング２２２に定義されているデータ構造を使用している。このメッセージフォーマットによれば、メッセージ２２０は、メッセージヘッダ２２４とメッセージ本体２２６を含んでいる。メッセージ本体２２６は、コンテナセクション２２８と１つまたは２つ以上のメソッド、セキュリティまたは診断セクション２３０を含んでいる。コンテナ、メソッドセキュリティおよび診断セクション２２８，２３０は、該当タイプのセクションヘッダ２３４，２３６から始まっている。セクションヘッダ２３４，２３６は、さらに共通ヘッダ（図９の”＿ＣｏｍｍｏｎＨｅａｄｅｒ”構造）を含んでいる。コンテナセクション２２８には、コンテナセクションヘッダ２３４があるのに対し、メソッドセクションの各々は長または短メソッドヘッダ２３６とパラメータデータ２３８を含んでいる。

メッセージヘッダ２２４は、レコーダまたはＭＳＭＱのどちらかによってセットされ、メッセージ本体と一緒に送信される複数のメッセージプロパティを収めている。これらのメッセージプロパティには、プライオリティ、メッセージＩＤ、相関ＩＤ、ＭＳＭＱパス名、および応答キュー名がある。プライオリティは、メッセージがＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎのメッセージ入力キューからプレイバックされるときの順序を判断するためにセットできる値である。クライアントアプリケーションによって割り当てられるプライオリティ値を高くすると、特定のオペレーションにプライオリティ処理が与えられる。例えば、銀行アプリケーションにおいて、小切手処理よりも、クレジットカード認可が優先されるといったようにである。メッセージＩＤは個々のメッセージを特定している。相関ＩＤは、ＱＣアーキテクチャ１３０では、ワークフロー内の待機メソッド呼び出しメッセージ群をグループ化するために使用されている。ワークフローを開始する初期メッセージは、ヌルの相関ＩＤをもつメッセージを生成する。初期メッセージのメッセージＩＤは、ワークフロー内のすべての後続メッセージの相関ＩＤとなる。ＭＳＭＱパス名はデスティネーションコンピュータ名、バックスラッシュ文字（つまり、”＼”）、およびデスティネーションコンピュータ上のキューの名前からなっている。例えば、”ＭａｃｈｉｎｅＮａｍｅ？ｐａｙｒｏｌｌ”。マシン名にピリオドを使うと、「このコンピュータ」、つまり、クライアントコンピュータを意味する。応答キュー名はサーバコンピュータからの応答メッセージのキューを示している。

セクション２２８、２３０の各々における共通ヘッダ２３４，２３６（図９のプログラムリスティング２０６では構造宣言”＿ＣｏｍｍｏｎＨｅａｄｅｒ”によって定義されている）は、２つの値、つまり、タイプと長さからなっている。タイプ値は次表に示すようにセクションのタイプを示している。長さはセクションヘッダとその内容の長さである。従って、現在の”＿ＣｏｍｍｏｎＨｅａｄｅｒ”を指すポイントに長さを加えると、次の”＿ＣｏｍｍｏｎＨｅａｄｅｒ”に進む。

コンテナセクション２２８は、コンテナヘッダ２３４を含んでいる。図９の”＿ＣｏｎｔａｉｎｅｒＨｅａｄｅｒ”構造宣言で定義されているように、コンテナヘッダ２３４は、ＧＵＩＤシグネーチャ、バージョン番号、およびサーバオブジェクトを作成するモニカを含んでいる。ＧＵＩＤシグネーチャ （“ｇｕｉｄＳｉｇｎａｔｕｒｅ”） は、メッセージがＱＣアーキテクチャ１３０においてレコーダからプレーヤへのものであることを示している。ＧＵＩＤシグネーチャに異なる値を使用すれば、異なるプレーヤクラスを示すことができる。モニカは、待機コンポーネント８６を作成するためのストリーム形式のＣＯＭモニカである。代替アーキテクチャでは、コンテナヘッダは、メッセージプロトコルバージョン番号およびクライアント側ＣＯＭバージョン識別子といった、追加の値を含むことが可能である。

メソッドヘッダ２３６（図９に構造宣言”＿ＳｈｏｒｔＭｅｔｈｏｄＨｅａｄｅｒ”および”＿ＭｅｔｈｏｄＨｅａｄｅｒ”によって定義されている）は、待機コンポーネント８６でのメソッド呼び出しを表している。メソッドヘッダは短または長ヘッダにすることができるが、その違いは長メソッドヘッダがインタフェース識別子（ＩＩＤ）を指定している点である。短メソッドヘッダのＩＩＤは、メッセージ全体を左から右へパスしているとき現れた最近の長メソッドヘッダからのものであることを意味している。メソッドヘッダ２３６は、メソッド識別子、データ表現、フラグフィールド、長さ、インターセプタフラグ、およびＩＩＤ（長メソッドヘッダの場合）を含んでいる。メソッド識別子 （“ｄｗＭｅｔｈｏｄＩｄ”） は、呼び出されるメソッドの仮想関数テーブル１０４（図３）までのインデックスである。データ表現は、ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャの規則に従う”ＲＰＣＯＬＥＭＥＳＳＡＧＥ”からの”ＲＰＣＯＬＥＤＡＴＲＥＰ”値を収めており、これは、ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャに従うメソッド呼び出しのマーシャリング（図４）期間に、インタフェースプロキシ１６６−１６７によってレコーダ１５０の ”ＩＲＰＣＣｈａｎｎｅｌＢｕｆｆｅｒ”インタフェース１７０に提示されるパラメータの１つである。フラグフィールドは、ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャの規則に従う “ＲＰＣＯＬＥＭＥＳＳＡＧＥ ｒｐｃＦｌａｇｓ”フィールドを含んでおり、これも、メソッド呼び出しのマーシャリング期間にインタフェースプロキシによってレコーダ１５０に提示される。長さフィールドは、ＣＯＭ ＲＰＣの標準マーシャリングアーキテクチャの規則に従う “ＲＰＣＯＬＥＭＥＳＳＡＧＥ ｃｂＢｕｆｆｅｒ”フィールドを含んでおり、これも、メソッド呼び出しのマーシャリング期間にインタフェースプロキシによってレコーダ１５０に提示される。インターセプタフラグは、どのマーシャリングメソッドが使用されたかを示す０か１を収めている。０はＭＩＤＬ生成のインタフェースプロキシが使用されたことを意味する。長メソッドヘッダ内のＩＩＤは、メソッドが呼び出される待機コンポーネント８６のインタフェースを示している。

メソッドセクション内のパラメータデータ２３８は、メソッド呼び出しからインタフェースプロキシ１６６−１６７によって生成された、マーシャリング済みパラメータデータである。

メッセージ本体２２６は、セクションの共通ヘッダのセクションタイプに示されているセキュリティヘッダセクション、セキュリティレファレンスセクション、および診断セクション（上記表１に示す値）を含むことも可能である。セキュリティヘッダセクションは、図９の “＿ＳｅｃｕｒｉｔｙＨｅａｄｅｒ” データ構造宣言に定義されているセキュリティヘッダを含んでいる。セキュリティヘッダセクションは、レコーダで抽出され、メソッド呼び出しのプレイバック時にアクセス特権をチェックするために使用されるセキュリティ情報を収めている。このセキュリティ情報は、メソッドごとに変化する。セキュリティレファレンスセクションは、セキュリティレファレンスヘッダを含んでおり、同じセキュリティ情報がメッセージ内の後続メソッド呼び出しに適用されるときセキュリティ情報が繰り返されるのをセーブするために、メッセージ内の先行セキュリティヘッダセクションを指定している。診断セクションは、サーバ側がアボートした後メッセージがＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎキューの間で移動されるときメッセージ本体に付加されるデータである。この診断データには、例えば、障害の時刻と理由を含めることが可能である。診断セクションは、メッセージのプレイバック期間プレーヤ１５４によって無視されるが、これを使用すると、手作業による介入が容易になる（例えば、メッセージがＣＯＭ＋ Ａｐｐｌｉｃａｔｉｏｎの最終休止キューに到着した後）。

図示実施形態を参照して本発明の原理を説明してきたが、これまでの説明から理解されるように、図示実施形態はかかる原理から逸脱することなく、構成および細部の面で変更することが可能である。当然に理解されるように、ここで説明されているプログラム、プロセス、またはメソッドは、別段の断りがない限り、どの特定タイプのコンピュータ装置にも限定されず、係わりをもつものでもない。ここに記載されている教示事項に従うオペレーションは、種々タイプの汎用コンピュータ装置または特殊コンピュータ装置を使用して実行することが可能である。ソフトウェアの形で示されている図示実施形態の各エレメントは、ハードウェアで実現することが可能であり、その逆も同様である。

本発明の原理は可能な限りの多数の実施形態に応用可能であることから理解されるように、詳しく説明してきた実施形態は単なる例示的なものであり、本発明の範囲を限定するものではない。従って、特許請求の範囲に記載されている、かかる実施形態またはその変形実施形態はいずれも、本発明の範囲と精神に属するものである。

待機メソッド呼び出しのために本発明を具現化している方法および装置を実装するために使用できるコンピュータシステムを示すブロック図である。 本発明の図示実施形態による待機メソッド呼び出しのための実行環境とランライムアーキテクチャを示すブロック図である。 図２の実行環境における待機コンポーネントの構造を示すブロック図である。 図２のランタイムアーキテクチャにおけるレコーダとプロキシを示すブロック図である。 図２のランタイムアーキテクチャにおけるプレーヤとスタブを示すブロック図である。 図２のランタイムアーキテクチャにおける配達不能メッセージキューモニタと例外ハンドラを示すブロック図である。 図２のランタイムアーキテクチャにおける待機コンポーネントをアクティベートするためのオブジェクトインスタンス生成コールの例を示すプログラムリストである。 図５と図６における例外ハンドラの “ＩＰｌａｙｂａｃｋＣｏｎｔｒｏｌ” インタフェースを示すプログラムリストである。 図２のランタイムアーキテクチャにおける待機メソッド呼び出しメッセージのフォーマットを示すプログラムリストである。 図２のランタイムアーキテクチャにおける待機メソッド呼び出しメッセージのフォーマットを示すブロック図である。

符号の説明

８０ 実行環境
８４ サーバコンピュータ
８６ オブジェクト
９０ ＡＳＰ
９２ クライアントコンピュータ
１２８ トランザクションマネージャ
１３０ 待機コンポーネントランタイムアーキテクチャ
１３２ クライアントプログラム
１３４ クライアントプロセス
１５０ レコーダ
１５２ リスナ
１５４ プレーヤ
１５８ メッセージキュー
１６５ カタログ

Claims (3)

1. サーバコンピュータ上の待機コンポーネントに対して、クライアントコンピュータから待機メソッド呼び出しを実行するための方法であって、
   前記クライアントコンピュータが、クライアントプログラムからのインスタンス生成要求に応答して、前記待機コンポーネントのインスタンスを生成するためのＡＰＩ関数をコールすると、前記クライアントコンピュータ上に、レコーダとして機能するコンポーネントのインスタンスが生成され、前記サーバコンピュータ上に前記待機コンポーネントのインスタンスを生成させる第１メッセージを、前記レコーダから前記クライアントコンピュータ上の第１メッセージキューに送信するステップと、
   前記サーバコンピュータ上で、アプリケーションサーバプロセスが起動されると、リスナとして機能するコンポーネントのインスタンスが生成され、前記リスナが、前記第１メッセージキューから前記サーバコンピュータ上の第２メッセージキューに転送された前記第１メッセージを受信して、プレーヤとして機能するコンポーネントのインスタンスとを生成させるステップと、
   前記プレーヤが、前記第１メッセージを参照して前記待機コンポーネントのインスタンスを生成させるステップと、
   前記レコーダが、前記クライアントプログラムから待機メソッド呼び出しを受信すると、複数の前記待機メソッド呼び出しをマーシャルして第２メッセージを生成し、前記第１メッセージキューに送信するステップと、
   前記第１メッセージキューから、前記第２メッセージキューへ前記第２メッセージを転送するステップと、
   前記リスナが、前記第２メッセージキューを監視し、前記第２メッセージが前記第２メッセージキューに到着すると、前記プレーヤを呼び出すステップと、
   前記プレーヤが前記リスナに呼び出され、前記第２メッセージから前記待機メソッド呼び出しをアンマーシャルして、アンマーシャルされた前記待機メソッド呼び出しを前記待機コンポーネントに出すステップと
   を備えたことを特徴とする方法。
2. 前記レコーダは、複数のプロキシインタフェースを含み、各々のプロキシインタフェースは、前記クライアントプログラムから特定の待機コンポーネントに対する待機メソッド呼び出しを受信するプロキシとして動作することを特徴とする請求項１に記載の方法。
3. 前記クライアントプログラムから前記待機コンポーネントに、ローカルプロキシを介して、リアルタイムメソッド呼び出しを出すステップと、
   前記リアルタイムメソッド呼び出しとは非同期に前記クライアントプログラムを実行するステップと、
   前記クライアントプログラムが、前記リアルタイムメソッド呼び出しに対する戻り値を受信するステップと
   をさらに備えたことを特徴とする請求項１に記載の方法。

Images