(57)【特許請求の範囲】
【請求項１】
それぞれサービスを提供する複数の計算機が接続されたネットワークを利用した各種サービスへのアクセス方式において，
前記ネットワークに接続されると共に端末装置からの前記計算機のサービスへのアクセスを全て受けつける中継エージェントを設け，
前記中継エージェントは，サービス名とサービスが提供される計算機名とそのアクセス方法が登録されたアクセス方法データベースと，サービスを提供するプログラムが登録されたサービスデータベースとを備え，
端末装置または他中継エージェントからのサービスを指定したアクセス要求に対し，前記アクセス方法データベースを検索して，指定されたサービスが利用可能な状態であると登録されたアクセス方法を元にサービスを提供する計算機との接続を確立し，
指定されたサービスが利用可能な状態でないことを検出すると，前記中継エージェントは，前記サービスデータベースを検索し, 要求されたサービスを提供するプログラムがネットワーク上の他の計算機に存在することを検出すると，前記他の計算機から前記プログラムの複製を受け取ってサービス名とプログラムとが登録されるインポートデータベースと，
他の計算機にサービスを提供するプログラムの複製を渡した時に，他の計算機名とサービス名を登録するエクスポートデータベースとを設け，
他の計算機からプログラムの複製を受け取った中継エージェントは，前記インポートデータベースに登録されたプログラムを起動することにより要求されたサービスを提供することを特徴とするネットワークを利用した各種サービスへのアクセス方式。
【請求項２】
請求項１において，
前記中継エージェントは，サービス名を指定したサービスの更新要求に対し，サービスデータベースに登録された該当サービスのデータを検索して，該当サービスがあるとこれを削除して，更新後のデータを登録すると共に，前記エクスポートデータベースに前記サービス名が登録されているかを検索し，
該当サービス名があると登録された他の計算機のインポートデータベースの該当サービスを削除して更新後のデータを登録することを特徴とするネットワークを利用した各種サービスへのアクセス方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はネットワークを利用した各種サービスへのアクセス方式に関し，全世界に広がるような広域ネットワークによって複数の計算ノードが繋がっていて，各計算ノード上で様々なサービスが提供される環境における各種サービスへのアクセス方式に関する。
【０００２】
近年，計算機の技術の発展に伴い，ネットワークで接続された複数の計算機上で様々なサービスが提供されるようになって来ている。例えば，ネットワーク上でスケジュールを管理するシステム等は，スケジュール管理のサービスを提供していると考えることができる。このようにネットワークで計算機が接続され，それらの計算機上で種々のサービスが提供された環境において，サービスに対する簡単なアクセスや，必要に応じたサービスの起動，終了，更新等ができることが望まれている。
【０００３】
本発明が対象とする環境は，ネットワークによって複数の計算ノードが相互接続されているような環境である。このようなネットワークには，従来，インターネットのような全世界に広がるコンピュータ・ネットワークやＬＡＮ（Local Area Network) のような小規模なネットワーク等がある。この場合の計算ノードとしては，ワークステーション，パーソナル・コンピュータ，携帯端末等のアプリケーションを実行する計算主体を表し，以下，これらを総称して計算機と呼ぶ。
【０００４】
【従来の技術】
通常ネットワーク上のサービスがそれぞれ独自のアクセス手順（プロトコル）を持つ場合には，それぞれのサービスに対応して決まった手順に従わなければならない。
【０００５】
他方，各サービスがある程度統一的な手順を決め，その手順に従えば多くのサービスを利用可能にする方法がある。その例として，インターネットのＷＷＷ（World Wide Web) のブラウザ等の場合，ＵＲＬ（Uniform Resource Locator) と呼ばれるアドレスを用いる方法でサービスを指定してアクセスすることが可能である。指定されたサービス側では，ＨＴＴＰ（Hyper Text Transfer Protocol) と呼ばれるプロトコルに従うことによって利用者に対してサービスを提供することが可能である。
【０００６】
【発明が解決しようとする課題】
上記の従来の技術を用いてサービスを提供する計算機にアクセスする場合，次の▲１▼，▲２▼のような問題がある。
【０００７】
▲１▼サービスに対するアクセスの問題
サービスを提供する計算機側が，上記のＨＴＴＰのプロトコルに従ってサービスを提供していない場合には，この方法ではサービスを受けることが不可能である。また，たとえ，そのプロトコルでサービスを提供している場合でも，ＵＲＬで指定された側が何らかの理由によりそのサービスを提供可能でない状態（サービスを提供するプログラムが起動されてない，サービスを提供するプログラムを起動している計算機にアクセスできない等）の時には，サービスを受けることが不可能である。そのような場合でも，利用者がアクセス可能な計算機のキャッシュメモリにサービスを提供する計算機から取り出したプログラム等が保持されている時には，当該他の計算機からサービスを提供することが可能であるが，キャッシュメモリにない情報にアクセスする場合や，情報が利用者との相互動作により動的に生成される場合等はキャッシュメモリを用いることが不可能である。
【０００８】
▲２▼必要に応じたサービスの起動，終了，更新の問題
従来の方法ではサービスを提供する側がそのサービスを提供可能な状態でない場合は，そのサービスを提供するプログラム等を起動しない限りそのサービスにアクセスすることは困難である。しかし，例えば，そのサービスがどのような計算機でどのようなプログラムによって起動されているのか等の情報が無い状況では，そのサービスを提供するプログラムを起動することは不可能である。同様に，サービスを終了させるために起動されているプログラムを終了させたり，サービスの内容を更新するために起動されているプログラムを更新することも不可能である。
【０００９】
本発明は，ネットワークで繋がった複数の計算機上で様々なサービスが提供される環境において，必要なサービスに対して簡単にアクセスすることができ，必要に応じたサービスの起動，終了及びサービス内容の更新を行うことができるネットワークを利用した各種サービスへのアクセス方式を提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明はネットワークで接続された複数の計算機上で提供される種々のサービスに対してアクセスする方法を管理するためのサーバとして機能する機構（中継エージェントと呼ぶ）を用い，その中継エージェントを経由してサービスにアクセスすることを原理とする。
【００１１】
図１は本発明の原理構成を示す図である。図中，１は利用者の端末装置（ワークステーション，パーソナル・コンピュータ，携帯端末等），１ａは端末装置１上で動作し中継エージェント２との間のインタフェースとして機能するＧＵＩ（グラフィカル・ユーザ・インタフェース，例えばＷＷＷブラウザ），２は利用者の端末装置１や，他の計算機（ホスト）とネットワークにより接続された中継エージェント，２０は中継エージェントの制御部，２１は各サービスに対応するアクセス方法が登録されたアクセス方法データベース（ＤＢで表す，以下同じ），２２はサービスを提供するプログラムが登録されたサービスデータベース（ＤＢ），２３は利用者の要求によって現在起動しているサービスを提供するプログラムが登録された現状データベース（ＤＢ），２４はサービスデータベース２２に登録されている情報を元に他の計算機上に起動すべきプログラムがあることが分かった場合に，他の計算機からコピーしてきた起動すべきプログラムが登録されたインポートデータベース（ＤＢ），２５は他の計算機に起動するプログラムのコピーを渡したことを登録したエクスポートデータベース（ＤＢ），３はネットワーク，４はネットワーク上の複数の計算機で提供される各種のサービスである。
【００１２】
利用者がネットワーク３上の各種サービス４の一つにアクセスする場合，サービスアクセスに関する要求は全て中継エージェント２に送られる，中継エージェント２は制御部２０の制御によりサービス名をキーとしてアクセス方法ＤＢ２１を検索し，登録されているアクセス方法を元に適切な接続を確立する。また，中継エージェント２はサービスを提供するプログラム自体をサービスＤＢ２２を用いて管理しており，例えばスケジュール管理のサービスを提供するプログラムをサービスＤＢ２２に登録しておけば，既にスケジュール管理サービスが利用可能な場合にはそのサービスを利用し，そうでない場合にはサービスＤＢ２２に登録されているプログラムを新たに起動する。但し，サービスＤＢ２２が管理する対象は，プログラムとは限らず，モジュールのようなものでもよい。現状ＤＢ２３には，現在利用者の要求によって起動したサービスを提供するプログラムが登録されている。
【００１３】
インポートＤＢ２４はサービスＤＢ２２に登録されている情報を元に他の計算機上に起動すべきプログラムがあることが分かった場合に，他の計算機からプログラムのコピーをしてきた起動すべきプログラムが登録されている。エクスポートＤＢ２５は他の計算機に対して起動するプログラムのコピーを渡したことを登録してある。これらの，インポートＤＢ２４，エクスポートＤＢ２５は，プログラムが更新された時に，更新元の計算機からコピーされた他の計算機の該当プログラムの内容も更新する場合に有効となる。
【００１４】
中継エージェント２は，ネットワーク３を介して端末装置１や他の計算機（各種サービス４を提供する各計算機）や，他の中継エージェントとの間の通信処理手段により接続が行われ，データ伝送を行うことができる。そして，利用者の端末装置１または他の中継エージェント２からの各種要求に対する処理を行い，ローカルに端末装置１の利用者にサービスを提供したり，他の計算機（ホスト）によりサービスを提供する場合の中継を行う。中継エージェント２の主要な機能を挙げると，次の通りである。
【００１５】
(1) アクセス方法に関する要求
サービスへアクセスする方法に関する要求であり，アクセス方法ＤＢ２１に対してアクセス方法の登録要求，削除要求，検索要求を実行する。
【００１６】
(2) サービスへのアクセス要求
サービスへアクセスするための接続を確立する要求であり，既にサービスが利用可能な状態の時には，そのサービスへの接続を確立し，確立したらアクセス方法ＤＢ２１を元に，プロトコルの変換を行う等によりサービスへアクセスする。
【００１７】
サービスが利用可能な状態でない時は，サービスＤＢ２２にサービスを提供するプログラムが登録されているか調べて，ある時はそのプログラムを起動しサービスへの接続を確立する。起動するプログラムが，他の計算機に登録されている場合，プログラムのコピーを他の計算機から受け取って，インポートＤＢ２４に登録して，起動する。プログラムを渡した計算機では，渡したことを覚えておくためそのエクスポートＤＢ２５にどの計算機に渡したかを登録する。
【００１８】
(3) サービスの登録要求，削除要求，更新要求，検索要求
各要求に含まれるサービスを提供するプログラムの登録，削除，更新及び検索を行う。サービスの登録は，サービスＤＢ２２に対して行われ，サービスの削除はサービスＤＢ２２だけでなく，関係する現状ＤＢ２３，インポートＤＢ２４，エクスポートＤＢ２５の各データベースについても実行される。サービスの更新は，サービスＤＢ２２や現状ＤＢ２３に対して行われる。
【００１９】
このような構成を備える本発明により，サービスに対するアクセスは，中継エージェント２に対して利用したいサービスへのアクセス要求を送ると，適切なアクセス方法で接続を確立することができる。また，中継エージェント２がプロトコル変換を行うため，変換する方法が登録されている如何なるプロトコルを用いたサービスに対してでも，適切なアクセス方法で接続を確立することができる。
【００２０】
また，中継エージェント２に対して利用したい新しいサービスの登録要求を送り，次にそのサービスへのアクセス方法の登録要求を送り，最後にそのサービスへのアクセス要求を送ることにより，適切なアクセス方法で接続を確立することができる。また，中継エージェントは他の計算機上にサービスを提供するプログラムをコピーさせて起動させたり（エクスポートＤＢ２５に登録），他の計算機上からサービスを提供するプログラムをコピーしてきてそれを起動する（インポートＤＢ２４に登録してキャッシュの形式で使用する）ことができる。このように必要に応じて必要なサービスを起動することが可能となる。更に，サービスの削除，更新や，各データベースの登録，更新，削除についても適切な要求を中継エージェント２に送ることにより行うことができる。
【００２１】
【発明の実施の形態】
上記図１に示す中継エージェント２は，制御部２０を構成するＣＰＵ，メモリを備えると共に各データベース２１〜２５を構成するデータを格納する記憶装置（磁気ディスク装置等）を備え，制御部２０は端末装置１の利用者からの要求または他の中継エージェント２からの各種の要求に応じて対応する制御処理を繰り返し実行する。
【００２２】
最初に，利用者端末または他の中継エージェントからの各種要求の処理において用いられる各データベース（ＤＢ）のデータ構造を説明する。
図２はアクセス方法ＤＢ（図１の２１）のデータ構造である。このデータは，先頭にサービス名，次にサービスを提供するサービスホスト，最後にサービスへのアクセス方法の３つのデータで構成され，アクセス方法の例としては，ＨＴＴＰ，ＡＧＥＮＴ（エージェント用のプロトコル）等のプロトコルがある。図２の下側にアクセス方法ＤＢのデータの例として，（スケジュール管理，bishop,HTTP)とその意味を示す。
【００２３】
図３はサービスＤＢ（図１の２２）及びインポートＤＢ（図１の２４）のデータ構造である。これらのＤＢ２２，２４のデータは，サービス名，プログラム（サービスを提供するプログラム），プログラムタイプの３つのデータで構成される。プログラムタイプの例としては図３に示すように，Ｃ（Ｃ言語），ＡＧＥＮＴ（モーバイルコード：完全なプログラムになってないモジュールで，実行形式であれば良い），ＲＥＭＯＴＥ（リモートホスト上のプログラム）等がある。これらのＤＢのデータの例が図３の下側に例１，例２として示す。
【００２４】
図４は現状ＤＢ（図１の２３）及びエクスポートＤＢ（図１の２５）のデータ構造である。これらのＤＢ２３，２５のデータは，サービス名とサービスホストの２つで構成され，データの具体例を図４の下側に示す。
【００２５】
上記図２乃至図４に示すデータ構造を備える各データベースを用いて，各中継エージェントにおいて各種要求の処理が行われる。各種の処理内容をそれぞれ処理フローの図として示して説明する。
【００２６】
サービス方法の登録，削除，更新，検索の各処理フローは図５乃至図８に示す。
アクセス方法の登録要求が発生すると，図５に示すアクセス方法の登録要求の処理フローが動作する。入力として“サービス名，サービスを提供するホスト名，アクセス方法”のそれぞれが指定される。これに応じてアクセス方法ＤＢ２１中に入力されたデータが存在するか判別する（図５のＳ１）。存在する場合は登録失敗となるが，存在しない場合は，これらの入力されたデータがアクセス方法データ２１に登録が行われると共にその登録が成功したか判別し（同Ｓ２），登録成功または，登録失敗の結果が出力される。
【００２７】
アクセス方法の削除要求が発生すると，図６に示すアクセス方法削除要求の処理フローが動作する。この場合も，入力として上記アクセス方法の登録要求の場合（図５）と同様に，“サービス名，サービスを提供するホスト名，アクセス方法”のそれぞれが指定される。これに応じてアクセス方法ＤＢ２１中に入力されたデータが存在するか判別する（図６のＳ１）。存在しない場合はデータが無いことを出力する。存在する場合は，該当するデータの削除を行うと共にその削除が成功したか否かを判別し（図６のＳ２），結果に応じて削除成功または削除失敗を出力する。
【００２８】
アクセス方法の更新要求が発生すると，図７に示すアクセス方法の更新要求の処理フローが動作する。この要求には，入力として“サービス名，元のホスト名，元のアクセス方法，更新後のホスト名，更新後のアクセス方法”が指定され，図７の例では“service, host1, access1,host2, access2) が入力されている。この要求に応じて，『service, host1, access1 』をアクセス方法ＤＢ２１から削除して，その削除が成功したか判別する（図７のＳ１）。これに失敗するとその出力を行い，削除が成功すると更新後のホスト名と更新後のアクセス方法をアクセス方法ＤＢ２１に登録して，その処理が成功したか判別する（図７のＳ２）。成功すると更新成功を出力し，成功しないと更新失敗を出力する。
【００２９】
アクセス方法の検索要求が発生すると，図８に示すアクセス方法の検索要求の処理フローが動作する。この要求には，入力として“サービス名，ホスト名，アクセス方法”のそれぞれが指定される。この要求に応じて，入力されたデータが存在するか判別し，存在する場合は該当データを出力し，存在しないとデータが無いことを表す出力を発生する。
【００３０】
サービスへのアクセス要求
サービスへのアクセス要求には，ホスト上でサービスが利用できないとアクセス失敗として終了する要求（アクセス要求１）と，ホスト上でサービスが利用できなくてもインポートＤＢやエクスポートＤＢを検索してアクセスを試みる要求（アクセス要求２）とがある。それぞれの処理フローについて説明する。
【００３１】
サービスへのアクセス要求１の処理フローを図９に示す。
このアクセス要求には，入力として，“サービス名，サービスホスト名，アクセス方法”が指定され，これに対し，アクセス方法データ２１中に該当するデータが存在するか判別する（図９のＳ１）。データが存在しないとアクセス失敗となって終了するが，存在する場合はホスト上で指定されたサービス名のサービスが既に利用できる（起動している）かを判別する（図９のＳ２）。利用できない場合は，アクセス失敗となるが，利用できる場合は，ホスト上の当該サービスへの接続確立を行い，確立が成功したか判別し（図９のＳ３），確立に成功するとアクセス成功を出力し，確立に失敗するとアクセス失敗を出力する。
【００３２】
サービスへの接続を確立した後は，中継エージェント２はアクセス方法ＤＢ２１に登録されているアクセス方法を元に，図１に示す端末装置１のＧＵＩ１ａとサービスとの間でプロトコルの変換を行う。基本的なプロトコル変換は，表を用いたコマンドの書き換えによって可能である。このようなリストを用いて，サービス側（サービスを提供する計算機）が指定しているプロトコルをＧＵＩ１ａ側で指定しているプロトコルに変換する。
【００３３】
図１０はプロトコル変換表の例を示す。この例では，サービス側が，「Display 」というコマンドを送ってきた場合には, 中継エージェントが「画面上に表示を行うコマンド」に変換して，端末装置１のＧＵＩ１ａ側に送る。逆にＧＵＩ１ａ側が，「他のプロセスにメッセージを送るコマンド」を送って来たら，中継エージェント２が「Send」コマンドに変換して送る。このようにすれば，プロトコルの数だけ同様の表を作ることによりプロトコル変換が可能である。
【００３４】
サービスへのアクセス要求２の処理フロー（その１）〜（その４）を図１１〜図１４に示す。
図１１に示すようにサービスへのアクセス要求２の処理では，上記図９に示すアクセス要求１の処理フローと同様の入力が指定され，同様のステップＳ１〜Ｓ３の処理が行われるが，Ｓ２においてホスト上で指定されたサービス名のサービスが既に利用できるか判別して，サービスが利用できないと判別された場合にステップＳ４に移行する点で相違する。ステップＳ４では，ホストが‘ローカル’かどうかを判別する（サービスが中継エージェントと同じ計算機上で提供されているかどうかをチェックする）。ここで，ローカルであると判別された場合は▲１▼の経路で図１３の処理へ移行し，ローカルでない場合は▲２▼の経路で図１４の処理に移行する。
【００３５】
ローカルの場合，図１３において，サービスＤＢ２２中に，指定されたサービス名（service)にマッチするデータ(service,code,type) が存在するか判別する（図１３のＳ１）。なお，この場合のデータの「service 」はサービス名，「code」はプログラム名, 「type」はプログラムタイプ（リモート，モジュール等）を表す。データが存在しないとアクセス失敗となり，存在する場合にはデータのtypeがREMOTE（リモート：他のホストが提供するプログラム）か判別する（図１３のＳ２）。リモートでない場合には，▲３▼の経路で示す処理（後述する図１２）に移行するが，リモートの場合は，インポートＤＢ２４内に指定されたサービス名（service)で指定されたデータ(service,code',type') が存在するか判別する（図１３のＳ３）。なお, この場合のcode',type’は上記図１３のステップＳ１のcode,type と異なるプログラム, タイプを表す。
【００３６】
存在する場合は，ステップＳ７に移行してサービス(service) としてプログラム(code)を起動して成功したか判別する。存在しない場合は，ホストcode（ステップＳ１で検索されたデータの中にあるcodeを計算機名として指定している）上のサービスＤＢ２２中に，指定されたサービス名（service)のプログラムのデータ(service,code',type') が存在するか判別する（図１３のＳ４）。存在しない場合はアクセス失敗となるが，存在する場合は，当該他の計算機から中継エージェント２のインポートＤＢ２４にこのデータのコピーを登録し，登録が成功したか判別する（図１３のＳ５）。登録が成功しないと，アクセス失敗となるが，成功すると，ホストcode上のエクスポートＤＢ２５に，このサービス名とホスト名(service,host)の登録を行い，登録が成功したか判別する（図１３のＳ６）。登録が成功しない場合は，アクセス失敗となるが，成功した場合は，そのサービス（サービス名code')を起動し, 起動が成功したか判別する（図１３のＳ７）。起動しない場合はアクセス失敗となるが，成功するとサービスへの接続を行って，接続が成功したか判別する（図１３のＳ８）。接続が成功するとアクセスが成功し，そのサービスの提供を受けることが可能となる。
【００３７】
上記図１３のステップＳ２でプログラムのタイプが‘リモート’でないと判別された場合，▲３▼の経路で図１２の処理に移行する。この場合，サービスとして指定された「code」を起動して，起動が成功したか判別し（図１２のＳ１），成功した場合はサービスへの接続を行って接続が成功したか判別する（図１２のＳ２）。成功した場合はアクセス成功となるが，Ｓ１，Ｓ２で成功しない場合はアクセス失敗が出力される。
【００３８】
上記図１１のステップＳ４の判別で，▲２▼へ移行した場合（hostがローカルでない場合) ，図１４の処理が実行される。最初にサービスＤＢ２２を検索し，その中に指定されたサービス名（service)のデータ（service,code,type)が存在するか判別し（図１４のＳ１），無い場合にはアクセス失敗となるが，存在する場合はそのタイプが‘リモート’であるか判別する（同Ｓ２）。リモートであればアクセス失敗であるが，リモートでない時は，他のホスト（host) 上のインポートＤＢ中にこのプログラムのデータ（service,code,type)のコピーの登録を行い，登録が成功したか判別する（図１４のＳ３）。成功しない場合はアクセス失敗となるが，登録が成功すると，中継エージェント２のエクスポートＤＢ２５に（サービス名service,ホスト名host) の登録を行い，登録が成功したか判別する（図１４のＳ４）。成功した場合はホストhost上にサービスservice としてプログラムcodeを起動し，起動が成功したか判別する（図１４のＳ５）。起動が成功した場合，サービスservice への接続を行って接続が成功したか判別し（同Ｓ６），成功するとアクセス成功の出力を発生する。上記Ｓ４，Ｓ５及びＳ６において成功しない場合は，アクセス失敗となる。
【００３９】
プログラムの起動
サービスを提供するプログラムの起動は，サービスＤＢ２２に登録されているプログラムとプログラムタイプを元に行う。例えば，プログラムタイプがＣの場合，登録されているプログラムはＣで記述されたプログラムであることを意味する。従って，このようなプログラムを他の計算機上で起動するためには，Ｃコンパイラを用いてそのプログラムをコンパイルして実行可能形式にし，それから起動する。また，エージェント技術の枠組で良く用いられるモーバイルコードのような形式の場合には，プログラムタイプがＡＧＥＮＴ等となっていて，プログラムとしてコードが登録されていることを意味する。このような場合，そのコードを理解するためのインタプリタを起動し，そのインタプリタにコードを渡すことにより起動する。起動するプログラムが他の計算機上に登録されている場合もある。この場合，プログラムタイプがリモート（REMOTE) となっていて，プログラムとして起動すべきプログラムが登録されているホスト名が指定されている。他の計算機上に登録されているプログラムを起動する場合には，起動すべきプログラムのコピーを他の計算機から貰い，インポートＤＢ２４に登録すると同時にそのプログラムを起動する。インポートＤＢ２４は，他の計算機に登録されているプログラムのキャッシュとして機能する。プログラムのコピーを渡した計算機では，渡したことを覚えておくためにエクスポートＤＢ２５にどのサービスをどの計算機に渡したかを登録する。この情報は，インポートＤＢ２４にキャッシュしている計算機に更新情報を知らせるため等に用いる。
【００４０】
図１５はプログラム起動の処理フローである。入力としてサービス名（service)，プログラム(code), プログラムのタイプ(type)が与えられて開始すると, タイプが‘リモート’(REMOTE)か判別する（図１５のＳ１）。リモートでない場合は，タイプを元に起動方法を調べ（同Ｓ２），起動方法が判明したかの判別をする（同Ｓ３）。判明しないと起動失敗となるが，判明するとその起動方法を元にプログラム(code)を起動し，起動に成功したか判別し（同Ｓ４），成功しない場合は起動失敗となり，成功すると現状ＤＢ２３に起動したサービス名，ホスト名を登録し，登録に成功したか判別する（同Ｓ５）。登録に成功すると起動成功となるが，登録に失敗すると起動失敗となる。
【００４１】
上記図１５のステップＳ１において，プログラムのタイプがリモートであると判別されると，インポートＤＢ２４に指定されたサービス名のプログラム（データservice,code',type')が存在するか判別する（図１５のＳ６）。存在しないと起動失敗となるが，存在するとタイプ＝type' を元に起動方法を調べ（同Ｓ７），起動方法が判明したか判別する（同Ｓ８）。判明した場合にはその判明した起動方法を元にプログラム(code') を起動し, 起動に成功したか判別する（図１５のＳ９）。成功しない場合は起動失敗となるが，成功すると次に現状ＤＢ２３に，起動したサービス名，ホスト名を登録し，登録が成功したか判別し（同Ｓ１０），成功の場合は起動成功となり，そうでないと起動失敗となる。
【００４２】
上記図１５のステップＳ２及びＳ７において起動方法を調べる場合，図１６の起動方法テーブルの構成例に示すようなテーブルを用いる。すなわち，プログラムタイプを元に起動方法テーブルを調べ，そこに登録されている起動手順に沿ってプログラムを起動すれば良い。
【００４３】
サービスの登録要求
新しいサービスを提供するプログラムを登録する場合，図１７に示すサービスの登録要求の処理フローにより行う。この場合，入力としてサービス名(service) ，そのサービスを提供するプログラムコード(code)，そのプログラムコードのタイプ(type)とを供給すると，サービスＤＢ２２中にそのデータが存在しないことが判別されると，そのデータをサービスＤＢ２２に登録する処理が行われる。
【００４４】
サービスの削除要求
サービスの削除要求に対しては，サービスを提供するプログラム（データ）を削除する処理が行われ，図１８にサービスの削除要求１の処理フロー，図１９，図２０にサービスの削除要求２の処理フロー（その１），（その２）を示す。なお，削除要求２の処理では，他の利用者が既にアクセスしているサービスの削除も行われる。
【００４５】
図１８のサービスの削除要求１の処理フローでは，入力として削除を要求するサービスを特定するための，サービス名，プログラム，プログラムのタイプを表す（service,code,type)が供給され，開始するとサービスＤＢ２２中に入力されたサービス名，プログラム及びプログラムタイプのデータが存在するか検索する（図１８のＳ１）。存在しないとデータ無しとなるが，存在すると該当するデータをサービスＤＢ２２から削除を行い，削除に成功したか判別する（同Ｓ２）。削除できないと削除失敗となるが，成功すると，プログラムのタイプが‘リモート’(REMOTE)か判別する（同Ｓ３）。リモートでない場合は，エクスポートＤＢに上記入力されたプログラムのデータが存在するか判別する（図１８のＳ４）。これは，当該プログラムが他の計算機にコピーされているか調べるもので，存在しないと削除成功となり，存在する場合は，該当するデータをエクスポートＤＢ２５から削除して，削除に成功したか判別する（図１８のＳ５）。エクスポートＤＢ２５からの削除に成功した場合，そのエクスポートＤＢ２５に示されたコピーが行われた宛先のホスト名を持つホスト上のインポートＤＢから，当該サービス名（service)のデータを削除して, 削除に成功したか判別し（同Ｓ６），成功した場合は削除成功となり，そうでないと削除失敗となる。
【００４６】
上記ステップＳ３において，削除したいサービスのプログラムのタイプが‘リモート’の場合，他の計算機からコピーしたサービスプログラムがインポートＤＢ２４にあるか識別するため，インポートＤＢ２４に要求されたサービス名のデータが存在するか検索する（図１８のＳ７）。存在しない場合は削除成功となるが，存在すると該当するデータをインポートＤＢ２４から削除を行い削除が成功したか判別する（同Ｓ８）。成功した場合，そのインポートＤＢ２４にコピーを行った元のホストである，ホスト名がcodeである計算機のエクスポートＤＢ２５から当該サービス名，ホスト名のデータを削除し，削除に成功したか判別し（同Ｓ９），成功した場合は削除成功となる。
【００４７】
図１９，図２０のサービスの削除要求２の処理フロー（その１），（その２）の場合，入力として上記図１８と同様の（service,code,type)が設定される，図１９のＳ１〜Ｓ９の各処理は上記図１８に示す対応する各ステップと同様であるため説明を省略するが，図１９のステップＳ４においてエクスポートＤＢ２５にサービス名（service)のデータ（service,host')が存在しないと判別された時，ステップＳ７においてインポートＤＢ２４にサービス名（service)のデータが存在しないと判別された時，及びステップＳ６においてインポートＤＢ２４からのデータの削除が成功したと判別された時，更にステップＳ９において他の計算機(code)上のエクスポートＤＢからサービス名（service), ホスト名(host)のデータの削除が成功したと判別された時の各場合に，▲１▼の経路で図２０の処理に移行する。
【００４８】
この場合，図２０に示すように，現状ＤＢ２３を検索して，サービス名（service)のデータが存在するか判別し（図２０のＳ１），無い場合はデータ無しとなるが，有る場合は該当するデータ（service,host) を現状ＤＢ２３から削除して，削除に成功したか判別する（図２０のＳ２）。成功した場合，ホスト（host) 上で起動されているサービス (service)を中止する処理を行い, 中止に成功したか判別する（図２０のＳ３）。成功した場合には削除成功の出力が発生するが，成功しないと削除失敗の出力を発生する。このサービスの削除要求２により，削除されるプログラムで提供されているサービスに既にアクセスしている利用者がいる場合に現在の接続を中止させることができる。
【００４９】
サービスの更新要求
サービスを提供しているプログラムを更新する要求であり，更新要求１と更新要求２とがある。
【００５０】
図２１はサービスの更新要求１の処理フローであり，入力として（service,code１，type１，code２，type２）が供給され，code１，type１は更新前のプログラム，プログラムタイプを表し，code２，type２が更新後を表す。サービスＤＢ２２から更新前のサービス名，code１，type１を削除する処理を行い（図２１のＳ１），削除に失敗すると更新失敗となるが，成功するとサービスＤＢ２２にcode２，type２を登録して，その処理が成功したか判別する（同Ｓ２）。これに成功すると更新成功となる。なお，図２１では省略されているが，更新の対象となるサービスがエクスポートＤＢ２５に登録されている場合は，typeの計算機がそのサービスを提供するプログラムのコピーを持っているので，そのコピーを持っている計算機（エクスポートＤＢ２５の登録内容から認識）上のインポートＤＢに登録されている関連情報も更新する。
【００５１】
図２２はサービスの更新要求２の処理フローであり，更新されるプログラムで提供されているサービスに既にアクセスしている利用者がいる場合，現在の接続を中断させ更新されたプログラムで提供されるサービスに対し接続を再開するようにした。
【００５２】
入力として供給されるデータは上記図２１の場合と同様であり，最初にサービスＤＢ２２中に“service,code１，type１”のＤＢが存在するか検索し（図２２のＳ１），存在する場合は該当するデータをサービスＤＢ２２から削除する処理を行い，削除に成功したか判別する（同Ｓ２）。成功した場合，現状ＤＢ２３を検索して，サービス名がservice のデータが存在するか検索する（図２２のＳ３）。存在する場合は，該当するデータ（service,host) を現状ＤＢ２３から削除する処理を行って，削除が成功したか判別する（図２２のＳ４）。現状ＤＢ２３からのデータの削除が成功した場合，ホスト名がhostであるホスト上で起動されているサービス(service) を中止させ，成功したか判別する（同Ｓ５）。中止が成功すると，更新されたデータ(service,code ２，type２）をサービスＤＢ２２に登録する処理を行い，処理が成功したか判別する（同Ｓ６）。成功した場合は，(service,code ２，type２) としてのプログラムの起動を行って, 起動に成功したか判別する（同Ｓ７）。成功すると更新成功が出力され，失敗すると更新失敗が出力される。
【００５３】
サービスの検索要求
図２３はサービスの検索要求の処理フローである。サービスを提供するプログラムを検索する場合，入力として（service,code，type）が供給されると，サービスＤＢ中に入力されたサービス名，プログラム名，プログラムタイプのデータが存在するか検索を行って判別され，存在すると該当データが出力され，存在しないとデータが無いことを表す出力が発生する。
【００５４】
次に中継エージェント２に備えられた各データベースの中の，アクセス方法ＤＢ２１，サービスＤＢ２２に対する操作は，上記に説明した処理において行われるが，現状ＤＢ２３，インポートＤＢ２４及びエクスポートＤＢ２５に対する操作について以下に示し，図２４〜図２６において現状ＤＢに関する操作を説明する。
【００５５】
サービス状況の登録要求
図２４はサービス状況の登録要求の処理フローである。この場合，入力としてサービス名とサービスを提供するホスト名（service,host) が供給される。最初に現状ＤＢ２３中に入力されたサービス名，サービスホストのデータが存在するか検索して判別する（図２４のＳ１）。存在すると登録に失敗する（既に登録済）が，存在しない場合は，現状ＤＢ２３にこのサービス名，サービスホストを登録を行い，登録に成功したか判別し（図２４のＳ２），成功すれば登録成功の出力が発生する。
【００５６】
サービス状況の削除要求
図２５はサービス状況の削除要求の処理フローである。あるホスト上で提供されているサービスを終わらせる場合に，終わらせるサービスとサービスを起動していたホストを削除するため，入力として削除したいサービス名とホスト名 (service,host) を供給し，現状ＤＢ２３を検索し，存在すると入力されたデータを削除し，削除が成功したか判別する。
【００５７】
サービス状況の検索要求
図２６はサービス状況の検索要求の処理フローである。現在起動しているサービスとそのサービスを提供しているホストに関する情報を検索する場合に行われ，入力として，サービス名とホスト名 (service,host) を指定すると，現状ＤＢ２３を検索し，存在する場合は該当データを出力し，存在しないとデータ無しを出力する。
【００５８】
次に図２７〜図２９にインポートＤＢに対する操作を示す。
プログラムのインポート登録要求
図２７はプログラムのインポート登録要求の処理フローであり，サービスを提供するプログラムを他の計算機からコピーしてきた時に，そのサービスに関してどの計算機からプログラムをコピーしてきたのかを記録する場合に実行される。入力として登録したい（service,code,type)を指定し，インポートＤＢに該当するデータが存在するか検索し，存在しない場合は登録を行って，登録成功か判別する。
【００５９】
プログラムのインポート削除要求
図２８はプログラムのインポート削除要求の処理フローであり，サービスを提供するプログラムが更新される等の理由によりコピーしてきたプログラムが不要となった場合に，それに関する情報を削除する場合に行われる。入力として削除したい（service,code,type)を指定し，インポートＤＢに該当するデータが存在するか検索し，存在しないとデータが無いことを出力し，存在すると該当するデータをインポートＤＢから削除する。
【００６０】
プログラムのインポート検索要求
図２９はプログラムのインポート検索要求の処理フローであり，現在，どのようなサービスに関してどのような計算機からプログラムをコピーして来ているのかに関する情報を検索する場合に実行される。入力として検索したい（service,code,type)を指定し，インポートＤＢに該当するデータが存在するか検索し，存在しないとデータが無いことを出力し，存在すると該当データを出力する。
【００６１】
次に図３０〜図３２にエクスポートＤＢに対する操作を示す。
プログラムのエクスポート登録要求
図３０はプログラムのエクスポート登録要求の処理フローであり，サービスを提供するプログラムのコピーを他の計算機に渡した時に，そのサービスに関してどの計算機にプログラムのコピーを渡したのかを記録する場合に実行する。入力として，登録したい（service,host) を指定し，エクスポートＤＢ中に該当するデータが存在するか検索し，存在しない場合にエクスポートＤＢに登録を行い，登録成功か判別する。
【００６２】
プログラムのエクスポート削除要求
図３１はプログラムのエクスポート削除要求の処理フローであり，サービスを提供するプログラムが更新された時等の際にコピーを渡したプログラムを無効にしたい場合に，それに関する情報を削除するために実行される。入力として削除したい（service,host) を指定し，エクスポートＤＢ中に該当するデータが存在するか検索し，存在した場合に該当するデータをエクスポートＤＢから削除して，削除成功か判別する。
【００６３】
プログラムのエクスポート検索要求
図３２はプログラムのエクスポート検索要求の処理フローであり，現在どのようなサービスに関してどのような計算機にプログラムのコピーを渡したのかに関する情報を検索する。入力として，検索したい（service,host) を指定し，エクスポートＤＢ中に該当するデータが存在するか検索し，存在する場合に該当データを出力し，存在しないとデータ無しを出力する。
【００６４】
本発明による中継エージェントを備えたネットワークの環境を個人化することができる。
図３３は個人化のための構成を示す図である。図中，１は端末装置，２’は中継エージェントを表し，中継エージェント２’は図１に示すネットワーク３と同様のネットワーク（図３３では図示省略）に接続される。この構成は，図１に示す中継エージェント２（元の中継エージェントという）の構成に対し利用者チェック部２６が追加されている。
【００６５】
この利用者チェック部２６を含む新たな中継エージェント２’に送られる利用者や他の中継エージェント等からの要求は，最初に全て利用者チェック部２６に送られ，ここで受けた要求の要求依頼者をチェックする。要求依頼者が中継エージェントの利用者（予め登録した利用者名）と同一であれば，その要求は元の中継エージェントに転送され，同一でなければその要求はエラーとされて受け付けられない。
【００６６】
利用者は，中継エージェント２’を起動する際に，その名前を中継エージェント２’に登録する。登録された利用者の情報は利用者チェック部２６に保持される。また，利用者や他の中継エージェントが中継エージェント２’に送る要求には，必ず要求依頼者の情報を付加する。これにより，中継エージェント２’では，誰からその依頼が送られてきたのか知ることができる。
【００６７】
図３４は要求依頼者チェックの処理フローである。入力の「ｕｓｅｒ」は予め登録された利用者名を表し，（sender,request) は利用者（または他の中継エージェント）からの要求を表し，「sender」には要求依頼者名が格納され，「request 」には要求内容が格納される。
【００６８】
中継エージェント２’では，要求が入力されると，予め登録された利用者（user) と入力された要求の要求依頼者(sender)を比較して, 一致が検出されると要求(request) を元の中継エージェントに送り，一致が検出されないと要求依頼者(sender)にエラーを送る。
【００６９】
本発明による効果的な応用例を説明する。
▲１▼特定のプログラム言語（例えば，Ａｐｒｉｌ）で記述されたプログラムが提供されるサービスへのアクセス
図１の端末装置１のＧＵＩ１ａとしてＷＷＷのブラウザを用いてＡｐｉｌで記述された計算機（エージェント）が提供するサービスへアクセスする場合，ＧＵＩがＷＷＷブラウザであるため，中継エージェント２とＧＵＩ１ａ間はＨＴＴＰのプロトコルに従わなければならない。また，ＧＵＩへの出力はＨＴＭＬの形式のテキストで出力しなければならない。さらに，中継エージェント２とサービス間ではＡｐｒｉｌ言語で提供されるメッセージを用いてサービスにアクセスしなければならない。この場合，中継エージェントは基本的に以下の処理を繰り返す。
【００７０】
１．ＷＷＷブラウザを通した利用者からの要求をＨＴＴＰプロトコルで受け取り，その要求をＡｐｒｉｌメッセージに変換しサービス側（Ａｐｉｌプロセス）に送る。
【００７１】
２．サービス側からＡｐｒｉｌメッセージとして送られる結果を受け，ＨＴＭＬ形式のテキストに変換し，ＨＴＴＰプロトコルに従ってＧＵＩに送る。
▲２▼ソフトウェアの自動メインテナンス
本発明は，ソフトウェアの自動メインテナンスにも応用することができる。上記したように，本発明を用いれば他の計算機に登録されているプログラムのコピーを貰い，それを起動してサービスを利用することができる。
【００７２】
ある計算機上で，あるソフトウェアを配付する場合に，そのソフトの利用者はサービスをＤＢに，（サービス名，ソフトが配付されているホスト名，ＲＥＭＯＴＥ）と登録すれば，本発明の構成を用いることにより配付元の計算機より配付ソフトのコピーをインポートＤＢに自動的に取得して利用することができる。これは，自動的にソフトをダウンロードしていることに相当する。また，配付元でソフトの更新があった場合，本発明によりエクスポートＤＢを調べてコピーを持っている計算機を調べ，その計算機上のインポートＤＢを自動的に更新する。これよってソフトウェアの自動メインテナンスが可能である。
【００７３】
▲３▼環境の個人化
本発明による技術を個人単位で行う，すなわち中継エージェントを個人単位で用いることにより，個人でカスタマイズされた環境を構築することが可能である。例えば，中継エージェントを完全に個人化し，他の利用者からのアクセスを禁止してしまえば，サービスＤＢに個人のプライベートな情報を管理するツールを登録して利用することが可能となる。また，中継エージェントを中心に様々なツールを利用することにより，統合的な個人環境を構築することが可能となる。この場合でも，利用者の中継エージェントは他の利用者からのアクセスを禁止するだけなので，通常通り他の計算機上で提供されているサービスにアクセスすることは可能である。
【００７４】
【発明の効果】
本発明によれば，ネットワーク上で提供される様々なサービスに対して，簡便で柔軟な方法によりアクセスすることが可能となる。また，他の計算機が保持するプログラムのコピーを取って保管すると共に複写元や，複写先のデータベースに関連するデータを管理するデータベースを備えることによりソフトウェアの自動メインテナンスが可能となる。更に，本発明のアクセス方式を個人単位で用いることにより，個人環境の構築が容易となる。
【図面の簡単な説明】
【図１】本発明の原理構成を示す図である。
【図２】アクセス方法ＤＢのデータ構造を示す図である。
【図３】サービスＤＢ及びインポートＤＢのデータ構造を示す図である。
【図４】現状ＤＢ及びエクスポートＤＢのデータ構造を示す図である。
【図５】アクセス方法の登録要求の処理フローを示す図である。
【図６】アクセス方法削除要求の処理フローを示す図である。
【図７】アクセス方法更新要求の処理フローを示す図である。
【図８】アクセス方法検索要求の処理フローを示す図である。
【図９】サービスへのアクセス要求１の処理フローを示す図である。
【図１０】プロトコル変換表の例を示す図である。
【図１１】サービスへのアクセス要求２の処理フロー（その１）を示す図である。
【図１２】サービスへのアクセス要求２の処理フロー（その２）を示す図である。
【図１３】サービスへのアクセス要求２の処理フロー（その３）を示す図である。
【図１４】サービスへのアクセス要求２の処理フロー（その４）を示す図である。
【図１５】プログラム起動の処理フローを示す図である。
【図１６】起動方法テーブルの構成例を示す図である。
【図１７】サービスの登録要求の処理フローを示す図である。
【図１８】サービスの削除要求１の処理フローを示す図である。
【図１９】サービスの削除要求２の処理フロー（その１）を示す図である。
【図２０】サービスの削除要求２の処理フロー（その２）を示す図である。
【図２１】サービスの更新要求１の処理フローを示す図である。
【図２２】サービスの更新要求２の処理フローを示す図である。
【図２３】サービスの検索要求の処理フローを示す図である。
【図２４】サービス状況の登録要求の処理フローを示す図である。
【図２５】サービス状況の削除要求の処理フローを示す図である。
【図２６】サービス状況の検索要求の処理フローを示す図である。
【図２７】プログラムのインポート登録要求の処理フローを示す図である。
【図２８】プログラムのインポート削除要求の処理フローを示す図である。
【図２９】プログラムのインポート検索要求の処理フローを示す図である。
【図３０】プログラムのエクスポート登録要求の処理フローを示す図である。
【図３１】プログラムのエクスポート削除要求の処理フローを示す図である。
【図３２】プログラムのエクスポート検索要求の処理フローを示す図である。
【図３３】個人化のための構成を示す図である。
【図３４】要求依頼者チェックの処理フローを示す図である。
【符号の説明】
１      利用者の端末装置
１ａ    ＧＵＩ
２      中継エージェント
２０    制御部
２１    アクセス方法データベース（ＤＢ）
２２    サービスデータベース（ＤＢ）
２３    現状データベース（ＤＢ）
２４    インポートデータベース（ＤＢ）
２５    エクスポートデータベース（ＤＢ）
３      ネットワーク
４      各種のサービス
【図１】
0003884123.tif 000002
【図２】
0003884123.tif 000003
【図３】
0003884123.tif 000004
【図４】
0003884123.tif 000005
【図５】
0003884123.tif 000006
【図６】
0003884123.tif 000007
【図７】
0003884123.tif 000008
【図８】
0003884123.tif 000009
【図９】
0003884123.tif 000010
【図１０】
0003884123.tif 000011
【図１１】
0003884123.tif 000012
【図１２】
0003884123.tif 000013
【図１３】
0003884123.tif 000014
【図１４】
0003884123.tif 000015
【図１５】
0003884123.tif 000016
【図１６】
0003884123.tif 000017
【図１７】
0003884123.tif 000018
【図１８】
0003884123.tif 000019
【図１９】
0003884123.tif 000020
【図２０】
0003884123.tif 000021
【図２１】
0003884123.tif 000022
【図２２】
0003884123.tif 000023
【図２３】
0003884123.tif 000024
【図２４】
0003884123.tif 000025
【図２５】
0003884123.tif 000026
【図２６】
0003884123.tif 000027
【図２７】
0003884123.tif 000028
【図２８】
0003884123.tif 000029
【図２９】
0003884123.tif 000030
【図３０】
0003884123.tif 000031
【図３１】
0003884123.tif 000032
【図３２】
0003884123.tif 000033
【図３３】
0003884123.tif 000034
【図３４】
0003884123.tif 000035