JPH08328838A

JPH08328838A - 分散オブジェクト環境における複数のオブジェクト・インタフェースのタイプ識別のためのシステム、及び方法

Info

Publication number: JPH08328838A
Application number: JP6860296A
Authority: JP
Inventors: Peter B Kessler; ピーター・ビー・ケスラー; Swee Boon Lim; スウィー・ブーン・リム; Peter Vanderbilt; ピーター・ヴェンダービルト; Michael L Powell; マイケル・エル・パウエル; Li-Wen Chen; リ−ウエン・チェン; Dwight F Hare; ドウエイト・エフ・ハーレ; Alan Snyder; アラン・スナイダー
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-03-24
Filing date: 1996-03-25
Publication date: 1996-12-13
Also published as: EP0733968A2; CA2171568A1; EP0733968B1; DE69621368T2; EP0733968A3; DE69621368D1

Abstract

(57)【要約】【課題】本発明の課題は、分散オフ゛シ゛ェクト環境における
個別タイフ゜の複数の定義に関し、動的及び静的タイフ゜支援を
行うシステムと方法を提供することにある。【解決手段】完全に範囲指定された、フ゜レフィックスを組み
込んだオフ゛シ゛ェクト名がオフ゛シ゛ェクトを区別するのに用いられ
る。この完全に範囲指定された名前は、インタフェース・リホ゜シ゛ト
リを介する動的タイフ゜の判定と、クライアント内で静的にコンハ゜イル
されたタイフ゜及びサーハ゛・スタフ゛・ルーチンの両方で使用される。イン
タフェース・リホ゜シ゛トリ内で、フ゜レフィックス名付け情報が各インタフェース定
義言語情報の根毎に提供され、同じインタフェース定義言語オフ゛
シ゛ェクト名を有するオフ゛シ゛ェクトに関する複数の定義が、これ
らの各定義が別のフ゜レフィックス名付け情報内にある場合に可
能となる。一実施例では、フ゜レフィックス名付け情報がフ゜レフィッ
クス・インタフェース定義オフ゛シ゛ェクトによって定義される。別の実施
例では、完全に範囲指定されたオフ゛シ゛ェクト名が、スタフ゛及び
スケルトン・コート゛・ルーチン内のインタフェース定義言語コンハ゜イラによって実
現される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト指向
アプリケーション開発、及びオブジェクト指向オペレー
ティング・システム開発に関し、より詳しくは、分散オ
ブジェクト・プログラミング環境においてオブジェクト
・インタフェースの展開を支援する方法、及びシステム
に関する。

【０００２】

【従来の技術】クライアント−サーバ・コンピューティ
ングは、通常分散されたコンピュータからなるネットワ
ーク上の、コンピュータ資源を管理するための有利なモ
デルである。サーバはコンピュータと、要求時に様々な
機能動作及びデータを提供する、コンピュータ上で実行
されるアプリケーション・プログラムからなる。クライ
アントはコンピュータと、こうしたサービスを要求する
アプリケーションからなる。クライアント及びサーバ
は、ネットワーク上の様々なコンピュータに分散される
ことがあり、また、クライアントまたはサーバ機能、ま
たはその両方を提供する個別アプリケーションによって
単一コンピュータ内に存在することもある。

【０００３】オブジェクト指向開発環境に基づくクライ
アント−サーバ・システムにおいて、サーバはオブジェ
クトを選択する機能を実施し、管理する。オブジェクト
はいくつかの状態、及び方法に関するパラメータととも
に方法を定義してそのオブジェクトの状態を操作する、
オブジェクトのインタフェースから成る。クライアント
は、オブジェクトの方法を呼び出してそのオブジェクト
を操作するコードである。

【０００４】分散オブジェクト・プログラミング環境に
おいて、クライアントはオブジェクト参照を介してオブ
ジェクトを呼び出すが、システム内のどこに呼び出され
たオブジェクトが存在するかという情報を有しておら
ず、即ち呼び出されたオブジェクトがどのコンピュータ
に記憶されているか、またはどのコンピュータでそれが
実行されているかという特別な情報を有していない。む
しろ、クライアントは、サーバを見つけ、サーバからの
全ての出力をクライアントに返送するオブジェクト要求
ブローカ(ORB)を介してオブジェクト参照を送信する。
ユーザに対してクライアントとサーバ、及び分散オブジ
ェクトの任意のグループは、オブジェクトが様々なコン
ピュータ・システムに分散されていても、統合されたア
プリケーションとして透過的に振る舞う。分散オブジェ
クト・プログラミング環境に関する１つの標準は、共通
オブジェクト要求ブローカ・アーキテクチャ(Common Ob
jectRequest Broker Architecture(CORBA))であり、オ
ブジェクト管理グループ(OMG)によって指定される。

【０００５】CORBA環境において、ORBが正しく要求を処
理するためには、ORBが処理するオブジェクトのそれぞ
れに対するインタフェース定義にアクセスする必要があ
る。このインタフェース定義は、２つのやりかたのうち
１つによって、ORBに対し利用可能となる。第１は、イ
ンタフェース定義がオブジェクト方法を表すスタブ(stu
b)ルーチンに直接組み込まれうるものである。スタブ
は、クライアント内で代理(proxy)オブジェクトを実施
する。サーバ・オブジェクトを呼び出すために、クライ
アントは、サーバ・オブジェクトの代理オブジェクトに
関する方法を呼び出す。代理オブジェクトのスタブ・ル
ーチンはORBと通信して、ORBに要求を伝送する。サーバ
・オブジェクトのインタフェースがクライアント内にコ
ード化されるため、このように、クライアントは、ORB
に対してサーバ・オブジェクトの所望の動作を指定でき
る。この処理は、C++のようなプログラミング言語で書
かれたクライアントに関するオブジェクト定義の静的な
チェックを提供する。クライアントはそのスタブを介し
て、クライアントが作成されたときにスタブ内にインタ
フェースが含まれていないオブジェクトにはアクセスで
きない。

