JP3553991B2 - プログラム制御方法 - Google Patents
プログラム制御方法 Download PDFInfo
- Publication number
- JP3553991B2 JP3553991B2 JP12617093A JP12617093A JP3553991B2 JP 3553991 B2 JP3553991 B2 JP 3553991B2 JP 12617093 A JP12617093 A JP 12617093A JP 12617093 A JP12617093 A JP 12617093A JP 3553991 B2 JP3553991 B2 JP 3553991B2
- Authority
- JP
- Japan
- Prior art keywords
- program
- data
- program code
- processing
- processes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44552—Conflict resolution, i.e. enabling coexistence of conflicting executables
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、複数のプログラムが協調して処理をおこなっていく処理形態のプログラム制御方式に関するものである。
【０００２】
とくに、サーバ・クライアントシステムとして実現されたデータベースシステムのように、サーバからの要求をクライアントに実行させたり、クライアントに新しい機能を提供したりする機構を要求されるシステムの実現に関するプログラム制御方式である。
【０００３】
【従来の技術】
近年、ＤＴＰシステムやＤｒａｗｉｎｇ ｔｏｏｌ（絵描きプログラム）などの複雑なアプリケーションプログラムが開発されていく過程において、”プログラミングの複雑化”，”プログラムの肥大”，”状況に応じた処理の切り替えが難しい”等の問題が提起されてきた。
従来、これらの問題の解決のために、以下のような方法が提案され利用されている。
・オブジェクト指向データベースシステム（例えば、Ｔｈｅ ＯｂｊｅｃｔＳｔｏｒｅ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍ，ＣＡＣＭ ｖｏｌ．Ｎｏ．１０，ｐｐ．５０−６３，（Ｏｃｔ．１９９１）に記述されたオブジェクト指向データベースシステム）
オブジェクト指向システムの考え方をデータベースシステムに適用したシステムである。複雑な構造をもつデータを、複数のプログラム間で共有する場合に要求される機構（例：データの永続化，並行アクセス制御，バージョン管理）を提供する。オブジェクト指向データベースシステムによって、データ共有を実現するために発生するプログラミングの複雑化を緩和することが可能となる。
・ｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇ（例えば、Ａｎ Ａｐｐｒｏａｃｈ ｔｏ Ｇｅｎｕｉｎｅ Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ ＣＳＥ−９０−２５ ，８−１９９０，Ｄｉｖ ｃｏｍｐｕｔｅｒ ｓｃｉｅｎｃｅ ｕｎｉｖｅｒｓｉｔｙ ｏｆ ｃａｌｉｆｏｒｎｉａ）
【０００４】
ある機能を、プログラムの作成時にそのプログラムに組み込んでしまうかわりに、プログラムの実行時に組み込む機構である。
通常、プログラムの作成時におこなわれるモジュール組み込み手続き（ｌｏａｄｉｎｇおよびｌｉｎｋｉｎｇ）をプログラムから呼びだすことができる関数として組み込んでしまうことにより実現される。
プログラムの肥大の回避と状況に応じて処理内容を切り替える機構として使用されている。
・共有ライブラリ（例えば、Ｕｎｉｘ ＳｙｓｔｅｍＶに付属するライブラリ）複数のプログラムで共通に使用される可能性のあるモジュールを１つないし数個のファイルにまとめたものをライブラリと呼ぶが、特に各プログラムが実行時にそのファイル内の手続きを呼び出し、実行することができるようになっているものを共有ライブラリと呼ぶ。
プログラムの肥大を解消する方法として使用されている。
【０００５】
【発明が解決しようとしている課題】
しかしながら、近年グループウェアなどのように、複数のプログラムが非常に複雑な構造をもつデータやそのデータの構造に依存したプログラムコードを共有し、協調して処理をおこなっていくような、さらに複雑な共有形態を要求するアプリケーションが作成されるようになるに従い、以下のような問題が発生している。
ａ． Ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ問題
たとえば、複数のウィンドウ・アプリケーションがデータを共有している場合、共有されているデータの状態を表示に常に反映させるには、あるアプリケーションが共有されたデータを変更する度に、他のアプリケーションにその旨を通知してやらなければならない。
ｂ． 所有者問題
データ管理アプリケーション、特にデータに対するの更新やアクセス制御を要求される場合、何らかの規約に基づく動作をアプリケーションに”強制”しなければならない場合が発生する。
ｃ． 蒸発問題
共有データを参照するアプリケーション内では、複数のアプリケーションで共有され各アプリケーションの終了後も永続的に保存されるデータと、各アプリケーション固有でアプリケーションの終了と共に消滅してしまう一時的なデータが混在することになる。
この様な状況において、永続的データに一時的なデータに対する参照情報が含まれている場合、アプリケーションの終了と共に一時的なデータが消滅してしまうため、永続的データはその時点で意味のないデータを保持していることになる。多くの場合この意味のないデータは、不正な値として解釈されアプリケーションに悪影響を及ぼすことになる。
ところが、前記従来例では、複数のプログラムが、非常に複雑な構造をもつデータやそのデータの構造に依存したプログラムコードを共有し、その状態を実行時に動的に変化させていくことによって発生する、これらの問題を解決することができない。
なぜならば、オブジェクト指向データベースシステムが提供するのは、永続化されたデータの集中管理機構であり、Ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ問題や所有者問題のような複雑な分散化データ管理の問題の解決や、蒸発問題のように永続化されていないデータの管理をおこなうことができない。
さらに、共有ライブラリが提供する機能はプログラムの作成時に決定可能なプログラムコードの共有をサポートするための機構であり、上記の問題のように、実行時の状況によって動的に変化する問題に対応することができない。
また、ｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇの場合は動的なプログラムコードの追加・実行をおこなうことができるが、そのプログラムコードの共有を管理する機構を提供することができない。このため複数のプログラムによる協調処理という基盤そのものをｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇでは実現することができない。
【０００６】
【課題を解決するための手段】
上記課題を解決するために、本発明のプログラム制御方法は、それぞれ異なる第１のプログラムを実行する複数の第１のプロセスと第２のプログラムを実行する第２のプロセスとが協調して処理を行なうシステムにおいて、前記複数の第１のプロセスが前記第２のプロセスに対してプログラムコード及びデータの追加を要求し、前記第２のプロセスが複数の前記第１のプロセスよりの追加の要求を受け取ると、要求された追加を許可する１つの前記第１のプロセスを選択して、当該選択したプロセスに許可を通知するとともに、他の前記第１のプロセスに対して認証拒否を通知し、前記第１のプロセスが、前記第２のプロセスより許可の通知を受けると、前記第２のプロセスに対して前記プログラムコード及びデータの追加を実行することを特徴とする。
【０００７】
これによって、プログラムの実行時に動的に変化していく状況を監視し、かつ必要な場合には積極的に状況を変化させ、複雑な協調作業に伴う前述の問題に対処することが可能となる。
【０００８】
また本発明は、
データおよびプログラムコードを組み込まれ実行される側が、その処理に許可をあたえるための認証手段と、
複数のプロセスからのデータおよびプログラムコードの追加・実行要求の衝突を解決する手段と、
データおよびプログラムコードの追加・実行の結果、１つのプロセス内に存在することになる複数の手続き間の並行制御手段を設けることにより、
強制された動作が正当なものであり、かつ現状に最も適したものにすることである。
【０００９】
【実施例】
ここでは、本発明の第１の実施例としての、マルチメディアデータ検索システムについて説明する。
【００１０】
ここで述べるマルチメディアデータ検索システムとは、データベース等で管理されている画像、音声、文書等のマルチメディアデータを検索・表示するアプリケーションのことである。
以下、このマルチメディアデータ検索システムについて図２，図３，および図４を用いて説明する。
まず図２は、本実施例のシステム構成を表したものである。
同図において、
２０１はマルチメディアデータ検索システムの利用者がコマンドやデータを入力するための入力装置で、キーボード，マウス，スキャナ等である。
【００１１】
２０２は入力装置２０１からの入力に基づいて後述する図面に示されたフロ−チャ−トの手順を記憶し、それに基づいて本実施例の処理を実行する処理部のＣＰＵである。
【００１２】
２０３はＣＰＵ２０２等の処理によって検索されたマルチメディアデータを表示するための出力装置で、ＣＲＴディスプレイやプリンタなどである。
【００１３】
２０４は本実施例においてマルチメディアデータの検索と取り出されたデータの処理機能を利用者に提供するマルチメディアデータ処理プログラムである。
【００１４】
２０５はマルチメディアデータ処理プログラム２０４およびその実行に必要なデータを一時的に記憶するための主記憶である。
【００１５】
２０１から２０３および２０５は計算機バス２０６で結合され、ワークステーション２０７を構成する。本実施例のマルチメディアデータ検索システムはワークステーション２０７上で動作する。本実施例では、ワークステーション２０７同等なものが複数存在してもよい。この場合、各ワークステーション上でマルチメディアデータ処理プログラム２０４同じプログラムが動作し、複数の利用者に同時にサービスを提供することができる。
【００１６】
２０８は、マルチメディアデータを記憶し管理するためのデータベースシステムであり、マルチメディアデータ検索システムにマルチメディアデータの検索などのサービスを提供する。
主に、マルチメディアデータを記憶・保存するハードディスク等の２次記憶装置２０９と、マルチメディアデータ処理プログラム２０４からの要求に従ってマルチメディアデータの検索・管理をおこなうデータベース処理プログラム２１０とで構成されており、ワークステーション２０７上、あるいは別の同様な構造をもつコンピュータ上で動作する。
【００１７】
本実施例において、本発明の中心であるデータおよびプログラムコードの共有機能はデータベースシステム２０８内のデータベース処理プログラム２１０によって提供されている。
２１１は、データベースシステム２０８とマルチメディアデータ処理プログラム２０４を結合し、システム間でのデータ交換を可能にする手段を示している。
この結合は通常、コンピュータネットワークおよびその上で実現されたプロセス間通信機能によって実現される。
【００１８】
つぎに図３は、図２のシステム構成上で動作するマルチメディアデータ処理プログラム２０４およびデータベース処理プログラム２１０の処理をあらわす概念図である。以降の説明は主にこの図と後で述べる図４にもとづいて行う。
同図において、
３０１は図２におけるワークステーション２０７上で動作しているマルチメディアデータ検索システムであり、３０２は図３上でのデータベースシステム２０８をあらわすものである。
また、３０３はマルチメディアデータ検索システム３０１とデータベースシステム３０２の間で共有されるマルチメディアデータを保持するための共有メモリである。
マルチメディアデータ検索システム３０１内部の３０４は出力装置２０３の１つとして使用されるＣＲＴディスプレイであり、マルチメディアデータ検索システムの利用者による検索コマンド等の結果がここに表示される。
３０５はマルチメディアデータ処理プログラム２０４がワークステーション２０７上で動作している時の形態をあらわすマルチメディアデータ処理プロセスであり、３０６はデータベース処理プログラム２１０をあらわすデータベース処理プロセスである。
３０７は２次記憶装置２０７に相当するハードディスクである。
のこる３０８，３０９，３１０，３１１は、あるマルチメディアデータのさまざまな形態を表現している。
すなわち、３０８はそのマルチメディアデータのハードディスク３０７上でのデータ形式であり、３０９と３１０はそのデータの共有メモリ３０３上でのデータ形式をあらわす。それぞれマルチメディアデータを処理するプログラムコードとマルチメディアデータそのものである。
また、３１１はＣＲＴディスプレイ３０４上でのビットマップデータ形式を表現しており、マルチメディアデータ検索システムの利用者が要求した検索結果の表示に相当している。
【００１９】
これらのデータ形式間の変換はマルチメディアデータ処理プロセス３０５およびデータベース処理プロセス３０６によっておこなわれる。
例えば、利用者からの検索結果としてハードディスク３０７上のデータ３０８がＣＲＴディスプレイ３０４に表示されるといった処理の場合、データ３０８はまずデータベース処理プロセス３０６によって共有メモリ上でのデータ形式３０９と３１０に変換され、共有メモリ３０３に書き込まれる。ここでは、他のデータへの参照データを共有メモリ上でのポインタにおきかえる（この処理をｓｗｉｚｚｌｉｎｇと呼ぶ。）等の変換がおこなわれる。
次にプログラムコード３０９はマルチメディアデータ処理プロセス３０５に組み込まれ、実行される。プログラムコード２０９の処理により、マルチメディアデータ３１０はＣＲＴディスプレイ上でのデータ形式３１１に変換され表示される。
【００２０】
ここで、このプログラム間でのデータおよびプログラムコードの組み込みを以降、”Ｉｎｊｅｃｔｉｏｎ”と呼び、その実現機構を”Ｉｎｊｅｃｔｉｏｎ機構”と呼ぶことにする。
【００２１】
図１ａ，１ｂは、このＩｎｊｅｃｔｉｏｎ機構の動作イメージをあらわしており、図１ａにおいて、プログラムＢ１０１がプログラムＡ１０２にデータと実行可能なプログラムコード１０３を付加（ないし置換）している。
【００２２】
また、図１ｂは図１ａの処理結果をあらわし、プログラムＢ１０１’はプログラムコード１０３を付加されたあとのプログラムＢ１０１をあらわしている。プログラムコード１０３’は、プログラムＢ１０１’付加されたプログラムコード１０３をあらわしている。
プログラムＢ１０１’上でプログラムコード１０３’が動作することにより、プログラムＡ１０２が意図した動作を強制することが可能となる。
本実施例では、この”意図した動作”がデータ３０８をＣＲＴディスプレイ３０４上に表示させることに相当する。
【００２３】
本実施例において、このＩｎｊｅｃｔｉｏｎ機構は以下のようにして実現されている。まず、プロセス間の要求伝達は、ＵＮＩＸ等のオペレーティングシステムが提供するプロセス間通信機構（ｓｏｃｋｅｔなど）によっておこなわれる。データおよびプログラムコードの共有あるいは追加・変更手段の実現にためには、データ共有の基本機構として共有メモリシステムを使用し、共有メモリ上にバイナリデータとしておかれたプログラムコードをｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇ機構を用いて動作中のプロセスに組み込む。
あるいは、そのプログラムコードが他の共有データのみに依存している場合なら、ｄｙｎａｍｉｃｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇの機構は特に必要なく、単にプログラムコードとそれが参照するデータを共有メモリ上に書き込むだけでよい。
共有したデータとプログラムコードの実行は、最近のオペレーティングシステムでサポートされるようになってきたｔｈｒｅａｄやｌｉｇｈｔ ｗｅｉｇｈｔ ｐｒｏｃｅｓｓ生成機構など、新たな処理の流れ（これをａｃｔｉｖｉｔｙと呼ぶ）を生成することができる機構を使用して実現することができる。ただし通常、新しいａｃｔｉｖｉｔｙの生成は同一プログラム内に存在している他のａｃｔｉｖｉｔｙのみに許されていることが多い。この場合、別のプログラムからａｃｔｉｖｉｔｙの生成を可能にする、プログラム間のインタフェースを規定する必要がある。
また、データおよびプログラムコードの追加・実行要求の認証の実現は、共有メモリ上に存在するが、まだリンクされていないデータおよびプログラムコードを読み出し、その内容を調べることにより、データの正当性を確認することで可能である。
具体な判定方法としては、オブジェクト指向言語におけるクラス継承の機構を利用し、そのデータが特定のクラスのサブクラスのインスタンスとなっているか否かをチェックし、そのサブクラスのインスタンスのみ認証されるという方式が考えられる。
ただし、本実施例においては、マルチメディアデータ処理プロセス３０５そのものが重要なデータを保持せず、データのほとんどがデータベース処理プロセス３０６によって管理されているため、Ｉｎｊｅｃｔｉｏｎは無条件で認証される。Ｉｎｊｅｃｔｉｏｎにおける認証の実施については、後で述べるの実施例で説明する。
データおよびプログラムコードの追加・実行要求の衝突を解決する手段としては、各要求に優先順位を付け、最も優先順位が高いものを採用するといった戦略が可能である。
本実施例では、あとで述べるように、要求の衝突は発生しないようになっている。
衝突の解決する手段の実施についても、後で述べるの実施例で説明する。
最後に、１つのプロセス内に存在することになる複数の手続き間の並行制御手段としては、従来のオブジェクト指向データベースでデータの共有に用いられている、ロックにもとづく変更アクセス制御機構を、従来のようなプロセス単位ではなく、プロセス内に同時に複数存在しうるａｃｔｉｖｉｔｙを単位として適用する。このときａｃｔｉｖｉｔｙ間で優先順位づけを行い、特定のａｃｔｉｖｉｔｙを優先的に実行させる機構が必要となる。本実施例では、Ｉｎｊｅｃｔされるプログラムコード３０９はかならず、マルチメディアデータ処理プロセス２０５の主手続きより高い優先度をもち、優先的に実行される。
【００２４】
さて、上記構成に基づいた本実施例の動作を図４ａ，４ｂ，４ｃのフローチャートを用いて説明する。各フローチャートはそれぞれ、マルチメディアデータ処理プロセス３０５の主手続き、データベース処理プロセス３０６内のＩｎｊｅｃｔｉｏｎ機構、およびプログラムコード３０９のＩｎｊｅｃｔｉｏｎの前におこなわれるＩｎｊｅｃｔｉｏｎ認証手続きの処理の流れをあらわしている。これらのフローチャートは見かけ上独立しているが、あるフローチャートのｏｎｅｓｔｅｐが他のフローチャートの処理を開始させるというかたちで、互いに関連しあっている。また、これらの処理の流れはひとつのプロセス内に同時に複数存在しうる。
【００２５】
本実施例の説明では便宜上、データベース処理プロセス３０６がマルチメディアデータ処理プロセス３０５より先に起動されている事を仮定する。また、データベース処理プロセス３０６は１つだけ起動されており、２つ以上のＩｎｊｅｃｔｉｏｎが同時に発生することはないものとする。
（Ｓ４ｂ０１） マルチメディアデータ処理プロセス３０５は、その起動後にＩｎｊｅｃｔｉｏｎが受け入れ可能である事を宣言する。
（Ｓ４ａ０１） データベース処理プロセス３０６は、マルチメディアデータ処理プロセス３０５のＩｎｊｅｃｔｉｏｎ受け入れ可能宣言を検知し、（例えばＩｎｊｅｃｔｉｏｎ受け入れ先リストなどにマルチメディアデータ処理プログラム３０５を登録し）憶する。
その後で、マルチメディアデータ検索システムの利用者によってマルチメディアデータの検索が要求されると（Ｓ４ｂ０２）、
（Ｓ４ｂ０３） マルチメディアデータ処理プロセス３０５はデータベース処理プロセス３０６に対し、利用者によって指示されたデータ３０８の検索を要求する。この時点で、マルチメディアデータ処理プロセス３０５の処理は利用者からの入力受付状態にもどり、次のコマンド等を受けつける（Ｓ４ｂ０４）。
以降の処理は主にデータベース処理プロセス３０６によって実行される。
（Ｓ４ａ０２） データ３０８の検索要求がデータベース処理プロセス３０６に通知されると、
（Ｓ４ａ０３） 検索要求に付加されている情報をもとに、要求されたデータ３０８をハードディスク３０７から取り出す。
（Ｓ４ａ０４） データベース処理プロセス３０６はマルチメディアデータ処理プログラム３０５に対し取り出したデータ３０８のＩｎｊｅｃｔｉｏｎの認証要求を発行する。
認証要求にはＩｎｊｅｃｔｉｏｎの発生とＩｎｊｅｃｔに関する情報が含まれている。
マルチメディアデータ処理プログラム３０５内の認証手続きは、Ｉｎｊｅｃｔｉｏｎの認証要求を検知し（Ｓ４ｃ０１）、
（Ｓ４ｃ０２） Ｉｎｊｅｃｔｉｏｎの認証が可能か否かを判断し、データベース処理プログラム３０６に結果を通知する（Ｓ４ｃ０３）。
通知された結果、
（Ｓ４ａ０５） Ｉｎｊｅｃｔｉｏｎの認証を受けることができなかった場合はＩｎｊｅｃｔｉｏｎは実行されず、マルチメディアデータ処理プロセス３０５にエラーが送られる。このエラーは、ＣＲＴディスプレイ３０４に表示されシステムの利用者に通知される（Ｓ４ａ０６）。
（Ｓ４ａ０７） Ｉｎｊｅｃｔｉｏｎが許可された場合は、必要なデータ３０８はプログラムコード３０９とマルチメディアデータ３１０に変換され、共有メモリ３０３上に置かれる。
【００２６】
ただし、プログラムコード３０９はデータ３０８と先に参照されたデータ間で共用されている場合がある。このような場合、プログラムコード３０９がすでに共有メモリ３０３上に存在することになるので、マルチメディアデータ３１０みが共有メモリ３０３上に置かれる。ただし、プログラムコード３０９とマルチメディアデータ３１０の（マルチメディアデータ３１０はプログラムコード３０９によって処理されるという）関係は保存される。
さらに、プログラムコード３０９はマルチメディアデータ処理プログラム２０４に動的にリンクされる。
このとき、プログラムコード３０９が前の処理によってすでにリンクされていた場合はリンクはおこなわれない。
この時点で、マルチメディアデータ処理プロセス３０５も共有メモリ３０３を介してデータを処理するための準備が完了する。
（Ｓ４ｂ０８） マルチメディアデータ処理プログラム２０４内にリンクされ、マルチメディアデータ処理プロセス３０５に組み込まれたプログラムコード３０９にａｃｔｉｖｉｔｙを与え、実行する。
プログラムコード３０９はＣＲＴディスプレイ３０４へのデータの表示等の処理を行う。
データベース処理プロセス３０６自身の処理はこの時点で完了し、次の要求発生を待つことになる（Ｓ４ａ０２）。
最後に、プログラムコード３０９の実行が終了し、利用者によって入力されたコマンドの処理が完了する。
以上のようなＩｎｊｅｃｔｉｏｎの実現により、本実施例では以下のような効果を得ることができる。
１． マルチメディアデータのブラウジング（表示）機構をＩｎｊｅｃｔｉｏｎを使用して後から組み込む事により、マルチメディアデータ処理プログラム２０４を一切変更することなく、新しいタイプのデータの取り込み，データフォーマットの変更への対応，データの表示等の処理の効率化をおこなうことができる。
２． プログラムコード３０９がマルチメディアデータ処理プロセス３０５の主手続きから切り離され、主手続きとは別のａｃｔｉｖｉｔｙが与えられることにより、マルチプロセッサ環境での実行スピードの改善を期待することができる。
【００２７】
（その他の実施例）
以下、本発明の第２の実施例であるプログラムコード共有システムについて図５，図６，および図７を用いて説明する。
ここで述べるプログラムコード共有システムとは、あるプログラムの一部（手続き）をデータベース等で管理してそのプログラム自身から切り離す事により、プログラムコードの共有やプログラムの拡張・修正を容易にする事を目的としたソフトェアシステムのことである。
まず図５は、本実施例におけるシステム構成をあらわしたものであり、先に述べたマルチメディアデータ検索システムとほぼ同じ構成である。
同図において、
５０１および５０１’はそれぞれ、本実施例上で動作するアプリケーションプログラムの利用者が、コマンドやデータを入力
するための入力装置で、キーボード、マウスなどである。
５０２および５０２’はそれぞれ、入力装置５０１，５０１’からの入力にもとづいてアプリケーションプログラムの処理を実行するＣＰＵである。ここでは、ＣＰＵ５０２とＣＰＵ５０２’が異なる命令セットを持っている場合を想定している。
５０３および５０３’はそれぞれ、ＣＰＵ５０２，ＣＰＵ５０２’等の処理によって検索されたマルチメディアデータを表示するための出力装置で、ＣＲＴディスプレイやプリンタなどである。
５０４および５０４’は、本実施例上で動作するアプリケーションプログラム５０５，５０５’およびその処理に必要なデータを一時的に記憶するための記憶装置である。５０６，５０６’はそれぞれ、５０１から５０４および５０１’から５０４’までの構成要素を結合する計算機バスであり、これらはワークステーション５０７，５０７’を構成する。アプリケーションプログラム５０５，５０５’はそれぞれワークステーション５０７，５０７’上で動作している。
５０８は、実行可能なプログラムコードを記憶し管理するためのプログラム管理データベースである。プログラム管理データベース５０８はワークステーション５０７ないし５０７’上あるいは、別の同様な構造をもつコンピュータ上で動作する。
【００２８】
本実施例においては、本発明の骨子であるデータとプログラムコードの共有機構は、プログラム管理データベース５０８とアプリケーションプログラム５０５，５０５’にリンクされたインタフェースライブラリ（後述）によって提供される。
【００２９】
また、本実施例においては、プログラム管理データベース５０８と同様なプログラム管理データベースが同時に複数存在してよい。ただしこの場合も、あるプログラムコードが複数の異なるプログラム管理データベースによって管理されることは禁止する。
最後の５０９，５０９’はそれぞれ、プログラム管理データベース５０８とアプリケーションプログラム５０５，５０５’を結合し、プログラムコードの共有を可能にする手段である”Ｉｎｊｅｃｔｉｏｎ機構”をあらわす。コンピュータネットワークおよびその上で実現されたプロセス間通信機構を利用して実現することが可能である。
【００３０】
つぎに図６は、図５のシステム上で動作するアプリケーションプログラム５０５およびプログラム管理データベース５０８の間でおこなわれる処理をあらわしたものである。以降の説明は主にこの図にもとづいて行う。アプリケーションプログラム５０５’とプログラム管理データベース５０８間でも同様な処理がおこなわれる。
同図において、
６０１は図５における、アプリケーションプログラム５０５が実行する処理を表現するアプリケーションプロセスである。その内部に存在する６０２はアプリケーションプロセス６０１の主手続きである。また、６０３はアプリケーションプロセス６０１からプログラム管理データベースへのインタフェースおよびＩｎｊｅｃｔｉｏｎ処理における認証手続き等の機構を提供するライブラリである。
６０４は図６においてプログラム管理データベース５０５をあらわし、プログラムコードを記憶・保存するハードディスク６０５とプログラムコードの検索・管理をおこない、本実施例においてＩｎｊｅｃｔｉｏｎ処理を担うコード管理プロセス ６０６によって構成される。
６０７は前の実施例と同様に、プログラム管理データベース６０４が、アプリケーションプロセス６０１に提供するプログラムコードを保持する共有メモリである。
また、６０８，６０９はそれぞれ、あるアプリケーションプロセス６０１に付加されるプログラムコードの、ハードディスク６０５上および共有メモリ６０７上でのデータ形式を表現している。
本実施例では、データ６０８からプログラムコード６０９への変換は、アプリケーションプロセス６０１へのリンクによっておこなわれる手続き呼びだし等の参照先解決が主なものである。このため、本実施例においては、参照関係が各アプリケーションプログラムに依存するようなプログラムコードでは、ハードディスク上のデータから２つ以上のプログラムコードイメージが共有メモリ上に生成される場合が発生する。
このようにして、アプリケーションプロセス６０１にリンクされたプログラムコード６０９は、主手続き６０２から呼びだされ、実行される。
本実施例においても、Ｉｎｊｅｃｔｉｏｎ機構は先に述べた実施例と同様にして実現されるが、
Ｉｎｊｅｃｔｉｏｎ実行時における認証処理が異なっている。
本実施例では、最も現在の状況に適したプログラムコードに認証が与えられる。すなわち、プログラムコードの性格をあらわす実行スピードとメモリ消費量のオーダの２つのパラメタを適当な評価関数にあたえた結果によって、現在の状況に適しているか否かを評価する。
もちろん、すべてのプログラムコードは、プログラム管理データベースに記憶された時に、プログラムコードの性格をあらわすこれらのパラメタが与えられる。また、Ｉｎｊｅｃｔされるプログラムコードにこれらのパラメタで優劣がつけられない場合に対処するため、プログラム管理データベース間での優先順位が決まっており、その優先順位に従ってＩｎｊｅｃｔｉｏｎが認証されるプログラムコードが決定される。プログラム管理データベース間での優先順位を決定するパラメタとしては、ネットワーク上での遠近を使用し、最もネットワーク上で近いところにあるプログラムコードが認証される。
さて、上記構成に基づいた本実施例の動作を図７ａ，７ｂ，７ｃのフローチャートを用いて説明する。
各フローチャートはそれぞれ、主手続き６０２，コード管理プロセス６０６，およびサポートライブラリインタフェース６０３内のＩｎｊｅｃｔｉｏｎ認証手続きの処理の流れをあらわしている。各フローチャートは見かけ上独立しているが、あるフローチャートのｏｎｅｓｔｅｐが、他のフローチャートの処理を開始させるというかたちで、互いに関連している。
また、これらの処理の流れは、プロセス内に同時に複数存在することができる。本実施例においても、コード管理プロセス６０６がアプリケーションプロセス６０１より先に起動されているとして説明する。
（Ｓ７ｂ０１） アプリケーションプロセス６０１はその起動後にＩｎｊｅｃｔｉｏｎが受け入れ可能である事を宣言する。ただし、この処理は、サポートライブラリ６０３によって自動的に実行される。
（Ｓ７ａ０１） コード管理プロセス６０４は、アプリケーションプロセス６０１のＩｎｊｅｃｔｉｏｎ受け入れ可能宣言を検知し、Ｉｎｊｅｃｔｉｏｎ受け入れ先リストにアプリケーションプロセス６０１を登録する。
（Ｓ７ａ０２） コード管理プロセス６０４は、逆にアプリケーションプロセス６０１に対してａｃｋｎｏｗｌｅｄｇｅメッセージをかえす。
（Ｓ７ｂ０２） アプリケーションプロセス６０１は、コード管理プロセス６０４のａｃｋｎｏｗｌｅｄｇｅメッセージを検知し、Ｉｎｊｅｃｔｉｏｎ候補リストにコード管理プロセス６０４を登録しておく。
その後の処理で、アプリケーションプロセス６０１内でのある手続き呼び出しが実行されると（Ｓ７ｂ０３）、
（Ｓ７ａ０３） この手続き呼び出しはＩｎｊｅｃｔｉｏｎ開始イベント７０１として、コード管理プロセス６０６に検知される。この時点で、アプリケーションプロセス６０１の処理は一時的に中断される。
（Ｓ７ａ０４） コード管理プロセス６０６はイベント７０１を検知すると、イベント７０１に付加されている情報をもとに（この情報は、主手続き６０２による手続き呼び出しに関するものであり、要求される手続きを一意に決定するために必要な手続き名，ＩＤ番号等を含んでいる。）、必要なプログラムコード６０８をハードディスク６０５から取り出す。取り出された、プログラムコード６０８はそのまま共有メモリ６０７上に書き込まれる。
この処理において、ハードディスク６０５中には、同じ入力に対して同じ結果をかえす等価なプログラムコードが複数存在しうる。たとえば、さまざまな種類のＣＰＵに対応するために、各ＣＰＵ用のバイナリが管理していたり、同一の意味をもつが、実行効率が異なるインプリメントがいくつか存在するような場合である。
この様な場合においても、イベント７０１に付加されている情報をもとに、要求されるコードを一意に決定できるものとする。
（Ｓ７ａ０５） コード管理プロセス６０６はアプリケーションプロセス６０１に対し取り出したプログラムコード６０８のＩｎｊｅｃｔｉｏｎ認証要求を発行する。
認証要求にはＩｎｊｅｃｔｉｏｎの発生とＩｎｊｅｃｔされるプログラムコードに関する情報（あるいはＩｎｊｅｃｔされるプログラムコード６０８自身）が含まれている。この情報は、Ｉｎｊｅｃｔｉｏｎの可・不可の判定や、複数のＩｎｊｅｃｔｉｏｎ要求の衝突が発生した場合の調整に使用される。
また、この時点でコード処理プロセス６０４における６０１に対する処理は認証が終了するまで中断される。ただし、他のアプリケーションプロセスに対するＩｎｊｅｃｔｉｏｎ処理には影響しない。
（Ｓ７ｃ０１） サポートライブラリ６０３内の認証手続きは、Ｉｎｊｅｃｔｉｏｎ認証要求を検知する。本実施例においてはさらに、Ｉｎｊｅｃｔｉｏｎの対象となるプログラムコードを提供することのできるすべてのプログラム管理データベースからの認証要求を集める。（Ｉｎｊｅｃｔｉｏｎの対象となるプログラムコードを提供できないプログラム管理データベースからも、その旨を通知する”空認証要求”が発行されるものとする。）
（Ｓ７ｃ０２） 各Ｉｎｊｅｃｔｉｏｎ要求のなかからの認証を許すものを１つだけ選択する。
（Ｓ７ｃ０３） 選ばれたプログラム管理データベースに認証がおこなわれたことを通知し、他のプログラム管理データベースには認証が拒否されたことを通知する。ここではプログラム管理データベース６０２が認証されたとして説明を続ける。
すべての要求が認証できない場合は、サポートライブラリ６０３が例外処理をおこなう。
（Ｓ７ａ０６，Ｓ６ａ０７） プログラムコード６０８はアプリケーションプログラム６０１に動的にリンクされ、共有メモリ上でのプログラムコードイメージ６０９に変換される。
（Ｓ７ａ０７） プログラムコード６０９がアプリケーションプログラム６０１にＩｎｊｅｃｔされたことを通知する。
（Ｓ７ｂ０４） アプリケーションプログラム６０１は中断されていた手続き呼び出しを再開し、Ｉｎｊｅｃｔされたプログラムコード６０９が実行される。
以上のようなＩｎｊｅｃｔｉｏｎの利用により、本実施例では以下のような効果を得ることが出来る。
１． 複数のコード管理プログラムから提供されたコードから最適なものをアプリケーションプログラムが選択出来るため、一定時間内に処理の終了を要求される，使用メモリの大きさが制限されている，エラー時に大がかりな例外処理をおこなう必要がある
など、状況によって変化する要求を満たす事が可能となる。
２． コード管理プログラムとアプリケーションプログラムの間のやりとりは、ライブラリインタフェース６０３によって自動的に実現されるので、アプリケーションプログラム作成者には負担がほとんどなく、またコード管理プログラム側の変更がアプリケーションプログラムにおよぼす影響を最小限に押さえることができる。
また、本実施例のバリエーションとして、実行可能コードではなくプログラムソースをコード管理プログラムで管理する事も考えられる。この場合、必要な時にコンパイルないし解釈実行することにより、さまざまなＣＰＵに対応することが可能である。
【００３１】
【発明の効果】
以上説明したように、本発明によれば、複数のプロセスが協調して処理を行なうシステムにおいて、各プロセスのプログラムを複雑化させることなく、各プロセスに適切な処理を実行させることができるという効果がある。
【図面の簡単な説明】
【図１】本発明におけるＩｎｊｅｃｔｉｏｎ機構の概念図、
【図２】本発明の実施例１であるマルチメディアデータ検索システムのシステム構成図、
【図３】マルチメディアデータ検索システムにおけるＩｎｊｅｃｔｉｏｎ処理を説明するための概略図、
【図４】マルチメディアデータ検索システムにおけるＩｎｊｅｃｔｉｏｎ処理説明するためのフローチャート
【図５】本発明の実施例２であるプログラムコード共有システムのシステム構成図、
【図６】プログラムコード共有システムにおけるＩｎｊｅｃｔｉｏｎ処理を説明するための概略図、
【図７】プログラムコード共有システムにおけるＩｎｊｅｃｔｉｏｎ処理説明するためのフローチャートである。
【符号の説明】
１０１ Ｉｎｊｅｃｔｉｏｎの対象となっているプログラムＢ
１０１’ Ｉｎｊｅｃｔｉｏｎ終了後のプログラムＢ
１０２ Ｉｎｊｅｃｔｉｏｎ処理をおこなうプログラムＡ
１０３ プログラムＢに注入されるデータ
１０３’ プログラムＢに注入されたデータ
【産業上の利用分野】
本発明は、複数のプログラムが協調して処理をおこなっていく処理形態のプログラム制御方式に関するものである。
【０００２】
とくに、サーバ・クライアントシステムとして実現されたデータベースシステムのように、サーバからの要求をクライアントに実行させたり、クライアントに新しい機能を提供したりする機構を要求されるシステムの実現に関するプログラム制御方式である。
【０００３】
【従来の技術】
近年、ＤＴＰシステムやＤｒａｗｉｎｇ ｔｏｏｌ（絵描きプログラム）などの複雑なアプリケーションプログラムが開発されていく過程において、”プログラミングの複雑化”，”プログラムの肥大”，”状況に応じた処理の切り替えが難しい”等の問題が提起されてきた。
従来、これらの問題の解決のために、以下のような方法が提案され利用されている。
・オブジェクト指向データベースシステム（例えば、Ｔｈｅ ＯｂｊｅｃｔＳｔｏｒｅ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍ，ＣＡＣＭ ｖｏｌ．Ｎｏ．１０，ｐｐ．５０−６３，（Ｏｃｔ．１９９１）に記述されたオブジェクト指向データベースシステム）
オブジェクト指向システムの考え方をデータベースシステムに適用したシステムである。複雑な構造をもつデータを、複数のプログラム間で共有する場合に要求される機構（例：データの永続化，並行アクセス制御，バージョン管理）を提供する。オブジェクト指向データベースシステムによって、データ共有を実現するために発生するプログラミングの複雑化を緩和することが可能となる。
・ｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇ（例えば、Ａｎ Ａｐｐｒｏａｃｈ ｔｏ Ｇｅｎｕｉｎｅ Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ ＣＳＥ−９０−２５ ，８−１９９０，Ｄｉｖ ｃｏｍｐｕｔｅｒ ｓｃｉｅｎｃｅ ｕｎｉｖｅｒｓｉｔｙ ｏｆ ｃａｌｉｆｏｒｎｉａ）
【０００４】
ある機能を、プログラムの作成時にそのプログラムに組み込んでしまうかわりに、プログラムの実行時に組み込む機構である。
通常、プログラムの作成時におこなわれるモジュール組み込み手続き（ｌｏａｄｉｎｇおよびｌｉｎｋｉｎｇ）をプログラムから呼びだすことができる関数として組み込んでしまうことにより実現される。
プログラムの肥大の回避と状況に応じて処理内容を切り替える機構として使用されている。
・共有ライブラリ（例えば、Ｕｎｉｘ ＳｙｓｔｅｍＶに付属するライブラリ）複数のプログラムで共通に使用される可能性のあるモジュールを１つないし数個のファイルにまとめたものをライブラリと呼ぶが、特に各プログラムが実行時にそのファイル内の手続きを呼び出し、実行することができるようになっているものを共有ライブラリと呼ぶ。
プログラムの肥大を解消する方法として使用されている。
【０００５】
【発明が解決しようとしている課題】
しかしながら、近年グループウェアなどのように、複数のプログラムが非常に複雑な構造をもつデータやそのデータの構造に依存したプログラムコードを共有し、協調して処理をおこなっていくような、さらに複雑な共有形態を要求するアプリケーションが作成されるようになるに従い、以下のような問題が発生している。
ａ． Ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ問題
たとえば、複数のウィンドウ・アプリケーションがデータを共有している場合、共有されているデータの状態を表示に常に反映させるには、あるアプリケーションが共有されたデータを変更する度に、他のアプリケーションにその旨を通知してやらなければならない。
ｂ． 所有者問題
データ管理アプリケーション、特にデータに対するの更新やアクセス制御を要求される場合、何らかの規約に基づく動作をアプリケーションに”強制”しなければならない場合が発生する。
ｃ． 蒸発問題
共有データを参照するアプリケーション内では、複数のアプリケーションで共有され各アプリケーションの終了後も永続的に保存されるデータと、各アプリケーション固有でアプリケーションの終了と共に消滅してしまう一時的なデータが混在することになる。
この様な状況において、永続的データに一時的なデータに対する参照情報が含まれている場合、アプリケーションの終了と共に一時的なデータが消滅してしまうため、永続的データはその時点で意味のないデータを保持していることになる。多くの場合この意味のないデータは、不正な値として解釈されアプリケーションに悪影響を及ぼすことになる。
ところが、前記従来例では、複数のプログラムが、非常に複雑な構造をもつデータやそのデータの構造に依存したプログラムコードを共有し、その状態を実行時に動的に変化させていくことによって発生する、これらの問題を解決することができない。
なぜならば、オブジェクト指向データベースシステムが提供するのは、永続化されたデータの集中管理機構であり、Ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ問題や所有者問題のような複雑な分散化データ管理の問題の解決や、蒸発問題のように永続化されていないデータの管理をおこなうことができない。
さらに、共有ライブラリが提供する機能はプログラムの作成時に決定可能なプログラムコードの共有をサポートするための機構であり、上記の問題のように、実行時の状況によって動的に変化する問題に対応することができない。
また、ｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇの場合は動的なプログラムコードの追加・実行をおこなうことができるが、そのプログラムコードの共有を管理する機構を提供することができない。このため複数のプログラムによる協調処理という基盤そのものをｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇでは実現することができない。
【０００６】
【課題を解決するための手段】
上記課題を解決するために、本発明のプログラム制御方法は、それぞれ異なる第１のプログラムを実行する複数の第１のプロセスと第２のプログラムを実行する第２のプロセスとが協調して処理を行なうシステムにおいて、前記複数の第１のプロセスが前記第２のプロセスに対してプログラムコード及びデータの追加を要求し、前記第２のプロセスが複数の前記第１のプロセスよりの追加の要求を受け取ると、要求された追加を許可する１つの前記第１のプロセスを選択して、当該選択したプロセスに許可を通知するとともに、他の前記第１のプロセスに対して認証拒否を通知し、前記第１のプロセスが、前記第２のプロセスより許可の通知を受けると、前記第２のプロセスに対して前記プログラムコード及びデータの追加を実行することを特徴とする。
【０００７】
これによって、プログラムの実行時に動的に変化していく状況を監視し、かつ必要な場合には積極的に状況を変化させ、複雑な協調作業に伴う前述の問題に対処することが可能となる。
【０００８】
また本発明は、
データおよびプログラムコードを組み込まれ実行される側が、その処理に許可をあたえるための認証手段と、
複数のプロセスからのデータおよびプログラムコードの追加・実行要求の衝突を解決する手段と、
データおよびプログラムコードの追加・実行の結果、１つのプロセス内に存在することになる複数の手続き間の並行制御手段を設けることにより、
強制された動作が正当なものであり、かつ現状に最も適したものにすることである。
【０００９】
【実施例】
ここでは、本発明の第１の実施例としての、マルチメディアデータ検索システムについて説明する。
【００１０】
ここで述べるマルチメディアデータ検索システムとは、データベース等で管理されている画像、音声、文書等のマルチメディアデータを検索・表示するアプリケーションのことである。
以下、このマルチメディアデータ検索システムについて図２，図３，および図４を用いて説明する。
まず図２は、本実施例のシステム構成を表したものである。
同図において、
２０１はマルチメディアデータ検索システムの利用者がコマンドやデータを入力するための入力装置で、キーボード，マウス，スキャナ等である。
【００１１】
２０２は入力装置２０１からの入力に基づいて後述する図面に示されたフロ−チャ−トの手順を記憶し、それに基づいて本実施例の処理を実行する処理部のＣＰＵである。
【００１２】
２０３はＣＰＵ２０２等の処理によって検索されたマルチメディアデータを表示するための出力装置で、ＣＲＴディスプレイやプリンタなどである。
【００１３】
２０４は本実施例においてマルチメディアデータの検索と取り出されたデータの処理機能を利用者に提供するマルチメディアデータ処理プログラムである。
【００１４】
２０５はマルチメディアデータ処理プログラム２０４およびその実行に必要なデータを一時的に記憶するための主記憶である。
【００１５】
２０１から２０３および２０５は計算機バス２０６で結合され、ワークステーション２０７を構成する。本実施例のマルチメディアデータ検索システムはワークステーション２０７上で動作する。本実施例では、ワークステーション２０７同等なものが複数存在してもよい。この場合、各ワークステーション上でマルチメディアデータ処理プログラム２０４同じプログラムが動作し、複数の利用者に同時にサービスを提供することができる。
【００１６】
２０８は、マルチメディアデータを記憶し管理するためのデータベースシステムであり、マルチメディアデータ検索システムにマルチメディアデータの検索などのサービスを提供する。
主に、マルチメディアデータを記憶・保存するハードディスク等の２次記憶装置２０９と、マルチメディアデータ処理プログラム２０４からの要求に従ってマルチメディアデータの検索・管理をおこなうデータベース処理プログラム２１０とで構成されており、ワークステーション２０７上、あるいは別の同様な構造をもつコンピュータ上で動作する。
【００１７】
本実施例において、本発明の中心であるデータおよびプログラムコードの共有機能はデータベースシステム２０８内のデータベース処理プログラム２１０によって提供されている。
２１１は、データベースシステム２０８とマルチメディアデータ処理プログラム２０４を結合し、システム間でのデータ交換を可能にする手段を示している。
この結合は通常、コンピュータネットワークおよびその上で実現されたプロセス間通信機能によって実現される。
【００１８】
つぎに図３は、図２のシステム構成上で動作するマルチメディアデータ処理プログラム２０４およびデータベース処理プログラム２１０の処理をあらわす概念図である。以降の説明は主にこの図と後で述べる図４にもとづいて行う。
同図において、
３０１は図２におけるワークステーション２０７上で動作しているマルチメディアデータ検索システムであり、３０２は図３上でのデータベースシステム２０８をあらわすものである。
また、３０３はマルチメディアデータ検索システム３０１とデータベースシステム３０２の間で共有されるマルチメディアデータを保持するための共有メモリである。
マルチメディアデータ検索システム３０１内部の３０４は出力装置２０３の１つとして使用されるＣＲＴディスプレイであり、マルチメディアデータ検索システムの利用者による検索コマンド等の結果がここに表示される。
３０５はマルチメディアデータ処理プログラム２０４がワークステーション２０７上で動作している時の形態をあらわすマルチメディアデータ処理プロセスであり、３０６はデータベース処理プログラム２１０をあらわすデータベース処理プロセスである。
３０７は２次記憶装置２０７に相当するハードディスクである。
のこる３０８，３０９，３１０，３１１は、あるマルチメディアデータのさまざまな形態を表現している。
すなわち、３０８はそのマルチメディアデータのハードディスク３０７上でのデータ形式であり、３０９と３１０はそのデータの共有メモリ３０３上でのデータ形式をあらわす。それぞれマルチメディアデータを処理するプログラムコードとマルチメディアデータそのものである。
また、３１１はＣＲＴディスプレイ３０４上でのビットマップデータ形式を表現しており、マルチメディアデータ検索システムの利用者が要求した検索結果の表示に相当している。
【００１９】
これらのデータ形式間の変換はマルチメディアデータ処理プロセス３０５およびデータベース処理プロセス３０６によっておこなわれる。
例えば、利用者からの検索結果としてハードディスク３０７上のデータ３０８がＣＲＴディスプレイ３０４に表示されるといった処理の場合、データ３０８はまずデータベース処理プロセス３０６によって共有メモリ上でのデータ形式３０９と３１０に変換され、共有メモリ３０３に書き込まれる。ここでは、他のデータへの参照データを共有メモリ上でのポインタにおきかえる（この処理をｓｗｉｚｚｌｉｎｇと呼ぶ。）等の変換がおこなわれる。
次にプログラムコード３０９はマルチメディアデータ処理プロセス３０５に組み込まれ、実行される。プログラムコード２０９の処理により、マルチメディアデータ３１０はＣＲＴディスプレイ上でのデータ形式３１１に変換され表示される。
【００２０】
ここで、このプログラム間でのデータおよびプログラムコードの組み込みを以降、”Ｉｎｊｅｃｔｉｏｎ”と呼び、その実現機構を”Ｉｎｊｅｃｔｉｏｎ機構”と呼ぶことにする。
【００２１】
図１ａ，１ｂは、このＩｎｊｅｃｔｉｏｎ機構の動作イメージをあらわしており、図１ａにおいて、プログラムＢ１０１がプログラムＡ１０２にデータと実行可能なプログラムコード１０３を付加（ないし置換）している。
【００２２】
また、図１ｂは図１ａの処理結果をあらわし、プログラムＢ１０１’はプログラムコード１０３を付加されたあとのプログラムＢ１０１をあらわしている。プログラムコード１０３’は、プログラムＢ１０１’付加されたプログラムコード１０３をあらわしている。
プログラムＢ１０１’上でプログラムコード１０３’が動作することにより、プログラムＡ１０２が意図した動作を強制することが可能となる。
本実施例では、この”意図した動作”がデータ３０８をＣＲＴディスプレイ３０４上に表示させることに相当する。
【００２３】
本実施例において、このＩｎｊｅｃｔｉｏｎ機構は以下のようにして実現されている。まず、プロセス間の要求伝達は、ＵＮＩＸ等のオペレーティングシステムが提供するプロセス間通信機構（ｓｏｃｋｅｔなど）によっておこなわれる。データおよびプログラムコードの共有あるいは追加・変更手段の実現にためには、データ共有の基本機構として共有メモリシステムを使用し、共有メモリ上にバイナリデータとしておかれたプログラムコードをｄｙｎａｍｉｃ ｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇ機構を用いて動作中のプロセスに組み込む。
あるいは、そのプログラムコードが他の共有データのみに依存している場合なら、ｄｙｎａｍｉｃｌｏａｄｉｎｇ／ｌｉｎｋｉｎｇの機構は特に必要なく、単にプログラムコードとそれが参照するデータを共有メモリ上に書き込むだけでよい。
共有したデータとプログラムコードの実行は、最近のオペレーティングシステムでサポートされるようになってきたｔｈｒｅａｄやｌｉｇｈｔ ｗｅｉｇｈｔ ｐｒｏｃｅｓｓ生成機構など、新たな処理の流れ（これをａｃｔｉｖｉｔｙと呼ぶ）を生成することができる機構を使用して実現することができる。ただし通常、新しいａｃｔｉｖｉｔｙの生成は同一プログラム内に存在している他のａｃｔｉｖｉｔｙのみに許されていることが多い。この場合、別のプログラムからａｃｔｉｖｉｔｙの生成を可能にする、プログラム間のインタフェースを規定する必要がある。
また、データおよびプログラムコードの追加・実行要求の認証の実現は、共有メモリ上に存在するが、まだリンクされていないデータおよびプログラムコードを読み出し、その内容を調べることにより、データの正当性を確認することで可能である。
具体な判定方法としては、オブジェクト指向言語におけるクラス継承の機構を利用し、そのデータが特定のクラスのサブクラスのインスタンスとなっているか否かをチェックし、そのサブクラスのインスタンスのみ認証されるという方式が考えられる。
ただし、本実施例においては、マルチメディアデータ処理プロセス３０５そのものが重要なデータを保持せず、データのほとんどがデータベース処理プロセス３０６によって管理されているため、Ｉｎｊｅｃｔｉｏｎは無条件で認証される。Ｉｎｊｅｃｔｉｏｎにおける認証の実施については、後で述べるの実施例で説明する。
データおよびプログラムコードの追加・実行要求の衝突を解決する手段としては、各要求に優先順位を付け、最も優先順位が高いものを採用するといった戦略が可能である。
本実施例では、あとで述べるように、要求の衝突は発生しないようになっている。
衝突の解決する手段の実施についても、後で述べるの実施例で説明する。
最後に、１つのプロセス内に存在することになる複数の手続き間の並行制御手段としては、従来のオブジェクト指向データベースでデータの共有に用いられている、ロックにもとづく変更アクセス制御機構を、従来のようなプロセス単位ではなく、プロセス内に同時に複数存在しうるａｃｔｉｖｉｔｙを単位として適用する。このときａｃｔｉｖｉｔｙ間で優先順位づけを行い、特定のａｃｔｉｖｉｔｙを優先的に実行させる機構が必要となる。本実施例では、Ｉｎｊｅｃｔされるプログラムコード３０９はかならず、マルチメディアデータ処理プロセス２０５の主手続きより高い優先度をもち、優先的に実行される。
【００２４】
さて、上記構成に基づいた本実施例の動作を図４ａ，４ｂ，４ｃのフローチャートを用いて説明する。各フローチャートはそれぞれ、マルチメディアデータ処理プロセス３０５の主手続き、データベース処理プロセス３０６内のＩｎｊｅｃｔｉｏｎ機構、およびプログラムコード３０９のＩｎｊｅｃｔｉｏｎの前におこなわれるＩｎｊｅｃｔｉｏｎ認証手続きの処理の流れをあらわしている。これらのフローチャートは見かけ上独立しているが、あるフローチャートのｏｎｅｓｔｅｐが他のフローチャートの処理を開始させるというかたちで、互いに関連しあっている。また、これらの処理の流れはひとつのプロセス内に同時に複数存在しうる。
【００２５】
本実施例の説明では便宜上、データベース処理プロセス３０６がマルチメディアデータ処理プロセス３０５より先に起動されている事を仮定する。また、データベース処理プロセス３０６は１つだけ起動されており、２つ以上のＩｎｊｅｃｔｉｏｎが同時に発生することはないものとする。
（Ｓ４ｂ０１） マルチメディアデータ処理プロセス３０５は、その起動後にＩｎｊｅｃｔｉｏｎが受け入れ可能である事を宣言する。
（Ｓ４ａ０１） データベース処理プロセス３０６は、マルチメディアデータ処理プロセス３０５のＩｎｊｅｃｔｉｏｎ受け入れ可能宣言を検知し、（例えばＩｎｊｅｃｔｉｏｎ受け入れ先リストなどにマルチメディアデータ処理プログラム３０５を登録し）憶する。
その後で、マルチメディアデータ検索システムの利用者によってマルチメディアデータの検索が要求されると（Ｓ４ｂ０２）、
（Ｓ４ｂ０３） マルチメディアデータ処理プロセス３０５はデータベース処理プロセス３０６に対し、利用者によって指示されたデータ３０８の検索を要求する。この時点で、マルチメディアデータ処理プロセス３０５の処理は利用者からの入力受付状態にもどり、次のコマンド等を受けつける（Ｓ４ｂ０４）。
以降の処理は主にデータベース処理プロセス３０６によって実行される。
（Ｓ４ａ０２） データ３０８の検索要求がデータベース処理プロセス３０６に通知されると、
（Ｓ４ａ０３） 検索要求に付加されている情報をもとに、要求されたデータ３０８をハードディスク３０７から取り出す。
（Ｓ４ａ０４） データベース処理プロセス３０６はマルチメディアデータ処理プログラム３０５に対し取り出したデータ３０８のＩｎｊｅｃｔｉｏｎの認証要求を発行する。
認証要求にはＩｎｊｅｃｔｉｏｎの発生とＩｎｊｅｃｔに関する情報が含まれている。
マルチメディアデータ処理プログラム３０５内の認証手続きは、Ｉｎｊｅｃｔｉｏｎの認証要求を検知し（Ｓ４ｃ０１）、
（Ｓ４ｃ０２） Ｉｎｊｅｃｔｉｏｎの認証が可能か否かを判断し、データベース処理プログラム３０６に結果を通知する（Ｓ４ｃ０３）。
通知された結果、
（Ｓ４ａ０５） Ｉｎｊｅｃｔｉｏｎの認証を受けることができなかった場合はＩｎｊｅｃｔｉｏｎは実行されず、マルチメディアデータ処理プロセス３０５にエラーが送られる。このエラーは、ＣＲＴディスプレイ３０４に表示されシステムの利用者に通知される（Ｓ４ａ０６）。
（Ｓ４ａ０７） Ｉｎｊｅｃｔｉｏｎが許可された場合は、必要なデータ３０８はプログラムコード３０９とマルチメディアデータ３１０に変換され、共有メモリ３０３上に置かれる。
【００２６】
ただし、プログラムコード３０９はデータ３０８と先に参照されたデータ間で共用されている場合がある。このような場合、プログラムコード３０９がすでに共有メモリ３０３上に存在することになるので、マルチメディアデータ３１０みが共有メモリ３０３上に置かれる。ただし、プログラムコード３０９とマルチメディアデータ３１０の（マルチメディアデータ３１０はプログラムコード３０９によって処理されるという）関係は保存される。
さらに、プログラムコード３０９はマルチメディアデータ処理プログラム２０４に動的にリンクされる。
このとき、プログラムコード３０９が前の処理によってすでにリンクされていた場合はリンクはおこなわれない。
この時点で、マルチメディアデータ処理プロセス３０５も共有メモリ３０３を介してデータを処理するための準備が完了する。
（Ｓ４ｂ０８） マルチメディアデータ処理プログラム２０４内にリンクされ、マルチメディアデータ処理プロセス３０５に組み込まれたプログラムコード３０９にａｃｔｉｖｉｔｙを与え、実行する。
プログラムコード３０９はＣＲＴディスプレイ３０４へのデータの表示等の処理を行う。
データベース処理プロセス３０６自身の処理はこの時点で完了し、次の要求発生を待つことになる（Ｓ４ａ０２）。
最後に、プログラムコード３０９の実行が終了し、利用者によって入力されたコマンドの処理が完了する。
以上のようなＩｎｊｅｃｔｉｏｎの実現により、本実施例では以下のような効果を得ることができる。
１． マルチメディアデータのブラウジング（表示）機構をＩｎｊｅｃｔｉｏｎを使用して後から組み込む事により、マルチメディアデータ処理プログラム２０４を一切変更することなく、新しいタイプのデータの取り込み，データフォーマットの変更への対応，データの表示等の処理の効率化をおこなうことができる。
２． プログラムコード３０９がマルチメディアデータ処理プロセス３０５の主手続きから切り離され、主手続きとは別のａｃｔｉｖｉｔｙが与えられることにより、マルチプロセッサ環境での実行スピードの改善を期待することができる。
【００２７】
（その他の実施例）
以下、本発明の第２の実施例であるプログラムコード共有システムについて図５，図６，および図７を用いて説明する。
ここで述べるプログラムコード共有システムとは、あるプログラムの一部（手続き）をデータベース等で管理してそのプログラム自身から切り離す事により、プログラムコードの共有やプログラムの拡張・修正を容易にする事を目的としたソフトェアシステムのことである。
まず図５は、本実施例におけるシステム構成をあらわしたものであり、先に述べたマルチメディアデータ検索システムとほぼ同じ構成である。
同図において、
５０１および５０１’はそれぞれ、本実施例上で動作するアプリケーションプログラムの利用者が、コマンドやデータを入力
するための入力装置で、キーボード、マウスなどである。
５０２および５０２’はそれぞれ、入力装置５０１，５０１’からの入力にもとづいてアプリケーションプログラムの処理を実行するＣＰＵである。ここでは、ＣＰＵ５０２とＣＰＵ５０２’が異なる命令セットを持っている場合を想定している。
５０３および５０３’はそれぞれ、ＣＰＵ５０２，ＣＰＵ５０２’等の処理によって検索されたマルチメディアデータを表示するための出力装置で、ＣＲＴディスプレイやプリンタなどである。
５０４および５０４’は、本実施例上で動作するアプリケーションプログラム５０５，５０５’およびその処理に必要なデータを一時的に記憶するための記憶装置である。５０６，５０６’はそれぞれ、５０１から５０４および５０１’から５０４’までの構成要素を結合する計算機バスであり、これらはワークステーション５０７，５０７’を構成する。アプリケーションプログラム５０５，５０５’はそれぞれワークステーション５０７，５０７’上で動作している。
５０８は、実行可能なプログラムコードを記憶し管理するためのプログラム管理データベースである。プログラム管理データベース５０８はワークステーション５０７ないし５０７’上あるいは、別の同様な構造をもつコンピュータ上で動作する。
【００２８】
本実施例においては、本発明の骨子であるデータとプログラムコードの共有機構は、プログラム管理データベース５０８とアプリケーションプログラム５０５，５０５’にリンクされたインタフェースライブラリ（後述）によって提供される。
【００２９】
また、本実施例においては、プログラム管理データベース５０８と同様なプログラム管理データベースが同時に複数存在してよい。ただしこの場合も、あるプログラムコードが複数の異なるプログラム管理データベースによって管理されることは禁止する。
最後の５０９，５０９’はそれぞれ、プログラム管理データベース５０８とアプリケーションプログラム５０５，５０５’を結合し、プログラムコードの共有を可能にする手段である”Ｉｎｊｅｃｔｉｏｎ機構”をあらわす。コンピュータネットワークおよびその上で実現されたプロセス間通信機構を利用して実現することが可能である。
【００３０】
つぎに図６は、図５のシステム上で動作するアプリケーションプログラム５０５およびプログラム管理データベース５０８の間でおこなわれる処理をあらわしたものである。以降の説明は主にこの図にもとづいて行う。アプリケーションプログラム５０５’とプログラム管理データベース５０８間でも同様な処理がおこなわれる。
同図において、
６０１は図５における、アプリケーションプログラム５０５が実行する処理を表現するアプリケーションプロセスである。その内部に存在する６０２はアプリケーションプロセス６０１の主手続きである。また、６０３はアプリケーションプロセス６０１からプログラム管理データベースへのインタフェースおよびＩｎｊｅｃｔｉｏｎ処理における認証手続き等の機構を提供するライブラリである。
６０４は図６においてプログラム管理データベース５０５をあらわし、プログラムコードを記憶・保存するハードディスク６０５とプログラムコードの検索・管理をおこない、本実施例においてＩｎｊｅｃｔｉｏｎ処理を担うコード管理プロセス ６０６によって構成される。
６０７は前の実施例と同様に、プログラム管理データベース６０４が、アプリケーションプロセス６０１に提供するプログラムコードを保持する共有メモリである。
また、６０８，６０９はそれぞれ、あるアプリケーションプロセス６０１に付加されるプログラムコードの、ハードディスク６０５上および共有メモリ６０７上でのデータ形式を表現している。
本実施例では、データ６０８からプログラムコード６０９への変換は、アプリケーションプロセス６０１へのリンクによっておこなわれる手続き呼びだし等の参照先解決が主なものである。このため、本実施例においては、参照関係が各アプリケーションプログラムに依存するようなプログラムコードでは、ハードディスク上のデータから２つ以上のプログラムコードイメージが共有メモリ上に生成される場合が発生する。
このようにして、アプリケーションプロセス６０１にリンクされたプログラムコード６０９は、主手続き６０２から呼びだされ、実行される。
本実施例においても、Ｉｎｊｅｃｔｉｏｎ機構は先に述べた実施例と同様にして実現されるが、
Ｉｎｊｅｃｔｉｏｎ実行時における認証処理が異なっている。
本実施例では、最も現在の状況に適したプログラムコードに認証が与えられる。すなわち、プログラムコードの性格をあらわす実行スピードとメモリ消費量のオーダの２つのパラメタを適当な評価関数にあたえた結果によって、現在の状況に適しているか否かを評価する。
もちろん、すべてのプログラムコードは、プログラム管理データベースに記憶された時に、プログラムコードの性格をあらわすこれらのパラメタが与えられる。また、Ｉｎｊｅｃｔされるプログラムコードにこれらのパラメタで優劣がつけられない場合に対処するため、プログラム管理データベース間での優先順位が決まっており、その優先順位に従ってＩｎｊｅｃｔｉｏｎが認証されるプログラムコードが決定される。プログラム管理データベース間での優先順位を決定するパラメタとしては、ネットワーク上での遠近を使用し、最もネットワーク上で近いところにあるプログラムコードが認証される。
さて、上記構成に基づいた本実施例の動作を図７ａ，７ｂ，７ｃのフローチャートを用いて説明する。
各フローチャートはそれぞれ、主手続き６０２，コード管理プロセス６０６，およびサポートライブラリインタフェース６０３内のＩｎｊｅｃｔｉｏｎ認証手続きの処理の流れをあらわしている。各フローチャートは見かけ上独立しているが、あるフローチャートのｏｎｅｓｔｅｐが、他のフローチャートの処理を開始させるというかたちで、互いに関連している。
また、これらの処理の流れは、プロセス内に同時に複数存在することができる。本実施例においても、コード管理プロセス６０６がアプリケーションプロセス６０１より先に起動されているとして説明する。
（Ｓ７ｂ０１） アプリケーションプロセス６０１はその起動後にＩｎｊｅｃｔｉｏｎが受け入れ可能である事を宣言する。ただし、この処理は、サポートライブラリ６０３によって自動的に実行される。
（Ｓ７ａ０１） コード管理プロセス６０４は、アプリケーションプロセス６０１のＩｎｊｅｃｔｉｏｎ受け入れ可能宣言を検知し、Ｉｎｊｅｃｔｉｏｎ受け入れ先リストにアプリケーションプロセス６０１を登録する。
（Ｓ７ａ０２） コード管理プロセス６０４は、逆にアプリケーションプロセス６０１に対してａｃｋｎｏｗｌｅｄｇｅメッセージをかえす。
（Ｓ７ｂ０２） アプリケーションプロセス６０１は、コード管理プロセス６０４のａｃｋｎｏｗｌｅｄｇｅメッセージを検知し、Ｉｎｊｅｃｔｉｏｎ候補リストにコード管理プロセス６０４を登録しておく。
その後の処理で、アプリケーションプロセス６０１内でのある手続き呼び出しが実行されると（Ｓ７ｂ０３）、
（Ｓ７ａ０３） この手続き呼び出しはＩｎｊｅｃｔｉｏｎ開始イベント７０１として、コード管理プロセス６０６に検知される。この時点で、アプリケーションプロセス６０１の処理は一時的に中断される。
（Ｓ７ａ０４） コード管理プロセス６０６はイベント７０１を検知すると、イベント７０１に付加されている情報をもとに（この情報は、主手続き６０２による手続き呼び出しに関するものであり、要求される手続きを一意に決定するために必要な手続き名，ＩＤ番号等を含んでいる。）、必要なプログラムコード６０８をハードディスク６０５から取り出す。取り出された、プログラムコード６０８はそのまま共有メモリ６０７上に書き込まれる。
この処理において、ハードディスク６０５中には、同じ入力に対して同じ結果をかえす等価なプログラムコードが複数存在しうる。たとえば、さまざまな種類のＣＰＵに対応するために、各ＣＰＵ用のバイナリが管理していたり、同一の意味をもつが、実行効率が異なるインプリメントがいくつか存在するような場合である。
この様な場合においても、イベント７０１に付加されている情報をもとに、要求されるコードを一意に決定できるものとする。
（Ｓ７ａ０５） コード管理プロセス６０６はアプリケーションプロセス６０１に対し取り出したプログラムコード６０８のＩｎｊｅｃｔｉｏｎ認証要求を発行する。
認証要求にはＩｎｊｅｃｔｉｏｎの発生とＩｎｊｅｃｔされるプログラムコードに関する情報（あるいはＩｎｊｅｃｔされるプログラムコード６０８自身）が含まれている。この情報は、Ｉｎｊｅｃｔｉｏｎの可・不可の判定や、複数のＩｎｊｅｃｔｉｏｎ要求の衝突が発生した場合の調整に使用される。
また、この時点でコード処理プロセス６０４における６０１に対する処理は認証が終了するまで中断される。ただし、他のアプリケーションプロセスに対するＩｎｊｅｃｔｉｏｎ処理には影響しない。
（Ｓ７ｃ０１） サポートライブラリ６０３内の認証手続きは、Ｉｎｊｅｃｔｉｏｎ認証要求を検知する。本実施例においてはさらに、Ｉｎｊｅｃｔｉｏｎの対象となるプログラムコードを提供することのできるすべてのプログラム管理データベースからの認証要求を集める。（Ｉｎｊｅｃｔｉｏｎの対象となるプログラムコードを提供できないプログラム管理データベースからも、その旨を通知する”空認証要求”が発行されるものとする。）
（Ｓ７ｃ０２） 各Ｉｎｊｅｃｔｉｏｎ要求のなかからの認証を許すものを１つだけ選択する。
（Ｓ７ｃ０３） 選ばれたプログラム管理データベースに認証がおこなわれたことを通知し、他のプログラム管理データベースには認証が拒否されたことを通知する。ここではプログラム管理データベース６０２が認証されたとして説明を続ける。
すべての要求が認証できない場合は、サポートライブラリ６０３が例外処理をおこなう。
（Ｓ７ａ０６，Ｓ６ａ０７） プログラムコード６０８はアプリケーションプログラム６０１に動的にリンクされ、共有メモリ上でのプログラムコードイメージ６０９に変換される。
（Ｓ７ａ０７） プログラムコード６０９がアプリケーションプログラム６０１にＩｎｊｅｃｔされたことを通知する。
（Ｓ７ｂ０４） アプリケーションプログラム６０１は中断されていた手続き呼び出しを再開し、Ｉｎｊｅｃｔされたプログラムコード６０９が実行される。
以上のようなＩｎｊｅｃｔｉｏｎの利用により、本実施例では以下のような効果を得ることが出来る。
１． 複数のコード管理プログラムから提供されたコードから最適なものをアプリケーションプログラムが選択出来るため、一定時間内に処理の終了を要求される，使用メモリの大きさが制限されている，エラー時に大がかりな例外処理をおこなう必要がある
など、状況によって変化する要求を満たす事が可能となる。
２． コード管理プログラムとアプリケーションプログラムの間のやりとりは、ライブラリインタフェース６０３によって自動的に実現されるので、アプリケーションプログラム作成者には負担がほとんどなく、またコード管理プログラム側の変更がアプリケーションプログラムにおよぼす影響を最小限に押さえることができる。
また、本実施例のバリエーションとして、実行可能コードではなくプログラムソースをコード管理プログラムで管理する事も考えられる。この場合、必要な時にコンパイルないし解釈実行することにより、さまざまなＣＰＵに対応することが可能である。
【００３１】
【発明の効果】
以上説明したように、本発明によれば、複数のプロセスが協調して処理を行なうシステムにおいて、各プロセスのプログラムを複雑化させることなく、各プロセスに適切な処理を実行させることができるという効果がある。
【図面の簡単な説明】
【図１】本発明におけるＩｎｊｅｃｔｉｏｎ機構の概念図、
【図２】本発明の実施例１であるマルチメディアデータ検索システムのシステム構成図、
【図３】マルチメディアデータ検索システムにおけるＩｎｊｅｃｔｉｏｎ処理を説明するための概略図、
【図４】マルチメディアデータ検索システムにおけるＩｎｊｅｃｔｉｏｎ処理説明するためのフローチャート
【図５】本発明の実施例２であるプログラムコード共有システムのシステム構成図、
【図６】プログラムコード共有システムにおけるＩｎｊｅｃｔｉｏｎ処理を説明するための概略図、
【図７】プログラムコード共有システムにおけるＩｎｊｅｃｔｉｏｎ処理説明するためのフローチャートである。
【符号の説明】
１０１ Ｉｎｊｅｃｔｉｏｎの対象となっているプログラムＢ
１０１’ Ｉｎｊｅｃｔｉｏｎ終了後のプログラムＢ
１０２ Ｉｎｊｅｃｔｉｏｎ処理をおこなうプログラムＡ
１０３ プログラムＢに注入されるデータ
１０３’ プログラムＢに注入されたデータ
Claims (8)
- それぞれ異なる第１のプログラムを実行する複数の第１のプロセスと第２のプログラムを実行する第２のプロセスとが協調して処理を行なうシステムにおいて、
前記複数の第１のプロセスが前記第２のプロセスに対してプログラムコード及びデータの追加を要求し、
前記第２のプロセスが複数の前記第１のプロセスよりの追加の要求を受け取ると、要求された追加を許可する１つの前記第１のプロセスを選択して、当該選択したプロセスに許可を通知するとともに、他の前記第１のプロセスに対して認証拒否を通知し、
前記第１のプロセスが、前記第２のプロセスより許可の通知を受けると、前記第２のプロセスに対して前記プログラムコード及びデータの追加を実行することを特徴とするプログラム制御方法。 - 前記第１及び第２のプロセスが、追加された前記プログラムコード及びデータを共有メモリを用いて共有することを特徴とする請求項１に記載のプログラム制御方法。
- 前記第２のプロセスが、複数の前記第１のプロセスのそれぞれが追加を要求するプログラムコードのパラメータを評価して、認証許可を通知する１つの前記第１のプロセスを決定することを特徴とする請求項１に記載のプログラム制御方法。
- 前記第１のプロセスが前記第２のプロセスに対して、追加された前記プログラムコードを実行させることにより、所定の動作を強制することを特徴とする請求項１に記載のプログラム制御方法。
- 前記プログラムコード及びデータの追加にともなって、前記第１及び第２のプロセス間で行なわれる処理のプロトコルが規定されていることを特徴とする請求項１に記載のプログラム制御方法。
- 前記第２のプロセスが複数のプログラムコードの並行実行を制御可能であることを特徴とする請求項１に記載のプログラム制御方法。
- 前記第１のプロセスから前記第２のプロセスに対する前記プログラムコード及びデータの追加が随時実行可能であることを特徴とする請求項１に記載のプログラム制御方法。
- 前記第１及び第２のプロセスが、ネットワークを介して接続された異なる計算機上でそれぞれ実行されることを特徴とする請求項１に記載のプログラム制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12617093A JP3553991B2 (ja) | 1993-05-27 | 1993-05-27 | プログラム制御方法 |
| US08/812,080 US5894573A (en) | 1993-05-27 | 1997-03-06 | Program controlling method having transfer of code and data among programs and apparatus therefor |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP12617093A JP3553991B2 (ja) | 1993-05-27 | 1993-05-27 | プログラム制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH06337794A JPH06337794A (ja) | 1994-12-06 |
| JP3553991B2 true JP3553991B2 (ja) | 2004-08-11 |
Family
ID=14928420
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12617093A Expired - Fee Related JP3553991B2 (ja) | 1993-05-27 | 1993-05-27 | プログラム制御方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5894573A (ja) |
| JP (1) | JP3553991B2 (ja) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08153076A (ja) * | 1994-11-30 | 1996-06-11 | Canon Inc | 協調作業支援方法及びその装置 |
| DE19732011A1 (de) * | 1997-07-25 | 1999-01-28 | Abb Patent Gmbh | Verfahren zum ortstransparenten Austausch von Prozeßdaten |
| JP3254434B2 (ja) * | 1999-04-13 | 2002-02-04 | 三菱電機株式会社 | データ通信装置 |
| WO2000068793A1 (en) * | 1999-05-10 | 2000-11-16 | Handsfree Networks, Inc. | System for automated problem detection, diagnosis, and resolution in a software driven system |
| US6742141B1 (en) | 1999-05-10 | 2004-05-25 | Handsfree Networks, Inc. | System for automated problem detection, diagnosis, and resolution in a software driven system |
| US7003781B1 (en) * | 2000-05-05 | 2006-02-21 | Bristol Technology Inc. | Method and apparatus for correlation of events in a distributed multi-system computing environment |
| US20020034964A1 (en) * | 2000-09-05 | 2002-03-21 | Yuichi Bannai | Personal information terminal equipped with enlarging optical system |
| US7113168B2 (en) | 2000-09-12 | 2006-09-26 | Canon Kabushiki Kaisha | Compact information terminal apparatus, method for controlling such apparatus and medium |
| JP2002140221A (ja) * | 2000-11-02 | 2002-05-17 | Canon Inc | 情報処理装置、情報処理方法、及び、記憶媒体 |
| JP2002140193A (ja) * | 2000-11-02 | 2002-05-17 | Canon Inc | 情報処理装置及びその方法、コンピュータ可読メモリ |
| US20020053000A1 (en) * | 2000-11-02 | 2002-05-02 | Masanori Wakai | Information processing apparatus and method, and computer readable memory |
| AU2003228512A1 (en) * | 2002-04-10 | 2003-10-27 | Instasolv, Inc. | Method and system for managing computer systems |
| US7849362B2 (en) * | 2005-12-09 | 2010-12-07 | International Business Machines Corporation | Method and system of coherent design verification of inter-cluster interactions |
| JP5173475B2 (ja) * | 2008-02-19 | 2013-04-03 | キヤノン株式会社 | リモートコントローラ装置、その制御方法及びプログラム |
| JP2018051799A (ja) | 2016-09-26 | 2018-04-05 | 富士ゼロックス株式会社 | 画像形成装置及びプログラム |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4814971A (en) * | 1985-09-11 | 1989-03-21 | Texas Instruments Incorporated | Virtual memory recovery system using persistent roots for selective garbage collection and sibling page timestamping for defining checkpoint state |
| US5247678A (en) * | 1989-10-12 | 1993-09-21 | Texas Instruments Incorporated | Load time linker for software used with a multiprocessor system |
| US5426747A (en) * | 1991-03-22 | 1995-06-20 | Object Design, Inc. | Method and apparatus for virtual memory mapping and transaction management in an object-oriented database system |
| US5359721A (en) * | 1991-12-18 | 1994-10-25 | Sun Microsystems, Inc. | Non-supervisor mode cross address space dynamic linking |
| US5475840A (en) * | 1993-04-13 | 1995-12-12 | Sun Microsystems, Inc. | High performance dynamic linking through caching |
-
1993
- 1993-05-27 JP JP12617093A patent/JP3553991B2/ja not_active Expired - Fee Related
-
1997
- 1997-03-06 US US08/812,080 patent/US5894573A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US5894573A (en) | 1999-04-13 |
| JPH06337794A (ja) | 1994-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3553991B2 (ja) | プログラム制御方法 | |
| US5539909A (en) | Negotiation method for calling procedures located within other objects without knowledge of their calling syntax | |
| US7000220B1 (en) | Networked software development environment allowing simultaneous clients with combined run mode and design mode | |
| EP0472279B1 (en) | Apparatus for implementing data bases to provide object-oriented invocation of applications | |
| US5341478A (en) | Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment | |
| US5440744A (en) | Methods and apparatus for implementing server functions in a distributed heterogeneous environment | |
| EP0474339B1 (en) | Methods and apparatus for providing a client interface to an object-oriented invocation of an application | |
| US5748959A (en) | Method of conducting asynchronous distributed collective operations | |
| US6026428A (en) | Object oriented thread context manager, method and computer program product for object oriented thread context management | |
| US5872971A (en) | Data processing systems and methods providing interoperability between data processing resources | |
| JPH06314227A (ja) | バージョン化オブジェクトに対するロッキング機構 | |
| US6112253A (en) | Object-oriented method maintenance mechanism that does not require cessation of the computer system or its programs | |
| US6189007B1 (en) | Method and apparatus for conducting a high performance locking facility in a loosely coupled environment | |
| JPH11252209A (ja) | ネットワーク管理システム | |
| JPH0683634A (ja) | 障害検出方法 | |
| US6253274B1 (en) | Apparatus for a high performance locking facility | |
| US7689999B2 (en) | Sharing dynamically changing resources in software systems | |
| US20030009601A1 (en) | Program execution method in an environment of a plurality of computers | |
| EP2375326A1 (en) | Executing operations via asynchronous programming model | |
| EP0767434A2 (en) | System and method for adding object services to a binary class in an object oriented system | |
| JP3586943B2 (ja) | プログラムロード装置と方法 | |
| CN116339920B (zh) | 基于云平台的信息处理方法、装置、设备及介质 | |
| JP4071678B2 (ja) | バッチアプリケーション実行制御方法，バッチアプリケーション実行制御装置およびバッチアプリケーション実行制御プログラム | |
| CN116980437A (zh) | 一种深度学习异构计算系统 | |
| JPH113231A (ja) | ソフトウェア処理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040329 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040420 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040506 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090514 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100514 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100514 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110514 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120514 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120514 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130514 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |