JPH03149642A

JPH03149642A - リモート資源定義方式

Info

Publication number: JPH03149642A
Application number: JP1289112A
Authority: JP
Inventors: Tomikazu Watanabe; 渡辺　富美一
Original assignee: Fuji Facom Corp
Current assignee: Fuji Facom Corp
Priority date: 1989-11-07
Filing date: 1989-11-07
Publication date: 1991-06-26

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】〔概要〕リモート資源定義方式に関し、実資源の存在位置を意識
することなく業務プログラムの作成ができるようにし、
生産性の向上ができるようにすることを目的とし、複数
のシステムがネットワークにより接続された分散システ
ムにおいて各システム内に業務プログラムが扱う自シス
テムにない実資源を仮想資源として抽象化して定義した
仮想資源変換テーブルを設け、仮想資源変換テーブルに
は、実資源が存在するシステム名を定義する。利用した
い資源が自システムに無ければ、この仮想変換テーブル
に定義されたシステムへ当該資源の利用が依頼され、実
資源名へは、すべて、その資源を持つシステムにて変換
される。

〔従来の技術〕

従来、ネットワーク上のファイル管理については、ネッ
トワークファイルシステム（ＮＦＳ：　　Ｎｅｔ〜ｗｏ
ｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍ）、リモートファイル（
ＲＰＳ：　　Ｒｅ−ｍｏｔｅ　Ｆｉｌｅ　Ｓｈａｒｉｎ
ｇ）が知られている。

この場合、ファイルシステム単位に自システム上にマウ
ントする手法をとっていた。第１２図の例ではファイル
システム１２仕の業務プログラム２１−１１からファイ
ルシステム７２内のファイル１２２°ｌをアクセスした
い場合、ファイル１２２１を含むファイルシステム１２
１のディレクトリ＃　Ｅ　ｗにマウントする。業務プロ
グラム１２１１からは／　Ａ　／　Ｅ　／　Ｄ　／　ｒ
ｆ　ｉ　ｌｅで識別される。この場合ファイルシステム
１２２仕では／Ａ／Ｂ／Ｄ／ｒｆｉｌｅ”で識別される
ため、業務プログラム１２１１をファイルシステム１２
３上で動作させるには、プログラムの変更が必要となる
。もちろん、同一の識別名になるように、ファイルシス
テムをマウントすることが考えられるが、ネットワーク
全体で統一することは困難である。

〔発明が解決しようとする課題〕

上記のような従来のものにおいては、次のような欠点が
あった。

（１）　　ＮＦＳ、ＲＦＳは、ファイルを対象としてお
り、他の資源（データベース、ＦＡ設備機器、他プロセ
スとの通信等）にアクセスするには各々異なったインタ
フェースを用いてプログラムを作成しなければならない
。

（２）　　業務プログラムの作成に当たって、対象ファ
イルの位置を意識する必要がある。

（３）業務プログラムの動作システムを変更する場合ア
クセスする資源への位置関係が変わってしまうため、プ
ログラムの変更が必要である。

１４）資源の配置を変更した場合、それをアクセスして
いる全業務プログラムを修正する必要がある。

（５）業務量の増加に伴う負荷の増大に対して、処理シ
ステムを増設して、対処しようとした場合、業務プログ
ラムの移植のためにプログラムの変更を必要とする。

本発明は、このような従来の欠点を解消し、実資源の存
在位置を意識することなく業務プログラムの作成ができ
るようにし、生産性の向上とシステムの変更に対するメ
ンテナンスの効率を向上し、且つ、このような従来の欠
点を解消し、業務プログラムの変型なしに、動作システ
ムを変更できるようにすることを目的とするものである
。

〔課題を解決するための手段〕

第１図は、本発明の原理図であり、３−１．３−２は業
務プログラム、４−１．４−２は資源、５．７は仮想資
源変換テーブル、６．８は実資源変換テーブルを示す。

〔作用〕

業務プログラム３−１が、アクセスする資源としては、
ローカＪしく自システム上）とリモート（他システム上
）に多数あり、例えば、ファイル。