【０００６】第２は、インタフェース定義が、ORBが動
的にインタフェース定義をアクセスするインタフェース
・リポジトリに持続的に記憶されうるものである。イン
タフェース・リポジトリによってクライアントは、クラ
イアントが定義されたときの、オブジェクトに関する情
報を有することなく、オブジェクトを直接呼び出すこと
ができる。クライアントがこうした呼び出しを行う場
合、クライアントは呼び出された方法の方法記号を得る
ためにインタフェース・リポジトリにアクセスする。ク
ライアントは、オブジェクト・サーバに対して好適に形
成された要求を構築し、動作結果を受け取るために、方
法記号を要求する。ORBもまた、この方法記号を使用し
て、その呼び出しのパラメータを動的にチェックする。
インタフェース・リポジトリにおいて、オブジェクトの
インタフェース定義は、オブジェクトが各動作のパラメ
ータとともに提供する動作の記述、起こりうる例外、及
び追加の情報内容を含む。各インタフェース定義は、そ
れ自身が内在するインタフェース情報を操作する動作を
有するインタフェース定義オブジェクトとして記憶され
ている。例えば、所与のサーバ・オブジェクトのインタ
フェースに関するインタフェース定義オブジェクトは、
要求に応答して、クライアントに、そのインタフェース
の記述を戻す。

【０００７】上述のように、クライアントは、最初にオ
ブジェクト参照を得ることによってオブジェクトを呼び
出す。クライアントは、そのオブジェクト参照に基づい
て、方法を呼び出して、所望のオブジェクトのインタフ
ェース定義を処理するインタフェース・リポジトリにお
けるインタフェース定義オブジェクトに対する別のオブ
ジェクト参照を得る。クライアントがオブジェクトのイ
ンタフェースを有している場合、クライアントはインタ
フェースで定義された方法、または属性をどれでも呼び
出すことができる。

【０００８】

【発明が解決しようとする課題】既存のCORBA指定（OMG
Object Request Broker 2.0 Interface Repository RE
P、OMG TCドキュメント94-11-7、omg.orgから匿名(anon
ymous)FTPによって入手可能）の下では、インタフェー
ス・リポジトリは首尾一貫したものであり、一つには、
オブジェクトの各タイプに関するインタフェース・レポ
ジトリにおいて、１つのインタフェース定義だけが存在
することを意味している。上述のように、各オブジェク
トはインタフェースを有し、そのインタフェースは、TC
ドキュメント93-12-43におけるOMGによって定義されるI
DL内のような、インタフェース定義言語ファイル内の宣
言によって記述される。各インタフェース定義は範囲指
定された名前を有している。２つのオブジェクトは、そ
れらのインタフェース宣言が同様に範囲指定された名前
を有する場合、同じタイプである。このことは、インタ
フェース宣言で与えられた名前を有するインタフェース
定義オブジェクトがユニークに決定されうることを保証
するために必要である。２つのインタフェース定義オブ
ジェクトが１つの所与のタイプのオブジェクトに関連づ
けられている場合に、その決定がタイプ名に基づいて行
われると、名前の競合が発生する。

【０００９】このアーキテクチャは持続性のあるインタ
フェースを使用した正確なオブジェクトの識別を保証す
るが、それはオブジェクト・インタフェースを時間外に
展開するシステム開発の、より現実的なモデルの妨げと
なる。オブジェクト・インタフェースの展開はほとんど
のシステムの通常の態様であり、従ってインタフェース
の展開を支援することはインタフェース・リポジトリに
とって好ましいことである。

【００１０】例えば、好適なシステムの初期設定におい
ては、展開環境と開発環境の２つの環境が共存しうる。
展開環境では、オブジェクトとそれらのインタフェース
が変更されずに持続される。これは、各オブジェクトが
持続性を有し、完全にテストされ、及び全てのクライア
ントに知られることを保証するために必要である。しか
し、開発環境では、オブジェクト・インタフェースは連
続的に開発され、変更される。これらの２つの環境は、
クライアントがオブジェクトの特定のインタフェースを
期待している場合に、展開環境におけるクライアント呼
び出しが、クライアントが期待しているような振る舞い
をしない、開発環境のバージョンのオブジェクトを呼び
出さないように、別々に保持されなければならない。し
かし、開発環境のバージョンのオブジェクトに持続性が
ある場合、全てのクライアントが使用できるように、そ
のオブジェクトを展開環境に配置する必要がある。

【００１１】単一システムで単一インタフェース・リポ
ジトリを使用する場合、同一タイプの複数オブジェクト
が異なるインタフェース定義オブジェクトによって表現
されるように、展開環境と開発環境を分離する簡単なや
り方が現在ないことは問題である。従って、展開環境と
開発環境のオブジェクトを区別するために、開発環境の
オブジェクトは、それら自身のインタフェース定義オブ
ジェクトを有する、展開環境のオブジェクトとは異なる
タイプでなければならない。その他の場合、即ちオブジ
ェクトのインタフェースが、追加または削除された方法
で更新される場合、オブジェクト参照を保持する既存の
クライアントは、これらのクライアントがそのオブジェ
クトの前のインタフェースを期待しているために、故障
する。

【００１２】新しいオブジェクト参照をインストールす
るために、より重要な点は、いくつかのクライアントが
現在のインタフェースを使用し、いくつかのクライアン
トが新しいインタフェースを実行して、現在展開されて
いるオブジェクトの動作と、更新された開発環境のオブ
ジェクトの動作に関するオブジェクト・インタフェース
を、両方同時に有することが最も望ましいということで
ある。このことによって円滑なインタフェース間の遷移
が達成される。しかし、単にOMG指定に準じるインタフ
ェース・リポジトリの動作では、単一オブジェクト・タ
イプに関する複数のインタフェース定義オブジェクトを
使用可能としていない。所与のタイプのオブジェクトに
関する第１のインタフェース定義オブジェクトが既に存
在している場合に、第２のインタフェース定義オブジェ
クトを挿入するよう要求があった場合、こうしたインタ
フェース・リポジトリは、第２のインタフェース定義オ
ブジェクトを入力して第１のインタフェース定義オブジ
ェクトを削除するかまたは、その要求を無効なものとし
て排除する。インタフェース・リポジトリが第２のイン
タフェース定義オブジェクトの挿入を可能としていれ
ば、オブジェクト名によってインタフェースを決定す
る、後続のいかなるクライアント要求も、曖昧な結果と
なる。

【００１３】この問題に対して、CORBA標準は、複数の
インタフェース・リポジトリを使用して、開発環境を展
開環境と分離することを示唆している。このアプローチ
は、展開環境内の既存の共有リソース、または既存のク
ライアント・オブジェクトを用いて開発環境のオブジェ
クトを完全にテストするために、オブジェクト開発者の
能力を厳密に制限している。既存のクライアントでテス
トを行うために、展開環境のオブジェクトは、開発環境
で重複していなければならず、結果的にシステム資源に
対して、より多くの要求を行うことになる。

