(57)【要約】【課題】本発明は、フレームワーク・アーキテクチャ内でプラグイン・アプリケーションを可能にするシステム及びその方法を提供する。【解決手段】本発明はソフトウェア・コンポーネント・プラグイン・フレームワーク（２００）を提供する。システムはインターフェイス・インプリメンテーション（プラグイン・モジュール）（２０４、２０５）のダイナミック・ローデイング、具体化、アンローデイングをこれらインターフェイス・インプリメンテーション（２０４、２０５）のカプセル化と共に支援する。本発明によりソフトウェア再使用、相互操作性、及び早い製品開発サイクルを含む多くの効果が提供される。【選択図】図２
2004534304.tif 000002
【特許請求の範囲】
【請求項１】
クライアント・アプリケーションがサーバー・コンポーネント・アプリケーションと通信することを可能にするためのフレームワーク・アーキテクチャ・システムであって、
サーバーへのアクセスをクライアントに提供するサーバー・エンジンを備え、前記サーバー・エンジンが、
サービスを提供するためのサーバー・コンポーネントと、
前記サービスの関数を提供するための前記サーバー・コンポーネント内のインプリメンテーションと、
クライアント・アプリケーションが前記インプリメンテーションにアクセスすることを可能にするためのインターフェイス機構とを含むフレームワーク・アーキテクチャ・システム。
【請求項２】
前記サーバー・コンポーネントが複数のインプリメンテーションを含み、前記インターフェイス機構は前記クライアント・アプリケーションが前記プラグイン・インプリメンテーションの１つを選択してアクセスすることを可能にする請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項３】
前記インプリメンテーションがプラグイン・インプリメンテーションであり、実行時に別のインプリメンテーションにより置換できる請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項４】
前記インターフェイスが、前記サーバー・コンポーネントの前記インプリメンテーションにより提供される関数のためのインターフェイス定義仕様を提供する請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項５】
前記インターフェイスが前記インターフェイス定義に従うデータ・タイプ構造を提供し、前記データ・タイプ構造の各メンバーが前記インターフェイスにより定義されるサービスを実現するインプリメンテーション関数への関数ポインタである請求項４に記載のフレームワーク・アーキテクチャ・システム。
【請求項６】
インターフェイス識別子と共に各インターフェイスのレコードを含むインターフェイス名前空間をさらに含む請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項７】
各インターフェイスが前記インターフェイスのバージョンと関連付けられている請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項８】
前記インターフェイスに対して複数のインプリメンテーションが存在する請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項９】
前記サーバー・コンポーネントに対して同じインプリメンテーションを提供する複数のインターフェイスが存在する請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項１０】
前記インプリメンテーションが、同じインターフェイスの別のインプリメンテーションからインターフェイス・メソッド及び関数の小組を継承する請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項１１】
インプリメンテーションが登録プロセスにより前記エンジン中にプラグインされて、そして前記エンジンから除去される請求項３に記載のフレームワーク・アーキテクチャ・システム。
【請求項１２】
前記インプリメンテーションが、実行時にエンジンによりロードされるコンテイナ内に記憶されている請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項１３】
前記コンテイナが、ダイナミック・ローダブル・ライブラリイである請求項１２に記載のフレームワーク・アーキテクチャ・システム。
【請求項１４】
前記コンテイナが、複数のプラグインを含む請求項１２に記載のフレームワーク・アーキテクチャ・システム。
【請求項１５】
前記インプリメンテーションが、前記サーバー・コンポーネントにサービスを追加するためのインターセプターを含む請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項１６】
前記インターセプターがファンアウト・インターセプターであり、インターフェイスの具体化の際にインプリメンテーションは複数のインターセプテイング・プラグインをインターセプション・シーケンス属性により指定されるようにまた具体化し、そしてクライアントによるその後のメソッドの呼び出しが指定された順序でインターセプテイング・プラグインの対応するメソッドの呼び出しを生ずる請求項１５に記載のフレームワーク・アーキテクチャ・システム。
【請求項１７】
前記インターセプターが、スタック・インターセプターであり、インターフェイスの実現の際にインプリメンテーションは各プラグインをインターセプション・シーケンスで順に具体化する請求項１５に記載のフレームワーク・アーキテクチャ・システム。
【請求項１８】
インプリメンテーションの永続性記憶のためにレジストリをさらに含む請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項１９】
クライアント・アプリケーションがインプリメンテーションを実現することができるための実現機構をさらに含み、前記インプリメンテーションはｖテーブル、プライベート・データ記憶、及びインスタンス当たりのデータ構造を含む請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項２０】
実現機構が、プラグインｖテーブル、プライベート・データ記憶、及びインスタンス当たりのデータ構造内に記憶されている情報を検索して、前記情報をプロキシｖテーブルにコピーし、そしてクライアントへプロキシｖテーブルへのポインタを戻すためのロジックを含む請求項１９に記載のフレームワーク・アーキテクチャ・システム。
【請求項２１】
クライアントがこのポインタをその後にインターフェイス・インプリメンテーションと通信するために使用する請求項２０に記載のフレームワーク・アーキテクチャ・システム。
【請求項２２】
前記インプリメンテーションが、ソフトウェア・パーソナリテイである請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項２３】
前記ソフトウェア・パーソナリテイが、Ｔｕｘｅｄｏ、Ｊｏｌｔ、又はＡＭＳの１つである請求項２２に記載のフレームワーク・アーキテクチャ・システム。
【請求項２４】
前記パーソナリテイが、プログラミング・アテイチュードを含む請求項２３に記載のフレームワーク・アーキテクチャ・システム。
【請求項２５】
前記プログラミング・アテイチュードが、Ｃ、ＯＬＥ、又はコボルの１つである請求項２４に記載のフレームワーク・アーキテクチャ・システム。
【請求項２６】
前記インプリメンテーションが、ソフトウェア・エクステンションである請求項１に記載のフレームワーク・アーキテクチャ・システム。
【請求項２７】
クライアント・アプリケーションがサーバー・コンポーネント・アプリケーションとフレームワーク・アーキテクチャを介して通信することを可能にするための方法であって、
サーバーへのアクセスをクライアントに提供するサーバー・エンジンを与え、
前記サーバー・エンジンが、
サービスを提供するためのサーバー・コンポーネントと、
前記サービスの関数を提供するための前記サーバー・コンポーネント内のインプリメンテーションと、
クライアント・アプリケーションが前記インプリメンテーションにアクセスすることを可能にするためのインターフェイス機構とを含む方法。
【請求項２８】
前記クライアント・アプリケーションが前記インターフェイスにより提供される複数のプラグイン・インプリメンテーションの１つを選択してアクセスすることができることをさらに含む請求項２７に記載の方法。
【請求項２９】
前記インプリメンテーションが、プラグイン・インプリメンテーションであり、そして実行時に別のインプリメンテーションに置換できる請求項２７に記載の方法。
【請求項３０】
前記インターフェイスが、前記サーバー・コンポーネントの前記インプリメンテーションにより提供される関数に対するインターフェイス定義仕様を提供する請求項２７に記載の方法。
【請求項３１】
前記インターフェイスが前記インターフェイス定義に従うデータ・タイプ構造を提供し、前記データ・タイプ構造の各メンバーは前記インターフェイスにより定義されるサービスを実現するインプリメンテーション関数への関数ポインタである請求項３０に記載の方法。
【請求項３２】
インターフェイス識別子と共に各インターフェイスに対するレコードを含むインターフェイス名前空間を維持することをさらに含む請求項２７に記載の方法。
【請求項３３】
各インターフェイスを前記インターフェイスのバージョンと関連付けることをさらに含む請求項２７に記載の方法。
【請求項３４】
前記インターフェイスに対して複数のインプリメンテーションが存在する請求項２７に記載の方法。
【請求項３５】
前記サーバー・コンポーネントに対して同じインプリメンテーションを与える複数のインターフェイスが存在する請求項２７に記載の方法。
【請求項３６】
前記インプリメンテーションが、同じインターフェイスの別のインプリメンテーションからインターフェイス・メソッド及び関数の小組を継承する請求項２７に記載の方法。
【請求項３７】
インプリメンテーションを前記エンジン内に登録プロセスを介してプラグインとして登録することをさらに含む請求項２９に記載の方法。
【請求項３８】
前記インプリメンテーションが、実行時にエンジンによりロードされるコンテイナ内に記憶されている請求項２７に記載の方法。
【請求項３９】
前記コンテイナが、ダイナミック・ローダブル・ライブラリイである請求項３８に記載の方法。
【請求項４０】
前記コンテイナが、複数のプラグインを含む請求項３８に記載の方法。
【請求項４１】
前記インプリメンテーション関数を前記サーバー・コンポーネントへサービスを追加するためのインターセプターと接続する請求項２７に記載の方法。
【請求項４２】
前記インターセプターがファンアウト・インターセプターであり、インターフェイスの具体化の際にインプリメンテーションが、
複数のインターセプテイング・プラグインをインターセプション・シーケンス属性により指定されるようにまた具体化し、そしてクライアントによるその後のメソッドの呼び出しが指定された順序でインターセプテイング・プラグインの対応するメソッドの呼び出しを生ずるステップを含む請求項４１に記載の方法。
【請求項４３】
前記インターセプターが、スタック・インターセプターであり、インターフェイスの実現の際にインプリメンテーションが、
各プラグインをインターセプション・シーケンスで順に具体化するステップを含む請求項４１に記載の方法。
【請求項４４】
インプリメンテーションをレジストリ内に記憶することをさらに含む請求項２７に記載の方法。
【請求項４５】
クライアント・アプリケーションがインプリメンテーションを実現することができるための実現機構を提供することをさらに含み、前記インプリメンテーションはｖテーブル、プライベート・データ記憶、及びインスタンス当たりのデータ構造を含む請求項２７に記載の方法。
【請求項４６】
プラグインｖテーブル、プライベート・データ記憶、及びインスタンス当たりのデータ構造内に記憶されている情報を検索し、前記情報をプロキシｖテーブルにコピーし、そしてクライアントへプロキシｖテーブルへのポインタを戻すことをさらに含む請求項４５に記載の方法。
【請求項４７】
前記ポインタをその後にインターフェイス・インプリメンテーションと通信するために使用することをさらに含む請求項４６に記載の方法。
【請求項４８】
前記インプリメンテーションが、ソフトウェア・パーソナリテイである請求項２７に記載の方法
【請求項４９】
前記ソフトウェア・パーソナリテイが、Ｔｕｘｅｄｏ、Ｊｏｌｔ、又はＡＭＳの１つである請求項４８に記載の方法。
【請求項５０】
前記パーソナリテイが、プログラミング・アテイチュードを含む請求項４９に記載の方法。
【請求項５１】
前記プログラミング・アテイチュードが、Ｃ、ＯＬＥ、又はコボルの１つである請求項５０に記載の方法。
【請求項５２】
前記インプリメンテーションが、ソフトウェア・エクステンションである請求項２７に記載の方法。
【発明の詳細な説明】
【０００１】
著作権表示
この特許書類の開示の一部は著作権保護を受ける内容を含む。著作権所有者は、特許商標庁の特許ファイル及び記録に現れるような特許書類のファクシミリな複製については異議を持たないが、それ以外については全ての著作権を留保する。
【０００２】
優先権主張
本出願は、ここに参照のために共に組み込まれた、２００１年３月３０日仮出願の仮出願番号６０／２９４，４６７「ソフトウェア・コンポーネント・プラグイン・フレームワークのためのシステム及びその方法」及び２００１年７月３１日出願の出願番号０９／９１８，８８０「ソフトウェア・コンポーネント・プラグイン・フレームワークのためのシステム及びその方法」の優先権を主張する。
【０００３】
技術分野
本発明は、一般に、オブジェクト・コンポーネント・モデルに関し、詳細には、フレームワーク・アーキテクチャ内でプラグイン・アプリケーションを可能にするシステム及びその方法に関する。
【０００４】
背景技術
今日のビジネス環境は、日々の作業に対して電子的商業又は「ｅコマース」アプリケーションにますます依存するようになっている。ｅコマース・アプリケーションは典型的に、このような企業全体機能を、サプライチェーン管理購買、販売、財務、製造、企業資源計画、及びデータ処理として定義する。ｅコマース・アプリケーションは典型的に、集団的にｅコマース又は取引サーバーとして知られている専用のコンピュータ・サーバー又はサーバーのグループ上で実行され又は動作されるよう設計されている。このようなサーバー製品は、カリフォルニア州サンノゼのＢＥＡシステムズ社からのＴＵＸＥＤＯ（商標）製品、同じＢＥＡシステムズからのウェブロジック・サーバー（商標）、ワシントン州レドモンドのマイクロソフト社からのコマース・サーバー（商標）、ニューヨーク州アーモンクのＡｖｉｌａ（商標）及びＣＲＭ（商標）を含む。
【０００５】
このようなサーバーの重要な要件は、成長する組織の必要性に合うように、証明され、信頼性、及び拡張性である。また、いくつかの製品は、柔軟性を意図して設計されている。特に、ＴＵＸＥＤＯは、全ての企業共同データを統合し、全てのユーザに接続し且つ権限を与えるために使用できる協力で柔軟なエンド・ツー・エンドのｅコマース・ソリューションを提供するように装備されている。
【０００６】
このようなｅコマース又は取引サーバーの主な短所の１つは、それらが大変大きいアプリケーションになる傾向があることである。典型的なｅコマース・サーバーは、それを通してクライアント・アプリケーションが通信できるエンジン又はカーネルを形成するためにコンパイルされなければならないサーバー・アプリケーションとして発送される。一旦、コンパイルされると、このカーネルの再構成の必要性なくしてサーバー・アプリケーション、従って、システムに追加又は修正することがほとんどできない。
【０００７】
図１は、ｅコマース・アプリケーションに適用されるような伝統的なカーネル・コンパイルを示す。図示されるように、典型的なｅコマース・サーバーは、最初はほとんど又は全く「パーソナリテイ」を持たずに発送される。ここで使用される「パーソナリテイ」の言葉は、ユーザ（クライアント）アプリケーションが相互作用する特定のアプリケーションのフロントエンドを指すために使用されて、そしてこのようなパーソナリテイとしてＡＭＳ、Ｊｏｌｔ、ＴＵＸＥＤＯを含む。パーソナリテイは、以降、「アテイチュード」と呼ばれるさまざまなプログラミング・コンセプトを介して外界（すなわち、クライアント・アプリケーション）と通信する。アテイチュードは、例えば、ジャバ、Ｃ、Ｃ＋＋、コボル及びＯＬＥ（オフジェクト・リンキング及びエンベッデイング）を含む。同様に、ｅコマース・サーバーは、ｅコマース・サーバーにより使用されるがクライアント・アプリケーションとしては直接的にプログラムされず、そして、いくつかの場合では外界と相互作用しないエクステンション、追加アプリケーションと共にはほとんど又は全く発送されない。エクステンションは、サーバーの標準の特徴を増大するために使用される有用なユーテイリテイ関数とみなすことができる。
【０００８】
伝統的に、パーソナリテイ又はエクステンションを追加するために、サーバー・カーネルは書くステップにおいて再構成及び再コンパイルされなければならない。これは、サーバーの停止時間を必要とし、そして再コンパイル作業又はできるだけ短い時間でサーバーを再び運転させる試みのいずれかの時に、エラーが導入される危険を著しく増大する。図１に示すように、ＴＵＸＥＤＯパーソナリテイに切り換え、接続モジュール・エクステンションを追加し、そしてセキュリテイ・モジュール・エクステンションを追加することは、３回ものサーバー停止時間及びカーネル再コンパイルを要する。このようなコンパイル問題は、ルーチンのサーバー・アプリケーション更新とソフトウェア・パッチを加える時にもまた遭遇する。伝統的なサーバー・アーキテクチャは、同様にサーバー・カーネル自身が置き換えられる時、モジュール・コードの再使用を可能としない。直前のバージョンのコードと大部分が同じのサーバー製品の新しいリリースのためにコードを再度書くのに多くの時間とコストを要する。彼等のサーバー製品と共に実行するためカスタム・コードを開発した顧客は、彼等のコードがサーバー製品のサーバー・リリースと共に使用できないことを見つける。全体の結果は、冗長なコーデイング、出費、及び時間の浪費の１つである。
【０００９】
発明の開示
この問題を解決するために、本発明者は、既存のアプリケーション取引サーバー又はｅコマース・サーバーを、より管理のし易いコンポーネントの組に分割することが利益となると結論した。これはまた次の目標も達成する。
【００１０】
コマース及び取引サーバー顧客が彼等のクライアント・アプリケーションを新しい又は将来のサーバー製品と共に再使用することを可能にする。
【００１１】
現在提供されているサーバー・インフラストラクチャへの変更のために他の関連のあるサーバーに基づいた製品をポーテイングしそして再証明する追加のステップを無くする。
【００１２】
サーバーに基づいた製品がサーバー・システムの最新のバージョンで修正されていないバグを含むために、ｅコマース・サーバー顧客がこうむる必要性を解決する。
【００１３】
「コンポーネント化」を通じて製品全体でコピーされる／変更されるコード量を減少し、そして冗長コードを最小にするためにソフトウェアの再使用を奨励する。
【００１４】
従って、これらの目的を達成するために、本発明者は、ここで「エンジン」と呼ばれるサーバー・エンジン・コンポーネントがいくつかの基本的なサービスを提供する中心的役割を果たし、そしてエンジンのカスタム化を可能にするプラグイン機構のｅコマース・サーバー・アーキテクチャを提案する。このカスタム化は、エンジンへの良く定義されたインターフェイスとエンジンからのコールアウトを含むことができる。パーソナリテイが、エンジン組のエクステンションへのカスタム化を含む、プラグイン・モジュールを介して提供される。
【００１５】
サーバー・エンジン内で、プラグイン・モジュールのダイナミック・リンキングとローデイング（ここでは、インターフェイス・インプリメンテーションと呼ばれる）、及び、そのインターフェイス・インプリメンテーションのカプセル化が、インターフェイス・インプリメンテーションがインターフェイス・ユーザから完全に隠されるように発生する（すなわち、コンポーネントがクライアント又はクライアント・アプリケーションとして動作する）。
【００１６】
ここに開示されるように、本発明は、エンジン・インターフェイスの動的なカスタム化を、それらのプラグイン・モジュールを通じての拡張により可能とするため、アプリケーション中に又はその一部として組み込むことができるプラグイン・フレームワークを提供する。これらのプラグイン・モジュールは、パーソナリテイとエンジン・エクステンションにより提供される。本発明と共に使用できるアプリケーション・サーバー・エンジンは、ｅコマース取引及びアプリケーション・エンジンの両方を含む。エンジン・プラグイン・フレームワークの１つの実施の形態は、以下の特徴を提供する。
【００１７】
フォーマル・プラグイン・モジュール統合モデル；
プラグイン・モジュールのダイナミック・ローデイング、リンキング及びアンローデイングのための共通のインフラストラクチャ；
プラグイン・モジュールのための共通レジストリ機構；及び
エンジンが提供されたインターフェイスへのエクステンションとして動作するプラグイン・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）。
【００１８】
プラグイン・モジュールのためのコンテイナのＤＬＬ（ダイナミック・リンク・ライブラリイ）及び非ＤＬＬの両タイプが、フレームワーク・アーキテクチャのさまざまな実施の形態により支援される。この新しいアーキテクチャを組み込んだシステムは、クライアント−サーバー関係を通じて互いに相互作用するソフトウェア・コンポーネントのプールとして見ることができる。ここでは、ソフトウェア・コンポーネントが別のコンポーネントにより提供されるサービスを要求する時、それは「クライアント」とみなされ、そして別のコンポーネントにより要求されたサービスを提供する時、それは「サーバー」とみなされる。コンポーネントにより提供されるサービスの組は、良く定義されたインターフェイスを通じてアクセスされる。コンポーネントは、対応するインターフェイスを通じて相互関連する又は相互関連しない（すなわち、互いに独立な）いずれかのサービスの複数の組を提供できる。クライアントには、コンポーネントはインターフェイスの組として見える。クライアントはこれらのインターフェイスが実際にどのようにコンポーネントにより実現されるかについては関心がない。従って、このアプリケーションのこの文脈中で使用されるようなコンポーネントは、それらが支援するインターフェイスの与えられた組についてのインプリメンテーション提供者である。コンポーネントはアプリケーションから除去でき、新しいコンポーネントが古いコンポーネントがしたのと同じインターフェイスについてのインプリメンテーションを提供する限り、別のコンポーネントと置き換えることができる。
【００１９】
このようなインターフェイス・アーキテクチャを実現する時、コンポーネントの使用に関する初期の設計決定の１つは、実行時間中にコンポーネントを利用可能にするための媒体又はコンテイナについての決定である。クライアントにより呼び出された各インターフェイスに対して後援インプリメンテーションが存在すべきである。このインプリメンテーション・ライブラリイは、もし要件がクライアントをインターフェイス・インプリメンテーションから切り離すことである場合は、動的にリンク可能であり、もし要件がコンポーネントを実際に必要とされるまでロードしない場合は、動的にロード可能であることができる。ライブラリイは同じ（すなわち、ローカル）ノード又は遠隔ノード上で別のプロセスであることができる。
【００２０】
詳細な説明
以下に、実施の形態の詳細な説明の理解に有用な言葉、略語、及び頭文字の簡単な説明が含まれる。
エンジン−共通のパーソナリテイ独立サービスの集まり（例えば、通信、負荷バランス、ルーテイング、基本セキュリテイ、基本管理）。このアプリケーションの文脈で使用される用語「エンジン」は、カーネルという言葉と同意語である。
パーソナリテイ−プログラミング・モデル支援（エンジン及び環境へのマッピングを含む）。例えば、ＡＰＩマッピング及びパーソナリテイ特有関数。
アテイチュード−プログラミング・モデルについてのプログラム的インターフェイス。
エクスインション−第３者製品と相互作用／接続するための特別なサービス。
インターフェイス−サービスの要求者（クライアント）と提供者（サーバー）との間のサービスの組に関する規約。この規約は関連する文章構成及び語義の特性（例えば、入力／出力パラメータ又は戻り値）により一組の関数を指定する。インターフェイス内のサービスは常ではないが普通は関連している。
インターフェイスＩＤ（Ｉｉｄ）−インターフェイス仕様に対する独特な識別子又はＩＤ。
インプリメンテーション−特定のインターフェイスにより指定されたサービスを実現するソフトウェア・モジュールの一組。
インプリメンテーションＩＤ−インターフェイスのインプリメンテーションのための独特な識別子又はＩＤ。このＩＤは、特定のインターフェイスに関連した登録済みインターフェイス・インプリメンテーションの全ての中で独特である。
インターフェイス実現−インターフェイス・インプリメンテーションを具体化し、そしてそのポインタをクライアントによる後の参照のために送るプロセス。
コンポーネント−一緒に束ねられたソフトウェア・モジュールの組であり、インターフェイスの組のインプリメンテーションを提供する。
プラグイン−特定のインターフェイスのインプリメンテーション。
プラグイン・フレームワーク（ＰＩＦ）−本発明によりプラグインを受領するために使用されるようなエンジン・プラグイン・フレームワーク・コンポーネント。
レジストリイ−ＰＩＦ関連情報を記憶するための永続的記憶データ貯蔵場所。
ダイナミック・リンク・ライブラリイ（ＤＬＬ）−コンポーネント・サーバー又はコンポーネントのためのコンテイナ。ＤＬＬは典型的にそれらがリンクしたクライアント・アプリケーションと同じアドレス空間を共有する。いくつかのプラットホーム上では（例えばＵＮＩＸ（登録商標））、コンテイナはそのテキスト部分が一旦ロードできるとそれを使用する全てのプロセス間で共有される共有オブジェクトである。
コンテイナ−プラグインを配達するための媒体。例えば、ＤＬＬはコンテイナとして動作できる。
仮想関数テーブル（Ｖテーブル又はＶｔｂｌ）−関連インターフェイスを構成する関数のさまざまなインプリメンテーションをポイントするインターフェイスのためのポインタの配列。
ｐＶｔｂｌ−Ｖテーブルへのポインタ。
導出されたインプレメンテーション（合成プラグイン、導出プラグイン）−あるインターフェイスの他のインプリメンテーションからのインターフェイスのいくつかのメソッドのインプリメンテーションを継承するそのインターフエイス・インプリメンテーション（換言すると、そのインターフェイスの他のインプリメーテーションと関連する又は実現する）。
一個のプラグイン−単一の具体例を持つプラグイン。
ドキュメント慣用例−本明細書の以下の部分を通じて、次の慣用例が示される例中に適用される。
［...］は、オプショナルな項目を示す。
＜...＞は、指定された文章構造と一致する実数値により置換できるトークンを示す。＜及び＞の間の値は、しばしばプラグイン指定関数を検索するためにプラグイン指定名により置換される。
【００２１】
図２は、本発明の１つの実施の形態によるシステム・アーキテクチャの概略図を示す。図２に示すように、本発明は動的に構成可能なプラグイン・エンジンを提供し、これはより大きなプラグイン・フレームワーク２００（以下、ＰＩＦという）の一部である。１つの実施の形態では、ＰＩＦ２００は、さまざまなプラグイン・パーソナリテイとプラグイン・エクステンションと一緒にエンジン２０１を含む。これらのフレームワーク・コンポーネントは、サービスを呼び出したアプリケーションには透明な態様でクライアント・アプリケーションがサービスにアクセスすることを可能にする。本発明内で使用できるパーソナリテイ２０２は、ＴＵＸＥＤＯ、Ｊｏｌｔ、ＡＭＳなどのシステムを含む。これらのパーソナリテイはクライアント・アプリケーション２０６が一組のプログラミング言語又はアテイチュード２０８を介してエンジンと相互作用することを可能にする。アタイチュードは、例えば、Ｃ、ＯＬＥ、及びＴＵＸＥＤＯパーソナリテイにより提供されるコボル・アテイチュードを含む。パーソナリテイは、クライアントによりサービスが必要とされる時に、一連のコンポーネントとしてエンジンにプラグインされる。しばしば、エクステンション２０４と呼ばれる特別化されたプラグインは、例えば、特別化されたサービス２０５のグループ又はフアミリイのマネージャ又はインターフェイスとして動作するために、同様にフレームワーク中にプラグインできる。
【００２２】
図示するように、ＰＩＦは次のようにコンポーネント・モデル・アーキテクチャのサポートとインプリメンテーションを可能にする。
【００２３】
コンポーネントは、一緒に束ねられ、対応するインターフェイスにより指定された一組のサービスのためのインプリメンテーションを提供するソフトウェア・モジュールの一組である。
【００２４】
インターフェイスは、サービスの要求者（クライアント）と提供者（サーバー）との間のサービスの組に関する規約である。この規約は関連する文章構成及び語義の特性、例えば、入力／出力パラメータ及び戻り値等、により、一組の関数を指定する。コンポーネントは、クライアント／サーバー関係を使用して、インターフェイスを介して互いに通信する。
【００２５】
このアーキテクチャにより、エンジン２０１はさらに、クライアント−サーバー関係を通じて互いに相互作用するソフトウェア・コンポーネントのプールとして、図３のように表示できる。
【００２６】
コンポーネント２１２は、別のコンポーネントにより提供されるサービス２２０、２２４を呼び出す時にクライアントとみなされ、別のコンポーネントにより呼び出されたサービスを提供する時にサーバー２１４、２１５とみなされる。各サーバー・コンポーネントにより提供されるサービスの組は、良く定義されたインターフェイス２１６、２１７を通じてアクセスできる。サーバー・コンポーネントは、相互に関連する又は相互に関連しない（互いに独立）対応するインターフェイスを通じてサービスの複数組を提供できる。
【００２７】
インターフェイスは、クライアント・コンポーネントとサーバー・コンポーネントとの間の結合ポイントである。クライアント・コンポーネントは、これらのインターフェイスがサーバー・コンポーネントによりどのように実現されるかを知る必要がない。換言すると、インターフェイスの背後のサーバー・コンポーネントは、クライアント・コンポーネントには完全に透明である。これは、インターフェイス２１６のインプリメンテーション２２１、２２２（プラグイン）は、クライアント・アプリケーション・コードに影響を与えることなく実行時に他のプラグインにより置換できることを意味する。
【００２８】
クライアントに対しては、インターフェイスは例えば、Ｃ言語データ・タイプ構造であり、その各メンバーは対応するインターフェイスにより定義されるサービスを実現するプラグイン関数を示す関数ポインタである。従って、インターフェイスは、それ（及びその対応するインプレメンテーション又はプラグイン）が登録されてその後に実現されるまでは、単にサービスの組の公式な仕様である。そのようにして、インターフェイスは、そのサービスを呼び出すことができる前に実現されなければならない。インターフェイス実現プロセスは、指定されたインプリメンテーションの探索、それを呼び出しをしたもののアドレス空間にロードし、そしてポインタの内部テーブルに対応するインターフェイスにより定義されたサービスを実現するプラグイン関数のアドレスを入れることからなる。
【００２９】
インターフェイス定義
インターフェイスを定義する１つの方法は、オブジェクト・マネージメント・グループ（以後、ＯＭＧという）のインターフェイス定義言語（以後、ＩＤＬという）又はその小組などの標準仕様を使用することである。しかし、代替的に、「構造」、「レコード」、又は、二重間接支援（例えば、Ｃ又はＣ＋＋に使用されるｓｔｒｕｃｔ命令）を持つデータ構造と等価なタイプを支援するどんな言語も使用できる。インターフェイスを実際に定義する方法は、本発明の理解には必要ではなく、インターフェイス開発者にまかせることができる。
【００３０】
しかし、インターフェイス開発者は、実行時前にクライアント及び／又はそのインターフェイスによりリンクされる、以下のソフトウェア・モジュールを提供することを期待される。
ヘッダーファイル：クライアント・アプリケーションとプラグインとは共にヘッダーファイルを、インターフェイス、インターフェイス関数の関数プロトタイプ、及びさまざまなインターフェイス関数の呼び出しのためのマクロを定義するために使用する。これらヘッダーファイルは、クライアント・アプリケーション及びプラグインのソースコード中に含まれる。
クライアント・スタッブファイル：クライアント・アプリケーションはインターフェイス関数を呼び出すためにクライアント・スタッブファイルを使用する。クライアント・スタッブは、インターフェイスを、インターフェイスの一部である各関数（メソッド）に対して１つ、言語特定データ・タイプ及びルーチンの一組として定義する。これらクライアント・スタッブはコンパイルされたクライアント・アプリケーションにリンクされる。
プラグイン・スケルトンファイル：プラグインは、プラグイン・スケルトンファイルをインターフェイス関数のクライアント呼び出しをインターフェイス・インプリメンテーション（すなわち、プラグイン）中の実際の関数インプリメンテーションへマップするために使用する。
【００３１】
インターフェイス識別
本発明の１つの実施の形態では、各インターフェイスは名前を有して、その名前はそのインターフェイスを使用するコード中のコンパイル時間タイプとしての役割を果たす。これらのプログラム的タイプはインターフェイス開発者により提供されたヘッダーファイル中に定義される。
【００３２】
インターフェイスのプログラム的名前は、アプリケーション・コード内で使用されるコンパイル時間タイプのみである。また、各インターフェイスは、次の構文を持つ独特な実行時識別子＜interface id＞を持つ。
【００３３】
2004534304.tif 000003
【００３４】
ここで、
2004534304.tif 000004
【００３５】
当業者には明らかなように、ここに与えられた特定の名前と構文は例示の目的のためであり、本発明はここに記載された特定の構文に限定されない。
【００３６】
本発明の１つの実施の形態では、エンジンＰＩＦ内に＜interface id＞を記録するための１つのユニバーサルな名前空間が存在する。各＜interface id＞は、この名前空間内では独特である。＜interface id＞に加えて、全てのインターフェイスは、２つの数＜major version number＞及び＜minor version number＞として指定される、それに関連したバージョンを持つ。バージョンと共に＜interface id＞の組合わせは、インターフェイスの特定のバージョンを独特に識別する。
【００３７】
バージョンは、インターフェイス内、特に、同じインターフェイスのリリース間の互換性を示すために使用される。＜major version number＞の変化は、異なるインターフェイスを意味する。異なるメジャー番号のインターフェイスは互いに互換性があるとは期待されない。しかし、同じ＜major version number＞であるが、異なる＜minor version number＞のインターフェイスは、より高い＜minor version number＞を持つバージョンはより低い＜minor version number＞のバージョンと下方互換性を持つという意味で互換性がある。＜major version number＞及び＜minor version number＞の両方は、０乃至２５６の間の数を表す数ストリングにより与えられる。
【００３８】
各エンジンのパーソナリテイ及びエクステンションは独特な＜component name＞を持つ。＜interface name＞はそれを所有するコンポーネント内では独特である。コンポーネント提供者（第３者ベンダー又は開発者）は、彼等が提供するインターフェイスに＜interface name＞、＜major version number＞及び＜minor version number＞を割当てる責任を持つ。
【００３９】
インプリメンテーション識別
本発明の１つの実施の形態によれば、支援された全てのインプリメンテーションは、それが実現するインターフェイスに関して独特なインプリメンテーションＩＤ（ｉｍｐｌｉｄ）を有する。このインプリメンテーションＩＤは次の構文を有する。
2004534304.tif 000005
エンジンＰＩＦ内に＜impl id＞を記録するための１つのユニバーサルな名前空間が存在する。各＜impl id＞は、この名前空間内では独特である。
【００４０】
バージョン制御
インターフェイス・バージョン互換性は、特定の呼び出すものにより呼び出された又は要求されたインターフェイスとそのインターフェイスを実現又はバックするインターフェイス・インプレメンテーション又はプラグインとの間の重要な問題である。本発明の１つの実施の形態によれば、各インターフェイスはメジャー及びマイナー・バージョン番号により指定できるバージョン番号を持つ。プラグインは、インターフェイスの指定バージョンのインプレメンテーションである。次の規則が、実現プロセス（_e_pif_realize()関数のプロセス）の際にインターフェイスをバックするとみなされるプラグインと実現されるインターフェイスとの間のバージョン互換性に関して適用される：
【００４１】
各プラグインは、それがインプリメンテーションを提供するインターフェイスのバージョンの実行時知識を持つ。もし、呼び出すものが実現しようと試みているインターフェイスのメジャー・バージョン番号と指定されたプラグインが実現するインターフェイスのメジャー・バージョン番号が異なる場合、インターフェイスとプラグインとは互換性が無く、この場合、インターフェイスの実現は失敗する。
【００４２】
もし、呼び出すものが実現しようと試みているインターフェイスのメジャー・バージョン番号と指定されたプラグインが実現するインターフェイスのメジャー・バージョン番号が同じ場合、次の規則の小組が適用される。
【００４３】
より高いマイナー・バージョン番号を持つインターフェイスは、より低いマイナー・バージョン番号及び同一の＜interface id＞を持つインターフェイスと下方互換性を有する（機能性及び関数シグニチャーの点で）。
【００４４】
より低いマイナー・バージョン番号及び同一の＜interface id＞を持つインターフェイスは、より高いマイナー・バージョン番号を持つインターフェイスの小組である。
【００４５】
実現プロセスの際、背後にあるプラグイン（すなわち、インターフェイスを実現するもの）は、実現されているインターフェイスのマイナー・バージョン番号と等しい又はより高いマイナー・バージョン番号を持たなければならない。そうでないと、インターフェイスとプラグインは互換性がない。
【００４６】
より高いマイナー・バージョン番号を持ちインターフェイスを実現するプラグインにより戻されるＶｔｂｌは、より低いマイナー・バージョン番号を持つが同じインターフェイスを実現するプラグインのＶｔｂｌの内容と大きさの２つの観点から下方互換性の方向にのみ成長することが可能である。ここで使用されるＶｔｂｌの言葉は、普通の意味を持ち、そして当業者に知られている言葉である。
【００４７】
上述された規則は、本発明の特定の実施の形態及びその実施の形態中に使用される特定のバージョン番号を説明するために与えられる。当業者には、他の規則が上述したものに加えられ又は置換できることが明らかであり、これらも本発明の精神と範囲内にある。
【００４８】
プラグイン・プロファイル
ＰＩＦプロファイルは、ＰＩＦクライアント（アプリケーション・プロセス又はシステム・プロセスのどちらかのＰＩＦ外部インターフェイス関数を呼び出したもの）を実行時にＰＩＦ関連属性の組と関連させる方法を提供する。ＰＩＦクライアントは、特定のインターフェイスについてそれ自身のインプリメンテーションを使用することを欲するか又は異なるインプリメンテーションを実現することを欲するだろう。
【００４９】
ＰＩＦプロファイルは、＜profile id＞と呼ばれる独特なプロファイル識別子により識別される。＜profile id＞の構文の詳細は以下の通りである。
＜profile  id＞:=＜a character string consists of alpha numeric characters
and _ character＞
【００５０】
エンジンＰＩＦ内に＜profile id＞に対して１つのユニバーサルな名前空間が存在する。各＜profile id＞は、この名前空間で独特である。ＰＩＦは、デフォルトのシステム全体プロファイルを探索する前に、＜interface id＞又は＜impl id＞内のＥＶ＿ＰＩＦ＿ＰＲＯＦＩＬＥ環境変数により指定されたプロファイル＜profile id＞を探索する。クライアントのグループは、同じプロファイルに関連付けられて、この結果、インターフェイス／インプリメンテーション・オブジェクト属性の同じ組を参照する。ＰＩＦクライアントは、ＥＶ＿ＰＩＦ＿ＰＲＯＦＩＬＥ環境変数を所望の＜profile id＞に設定することにより、既存のＰＩＦファイルと関係付けられる。
【００５１】
ＰＩＦレジストリ
ＰＩＦは、ＤＬＬ（指定されたプラグインを含む）であることができる必要なプラグイン・コンテナを探して、それをレジストリにロードする。従って、それはインターフェイスとそれが処理するインターフェイス・インプリメンテーションに関するそのイメージ・パス及び他の属性を知る必要がある。これを達成するため、本発明の１つの実施の形態は、この種の情報を記憶するために永続性記憶に基づいたデータ貯蔵庫を使用する。ＰＩＦは、永続性記憶に基づいたプラグイン関連情報について特定の構造を要求しない。その代わり、ＰＩＦは、このプラグイン情報を記述し、そしてプラグインを登録し及び登録削除するためと記憶されたプラグイン情報を質問及び／又は更新するための一組の命令ユーテリテイを指定する。本明細書では、ＰＩＦ関連情報を記憶するために使用されるデータ貯蔵庫を「レジストリ」という。レジストリ内で、インターフェイス及びインターフェイス・インプリメンテーションは、それぞれ、＜interface id＞及び＜impl id＞で識別される。
【００５２】
インターフェイス及びその背後にあるインプレメンテーションの両方は、関連した属性の組を有する。さらに、インプレメンテーションは、それが実現するインターフェイスと常に関連されている。ある特定のインターフェイスには、そのインターフェイスのための複数のインプレメンテーションが存在することができる。インターフェイス識別子＜interface id＞はインターフェイス・インプレメンテーションの属性であり、この特定のインターフェイス・インプレメンテーションが実現するインターフェイスを識別する。インプレメンテーション識別子＜impl id＞は、インプレメンテーションと関連付けられていインターフェイスの属性である。
【００５３】
オブジェクト指向技術においては、レジストリは、ＰＩＦ関連オブジェクトとそれが関連した属性に対する永続的な記憶とみなすことができる。これらＰＩＦ関連オブジェクト及びそれらの属性は表１、表２及び表３に記載されている。表１は、いくつかのインターフェイス・オブジェクトをリストしている。表２は、インプリメンテーション・オブジェクトをリストしている。表３は、プロファイル・オブジェクトをリストしている。当業者には明らかなように、他のオブジェクトが示されたものと置換して又は補足するためにレジストリ内に記憶でき、これらも本発明の精神と範囲内にある。
【００５４】
表１
2004534304.tif 000006
【００５５】
表２
2004534304.tif 000007
【００５６】
表３
2004534304.tif 000008
【００５７】
プラグイン登録
インターフェイス・インプリメンテーションが使用できる前（すなわち、それが実現できる前）に、それはシステム内に導入されて、レジストリ内に登録されなければならない。後でレジストリから全ての関連情報を除去するために、インターフェイス・インプレメンテーションの登録末梢及び／又は削除が必要である。これらの作業を達成するために、ＰＩＦは以下の命令ユーテイリテイを提供する。
ｅｐｉｆｒｅｇ（）はプラグインの登録のため、
ｅｐｉｆｕｎｒｅｇ（）はプラグインの登録抹消のため、
ｅｐｉｆｒｅｇｅｄｔ（）はレジストリに基づいたＰＩＦ関連情報を編集するため。
【００５８】
関数ｅｐｉｆｒｅｇ、ｅｐｉｆｕｎｒｅｇ、ｅｐｉｆｒｅｇｅｄｔ及び以下に説明されるその他の関数は、これらの関数名は説明目的のために与えられた。当業者には明らかなよう本発明はここに記載された特定の関数の使用に限定されない。
【００５９】
ダイナミック・ローダブル・ライブラリ（ＤＬＬ）
本発明の１つの実施の形態では、ダイナミック・ローダブル・ライブラリ（ＤＬＬ）がコンポーネント・サーバー又はコンテイナとして使用される。インターフェイス（プラグイン）のインプリメンテーションはＤＬＬ内に含まれる。１つの実施の形態によれば、それらの実施の形態は複数プラグインＤＬＬを支援するが、ＤＬＬは、１つのプラグインのみを含んでよい。プラグインは複数のＤＬＬに広がらなくてよい。ＤＬＬは同じインターフェイスに対する又は同じでないインターフェイスに対する複数のプラグインを含んでも良い。ＤＬＬは、対応するインターフェイスを構成する関数の小組のみを実現し、そして別のプラクインからインターフェイスの残りの関数のインプリメンテーションを継承する導出プラグインを含んでも良い。
【００６０】
ＰＩＦは、呼び出したもののアドレス空間から及びへＤＬＬをアンロードし及びロードし、そしてロードされたＤＬＬ中の関数のアドレスを得るために、以下の関数又はサービスを提供する。
＿ｅ＿ｄｌ＿ｌｏａｄは実行可能モジュールを呼び出しプロセスのアドレス空間内にロードするために使用される。
＿ｅ＿ｄｌ＿ｕｎｌｏａｄはダイナミック・ローダブル・ライブラリ（ＤＬＬ）モジュールを呼び出しプロセスのアドレス空間からアンロードするために使用される。また、この関数は指定されたライブラリイと関連した基準カウントを減少する。
＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒはエクスポートされたダイナミック・ローダブル・ライブラリ（ＤＬＬ）関数の与えられた関数名のアドレスを得るために使用される。
＿ｅ＿ｄｌ＿ａｄｄｒｅｆはＤＬＬに関連した基準カウントを増加するために使用される。
【００６１】
これらの関数は、各所望の又は支援されたパーソナリテイに調節されたライブラリイとして提供される。例えば、ＴＵＸＥＤＯと共に使用するため、関数はＴＵＸＥＤＯ標準ｌｉｇａｐライブラリイを介して提供される。
【００６２】
プラグイン・フレームワーク外部インターフェイス
ＰＩＦ外部インターフェイスは以下の関数を含む。
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）はインターフェイスの実現及びプラグインの具体化のため、
＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）はプラグインのインスタンスと関連した基準カウントを増加するため（ライフタイム制御のために使用できる）又はプラグイン・インターフェイスを複製するため、
＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）はライフタイム制御のために使用されるインスタンスと関連した基準カウントを減少するため、
＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏ（）はプラグインに関する情報を集めるため、
＿ｅ＿ｐｉｆ＿ｉｓｃｏｍｐａｔｉｂｌｅ（）はバージョン互換性の検査のため、
＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ（）はファンアウト・タイプ・インターセプション・シーケンス内のプラグイン・インスタンスのインターフェイス・ポインタの順序付けられたシーケンスを得るため、
＿ｅ＿ｐｉｆ＿ｔｈｉｓ（）はプライベート・データのアドレスを得るためである。
【００６３】
インターフェイスの実現
図４は、インターフェイス実現プロセスの際の関数呼び出しシーケンスの流れを示す。実現されるまでは、インターフェイスは関連した動作的意味論を持つ関数シグニチャーの組の単なる仕様である。１つの実施の形態では、いくつかのインプレメンテーション２３８がコンテイナ２４０内に格納できる。この機能のために他のタイプのコンテイナが利用できるが、この例では、ＤＬＬファイルが使用される。クライアント・アプリケーション２３０がこれらのインプリメンテーションをフレームワーク・レジストリ２３４内に登録する（そして、後で選択的に登録を抹消する）ために使用される。登録プロセスは上述された一続きのルーチンｅｐｉｆｒｅｇ、ｅｐｉｆｕｎｒｅｇ、及びｅｐｉｆｒｅｇｅｄｔにより達成される。ここに与えられたルーチン又は関数の名前は説明の目的であり、本発明の全ての実施の形態で必要とされるものではない。その代わり、等価な機構及びルーチンで置換してもよい。
【００６４】
登録プロセスの後、レジストリは全ての現在のインプリメンテーションのリストを含む。クライアント・アプリケーションがインプリメンテーションの使用のための要求をする時、インターフェイスを実現しなければならない。これは、＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅルーチンを通じて実行される。＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏなどの他のルーチンは、クライアント・アプリケーションがインターフェイスについて追加の情報を得ることを可能にする。インターフェイスを実現するための呼び出しはカーネル・ポータビリテイ・レイヤー２４２へ送られる。カーネル・ポータビリテイ・レイヤーはＰＩＦ２００自身がオペレーテイング・システム・レイヤー２４６から独立であることを可能にする。ＰＩＦはクライアントからの実現要求を適当なインプレメナテーション・コンテイナをロードするためのカーネル・ポータビリテイ・レイヤーへの一続きの関数要求２４４に翻訳する。また、ＰＩＦは特定のインプレメンテーションを具体化するために要求２４８を適当なコンテイナへ送る（そして、そのインプレメンテーションを解除するために後で要求２５０を送る）。
【００６５】
インターフェイスが使用できるためには、インターフェイスは言語結合、インプリメンテーション、及びクライアントとインターフェイスのインプリメンテーションとの間の相互作用の良く定義された規則組を持たなければならない。この規則組は「インターフェイス実現プロトコル」を含む。インターフェイス実現プロトコルは、クライアント呼び出し、仮想関数テーブル、プラグイン具体化及び基準カウントを制御する規則を含む。本発明の１つの実施の形態によると、どんな特定のインターフェイスのクライアントはそれがインターフェイスのいずれの関数を呼び出すことができる前にインターフェイスの背後にあるプラグインの新しく生成された具体化へのハンドル（ポインタ）を持たなければならない。それは、＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ関数を呼び出すことによりインターフェイスに対するこのハンドルを獲得する。この関数の一例が次のリスト１（数１）に示されている（ＴＭ３２Ｕが符号の無い整数変数を引用するために使用されている。他の変数タイプが使用できる）。
【００６６】
2004534304.tif 000009
【００６７】
以下にｐｌｍｐｌｌｄと呼ぶ、インプリメンテーション識別へのポインタ（インプリメンテーション識別ポインタ）は、＜impl id＞又は＜selector＞又は無効（ＮＵＬＬ）のいずれかで指定される。もし、ｐｌｍｐｌｌｄがＮＵＬＬと指定された場合、レジストリ・データベース（Ｄｅｆａｕｌｔｉｍｐｌ属性）内で定義されたデフォルト・インプリメンテーションの＜impl id＞が代わりに使用される。このデフォルト・インプリメンテーションは、レジストリ・データベースに関連した探索規則、例えば、第１クライアント（呼び出しをしたもの）プロファイル及びそのインターフェイス識別のためのシステム全体プロファイル、に従って探索される。
【００６８】
図５は、クライアントのメモリ空間中にインプリメンテーションを読むために使用される方法のフローチャートである。図５に示すように、ステップ２５２で、フレームワーク・インターフェイスの組が定義される。ステップ２５３で、クライアント・アプリケーションがフレームワーク内で定義された特定のインターフェイスを使用するために開発又は指示される。ステップ２５４で、クライアント・アプリケーションがプラグイン・フレームワーク（ＰＩＦ）内のインターフェイスを実際に使用するために要求を行う。インターフェイスを実現するために呼び出しが行われる（ステップ２５５）。これによりクライアントが所望のインプリメンテーションへのポインタを受信する（ステップ２５６）。クライアントはステップ２５７でインプリメンテーションを見つけるために使用して、そしてローカル・メモリ中にそのインプリメンテーションを回収する。
【００６９】
この例のインターフェイス実現は１つのインプリメンテーションのみを含み（継承を伴わない）、そして図６にさらに説明される。図６において、呼び出しアプリケーション（呼び出すもの）２６０がインプレメンテーション・プラグインＡ２６４を実現するためにＰＩＦ２６２を使用する。図中の破線は呼び出しシーケンス及びインターフェイスの実現の際にさまざまなコンポーネントに戻されたハンドルを示す。そして、図６中の実線は、インターフェイス実現に含まれるデータ構造内の関係を示す。呼び出すもの２６０はインターフェイスを実現するためにＰＩＦ２６２へ要求２６６を送る。ＰＩＦはプラグインＡ２６４へ具体化要求２６８を送信するためにレジストリ内に記憶されている情報及びこの要求情報を使用する。ＰＩＦは、プロキシＶｔｂｌ２７６を生成するために、プラグインＶｔｂｌ２７０、プライベート・データ記憶２７４、及びインスタンス当たりデータ構造２７２内に記憶された情報を使用する。そして、プロキシＶｔｂｌ内のポインタ２７８は呼び出すものへ戻される。このポインタを使用して呼び出すものはその後にインターフェイスとインプリメンテーションと通信２８０する。これらのプロセスの各々は以下にさらに詳細に説明する。
【００７０】
図６に示すように、戻されたハンドル（ｉｐ）は、プロキシ仮想関数テーブル（Ｐｒｏｘｙ  Ｖｔｂｌ）と呼ばれるメモリ内のデータ構造へのポインタである。１つの実施の形態では、仮想関数テーブル（Ｖｔｂｌ）は、実現されているインターフェイスのためのインプリメンテーションを含む実際の関数を指す関数ポインタのＣストラクトである。各プラグインはそれ自身のＶｔｂｌを維持することが必要である（すなわち、メモリ・ブロックを割当てそこに記憶する）。また、プラグインはインスタンスごとのプライベート・データ及びプラグイン全体のｓｔｒｕｃｔ＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏデータ構造を管理する責任を持つ。ＰＩＦは、そのメンバーがインターフェイスの指定する関数シグニチャーを実現する関数のポインタであるＣストラクトとして実現されたインターフェイスをクライアントへ提供する責任を持つ。
【００７１】
インターフェイス実現プロセスの一部として、ＰＩＦはコンテイナ又はインターフェイスをバッキングするための目標のプラグインを含んだＤＬＬをロードし、そして、もしそれが利用可能で登録されているならば、プラグインの＜_ec_pif_instantiate＞()関数を呼び出す。それ以外は、プラグインのインスタンスを具体化するためにＤＬＬ全体の＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）関数を呼び出す。＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）及び＜_ec_pif_instantiate＞()関数の両方は、同じ関数シグニチャーを有する。＜interface id＞へのポインタ及び＜impl id＞へのポインタを与えると、これらはプラグインを具体化して、次の３つのハンドルを戻す。プラグインのＶｔｂｌのアドレスと、プラグイン・インスタンス特別プライベート・データのアドレスと、プラグインの＿ｅ＿ｐｉｆ＿ｐｌｕｇ＿ｉｎｆｏ構造のアドレスとである。
【００７２】
＿ｅ＿ｐｉｆ＿ｐｌｕｇ＿ｉｎｆｏ構造は、インターフェイスのインプリメンテーションに関連する情報を含む。特に、ＥＦ＿ＰＩＦ＿ＳＩＮＧＬＴＯＮフラグはＰＩＦに対してインプリメンテーションが「一人っ子」であることを示す。一人っ子インプリメンテーションが具体化される時、インプリメンテーションを具体化するための新しい呼び出しは、第１のプラグイン・インスタンスへの参照を結果する。ＰＩＦは、このインプリメンテーションに対する他の＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）呼び出しについての参照処理を最適化するためにこの一人っ子指示を使用する（ＰＩＦは、＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）関数を呼び出す必要がないため）。もし、特定のインプリメンテーションがこの指示をオフにした場合、ＰＩＦはクライアントがインプリメンテーションを実現する度に常に＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）関数を呼び出す。一人っ子でないプラグインの実現は常に新しいプラグイン・インスタンスを結果する。
【００７３】
プラグイン・ライフタイム
ここで使用されるインターフェイス・ライフタイム制御という言葉は、現在使用中のインターフェイスのインプリメンテーションを含むコンテイナ又はＤＬＬを何時アンロードするかを決定するために使用される規則組及び機構を指す。本発明の目的の１つは、インターフェイスの現在のインプリメンテーションを別のインプリメンテーションにより置換することに対してクライアント又は呼び出すものに免疫を与えることである。クライアントに対して、コンポーネントがそれの支援するインターフェイスである。大部分の場合、クライアントはコンポーネントにより提供されるインターフェイスの実際のインプリメンテーションについて何も知らない。従って、プログラムの異なる部分は異なるインターフェイス及び／又はＤＬＬにより支援される同じインターフェイスの複数の具体化を参照するためにクライアントはＤＬＬのライフタイムを直接に制御することはできない。実際に、クライアントは１つのインターフェイスについて終了したがまだ別のインターフェイスを使用しているときにＤＬＬをアンロードすることを欲しない。クライアント・アプリケーション・プログラムの複雑性が増加すると共に、何時ＤＬＬを解除するかの決定が増加的に複雑になる。ＰＩＦがこのライフサイクルを管理するために使用できる。
【００７４】
これを達成するため、プラグイン・ライフタイム制御目的のためにＰＩＦのクライアントにより呼び出すことのできる２つの関数、すなわち、＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）及び＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）をＰＩＦは提供する。ＰＩＦは各プラグイン・インスタンスについての基準カウントを維持する。クライアントがインターフェイス・ポインタを得る時、対応する基準カウントをそのインターフェイスの＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）関数を呼び出すことにより増加する。クライアントがインターフェイスの使用を終了する時、基準カウントをそのインターフェイスの＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）関数を呼び出すことにより減少する。ＤＬＬにより支援される全てのインターフェイスの全ての基準カウントがゼロになる時、ＤＬＬはメモリからアンロードされる。
【００７５】
ＰＩＦにより提供されるこれら２つの関数に加えて、プラグインは＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙ（）関数のインプリメンテーションを提供してもよい。プラグインに対する基準カウントがゼロになる時、ＰＩＦはこの関数を呼び出す。基準カウント構成の効果的な使用のためには、関与するものに以下に示すいくつかの規則を課す。
１．インターフェイス・ポインタを返す関数は、インターフェイス・ポインタを返す前に常にそのインターフェイス・ポインタと共に＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）を呼び出す。
２．クライアントがインターフェイスを終了する時（これ以上、インターフェイス・ポインタを使用しない等）、そのインターフェイス・ポインタと共に＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）を呼び出す。
３．インターフェイス・ポインタが別のインターフェイス・ポインタに割当てられている時は常に、関数は＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）を呼び出す。
４．入れ子されたライフタイム（例えば、１つのインターフェイス・ポインタのライフタイムが別のインターフェイス・ポインタのライフタイム内に含まれる）を持つインターフェイス・ポインタは基準カウントする必要がない。しかし、重なり合ったライフタイムを持つインターフェイス・ポインタは共に基準カウントされなければならない。
５．呼び出されたものにより設定された関数パラメータ中に新しいインターフェイス・ポインタを戻す関数は、新しいインターフェイス・ポインタと共に＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）を呼び出す。
６．関数が既に呼び出したもののライフタイム内に入れ子されているため、関数への値を持つ関数パラメータ内の関数中に送られたインターフェイス・ポインタは、＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）及び＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）を必要としない。
７．関数のライフタイムの間のみ存在することが知られているインターフェイス・ポインタのローカル・コピーは＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）と＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）の対を必要としない。
８．もし、インターフェイス・ポインタがグローバル又はメンバー変数内に記憶されている場合、クライアントはそれを別の関数に送る前にインターフェイス・ポインタと共に＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）を呼び出す。
９．疑いがある時は常に、＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）と＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）の対を追加する。
【００７６】
インターフェイスの各インプリメンテーションは、ＰＩＦの＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）関数を支援する＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ（）関数を提供する。１つの実施の形態では、ＥＦ＿ＰＩＦ＿ＤＥＥＰ＿ＣＯＰＹフラグと共に＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）関数が呼び出されそしてプラグインが一人っ子でない時、ＰＩＦはプラグイン・インターフェイスのプライベート・データのコピーを得るためにプラグインの＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ（）関数を呼び出す。
【００７７】
また、各プラグイン・コンテイナ（ＤＬＬ）は、コンテイナが含むプラグインを具体化するための＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）を提供する。この関数は、もし、選択されたプラグインがそれ自身の＜_ec_pif_instantiate＞()関数を提供せずそしてその＜_ec_pif_instantiate＞()関数の名前に対するレジストリ属性ＥｎｔｒｙＦｕｎｃの値を設定しない場合、ＰＩＦにより呼び出される。
【００７８】
メンバー関数を呼び出す時、呼び出すものはプラグイン・インターフェイス（対応する＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）関数から戻される）へのインターフェイス・ポインタを第１パラメータとして含まなければならない。本発明の１つの実施の形態によると、定義されたインターフェイスの各プラグインは次の規則に従う必要がある。
１．プラグインを実現するインターフェイスの関数シグニチャーを実現するその関数のアドレスが入った静的Ｖｔｂｌを維持する。このＶｔｂｌのアドレスは、対応する＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）関数又はプラグイン特定＜_ec_pif_instantiate＞()関数により戻されるアドレスであり、第２引数として＿ｅ＿ｐｉｆ＿ｔｈｉｓ（）関数へ送られるアドレスである。
２．次の関数に対するインプリメンテーションを提供する。
＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙ（）プラグイン・インスタンスを破壊するため。
＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ（）指定されたプラグイン・インスタンスの複製コピーを生成するため。
３．プラグイン特定情報を含んだ静的メモリ・ブロックを維持する。
４．具体化されるためにＰＩＦにより呼び出される関数を選択的に提供してもよい。プラグインのＥｎｔｒｙＦｕｎｃ属性がこの関数の名前に対して設定される。この関数の関数シグニチャーは、名前を除いて、＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）のそれと同じである。
５．インターフェイス関数に対応したプラグイン関数実現は、それらの第１パラメータとしてインターフェイス・ポインタを受け取る。
６．プラグインは、適用可能な場合、それらのプライベート・データを管理する責任を持つ。
７．プラグイン・インスタンスの文脈中で呼び出されたプラグインの全関数は、プラグインの関数当たりではなく又はプラグイン・インスタンスの関数当たりではなく、プラグインのインスタンス当たりの同じプライベート・データ領域をアクセスできる。
８．プライベート・データを使用しているプラグインは、＿ｅ＿ｐｉｆ＿ｔｈｉｓ（）関数を呼び出すことによりそれらのプライベート・データにアクセスできる。
【００７９】
インプリメンテーション継承
ＰＩＦは、１つのインターフェイス・インプリメンテーションが同じインターフェイス内の別のインターフェイス・インプリメンテーションからのインターフェイス・メソッド又は関数の小組のインプリメンテーションを継承することを可能にする。同じインターフェイスのいずれか２つのインターフェイス・インプリメンテーションの間のこの継承関係は、継承フロム（継承先）属性により指定される。継承先属性は継承しているプラグインの属性であり、そしてこの属性の値は継承先のインターフェイス・インプリメンテーションを識別する。この属性はその値として＜impl id＞を取る。
【００８０】
ＰＩＦは、単一又は複数の継承を支援する。単一の継承により、継承されるインプリメンテーションは、別のインターフェイス・インプリメンテーションからそれが継承するプラグインの＜impl id＞へその継承先属性を設定することにより、継承することができる。
【００８１】
図７に、インプリメンテーション継承によるインターフェイス実現のメモリ配置が示されている。図７に示すように、破線は呼び出しシーケンス及びインターフェイス実現の際にさまざまなコンポーネントへ戻されるハンドルを示し、実線はインターフェイス実現の際に含まれるデータ構造中の関係を示す。前と同じく、呼び出しをするクライアント２６０は、インターフェイスを実現するためにＰＩＦ２６２へ要求２６６を送る。ＰＩＦはプラグインＡ２６４へ具体化要求２６８を送るために要求中の情報及びレジストリ中の情報を使用する。プラグインＡのｖｔａｂｌ２７０、プライベート・データ記憶２７４、及びインスタンス当たりデータ構造２７２からの情報がプロキシｖｔａｂｌ２７６の部分を満たすために使用される。これはプラグインＡがインターフェイス関数の小組を実行することを可能にする。残りのインターフェイス関数は、導出プラグインＢ２８４により提供される。導出プラグインＢは、そのＶｔｂｌ２９０、プライベート・データ記憶２９４、及びインスタンス当たりデータ構造２９２からの情報をプロキシＶｔｂｌの残りの関数を満たすために提供する。そして、前と同じく、呼び出すものはポインタ２７８を使用してインターフェイスと通信し、そしてプロキシｖｔａｂｌを介してバッキング・インプレメンテーションする。次の規則が、インターフェイス実現プロセスに適用される。
【００８２】
インプリメンテーション継承又は継承シーケンスに関与する全てのプラグインは、実現されているインターフェイスのそれと同じメジャー・バージョン番号を持つ。
【００８３】
インプリメンテーション継承に関与するプラグインの少なくとも１つは、実現されているインターフェイスのそれと等しいか又はより高いマイナー・バージョン番号を持つ。
【００８４】
導出プラグイン（インプレメンテーション継承プロセスの最終出力）のマイナー・バージョン番号は、インプリメンテーション継承プロセスに関与する全てのプラグイン中で最高のマイナー・バージョン番号を持つプラグインのそれである。
【００８５】
上記規則のいずれかが継承プロセスの際に違反された場合、インターフェイス実現プロセスは失敗し、そしてＥＥ＿ＰＩＦ＿ＶＥＲＳＩＯＮ＿ＭＩＳＭＡＴＣＨエラー値が＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）の呼び出しをするものに戻される。
【００８６】
プロキシＶｔｂｌは、無効（ＮＵＬＬ）又は無効アドレス値エンリトリを持ってはならない。
【００８７】
上述した特定の規則は本発明の特定の実施の形態を説明しそしてＰＩＦシステムの柔軟性を示す目的のために与えられた。これらの規則は本発明を実施するために全体又はその一部を実現する必要がない。上述したものを他の規則と置換することができ、これらも本発明の精神及び範囲内にある。
【００８８】
また、ＰＩＦはプラグイン継承について説明されたのと同様に動作するプロセスを持つインターフェイス継承を支援する。
【００８９】
インターセプター
インターセプターは、システムにサービスを追加する柔軟な手段を与える。これらは、クライアント及び拡張された目標オブジェクトの間の結合を可能にし、両方の相互要求を反映するために特別化される。インターセプターは、要求を行うクライアント・アプリケーションと要求されたオブジェクトのインプリメンテーションとの間の呼び出し及び応答コード・パス中に挿入されると論理的に考えることができる。このように、インターセプターは、挿入されているサービスを提供する構成されたインターフェイス・インプレメンテーション又はプラグインの関数又はメソッドである。
【００９０】
本発明の１つの実施の形態では、エンジンは２つのタイプのインターセプターを支援する。ファンアウト・タイプ・インターセプター及びスタック・タイプ・インターセプターである。インターセプターは、一対の属性、すなわち、インターセプション・タイプ及びインターセプション・シーケンス、により指定される。これらの属性は、インターフェイス・インプリメンテーション<impl id>と関連付けられる。インターセプション・タイプ属性はインターセプションのタイプ（ファンアウト又はスタックのいずれか）を指定し、一方、インターセプション・シーケンス属性はインターセプションの順序を定義する。
【００９１】
インターセプション・シーケンス属性は、インターセプトするプラグイン及びそれらのインターセプション順序を指定する。１つの実施の形態では、その値はカンマで分離されて順序付けられた<impl id>の組であり、対応するインターフェイスの関数が何時呼び出されるかを指定した順序でそのメソッドが呼び出されるプラグインの順序を記載する。インターフェイスの動詞がコード・パス中で参照される時は常に、インターセプション・シーケンス値のデータ・フィールド中で指定されたインターフェイス・インプリメンテーションの対応する関数が指定された順序で呼び出される。
【００９２】
ファンアウト・タイプ・インターセプター
図８に、ファンアウト・タイプ・インターセプターが示されている。図８に示すように、ファンアウト・タイプ・インターセプターは、ＰＩＦから完全に独立して実現できる。ＰＩＦはその存在をＰＩＦに関する限り知る必要が無い。インターセプションのシーケンスはインターセプション・シーケンス属性で指定されたインターセプションのシーケンスを含むプラグインのグループである。しかし、この手法では、ファンアウト・プラグインは対応するインターセプション・シーケンス属性の値を得るためにどのようにしてレジストリにアクセスするかを知る必要がある。これは、レジストリ・アプリケーション・プログラミング・インターフェイス（ＡＰＩ）を露呈することにより、又は、ファンアウト・タイプ・インターセプターによるアクセスを支援するためにＰＩＦの助けを使用することにより達成できる。
【００９３】
１つの実施の形態では、ＰＩＦは＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）及び＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ（）関数により必要な支援を提供できる。図８を再び参照すると、インターセプションのこのモデルでは、呼び出すクライアント又は呼び出すもの３０２は、プラグインＡ３０４のメソッドを呼び出すが、インターセプトするプラグイン３０６、３０８、３１０、３１２を知らない。プラグインＡの具体化の際、プラグインＡのインターセプション・シーケンス属性により指定されるようなインターセプトするプラグインがまたＰＩＦにより具体化され、そしてインターセプトするプラグインのこれらのインスタンスの順序付けられたアドレスのシーケンスが、＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）を介してプラグインＡに送られる。クライアント又はインターフェイスを呼び出すものによるその後のメソッドの呼び出しは、インターセプト・シーケンス属性により指定された順序でインターセプトするプラグインの対応するメソッドの呼び出し呼び出しを生ずる。
【００９４】
このインターセプション・モデルの重要な特徴は、次のように詳細に説明できる。
クライアントがプラグインＡ（図８中、３０３で示される）のメソッドＸを呼び出すとすると、プラグインＡのメソッドＸは、次のようなプラグインＡのインターセプション・シーケンス属性により指定されたファンアウト順序でインターセプトするプラグインのメソッドＸを呼び出す：
プラグイン１のメソッドＸが呼び出される３１４、
プラグイン１のメソッドＸが戻す３１６、
プラグイン２のメソッドＸが呼び出される３１８、
プラグイン２のメソッドＸが戻す３２０、
プラグイン３のメソッドＸが呼び出される３２２、
プラグイン３のメソッドＸが戻す３２４、
・・・
プラグインｎのメソッドＸが呼び出される３２６、
プラグインｎのメソッドＸが戻す３２８、
そして、最後に、プラグインＡのメソッドＸが呼び出したものに戻す３２９。
【００９５】
インターセプトするプラグインのメソッドは、関数の戻しについて成功又は失敗を戻す。
【００９６】
順序付けられたメソッドの呼び出しは、最初のメソッドが失敗状態を戻すことにより停止し、そして、状態がクライアントへ戻される。
【００９７】
インターセプションに関与する全てのプラグインは、同じインターフェイスを実現する。すなわち、彼等の対応するメソッドは同じシグニチャーを有する。
【００９８】
同じプラグインの複数の出現は、インターセプション・シーケンスでは許されない。
【００９９】
ファンアウト・タイプ・インターセプション・シーケンス内のインターセプトしないプラグインは、ファンアウト・タイプ・プラグイン又はスタック・タイプ・プラグインになることはできない。
【０１００】
プラグインは、ファンアウト・タイプ・プラグイン及びスタック・タイプ・プラグインの両方になることはできない。
【０１０１】
ファンアウト・タイプ・プラグインは導出（すなわち、継承）プラグインになることはできない。
【０１０２】
上述された特定の規則は、本発明の特定の実施の形態を説明する目的のために与えられ、そしてＰＩＦシステムの柔軟性を示す。本発明を実施するためにこれらの規則は全部又は一部を実現する必要がない。そして、他の規則が上述したものと置換できる。これらも本発明の精神とその範囲内にある。
【０１０３】
スタック・タイプ・インターセプター
図９に、スタック・タイプ・インターセプションが示されている。図９に示されるスタック・タイプ・インターセプション・モデルにおいては、クライアント３３２がプラグインＡ３３４のメソッドを呼び出すが、インターセプトするプラグイン３３６、３３８、３４０を知らない。ＰＩＦは、インターフェイス実現の際、プラグインＡに加えて、関連インターセプション・シーケンス属性により指定されるようにインターセプテイング・プラグインをロードして具体化し、そしてインターセプション・シーケンスを構築し維持する責任を持つ。
【０１０４】
クライアント（インターフェイスを呼び出すもの）によるプラグインＡのメソッドのその後の呼び出しは、インターセプション・シーケンス属性により指定された順序でインターセプトするプラグインの対応するメソッドの呼び出しを生ずる。スタック・タイプ・インターセプション・シーケンスを含むインターフェイスの実現の際、ＰＩＦはインターフェイス・ポインタをシーケンス中の各プラグインの＜_ec_pif_instantiate＞()関数を介してインターセプション・シーケンス中の次のプラグインへ送る。
【０１０５】
このインターセプション・モデルの重要な特徴は以下に詳細に説明される。
クライアントがプラグインＡのメソッドＸを呼び出したとすると（図９中に３３３として示される）、メソッドＸがプラグインＡのインターセプション・シーケンス属性により指定された順序で次のように呼び出される：
プラグインＡのメソッドＸがプラグイン１のメソッドＸを呼び出す３４２、
プラグイン１のメソッドＸがプラグイン２のメソッドＸを呼び出す３４４、
・・・
プラグインｎ−１のメソッドＸがプラグインｎのメソッドＸを呼び出す３４６、
プラグインｎのメソッドＸが戻す３４８、
プラグインｎ−１のメソッドＸが戻す、
・・・
プラグイン２のメソッドＸが戻す３５０、
プラグイン１のメソッドＸが戻す３５２、
プラグインＡのメソッドＸが呼び出したものに戻す３５５。
【０１０６】
ファンアウト・タイプ・インターセプションのように、スタック・インターセプタにより、インターセプションに含まれる全てのプラグインは同じインターフェイスを実現する。すなわち、それらの対応するメソッドは同じシグニチャーを有する。
【０１０７】
順序付けられたメソッドの呼び出しは、失敗状態を返す最初のメソッドにより停止される。そして、この状態がクライアントへ戻される。
【０１０８】
スタック・タイプ・インターセプション・シーケンス中に含まれる全てのプラグインは、シーケンスの最後のインターセプトするプラグインを除いてスタック・タイプであることが必要である。シーケンスの最後のインターセプトするプラグインは、非インターセプト（ファンアウト・タイプ又はスタック・タイプのいずれでもない）プラグインであってよい。
【０１０９】
同じプラグインの複数の出現は、インターセプション・シーケンスでは許されない。
【０１１０】
プラグインは、ファンアウト・タイプ・プラグイン及びスタック・タイプ（スタックアゥエア）プラグインの両方になることはできない。
【０１１１】
スタック・タイプ・プラグインは導出（すなわち、継承）プラグインになることはできない。
【０１１２】
上述された特定の規則は、本発明の特定の実施の形態を説明する目的のために与えられ、そしてＰＩＦシステムの柔軟性を示す。本発明を実施するためにこれらの規則は全部又は一部を実現する必要がない。そして、他の規則が上述したものと置換できる。これらも本発明の精神とその範囲内にある。
【０１１３】
プロセス・スレッデイング
本発明の１つの実施の形態では、ＰＩＦが、特定のインプリメンテーションの＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）、＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ（）及び＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙ（）関数の呼び出しを連続でき、分離されたプロセシング・スレッドを使用できる。これはシステムの全体の性能に大幅に貢献できる。
【０１１４】
インターフェイス関数ユーテイリテイ
インプリメンテーションを登録してインターフェイスを実現するために、ＰＩＦと共に使用されるさまざまな関数が次に説明される。当業者には明らかなように追加の又は代替的な関数も使用でき、これらも本発明の精神及び範囲内にある。
【０１１５】
＿ｅ＿ｄｌ＿ｌｏａｄ
＿ｅ＿ｄｌ＿ｌｏａｄ関数は、指定された実行可能モジュールを呼び出しプロセスのアドレス空間内にマップする。
【０１１６】
2004534304.tif 000010
【０１１７】
ここで、＿ＴＣＡＤＥＦは、エンジン文脈の選択的なＡＮＳＩ定義である（典型的に、タスセード・インプリメンテーションのみに使用される。）。
ｄｌｌｐａｔｈは、ＤＬＬファイルの名前を示すナルで終了するストリングへのポインタである。もし、ストリングがパスを指定するが、そのファイルが指定されたデイレクトリ中に存在しない場合、関数は失敗する。もし、ストリングが全パス名前を指定しない場合、関数はファイルを見つけるために標準の探索戦略を使用する。
ｄｌｌｈａｎｄｌｅは、その後の＿ｅ＿ｄｌ＿ｕｎｌｏａｄ及び＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ関数内で使用されるＤＬＬハンドルである。
【０１１８】
＿ｅ＿ｄｌ＿ｕｎｌｏａｄ
＿ｅ＿ｄｌ＿ｕｎｌｏａｄ関数は、ＤＬＬをアンロードする。
【０１１９】
2004534304.tif 000011
【０１２０】
＿ｅ＿ｄｌ＿ｕｎｌｏａｄ関数は、呼び出しプロセスのアドレス空間から指定されたライブリイをアンロードする。この呼び出しの後、指定されたハンドルは有効でなくなる。ここで、
ｄｌｌｈａｎｄｌｅは、ロードされたライブラリイ・モジュールを識別する。＿ｅ＿ｄｌ＿ｌｏａｄ関数はこのハンドルを戻す。
【０１２１】
＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ
＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ関数は、指定されエクスポートされたダイナミック・リンク・ライブラリイ（ＤＬＬ）関数のアドレスを戻す。
【０１２２】
2004534304.tif 000012
【０１２３】
＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ関数は、指定されエクスポートされたダイナミック・ロード可能ライブラリイ（ＤＬＬ）関数のアドレスをｐｆａ中に戻す。ここで、
＿ＴＣＡＤＥＦは、前と同様に、エンジン文脈中のＡＮＳＩ定義である。
ｄｌｌｈａｎｄｌｅは、その関数を含むＤＬＬモジュールを識別する。＿ｅ＿ｄｌ＿ｌｏａｄ関数はこのハンドルを戻す。
ｐＦｕｎｃＮａｍｅは、関数名前を含むナルで終了するストリングを指す。
Ｐｆａは、ｆｕｎｃアドレスを指すポインタへのポインタである。
【０１２４】
＿ｅ＿ｄｌ＿ａｄｄｒｅｆ
＿ｅ＿ｄｌ＿ａｄｄｒｅｆ関数は、ロードされたＤＬＬに関連した基準カウントを増分する。
【０１２５】
2004534304.tif 000013
【０１２６】
＿ｅ＿ｄｌ＿ａｄｄｒｅｆ関数は、ｄｌｌｈａｎｄｌｅにより指定されたＤＬＬの基準カウントを増分する。それはプラグインのインスタントへのポインタの新しいコピーごとに呼び出される。ここで、
ｄｌｌｈａｎｄｌｅは、その関数を含むＤＬＬモジュールを識別する。＿ｅ＿ｄｌ＿ｌｏａｄ関数はこのハンドルを戻す。
【０１２７】
＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ
＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ関数は、プラグインを具体化する。
【０１２８】
2004534304.tif 000014
【０１２９】
＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ関数は、インターフェイスの実現の際（すなわち、＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）を呼び出すクライアントの結果として）、プラグイン・フレームワーク（ＰＩＦ）により呼び出された、コンテイナ全体デフォルト・プラグイン・インスタンス具体化関数（＜_ec_pif_instantiate＞()）である。それは、プラグイン・インプレメンターにより実現され、そしてプラグイン特定具体化関数が利用可能でない場合のみに呼び出される。もし、プラグイン特有＜_ec_pif_instantiate＞()関数が与えられると、ＤＬＬ全体＿ｅｃ＿ｐｆｉ＿ｉｎｓｔａｎｔｉａｔｅ（）関数ではなく、この関数が呼び出される。プラグイン特有＜_ec_pif_instantiate＞()関数は、＿ｅｃ＿ｐｆｉ＿ｉｎｓｔａｎｔｉａｔｅ（）関数のそれと同じ関数シグニチャーを有する。ここで、
ｐＩＩｄは、インターフェイス識別子へのポインタである。
ｐｉｍｐｌｅｄは、インプレメンテーション識別子へのポインタである。
ｖｅｒｓｉｏｎは、インターフェイスのバージョンである。
ｐＤａｔａは、呼び出すもの及び／又はレジストリから送られたデータである。
ｐＩｎｔｅｒｃｅｐｔｉｏｎＤａｔａは、インターセプション・データへのポインタである。
ｐＩは、プラグイン・インスタンス・ハンドルへのポインタである。
【０１３０】
＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ関数は、＜interface id＞へのポインタ、インターフェイスのバージョン及び＜impl id＞へのポインタが与えられると、実現されているインターフェイスを実現するプラグインを具体化し、そして、ｐｌにより示されたメモリ・ブロック中に具体化されているプラグインのインスタンス及びプラグインに関するハンドルの組を戻す。バージョンは、ｐｌｌｄによりその＜interface id＞が指示されるインターフェイスのバージョンを指定する。
【０１３１】
ｐＩｎｔｅｒｃｅｐｔｉｏｎＤａｔａは、以下の通り定義されるデータ・タイプ・ストラクトｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｄａｔａのインコア・データを指示する。
【０１３２】
2004534304.tif 000015
【０１３３】
ポインタｐＩは、以下の通り定義されるデータ・タイプ・ストラクトｅ＿ｐｉｆ＿ｉｎｓｔａｎｃｅ＿ｈａｎｄｌｅｓのメモリ・ブロックを指示する。
【０１３４】
2004534304.tif 000016
【０１３５】
ｐＩｎｔｅｒｃｅｐｔｉｏｎＤａｔａ構造において、ｐＶｔｂｌは、具体化されているプラグインのＶｔｂｌのアドレスを含む。ｐＰｒｉｖＤａｔａは生成されているプラグインのインスタンスのプライベート・データのアドレスを含む。ｐＰｌｕｇｉｎＩｎｆｏは、具体化されているプラグインに特有なプラグイン情報を含むタイプ・ストラクト＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏのメモリ・ブロックのアドレスを含む。この構造のフィールドを満たすことはプラグインの責任である。ストラクト＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏは、次の通り宣言される。
【０１３６】
2004534304.tif 000017
【０１３７】
＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏ構造は、インターフェイスのインプレメンテーションに関連する情報を含む。ｍ＿ｆｌａｇｓフィールドは、インプリメンテーションにより設定され、そしてＰＩＦにより解釈されるフラグを定義する。本発明の１つの実施の形態では、次のフラグが定義される。
ＥＦ＿ＰＩＦ＿ＳＩＮＧＬＥＴＯＮ    インプリメンテーションが一人っ子オブジェクトである信号又はフラグ、
ＥＦ＿ＰＩＦ＿ＳＴＡＣＫ    インプリメンテーションがスタック・タイプ・インターセプト・プラグインである信号、
ＥＦ＿ＰＩＦ＿ＦＡＮＯＵＴ    インプリメンテーションがファンアウト・タイプ・インターセプト・プラグインである信号、
ＥＦ＿ＰＩＦ＿ＣＯＮＣＵＲＲＥＮＣＹＡＷＡＲＥ    インプリメンテーション（それが導出インプリメンテーション、又は、ファンアウト又はスタック・タイプ・インターセプション・シーケンスの先頭のいずれか）が並行性を知っている信号である。
【０１３８】
ＥＦ＿ＰＩＦ＿ＳＩＮＧＬＥＴＯＮフラグは、インプリメンテーションが一人っ子であるかどうかを指示するプラグイン・フレームワークへのヒントである。一人っ子インプリメンテーションが具体化される時、インプリメンテーションを具体化するための新しい呼び出しは、最初のプラグイン・インスタンスへの参照を生ずる。ＰＩＦは、このインプレメンテーションへの他の＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）呼び出しを処理する参照を最適化するためにこのヒントを使用できる（ここでは、プラグイン・フレームワークはｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）関数を呼び出す必要がない）。
【０１３９】
ｍ＿ｆｌａｇｓフィールドにより指定されたフラグは、互いに排他的ではない。ＥＦ＿ＰＩＦ＿ＱＵＥＲＹはこのようなフラグの一例である。それが設定されると、＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）は、Ｖｔｂｌ及びプラグインの具体化なしにｐＩにより指示されたストラクト＿ｅ＿ｐｉｆ＿ｉｎｓｔａｎｃｅ＿ｈａｎｄｌｅｓのｐＰｌｕｇｉｎＩｎｆｏフィールドに入れる。
【０１４０】
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ関数は、インターフェイスを実現する。
【０１４１】
2004534304.tif 000018
【０１４２】
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ関数は、ＰＩｍｐｌＩｄにより指定されたインターフェイス・インプリメンテーションを具体化することにより、ｐＩＩｄ及びｖｅｒｓｉｏｎにより指定されたインターフェイスを実現する。クライアントは、それがインターフェイスのいずれの関数を呼び出す前に、インターフェイスをバッキングするプラグインの新しく生成された具体化へのポインタを有する。それは、＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ関数を呼び出すことにより、そのインターフェイスに対するハンドルを獲得する。
【０１４３】
ＰＩｍｐｍｌＩｄは、具体化されるべきプラグインに対する＜selector＞又はその＜impl id＞のいずれかである。
【０１４４】
もし、ＰＩｍｐｌＩｄが、無効（ＮＵＬＬ）と指定された場合、インターフェイスをバックするためにインターフェイス＜interface id＞のたるのデフォルト・インプリメンテーション（ＤｅｆａｕｌｔＩｍｐｌ）がロードされる。もし、そのインターフェイスのためのデフォルト・インプリメンテーションが設定されていなければ、（実現されている）インターフェイスのそれと等しいメジャー・バージョン番号及び最高のマイナー・バージョン番号を持つ登録されたインプリメンテーションが、以下に説明されるバージョン制御規則に従って、そのインターフェイスをバックするためにロードされる。
【０１４５】
目標のプラグインのメジャー・バージョン番号はそのインターフェイスのメジャー・バージョン番号と一致しなければならない。そうでないと、実現されているインターフェイスと目標のインプリメンテーションは互換性がない。
【０１４６】
目標のプラグインのマイナー・バージョン番号は実現されているそれと等しいか又はより高くなければならない。そうでないと、インターフェイスと目標のインプリメンテーションは互換性がない。
【０１４７】
もし、目標のインプリメンテーションが他のプラグインから継承している場合、継承シーケンス中の全てのプラグインは、実現されているインターフェイスのそれと等しいメジャー・バージョン番号を持たなければならない。
【０１４８】
もし、目標のインプリメンテーションが他のプラグインから継承している場合、継承シーケンス中のプラグインの少なくとも１つが、実現されているインターフェイスのそれと等しいか又はより高いマイナー・バージョン番号を持たなければならない。
【０１４９】
もし、ｐＩｍｐｌＩｄが指定され、そしてＥＦ＿ＰＩＦ＿ＥＸＡＣＴ＿ＭＡＴＣＨフラグが設定されている場合、上述したバージョン制御規則に従いｐＩｍｐｌＩｄにより指定されたプラグインがロードされる。もし、それが登録されていない場合（すなわち、発見されない）、この関数は失敗し、そしてＥＦ＿ＰＩＦ＿ＮＯＴ＿ＲＥＧＩＳＴＥＲＥＤが戻され、エラー値が戻される。
【０１５０】
もし、ｐＩｎｐｌＩｄが指定されたが、登録されず又は発見されず、そしてＥＦ＿ＰＩＦ＿ＥＸＡＣＴ＿ＭＡＴＣＨフラグが設定されていない場合、システムはそのインターフェイスのためのデフォルト・インプリメンテーションを探索することを試みる。もし、デフォルト・インプリメンテーションが互換性がないか又は発見されない場合、システムはバージョン引数に指定された値と等しいか又はより大きい最高のマイナー・バージョンを持つ互換性のあるインプリメンテーションの探索を試みる。もし、互換性のあるインプレメンテーションが存在しない場合、関数は失敗し、ＥＦ＿ＰＩＦ＿ＮＯＴ＿ＲＥＧＩＳＴＥＲＥＤエラーが戻される。そして、例えば、そのインターフェイス識別に対して最初にクライアントの（呼び出したものの）プロファイル、そしてシステム全体プロファイルなど、レジストリに関連した探索規則に従い、指定されたプラグインが探索される。
【０１５１】
ｄａｔａは、呼び出すものからのプラグインへ送られたデータを指示し、そしてｄａｔａｌｅｎは、ｄａｔａにより指示されたバッフアの長さを指定する。
【０１５２】
＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ
＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ関数は、ロードされたプラグイン・インスタンスと関連した基準カウントを増分するか、又は、プラグイン・インスタンスを複製する。
【０１５３】
2004534304.tif 000019
【０１５４】
＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆは、ｐＩにより指示されたプラグイン・インスタンスの基準カウントを増分し、そしてプラグイン・インスタンスのアドレスをｐｐｄｕｐへ複製する。それは、プラグインのインスタントへのポインタの新しいコピーごとに呼び出される。
【０１５５】
フラグは、ＥＦ＿ＰＩＦ＿ＤＥＥＰ＿ＣＯＰＹを含み、もし指定されると、それはプラグイン・フレームワークにｐＩにより指定されたインスタンスの複製コピーを生成させ、そして複製コピーへのインターフェイス・ポインタをｐｐｄｕｐ中に戻す。複製インスタンスは、それのプライベート・データ（もし、それが存在すれば）、ライフ制御、及び独特なインターフェイス・ポインタのためのそれ自身のメモリ・ブロックを有する。
【０１５６】
＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ
＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ関数はロードされたプラグイン・インスタンスと関連した基準カウントを減少する。
【０１５７】
2004534304.tif 000020
【０１５８】
＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅは、インターフェイス・ポインタｐＩにより指示されたプラクイン・インスタンスの基準カウントを減少する。もし、指定されたプラグイン・インスタンスの基準カウントがゼロになると、そのプラグイン・インスタンスは破壊される。
【０１５９】
＿ｅ＿ｐｉｆ＿ｉｓｃｏｍｐａｔｉｂｌｅ
＿ｅ＿ｐｉｆ＿ｉｓｃｏｍｐａｔｉｂｌｅ関数は、指定されたインターフェイス・バージョンがプラグイン・インスタンスにより支援されているかどうかを検査する。
【０１６０】
2004534304.tif 000021
【０１６１】
＿ｅ＿ｐｉｆ＿ｉｓｃｏｍｐａｔｉｂｌｅ関数は、ｐＩにより指定されたプラグイン・インスタンスがｖｅｒｓｉｏｎにより指示されたインターフェイス・バージョンと互換性があるかどうかを検査する。
【０１６２】
＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ
＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ関数は、インターセプション・シーケンス中のプラグイン・インスタンスのアドレスの順序付けられたシーケンスを戻す。
【０１６３】
2004534304.tif 000022
【０１６４】
単に１つのプラグインがシーケンス中に存在するかもしれないが、それにもかかわらず、＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑは、ｐＩに指定されたプラグイン・インスタンスに関する呼び出しシーケンス中のインターセプテイング・プラグインのインスタンスのアドレスを、*ｐｐＩｎｔｅｒｃｅｐｔｉｏｎＤａｔａに指示されたデータ・タイプ・ストラクト＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｄａｔａのインコア・データ構造中に戻す。
【０１６５】
データ構造ストラクト＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｄａｔａは、次のように定義される。
【０１６６】
2004534304.tif 000023
【０１６７】
もし、呼び出すものがファンアウト・プラグインである場合、ファンアウト・プラグインについてのインターセプション・シーケンスを構成するファンアウト・インターセプテイング・プラグイン・インスタンスのアドレスのｎ個の順番付けられたシーケンスが、配列*ｆａｎｏｕｔ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑに戻される。ｆａｎｏｕｔ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ＿ｌｅｎ変数が、この配列中のアドレス数を示す。
【０１６８】
スタック・タイプ・インターセプテイング・プラグインの場合、呼び出しシーケンス中の次のプラグイン・インスタンスのアドレスは、*ｎｅｘｔ＿ｉｐに戻される。もし、ｐＩにより指示されたプラグイン・インスタンスがインターセプション・シーケンス中の最後のプラグイン・インスタンスである場合、無効（Ｎｕｌｌ）が*ｎｅｘｔ＿ｉｐ中に戻される。
【０１６９】
＿ｅ＿ｐｉｆ＿ｔｈｉｓ
＿ｅ＿ｐｉｆ＿ｔｈｉｓ関数は、プライベート・データ領域のアドレスを戻すために使用される。
【０１７０】
2004534304.tif 000024
【０１７１】
＿ｅ＿ｐｉｆ＿ｔｈｉｓは、ｐＩにより指示されたプラグイン・インスタンスのプライベート・データ領域のアドレスを戻す。ｐＶｔｂｌハンドルは、プラグイン特有Ｖｔｂｌを指示する。これはプラグインのインスタンスの生成中に＜_ec_pif_instantiate＞()関数からそのアドレスが戻される同じＶｔｂｌである。
【０１７２】
＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏ
＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏ関数がロードされたプラグインについての情報を得るために使用される。
【０１７３】
2004534304.tif 000025
【０１７４】
＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏは、ｐＩにより指定されたプラグイン・インスタンスについての情報を得る。この情報は、ｐＩｎｆｏにより指示された＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ−ｉｎｆｏ−ｐｕｂｌｉｃ構造へ戻される。
【０１７５】
2004534304.tif 000026
【０１７６】
ｍ＿ｆｌａｇｓフィールドは、ＰＩＦにより解釈されてインプリメンテーションにより設定されたフラグを定義し、そして上述されたＥＦ＿ＰＩＦ＿ＳＩＮＧＬＥＴＯＮ、ＥＦ＿ＰＩＦ＿ＳＴＡＣＫ、ＥＦ＿ＰＩＦ＿ＦＡＮＯＵＴ、及びＥＦ＿ＰＩＦ＿ＣＯＮＣＵＲＲＥＮＣＹＡＷＡＲＥを含む。同時的認識は常に合成的振舞いを含む。もし、プラグインが導出プラグイン又はインターセプション・シーケンスの頭である場合、これはその構成に含まれるプラグインの全てが同時性認識であることを意味し、そして、もし、１つのコンポーネントが同時性を支援しない場合、その構成は同時性認識ではない。この結果、この場合は、同時性認識のフラグは戻されない。
【０１７７】
フラグ引数は、選択的なフラグ、例えば、ＥＦ＿ＰＩＦ＿ＤＥＴＡＩＬＥＤＩＮＦＯフラグを指定する。もし、それが指定されると、＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏ（）は指定されたプラグインに関する詳細な情報を戻す。もし、指定されたプラグインが導出インプリメンテーションである場合、最も導出されたインプリメンテーションから始まるプラグインの導出を含む全てのインプリメンテーションに関する情報が戻される。もし、指定されたプラグインがファンアウト・タイプの頭又はスタック・タイプ・インターセプション・シーケンスの場合、指定されたプラグイン（インターセプション・シーケンスの頭）から始まり、ファンアウト・タイプの場合は左から右へ、そしてスタック・タイプの場合は上から下へインターセプテイング・プラグインが続く、インターセプション・シーケンスに含まれる全てのプラグインに関する情報が戻される。
【０１７８】
＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙ
＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙ関数がプラグイン・インスタンスを破壊するために使用される。
【０１７９】
2004534304.tif 000027
【０１８０】
＿ｅｃ＿ｐｉｆ＿ｄｅｓｔｒｏｙは、ｐＩｈａｎｄｌｅｓにより指定されたプラグイン・インスタンス特有システム資源を解放する。ｐＩｈａｎｄｌｅｓは次のように定義されるデータ・タイプ・ストラクト＿ｅ＿ｐｉｆ＿ｉｎｓｔａｎｃｅ＿ｈａｎｄｌｅｓのメモリ・ブロックを指示する。
【０１８１】
2004534304.tif 000028
【０１８２】
ここで、ｐＶｔｂｌはプラグイン・インスタンスのＶｔｂｌのアドレスを含み、そしてｐＰｒｉｖＤａｔａは破壊されているプラグイン・インスタンスのプライベート・データのアドレスを含む。もし、プラグイン・インスタンスによりプライベート・データが使用されない場合、ｐＰｒｉｖＤａｔａの値は無効（Ｎｕｌｌ）に設定される。ｐＰｌｕｇｉｎＩｎｆｏは、プラグイン・インスタンスに特有のプラグイン情報を含んだ、タイプ・ストラクト＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏのメモリ・ブロックのアドレスを含む。この関数は、プラグイン・インスタンスに関連した基準カウントがゼロになる時、ＰＩＦのみにより呼び出される。
【０１８３】
＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ
＿ｅｃ＿ｐｉｆ＿ｃｏｐｙ関数は、プラグイン・インスタンスの複製コピーを生成する。
【０１８４】
2004534304.tif 000029
【０１８５】
＿ｅｃ＿ｐｉｆ＿ｃｏｐｙは、ｐＩｈａｎｄｌｅｓにより指定されたプラグイン・インスタンス・プライベート・データの複製コピーを生成し、そしてｐＩｈａｎｄｌｅｓにより指示されたデータ構造中の複製コピーにポインタを戻す。
【０１８６】
ｐＩｎｔｅｒｃｅｐｔｉｏｎＤａｔａは、データ・タイプ・ストラクトｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｄａｔａ（上記で定義された）のインコア・データ構造を指示し、一方、ｐＩｈａｎｄｌｅｓはデータ・タイプ・ストラクトｅ＿ｐｉｆ＿ｉｎｓｔａｎｃｅ＿ｈａｎｄｌｅｓ（上記で定義された）のメモリ・ブロックを指示する。
【０１８７】
ｐＶｔｂｌは、そのプライベート・データが複製されているプラグイン・インスタンスのＶｔｂｌのアドレスを含んだポインタである。ｐＰｒｉｖＤａｔａは、プラグイン・インスタンス・プライベート・データのアドレスを含んだポインタである。もし、プラグイン・インスタンスによりプライベート・データが使用されない場合、無効（Ｎｕｌｌ）が戻される。ｐＰｌｕｇｉｎＩｎｆｏポインタは、以下の様に宣言されるプラグイン・インスタンス特定情報を含んだタイプ・ストラクト＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏのメモリ・ブロックのアドレスを含む。
【０１８８】
2004534304.tif 000030
【０１８９】
＿ｅ＿ｐｉｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏ構造は、インターフェイスのインプレメンテーションに関する情報を含む。ｍ＿ｆｌａｇｓフィールドは、ＰＩＦにより解釈されてインプリメンテーションにより設定されたフラグを定義する。フラグは、全て上述されたＥＦ＿ＰＩＦ＿ＳＩＮＧＬＥＴＯＮ、ＥＦ＿ＰＩＦ＿ＳＴＡＣＫ、ＥＦ＿ＰＩＦ＿ＦＡＮＯＵＴ、及びＥＦ＿ＰＩＦ＿ＣＯＮＣＵＲＲＥＮＣＹＡＷＡＲＥ／*を含む。
【０１９０】
ｅｐｉｆｒｅｇ
ｅｐｉｆｒｅｇ関数又は命令は、プラグイン・インプレメンテーションを登録し、そして次の構文を使用する。
【０１９１】
2004534304.tif 000031
【０１９２】
ｅｐｉｆｒｅｇ関数は、上記に示すようなさまざまオプションを取ることができる。これらオプションは次の意味を持つ。
−ｐ  登録されるべきプラグインのインプリメンテーション識別子。インプリメンテーション識別子は次の構文を持つ独特な値である。
＜ｉｍｐｌｉｄ＞  ：：＝＜コンポーネント名＞  ［／＜サブ・コンポーネント名＞］／＜インプリメンテーション名＞
−ｉ  プラグインにより実現されるインターフェイスの識別子。インターフェイス識別子は次の構文を持つ独特な値である。＜ｉｎｔｅｒｆａｃｅｉｄ＞：：＝＜コンポーネント名＞［／＜サブ・コンポーネント名＞］／＜インターフェイス名＞。もし、レジストリにインターフェイスが存在しない場合、それは自動的に生成される。
−ｖ  プラグインにより実現されるインターフェイスのバージョン番号。バージョン番号はメジャー・バージョン番号とマイナー・バージョン番号とからなる。
−ｆ  プラグイン・インプリメンテーションを含んだダイナミック・ローダブル・ライブラリ（ＤＬＬ）又はコンテイナのパス名。
−ｅ  ＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）ルーチンを実現する関数の名前。この関数は、プラグインを具体化するためにプラグイン・フレームワークにより使用される。もし、このオプションが指定されないと、プラグイン・フレームワークはデフォルト＿ｅｃ＿ｐｉｆ＿ｉｎｓｔａｎｔｉａｔｅ（）ルーチンを使用する。
−ｂ  このオプションは、このプラグインがインプリメンテーション継承を使用することを指定するために使用される。
−ｏ  このオプションは、プラグインを指定されたプロファイルに加えるために使用される。もし、ｐｒｏｆｉｌｅｉｄが存在しないと、新しいプロファイルが生成される。プロファイルは、ＥＶ＿ＰＩＦ＿ＰＲＯＦＩＬＥ環境変数をプロファイル識別子に設定することによりプロセスと関連付けることができる。プラグイン・フレームワークはデフォルト・システム全体プロファイル“ＳＹＳＴＥＭ”を探索する前に常に指定されたプロファイル中のプラグイン情報を探索する。
−ｕ  具体化の際にプラグインのインプリメンテーションに送られるユーザ・パラメータ（例えば、文字の列）。
−ｓ  このオプションは、プラグインがインターセプターであることを示すために使用される。インターセプター・タイプ引数は、プラグインにより実現されるインターセプションのタイプを言及し、そしてその値はスタック又はファンアウトのいずれかである。選択的に、インターセプション・シーケンスは、記号‘：’の後に指定することができる。このインターセプション・シーケンスは、インターセプテイング・プラグイン及びインターセプション順序を指定するインプリメンテーション識別子のコンマで分離されたリストである。
【０１９３】
ｅｐｉｆｕｎｒｅｇ
ｅｐｉｆｕｎｒｅｇ関数は、プラグインの登録を削除する。
ｅｐｉｆｕｎｒｅｇ  −ｐ  ｉｍｐｌｉｄ  ［−ｏ  ｐｒｏｆｉｌｅＩｄ］
【０１９４】
ｅｐｉｆｕｎｒｅｇ命令は、指定されたプラグインの登録を削除する。−ｐオプションは、登録削除されるべきプラグインのインプリメンテーション識別子を指定する。もし、このオプションが単独で使用される場合、プラグイン・フレームワーク内に記憶されたプラグインのデータの登録が削除される（既存のファイルの全てに記憶されたデータを含む）。−ｏオプションは、プラグインに関する情報が指定されたプロファイルから除去されるべきことを示すために選択的に使用される。この命令は、ｅｐｉｆｒｅｇｅｄｔ命令により除去できる関連プラグイン・インターフェイスに関するデータを除去しない。
【０１９５】
ｅｐｉｆｒｅｇｅｄｔ
ｅｐｉｆｒｅｇｅｄｔ関数は、プラグイン・フレームワーク・レジストリ内に記憶されたインプリメンテーション、インターフェイス及びプロファイルの属性を編集する。
ｅｐｉｆｒｅｇｅｄｔ  ［−ｇ｜−ｓ｜−ｄ｜−ｃ｜−ｍ｜−ｋ  ｋｅｙ  ［−ａ  ＡｔｔｒＮａｍｅ［＝ＡｔｔｒＶａｌｕｅ］
ｅｐｉｆｒｅｇｅｄｔ命令は、−ｋオプションにより指定されたＰＩＦレジストリ・オブジェクトの属性を編集する。レジストリ・オブジェクトは、それらの対応キーによりレジストリ内で独特に識別される。ＰＩＦレジストリ・オブジェクトのキーは次の構文を持つ。
＜ＰｒｏｆｉｌｅＩｄ＞  ［／ｉｍｐｌ｜ｉｎｔｅｒｆａｃｅｓ／＜ＯｂｊＩｄ＞］
ここで、
＜ＰｒｏｆｉｌｅＩｄ＞は、オブジェクトがその中に登録されているプロファイルのプロファイル識別である。
ｉｍｐｌは、そのオブジェクトがインプリメンテーション・オブジェクトであることを指示する。
ｉｎｔｅｒｆａｃｅｓは、そのオブジェクトがインプリメンテーション・オブジェクトであることを指示する。
＜ＯｂｊＩｄ＞は、インターフェイス・オブジェクト識別（ｉｎｔｅｒｆａｃｅＩｄ）又はインプリメンテーション・オブジェクト識別（ＩｍｐｌＩｄ）を指定する。
【０１９６】
プラグイン・フレームワークは、指定されたインターフェイス及び／又はインプリメンテーション・オブジェクト・データについてレジストリ内の指定されたプロファイルを探索する。＜ＰｒｏｆｉｌｅＩｄ＞又は＜ＯｂｊＩｄ＞は、編集操作が全ての既存のプロファイル又はインターフェイス／インプリメンテーション識別にそれぞれ適用することを示すために、“*”として指定できる。“ＳＹＳＴＥＭ”は、デフォルト・システム全体プロファイルに対する＜Ｐｒｏｆｉｌｅ  ｉｄ＞である。
【０１９７】
−ａオプションは、指定されたオブジェクトについての操作の編集に含まれる属性を指定するために使用される。ＡｔｔｒＮａｍｅは、編集されたオブジェクトの属性の名前であり、ＡｔｔｒＶａｌｕｅは、この属性に割当てられた値である。いくつかの属性が特定の編集操作（設定、作成、又は削除など）の範囲を狭くするために使用できる。
次のオプションは、ｅｐｉｆｒｅｇｅｄｔ命令により実行される編集操作を指定する。
−ｇ  指定されたオブジェクトの選択された属性の値を得る。もし、−ａオプションにより属性が指定されない場合、オブジェクトの全ての属性が検索される。それ以外の場合、指定された属性だけが検索される。これ及び全ての他のオプションにより、もし、ＡｔｔｒＶａｌｕｅが供給されて、それが指定される場合、それはこの操作範囲を狭くするために使用される。対応するＡｔｔｒＶａｌｕｅ値により複数のＡｔｔｒＮａｍｅ属性が指定される場合、対応するＡｔｔｒＮａｍｅ属性に対して同一のＡｔｔｒＶａｌｕｅ値を持つオブジェクトのみが検索される。
−ｓ  指定されたオブジェクトの選択された属性の値を設定し、作成し、又は変更する。新しいオブジェクトがレジストリ内で生成される時、いくつかの属性が必要である。これらの属性が−ａオプションにより指定される。
−ｄ  この指定されたオブジェクトの選択された属性を削除する。もし、−ａオプションにより属性が指定されなければ、オブジェクト及び全てのその属性がレジストリから削除される。それ以外は、指定された属性のみが削除される。
−ｃ  指定されたオブジェクトを別のプロファイルへコピーする。新しいプロファイルは、ＡｔｔｒＶａｌｕｅの値として新プロファイル識別子及びＡｔｔｒＮａｍｅの値としてＰｒｏｆｉｌｅＩｄを使用して、−ａオプションにより指定される。
−ｍ  指定されたオブジェクトを別のプロファイルへ移す。新しいプロファイルは、ＡｔｔｒＶａｌｕｅの値として新プロファイル識別子及びＡｔｔｒＮａｍｅの値としてＰｒｏｆｉｌｅＩｄを使用して、−ａオプションにより指定される。もし、目標プロファイルが存在しない場合、新しいプロファイルが生成される。
【０１９８】
インプリメンテーション例
このセクションは、どのようにしてＰＩＦコンプライアント・クライアント・アプリケーション及び対応するプラグインを製作するかを示すサンプル・コードの説明を提供する。以下のファイルは、本発明をより良く説明するために説明目的のためにのみ示される。当業者には使用された手順がより複雑な状態及びアプリケーションに適用するために拡張でき、そして本発明は以下に与えられたＣ言語例に限定されないことが明らかである。
【０１９９】
プラグインは、プラグイン・ウィザード又は同様のツールを使用したメタ言語フォーマットで定義できる。メタ言語は、プラグイン操作、及びプラグイン名などの変数、インターフェイス名、及びインターフェイス・バージョン番号を定義する。
【０２００】
プラグイン記述ファイル
以下のプラグイン記述ファイル（ｄｕｍｍｙ．ｐｉ）は、プラグインを定義するために使用される記述ファイルの例である。いくつかの実施の形態では、プラグイン記述は、プラグイン・ウィザード又はプラグイン設計ツールにより生成される。少なくとも、それはプラグイン名（この場合は、“ｄｕｍｍｙ”）、インターフェイス名（“ｓｅｃ”）、及びインターフェイス・バージョン番号（“１．２”）を含む。また、プラグインは、いくつかの操作を含む（この例では、ｏｐ１、ｏｐ２、ｏｐ３、及びｏｐ４として表示される）。操作は、プラグインが呼び出しアプリケーションに現実に提供する関数を定義する。
【０２０１】
2004534304.tif 000032
【０２０２】
プラグイン・ヘッダー・ファイル
下のｄｕｍｍｙ．ｈファイルは、プラグイン・ウィザードの出力であるヘッダー・ファイル又は生成されたインクリュードの例である。ヘッダー・ファイルはコンパイル時に各プラグイン・インプレメンテーション及びクライアント・アプリケーション内に含まれなければならない。インクリュード・ファイルは、プラグインが操作する特定のインターフェイスの仕様を与える。
【０２０３】
2004534304.tif 000033
【０２０４】
この例では、インクリュード・ファイルは名前（“ｄｕｍｍｙ”）及び特定のインターフェイスとバージョン番号（この場合、１．２）に対するデータ構造を定義するデータ構造定義を含む。データ構造は、この特定のインターフェイスとバージョン番号により支援される全ての操作についてのポインタを含む。
【０２０５】
プラグイン・アプリケシーョン・ファイル
下のｄｕｍｍｙ．ｃファイルは、生成されたスケルトン・テンプレートの例であり、実際のプラグイン・アプリケーションを表す。生成された．ｈファイルからの唯一の修正は操作インプレメンテーションの各々の生成されたコメントを実際のコードで置換し、そしてプライベート・データ構造にプライベート・データ・メンバーを追加することである。コンパイルされる時、ｃファイルが実際のプラグイン・インプレメンテーションを提供するために使用される。ある動詞（例えば、ｐｉｆ破壊及びｐｉｆコピー）はインターフェイスが呼び出しアプリケーションと成功的にハンドシェイクするために必要である。他の動詞（ｏｐ１、ｏｐ２、ｏｐ３、ｏｐ４）はプラグイン・フレームワークの機能的操作を提供する。
【０２０６】
2004534304.tif 000034
2004534304.tif 000035
2004534304.tif 000036
【０２０７】
アプリケーション・ファイル
下に示されるｔｅｓｔ．ｃファイルは、プラグインをロードしその上での操作を呼び出すクライアント・アプリケーションの一例である。クライアント・アプリケーションは、必要なインターフェイス定義（ｄｕｍｍｙ．ｈ中に指定される）を呼び出すために書かれた。クライアント・アプリケーションは、指定されたプラグインにより所望のインターフェイス（ｓｅｃ）を成功的に実現しなければならない。その後、それはポインタ（ｐｉｎ）を使用してインプリメンテーション・ｖテーブル（Ｖｔｂｌ）を参照する。操作そのものはプット命令の一続きを介して呼び出される。
【０２０８】
2004534304.tif 000037
【０２０９】
クライアントは、実際のインプリメンテーションを指定する必要がない（この例では行うが）。インプリメンテーションが指定されない時、クライアントはそのインターフェイスに対するデフォルトのインプリメンテーションが与えられる。
【０２１０】
関数設計仕様
このセクションでは、（ａ）インプリメンテーション継承及び（ｂ）インプリメンテーション継承無しの両方の場合を支援するインターフェイス・プロセスの関数毎の実現のための設計例が提示される。設計例は、エンジンの全ての実施の形態では要件ではないが、インターフェイス継承を支援する。この特定の設計の重要な観点は以下の通りである。
クライアントは、Ｃストラクトとして実現されたインターフェイスが提供される。そのメンバー変数は、インターフェイスをバッキングするインプリメンテーションが単一のインプリメンテーションか又は導出されたインプリメンテーションかに関係なく、そのインターフェイスの関数シグニチャーを実現するインプリメンテーションの関数へのポインタである。クライアントは、実現されたインターフェイスがオリジナルなインターフェイスか又は合成又は継承されたインターフェイスであるかどうかを知らない。その代わり、それを単一のインターフェイスとして見る。
【０２１１】
インターフェイス・メソッド呼び出しは、インターフェイス・ポインタを第１引数としてプラグイン・インスタンスへ送る。
【０２１２】
インプリメンテーション・メソッドは、ＰＩＦにより与えられた＿ｅ＿ｐｉｆ＿ｔｈｉｓ（）関数を呼び出すことによりプライベート・データをインスタンス毎にアクセスすることができる。
【０２１３】
図１２に、この特定の設計の実施の形態の実現及びインプリメンテーション・プロセスが示されている。図１２に示すように、プロセスは、実現フェーズ、インターセプタ・フェーズ、ロード及びアンロード・フェーズ、及び再審フェーズを含む。これらは以下に詳細に説明される。
【０２１４】
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ（）３９０
＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅ関数３９０は、相互排除ロック・ルーチン（ミューテクス）を初期化するために、ｐｉｆ＿ｉｎｉｔを呼び出す。ミューテクスは、相互排除のポリシーを実施する抽象的な構造である。伝統的に、一時に１つだけのプロセス・スレッドが特定のミューテクスを保持でき、そして保持されたミューテクスをロックしようとするスレッドはミューテクスのロックがはずされるまでブロックする。ミューテクスは、それらが入った順番とは逆に出なければならず、そして出る前に再入場はできない。
【０２１５】
もし、レジストリ・プラグインが既に実現されていなければ、プロセスはそれを実現しようとする。レジストリ・プラグインのこのインスタンスは、性能の利点のためにキャシュすることができる。活動的なプラグインのカウントが新プラグインを反映するために増分され、そしてミューテクスのロックがはずされる。
【０２１６】
プロセスは、フレームワークが何時必要でなくなるかを知らないため、それは与えられた時間においてどれだけのプラグイン・インスタンスが活動的であるかを追跡する。このカウントがゼロになる時に、キャシュされたレジストリ・プラグインが解放される。最適化のためにキャシュを使用することは、少なくとも１つの活動的なプラグイン・インスタンスが存在する際に他のプラグインが実現されている時にのみ有用である。もし、設計モデルが一時に唯１つのプラグインが活動的であるような場合、レジストリ・プラグインが各時に実現されて解放される。レジストリ・プラグインをキャシュする副作用は、使用されている下にあるレジストリがレジストリが閉じられそして再び開かれるまでレジストリ変化を見ないことである。
【０２１７】
そして、プロセスが、ｒｅａｌｉｚｅ＿ｆｒｏｎｔｅｎｄ関数３９２を呼び出す。もし、これが成功しなければ、ミューテクスがロックされて、活動的プラグイン・カウントが減少される。もし、活動的カウントがゼロになると、レジストリ・プラグインが解放されて、そしてミューテクスのロックがはずされる。
【０２１８】
ｒｅａｌｉｚｅ＿ｆｒｏｎｔｅｎｄ（）３９２
プロセスは、ｒｅａｌｉｚｅ＿ｆｒｏｎｔｅｎｄ関数３９２に続く。これは、最初のステップとして、供給された引数を使用してＰＩＦ＿ＲＡＲＧＳスタックを構築し、そしてｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌ３９４を呼び出す。もし、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌが一人っ子プラグイン値を見つけると、対応する一人っ子が戻される。もし、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌがスタック・インターセプタを見つけると、スタック中の最初のプラグインのハンドル又はポインタが戻される。もし、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌが成功以外のものを戻すと、エラーが戻される。もし、上記基準のいずれも満足されない場合、プラグインがそのコンポーネントから構築される。ｒｅａｌｉｚｅ＿ｆｒｏｎｔｅｎｄ関数は、各インプリメンテーションを通じてループし、そしてメジャー・バージョン番号を確証する。同時に、最高のマイナー・バージョン番号及び最大のＶｔｂｌサイズの両方を探す。
【０２１９】
確証ステップは、最高のマイナー・バージョン番号が要求されたものと等しいか又は大きいことを保証する。必要とされるメモリのブロックの大きさが計算されて割当てられる。メモリの１つのブロックが、可変サイズのＰＩＦ＿ＣＯＮＴＲＯＬブロック、プロキシＶｔｂｌ、ファンアウト・インターセプト配列、及びｉｎｆｏ＿ｐｕｂｌｉｃポインタの配列に対して割当てられる。
【０２２０】
ＰＩＦ＿ＣＯＮＴＲＯＬブロックが、各インプリメンテーションのＶｔｂｌを通じてループすることによりプロキシＶｔｂｌが満たされるように満たされ、そしてＶｔｂｌからの非ニル・エントリによりプロキシＶｔｂｌの空のエントリを満たす。
【０２２１】
満たされたプロキシＶｔｂｌは、空のエントリを検査し、そして、もし、見つかれば、資源無しエラーが戻される。
【０２２２】
ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌ（）３９４
追加の引数の１つが、ローカルとして宣言されたＰＩＦ＿ＰＩＮＦＯデータ構造の配列である。この配列は、実現プロセスがどれだけの大きさのダイナミック・メモリの部分を割当てるべきかを知るために完全なプラグインを構成する全てのインプリメンテーションが最初に具体化できるように使用される。これは、インプリメンテーション継承の深さ及び完全なプラグインを構成する全てのインプリメンテーション中のＶｔｂｌの最大の大きさの両方に依存する。この配列はプロセスがインプリメンテーション継承の実際の深さを知る前に割当てられるため、フレームワークは許されるインプリメンテーション継承の最大の深さについてインプリメンテーション制限を課すであろう。もし、実現プロセス中にこの制限に到達した場合、プロセスが失敗して戻される。
【０２２３】
もし、インプレメンテーション識別子が指定されない場合、レジストリの最初の読出しが指定されたインターフェイス識別子とインターフェイスのメジャー・バージョン番号を使用して、ＧｅｔＩｎｔｆ４００を呼び出す。もし、ＤｅｆａｕｌｔＩｍｐｌ属性が非ニルならば、それがインプリメンテーション識別子として使用される。
【０２２４】
もし、インプレメンテーション識別子が指定されず、そして上述したＤｅｆａｕｌｔＩｍｐｌ属性がニルの場合、ＨｉｇｈｅｓｔＭｉｎｏｒＩｍｐｌ属性が見られる。
【０２２５】
もし、インプレメンテーション識別子が指定されるか又は上記ステップから決定される場合、次のステップは識別子がセレクタか又は別名かをＧｅｔＡｌｉａｓ４００を呼び出すことにより検査する。もし、一致が見つからなければ、インプレメンテーション識別子は別名ではない。もし、一致が見つかると、別名として知られているものが属性名として使用されて、その値がレジストリから読み出される。そして、この属性の値がインプリメンテーション識別子として使用されるが、別名が別の別名にマップされているかを見るために最初に反復的に検査される。
【０２２６】
インターフェイス識別子引数及び結果として得られたインプリメンテーション識別子を使用して、既に実現されている（そして、まだ解放されていない）一人っ子プラグインのリストは、その最大に導出されたインプリメンテーションの情報構造が適当なｍ＿ｉｎｔｅｒｆａｃｅ＿ｉｄ及びｍ＿ｉｍｐｌ＿ｉｄフィールドを持つものを見つけるため検査される。もし、一致が見つかると、＿ｐｅ＿ｐｆ＿ｄｕｐｒｅｆが一致したプラグインについて呼び出され、そして新ポインタが戻される。インプリメンテーションが基本インプリメンテーションとして具体化されている時、既存の一致した一人っ子に対する探索は行われない。
【０２２７】
結果として得られるインプリメンテーション識別子を使用して、ＧｅｔＩｍｐｌ４００が呼び出される。もし、インプリメンテーションが存在しない場合、エラーが戻される。もし、使用された識別子が呼び出したものにより元から指定されたものでない場合は、プロセスは呼び出したものがインプリメンテーション識別子をあたかも指定しなかったように上から開始する。
【０２２８】
次に、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌは、インターセプション・タイプ属性を検査する。もし、この属性が「非インターセプター」以外のものを示す場合、インターセプターの実現を処理する内部ルーチンを呼び出す。もし、実現されているインプレメンテーションがスタック・インターセプション・シーケンス中に指定されているものであった場合は、このステップは飛ばされる。
【０２２９】
もし、インターセプション・タイプ属性が設定される場合、プロセスはｒｅａｌｉｚｅ＿ｉｎｔｅｒｃｅｐｔｏｒ４０２を呼び出す。
【０２３０】
もし、インターセプション・タイプ属性がスタックの場合、ポインタがまた次のスタック・メンバーに設定される。
【０２３１】
＿ｅ＿ｄｌ＿ｌｏａｄ関数が、イメージパス属性又はｉｍｐｌＩｄを使用して呼び出される。
【０２３２】
＿ｅ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ関数３９８が、ＥｎｔｒｙＦｕｎｃ属性又はデフォルト“＿ｅｐ＿ｄｌ＿ｉｎｓｔａｎｔｉａｔｅ”を使用して呼び出される。そして、プラグインの＿ｅｐ＿ｄｌ＿ｉｎｓｔａｎｔｉａｔｅ関数が呼び出される。
【０２３３】
適当なｉｎｆｏ＿ｐｕｂｌｉｃ構造（ＰＩＦ＿ＰＩＮＦＯストラクト中のｍ＿ｐｉｎｆｏ）が、対応するインプリメンテーション・プライベート情報構造から初期化される。
【０２３４】
＿ｅ＿ｄｌ＿ｕｎｌｏａｄ（）４０４
イメージパス属性の値が、＿ｇｐ＿ｄｌ＿ｌｏａｄへ送られる。そして、プラグインの具体化ルーチンのアドレスを得るためにＥｎｔｒｙＦｕｎｃ属性の値が、＿ｇｐ＿ｄｌ＿ｇｅｔｆｕｎｃａｄｄｒ３９８へ送られる。具体化ルーチンは、＿ｐｅ＿ｐｆ＿ｒｅａｌｉｚｅに送られたもの及び内部で生成されたものから生ずる適当な引数でもって呼び出される。
【０２３５】
ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌは、継承フロム属性を検査する。もし、この属性が存在すると、それは前記属性の値を用いて反復的にｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌを呼び出す。フレームワークにより実現される時、継承フロム属性中で指定されたインプリメンテーション識別子は、あたかも、ＥＦ＿ＰＦ＿ＥＸＡＣＴ＿ＭＡＴＣＨフラグが指定されたかのように実現される。
【０２３６】
制御がｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌから、＿ｐｅ＿ｐｆ＿ｒｅａｌｉｚｅへ戻されると、必要なプロキシＶｔｂｌの大きさが決定され、そして継承の深さが知られる。
【０２３７】
この時、システムは、呼び出したものにより要求された少なくとも最小のマイナー・バージョン番号を実現する完全なプラグインを構成する少なくとも１つのインプリメンテーションが存在することを確認するために検査できる。この検査は、各インプリメンテーションの＿ｅ＿ｐｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏデータ構造を見ることにより行われる。もし、この検査が失敗すると、バージョン不一致エラーが戻される。
【０２３８】
ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造を今、割当てることができる。ＰＩＦ＿ＰＩＮＦＯデータ構造のスタック・ローカル配列が、ｍ＿ｐｉフィールドへコピーされる。
【０２３９】
プロキシＶｔｂｌも今、満たされる。最大の導出インプリメンテーションから開始して、最小の導出インプリメンテーションで終了する、以下のことが行われる。プロキシＶｔｂｌ中に同じオフセットでニル・ポインタが存在するインプリメンテーション静的Ｖｔｂｌ中の各非ニル・エントリについて、インプリメンテーション静的ＶｔｂｌからのポインタがプロキシＶｔｂｌへコピーされる。
【０２４０】
ニル・ポインタがないことを確認するために、プロキシＶｔｂｌが検査される。もし、いずれかが見つかると、全てが解放されて、エラーが戻される。
【０２４１】
ＰＩＦ＿ＣＯＮＴＲＯＬ構造のｍ＿ｐｉフィールドの各メンバーのｍ＿ｐｕｂｌｉｃｉｎｆｏフィールドは、各対応するインプリメンテーションのプライベート“ｉｎｆｏ”構造からの対応するフィールドを単にコピーすることにより、初期化できる。ＰＩＦ＿ＣＯＮＴＲＯＬ構造のｍ＿ｐｕｂｌｉｃｉｎｆｏフィールドにより指示されたポインタのベクトルは、ＰＩＦ＿ＰＩＮＦＯ構造（ｍ＿ｐｉ）の配列中の適当なｍ＿ｐｕｂｌｉｃｉｎｆｏフィールドを指示するために初期化される。
【０２４２】
各インプリメンテーションの情報データ構造は、ｍ＿ｓｉｎｇｌｅｔｏｎフラグが設定されているかどうかを見るため検査される。もし、各インプリメンテーションがこのフラグを設定している場合、ＰＩＦ＿ＣＯＮＴＲＯＬ構造中のＰＩＦ＿ＳＩＮＧＬＥＴＯＮフラグが設定される。もし、このフラグが設定されると、ＰＩＦ＿ＣＯＮＴＲＯＬ構造が、ｍ＿ｎｅｘｔＳｉｎｇｌｅｔｏｎポインタを使用して一人っ子プラグインのリンクされたリストへ接続される。
【０２４３】
ｒｅａｌｉｚｅ＿ｉｎｔｅｒｃｅｐｔｏｒ（）４０２
クライアント又は呼び出しアプリケーション（呼び出すもの）は、ｒｄｅｐｔｈ＋１とＥＸＡＣＴ＿ＭＡＴＣＨとＩＧＮＯＲＥ＿ＩＳＥＱフラグを用いてシーケンス中の各ｉｍｐｌＩｄについてｒｅａｌｉｚｅ＿ｆｒｏｎｔｅｎｄへの呼び出しを行う。
【０２４４】
戻されたポインタｉｐは、ＰＩＦ＿ＲＡＲＧＳ構造中に記憶される。もし、それがファンアウト・インターセプション・タイプである場合、ｆａｎｏｕｔＬｅｎ（ＰＩＦ＿ＲＡＲＧＳ）がシーケンス長に設定される。両インターセプション・タイプについて、フレームワークにより実現される時、インターセプションＳｅｑ属性中で指定されたインプリメンテーション識別子が、あたかもＥＦ＿ＰＦ＿ＥＸＡＣＴ＿ＭＡＴＣＨフラグが指定されたかのように、実現される。
【０２４５】
インターセプターのファンアウト・タイプについて、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌ関数が、シーケンスからの対応する１つにより置換されたインプリメンテーション識別子引数を除いて、＿ｐｅ＿ｐｆ＿ｒｅａｌｉｚｅへの元の呼び出しと同じ引数を用いてＮ回呼び出される。Ｎは、シーケンス中のインプリメンテーション識別子の数である。そして、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌ関数が再び呼び出される。この時には実現されたインターセプトするプラグインへのポインタのシーケンスを持つ。
【０２４６】
インターセプターのスタック・タイプについて、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌ関数が、＿ｐｅ＿ｐｆ＿ｒｅａｌｉｚｅへの元の呼び出しと同じ引数を用いて、Ｎ回呼び出される。この時、インプリメンテーション識別子のシーケンスは後方向へ移動される。さらに、最初を除いて、ｒｅａｌｉｚｅ＿ｉｎｔｅｒｎａｌへの各呼び出しについて、実現された最後のインターセプトするプラグインへの単一のポインタが渡される。もし、インターセプター・シーケンスを定義したレジストリ・キーについてイメージパス・レジストリ属性が存在する場合、そのキーはあたかもそれがスタックされたインターセプション・シーケンス中の最初のプラグインのように扱われる。
【０２４７】
＿ｅ＿ｐｉｆ＿ｄｕｐｒｅｆ（）４０６
深くないコピーの場合、ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造中に記憶された基準カウントは単に増分されて、同じポインタが戻される。
【０２４８】
深いコピーの場合、以下が行われる。新ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造が割当てられる。
【０２４９】
もし、ＰＩＦ＿ＳＴＡＣＫＩフラグが設定される場合、＿ｐｅ＿ｐｆ＿ｄｕｐｒｅｆ４０６がスタック中の次のプラグインについて呼び出される。戻された新ポインタが、割当てられた新ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造のｍ＿ｉｎｔｅｒｃｅｐｔｏｒｓフィールド中に記憶される。新スタック中の次のプラグインへのポインタが現在のプラグインに対するいずれのインプリメンテーションのためのいずれのコピー・ルーチンが呼び出される前に必要となるために、再帰が最初に行われる。
【０２５０】
もし、ＰＩＦ＿ＦＡＮＯＵＴＩフラグが設定される場合、＿ｅ＿ｐｆ＿ｄｕｐｒｅｆ４０６がファンアウト・インターセプション・シーケンス中の各プラグインについて呼び出され、そして戻されたポインタが新ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造の対応するフィールド中に記憶される。新シーケンスが現在のプラグインに対するいずれのインプリメンテーションのためのいずれのコピー・ルーチンが呼び出される前に必要となるために、この再帰が最初に行われる。
【０２５１】
新ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造が、元のＰＩＦ＿ＣＯＮＴＲＯＬデータ構造から満たされ、そして、新ＰＩＦ＿ＣＯＮＴＲＯＬの基準カウントが１に設定される。新ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造を使用して、プラグインのコピー・ルーチン（その＿ｅ＿ｐｆ＿ｐｌｕｇｉｎ＿ｉｎｆｏデータ構造により指示された）が呼び出される。インプリメンテーション継承の場合、継承リスト中の各プラグインは呼び出されたそのコピー・ルーチンを持つ。
【０２５２】
＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ（）３９６
ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造中の基準カウントが減少され、そして、もし、減少後のカウントがゼロより大きい場合、それは単に戻される。
【０２５３】
基準カウントがゼロになる時に行われる最初のことは、資源を解放するためにプラグイン破壊ルーチンを呼び出すことである。インプリメンテーション継承の場合、最大導出インプリメンテーションの破壊ルーチンが最初に呼び出される。
【０２５４】
もし、解放されているプラグインがスタックされたインターセプター・チェーンの一部である場合、＿ｐｅ＿ｐｆ＿ｒｅｌｅａｓｅがチェーンの次のプラグインについて再び呼び出される。
【０２５５】
もし、解放されているプラグインがファンアウト・プラグインである場合、対応するインターセプテイング・プラグインの各々が解放される。
【０２５６】
もし、ＰＩＦ＿ＣＯＮＴＲＯＬデータ構造中にＰＩＦ＿ＳＩＮＧＬＥＴＯＮフラグが設定されている場合、実現された一人っ子プラグインのリンクされたリストがそのリスト上にこのプラグインがあるかどうかを検査される。もし、あれば、それはそのリストから除去される。
【０２５７】
最後に、ダイナミック・ライブラリイ・ハンドルがアンロードされ４０４、そしてＰＩＦ＿ＣＯＮＴＲＯＬデータ構造が自由になる。
【０２５８】
活動的なプラグインのカウントがゼロになる時、キャシュされたレジストリ・プラグイン参照が解放される。
【０２５９】
もし、解放フラグが設定されている場合、＿ｅ＿ｐｉｆ＿ｒｅｌｅａｓｅ関数が次のスタック・インターセプタについて呼び出され（もし、あるならば）、そしてファンアウト・インターセプテイング・プラグインについて呼び出される。
【０２６０】
＿ｅ＿ｐｉｆ＿ｔｈｉｓ（）
そして、プロセスはＰＩＦ＿ＣＯＮＴＲＯＬ中のＰＩＦ＿ＰＩＮＦＯの配列を介して索引して、ｐＶｔｂｌインスタンス・ハンドルがキー中の渡されたものと一致するものを探す。もし、一致が見つかると、対応するｐＰｒｉｖＤａｔａポインタが戻される。
【０２６１】
＿ｅ＿ｐｉｆ＿ｉｎｔｅｒｃｅｐｔｉｏｎ＿ｓｅｑ（）
ＰＩＦ＿ＣＯＮＴＲＯＬ中のｍ＿ｉｎｔｅｒｃｅｐｔｏｒｓフィールドへのポインタが戻される。
【０２６２】
＿ｅ＿ｐｉｆ＿ｇｅｔｉｎｆｏ（）
ＰＩＦ＿ＣＯＮＴＲＯＬからパブリック情報ポインタの配列への長さとポインタが戻される。
【０２６３】
当業者には明らかなように、ここに説明されたいくつかの関数とルーチンはある規則に従う制約と特徴と特性を有することが示されたが、本発明を実施するためにこれらの規則の一部又は全部は従う必要がない。そして、与えられた例は本発明の実施の形態を説明する目的のためである。
【０２６４】
開発例
図１３は、典型的なクライアント／サーバー環境内で本発明を配備する方法の一例のフローチャートを示す。ステップ３７０に示すように、サービスの組がサーバーにより提供される各インターフェイスに対して開発者又は管理者により指定される。ステップ３７２において、各インターフェイスに対してインプリメンテーションがそのインターフェイスの特定サービスの必要を解決するために開発される。ステップ３７４において、他の開発者及び第三者ベンダーなどの異なるエンテイテイがそのインターフェイスに対して異なるインプリメンテーションを開発し、各インプリメンテーションは異なる特徴組を持つ。ステップ３７６において、呼び出しアプリケーション又はクライアントはサーバー・エンジンにアクセスし、そして特定のインプリメンテーション・タイプを要求する。ステップ３７８において、クライアントは所望のインターフェイスを実現するため、＿ｅ＿ｐｉｆ＿ｒｅａｌｉｚｅの呼び出しを行う。このプロセスにおいて、インターフェイス独特識別子が生成されてクライアントへ与えられる。そして、クライアントはこのインプリメンテーション・タイプに対してデフォルト・インプリメンテーション・プラグイン又は代替的インプリメンテーション・プラグイン（例えば、クライアントは特別に「代替的バージョン」と名付けられたインプリメンテーション要求することができる）のいずれかを選択することができる（３８０、その構成に依存して）。クライアントが将来の使用のためにクライアント・アプリケーション中に記憶できるいくつかの場合ではトークン又はクッキーの形式のハンドルをクライアントは受け取る（３８２）。ハンドルは、インプリメンテーションが入っているｖテーブル・データ空間内へのポインタとして使用され、そしてサービス・インプリメンテーションそのものへのポインタとして使用される。
【０２６５】
上述された本発明の好適な実施の形態は、説明目的のために提供された。本発明を開示された正確な形に限定する意図も網羅的であることも意図していない。当業者には多くの修正と変形が明らかである。実施の形態は、本発明の原理とその実際的な応用を最良に説明し、それにより当業者が考える特定の用途に適したさまざまの修正を持つさまざまな実施の形態を理解できるようにするために選ばれて記述された。本発明の範囲は特許請求の範囲の記載とその均等物により定義されるべきことを意図している。
【図面の簡単な説明】
【０２６６】
【図１】従来技術のサーバー構成プロセスを示す図。
【図２】本発明の１つの実施の形態によるエンジンの配置を示すフレームワーク・システム・アーキテクチャの概略図。
【図３】本発明の１つの実施の形態によるコンポーネント・インターフェイスの概略図。
【図４】本発明の１つの実施の形態によるエンジン・プラグイン・フレームワークの概略図。
【図５】本発明の１つの実施の形態によるインターフェイス実現のフローチャート。
【図６】本発明の１つの実施の形態によるプラグイン実現の概略図。
【図７】本発明の１つの実施の形態による導出されたプラグイン又はインプリメンテーション継承の概略図。
【図８】本発明の１つの実施の形態によるフアン・アウト・タイプのインターセプションの概略図。
【図９】本発明の１つの実施の形態によるスタック・タイプのインターセプションの概略図。
【図１０】本発明の１つの実施の形態によるフアン・アウト・インプリメンテーションを持つインターフェイスの実現の概略図。
【図１１】本発明の１つの実施の形態によるスタック・インプリメンテーションを持つインターフェイスの実現の概略図。
【図１２】本発明の１つの実施の形態による実現プロセスのフロー図。
【図１３】本発明の１つの実施の形態によるインターフェイス仕様プロセスのフローチャート。
【図１】
2004534304.tif 000038
【図２】
2004534304.tif 000039
【図３】
2004534304.tif 000040
【図４】
2004534304.tif 000041
【図５】
2004534304.tif 000042
【図６】
2004534304.tif 000043
【図７】
2004534304.tif 000044
【図８】
2004534304.tif 000045
【図９】
2004534304.tif 000046
【図１０】
2004534304.tif 000047
【図１１】
2004534304.tif 000048
【図１３】
2004534304.tif 000049
【国際公開パンフレット】
2004534304.tif 000050
2004534304.tif 000051
2004534304.tif 000052
2004534304.tif 000053
2004534304.tif 000054
2004534304.tif 000055
2004534304.tif 000056
2004534304.tif 000057
2004534304.tif 000058
2004534304.tif 000059
2004534304.tif 000060
2004534304.tif 000061
2004534304.tif 000062
2004534304.tif 000063
2004534304.tif 000064
2004534304.tif 000065
2004534304.tif 000066
2004534304.tif 000067
2004534304.tif 000068
2004534304.tif 000069
2004534304.tif 000070
2004534304.tif 000071
2004534304.tif 000072
2004534304.tif 000073
2004534304.tif 000074
2004534304.tif 000075
2004534304.tif 000076
2004534304.tif 000077
2004534304.tif 000078
2004534304.tif 000079
2004534304.tif 000080
2004534304.tif 000081
2004534304.tif 000082
2004534304.tif 000083
2004534304.tif 000084
2004534304.tif 000085
2004534304.tif 000086
2004534304.tif 000087
2004534304.tif 000088
2004534304.tif 000089
2004534304.tif 000090
2004534304.tif 000091
2004534304.tif 000092
2004534304.tif 000093
2004534304.tif 000094
2004534304.tif 000095
2004534304.tif 000096
2004534304.tif 000097
2004534304.tif 000098
2004534304.tif 000099
2004534304.tif 000100
2004534304.tif 000101
2004534304.tif 000102
2004534304.tif 000103
2004534304.tif 000104
2004534304.tif 000105
2004534304.tif 000106
2004534304.tif 000107
2004534304.tif 000108
2004534304.tif 000109
2004534304.tif 000110
2004534304.tif 000111
2004534304.tif 000112
2004534304.tif 000113
2004534304.tif 000114
2004534304.tif 000115
2004534304.tif 000116
2004534304.tif 000117
2004534304.tif 000118
2004534304.tif 000119
2004534304.tif 000120
2004534304.tif 000121
2004534304.tif 000122
2004534304.tif 000123
2004534304.tif 000124
2004534304.tif 000125
2004534304.tif 000126
2004534304.tif 000127
2004534304.tif 000128
2004534304.tif 000129
2004534304.tif 000130
2004534304.tif 000131
2004534304.tif 000132
2004534304.tif 000133
2004534304.tif 000134
2004534304.tif 000135
2004534304.tif 000136
2004534304.tif 000137
2004534304.tif 000138
2004534304.tif 000139
2004534304.tif 000140
【国際調査報告】
2004534304.tif 000141