端末、設備機器、データベース、他の業務プログラムな
どである。

これらの資源４−１．４−２は全て、仮想ファイルとし
て抽象化する。業務プログラム３−１゜３−２は仮想フ
ァイルに対してアクセスするように作成するればよい、
資源４−１．４−２の種類と位置については、仮想ファ
イル定義として、業務プログラムとは切り離して個別に
記述する。

前記、仮想ファイル定義としては、仮想ファイル変換テ
ーブル５．７を設け、この仮想ファイル変換テーブル５
，７と、実資源変換テーブル６゜８により、業務プログ
ラム３−１．３−２のアクセスする仮想ファイル名は実
資源に変換され、資源４−１．４−２をアクセス可能と
する。

〔実施例〕

以下、本発明の実施例を図面に基づいて説明する。

尚、全図を通じ同一部分には同一符号を付す。

第２図は、本発明の１実施例のブロック図であり、２１
．２２はシステム、２３は業務ブロイグラム、２４は実
資源、２５．２８は（仮想ファイルインタフェース部（
ＶＦＩ）、２６はクライアントドライバ、２７はサーバ
ドライバである。

第３図（ａ）、　（６）は仮想ファイル変換テーブルを
示す。

システム２上の業務プログラム２３から、システム２２
上の実資源２４をアクセスする場合、システム２１例の
仮想ファイル変換テーブル２９−１で、システム名に変
換され、該当システム２２上の仮想ファイル変換テーブ
ル２９−２で、実費源２４への変換が行われる。

第４図に第２図に示すシステム２１上の業務プログラム
２３が、システム２２上の実資源２４ヘリモートアクセ
スるす場合のフロー図を示す。

実資源２４　／　ｉａｄａｔ　／ｒｆｉｌｅ　」にｒＲ
ＦＩＬＥ。

という仮想ファイル名を付けるものとする。この場合、
システム２２の仮想ファイル変換テーブル２９−２には
仮想ファイル名と実資源の対応ｒＲＦＩＬＥ　　ニー般
ファイル＊　／ｉａｄａｔ　／ｒｆｉｌｅ　」が定義さ
れ、システフ、２１の仮想ファイル変換テーブル２９−
１には、仮想ファイル名と、その存在するシステム名の
対応ｒＲＦＩＬＥ　：リモー）　＊　ｓｙｓｔｅｍ２」
が定義される。業務プログラム２３が仮想ファイルｒＲ
ＦＩＬＥＪにアクセスるすと、まずＦＶＩ２５は、変換
テーブル２９−１にｒＲＦＩＬＪを捜し、リモート資源
であり、実資源はシステム２２に存在することを知る。

次にＶＦＩ２５はシステム２２に接続するクライアント
ドライバ２６に対して、アクセス依頼を行う。クライア
ントドライバ２６は、システム２２のサーバドライバ２
７にアクセス依頼する。システム２のサーバドライバ２
７はアクセス依頼に従ってｒＲＦＩＬＥＪをアクセスす
る。

これにより、ＶＦＩ２Ｂは、仮想ファイル変換テーブル
２９−２にｒ　ＲＦ　Ｉ　ＬＥ　Ｊを捜し、実資源「／
ｉａｄａｔ　／ｒｆｉｌｅ　Ｊを知り、アクセスし、結
果をシステムｌへ通知され、システム２１の業務プログ
ラム２３へと結果が渡って行く。

また、仮想ファイル変換テーブルを利用した他の実施を
第５図乃至第１１図に示す。

第５図に、資源定義の自動更新の例を示す。

システムＢ５２上のａｆｉ１５２２をシステムＣ５３上
に移動する場合、システムＢ５２上の変換テーブル５１
１は、ローカルの定義から、リモートの定義へ変更し、
移動先のシステム５３上の変換テーブル５３には、ロー
カルの定義を行う、このとき、ａｆｉｌｅ　５２２の仮
想ファイル名ｒＡＢＣ，にて、リモートアクセスに来る
他のシステム上の変換テーブルもシステムＢ５２からシ
ステムＣ５３べ変更する必要があるが、この変更は、移
動後の業務プログラムからの最初のアクセス時に行う。