【００１４】更に、新しい、または更新されたオブジェ
クト・インタフェースを、開発環境及び展開環境に関す
る別のインタフェース・リポジトリでインストールする
ために、展開環境のインタフェース・リポジトリはシャ
ットダウンされなければならず、その結果、新しいイン
タフェースが古いインタフェースの代わりにインストー
ルされる。このことは、システムに関して受け入れがた
い動作上の負担を強いる可能性があり、銀行システム、
またはオンライン取引処理システムのような継続的な稼
働が必要な大規模システムで使用することはできない。

【００１５】従って、オブジェクト要求に関する正しい
インタフェース識別とタイプのチェックを提供する一
方、単一のインタフェース・リポジトリで所与のオブジ
ェクト・タイプに関する複数のインタフェース定義オブ
ジェクトを維持できる、改良されたシステムを提供する
ことが好ましい。

【００１６】

【課題を解決するための手段】本発明は、上述の制限
を、オブジェクトに対して、オブジェクトを異なる名付
け情報で識別するプレフィックスを含む、完全に範囲指
定されたオブジェクト名を提供することによって克服す
るものである。本発明の一実施態様では、単一のインタ
フェース・リポジトリが、インタフェース定義オブジェ
クトの様々なグループに関するIDLの根情報である、多
くのプレフィックス名付け情報を含む。各プレフィック
ス名付け情報において、別のプレフィックス名付け情報
のオブジェクトで同じIDL名を有するオブジェクトに関
するインタフェース定義オブジェクトが存在しうる。各
インタフェース定義オブジェクトが、プレフィックス名
付け情報からなる名前を含む、完全に範囲指定された名
前を有するために、名前の競合が回避され、それによっ
て、様々なオブジェクトのタイプが提供される。本発明
のこの態様における好適実施例では、プレフィックス名
付け情報はプレフィックス・オブジェクトによって定義
される。この実施例では、インタフェース・リポジトリ
・ローダが、IDL宣言を含むIDLファイルを指定されたプ
レフィックス名付け情報にロードし、必要であればプレ
フィックス名付け情報を作成する。インタフェース・リ
ポジトリ・ローダは更に、各IDL宣言毎にプレフィック
ス名付け情報を識別する、新しいタイプのデータ・ファ
イル、ifrファイルを作成する。

【００１７】本発明の別の態様では、完全に範囲指定さ
れた名前が、オブジェクト要求ブローカ環境にアクセス
する、クライアント・スタブ、及びサーバ・スケルトン
・コード・ルーチンで使用される。この完全に範囲指定
された名前は、静的に指定されたオブジェクト・タイプ
が正しく識別され、クライアント・オブジェクトにアク
セスされることを可能とする。本発明のこの態様におけ
る好適実施例では、IDLコンパイラがスタブ、及びスケ
ルトン・コード・ルーチンを生成する。

【００１８】

【発明の実施の形態】図１を参照すると、本発明で改良
されたインタフェース・リポジトリを使用するためのシ
ステムが示されている。システム100は、サーバとクラ
イアント、その他を含む、オブジェクト実施のコード、
及びデータを長期間記憶するための２次記憶装置107を
有するホスト・コンピュータ101、コマンドとデータを
システム100内に受信し出力するための入力装置109と出
力装置116、及びプロセッサ111で実行中の、サーバとク
ライアント実施コードを記憶するアドレス指定可能メモ
リ113を含む。プロセッサ111での実行中、サーバ117と
クライアント105のオブジェクトはアドレス指定可能メ
モリ113内の処理として存在する。追加のサーバ・オブ
ジェクト117、及びクライアント105は、ネットワーク10
3に沿って接続された他のホスト・コンピュータ101（図
示せず）内の処理として実行可能であり、またホスト・
コンピュータ101のどれか１つの中の別の処理として実
行可能であり、あるいは、同じ処理として実行可能であ
る。各クライアント105は、ネットワーク103上のホスト
・コンピュータ101内のサーバ・オブジェクト117からサ
ービス、またはデータを要求する。ホスト・コンピュー
タ101は、アメリカ合衆国カリフォルニア州マウンテン
・ビューのSun Microsystems,Inc.によって製造されたS
PARCステーション^TMコンピュータのような、最も一般的
な汎用コンピュータによって実現されうる。他の任意の
汎用コンピュータも、本発明の使用に適用することがで
きる。ホスト・コンピュータ101は、Sun Microsystems
のSolaris^TMオペレーティング・システムのような汎用
オペレーティング・システムを実行する。

【００１９】システム100は、CORBA標準を満足するオブ
ジェクト要求ブローカ環境を組み込んでおり、CORBA標
準は、「The Common Object Request Broker:Architect
ure and Specification」第1.2版、OMG TCドキュメント
番号93-12-43でオブジェクト管理グループによって設定
されており、omg.orgから匿名(anonymous)FTPによって
入手可能である。分散オブジェクト・システムの他の同
等の環境も使用されうる。好適実施例においては、オブ
ジェクト要求ブローカ環境は、Sun Microsystemsのプロ
ジェクトDOE(徹底した分散オブジェクト)である。従っ
て、システム100はオブジェクト要求ブローカ(ORB)115
を含み、CORBA仕様で定義された機能を提供する。要す
るに、ORB 115は、クライアント105からのサービスに関
する要求を処理し、要求をサービスする適当なオブジェ
クト実施を決定し、その要求をオブジェクト実施に伝送
し、その要求に対する応答をオブジェクト実施からクラ
イアント105に伝送する。ORB 115によって、サービス提
供オブジェクトのインタフェースが、オブジェクト実施
の位置、及び言語に全く依存しなくなった。各クライア
ント105は、ORB 115と通信するためのスタブ・コード・
ルーチン137を含む。各サーバ・オブジェクト117も同様
に、ORB 115と通信するためのスケルトン・コード・ル
ーチン139を有する。

