JPH09507318A

JPH09507318A - オブジェクト指向システムにおけるサービスの作成

Info

Publication number: JPH09507318A
Application number: JP7517393A
Authority: JP
Inventors: アンダート，グレン，ピー．; ノーマン，ジョージ，ダブリュ．
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1993-12-21
Filing date: 1994-05-17
Publication date: 1997-07-22
Also published as: CA2169639A1; DE69402875D1; US6564270B1; AU7311494A; EP0714533B1; US5864668A; US5548779A; EP0714533A1; WO1995017720A1

Abstract

(57)【要約】オブジェクト指向システムにおけるサービスの作成が開示され、具体的には、オブジェクト指向システムにおいてサービスを提供する方法およびシステムが開示されている。方法およびシステムは、リクエストに応答してサービスを作成するオブジェクトのインタフェース参照フレームワーク(interface reference framework)の形体になっている。クライアントはリクエストに応答して作成されるサービスを要求する。リクエストに応答して、フレームワークは、まず、サービス記述を作成する。この記述はサービス記述のスタックの形体になっている。スタック記述から、実際のサービスはメーカ・オブジェクト(maker object)によって作成される。

Description

【発明の詳細な説明】オブジェクト指向システムにおけるサービスの作成著作権表記本出願には、一部に著作権保護の対象となる内容が含まれている。何人が、特許文書または特許開示内容を、米国特許商標局の特許ファイルまたは記録の通りに複写複製しても、著作権所有者はそれを妨げるものではないが、そうでない場合には、一切の著作権を留保する。技術分野本発明は、コンピュータ・システムにおける改良に関し、特に、オブジェクト指向オペレーティング・システムでサービスを作成するシステムおよび方法に関する。背景技術コンピュータ・システムは一般に非常に融通がきかない。情報が支障なく流れるシステムを提供するため、システムのアプリケーション開発者およびユーザは、ハードウェアのプロトコルとコンフィグレーションの詳細を熟知していなければならないことがしばしばある。ポートおよびＩ／Ｏデバイスの特定のタイプの詳細を、個別に、取り扱わなければならない。アプリケーション開発者およびユーザも、コンピュータ・システムの変化に遅れをとらないようにしなければならない。これは、コンピュータ・システムの変化をソフトウェアとハードウェアに反映させて、その変化をフルに活用できるようにするためにである。入出力デバイスの変化の度合は、情報を入出力デバイスとの間で転送するために用いられる中間要素の変化の度合と同様に、非常に速い。システムのユーザはシステムを適正にパフォームさせることができるように、変化があるごとに、学習プロセスが必要である。コンピュータ・システムは、パフォームされるサービスを必要とするクライアントの大きな集まりと考えることができる。クライアントは、仮想的には、何かを必要とすることができるシステムの任意の部分と考えることができる。例えば、ＣＰＵは、システム内の特定の要素によりパフォームされるサービスを必要とするクライアントと考えることができる。サービスの性能には、要求されたサービスを提供するため、多くのステップと、多くの要素とを含めることができる。サービスは、システム内の別のエンティティが必要とする、なにかを提供するものと考えることができる。例えば、特定のチップは、特定のタイプのディジタル信号処理を、サービスとして、もう１つのシステム要素に提供することができる。単一要素は、クライアントとなることもできるし、サービスをクライアントに提供することもできる。サービス要求と、サービス提供と、円滑なプロセスとを要求するには、クライアントとサービスの相互作用を、開発者とユーザが、しばしば、充分に配慮する必要がある。サービス要求とサービス提供に対するプロトコルは、しばしば、非常に柔軟性に欠けるため、プロトコルを変更するには、細部にまでも介入する必要がある。多くの点で、サービス要求とサービス提供は石に填込まれていると考えることができる。そのため、サービスを要求し、サービスを提供するには、柔軟性のあるシステムを提供する必要がある。この柔軟性のあるシステムは、関係する詳細のレベルに関する上記困難性を解消し、システム変化に関連する問題を解決し、クライアントとサービス・プロバイダとの間のソフトウェアとハードウェアの全体的な硬直性を解消する必要がある。発明の開示以上に鑑みて、本発明の第１の目的は、クライアントとサービスとの間の対話を改善するシステムと方法を提供するにある。本発明の第２の目的は、クライアントとサービス・プロバイダのシステムの変化をより柔軟に調整するシステムと方法を提供することにある。本発明の第３の目的は、リクエストされたサービスの詳細を配慮することなく、サービスのリクエストを行うことができるシステムと方法を提供することにある。本発明の第４の目的は、サービス・プロバイダの詳細に配慮することなく、サービスのリクエストを行うことができるシステムと方法を提供することにある。上記の目的およびその他の目的は、リクエストに応答してサービスを作成するインタフェース・フレームワークにより達成される。システムはインタフェース参照(interface reference)を受け取り、この受け取った参照から、以前に存在しないサービスを作成する。インタフェース参照はインタフェース・メーカ(int erface maker)を作成する。このインタフェース・メーカにより、リクエストされたサービスが実際に作成され、活動化される。サービスの活動化は２ステップのプロセスと考えることができる。この２ステップのプロセスでは、サービス・スタック記述が作成され、この作成されたサービス・スタック記述から、サービス・スタックが作成される。インタフェース参照とは、あるサービスを作成するのに必要な全ての情報をカプセル化するエンティティである。クライアントはインタフェース参照を有し、そのインタフェース参照を活動化して、必要とされるサービスを作成する。インタフェース参照は、最初に、サービス・スタックのトップ（最上部）とボトム（最下部）を構成するサービス・インタフェースを判断して、サービス・スタック記述を作成し、ついで、探索して、トップ・インタフェースとボトム・インタフェースの間のサービスの集合を見つけ出す。これらのサービスの集合は、リクエストされたサービス・スタックを構成することになる。インタフェース・メーカはサービス・スタック・フレームワークからのサービス・プロバイダ・クラスを「バッファリング」する目的をサーブする。サービス・スタック記述から、そのサービス・スタック記述に対応するインタフェース・メーカが作成される。このインタフェース・メーカの作成はこのサービス・スタック記述の下から上に向かって行われる。このサービス・スタック記述はインタフェース・メーカに対する参照のリストと考えることができる。図面の簡単な説明図１は本発明に係るコンピュータの典型的なハードウェア構成を示す図である。図２はインタフェース参照を用いるクライアントを示す図である。図３はドラッグ・アンド・ドロップ・オペレーションを示す図である。図４はプリンタとシリアル・データ転送に関係付けをしたサービス・スタックを示す図である。図５はプリンタとパラレル・データ転送に関係付けをしたサービス・スタックを示す図である。図６はプリンタに対するサービス間の関係を示すBooch 図である。図７はオペレーティング・システムとハードウェアとの間のインタフェースとしてアクトする本発明に係るパーソナリティ・ニュートラル層(personality neu tral layer)の概念を示すブロック図である。図８はインタフェース参照のオペレーションを示す概要図である。図９はinterface reference クラスを示す図である。図１０は可能なサービス・スタック構成を示すブロック図である。図１１はinterface maker クラスを示す図である。図１２はサービス・メーカ間の制約を階層的に示す図である。図１３はサービスの階層の自由度を示す図である。図１４はTInterfaceBundleクラスを示す図である。図１５はTHardwareInterfaceReference のハードウェア構成を示す図である。図１６はサービス・メーカ・エンティティ（つまり、これらはTServiceMakerL ocator プロパティの探索から見付け出されることになるエンティティである）の架空の「プール」を示す図である。図１７はTHardwareReferenceオブジェクトによるスタック作成を示す図である。図１８は図１７の要素の一部の種々のクラスの関係を示す図である。図１９はTHardwareInterfaceReference を活動化するためのスタック記述の作成を示す図である。図２０はTHardwareInterfaceReferenceのスタック作成の全体的なオペレーションを示す図である。図２１、図２２および図２３は、ともに、 THardwareInterfaceReferenceによるサービス・スタック作成を、ビジュアル設計言語で示す図である。図２４はマウスに対するスタック記述を作成するためのハードウェア構成を示す概要図である。図２５は THardwareInterfaceReferenceオブジェクトに対する計算されたスタック「記述」を示す図である。図２６はスイッチ・ボックスによりシリアル・ポートに対するスタック記述を作成するためのハードウェア構成を示す概要図である。図２７はＳＣＳＩスタック記述を作成するためのハードウェア構成を示す概要図である。図２８はTHardwareInterfaceReferenceをImageWriterII に対するプリンタ・フレームワークによりどのように用いることができるかを例示する図である。図２９はmaker クラスを示す図である。図３０はservice クラスを示す図である。図３１はTPresentableViews の階層を示す図である。図３２は共通クラス階層が回避されなかった場合のサービスのクラス階層を示す図である。図３３と図３４は共にメーカの展開を示す図である。発明の詳細な説明以下、本発明の実施の形態を詳細に説明する。当然、以下に説明する実施の形態は本発明の単なる例示に過ぎず、種々の態様をとることができる。従って、以下に開示する詳細な説明は、それに限定されるものではなく、単に、請求の範囲の基礎にすぎず、しかも、本発明を製造および／または使用する方法を当業者に教示する基礎に過ぎない。文献には、ＯＯＰ(object-oriented programming)の歴史が紹介され、フレームワークの開発が開示されている。Ｃ++とSmalltalk は、文献に詳しいので、ここでは、説明しない。同様に、オブジェクトの特性、例えば、カプセル化と、多態性(polymorphism)と、継承のような特性は、文献や特許明細書に、長々と論じられている。オブジェクト指向システムの優れた概説書として、"Object Orient ed Design With Applications"by Grady Booch を参照されたい。多くのオブジェクト指向システムは、基本的な入出力をパフォームする基本的なオペレーティング・システムのトップに対してオペレートするように設計されており、本発明に係るシステムは、特定の機構（フィーチャ）をシステム・レベルでサポートするのに用いられる。なお、忘れてならないことは、処理階層の異なるレベルでオブジェクトをサポートするため、ここに開示されている新規なオブジェクトも、そのシステム・レベルより上位の層に出現させるができる。本発明は、ＩＢＭ（登録商標）PS/2（登録商標）またはApple(登録商標)Macin tosh(登録商標)コンピュータのようなパーソナル・コンピュータに駐在するオペレーティング・システムのコンテキストで実施されるのが好ましい。図１は代表的なハードウェア環境を示し、本発明に係るコンピュータの典型的なハードウェア構成を示す。このハードウェア構成は、ＣＰＵ(central processing unit)１０、例えば、慣用のマイクロプロセッサを有し、システム・バス１２により相互結合された複数の他のユニットを有する。図１に示すコンピュータには、ＲＯＭ (read only memory)１６と、ＲＡＭ(random access memory)１４とが含まれる。また、このコンピュータには、周辺デバイス、例えば、ディスク・ユニット２０と、２１で示す他のＩ／Ｏ周辺装置のような周辺デバイスをシステムバス１２に接続するためのＩ／Ｏアダプタ１８が含まれる。さらに、このコンピュータには、キーボード２４、マウス３２、スピーカ２８、マイクロホン２６、および／または、ユーザ・インタフェース・デバイス、例えば、図示しないタッチスクリーン・デバイスのようなデバイスを、システムバス１２に接続するためのユーザ・インタフェース・アダプタ２２が含まれる。さらにまた、このコンピュータには、ワークステーションを、２３で示すデータ処理ネットワークに接続するための通信アダプタ３４と、システムバス１２をディスプレイ・デバイス３８に接続するためのディスプレイ・アダプタ３６が含まれる。このワークステーションには、Apple System/7（登録商標）オペレーティング・システムのようなオペレーティング・システムが駐在している。以下に、本発明の好ましい実施の形態により提供される要件と、クライアント・ニーズと、クラスを説明する。この好ましい実施の形態を、「インタフェース参照フレームワーク(interface reference framework)」という。インタフェース参照フレームワークは、コンピュータ産業の様々なセグメント、すなわち、１．「コンピュータ・ビュワー」と、「低レベル・ハードウェア構成フレームワーク」および「ネットワーク・ブラウザ」の設計者および開発者、２．コンピュータ・ビュワーおよびネットワーク・ブラウザに表示される新タイプのTModelSurrogate の開発者、３．サービス（例えば、ＣＡＮ、ＤＡＭ、デバイス・チャネル）の設計者インタフェース参照フレームワークは、サービスがどのように作成されるかの詳細から、開発者自身を切り離そうとする開発者のニーズにアドレスするように設計されている。インタフェース参照フレームワークを用いる開発者は、メッセージ・ストリームのような基本的なサービス作成技法をクライアントから見えないように隠蔽することができる。これらの詳細は、全て、インタフェース参照フレームワークによりカプセル化される。インタフェース参照フレームワークの第１の利点は、サービスがどのように作成されるかの詳細をクライアントから見えないようにする抽象化を、インタフェース参照フレームワークが提供する点にある。TinterfaceReference のサブクラスのインスタンスは、クライアントにより指定されたインタフェースで、特定デバイスに対するサービスを作成し使用する能力を表している。Ｃ++では、クライアントは特定クラスをインスタンシエートするだけで、インタフェースを指定するのが典型的である。TImageWriterサービスを必要とするクライアントを考察する。数多くの具象TImageWriter serviceクラス、例えば、TImageWriterOnSe rialと、TImageWriterOnParallelと、TImageWriterOnMessageStreamと、TImageW riterOnSCSIのようなクラスが利用可能である。これらの具象クラスは、それぞれ、TImageWriterインタフェースをサポートしている。どのクラスを選択するか。貴方たちが選択することのできる唯一の方法は、デバイスが実際にどこに接続されているかについて、何かを知ることである。しかし、貴方たちは詳細(detai l)のタイプを知る必要はない。そうして、我々はこの知識をインタフェース参照の内部でカプセル化する。この知識が、貴方たちのために、具象クラスのどれを、「メタル(metal)」に至るまで、インスタンシエートするかを判断する。例えば、ImageWriter を考察する。このImageWriter を、コンピュータの任意のシリアル・ポートまたはパラレル・ポートに接続することができるし、ネットワークにさえも接続することができる。どの場合にも、そのプリンタと通信するため、サービスの異なる集合を作成する必要がある。ImageWriter がどのように接続されているか、サービスの異なる集合がどのようにしてImageWriter をアクセスするかという詳細から、インタフェース参照フレームワークはクライアントを切り離している。図２は、"ImageWriter"サービス２０２を必要とするクライアント２００（I mageWriter TModelオブジェクト）の高レベルなシナリオを示す。図２において、両側にラインがある矢印は、コラボレーション(collaboration)をセットアップするメッセージ送信を示す。一方の端に"+"があるライン（矢印なし）は作成を意味する。クライアント２００には、システムの組込みシリアル・ポートに接続されたIm ageWriter ２０４へのインタフェース参照２０６が与えられる。クライアントは"ImageWriter"２０４をトップ・インタフェースとしてセットし、インタフェース参照２０６を活動化する。その結果、ImageWriter サービス２０２が作成され、作成されたImageWriter サービス２０２がそのターゲット・プリンタに返される。ImageWriter サービス２０２自身が、シリアル・サービス２０８をたまたま必要としている。さらに、シリアル・サービス２０８はUARTサービス２１０を必要としている。ImageWriter TModelオブジェクト２００は、これらサービスのどれもが必要なことを気にとめない。このシナリオの利点は、コンピュータ・ビュワー(computer viewer)と、ネットワーク・ブラウザ(network browser)が、共に、同じコンストラクタを用いて同じモデルを作成することができる点にある。そのため、モデル・ライタはモデルを、２つではなく、１つだけ書くだけでよいので、モデル・ライタのジョブが単純化される。インタフェース参照フレームワークの第２の利点は、ユーザがコンピュータ・ビュワーにより接続を変更した後も有効になるように、サービスの関係付けが保証される点にある。例えば、図３に示すように、グラフィックス・インタフェース３００のユーザはprinter ３０２をdocument３０４上にドロップすることができる。そうすることにより、document３０４がプリンタ・サービスと「関係付け」される。デフォルトdocument printコマンドが発行されると、常に、document ３０４はこのprinter ３０２を用いる。printer ３０２の接続が変更されても、そのprinter ３０２と「関係付け」されているdocumentは、全て、依然として、同じプリンタにプリントされることになる。このことがサポートされていない場合は、ユーザは、修正されたコネクションにより影響を受けたドキュメントをそれぞれフィックス(fix)する必要がある。第３の利点は、ドキュメントと関係付けされたサービスが、システムのリブートを絶えずアクセスする点にある。システムがリブートされると、これらの関係付けは全てそのまま有効である。サービス・スタック(servicestack)：サービス・スタックとは、積み重ねられた一連のサービスである。サービス・スタックのサービスは、それぞれ、１つのインタフェースをクライアントに確実にエクスポートし、当該サービスより下にある１つのサービスが確実に用いられることを期待する。次に、図面を参照してサービス・スタックを説明する。図示をしたボックスはそれぞれサービスを表す。図４に示すトップのボックス４００は、「printer」をそのインタフェースとして、クライアントにエクスポートするサービスを表す。このサービスは、その「printer」インタフェースの責務を果たすため、当該サービスより下のサービスである「serial」０２／４０４を必要とする。図５に示すトップのボックス５００は、図４に示すトップのボックス４００とは異なるサービスを表す。エクスポートされるインタフェースは同じであるが、そのインタフェースの下に、異なるインタフェース、すなわち、parallel５０２／５０４を要求する。図６に示すように、これらの２つのサービス６０２，６０４は、実際には、共通の抽象６００のサブクラスである。この構造により、トップにあるサービスのクライアント（この場合には、「printer」）を、下位レベルの種々のサービス間で再利用することができる。本発明に係るインタフェース・フレームワークに関して上述したメカニズムの主な目的は、このようなスタックを自動的に作成することができ、上位レベルのクライアントを最大限に再利用することができることにある。トップ・インタフェース：クライアントがサービスをアクセス（または使用）するときに用いるインタフェースは、トップ・インタフェース(top interface )と呼ばれる。上の例では、「Serial」４０４が、＜Serial、UART＞サービスのトップ・インタフェースである。「Parallel」５０４が、＜Parallel、VIA＞サービスのトップ・インタフェースである。ボトム・インタフェース(bottom interface)：「トップ」インタフェースの責務を果たすためにサービス・プロバイダが用いるインタフェースは、ボトム・インタフェースと呼ばれる。上の例では、"UART"４０６が、＜Serial、UART＞サービスのボトム・インタフェースである。"VIA"５０６が、＜Parallel、VIA＞サービスのボトム・インタフェースである。アクセス・マネージャ(Access Manager)：アクセス・マネージャとは、物理ハードウェア・コンポーネント（例えば、集積回路）と直接に話(talk)をすることができる入出力サービスである。アクセス・マネージャは、ハードウェアをアクセスする複数のリクエストの調停をハンドルする。要件次に、インタフェース参照フレームワークの要件の完全なリストを示す。多態によるサービス作成のサポート：このようなサービスがどのように作成されるかの詳細を、サービスのコンシューマ(consumer)から隠蔽することができる拡張可能なメカニズムが必要である。このようなサービスがリモートで提供されるか、あるいは、ローカルで提供されるかを、コンシューマは知る必要がない。さらに、ローカル・サービスのコンシューマは、ローカル・サービスが用いるポートはどのタイプか（例えば、シリアルか、ＳＣＳＩか）、あるいは、ローカル・サービスがどの特定ポ-ト（例えば、モデム・ポートか、プリンタ・ポートか）に接続されているかを知る必要はない。クライアントが使用したいサービス・インタフェースをクライアントが指定できること：全てのサービスはあるインタフェースをそのクライアントにエクスポートする。インタフェース参照フレームワークは、クライアントが必要とするインタフェースをクライアントが指定できるメカニズムに提供しなければならない。「接続」が変更された場合にサービスを再確立する能力：ローカル・デバイスとの接続が変更されると、適正な新しいサービスを作成しなければならない。例えば、プリンタが、現在、シリアル・ポート１に接続されていたが、ユーザがその接続をパラレル・ポート２に移動した場合は、新しいサービスを、パラレル・ポート２を用いて、作成しなければならない。持続的なサービスの関係付けのサポート：サービス（例えば、ImageWriter IIアイコン）を、ドキュメント・モデルと関係付けをすることができる。ユーザが行なった関係付けであってサービスとドキュメントとの関係付けを、クライアントがインタフェース参照フレームワークにより保つことができることは重要なことである。サービスの記述を計算する能力：サービス記述は特定のサービス・スタックの作成に必要な一切の情報よりなる。サービス記述はいつでも計算することができる。最適化として、サービス記述をキャッシュすることができる。遅延(lazy)活動化のサポート：いつでも、サービス記述からサービス・スタックを作成することができる。このため、インタフェース参照のクライアントは、サービスが実際に必要になるまで、サービスの作成を先に延ばすことができる。例えば、ドキュメント・モデルはプリンタとのインタフェース参照をもつことができる。プリンタ・サービス・スタックの作成を、ユーザがドキュメントのプリントをリクエストするまで、先に延ばすことができる。各入出力ポートに対する複数のスタックをサポートし、ボトムで調停を行う：所定の入出力ポートに対して、２つ以上のスタックが同時に存在させることができなければならない。ハードウェア資源（例えは、チップ）の調停は、ボトムのアクセス・マネージャによりハンドルされる。スタック活動化は新たに「インストール」されたソフトウェアを利用しなければならない：サービス・スタックが活動化（すなわち、作成）されるたびに、サービス・スタックは、最新のサービスであって、スタックのメンバであるサービスを組み込まなければならない。特徴次に、インタフェース参照フレームワークの特徴(features)を列挙する。ローカル・サービスとリモート・サービスを多態により作成する：インタフェース参照フレームワークは、サービスを作成し、そのサービスをアクセスするための単純なメカニズムを、コンシューマに提供する。サービスを作成するのに必要になる詳細から、クライアントを切り離す。サービス・コンシューマには、「トップ」インタフェースを供給することだけが要求される。他のタイプのサービス・スタックをサポートするために拡張することができる：インタフェース参照フレームワークは拡張可能である。例えば、２タイプのサービス、例えば、ローカルとリモートのようなサービスをサポートすることができる。ある記述からオン・ザ・フライ(on the fly)でサービスを作成することができる：クライアントがあるサービスをリクエストした時点で、サービスがインタフェース参照フレームワークにより自動的に作成される。サービスの作成に必要な情報は、全て、インタフェース参照フレームワークによりカプセル化されている。サービス・クラス階層を必要としない：インタフェース参照フレームワークにより用いられるサービスは、何か特殊なものからサブクラス化する必要がない。（正当なhelperクラスが利用可能である限り）任意のクラスを用いて、サービスをこのフレームワークに提供することができる。入出力ポートにより提供される可能な限りのサービスを列挙する：特定のポートにより現在サポートされているサービスの集合を、クライアントはオンデマンドで利用可能である。クライアント依存関係ハードウェア構成フレームワーク／コンピュータ・ビュワー： TModelSurrogate は、物理ハードウェアをアクセスすることができるサービスを作成することができなければならない。コンピュータ・ビュワーとネットワーク・ブラウザが、同じモデル・クラスとコンストラクタを使用することができるためには、多態インタフェース参照が必要である。例えば、Image Writerは、コンピュータ・ビュワーとネットワーク・ブラウザの両方に出現することができる。同じImage Writerモデルは、コンピュータ・ビュワーとネットワーク・ブラウザの両方によって使用することができる。接続をいつ変更できるかを知る能力が必要である（ＵＩの課題）。現在使用中のデバイスの接続をユーザが変更するのを禁止することは、好ましいことである。コンピュータ・ビュワー／ネットワーク・ブラウザ：あるサービスに対する同一のTModelSurrogate クラスは、コンピュータ・ビュワーとネットワーク・ブラウザの両方により使用される必要がある。 Modem フレームワークと、Printer フレームワークと、MIDIフレームワーク：あるクライアントにとって、サービスがローカルであっても良いし、リモートであっても良いし、デバイスがどのポートに接続されていても良い。特定デバイスに対するオブジェクトとサロゲート(surrogate)は、クライアントのこのカテゴリから逸脱しない。例としては、TModemと、printer TModelSurrogate と、MI DI TModelSurrogateがある。サービス依存関係サービス記述の識別：サービスがインタフェース参照フレームワークによって使用されることが予想される場合は、当該サービスがクライアントにエクスポートするインタフェース（つまり、「トップ」インタフェース）と、当該サービスの下に当該サービスが必要とするインタフェース（つまり、「ボトム」インタフェース）を識別する必要がある。現在、この要件は、（後述する）「helper」クラスのみに適用され、サービス自体には適用されない。ハードウェア構成フレームワーク：ローカル・デバイスのサービス・スタックの作成をサポートするため、ローカル・ポートに関する情報にアクセスできなければならない。この依存関係は、有効なルート(root)（つまり、マザーボード）のTHardwareModuleHandle オブジェクトで、コンピュータ・データベースを初期化しなければならないことを暗黙的に示している。サービスを提供する周辺デバイスに対するTHardwareInterfaceHandleは、我々に、 − 接続をナビゲート(navigate)して周辺デバイスがどのポートに接続されているかを知る能力と、 − そのポートに対するTHardwareInterfaceIdentifierへのアクセスとを与える。パーソナリティ・ニュートラル・サービスフレームワークはパーソナリティ・ニュートラル層(personality neutral layer)７０６の一部と考えることができる。パーソナリティ・ニュートラル層７０６はＯＳパーソナリティ（例えば、Taligent OS ７０４と、OS/2 ７００と、 AIX ７０２と）にサービスを提供する。パーソナリティ・ニュートラル層に一旦ポートされると、これらのＯＳパーソナリティは、本質的に、ハードウェア・プラットフォーム７０８独立となる。アーキテクチャ以下に、処理階層の特定要素に対する種々の例を示す。これらの例は説明の便宜上示すに過ぎない。クライアントによる参照によりサービス・スタックを動的に作成するコンセプトであって、ここに具現化したコンセプトを、処理階層の任意の要素に適用することができる。必要な関係のみが、クライアントによるサービスに必要である。サーベイクラス図インタフェース参照フレームワークは次の３組のクラス、すなわち、（１）Interface Reference クラス（図９）と、（２）Interface Maker クラス（図１１）と、（３）TInterfaceBundleクラス（図１４）とよりなる。概要図図８はインタフェース参照フレームワークにおける全てのクラス間の関係を示す概要図ある。クライアントにはinterface reference オブジェクト８０２が与えられる。そのクライアントはトップ・インタフェース属性８００を設定する。そのクライアントはActivate８０４をコールする。interface reference オブジェクトは、インタフェース・メーカ８０６を作成し、作成されたインタフェース・メーカ８０６をバンドル・コレクション(bundle collection)８１０に渡す。インタフェース・メーカはサービス８０８を作成する。そのサービス８０８を、任意指定で、バンドル・コレクションか、特定のbundleオブジェクトに渡すか、あるいは、特定の設定メソッドをコールするかして、サービスをセットアップすることができる（サービスがなにを必要としていても）。maker クラスは、サービスをセットアップの詳細から、インタフェース参照フレームワークを隔離する。インタフェース参照コンポーネント Interface Reference クラス（図９）： − Taligentにより開発。特定ニーズに対してサブクラス化が可能。 − サービス作成のためにサービス・コンシューマによって使用。 TInterfaceReference ９００ TInterfaceReference ９００と、TInterfaceReference ９００に関係付けをした属性の主目的は、クライアントが、どのようにサービスが提供されるかを気にしないで、サービスを作成することができることにある。例えば、インタフェース参照フレームワークを用いて、ユニバーサルなTImageWriterModel クラスを書くことができる。このクラスは、ImageWriter がネットワーク上に置かれているか、ホスト・コンピュータにローカルに接続されているかとは関係がない。TInt erfaceReference のサブクラスのインスタンスは、具体的なＡＰＩで、具体的なデバイスに対するサービスを作成し、アクセスする能力を表している。次々にネストされた２つ以上のサービスにより、サービス・スタックを表すことができる。セッションからセッションまで、同一のTInterfaceReference は、接続が変更されたかどうかどうか、あるいは、新しいソフトウェアがインストールされたかどうかにより、異なるサービス・スタックを作成することができる。 TInterfaceReference ９００は次のような属性９０２をもっている。すなわち、 TopInterface: InterfaceName − この値は、クライアントが必要とするサービス・インタフェースのタイプを指定する。 Bundle: TDictionary〈InterfaceName,TInterfaceBundle〉 − ディクショナリ(dictionary)の各キーは、InterfaceName オブジェクトであり、TInterface Bundleのサブクラスの１つのインスタンスと関係付けしてある。TInterfaceBund leオブジェクトは、このオブジェクトが表すタイプのインタフェースに特有のデータをカプセル化する。例えば、Serialインタフェースの場合、BAUDレートとパリティ情報をカプセル化することができる。バンドルは任意指定である。サービスが活動化されると、あるバンドル（存在する場合）がサービス・メーカに渡される。次のシナリオは、ローカル・デバイスとリモート・デバイスに対して稼働するユニバーサルなImageWriter モデルが、どのようにサポートされるかを示す。Im ageWriter モデルは、自分がTInterfaceReference をもっていることだけを知っており、どのタイプであるかは無関心である。サービスを、リモートか、ローカル・シリアルか、あるいは、ローカル・パラレルにすることができる。これらの詳細はImageWriter モデルの観点からは重要でない。ImageWriter モデルが必要とするものは、"PrinterDeviceChannel"のインタフェースをエクスポートするサービスだけである。 ImageWriterモデルのコードは、printerサービスを獲得するため、次のようになっている。 TNetworkInterfaceReference ９０８ TNetworkInterfaceReference ９０８の目的は、リモート・デバイスに対するサービスがどのように作成されるかという詳細から、クライアントを隠蔽することにある。アクテイブなTNetworkInterfaceReferenceオブジェクトは、リモート・サービスへのアクセスを表す。 TNetworkInterfaceReference ９０８は次のような属性９１０を有する。すなわち、 Service Reference： TServiceReference ９１０ − TNetworkInterfaceR eferenceが活動化されたとき使用するため、この値はネットワーク・サービス参照を指定する。TNetworkInterfaceReference ９０８オブジェクトが活動化されると、このオブジェクトは「トップ」インタフェースとTServiceReference 属性９１０を用いてサービス・スタックを作成する。このサービス・スタックのボトム・サービスは、TRequestSenderStreamオブジェクトである。図１０はサービス・スタックの可能な変形を示す。トップ・インタフェースが"TRequestSenderStream"である場合、このスタックは、１０００で示すように、この単一サービスだけからなる。「トップ」インタフェースが「pr inter」である場合、トップが「printer」であり、ボトムが"TRequestSenderStr eam"であるサービスの集合が作成される。このことを、図１０に項目１００２と１００４で示す。「トップ」インタフェースが「modem」である場合は、トップが「modem」であり、ボトムが"TRequestSenderStream"であるサービスの集合が作成される。このことを、図１０に項目１００６と１００８で示す。 THardwareInterfaceReference ９０４ THardwareInterfaceReference ９０４の目的は、ローカル・デバイスのサービスがどのように作成されるかという詳細を、クライアントから隠蔽することにある。アクテイブなTHardwareInterfaceReference オブジェクト９０４は、実ローカル・デバイスにより提供されるサービスへのアクセスを表す。 THardwareInterfaceReference は次のような属性９０６を有する。すなわち、 Connector ： THardwareInterfaceHandle − THardwareInterfaceHandleは、インタフェース参照が表すサービスを実際にパフォームするデバイスのコネクタを表す。THardwareInterfaceReference ９０６は、そのコネクタのハードウェア接続をたどっていって、サービス・スタックをコンストラクトするのに必要となる絶対「ボトム」インタフェースを判断することができる。 UseConnectorName: Boolean − TRUEである場合、interface reference オブジェクトが活動化されると、所定の「トップ」インタフェース名を無視し、その代わりに、コネクタのInterfaceName を「トップ」インタフェース名として用いる。これは、任意の抽象プロトコルを用いなければならないが、具象プロトコルを指定することを望んでいないクライアントにとって有用である。例えば、クライアントはポインティング・デバイス・プロトコルを用いることができるが、"Log iTechPointingDevice"プロトコルを使用すべきか、"AppleADBMouse"プロトコルを使用すべきかの判断に係わらなくすることができる。この判断は、UseConnect orNameの値がTRUEにセットされている場合、THardwareInterfaceReference オブジェクト９０４により自動的に行われる。図４および図５を参照して説明したように、THardwareInterfaceReference オブジェクトが活動化されると、このオブジェクトはTHardwareInterfaceHandle属性から判断された「トップ」インタフェースと「ボトム」インタフェースの両方を用いてサービス・スタックを作成する。 TIneterfaceMaker Interface Maker クラス（図１１）： − アクセス・マネージャのライタか、サービス・クラスのプロバイダか、等々により開発される。 − サービスを作成するため、interface reference クラスによって内部で使用される。 TInterfaceMaker １１００の目的は、service providerクラスを、全て、サービス・スタック・フレームワークから隔離し、限られた量のタイプ・セーフティ（例えば、no void^*）を提供することにある。各maker オブジェクトは特定のサービスを作成し、初期化する能力を表す。インタフェース参照フレームワークは、サービスを直接取り扱うのではなく、interface maker オブジェクトを直接取り扱う。例えば、サービスを作成するため、インタフェース参照はActivateメソッド（１１０４、１１０８、１１１２）をmaker オブジェクト（１１０２、１１０６、１１１０）にコールする。これらmaker オブジェクトはサービスを作成し初期化する。このinterface reference オブジェクトはサービスに直接に触れることはない。決して直接触れることはない。このように回りくどい方法をとった理由は、システム内の全てのサービスを、インタフェース参照フレームワークにより定義された単一のクラスから派生させる必要がないからである。例えば、ISerialACIA ６８５０ access manager クラスは、インタフェース参照フレームワークの任意のクラスから派生させる必要はない。サービス・メーカはオーバヘッドが非常に小さく、開発が簡単である。サービス・メーカは、インタフェース参照フレームワークによりディクテイト(dictate )された階層に属している。図１２および図１３は、サービス・メーカの階層上の制約と、サービスの階層の自由度とを対比したものである。当該メーカはTInt erfaceMaker １２００を親としてもっていることに注意されたい。他方、サービスは、オーサ(author)が望む階層が何であれ、階層に自由に属することができる。 TInterfaceMaker オブジェクト１２００のアクティブなサブクラスを、適正なサブタイプにダウンキャスト(down-cast)することができ、実サービス・オブジェクトを指すポインタを安全に取得することができる。これにはプロトコルがない。図１２の例では、クライアントは、TUARTAccessManagerMaker １２０６を指すポインタをダウンキャストして、GetAccessManager１３００を安全にコールし、GetAccessManager１３０はTUARTAccessManager１３００を指すポインタを返す。以下に、TUARTAccessManagerMaker １２０６とTUARTAccessManager１３００との関係をもっと簡潔に定義する。 TAccessManagerMaker １２０２ TAccessManagerMaker オブジェクト１２０２はアクセス・マネージャを作成し、活動化する。アクセス・マネージャは、Activateメソッドに渡されたTHardwar eInterfaceIdentifierオブジェクトにより識別されたデバイスへのアクセスを調停する。アクセス・マネージャはインタフェース参照基底クラスから派生させる必要がない。TInterfaceMaker １２００のこのサブクラスを用いて、サービス・スタックのボトム・サービスが作成される。TAccessManagerMakerオブジェクト１２０２は、THardwareInterfaceIdentifierオブジェクトが活動化されると、TI nterfaceReference オブジェクトにより作成される。 TInterfaceReference は、アクセス・マネージャにより制御される「メタル」を表すTHardwareInterfaceIdentifer オブジェクトを渡す。 TUpperInterfaceMaker TUpperInterfaceMakerオブジェクトにより、TInterfaceMaker は、特定のサービス・オブジェクトを他の幾つかのサービスの上に作成し活動化することができる。TInterfaceReference のこのサブクラスは、具体的なサービス・オブジェクトを他のサービスの上に作成し活動化するために使用される。TInterfaceMaker のこのサブクラスは、サービス・スタックの非ボトム・サービスを作成するために用いられる。サービスはインタフェース参照基底クラスから派生させる必要はない。TUpperInterfaceMakerオブジェクトは、TInterfaceReference オブジェクトが活動化されると、TInterfaceReference オブジェクトにより作成される。 TInterfaceBundle１４００ Interface Bundleクラス（図１４）： − アクセス・マネージャのライタまたはサービス・クラスのプロバイダにより開発される。 − 構成情報を提供するため、サービスにより直接使用される。 TInterfaceBundle１４００のインスタンスは、特定のデバイスに固有のカプセル化情報を表す。あるバンドルを、活動化時に、多態的にサービス・メーカに渡すことができる。TInterfaceBundle１４００は、特定タイプのサービスに固有の情報をカプセル化するために、サブクラス化される。 TInterfaceBundle１４００のインスタンスを、ファイルにストリーム化することができる。キー・シナリオ THardwareInterfaceReference を活動化する − 概要＃１このシナリオは２度提供される。１回目は、Booch 表記法を用いて提供され、もう１回は、VDL（ビジュアル設計言語）を用いて提供される。このようにしたのは、どちらの表記法も、サービス・スタックを活動化するプロセスを搬送するというジョブをうまく行えないからである。シナリオ：クライアントはあるオブジェクトを指すTInterfaceReference ポインタをもち、このオブジェクトの実際のサブクラスはTHardwareReferenceであり、このオブジェクトのトップ・インタフェースは「printer」に設定されている。クライアントはそのActivate()メソッドをコールする。活動化は２つのステージ、すなわち、(I)スタック記述の作成、(II)サービス・スタックの作成の２つのステージで行われる。図１５はこのシナリオのためのハードウェア構成を示す。Handle １５００と１５１０は、ハードウェア・コンポーネントを参照するために使用されるオブジェクトである。ハードウェア・コンポーネントとしては、THardwareInterfaceRe ference オブジェクト１５０８と、プリンタのコネクタ１５１４（THardwareInterfaceReference オブジェクトの属性）と、コネクタの identifierオブジェクト１５１６と、connectionオブジェクト１５１２と、プリンタが接続されているコネクタ１５０２と、コネクタのidentifierオブジェクト１５０４と、「メタル」１５０６がある。 (I)スタック記述の作成：（１）スタック記述を作成するためTHardwareReferenceオブジェクトがパフォームしなければならない第１ステップは、「ボトム」インタフェースを得ることである。ボトム・インタフェースは、このシナリオでは、次のような方法で見付け出される。まず、THardwareInterfaceReference オブジェクトのconnector 属性１５１４をアクセスする。次に、connector 属性１５１４からTHardwareInter faceIdentifierオブジェクト１５１６を取り出し、取り出されたオブジェクトを試験する。この識別子を活動化できないので、次に進む。次に、THardwareInter faceReference オブジェクトは、connectionオブジェクト１５１２をプリンタのコネクタから取り出す。他のエンド１５０２が、この接続から取り出される。TH ardwareInterfaceIdentifierオブジェクト１５０４はエンド１５０２から取り出され、試験される。この識別子オブジェクトは活動化可能であるので、ここで停止することができる。これはボトム・インタフェース“６８５０”を指定する。（２）このステージで、我々は、サービス・スタックのまさしくトップ（「Printer」）インタフェースと、ボトム（“６８５０”）インタフェースを知る。次のステップでは、必要とするサービス・スタック（TLocatorまたはTFSL ocatorをサブクラス化して、都合よく実現することができる）を形成するため、結合することができるサービスの集合を探すファイル・システム(NuBus ROMも可能性がある)が探索される。図１６はサービス・メーカ・エンティティ（つまり、これらはTServiceMakerL ocatorプロパティを探索して、見付け出されるエンティティである）の架空上の「プール」１６００を示す。このプールの各エンティティは、システムに「インストール」されている１つのTServiceMakerエンティティを表す。各エンティティはそのトップ・インタフェースとボトム・インタフェースにより識別される。破線１６０２は、我々が我々のTHardwareInterfaceReference オブジェクトを見付け出すパスを示す。（３）このTHardwareInterfaceReference オブジェクトに対する計算されたスタック「記述」は、図１６で破線により接続されたエンティティにより定義されている。 (II) スタックの作成：（１） THardwareReference オブジェクトは、図１７に示すように、次の順序でスタックを作成する。(a)最下位のTInterfaceMaker オブジェクトをスタック記述から作成する。作成されるオブジェクト１７００は、図１８に示すクラス１８００のインスタンスである。オブジェクト１７００は、このACIAポートを表す THardwareInterfaceオブジェクトから取り出されたTInterfaceIdentifierを渡して活動化される。図１８は多数のクラスを示す。図１７に関係する特定のクラスのみを説明する。図１３に示す関係の多くは既に説明した。 (b) TInterfaceMaker オブジェクトはその対応するサービス（アクセス・マネージャ）を作成し、h() をコールし、このh() に同一のTInterfaceIdentifierを渡す。この新しいサービスは１７０２とラベル付けされ、図１８のクラス１８０２のインスタンスである。 (c) THardwareReferenceオブジェクトは、引き続き、次のTInterfaceMaker オブジェクトをスタック記述から獲得する（獲得されるオブジェクトはTUpperInte rfaceMakerである）。TAccessManagerMaker オブジェクト１７００をTHardwareR eferenceオブジェクトに渡し、THardwareReferenceオブジェクトはTUpperInterf aceMakerをActivateする。次は、トリッキ(tricky)な部分である。THardwareRef erenceオブジェクトに渡されたTAccessManagerMakerオブジェクトが、ACIAメーカであることは充分良く分かっているので（これは、ここで約束したことであり、プロパティが存在しない場合にトリッキな部分が働く）、THardwareReference オブジェクトはTAccessManagerMaker オブジェクトを正しいタイプのメーカにダウンキャストし、TAccessManagerMaker オブジェクトにサービス１７０２を要求する。このオペレーションにより、ACIAアクセス・マネージャにアクセスされる。 (d) 次に、TUpperInterfaceMakerオブジェクトはその対応するサービス（これはどれからでも派生することが可能である）を作成し、g() をコールし、このg( ) にACIAアクセス・マネージャを渡す。 (e) THardwareReferenceオブジェクトは、引き続き、、次のTInterfaceMaker オブジェクト（もう１つののTUpperInterfaceMaker）をスタック記述から獲得する。クラス１８０４のTAccessManagerMaker オブジェクトがTHardwareReference オブジェクトに渡され、THardwareReferenceオブジェクトはTUpperInterfaceMak erオブジェクトを活動化する。ダウンキャストのマジックがこの場合にも行われ、渡されたTUpperInterfaceMakerオブジェクト（クラス１８０６のオブジェクト）、サービス１７０６を要求する。その結果はSerial-ACIAサービスである。 (f) 最後に、クラス１８００のTUpperInterfaceMakerオブジェクトはその対応するサービス１７１０を作成し、f() をコールし、このf() にSerial-ACIA サービスを渡す。以上で当該サービス・スタックが完成する。THardwareReferenceオブジェクトは、活動化の結果として、クラス１８０８の最上位のTInterfaceMaker １７０８を返す。そして、クライアントは結果に合せてダウンキャストを行い、このサービス・スタックの最上位のサービスをアクセスすることができる。 THardwareInterfaceReference を活動化する − 概要＃２シナリオ：クライアントは、実際のサブクラスがTHardwareInterfaceRefere nce であるオブジェクトを指すTInterfaceReferenceポインタをもつ。クライアントはそのActivate()メソッドをコールする。このメソッドは２つのステージ、すなわち、(I) スタック記述の作成と、(II) スタックの作成との２つのステージで実行される。 (I) スタック記述の作成（図１９）：トップ・インタフェース１９０６のTHardwareInterfaceReference オブジェクト１９０８のスタック記述は、次のステップで作成される。まず、「ボトム」インタフェースをハードウェア構成フレームワーク１９００から取得する。次に、必要なインタフェースを満足するサービスの集合を突き止める。最後に、スタック記述１９０４を計算する。これは、適正なトップ・インタフェースとボトム・インタフェースをもつスタックを形成するために、次々とスタックさせることができるサービスの集合を見付け出すまで、あるサービスのトップ・インタフェースを別のサービスのボトム・インタフェースと突き合わせて行われる。１つのサービス・スタック記述のみがこのプロセスから計算されるものと仮定する。スタック記述が２つ以上見つかった場合は、たぶん、例外が引き起こされる。注意：このサービス・スタック自身がこのプロセスで実際に作成されず、ただ、このサービス・スタックの記述だけが作成される。このスタック記述は、インタフェース・メーカへの参照の順序付けをしたリストよりなる。各インタフェース・メーカは、その対応するサービスがどのように作られるかを知っており、我々のシナリオの次のステージでそのようにするため、その対応するサービスがコールされる。 (II)このサービス・スタックの作成：このサービス・スタックの作成を２個所で示す。第１セクションでは、簡単な概要を示す。第２セクションでは、より詳細に示す。概要図２０は、THardwareInterfaceReference のスタック作成の全体的なオペレーションを示す。サービス・スタックの作成が、スタック記述２００８全体で繰り返し行われる。スタック記述の各インタフェース・メーカ「参照」２０１０ごとに、次のことを行う。まず、interface maker オブジェクト２０００を作成する。次に、interface maker オブジェクトを活動化し、適正な引数を渡す(interfa ce maker オブジェクトがAccess Manager Makerである場合は、THardwareInterf aceIdentifier２００２を渡し、Upper interface maker である場合は、その下のTInterfaceMaker オブジェクトを指すポインタを渡す）。対応するTInterfaceBundleオブジェクト２００４が利用可能である場合は、このTInt erfaceBundleオブジェクト２００４はinterface maker オブジェクト２０００に与えられる。最後に、interface maker オブジェクト２０００は、その対応する service オブジェクト２００６を作成する。interface maker オブジェクト２０００はservice オブジェクト２００６を初期化する。interface maker オブジェクト２０００はどの情報が必要であるかをよく知っている（例えば、THardwareI nterfaceIdentifierと、その下のTInterfaceMaker オブジェクトを指すポインタと、TInterfaceBundleオブジェクトと、等々）。詳細このセクションはサービス・スタックがどのように作成されるかという詳細な VDL シナリオを説明する。図２１に示すように、THardwareInterfaceReference オブジェクト２１０４は次の順序でスタックを作成する。（１）最下位のTInterfaceMaker オブジェクト２１１２をスタック記述２１０２から作成する（作成されたオブジェクトは図２０に示すクラスのインスタンスであり、その側に、interface maker オブジェクト２０００がある）。スタック記述は、２１００で示すサービスの集まりに基づいている。 TInterfaceMaker オブジェクト２１１２は、ACIAポートを表すTHardwareInterfa ceHandleオブジェクトから取り出したTHardwareInterfaceIdentifier ２１０６を渡すことにより活動化される。要素２１０８と２１１０はそれぞれACIAと６８５０を表現する。（２） TInterfaceMakerオブジェクト２１１２はその対応するサービス（アクセス・マネージャ２１１４）を作成し、その初期化関数h() をコールし、このh( ) に同じTHardwareInterfaceIdentifier ２１０６を渡す。この新サービスは図２１に２１１４で示してあり、図２０のクラス２００２のインスタンスである。（３）図２２に示すように、THardwareInterfaceReference オブジェクトは、引き続き、スタック記述から次のTInterfaceMaker オブジェクト２２００を作成する（これはTUpperInterfaceMakerである）。ステップ１で既に作成されたTAcc essManagerMaker オブジェクトがTHardwareInterfaceReference オブジェクトに渡され、THardwareInterfaceReference オブジェクトはTUpperInterfaceMakerを活動化する。次はトリッキな部分である。 THardwareInterfaceReference オブジェクトに渡されたTAccessManagerMaker オブジェクト２２０２が、ACIAメーカ２２００であることは充分に分かっているので、THardwareInterfaceReference オブジェクトはTAccessManagerMaker オブジェクトをメーカの適正なタイプにダウンキャストして、ステップ２で作成されたサービス２２０６をTAccessManagerMaker オブジェクトに要求する。このオペレーションにより、ACIAアクセス・マネージャにアクセスされる。図２２に示す要素の多くは、図２１に示す対応する要素と性質は同一であるので、これ以上説明することは省略する。（４）次に、TUpperInterfaceMakerオブジェクトはその対応するサービス２２０４（このサービスをどれからでも派生させることができる）を作成し、そのサービス２２０４の初期化関数g() をコールし、g() にACIAアクセス・マネージャを渡す。（５）図２３に示すように、THardwareInterfaceReference オブジェクトは、引き続き、スタック記述から次のTInterfaceMaker オブジェクト２３００を作成する（もう１つのTUpperInterfaceMaker）。THardwareInterfaceReference オブジェクトにTAccessManagerMaker オブジェクト２３０２が渡され、THardwareInt erfaceReference オブジェクトは、TInterfaceMaker オブジェクト２３００を活動化する。ダウンキャストのマジックはこの場合も行われる（結果はSerial-ACI Aサービス２３０６である）。（６）最後に、TUpperInterfaceMakerオブジェクトはその対応するサービス２３０４を作成し、その初期化関数f() をコールし、このf() にSerial−ACIAサービスを渡す。以上でサービス・スタックが完了する。スタック記述にはエントリは存在しない。THardwareInterfaceReference オブジェクトはステップ５で作成された最上位のTInterfaceMaker を返す。そして、クライアントはそれをダウンキャストし、スタックの最上位のサービスにアクセスする。スタック記述を作成する − シリアル・ポート（マウス）シナリオ：インタフェース参照フレームワークは、クライアントがどの「トップ」インタフェースを使用すべきかについて確信がないとき働く。このシナリオが上述のシナリオと若干異なっている。というのは、UseConnectorNameClass 属性がTRUEに設定されているからである。このため、インタフェース参照は、コネクタのインタフェース名をトップ・インタフェースとして使用する。これは図１５と関係付けをしたオペレーションと非常によく似ている。クライアントは、実際のサブクラスがTHardwareInterfaceReference であり、しかも、トップ・インタフェースが"PointingDevice"であるオブジェクトを指す TInterfaceReference ポインタをもっている。クライアントはそのActivate()メソッドをコールする。図２４はこのシナリオに対するハードウェア構成を示す概要図である。 THardwareInterfaceReference オブジェクト２４０８と、マウスのコネクタ２４１２と、マウスのHardwareInterfaceIdentifier オブジェクト２４１４と、cone ction オブジェクト２４１０と、マウスが接続されているポート２４０２と、ポートのHardwareInterfaceIdentifier オブジェクト２４０４と、「メタル」２４０６である。（１）スタック記述を作成するために、THardwareInterfaceReference がパフォームしなければならない第１ステップは、「ボトム」インタフェースを得ることである。これは上述したシナリオと全く同じである。（２）第２ステップはInterfaceIdentifier オブジェクト２４１４からInterf aceName を得ることであり、InterfaceNameは「トップ」インタフェースを指定するために使用される。これは、connector オブジェクト２４１２をアクセスし、identifierオブジェクトを取り出し、GetInterfaceNameをコールすることにより行われる。（３）この時点で、サービス・スタック("６８５０)のトップ・インタフェースである"LogiTechMouse"と、ボトム・インタフェースは分かっている。次のステップでは、ファイル・システムが探索され、組合わせて必要なサービス・スタックを形成することができるサービスの集合を探す。インタフェース参照のTopInterface名属性により指定されたクラスのサブクラスであることを確かめるため、トップ記述が試験される。（４）図２５はTHardwareInterfaceReference オブジェクトに対する計算されたスタック「記述」２５００を示す。スタック記述を作成する − スイッチボックス経由のシリアル・ポートシナリオ：インタフェース参照フレームワークはスイッチボックスを取り扱う。このシナリオは、スイッチボックス経由でシリアル・ポートに接続されたプリンタの第１ステージ（つまり、スタック記述の作成）のみを示す。クライアントは、実際のサブクラスがTHardwareInterfaceReference であり、トップ・インタフェースが「printer」にセットされているオブジェクトを指すT InterfaceReference ポインタをもつ。クライアントはそのActivate()メソッドをコールする。図２６はこのシナリオに対するハードウェア構成を示す概要図である。 THardwareInterfaceReference オブジェクト２６００と、プリンタのコネクタ２６０２（THardwareInterfaceReference オブジェクトの属性）と、プリンタのHa rdwareInterfaceIdentifier オブジェクト２６０４と、connectionオブジェクト２６０６と、スイッチボックスのコネクタ２６０８と、スイッチボックス・コネクタのHardwareInterfaceIdentifier オブジェクト２６１０と、スイッチボックスのデフォルト・コネクタ２６１２と、connectionオブジェクト２６１４と、スイッチボックスが接続されているポート２６２６である。（１）スタック記述を作成するため、THardwareInterfaceReference オブジェクトがパフォームしなければならない第１ステップは、「ボトム」インタフェースを得ることである。すなわち、THardwareInterfaceReference オブジェクトは、活動化できるTHardwareInterfaceIdentifierオブジェクトが見つけ出すまで、 THardwareInterfaceHand1eオブジェクトをナビゲート(navigate)する。図２６は一見複雑であるが、実際は、そうではない。このプロセスは、ストレート・シリアル・ポートが係わりをもつ上述のシナリオを単に繰返したものである。ボトム・インタフェースは次のようにして見付け出される。まず、THardwareI nterfaceReferenceオブジェクトのコネクタ属性にアクセスする。次に、Hardwar eInterfaceIdentifier オブジェクト２６０４を取り出し試験する。HardwareInt erfaceIdentifier オブジェクト２６０４は活動化できるので、先に進む。次に、プリンタのコネクタから接続オブジェクト２６０６を取り出す。スイッチボックスHardwareInterface オブジェクト２６０８は、接続オブジェクト２６０６から取り出される。取り出されたHardwareInterfaceIdentifier オブジェクトは活動化することができない。以上で、THardwareConnectionHandle オブジェクトを一巡したが、活動化できるインタフェース識別子は見つからなかった。次に行わなければならないことは、我々が夢中になっているデバイス、つまり、要素２６０８を表すことができるサービスを作成することである。このデバイスに対するサービスが作成できなければ、我々は失敗である。このデバイスを自動または手動スイッチ・ボックスにすることができる。自動スイッチ・ボックスはこのスイッチ・ボックスを制御できるサービスを必要とする。手動スイッチ・ボックスもサービスを必要とするが、これは一貫性を保つためだけである。このサービスを作成するため、我々はスイッチ・ボックスのデフォルトTHardw areInterfaceHandleオブジェクト２６１２上に、THardwareInterfaceReference を作成する。我々はトップ・インタフェースをMMultiplexer（または、我々が後で定義することができるなにか適正なもの）に設定する。次に、我々はMMultipl exerをActivateする。その結果、引き続き、「ボトム」インタフェースが探索される。この探索では、connectionオブジェクト２６１４をたどっていき、THardw areInterfaceHandleオブジェクト２６１６で終了するが、このTHardwareInterfa ceHandleオブジェクト２６１６は活動化可能である。有効なボトムが見つかった。我々が作成したインタフェース参照は、引き続き、スイッチ・ボックスのサービス・スタックを作成する（注意：これはクライアントが関心をもっているサービス・スタックではない。スイッチ・ボックスであるため、我々は、一時的にわき道にそれただけである）。この時点で、我々は、MMultiplexerであるサービスを持つ。自動スイッチ・ボックスのディベロパは、このサービスを自身で用意する必要がある。手動スイッチ・ボックスの場合、我々は全ての手動スイッチ・ボックスに対する標準サービスを提供することができる。我々はSWitCh()をMMulti plexerにコールし、（すなわち、２６０８）にスイッチするために、コネクタに渡す。このSwitchメソッドは、マルチプレクサを我々のコネクタにセットすることを担当する（自動の場合にのみ）。手動スイッチ・ボックスの場合は、ユーザの責任で適正なボタンを押す。手動スイッチ・ボックスの場合は、ユーザ・アラートを任意指定で発生させて、ユーザが手動スイッチ・ボックスのボタンを押すのを忘れないようにする。このアラートが必要になるのは、シリアル・ポートが、以前の活動化とは異なるデバイスをアクセスするときだけである（すなわち、我々がモデムを２回続けて活動化する場合は、ユーザはなにもする必要はない）。この時点で、我々は、スイッチ・ボックスが適正なポジションにスイッチされたものと仮定する。我々はMMultiplexerから「ボトム」インタフェースを得て、 MMultiplexerサービス・スタックを削除する。我々は、最早、MMultiplexerは必要ではない。我々がMMultiplexerを使用するのは、ボトム・インタフェースを得るためと、スイッチをパフォームするためだけである。これで、我々は、適正なボトム・インタフェース（このボトム・インタフェースタから、クライアントのサービス・スタックを構築する）を得た。スタック記述を作成する − SCSI デバイスシナリオ：インタフェース参照フレームワークは自動構成可能デバイスのために働く。このシナリオはSCSIポートに接続されたプリンタに対する第１ステージ（つまり、スタック記述の作成）を説明する。この例では、クライアントは、ポートにではなく、SCSIデバイスと話す(talk)ことを望んでいる。このポートに対するサービス・スタックを作成する別のシナリオも可能である。コンピュータ・ビュワーは、ユーザがコンピュータ・ビュワーにSCSIポートをリフレッシュするように要求したとき、これを行う。クライアントは、実際のサブクラスがTHardwareInterfaceReference であり、しかも、トップ・インタフェースが「printer」に設定されているオブジェクトを指すTInterfaceReference ポイントを持っている。クライアントはそのActiva te()メソッドをコールする。図２７はこのシナリオのためのハードウェア構成を示す概要図である。 THardwareInterfaceReference オブジェクト２７００と、プリンタのコネクタ２７０２（THardwareInterfaceReferenceオブジェクトの属性）と、プリンタのHar dwareInterfaceIdentifier オブジェクト２７０４である。（１）スタック記述を作成するために、THardwareInterfaceReference オブジェクトがパフォームしなければならない第１ステップは、「ボトム」インタフェースを得ることである。すなわち、活動化できるTHardwareInterfaceIdentifier オブジェクトが見つかるまで、THardwareInterfaceHandleオブジェクトをナビゲートする。 THardwareInterfaceReference オブジェクトのコネクタ属性２７０２をアクセスして、ボトム・インタフェースを見付け出す。そして、ボトム・インタフェースからTHardwareInterfaceIdentifierオブジェクト２７０４が取り出される。次に、HardwareInterfaceIdentifier オブジェクトが試験される。 HardwareInterfaceIdentifier オブジェクトは活動化できるので、ここで、我々は終了する。このIDは"SCSI"をボトム・インタフェースとして指定している。（２）この時点で、我々は我々のサービス・スタックのトップ・インタフェースとボトム・インタフェースは知っている。次のステップでは、ファイル・システムが探索され、組合わせて必要なサービス・スタックを形成することができるサービスの集合を探す。注意： SCSIインタフェース識別子はボトム・サービスに渡される。SCSI識別子には、ボトム・サービスが取得することができるSCSIデバイス・ハンドルであって、SCSIプリンタと話すために用いることができるSCSI デバイス・ハンドルが含まれている。 TNetworkInterfaceReferenceを活動化するシナリオ：「トップ・インタフェース」が「printer」に設定されているTNe tworkInterfaceReferenceオブジェクトの場合であり、クライアントはそのActiv ate()メソッドをコールする。活動化は２つのステージ、すなわち、(I) スタック記述の作成と、(II) スタックの作成の２つのステージで行われる。 (I) スタック記述の作成：（１）スタック記述を作成するために、TNetworkReference オブジェクトがパフォームする第１ステップは、「ボトム」インタフェースを"MessageStream"に設定することである。（２）この時点で、我々はサービス・スタックのトップ・インタフェースとボトム・インタフェースを知っている。このステージの残りの部分は、THardwareI nterfaceReference と全く同じである。 (II)スタックの作成： TNetworkReference オブジェクトは次のような順序でスタックを作成する。・ TNetworkReference オブジェクトは最下位のTInterfaceMaker オブジェクトをスタック記述から作成する（TNetworkMaker オブジェクト）。・ TNetworkReference オブジェクトにTServiceReference オブジェクトが渡され、TNetworkReference オブジェクトはTServiceReference オブジェクトを活動化する。・ TInterfaceMaker オブジェクトはその対応するサービスを作成する（これはどれからでも派生することができる）。・ TInterfaceMaker オブジェクトはその初期化関数f() をコールし、f() に同じTServiceReference を渡す。ネットワーク・サービス・スタックの深さを２レベル以上にすることができる。 TNetworkInterfaceReferenceを活動化するシナリオ：「トップ・インタフェース」が「printer」に設定されているTNetw orkInterfaceReferenceオブジェクトの場合であり、クライアントはそのActivat e()メソッドをコールする。活動化は２つのステージ、すなわち、(I) スタック記述の作成と、(II) スタックの作成の２つのステージで行われる。 (I) スタック記述の作成：（１）スタック記述を作成するために、TNetworkReference オブジェクトがパフォームする第１ステップは、「ボトム」インタフェースを"MessageStream"に設定することである。（２）この時点で、我々はサービス・スタックのトップ・インタフェースとボトム・インタフェースを知っている。このステージの残りの部分は、THardwareI nterfaceReference と全く同じである。 (II)スタックの作成： TNetworkReference オブジェクトは次のような順序でスタックを作成する。・ TNetworkReference オブジェクトは最下位のTInterfaceMaker オブジェクトをスタック記述から作成する（TNetworkMaker オブジェクト）。・ TNetworkReference オブジェクトにTServiceReference オブジェクトが渡され、TNetworkReference オブジェクトはTServiceReference オブジェクトを活動化する。・ TInterfaceMaker オブジェクトはその対応するサービスを作成する（これはどれからでも派生することができる）。・ TInterfaceMaker オブジェクトはその初期化関数f() をコールし、f() に同じTServiceReference を渡す。ネットワーク・サービス・スタックの深さを２レベル以上にすることができる。 THardwareInterfaceReference をインスタンシエートする。シナリオ：コンピュータ・ビュワーはTHardwareModuleHandle オブジェクトを持つが、その対応するモデル・オブジェクトを既に作成している。 THardwareModuleHandleオブジェクトにより所有されるTHardwareInterfaceHandl eオブジェクトごとに、THardwareInterfaceReferenceオブジェクトを１つ作成し、そのモデルに付加する。（１）まず、THardwareInterfaceHandleオブジェクト（つまり、コネクタ）の反復子(iterator)を、THardwareModuleHandle オブジェクトに作成する。（２）次に、反復子から返された各THardwareInterfaceHandleオブジェクトごとに、次のように、THardwareInterfaceReference オブジェクトを作成し、そのモデルに付加する。 theModel.AddInterfaceReference(THardwareInterfaceReference(aHardwareIn terface)); TNetworkInterfaceReferenceをインスタンシエートする。シナリオ：ネットワーク・ブラウザの課題。手操作で接続したデバイス（"Let Resouces Find You"により構成する）の使用。シナリオ：ユーザはローカル・シリアル・ポートに接続されたプリンタを用いて、ドキュメントをプリントする。このシナリオは、THardwareInterfaceRefe rence をImageWriterII のプリンタ・インタフェースによりどのように使用できるかという例を示す。図２８はこのシナリオを示す。（１）ユーザはドキュメント・アイコンをImageWriter アイコン上にドラッグする。（２）このプリンタ・アイコンはこのドキュメント・アイコンを受け取る。このドキュメント・アイコンとこのプリンタとの協力により、ImageWriter を表す TPrinterオブジェクト２８０２に付加されるプリント・ジョブが作成される。（３） PrinterHandler オブジェクト２８０４は、TPrinterオブジェクト２８０２から渡されたTHardwareInterfaceReference オブジェクト２８０６に、 Activateをコールする。（４） THardwareInterfaceReferenceオブジェクトは適正なサービス・スタックを作成し参照を返す。手作業で接続されたデバイス（"You find the Resource"により構成する）を使用する。シナリオ：コンピュータ・ハードウェア・データベースを照会して、ImageW riter を探し、ImageWriterにアクセスすることを、誰かが望んでいる。（１）"AppleImageWriterII"をそのシグネチャ(signature)として持つTHardwa reModuleHandle オブジェクトを探すため、コンピュータ・ハードウェア・データベースを探索する。（２）適正なTHardwareInterfaceHandleオブジェクトをTHardwareModuleHandl e オブジェクトから取得する。（３）THardwareInterfaceReference を作成し、THardwareInterfaceHandleオブジェクトを渡す。（４）THardwareInterfaceReference オブジェクトのトップ・インタフェースを設定する。（５）参照オブジェクトを活動化し、ImageWriterII との通信を開始する。手作業で接続されたデバイスの接続を変更するシナリオ：このシナリオは、そのデフォルト・プリンタが特定のローカルIm ageWriter であるドキュメントが、ユーザがプリンタの接続を変更した後でも、依然として、そのプリンタにプリントする能力をもつことを説明する。このシナリオについては、「低レベル・ハードウェア構成ERS」を参照されたい。 3.3.12 開発者は新しいサービスを作成する。シナリオ：このERS で定義されたメカニズムを用いて、２つの新サービスを Pinkに導入するのに必要なクラスを示す。この新サービスとは、TxyzUARTに対するUARTサービスと、TpdqUARTに対するUARTサービスである。（１）図２９はmakerクラス図を示す。（２）図３０はservice クラス図を示す。注意：maker クラスとservice クラスの間には１対１の対応関係がある。陰影を付けたクラスは開発者が書いたものである。クラス・インタフェース TInterfaceReference クラス記述目的：このクラスの目的と、このクラスのインスタンスが何を表現しているかと、このクラスが何のために使用されるかと、その属性の意味は、上述の説明を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフではない。持続性： TInterfaceReference のサブクラスのインスタンスはいつでもファイルにセーブし、リストアすることができる。メンバ関数 void GetTopInterface(IntrfaceName&) const このInterfaceReferenceのトップ・インタフェースを取得する。クライアントがこのメソッドをコールすることはまれである。 void SetTopInterface(const InterfaceName&) このメソッドは、Activateに返させたいサービスのインタフェースを指定する。クライアントはActivateをコールする前に、このメソッドをコールしなければならない。 void GetBundles(TDictionary〈InterfaceName,TInterfaceBundle〉&) このInterfaceReferenceのTInterfaceBundleオブジェクトの全てで、コレクション引数を満たす。先に、ディクショナリを空にしない。クライアントがこのメソッドをコールすることはまれである。 void SetBundles(const TDictionary〈InterfaceName,TInterfaceBundle〉&) このInterfaceReferenceの現在のBundles 属性を削除し、ついで、所定のTDic tionary オブジェクトをコピー（クローン）し、新しいBundles属性にする。このInterfaceReferenceのそれ以後の活動化では、この新Bundles属性を用いる。I nterfaceReferenceが活動化したサービスが、サービス固有のデータを必要とする場合、クライアントがこのメソッドをコールする。詳しい説明はメーカ・サブクラスのActivateメソッドを参照されたい。 void GetPossibleTops(TCollection〈InterfaceName〉&) 現在、「インストール」されたサービスがシステム上にある場合、このInterf aceReferenceが現在サポートすることができるInterfaceName オブジェクトの全てで、コレクション引数を満たす。そのコレクションの各InterfaceNameオブジェクトは、サポートされたサービスの１つのタイプを識別する。クライアントはこのメソッドをコールして、所定のInterfaceReferenceに対して、どのサービスが利用可能であるかを判断する。コンピュータ・ビュワーは、コネクタ間でタイプ調停を行う間、このメソッドを用いる。シリアルがSCSIポートによりサポートされていないと、InterfaceReferenceが言う場合、例えば、ImageWriter をSCSI ポートに接続しようとしているユーザは、その接続が禁止されることになる。 TInterfaceMaker^*Activate() = ０このメソッドは、そのトップ・インタフェースがSetTopInterface() によって指定されたインタフェースをもっているサービス・スタックを作成する。ボトム資源はサブクラスに依存する。ボトム資源はハードウェア・コンポーネントか、ネットワーク・サービスか、あるいは、ソフトウェア・サービスにすることができる。このメソッドはクライアントにより直接にコールされる。指定されたタイプのTInterfaceMaker オブジェクトを指すポインタが返される。クライアントはこのポインタを適正なタイプにダウンキャストし、実サービス・オブジェクトを指すポインタを取得する。これが完了した後、クライアントはTInterfaceMaker ブジェクトを削除する必要がある。 TStream& operator>>=(TStream& toWhere) const interface reference オブジェクトの全体をtoWhere 引数にストリームアウトする。 TStream& operator<<=(TStream& fromWhere) interface reference オブジェクトの全体をfromWhere 引数からストリームインする。〜THardwareInterfaceReference() interface reference オブジェクトのみを破壊する。この破壊により、活動化されたサービスがあってもそのサービスには影響しない。 THardwareInterfaceReference() サブクラスは、空のTHardwareInterfaceReferenceオブジェクトを作成するため、コールすることができる。 THardwareInterfaceReference(const THardwareInterfaceReference& copyFrom) サブクラス・コール（コンストラクタをコピー）。 THardwareInterfaceReference& operator=(const THardwareInterface Referenc e& copyFrom) サブクラス・コール。ネットワーク・インタフェース参照クラス記述目的：このクラスの目的と、このクラスのインスタンスが何を表現しているかと、、何のためにこのクラスが使用されるかと、その属性の意味は、セクション３．２を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフでない。持続性： TInterfaceReference のサブクラスのインスタンスは、いつでもファイルにセーブし、リストアすることができる。メンバ関数 TNetworkInterfaceReference() ネットワークに接続されたサービスのデフォルト・インタフェース参照を作成する。Activateがコールされる前に、オブジェクトに「トップ」インタフェース名とサービス参照を渡しておかなければならない。さもないと、例外が引き起こされる。ストリーミングを行うのに有用である。 TNetworkInterfaceReference(const TServiceReference&) ネットワークに接続されたサービスに対するインタフェース参照を作成し、所定のinterface reference オブジェクトにより表現される。Activateがコールされる前に、オブジェクトに「トップ」インタフェース名を渡しておかなければならない。さもないと、例外が引き起こされる。〜TNetworkInterfaceReference() このinterface reference オブジェクトを破壊するが、活動化されたサービスがある場合は、そのサービスには影響を与えない。 TNetworkInterfaceReference(const TNetworkInterfaceReference& copyFrom) interface reference オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TNetworkInterfaceReference& operator=(const TNetworkInterfaceReference&c opyFrom) インタフェース参照オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TServiceReference^* CreateServiceReference() const このNetworkInterfaceReference のサービス参照属性のコピーを作成し返す。クライアントは返されたオブジェクトを採用する。クライアントがこのメソッド１を使用することはまずない。 void SetServiceReference(const TServiceReference&) このNetworkInterfaceReference のService Reference 属性を設定する。Netw orkInterfaceReference オブジェクトの作成者は、サービスを提供するネットワーク・サービスを指定するのにこのメソッドを用いる。 TInterfaceMaker^*Activate() このメソッドは、トップ・サービスがSetTopInterface() により指定されたインタフェースをもつネットワーク上のエンティティに対して、サービス・スタックを作成する。このメソッドはクライアントにより直接にコールされる。指定されたタイプのTInterfaceMaker オブジェクトを指すポインタが返される。クライアントはこのポインタを適正なタイプにダウンキャストし、実service オブジェクトを指すポインタを得る。これが完了したあと、クライアントはTInterfaceMa ker オブジェクトを削除する必要がある。 TStream& operator>>=(TStream& toWhere)const interface reference オブジェクト全体をストリームアウトしてtoWhere 引数に入れる。TStream& operator<<=(TStream& fromWhere) interface reference オブジェクトの全体をfromWhere 引数からストリームインする。 THardwareInterfaceReference クラスの記述目的：このクラスの目的と、このクラスのインスタンスが何を表すかと、このクラスが何のために使用されるかと、その属性の意味は、セクション３．２を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフではない。持続性： THardwareInterfaceReference のサブクラスのインスタンスは、いつでもファイルにセーブし、リストアすることができる。メンバ関数 THardwareInterfaceReference() ローカル・コンピュータに接続されたデバイスにより提供されたサービスに対するデフォルト・インタフェース参照を作成する。Activateがコールされる前に、オブジェクトに「トップ」インタフェースとTHardwareInterfaceHandleを渡しておかなければならない。さもないと、例外が引き起こされる。ストリーミングを行うときに有用である。 THardwareInterfaceReference(const THardwareInterfaceHandle&) ローカル・コンピュータに接続されたデバイスにより提供されたサービスのインタフェース参照を作成する。デバイスは所定のハードウェア・インタフェース・ハンドルによって識別される。Activateがコールされる前に、オブジェクトに「トップ」インタフェース名を渡しておかなければならない。さもないと、例外が引き起こされる。 THardwareInterfaceReference(const THardwareInterfaceIdentifier&) ローカル・コンピュータに接続されたデバイスにより提供されたサービスのインタフェース参照を作成する。デバイスは所定のハードウェア・インタフェース識別子により識別される。Activateがコールされる前に、オブジェクトに「トップ」インタフェース名を渡しておかなければならない。さもないと、例外が引き起こされる。〜THardwareInterfaceReference() interface reference オブジェクトを破壊するが、活動化されたサービスがある場合は、それに影響を与えない。 THardwareInterfaceReference(const THardwareInterfaceReference& copyFrom) interface reference オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 THardwareInterfaceReference& operator=(const THardwareInterfaceReference & copyFrom) interface reference オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 void SetTopInterface(const InterfaceName&，Boolean UseConnectorName) このメソッドは、Activateに返させようとするtop service オブジェクトのインタフェースを指定する。UseConnectorName引数がTRUEである場合、このtop In terfaceName 引数は基底クラス名として扱われ（タイプ検査のため）、サービス・スタックの実「トップ」インタフェース名はコネクタから検索される。UseConnectorName 引数がFALSE である場合は、このメソッドは通常のSetTopInte rface メソッドとして振る舞う。 THardwareInterfaceHand1e GetConnector() const このHardwareInterfaceReferenceのConnector 属性のコピーを返す。 Connector 属性は、物理ハードウェア上のコネクタであって、実際にサービスを提供するコネクタ（例えば、StyleWriter の背面のコネクタ）を表す。このコネクタはサービスをドライブするポートに接続されている（例えば、PCマザーボード上のシリアル・ポート）。クライアントがこのメソッドを使用するのは、まれである。HardwareIntefaceReference はこのメソッドを用いて、ボトム・インタフェースを判断する。 voidSetConnector(const THardwareInterfaceHand1e&) このHardwareInterfaceReferenceのConnector 属性を設定する。 HardwareInterfaceReferenceオブジェクトの作成者は、このメソッドを用いて、物理ハードウェア上のコネクタであって実際にサービスを提供するコネクタ（例えば、StyleWriter の背面のコネクタ）を指定する。 TInterfaceMaker^*Activated() このメソッドはローカル・コンピュータに接続されたデバイスに対するサービス・スタックを作成する。このサービス・スタックのトップ・サービスは、SetT opInterface() により指定されたインタフェースを有する。このメソッドはクライアントによって直接にコールされる。指定されたタイプのTInterface Maker オブジェクトを指すポインタが返される。クライアントはこのポインタを適正なタイプにダウンキャストし、実service オブジェクトを指すポインタを得る。これが完了したあと、クライアントはTInterfaceMaker オブジェクトを削除する必要がある。 TStream& Operator>>=(TStream& toWhere)const interface reference オブジェクトの全体をストリームアウトしてtoWhere 引数に入れる。 TStream& operator<<=(TStream& fromWhere) interface reference オブジェクトの全体をfromWhere 引数からストリームインする。 TInterfaceMaker クラスの記述目的：このクラスの目的と、このクラスのインスタンスが何を表すかと、このクラスが何に使用されるかと、その属性の意味は、セクション３．２を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフである。持続性：インタフェース・メーカは持続性がない。メンバ関数〜TInterfaceMaker() このinterface makerオブジェクトを破壊する。 TInterfaceMaker() interface maker サブクラスのデフォルト・インタフェース・メーカを作成する。 TInterfaceMaker(const TInterfaceMaker& copyFrom) interface maker オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TInterfaceMaker& operator=(const TInterfaceMaker& copyFrom) interface maker オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TUpperInterfaceMaker クラスの記述目的：このクラスの目的と、このクラスのインスタンスが何を表すかと、このクラスが何に使用されるかと、その属性の意味はセクション３．２を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフでない。持続性：インタフェース・メーカは持続性がない。メンバ関数 virtual void Activate(const TInterfaceMaker& below,const TInterfaceBundl e&)=０サブクラスはどの「実」service オブジェクトを作るべきかを知っている。TI nterfaceReference オブジェクトにbelow interface maker オブジェクトが渡され、TInterfaceReference オブジェクトによってこのメソッドがコールされる。このサブクラスはbelow interface maker オブジェクトをダウンキャストし、be low interface maker オブジェクトに実below サービスを要求する。そして、この実below サービスは、このinterface maker サブクラスにより作成されたserv ice オブジェクトに与えられる。TInterfaceReference オブジェクトがこのメーカに対応するトップ・インタフェースに関係付けをしたTInterfaceBundleを有する場合は、TInterfaceReference オブジェクトはTInterfaceBundleをこの機能に渡す。所定のTInterfaceBundleポインタがnil でない場合は、被コール側(calle e)は自分が期待するタイプにTInterfaceBundleを安全にダウンキャストすることができる。このオブジェクトには、特殊サービス固有情報（例えば、BAUDレート）が含まれる。〜TUpperInterfaceMaker() このinterface maker オブジェクトを破壊する。 TUpperInterfaceMaker() upper interface maker サブクラスのデフォルト・インタフェース・メーカを作成する。 TUpperInterfaceMaker(const TUpperInterfaceMaker& copyFrom) interface maker オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TUpperInterfaceMaker& operator=(const TUpperInterfaceMaker& copyFrom) interface maker オブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TAccessManagerMaker クラスの記述目的：このクラスの目的と、このクラスのインスタンスが何を表すかと、このクラスが何に使用されるかと、その属性の意味は、上述した説明を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフである。持続性： Interface Maker は持続性がない。メンバ関数 virtual void Activate(const THardwareInterfaceIdentifier& theMetal，cons t TInterfaceBundle&)=０サブクラスはどの実Access Managerオブジェクトを作るべきかを知っている。 TInterfaceReference オブジェクトにTHardwareInterfaceIdentifierオブジェクトが渡され、TInterfaceReference オブジェクトによりこのメソッドがコールされる。このメソッドは、AccessManagerMakerサブクラスにより作成されたAccess Manager オブジェクトに与えられる。バンドル・パラメタはTUpperInterfaceMak er::Activateに対して指定されたのと同じルールに従う。〜TAccessManagerMaker() このaccess manager makerオブジェクトを破壊する。 TAccessManagerMaker() upper interface maker サブクラスのデフォルトaccess manager makerを作成する。 TAccessManagerMaker(const TAccessManagerMaker& copyFrom) access manager makerオブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TAccessManagerMaker& operator=(const TAccessManagerMaker& copyFrom) access manager makerオブジェクトの全体を、copyFrom引数からこのオブジェクトにコピーする。 TInterfaceBundle クラスの記述目的：このクラスの目的と、このクラスのインスタンスが何を表すかと、このクラスが何に使用されるかと、その属性の意味は、上述した説明を参照されたい。派生クラス：このクラスは多態的である。並行性：このクラスはマルチスレッド・セーフである。持続性：インタフェース・バンドルは持続性がある。メンバ関数〜TInterfaceBundle() interface bundleオブジェクトを破壊する。 TInterfaceBundle() interface bundleサブクラスのデフォルトinterface bundleを作成する。 TStream& operator>>=(TStream& toWhere)const interface bundleオブジェクトの全体をストリームアウトしてtoWhere 引数に入れる。 TStream& operator<<=(TStream& fromWhere) interface bundleオブジェクト全体をfromWhere 引数からストリームインする。 TInterfaceBundle(const TInterfaceBundle& copyFrom) interface bundleオブジェクトの全体をcopyFrom引数からこのオブジェクトにコピーする。 TInterfaceBundle& operator=(const TInterfaceBundle& copyFrom) interface bundleオブジェクト全体をcopyFrom引数からこのオブジェクトにコピーする。その他の考慮事項２つ以上のスタック記述をあるActivateの間に生成するのは、可能である。所望のデバイスＩＤに対する要求されたトップ・サービスを提供することができる多くのサービス・スタックには、複数のパスが存在する。ヒューリスティックの中には、１つのスタックを解析し選択することになるものがある。クライアント、例えば、時間ベースのメディア(time-based media)は、種々のスタックを選択するため、中間層に非常に関心をもつことができる場合がある。中間層の特性は、種々のスタックを選択するに際して、好みにより構成することができる。マウス・デバイスが登録されていない場合には（デッド・マウス課題に関係する）、そのマウスのドライバを作成する能力がなければならない。考えられる解決法として次の２つがある。（１）マウス・ドライバを登録し、参照を活動化し、マウスを登録から除く。（２） CAMは、マウスの動きを検出すると、ドライバを作成する。サービスの作成を、その作成が必要になる時点まで、先に延ばすことが虞らく望ましい。例えば、ImageWriter に対するプリンタ・サービスの作成を、ユーザがdocumentをprinter にドラッグする時点まで先に延ばす。あるいは、ImageWri ter が接続されたことが分かったとき、即時に、サービスを作成することができる。好ましい実施の形態によれば、クライアントはどちらの選択も行うことができる。そのモデルにストアされたTDictionary にストアされたバンドルに、サービス固有のパラメータをストアして、シリアルImageWriter のBAUDレートを設定する。これらのパラメータは、ディクショナリ(dictionary)を受け取ると、そのディクショナリをTInterfaceReference にコピーする。設計決定 Interface Maker 最初にTInterfaceReference クラスを見たクライアントは、特定タイプのサービスを作成し返すことができる抽象化を目にする。残念ながら、TInterfaceReference は、maker クラスを導入したので、一見単純かつ平凡なオペレーションのようなものを不明瞭にしている。サービス・スタックをアクセスするため、クライアントはステップをもう１つ付け加えなければならなくなる。開発者は、maker クラスをコーディングせざる得ないので、余分の実装作業を負担することになる。その設計を理解するのに必要な余分な精神的な努力を、誰もが負担することになる。理由があって、異質のmaker クラスを扱わなければならないし、異質のmaker ラスを充分に理解するために、検討しなければならない課題が幾つかある。まず、図３１に示すようなTPresentableViews ３１０２の階層を綿密に調べる必要がある。TPresentableView ３１０２はTView ３１００のサブクラスである。 TPresentab1eView ３１０２は、システム全体にわたって多数のビューを表現するために使用される（例えば、コントロールと、編集可能テキストと、グリッド・ビューと、対話式ビューと、ムービーと、ペイン(panes)と、等々。これらは図３１に３１０４で示してある。）。全てのviewオブジェクトの間には共通の抽象化がある（例えば、ドローイングと、変形と、通知と、ヒット・テストと、他のビューのネストと、等々）。このことは、共通基底抽象化を示唆している。さらに、viewは大部分のユーザ・インタフェース・システムにより使用される。このことは、多態性の必要性を示唆している。次に、サービス・スタックを検討することにする。上述したように、サービスに対する共通クラス階層を避けることが望ましい。我々がこの目標を拒否した場合は、そのサービス階層は図３２に示すようなものにする必要がある。３２０６に関係付けをしたディスク・ドライバと、３２０８に関係付けをしたシリアル・ポート・プリンタと、３２０４に関係付けをしたプリンタと、３２０２に関係付けをしたマウス・ドライバの間には共通性はない。多態性に対する要件はない。サービス・スタックは、当該システムの各部にパッシングされることはない。多態性の要件は、全てTInterfaceReference クラスによってハンドルされる。従って、コンセプト上なにも存在しない所に、共通抽象化を要求する利点は、虞らくそれらの欠点を補い得ないであろう。実際には、maker クラスには有利な面がある。メーカを導入すれば、どのサービスもインタフェース参照フレームワークによりサポートすることができる。例えば、インタフェース参照が虞らく使用しないと思われるサービスが作成された場合、開発者がサービス・スタックのサービスを使用することは禁止されない。開発者は１つのmaker クラスを書くことだけが必要になる。（サービスを初めから書いたり、ラッパ(wrapper)を書いたりするよりも、作業量がはるかに少なくなる）。ラッパが必要になるのは、maker クラスがない場合である。これは、全てのサービスをTService ３２００から派生させる必要があることを、暗黙的に言っている。問題のクラスはそうではないので、開発者はTServiceの派生クラスでそのクラスを終わらせることになる。図３３は、１つのメーカ・クラスを追加すると、インタフェース参照フレームワーク内で、サービスを行うことが、開発者にとって、どれだけ容易かを示す。ディスク・ドライブ・サービスはインタフェース参照フレームワークによりサポートされていない（現時点では、そのサポートは必要でないと考えられている）。しかし、図３４では、「現在」、ディスク・ドライブ・サービスがインタフェース参照フレームワークによってサポートされている。（その必要が起こったため、maker が開発されたことによる）。以上、具体的なシステム環境における、本発明に係る好ましい実施の形態を説明したが、請求の範囲に記載の発明の精神と範囲を逸脱せずに、修正を加え、他の異なる環境で実施することができることは、当業者にとって当然のことである。

【手続補正書】特許法第１８４条の８【提出日】１９９５年１２月１８日【補正内容】（原文明細書第１頁）明細書オブジェクト指向システムにおけるサービスの作成著作権表記本出願には、一部に著作権保護の対象となる内容が含まれている。何人が、特許書類または特許開示内容をＥＰＯの記録の通りに複写複製しても、著作権者はそれを妨げるものではないが、そうでない場合には、一切の著作権を留保する。発明の分野本発明は、コンピュータ・システムの改良に関し、特に、オブジェクト指向オペレーティング・システムにおけるサービス作成のためのシステムおよび方法に関する。背景技術コンピュータ・システムは一般に非常に融通がきかない。情報が支障なく流れるシステムを提供するため、システムのアプリケーション開発者およびユーザは、ハードウェアのプロトコルと構成の詳細を熟知していなければならないことがしばしばある。ポートおよび入出力デバイスの特定のタイプの詳細を、個別に、取り扱わなければならない。アプリケーション開発者およびユーザも、コンピュータ・システムの変化に遅れをとらないようにしなければならない。これは、コンピュータ・システムの変化をソフトウェアとハードウェアに反映させて、その変化をフルに活用できるようにするためにである。 PROCEEDINGS OF THE 2ND INTERNATIONAL WORKSHOP ON OBJECT ORIENTATION IN OPERATING SYSTEMS，Dave et al.，"Proxies，Application Interfaces and Distributed Systems，pp.212-220，24 September 1992には、分散システムにおけるリモート・オブジェクトのローカルな担当者であるproxy オブジェクトが開示されている。このproxy オブジェクトは、Choices 分散オペレーティング・システムの透過的なＡＰＩ(Application Programming Interface)をコンストラクトするのに利用されている。RemoteProxies を付加すると、アプリケーションは、メソッドをオブジェクトに呼び出すだけで、一様な方法で、全ての資源にアクセスすることができる。このことは、これらのオブジェクトがローカルであっても、カーネル内にあっても、異なるユーザ・バーチャル・アドレス空間にあっても、リモートであっても可能である。proxy はサーバ・インタフェースの変化をサポートするため、リモート・オブジェクトおよびプロテクティド(protected) オブジェクトへのアクセスを適正化する。proxy メカニズムにより、メソッドをリモート・オブジェクトに呼び出すための新しいＲＰＣ(Remote Procedure Call ）ファシリティも説明されている。慣用のＲＰＣのインプリメントでスタブにより正規に提供される機能を全てパフォームするため、ルックアップ・テーブルを用いて、ＡＰＩを動的に構成させることができる。最後に、アプリケーション・コードを再コンパイルすることなく、このＡＰＩにより、新しいバージョンのサービスを導入することができる。入出力デバイスの変化の度合は、情報を入出力デバイスとの間で転送するために用いられる中間要素の変化の度合と同様に、非常に速い。システムのユーザはシステムを適正にパフォームさせることができるように、変化があるごとに、学習プロセスが必要である。コンピュータ・システムは、パフォームされるサービスを必要とするクライアントの大きな集まりと考えることができる。クライアントは、仮想的には、何かを必要とすることができるシステムの任意の部分と考えることができる。例えば、ＣＰＵは、システム内の特定の要素によりパフォームされるサービスを必要とするクライアントと考えることができる。サービスの性能には、要求されたサービスを提供するため、多くのステップと、多くの要素とを含めることができる。サービスは、システム内の別のエンティティが必要とする、なにかを提供するものと考えることができる。例えば、特定のチップは、特定のタイプのディジタル信号処理を、サービスとして、もう１つのシステム要素に提供することができる。請求の範囲１．プロセッサ（１０）とメモリ（１４）とを有するコンピュータ・システムであって、該コンピュータ・システムに通信媒体（３４）を介して接続されているデバイス（２３）を有するコンピュータ・システムにおいて、前記コンピュータ・システムに対して実行されるクライアント・アプリケーション（７００）に、前記デバイスへのサービスを提供するインタフェース参照フレームワーク（９００）であって、前記デバイスを前記コンピュータ・システムにどのように接続し、しかも、前記デバイスにアクセスする前記システム・サービスをどのように作成するかという詳細から、前記クライアント・アプリケーションを隔離するインタフェース参照フレームワークにおいて、（ａ）事前定義したインタフェース（１８０２）に従って通信を行う手段を有するサービス・オブジェクト（１８１０）をそれぞれ定義する複数のサービス・クラス定義（１７００，１７０４，１７０８）と、（ｂ）前記メモリ（１４）の複数のサービス・メーカ・クラス定義（１８０８）であって、サービス・クラス定義（１１００）のうちの１つのサービス・クラス定義から、対応するサービス・オブジェクト（１８１０）を作成する手段を有するサービス・メーカ・オブジェクト（１８０４）をそれぞれ定義する複数のサービス・メーカ・クラス定義（１８０８）と、（ｃ）前記デバイスに対応するインタフェース参照オブジェクト（１５０８）を、前記クライアント・アプリケーションに提供する手段とを備え、前記インタフェース参照オブジェクト（１５０８）は、前記クライアント・アプリケーションからトップ・インタフェースを受信して、デバイス（１５１４）へのサービスに対するプロトコルを定義する手段と、前記デバイスと通信を行うためのボトム・サービスを識別し、前記トップ・インタフェースに従って前記クライアント・アプリケーションと通信を行うためのトップ・サービスを識別し、事前定義したインタフェース（１７０２，１７０６，１７１０）に従って、前記通信媒体を介して、前記トップ・サービスおよび前記ボトム・サービスと通信を行うための中間サービスを識別するスタック記述を前記メモリで作成する手段と、前記スタック定義から、前記メモリで、サービスを作成する手段であって、前記トップ・インタフェースにより定義されたサービス・プロトコルに従って、前記デバイスと通信を行うために、前記クライアント・アプリケーションが前記サービス・スタックを用いることができるように、前記サービス・スタックへの参照を前記クライアント・アプリケーションに返す手段とを含み、前記サービス・スタックを作成する手段（１７１０）は、前記スタック記述を繰り返す手段であって、前記スタック定義で識別されたサービスに対して、前記サービス・メーカ・クラス定義のうちの１つの定義から、前記メモリで、対応するサービス・メーカ・オブジェクトを作成する手段（１７０８）と、トップ・サービス・オブジェクトが中間サービス・オブジェクトと通信し、該中間サービス・オブジェクトがボトム・サービス・オブジェクトと通信を行うサービス・スタックを作成するため、前記サービス・メーカ・オブジェクトを多態的に活動化して、対応するサービス・オブジェクトを、前記サービス・クラス定義のうちの１つの定義から作成する手段（１７００）とを含むことを特徴とするインタフェース参照フレームワーク。２．請求項１において、前記提供する手段は、前記コンピュータ・システムとローカルに接続されたデバイスに対するハードウェア・インタフェース参照クラス（２４１４）と、前記コンピュータ・システムにリモートに接続されたデバイスに対するネットワーク・インタフェース参照クラス（２６１４）を含み、前記ネットワーク・インタフェース参照クラスからインタフェース参照オブジェクトを作成するため、前記デバイスがローカルに接続されているか、リモートに接続されているかにより、前記クライアント・アプリケーションを実行している間、前記ハードウェア・インタフェース参照クラスと前記ネットワーク・インタフェース参照クラスから動的に選択することを特徴とするインタフェース参照フレームワーク。３．請求項１において、前記インタフェース参照オブジェクトは、前記ボトム・サービス（２６００）を指定することを特徴とするインタフェース参照フレームワーク。４．請求項１において、前記インタフェース参照オブジェクトは、構成フレームワーク（２９００）をアクセスして前記ボトム・サービスを判定することを特徴とするインタフェース参照フレームワーク。５．請求項１において、前記コンピュータ・システムは、該コンピュータ・システム内から、照会パラメタに基づき、サービスを動的に突き止めるロケータ手段を含み、前記スタック記述を作成する手段は、前記中間サービス（２９０６）を動的に突き止めるため、前記トップ・インタフェースおよび前記ボトム・インタフェースを、前記ロケータ手段への照会パラメタとして用いること特徴とするインタフェース参照フレームワーク。６．プロセッサ（１０）とメモリ（１４）とを有するコンピュータ・システムであって、該コンピュータ・システムに通信媒体（３４）を介して接続されているデバイス（２３）を有するコンピュータ・システムで、前記デバイスへのサービスを、前記コンピュータ・システムに対して実行されるクライアント・アプリケーション（７００）に提供する方法であって、前記デバイスを前記コンピュータ・システムにどのように接続し、しかも、前記デバイスにアクセスする前記システム・サービスをどのように作成するかという詳細から、前記クライアント・アプリケーションを隔離する方法において、（ａ）事前定義したインタフェース（１８０２）に従って通信を行う手段を有するサービス・オブジェクト（１８１０）をそれぞれ定義する複数のサービス・クラス定義（１７００，１７０４，１７０８）を提供するステップと、（ｂ）前記メモリ（１４）の複数のサービス・メーカ・クラス定義（１８０８）であって、サービス・クラス定義（１１００）のうちの１つのサービス・クラス定義から、対応するサービス・オブジェクト（１８１０）を作成する手段を有するサービス・メーカ・オブジェクト（１８０４）をそれぞれ定義する複数のサービス・メーカ・クラス定義（１８０８）を提供するステップと、（ｃ）前記デバイスに対応するインタフェース参照才ブジェクト（１５０８）を、前記クライアント・アプリケーションに提供するステップと（ｄ）前記クライアント・アプリケーションが、前記デバイスへのシステム・サービスに対するプロトコルを定義するトップ・インタフェースを、前記インタフェース参照オブジェクト（１５１４）に提供するステップと、（ｅ）前記デバイスと通信を行うためのボトム・サービスを識別し、前記トップ・インタフェースに従って前記クライアント・アプリケーションと通信を行うためのトップ・サービスを識別し、事前定義したインタフェース（１７０２，１７０６，１７１０）に従って、前記通信媒体を介して、前記トップ・サービスおよびボトム・サービスと通信を行うための中間サービスを識別するスタック記述を、前記インタフェース参照オブジェクトが前記メモリで作成するステップと、（ｆ）前記スタック記述を繰り返すステップであり、該スタック定義で識別されたサービスに対して、前記サービス・メーカ・クラス定義のうちの１つの定義から、前記メモリで、対応するサービス・メーカ・オブジェクトを作成するステップであり、トップ・サービス・オブジェクトが中間サービス・オブジェクトと通信を行い、該中間サービス・オブジェクトがボトム・サービス・オブジェクト（１７００）と通信を行うサービス・スタックを作成するため、前記サービス・メーカ・オブジェクトを多態的に活動化して、対応するサービス・オブジェクトを、前記サービス・クラス定義のうちの１つの定義から作成するステップであって、前記インタフェース参照オブジェクトが、前記スタック定義から、前記メモリで、サービス・スタック（１７１０）を作成するステップであり、前記トップ・インタフェース（１７０８）により定義されたサービス・プロトコルに従って、前記デバイスと通信を行うために、前記クライアント・アプリケーションが前記サービス・スタックを用いることができるように、前記サービス・スタックへの参照を前記クライアント・アプリケーションに返すステップとを備えたことを特徴とする方法。７．請求項６において、前記コンピュータ・システムは、該コンピュータ・システムとローカルに接続されたデバイスに対するハードウェア・インタフェース参照クラス（２４１４）と、前記コンピュータ・システムにリモートに接続されたデバイスに対するネットワーク・インタフェース参照クラスを含み、前記ステップ（ｃ）が、（ｃ．１）前記ネットワーク・インタフェース参照クラス（２６１４）からインタフェース参照オブジェクトを作成するため、前記デバイスがローカルに接続されているか、リモートに接続されているかにより、前記クライアント・アプリケーションを実行している間、前記ハードウェア・インタフェース参照クラスと前記ネットワーク・インタフェース参照クラスから動的に選択するステップを含むことを特徴とする方法。８．請求項６において、前記インタフェース参照オブジェクトは、前記ボトム・サービス（２６００）を指定することを特徴とする方法。９．請求項６において、前記インタフェース参照オブジェクトは、構成フレームワーク（２９００）によりアクセスして、前記ボトム・サービスを判定することを特徴とする方法。１０．請求項６において、前記コンピュータ・システムは、該コンピュータ・システム内から、照会パラメタに基づき、サービスを動的に突き止めるロケータ手段を含み、本方法は、（ｇ）前記スタック記述（２９０６）を作成するため、前記トップ・インタフェースおよび前記ボトム・インタフェースを、前記ロケータ手段への照会パラメタとして用いて、前記中間サービスを動的に突き止めるステップを含むこと特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．システム・サービスを行う装置であって、（ａ）プロセッサ手段と、（ｂ）該プロセッサ手段に接続されたストレージ手段と、（ｃ）インタフェース・オブジェクトを作成し管理するオブジェクト指向インタフェース・フレームワークであって、少なくとも１つのサービス・リクエストを受け取る手段を含むオブジェクト指向インタフェース・フレームワークと、（ｄ）サービス・リクエストに応答してサービスを作成する少なくとも１つのオブジェクトと、（ｅ）サービス・リクエストを行うクライアントとを具備したことを特徴とする装置。２．請求項１において、インタフェースを指定するクライアント手段を含むことを特徴とする装置。３．請求項１において、インタフェース参照を活動化し、しかも、前記少なくとも１つのオブジェクトを呼び出してサービスを作成するクライアント手段を含むことを特徴とする装置。４．請求項１において、サービス・リクエストに応答して作成されたサービスは、前記クライアントに関係付けをした変更にもかかわらず持続することを特徴とする装置。５．請求項１において、前記インタフェース・オブジェクトは特定のデバイスに対して、少なくとも１つのインタフェース参照オブジェクトを含むことを特徴とする装置。６．請求項５において、前記インタフェース参照オブジェクトはサービスを作成するのに必要な情報を含むことを特徴とする装置。７．請求項５において、前記インタフェース参照オブジェクトは少なくとも１つのインタフェース・メーカ・オブジェクトを作成することを特徴とする装置。８．請求項５において、前記インタフェース参照オブジェクトはサービスを作成し、該サービスへのアクセスを容易にする手段を含むことを特徴とする装置。９．請求項５において、前記インタフェース参照オブジェクトはサービスの記述を作成する手段を含むことを特徴とする装置。１０．請求項９において、記述を作成する手段は、サービス・スタックの記述を作成する手段を含むことを特徴とする装置。１１．請求項９において、サービスの記述を作成する手段は、サービス・リクエストを行うサービスの集合を探索する手段を含むことを特徴とする装置。１２．請求項１において、サービスの集合を判断する手段はインタフェース名を判断する手段を含むことを特徴とする装置。１３．請求項９において、少なくとも１つのインタフェース・メーカを参照する手段を含むことを特徴とする装置。１４．請求項１において、少なくとも１つのインタフェース・メーカ・オブジェクトを含むことを特徴とする装置。１５．請求項１４において、サービス・リクエストを行うためにサービス・スタックを作る手段を含むことを特徴とする装置。１６．サービス方法であって、（ａ）インタフェース・オブジェクトを作成し管理するオブジェクト指向インタフェース・フレームワークであって、少なくとも１つのサービス・リクエストを受け取る手段を含むオブジェクト指向インタフェース・フレームワークを提供するステップと、（ｂ）クライアントからサービス・リクエストを受け取るステップと、（ｃ）サービス・リクエストに応答してサービスを作成するステップとを具備したことを特徴とする方法。１７．請求項１６において、クライアントがインタフェースを指定するステップを含むことを特徴とする方法。１８．請求項１６において、サービスを作成するオブジェクトにサービスを作成させるインタフェース参照を、活動化するステップを含むことを特徴とする方法。１９．請求項１６において、クライアントに関連する変更があっても当該サービスとの関係付けをを維持するステップを含むことを特徴とする方法。２０．請求項１６において、インタフェース参照オブジェクトを特定のデバイスに提供するステップを含むことを特徴とする方法。２１．請求項２０において、インタフェース参照オブジェクトからの情報を用いてサービスを作成するステップを含むことを特徴とする方法。２２．請求項２０において、少なくとも１つのインタフェース・メーカ・オブジェクトを作成するステップを含むことを特徴とする方法。２３．請求項２０において、サービスを作成し、該サービスへのアクセスを可能にするステップを含むことを特徴とする方法。２４．請求項２０において、前記サービスを作成するステップは、サービスの記述を作成するステップを含むことを特徴とする方法。２５．請求項２４において、前記記述を作成するステップは、サービス・スタックの記述を作成するステップを含むことを特徴とする方法。２６．請求項２４において、前記サービスの記述を作成するステップは、サービス・リクエストを行うサービスの集合を探索するステップを含むことを特徴とする方法。２７．請求項２６において、前記サービスの集合を判断するステップは、インターフェース名を判断するステップを含むことを特徴とする方法。２８．請求項２４において、少なくとも１つのインタフェース・メーカを参照するステップを含むことを特徴とする方法。２９．請求項１６において、インタフェース・メーカ・オブジェクトを作成するステップを含むことを特徴とする方法。３０．請求項２９において、サービス・リクエストを行うサービス・スタックを作成するステップを含むことを特徴とする方法。