第５図において移動前は、■の経路により、アクセスが
行われる。移動後の最初のアクセス時は、■の経路によ
り、移動前のシステムＢ５２を経由して、アクセスされ
るが、この時システムＢ５２よりアクセス元のシステム
Ａ５１の変換テーブル５１２に対して、更新がかけられ
、以降は、■の経路により、直接システムＣ５３ヘアク
セスが行われる。

第６図に経路■での定義自動更新のフローを示す。

資源の配置の変更に対しては、移動元では移動先へのリ
モートファイルの定義に変更し、移動先で実資源への対
応を定義する。業務プログラムからのアクセスは、まず
移動元へアクセス依頼がなされ、そこより移動先へ移す
ことになる。この時移動元よりアクセス元の変換テーブ
ルの変更を行う、以後、業務プログラムからのアクセス
は直接移動先へ依頼されることになる。このように対象
資源へのアクセス時に定義を変更することにより、シス
テムのメンテナンスが容易になる。

第７図は他の実施例を示す図である。

７３は業務プログラム、７４は仮想ファイルインタフェ
ース、７５．７６は資源、７７に仮想ファイルと資源を
結合する定義を示す。

業務プログラム７３がアクセスする資源７５は、ローカ
ル資源であり、資源７６は他システム（システム２）に
あるリモート資源である。この資源７５の位置は仮想フ
ァイルの定義として、業務プログラム７３とは、別に記
述され、インタフェースの違いは、仮想ファイルインタ
フェースが吸収し、業務プログラム３からは、ローカル
資源もリモート資源も同様にアクセスする。

このシステムにおいて、システム３を追加し、業務プロ
グラム７３を移す場合、仮想ファイルインタフェースが
参照する仮想ファイルの定義フッを変更し、資源７５も
リモート資源として定義し直すだけで業務プログラム７
３の変更は必要ない。

第８図乃至第１１図により他の実施例の説明を行う。

第８図はシステム構成図、第９図は仮想ファイル定義、
第１０図は業務−プログラムを移動したシステム構成図
、第１１図は仮想ファイル定義である。

８１．８２，１１３はシステム、図において、８３は業
務プログラム、８５，８６．１１２はネットワーク制御
プログラム、８４．８７．１１１は仮想ファイルインタ
フェース、ｓｏ−ｔ、ｓ。

−２，８０−３は仮想ファイル定義、８８．８９は実資
源を示す。

第８図では、システムｌ上の業務プログラム８３が実資
源８８．８９をアクセスするが、実費源８は自システム
上にあるローカル資源、実資源８９は、システム２にあ
るリモート資源である。ここで、システムｌ上の仮想フ
ァイル定義８０−１には第９図（ａ）に示すように実資
源８にｒａｆｉｌｅ　Ｊという仮想ファイル名が付けら
れ、ローカル資源であることが定義される。また、実費
源８９には、ｒｂｆｉｌｅ　Ｊという仮想ファイル名が
付けられ、システム２上にあるリモート資源であると定
義される。業務プログラム８３はこのｒａｆｉｌｅ」ｒ
ｂｆｉｌｅ」の仮想ファイル名で実資源をアクセスする
ように作成する。

この業務プログラム８３を、システム３上に移す場合、
第１０図のように、仮想ファイル定義８〇−３を作成す
れば、プログラム変更は必要ない。

仮想ファイル定義８０−３には、第１１図に示すように
ｒａｆｉｌｅ」は、システムｌ上にあるリモート資源、
ｒｂｆｉｌｅ」はシステム２上にあるリモート資源であ
ると定義される。

以上の実施例では、システム資源としてファイルを考え
、各システム中の仮想ファイル名とその実ファイル名と
を定義した実ファイル変更テーブルを全て仮想変換テー
ブル中に組み込んだが、本発明はファイル以外の資源を
含むと共に、実資源変換テーブルのほかに、仮想変換テ
ーブルを独立に設けてもよい。