【００２０】システム100には、本発明に従うインタフ
ェース・レポジトリ119も提供される。インタフェース
・レポジトリ119は、更にここで記述される改良部分と
共に、CORBA仕様に記述された基本機能を提供する。イ
ンタフェース定義言語コンパイラ135が、インタフェー
ス定義言語ファイルをコンパイルして、オブジェクトが
直接ORB 115をアクセスできる、クライアント・スタブ1
37とサーバ・スケルトン139コード・ルーチンを生成す
る。インタフェース定義言語ファイルは、OMGによって
定義されたIDLのような、任意の適当な言語で書くこと
ができる。容易に参照が行えるように、ここで参照する
インタフェース定義言語は「IDL」と呼ばれるが、これ
は任意のインタフェース定義言語を含むものであって、
IDLに限定されるものではない。インタフェース・リポ
ジトリ・ローダ、IFRローダ143は、指定されたIDLファ
イルをとり、その中に含まれたインタフェース宣言をイ
ンタフェース・リポジトリ119にロードする。IFRローダ
143の動作は、以下で更に詳細に説明する。

【００２１】ここで図２を参照すると、本発明のインタ
フェース・リポジトリ119の一実施例が更に詳しく示さ
れている。この実施例においては、インタフェース・リ
ポジトリ119が、システム100内の様々なオブジェクトの
インタフェースに関連した階層的な情報を定義する、多
くの名付け情報を含む。好適実施例において、名付け情
報は、インタフェース定義オブジェクトによって例示さ
れる。

【００２２】より詳しくは、特定のインタフェース定義
オブジェクトを、オブジェクト名またはリポジトリ識別
子によって見つける動作を含む、インタフェース・リポ
ジトリ119を広範にアクセスするための多くの動作を提
供する単一のリポジトリ・オブジェクト121が提供され
る。システム100内の各オブジェクトの定数、タイプ、
例外、動作、及び属性を定義するインタフェース・オブ
ジェクト123を含む、他のインタフェース定義オブジェ
クトも提供される。インタフェース・オブジェクト123
によって定義される名付け情報の一部となりうるモジュ
ール・オブジェクト125、例外オブジェクト129、動作オ
ブジェクト141、及び引数オブジェクト143を含む、他の
インタフェース定義オブジェクトも提供される。これら
のオブジェクトのそれぞれは、他のインタフェース定義
オブジェクトに関するコンテナとして作用し、それによ
って名付け情報の階層的配列を提供できる。非コンテナ
・インタフェース定義オブジェクトは、定数オブジェク
ト127、及びtypedefオブジェクト131を含む。これらの
インタフェース定義オブジェクトは、インタフェース・
リポジトリ119内の葉ノードとして配置される。インタ
フェース・リポジトリ119内のインタフェース定義オブ
ジェクトは、オブジェクト・インタフェースを定義する
のに用いられるIDLファイルから導出されることが望ま
しい。同時に、インタフェース定義オブジェクトは、ク
ライアント・オブジェクトによる要求に応答して、オブ
ジェクトのインタフェースを位置づけるように横断され
うる、階層名前空間を形成する。

【００２３】インタフェース・リポジトリ119、または
インタフェース定義オブジェクトによって、所与のタイ
プのオブジェクトに関する複数のインタフェース定義
が、単一のインタフェース・リポジトリ内でアクセスさ
れる場合に生じる問題を克服するために、インタフェー
ス・リポジトリ119とインタフェース定義オブジェクト
はその中に、２つの特徴を更に有する。１つは、インタ
フェース・リポジトリ119が少なくとも１つのプレフィ
ックス・オブジェクト133を、名前空間の階層を定義す
るための利用可能なインタフェース定義オブジェクトの
１つとして含むことである。プレフィックス・オブジェ
クト133は、インタフェース・リポジトリ119内に名付け
情報を定義する。通常の実施例においては、多くのこう
したプレフィックス名付け情報が存在可能で、それぞれ
は別々のプレフィックス・オブジェクト133によって定
義される。各プレフィックス・オブジェクト133は、そ
のオブジェクトに従属するインタフェース定義オブジェ
クトに関するIDL根情報である。各プレフィックス・オ
ブジェクト133は、様々な名付け情報を分離するのに用
いられうる、ユーザ選択のプレフィックスを表す。例え
ば、２つのプレフィックス・オブジェクト133が、「展
開」及び「開発」といった識別プレフィックスを記憶す
るために作成され、それによって、システム100の展開
環境と開発環境を分離する。それらはまた、「SunSof
t」や「DEC」といった様々なメーカからオブジェクトを
区別するのにも使用されうる。プレフィックス名付け情
報はまた、様々なコンピュータ・システムの箇所、様々
な会社の部署、またはシステム100のユーザに対して有
益な他の任意のタイプを区別するのにも用いられる。本
明細書におけるプレフィックス・オブジェクト133とプ
レフィックス名付け情報に対する参照は、例によるこう
した１つ、または２つの実体を指しているが、任意の数
のプレフィックス名付け情報とプレフィックス・オブジ
ェクト133が、本発明に従う単一インタフェース・リポ
ジトリ119で使用できることが理解される。

【００２４】第２は、インタフェース・リポジトリ119
内の各インタフェース定義オブジェクトが、「foo」の
ようなオブジェクトの簡単な名前と、それが配置されて
いる名付け情報のそれぞれを含むオブジェクト名を有
し、上位のプレフィックス・オブジェクト133によって
定義される名付け情報を含む。図３は本発明に従うイン
タフェース・リポジトリ119の一例を、銀行システムで
使用されているものとして示している。ここでは、３つ
のプレフィックス・オブジェクト133が垂れ下がってい
るリポジトリ・オブジェクト301、展開オブジェクト303
a、開発オブジェクト303b、及び共通オブジェクト303c
が示されている。展開オブジェクト303aの下には、更に
銀行モジュール・オブジェクト317a、口座オブジェクト
305a、借方オブジェクト307a、貸方オブジェクト309aの
ようなインタフェース定義オブジェクトがある。これら
のオブジェクト305aないし309aのそれぞれは、それらが
様々なクライアントへのサービスを提供するオブジェク
トのインタフェースを定義するための、インタフェース
・オブジェクト123である。従って、口座オブジェクト3
05aは更に、名付け情報の一部として、口座残高オブジ
ェクト311a、引き出しオブジェクト313a、及び預金オブ
ジェクト315aのような、下位のインタフェース定義オブ
ジェクトを含む。これらのインタフェース定義オブジェ
クトのそれぞれは、口座オブジェクト305aのインタフェ
ースによって支援される様々な動作を定義する。同様
に、開発オブジェクト303bの下では、それぞれのオブジ
ェクトの性能を改良するために銀行の開発者によって、
例えば新しい動作を追加したり、不要な動作を削除した
りするといった更新が現在なされている、インタフェー
ス定義を表している同様のオブジェクト305bないし315b
がある。

【００２５】オブジェクト305ないし317のオブジェクト
名は、それらの上位のプレフィックス・オブジェクト13
3を含む、名付け情報のフルパスを含んでいる。従っ
て、展開オブジェクト303aの下の展開プレフィックス名
付け情報において、口座残高オブジェクト311aは、オブ
ジェクト名「展開/銀行/口座/残高」を有するが、開発
オブジェクト303bの下の開発プレフィックス名付け情報
内にある、他の口座残高オブジェクト311bは、「開発/
銀行/口座/残高」というオブジェクト名を有する。従っ
て、プレフィックス名付けオブジェクト133を使用する
ことによって、所与のオブジェクト・タイプに対して複
数のインタフェース定義オブジェクトを明確に区別する
ことが可能になる。

【００２６】好適実施例において、本発明のインタフェ
ース・リポジトリ119は、それがオブジェクトに関する
要求を受け取ったときに、オブジェクト名のフル・プレ
フィックスを処理し、従って、所与のオブジェクト・タ
イプの２つのインタフェース定義オブジェクトの間で起
こりうる名前の競合を解決することができる。こうし
て、単一のインタフェース・リポジトリ119が単一のオ
ブジェクト・タイプに対応する複数のインタフェース定
義オブジェクトを維持できる。これよって、両方のイン
タフェース定義オブジェクトのクライアントを同時にシ
ステム100上で表現できる。従って、所与のオブジェク
トのインタフェースが、その展開バージョンのインタフ
ェースと一致して、かつ展開バージョンのインタフェー
スと同じシステム内で、変更され、更新されうる。これ
によって、開発環境バージョンは、システム資源の重複
無しに、他の既存のクライアント・オブジェクトを用い
てテストされる。これは、オブジェクト・インタフェー
スの現在のバージョンから改良されたバージョンへの遷
移を更に容易にする。プレフィックス名付け情報を用い
て、改良されたインタフェース・リポジトリ119は、現
在及び更新されたインタフェース両方に関する複数のク
ライアント・オブジェクトを支援できる。更に、更新さ
れたインタフェース定義オブジェクトの遷移及びインス
トールは、システム100のシャットダウンを必要としな
い。

【００２７】システム動作上記の改良されたシステム・アーキテクチャとともに、
本発明は、IFRローダ143とIDLコンパイラ135の両方に関
する改良された動作を提供する。これらの動作は、プレ
フィックス・オブジェクト133を使用してインタフェー
ス・リポジトリ119を作成、変更し、プレフィックス・
オブジェクト133によって提供された名付け情報を組み
込んでいるクライアント・スタブ137とサーバ・スケル
トン139を生成する。

【００２８】ロード・インタフェース・リポジトリインタフェース・リポジトリ119は、インタフェース定
義オブジェクトを作成し、保持する機能と協働する。こ
の機能はIFRローダ143である。図４は、本発明に従って
インタフェース・リポジトリ119のロードを行う際のIFR
ローダ143の機能動作を例示するフローチャートであ
る。

【００２９】IFRローダ143は呼び出されて(401)、新し
いIDLファイルをロードし、システム100内のオブジェク
トのインタフェースを記述する。IFRローダ143は、IDL
ファイル、またはロードされるファイルを示す引数と、
IDLファイルの結果のインタフェース定義オブジェクト
が記憶されるプレフィックス名付け情報の名前を送信す
る。例えば、一例として、「new_object.idl」がロード
されるべきIDLファイルのファイル名であり、「展開(de
ployment)」がインタフェース定義の配置されるべきプ
レフィックス名付け情報を定義するプレフィックス・オ
ブジェクト133を識別する場合、コマンド行引数は「ifr
load new_object.idl -p deployment」という形式をと
る。この後者の引数は、IFRローダ143がIDLの根情報の
下位のどこかを識別する。

【００３０】IFRローダ143は、供給されたプレフィック
ス引数に対応するプレフィックス・オブジェクト133に
よって定義される名付け情報が存在するかどうかを判定
する(403)。まだこうしたプレフィックス・オブジェク
ト133が存在していない場合、IFRローダ143は、プレフ
ィックス引数内で供給された対応するオブジェクト名
で、新しいプレフィックス・オブジェクト133を作成す
る(405)。このプレフィックス・オブジェクト133はリポ
ジトリ・オブジェクト131の下に配置され(407)、その下
位のIDL定義に関するIDL根情報になる。例えば、図３に
示されたインタフェース・リポジトリ119が、空の状態
からコマンド「ifrload bank.idl -p deployment」で最
初にロードされると、展開オブジェクト303aが根のリポ
ジトリ・オブジェクトの下位のプレフィックス・オブジ
ェクト133として作成され、bank（銀行）.idl内のIDL定
義が展開プレフィックス名付け情報内に配置される。指
定されたプレフィックスを有するプレフィックス・オブ
ジェクト133が存在する場合、IFRローダ143は処理を継
続する。

【００３１】IFRローダ143は指定されたIDLファイルを
読み取り(409)、その中に含まれるIDL宣言を得る。多く
の例で、所与のIDLファイル内に、他のファイルで定義
された参照シンボルやトークンが存在する。例えば、オ
ブジェクト動作のインタフェース定義が、他のIDLファ
イル内に定義されたタイプを返すこともある。また、ID
Lファイルが様々なライブラリ関数を参照することもあ
り、また同様のものが動作を定義する際に使用されるこ
ともある。これらの他のIDLファイルは、IDLファイル内
のインクルード(include)ステートメントによって参照
されるかまたは、他のインタフェース定義言語での同様
の構造によって参照される。しかし、インクルードされ
たファイル内のオブジェクト・タイプは、プレフィック
ス制限名によって完全に範囲指定された名前ではなく、
むしろインタフェース宣言で使用されたIDL名のみによ
って完全に範囲指定された名前によって定義される。

【００３２】例えば、IDLファイルのaccount.idlは、
「#include "datatypes.idl"ステートメントによってda
tatypes（データ・タイプ）.idl内に定義されたリター
ン・タイプを参照するオブジェクト動作を有することが
できる。

【００３３】

【表１】