４、発明の効果本発明によれば、次のような効果がある。

（１）　　実資源の存在位置を意識することなく、業務
プログラムを作成できるため、生産性が向上する。

（２）　　仮想ファイルとして扱える資源は、ファイル
に限らず、端末、設備機器、データベース、他プロセス
との通信等を全て同一インタフェースでアクセスするこ
とができるため、生産性が向上する。

（３）　　仮想ファイルの定義が業務プログラムと切り
離されているため、システムの変更（資源の存在位置の
変更）に対して、業務プログラムの修正が必要なく、定
義の変更のみで済む。

（４）資源の存在位置の変更時の定義の変更が、元の存
在システムと移動先システムのみで済むため、容易であ
る。

（５）集中システム環境で、十分にテストを行い分散シ
ステムへ移行することができるため、業務プログラムの
作成作業が容易となり、品質が向上する。

（６）業務量の増大に伴う負荷の増大に対して、処理シ
ステムを追加して対処する場合、業務プロダラムの移植
が非常に容易に行える。プログラムの変更は必要ない。

（７）集中システムにて動作している業務プログ　−ラ
ムも、容易に分散システム環境に移行できる。

この際、プログラム上の変更は必要ない。

【図面の簡単な説明】

第１図は本発明の原理図、第２図は実施例のブロック図、第３図（ａ）、（ロ）は仮想ファイル変換テーブルを示
す図、第４図はリモートアクセスフロー、第５図は資源定義の自動更新を示す図、第一６図は資源
定義の自動変更フロー、第７図は他の実施例を示す図、第８図はシステム構成図、第９図は仮想ファイル定義、第１０図は業務プログラムを移動したシステム構成図、第１１図は仮想ファイル定義、ｍ１２図はネットワークファイルシステム図である。１．２はシステム、３−１．３−２は業務プログラム、
４−１．４−２は実資源、５．７は仮想変換テーブル、
６．８は実資源変換テーブルである。＼ｌ；１１　　　１　　　１−はー１１１−．　　　Ｉ＋　　　　Ｉ１ス　　ｌ　　　　　　　　　　１１　↑　！ｌ！ば。ｌ　　　　　　　　１１音　１ｋ　　　　　ｈ（ｖ

Claims

【特許請求の範囲】１）複数のシステムがネットワークを構成すると共に、
各システム内に仮想資源名と実資源名との対応を定めた
実資源変換テーブル（６）を有する分散処理システムに
おいて、他システム（２）中に存在する資源の仮想資源
名と、その資源の存在するシステム名との対応を定めた
仮想資源変換テーブル（５）を各システム中に設け、上
記仮想資源変換テーブル（５）と上記実資源変換テーブ
ル（６）により他システム（２）中の実資源（４−２）
の実資源名を求めることを特徴とするリモート資源定義
方式。２）各システム中の前記実資源変換テーブルを前記仮想
資源変換テーブル（５）内に組み込んだことを特徴とす
る特許請求の範囲第一項記載のリモート資源定義方式。３）第１のシステム（１）中の資源が第２のシステム（
２）に移行した時、この移行資源に関する項目を第１の
システム（１）の前記実資源変換テーブル（６）から、
前記仮想変換テーブル（５）に移し、第２のシステムの
前記仮想資源変換テーブルから、前記実資源変換テーブ
ルに移すことを特徴とする特許請求の範囲第一項記載の
リモート資源定義方式。４）第１のシステム（１）中の資源が第２のシステム（
２）に移行した時、各第１、第２のシステム（１、２）
におけるこの移行資源に関する前記仮想変換テーブル（
５）では実資源名をシステム名に、システム名を実資源
に各々変更したことを特徴とする特許請求の範囲第２項
記載のリモート資源定義方式。５）他システムの前記仮想変換テーブル中の移行資源の
移行前システム名が移行後、最初のアクセスを契機とし
て移行後のシステム名に変更されることを特徴とする特
許請求の範囲第３項または、第４項記載のリモート資源
定義方式。