【００３４】ここで、残高(balance)動作のリターン・
タイプは「金(money)」であり、これはインクルードさ
れたdatatypes.idlファイル内で定義されている。イン
タフェース・リポジトリ119内でインストールが行われ
ると、こうした動作に関するインタフェース定義オブジ
ェクトは、インタフェース・リポジトリ119内に定義さ
れたリターン・タイプのインタフェース定義オブジェク
トを参照する必要がある。しかし、プレフィックス・オ
ブジェクト113の追加によって、複数のプレフィックス
名付け情報内で定義されたインタフェース「datatypes/
money」を有することができる。複数のプレフィックス
名付け情報内で定義されるトークンに対する参照はどれ
も曖昧になる。従って、IFRローダ143は、その参照を明
確にして、適当なリターン・タイプ情報のようなトーク
ンの定義を提供できなければならない。これは、以下の
好適実施例で実施される。

【００３５】IFRローダ143は、IDLファイルが「インク
ルード」ステートメントを使用した、他のIDLファイル
に対する参照を含んでいるかどうかを判定する(411)。
インクルード・ステートメントが見つかると、IFRロー
ダ143は、そのインクルードされたファイルを得る(41
3)。IFRローダ143はインクルードされたファイルのディ
レクトリを読み取って、サフィックス「ifr」に続く名
前を有するIDLファイルが存在するかどうかを判定する
(415)。このifrファイルは、IDLファイルが以前にロー
ドされている場合に、インクルードされたIDLファイル
に関するインタフェース定義が下に配置される、プレフ
ィックス・オブジェクト133の名前を含む、新しいタイ
プのデータ・ファイルである。例えば、図３に関して、
「ifrload -p common datatypes.idl」は、datatypes.i
dlファイルを、「共通(common)」と呼ばれるプレフィッ
クス・オブジェクト303cによって定義されたプレフィッ
クス名付け情報にロードする。この名付け情報は、デー
タ・タイプの定義のような、展開環境と開発環境の両方
が共通して利用できる情報を含んでいる。IFRローダ143
は、ここでは共通(common)の、データ・タイプ・ファイ
ル内の定義が下に配置される、プレフィックス・オブジ
ェクトの名前を含むdatatypes.ifrというファイルを別
々に作成する。datatypes.ifrのようなifrファイルは、
インクルードされたIDLファイルと同じディレクトリか
または、階層的に類似するファイルに記憶される。当業
者には、「ifr」というサフィックスが単に、ファイル
を他のタイプのファイルと区別するために用いられるも
のであり、それらの中身自身は重要ではないことが理解
できる。他の適当なファイル名に関する技法が使用され
て、IFRローダ143に関するファイルを明確に識別するの
に用いられる。

【００３６】インクルードされたIDLファイルに関するi
frファイルが利用可能である場合、IFRローダ143がその
ifrファイルを読み取り(419)、そこに記憶された名付け
情報に関する情報を得る(421)。このことによって、IFR
ローダ143が参照を解決でき、オブジェクト・タイプ、
インタフェース・タイプ、データ・タイプ、例外その他
に関する正しい情報を得ることができる。こうして、共
通オブジェクトの既存のインタフェース定義、または他
の既存のオブジェクトはインタフェース・リポジトリ11
9内の任意のインタフェース定義オブジェクトに対して
利用可能であり、それによって新しいインタフェース定
義オブジェクトが、曖昧さを増大させることなくインタ
フェース・リポジトリ119内に統合されうる。ifrファイ
ルが見つからなかった場合は、IFRローダ143が例外を発
生させて(417)終了するかまたは、定義されたシステム
全般のデフォルト・プレフィックスを選択して(418)処
理を続けるといった、その他の任意の好ましい行動をと
る。

【００３７】IDLファイル、及びインクルードされたフ
ァイルからのインタフェース定義とともに、適当なイン
タフェース定義オブジェクトを用いて、IFRローダ143は
IDLファイル内の各タイプ宣言に関する名付け情報を作
成する(423)。名付け情報、及びインタフェース定義オ
ブジェクトは、IDLファイルのインタフェースの記述に
従って作成される。図３のインタフェース・リポジトリ
119の例に関して、IFRローダ143は、それぞれが下位の
動作、定数、例外、及び他のインタフェース定義オブジ
ェクトを有することのできる、下位の口座、借方、及び
貸方インタフェース・オブジェクト123を有する銀行モ
ジュール・オブジェクトからなる銀行システムを記述し
たIDLファイルから作成を行う。

【００３８】各インタフェース定義オブジェクトが作成
されると、それは、指定されたプレフィックス・オブジ
ェクトの名付け情報の下位にある、適当な名付け情報内
に配置される(425)。各インタフェース定義オブジェク
トには、それの上位のプレフィックス・オブジェクト11
3の名前を含む、完全に範囲指定されたオブジェクト名
が与えられる(427)。これによって、インタフェース・
リポジトリ119が、単純なオブジェクト名、またはIDLの
範囲指定された名前が同じであるが、異なるプレフィッ
クス名付け情報内に存在するインタフェースに関する名
前の競合を結果的に避けることができる。

【００３９】最後に、IFRローダ143は、file_nameがロ
ードされるIDLファイルの名前であり、「ifr」（または
その他の任意の適当なサフィックス）がここで記述され
たデータ・タイプのタイプを示している場合、データ・
ファイルをfile_name.ifrというフォーマットで作成す
る。ifrファイルはプレフィックス・オブジェクト133の
名前を含み、そのオブジェクトの上にインタフェース定
義オブジェクトが作成されている。

【００４０】新しいスタブとスケルトンの生成インタフェース・リポジトリ119は動的にオブジェクト
定義をアクセスするために使用される。更に、クライア
ント105は、ORB 115へのアクセスを提供する、静的に定
義されたスタブ・コード・ルーチン137を使用して、サ
ーバ・オブジェクト117を呼び出すことができるスタブ
・ルーチン137が正確にオブジェクト・インタフェース
を識別することを保証するために、IDLコンパイラ135
は、こうしたスタブ・ルーチン137内のプレフィックス
名の範囲を有するクライアント105を提供する。

【００４１】更に、クライアント・スタブ137のサーバ
・オブジェクト117やその代理オブジェクトは、別のク
ライアント・オブジェクト105からの要求に応答して、
サーバ・オブジェクト117のインタフェースを識別でき
るようなものでなければならない。例えばこのことは、
CORBA環境において、_is_a()要求で行われる。この_is_
a()は、オブジェクトが所与のタイプかどうか判定す
る： CORBA::ブール CORBA::オブジェクト::_is_a(object_
type)。

【００４２】同じIDL名の２つの異なるインタフェース
定義が存在するが、これらのインタフェース定義が異な
るプレフィックス名付け情報内にある場合、スタブ137
とスケルトン139内に、各インタフェース定義に関する
正しいプレフィックス情報が符号化される。より詳しく
は、ユニークな、完全に範囲指定された名前を有する、
各インタフェース定義オブジェクトに関して、正しいプ
レフィックス名付け情報を符号化するスタブ137とスケ
ルトン139が提供される。スタブ137とスケルトン139が
生成されると、IDLコンパイラ135がオブジェクトのイン
タフェースを識別するためのプレフィックスを含むオブ
ジェクト名を有するスタブとスケルトンを提供する。例
えば、図３では、インタフェースが共通の名付け情報に
定義された場合、datatypes.idlファイルに関するスタ
ブを生成するために、Solaris^TM環境でコマンド「gener
ate_stub -p common datatypes.idl」が使用される。こ
のコマンドの結果、オブジェクト・タイプ定義に関する
スタブ137のそれぞれが、「共通」プレフィックス名付
け情報に関するプレフィックス名を含んだ、完全に範囲
指定された名前を有する。この処理は、スケルトンが生
成されるときも同様に行われる。

【００４３】スタブ137とスケルトン139が完全に範囲指
定された名前を含む場合、このスタブ・コード137は静
的に作成され、ユニークに正しいインタフェースを識別
するので、クライアント・スタブ・コード137は正しい
インタフェースをサーバ・オブジェクト117に供給す
る。この情報によって、_is_a()、及びタイプを指定す
る任意の動作が、オブジェクトの正しいインタフェース
定義を提供する。

【００４４】最後に、インタフェース・リポジトリ119
を介して、またはスタブ及びスケルトン内に静的にコン
パイルされたコードを介して動的な呼び出しを行うよう
な、IDLのタイプを指定する必要がある任意のケース、
及び動作で、プレフィックス名付け情報を使用すること
によって、複数のIDLのタイプを区別する方法が提供さ
れる。

【００４５】

【発明の効果】本発明によって、分散オブジェクト環境
における個別タイプの複数の定義に関して、動的及び静
的なタイプの支援を行うシステム、及び方法が提供され
る。

【図面の簡単な説明】

【図１】複数のインタフェース定義に関するオブジェク
ト・タイプの支援を提供するためのシステムのブロック
図である。

【図２】本発明のインタフェース・リポジトリを例示す
る図である。

【図３】本発明に従う１つのインタフェース・リポジト
リの例を示す図である。

【図４】単一インタフェース・リポジトリにおいて複数
のインタフェース定義を提供する方法のフローチャート
である。

【符号の説明】

101 ホスト・コンピュータ 103 ネットワーク 105 クライアント 107 ２次記憶装置 109 入力装置 111 ＣＰＵ 113 アドレス指定可能メモリ 115 ORB 116 出力装置 117 サーバ 119 インタフェース・リポジトリ 135 IDLコンパイラ 143 IFRローダ

───────────────────────────────────────────────────── フロントページの続き (72)発明者スウィー・ブーン・リムアメリカ合衆国カリフォルニア州94043マウンテン・ヴュー，ナンバー50，ステイアーリン・ロード・405 (72)発明者ピーター・ヴェンダービルトアメリカ合衆国カリフォルニア州94043マウンテン・ヴュー，ビューメ・コート・ 440 (72)発明者マイケル・エル・パウエルアメリカ合衆国カリフォルニア州94301パロ・アルト，エマーソン・ストリート・ 2305 (72)発明者リ−ウエン・チェンアメリカ合衆国カリフォルニア州95014クパーティノ，オーク・ミードウ・コート・ 7725 (72)発明者ドウエイト・エフ・ハーレアメリカ合衆国カリフォルニア州95076 ラ・セルヴァ・ビーチ，ブレーヴ・アヴェニュー・１ (72)発明者アラン・スナイダーアメリカ合衆国カリフォルニア州94306パロ・アルト，ブレイアーウッド・ウエイ・ 4160

Claims

【特許請求の範囲】

【請求項１】複数のタイプ定義のためのタイプ支援を提
供するコンピュータ・システムであって、前記システム
が、インタフェース・リポジトリを含み、前記インタフェー
ス・リポジトリが、リポジトリ名付け情報、及びリポジトリ名付け情報に対
して下位のプレフィックス名付け情報であって、前記プ
レフィックス名付け情報が少なくとも１つのインタフェ
ース定義言語の宣言に関する名付け情報の根として機能
することを特徴とする、前記システム。
【請求項２】前記プレフィックス名付け情報が、インタフェース定義オブジェクトとプレフィックス名付
け情報に従属するものによって定義される、少なくとも
１つの名付け情報を更に含むことを特徴とする、請求項
１に記載のシステム。
【請求項３】少なくとも１つのインタフェース定義オブ
ジェクトが、インタフェース定義オブジェクトの従属し
ているプレフィックス名付け情報のプレフィックス名を
含む、完全に範囲指定されたオブジェクト名を有するこ
とを特徴とする、請求項２に記載のコンピュータ・シス
テム。
【請求項４】前記プレフィックス名付け情報がリポジト
リ名付け情報のすぐ下位にあることを特徴とする、請求
項１に記載のコンピュータ・システム。
【請求項５】前記プレフィックス名付け情報が、インタフェース定義オブジェクトによって定義された、
少なくとも１つの葉ノードを更に含むことを特徴とす
る、請求項１に記載のコンピュータ・システム。
【請求項６】プレフィックス名付け情報がプレフィック
ス・オブジェクトによって定義されることを特徴とす
る、請求項１に記載のコンピュータ・システム。
【請求項７】少なくとも１つのインタフェース定義言語
の宣言と指定されたプレフィックス名を含む、指定され
たインタフェース定義言語ファイルを、入力パラメータ
として受け入れ、インタフェース・リポジトリ内のプレ
フィックス名付け情報を有するプレフィックス名付け情
報内に、前記少なくとも１つのインタフェース定義言語
の宣言をインストールする、インタフェース・リポジト
リ・ローダを更に含むことを特徴とする、請求項１に記
載のコンピュータ・システム。
【請求項８】前記インタフェース・リポジトリ・ローダ
が、指定されたインタフェース定義言語ファイルに関連
するものとして識別され、指定されたプレフィックス名
付け情報の識別を含むデータ・ファイルを作成すること
を特徴とする、請求項７に記載のコンピュータ・システ
ム。
【請求項９】前記インタフェース・リポジトリ・ローダ
が、指定されたプレフィックス名付け情報がインタフェ
ース・リポジトリ内に存在しない場合、インタフェース
・リポジトリ内に、指定されたプレフィックス名付け情
報を作成することを特徴とする、請求項７に記載のコン
ピュータ・システム。
【請求項１０】前記インタフェース・リポジトリを記憶
するメモリ装置、及び前記インタフェース・リポジトリ
・ローダの動作を実行する処理装置を更に含むことを特
徴とする、請求項１に記載のコンピュータ・システム。
【請求項１１】前記処理装置が更に、前記インタフェー
ス・リポジトリ・ローダを実行して、指定されたインタ
フェース定義言語ファイルと関連するよう識別され、指
定されたプレフィックス名付け情報の識別を含むデータ
・ファイルを作成することを特徴とする、請求項10に記
載のコンピュータ・システム。
【請求項１２】複数のタイプ定義のためのタイプ支援を
提供するコンピュータ・システムであって、前記システ
ムが、クライアント・オブジェクトに動作を提供するタイプを
識別する、完全に範囲指定された名前を含むスタブ・ル
ーチンを有する少なくとも１つのクライアント・オブジ
ェクト、及びサーバ・オブジェクトに関するタイプを識
別する、完全に範囲指定された名前を含むスケルトン・
ルーチンを有する少なくとも１つのサーバ・オブジェク
トを含むことを特徴とする、前記システム。
【請求項１３】クライアント・オブジェクト内にスタブ
・ルーチンを生成する、インタフェース定義言語コンパ
イラを更に含むことを特徴とする、請求項12に記載のコ
ンピュータ・システム。
【請求項１４】サーバ・オブジェクト内にスケルトン・
ルーチンを生成する、インタフェース定義言語コンパイ
ラを更に含むことを特徴とする、請求項12に記載のコン
ピュータ・システム。
【請求項１５】前記少なくとも１つのクライアント・オ
ブジェクト、及び前記少なくとも１つのサーバ・オブジ
ェクトを記憶するメモリ装置、及びクライアント・オブ
ジェクトによるサーバ・オブジェクトの呼び出しに応答
して、サーバ・オブジェクトを実行する処理装置を更に
含むことを特徴とする、請求項12に記載のコンピュータ
・システム。
【請求項１６】前記処理装置がインタフェース定義言語
コンパイラを実行して、スタブ・ルーチンとスケルトン
・ルーチンを生成することを特徴とする、請求項15に記
載のコンピュータ・システム。
【請求項１７】複数のタイプ定義のためのタイプ支援を
提供する方法であって、前記方法が、インタフェース・リポジトリ内に、プレフィックス名付
け情報を定義するステップ、及びリポジトリ名付け情報
に対して下位のプレフィックス名付け情報をインタフェ
ース・リポジトリ内に記憶するステップであって、前記
プレフィックス名付け情報が、プレフィックス名付け情
報に対して下位のインタフェース定義オブジェクトに関
するインタフェース定義言語の根情報を形成する前記ス
テップを含むことを特徴とする、前記方法。
【請求項１８】各プレフィックス名付け情報が、リポジ
トリ名付け情報に対してすぐ下位に記憶されることを特
徴とする、請求項17に記載の方法。
【請求項１９】少なくとも１つのインタフェース定義言
語の宣言を含む、インタフェース定義言語ファイルを指
定するステップ、プレフィックス名付け情報を指定するステップ、及び指
定されたインタフェース定義言語ファイル内の各インタ
フェース定義言語の宣言を、指定されたプレフィックス
名付け情報内に記憶するステップを更に含むことを特徴
とする、請求項17に記載の方法。
【請求項２０】各インタフェース定義言語の宣言を記憶
する前記ステップが、前記インタフェース定義言語の宣言に関する、インタフ
ェース定義オブジェクトを作成するステップ、指定されたプレフィックス名付け情報内に、インタフェ
ース定義オブジェクトを記憶するステップ、及び前記イ
ンタフェース定義オブジェクトに、前記インタフェース
定義オブジェクトが記憶されているプレフィックス名付
け情報からのプレフィックス名を含む、完全に範囲指定
されたオブジェクト名を提供するステップを更に含むこ
とを特徴とする、請求項19に記載の方法。
【請求項２１】指定されたインタフェース定義言語ファ
イルに関連するものとして識別され、指定されたプレフ
ィックス名付け情報の識別を含む、データ・ファイルを
作成するステップを更に含むことを特徴とする、請求項
19に記載の方法。
【請求項２２】複数のタイプ定義のためのタイプ支援を
提供する方法であって、前記方法が、インタフェース・リポジトリを含み、前記インタフェー
ス・リポジトリが、リポジトリ名付け情報、及びリポジトリ名付け情報に対
して下位のプレフィックス名付け情報であって、前記プ
レフィックス名付け情報が少なくとも１つのインタフェ
ース定義言語の宣言に関する名付け情報の根として機能
することを特徴とする、前記方法。
【請求項２３】複数のタイプ定義のためのタイプ支援を
提供する方法であって、前記方法が、クライアント・オブジェクトに動作を提供するオブジェ
クト・タイプに関する、完全に範囲指定された名前を含
むスタブ・ルーチンを有する少なくとも１つのクライア
ント・オブジェクトを提供するステップ、及びサーバ・
オブジェクトに関するオブジェクト・タイプを識別す
る、完全に範囲指定された名前を含むスケルトン・ルー
チンを有する少なくとも１つのサーバ・オブジェクトを
提供するステップを含むことを特徴とする、前記方法。
【請求項２４】前記少なくとも１つのクライアント・オ
ブジェクト、及び前記少なくとも１つのサーバ・オブジ
ェクトを記憶するメモリ装置を提供するステップ、及び
クライアント・オブジェクトによるサーバ・オブジェク
トの呼び出しに応答して、サーバ・オブジェクトを実行
する処理装置を提供するステップを更に含むことを特徴
とする、請求項21に記載の方法。