(57)【要約】    【課題】  サービス提供側と利用側との間のインタフェースを保証する。    【解決手段】  サービス提供装置であるサーバ１０において、各種サービスに係るインタフェースの変更内容の変更依頼があると、サービス利用装置であるクライアント２０に対して、その変更内容を示す変更通知電文を事前通知する。一方、インタフェースの変更内容の事前通知を受けたクライアント２０では、各種サービスに係るインタフェースの変更ポリシーに基づいて、インタフェースの変更による影響があるか否かを判定し、その影響判定結果を含んだ応答電文をサーバ１０に通知する。応答電文を受けたサーバ１０では、クライアントから通知された影響判定結果に基づいて、インタフェースの変更が可能であるか否かを判定し、その判定結果をシステム管理者に通知する。【選択図】  図１８
2006163783.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータネットワークにより相互接続され、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するインタフェース保証装置であって、
前記サービス提供装置は、
前記サービス利用装置に対して、各種サービスに係るインタフェースの変更内容を所定期日前に事前通知する事前通知手段と、
該事前通知手段により事前通知されたインタフェースの変更内容の応答として、前記サービス利用装置から通知された影響判定結果に基づいて、前記インタフェースの変更が可能であるか否かを判定する変更可否判定手段と、
を含んで構成されたことを特徴とするコンピュータネットワークにおけるインタフェース保証装置。
【請求項２】
前記サービス提供装置は、
各種サービスに係るインタフェースごとに、複数のサービス利用装置に対してインタフェースの変更内容を事前通知する通知期日を夫々記憶する通知期日記憶手段と、
該通知期日記憶手段に記憶された通知期日について、各インタフェースごとに最長のものを可視的に出力する通知期日出力手段と、
を備えたことを特徴とする請求項１記載のコンピュータネットワークにおけるインタフェース保証装置。
【請求項３】
コンピュータネットワークにより相互接続され、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するインタフェース保証装置であって、
前記サービス利用装置は、
各種サービスに係るインタフェースの変更ポリシーを記憶するポリシー記憶手段と、
前記サービス提供装置から所定期日前にインタフェースの変更内容の事前通知があったときに、前記ポリシー記憶手段に記憶された変更ポリシーに基づいて、該インタフェースの変更による影響があるか否かを判定する影響判定手段と、
該影響判定手段による影響判定結果を前記サービス提供装置に通知する判定結果通知手段と、
を含んで構成されたことを特徴とするコンピュータネットワークにおけるインタフェース保証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスを実現するコンピュータネットワークにおいて、サービス提供側と利用側との間のインタフェースを保証する技術に関する。
【背景技術】
【０００２】
近年では、金融機関などにおいて、ＳＯＡＰ／ＸＭＬ形式のメッセージ交換によって、コンピュータネットワーク上の自律したコンピュータを連携させるＷｅｂサービスが実用化されている。Ｗｅｂサービスでは、ＨＴＴＰで相互接続されたネットワーク環境で、ＳＯＡＰというインタフェースを使用し、ＸＭＬ形式のデータ交換によって、コンピュータを連携させる形態が採用されている。このため、Ｗｅｂサービスにおいては、サービス提供側と利用側との間で、インタフェースの整合性をとる必要があるが、サービス拡張などにより、サービス提供側のインタフェースを変更する必要が生じ得る。
【０００３】
サービス提供側のインタフェース変更が、サービス利用側に影響を及ぼさなければ不具合が発生しないが、コンピュータネットワークには多種多様なコンピュータが接続される実情を考慮すると、インタフェースを保証することは極めて困難である。そこで、特開平９−９１２３２号公報（特許文献１）に記載されるように、クライアントによって指定されたサーバのリソースに変更が生じたときに、サーバがクライアントにその旨を通知する技術が提案されている。
【特許文献１】特開平９−９１２３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、かかる提案技術においては、サーバのリソースに変更が生じたときに、その旨がクライアントに通知されるものの、クライアントのインタフェースなどを一切考慮していないため、次のような不具合が発生するおそれがあった。即ち、サービス提供側たるサーバは、利用側たるクライアントに対して一律的にインタフェース変更を通知しているため、利用側でその変更に対応する時間的余裕がなく、Ｗｅｂサービスが受けられない期間が生じてしまうおそれがある。Ｗｅｂサービスの停止は、それが僅かな期間であっても質の低下に繋がるため、できるだけ避けなければならない。
【０００５】
そこで、本発明は以上のような従来の問題点に鑑み、サービス提供側がサービス利用側にインタフェース変更を事前通知する一方、サービス利用側がその事前通知に基づいてインタフェースに影響があるか否かを判定することで、サービス提供側と利用側との間のインタフェースを保証する技術を提供することを目的とする。
また、Ｗｅｂサービスでは、企業と企業間のシステム連携として利用することを目的とする。この場合、インタフェース変更へのサービス提供者とサービス利用者の責任を明確化する必要がある。利用者が必要としているインタフェースや、利用しているデータ項目を明確にし、契約事項として、インタフェースの保証を行う。また、利用者に影響があるシステムの変更は、サービス提供者は、独自には行わない。さらに、影響がない範囲においてのインタフェースの機能拡張などを許可することができる。これらをシステムとして保証し、インタフェースの変更が発生した場合に、サービス提供者とサービス利用者の責任関係を明確に可視化することで、サービスレベルを保証することを目的とする。
【課題を解決するための手段】
【０００６】
このため、本発明では、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するために、サービス提供装置は、サービス利用装置に対して各種サービスに係るインタフェースの変更内容を所定期日前に事前通知し、その応答としてサービス利用装置から通知された影響判定結果に基いて、インタフェースの変更が可能であるか否かを判定するようにする。また、サービス利用者とサービス提供者の責任範囲を明確にできる。一方、サービス利用装置は、サービス提供装置から所定期日前にインタフェースの変更内容の事前通知があったときに、各種サービスに係るインタフェースの変更ポリシーに基づいて、インタフェースの変更による影響があるか否かを判定し、その影響判定結果をサービス提供装置に通知する。
【０００７】
また、サービス提供装置は、各種サービスに係るインタフェースごとに、複数のサービス利用装置に対してインタフェースの変更内容を事前通知する通知期日を夫々記憶し、各インタフェースごとに最長の通知期日を可視的に出力するようにすることが望ましい。このようにすれば、サービス提供装置のシステム管理者は、各インタフェースについて、その変更に要する期間を容易に把握可能となり、サービス利用側が許容できない期間でのインタフェース変更を行うという不具合を回避することができる。このため、システム管理者の無駄な労力が軽減され、システムの管理コストなどを低減することができる。
【０００８】
さらに、サービスの変更をシステムが自動的にチェックを行い、期日を越えた変更通知の抑止やサービス利用者に影響があるシステムの変更の抑止ができるしくみとすることで、サービス利用者へのサービス停止状態となることを防止することができる。
また、サービス利用者とサービス提供者の責任範囲を明確にするために、本発明では、インタフェースのポリシーを定義し、その中に、インタフェースのデータ項目単位にプライマリ項目か非プライマリ項目として、サービス利用者が、必要とするデータ項目を明確にし、本項目をインタフェースの保証範囲と定義する。これにより、インタフェースの変更が発生した場合に、利用者の影響と責任範囲を可視化し、サービス利用者に安心したサービスを提供することができる。
【発明の効果】
【０００９】
本発明によれば、サービス利用装置に対してインタフェースの変更が所定期日前に事前通知されるので、サービス利用装置において、インタフェース変更に対応する時間が確保され、サービス提供装置とサービス利用装置との間のインタフェースを保証することができる。また、サービス提供装置とサービス利用装置との間のインタフェースが保証されることから、サービス利用装置でサービスを利用できない期間が生じることがなく、サービスの質の低下を防止することができる。
【発明を実施するための最良の形態】
【００１０】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明を具現化したコンピュータネットワークにおけるインタフェース保証装置（以下「インタフェース保証装置」という）の全体構成を示す。
インタフェース保証装置は、各種サービスを提供するＷｅｂサービスサーバ（以下「サーバ」という）１０と、各種サービスを利用するＷｅｂサービスクライアント（以下「クライアント」という）２０と、を含んで構成される。サーバ１０及びクライアント２０は、ＨＴＴＰで相互接続されたネットワーク環境でＳＯＡＰ３０というインタフェースを使用し、ＸＭＬ形式のデータ交換により連携を行う。また、サーバ１０には、サービス拡張に伴うインタフェース変更などの各種作業を行うべく、システム管理者のコンソール４０が接続される。
【００１１】
サーバ１０では、メモリにロードされたインタフェース保証プログラムを実行することで、インタフェース変更管理部１２，適用スケジュール部１４及び修正適用部１６が夫々実現される。インタフェース変更管理部１２は、クライアント２０と連携し、インタフェースの変更が可能であるか否かを判定することで、サービス提供側と利用側との間のインタフェースを保証する。適用スケジュール部１４は、所定のスケジュールに則って、インタフェースを更新する修正適用部１６を起動すると共に、クライアント２０の各種設定変更をシステム管理者に通知する。また、サーバ１０には、このような機能を実現すべく、データベース相当の配信路情報ファイル１８Ａ，電文スキーマ変更定義ファイル１８Ｂ，適用スケジュール環境設定ファイル１８Ｃ，適用スケジュールファイル１８Ｄ，修正モジュールファイル１８Ｅ及び稼動システムファイル１８Ｆが夫々備えられる。
【００１２】
なお、インタフェース変更管理部１２は、事前通知手段，変更可否判定手段，通知期日出力手段，拒否通知手段及び通知手段として機能する一方、適用スケジュール部１４及び修正適用部１６は、変更適用手段として機能する。また、配信路情報ファイル１８Ａは、通知期日記憶手段及び判定結果記憶手段として機能する一方、適用スケジュールファイル１８Ｄは、変更日時記憶手段として機能する。
【００１３】
配信路情報ファイル１８Ａには、図２に示すように、各種サービスに係るインタフェースごとに、少なくとも、サービス利用側のクライアント及び利用サービスを特定するアドレス情報、会社名，所属部署，連絡先及び電話番号からなる所属情報、変更通知依頼電文の送信日時を示す変更通知依頼送信日時、定義又は変更通知電文の送信日時を示す定義／変更通知送信日時、インタフェースの変更が可能であるか否かを示す変更可否、インタフェースを変更する日時を示す適用日時、並びに、変更通知の通知期限を示す通知期日が登録される。ここで、変更通知依頼電文とは、クライアント２０からサーバ１０に送信される、インタフェースに変更があるか否かを問い合わせる電文であり、また、定義通知電文又は変更通知電文とは、変更通知依頼電文の応答として、サーバ１０からクライアント２０へ返信される電文である。
【００１４】
電文スキーマ変更定義ファイル１８Ｂには、図３に示すように、各種サービスに係るインタフェースごとに、変更予約があるか否かを示す変更予約あり／なし、変更予約に係るインタフェース定義を示す変更予約インタフェース、並びに、現在稼動中のインタフェース定義を示す稼動中インタフェースが登録される。変更予約インタフェース及び稼動中インタフェースは、少なくとも、インタフェースの項目名、型、サイズ、必須項目並びに有効範囲を含んで構成される。ここで、必須項目とは、その項目がサービス利用者のシステムに不可欠なプライマリ項目であるか、不可欠ではない非プライマリ項目であるかを示すものである。また、有効範囲とは、その項目が取り得る範囲（数値，文字など）を示すものである。なお、電文スキーマ変更定義をＸＭＬ形式で表現すると、図４に示すようになる。
【００１５】
適用スケジュール環境設定ファイル１８Ｃには、適用スケジュール部１４の作動スケジュールを設定すべく、図５に示すように、配信路情報ファイル１８Ａ及び適用スケジュールファイル１８Ｄを夫々参照する時間間隔を示す配信路情報参照時間間隔及び適用スケジュール参照時間間隔、並びに、配信路情報ファイル１８Ａ及び適用スケジュールファイル１８Ｄを夫々特定する配信路情報ファイル名及び適用スケジュールファイル名が登録される。
【００１６】
適用スケジュールファイル１８Ｄには、変更予約に係るインタフェースの適用日時を設定すべく、図６に示すように、少なくとも、変更予約に係るインタフェース名、適用日時並びにその適用モジュールを示す適用モジュール名が登録される。
修正モジュールファイル１８Ｅ及び稼動システムファイル１８Ｆには、変更予約に係るインタフェースの修正モジュール及び稼動中のインタフェースのモジュールが夫々登録される。
【００１７】
一方、クライアント２０では、メモリにロードされたインタフェース保証プログラムを実行することで、電文編集部２２が実現される。電文編集部２２は、クライアント起動時に変更通知依頼電文をサーバ１０に送信すると共に、サーバ１０からの定義通知電文又は変更通知電文に応答してインタフェース変更による影響の有無を判定し、その判定結果をサーバ１０に返信する。また、クライアント２０には、このような機能を実現すべく、電文編集環境設定ファイル２４Ａ及び電文ポリシー定義ファイル２４Ｂが夫々備えられる。
【００１８】
なお、電文編集部２２は、影響判定手段及び判定結果通知手段として機能する。また、電文ポリシー定義ファイル２４Ｂは、ポリシー記憶手段として機能する。
電文編集環境設定ファイル２４Ａには、各種サービスに係るインタフェースについて、その変更をいつまでに通知してほしいかを適宜設定すべく、図７に示すように、少なくとも、インタフェース名、クライアント及びサービスを特定する通知先アドレス、通知期日並びに所属情報が登録される。
【００１９】
電文ポリシー定義ファイル２４Ｂは、クライアント２０のシステム管理者により、そのシステム構成などを考慮して適宜設定又は変更されるものであって、各種サービスに係るインタフェースの変更ポリシーが定義される。具体的には、電文ポリシー定義ファイル２４Ｂには、図８に示すように、各種サービスに係るインタフェースごとに、少なくとも、項目名、順序性、型、サイズ、必須項目、有効範囲並びに有効範囲変更可否が登録される。ここで、順序性とは、インタフェースを構成する各項目に順序があるか否かを示し、また、有効範囲変更可否とは、有効範囲を変更しても影響がないか否かを示すものである。なお、電文ポリシー定義をＸＭＬ形式で表現すると、図９に示すようになる。
【００２０】
次に、クライアント起動時に実行される処理概要について、図１０を参照しつつ説明する。なお、ここでは、サーバ１０は起動済みであることを前提とする。
クライアント２０が起動されると、クライアント２０は、サーバ１０に対して、各種サービスに係るインタフェースに変更があるか否かを問い合わせる変更通知依頼電文を送信する。ここで、変更通知依頼電文は、図１１に示すように、インタフェース名、通知先アドレス、通知期日並びに所属情報を含んで構成される。
【００２１】
一方、変更通知依頼電文を受信したサーバ１０は、変更通知依頼電文が通知期日以降に送信されたものであるか否かを判定する。そして、サーバ１０は、クライアント２０に対して、変更通知依頼通知が通知期日以降に送信されたものであれば拒否電文を、変更通知依頼電文が通知期日内に送信されたものであれば稼動中又は変更予約に係るインタフェース定義を示す定義通知電文又は変更通知電文を送信する。拒否電文は、図１２に示すように、インタフェース名、通知先アドレス、通知期日並びに拒否内容を示す結果を含んで構成される。また、定義通知電文及び変更定義電文は、図１３及び図１４に夫々示すように、各種サービスに係るインタフェースごとに、項目名、型、サイズ、有効範囲並びに順序性を含んで構成される。
【００２２】
拒否電文，定義通知電文又は変更通知電文を受信したクライアント２０は、拒否電文であればエラーメッセージを表示する一方、定義通知電文又は変更通知電文であればインタフェースに影響があるか否かを通知する応答電文をサーバ１０に送信する。応答電文は、図１５に示すように、インタフェース名、通知先アドレス、通知期日並びに結果を含んで構成される。ここで、結果には、サーバ１０におけるインタフェースに変更があると、クライアント２０のインタフェースに影響があるか否かに加え、影響があるときには、サービスが継続して利用可能であるか否かを示すフラグが設定される。
【００２３】
応答電文を受信したサーバ１０は、インタフェースを変更するとクライアント２０に影響があれば、その旨をシステム管理者に通知する。
図１６は、クライアント起動を契機として、クライアント２０の電文編集部２２で実行される処理詳細を示す。
ステップ１（図では「Ｓ１」と略記する。以下同様）では、電文編集環境設定ファイル２４Ａを読み込み、そのインタフェース名，通知先アドレス，通知期日及び所属情報から、図１１に示す変更通知依頼電文を作成する。
【００２４】
ステップ２では、サーバ１０に対して、作成した変更通知依頼電文を送信する。
ステップ３では、サーバ１０から電文を受信するまで待機する。
ステップ４では、受信した電文が拒否電文以外、即ち、定義通知電文又は変更定義電文であるか否かを判定する。そして、電文が拒否電文以外であればステップ５へと進む（Ｙｅｓ）。一方、電文が拒否電文であればステップ１１へと進み（Ｎｏ）、変更通知依頼が通知期日以降になされた期日違反であることをシステム管理者に通知すべくエラーメッセージを表示すると共に、その旨を示すエラー情報をシステムログに記録する。
【００２５】
ステップ５では、受信した定義通知電文又は変更通知電文の項目名，型，サイズ，有効範囲及び順序性について、電文ポリシー定義ファイル２４Ｂとのマッチングを行い、インタフェース整合性をチェックする。具体的には、受信電文と電文ポリシー定義ファイル２４Ｂとの間で、項目名，型及びサイズが同じであるか、順序性ありの場合には項目順序が同じであるか、有効範囲が変更可能である場合にはこれが同じであるか、などをチェックする。そして、インタフェース整合性がなければステップ６へと進む一方（Ｙｅｓ）、インタフェース整合性があればステップ９へと進む（Ｎｏ）。
【００２６】
ステップ６では、インタフェース整合性がない各項目について、プライマリ項目であるか否かを判定する。そして、インタフェース整合性がない項目の少なくとも１つがプライマリ項目であればステップ７へと進み（Ｙｅｓ）、インタフェースに影響がありかつサービスを継続して利用できないと判定する。一方、インタフェース整合性がない項目のすべてがプライマリ項目でなければステップ８へと進み（Ｎｏ）、インタフェースに影響があるもものサービスを継続して利用可能であると判定する。
【００２７】
ステップ９では、インタフェース整合性のチェック結果に応じて、図１５に示すような応答電文を作成する。
ステップ１０では、サーバ１０に対して、作成した応答電文を送信する。
図１７は、サーバ起動を契機として、サーバ１０のインタフェース変更管理部１２で実行される処理詳細を示す。
【００２８】
ステップ２１では、クライアント２０から変更通知依頼電文を受信するまで待機する。
ステップ２２では、変更通知依頼電文が通知期日前に送信されたものであるか否かを判定する。そして、変更通知依頼電文が通知期日前に送信されたものであればステップ２３へと進む一方（Ｙｅｓ）、通知期日以降に送信されたものであればステップ３２へと進む（Ｎｏ）。
【００２９】
ステップ２３では、稼動中又は変更予約に係るインタフェース定義を通知する定義通知電文又は変更通知電文を作成する。即ち、変更予約に係るインタフェース定義が修正モジュールファイル１８Ｅに登録されていなければ、図１３に示す定義通知電文を作成する一方、変更予約に係るインタフェース定義が修正モジュールファイル１８Ｅに登録されていれば、図１４に示す変更通知電文を作成する。
【００３０】
ステップ２４では、クライアント２０に対して、作成した定義通知電文又は変更通知電文を送信する。
ステップ２５では、配信路情報ファイル１８Ａを更新する。即ち、変更通知依頼電文のインタフェース名により特定されるインタフェースについて、配信路情報ファイル１８Ａのアドレス情報並びに変更通知依頼送信日時を更新する。
【００３１】
ステップ２６では、変更通知依頼電文及び配信路情報ファイル１８Ａの通知期日が一致しているか否かに基づいて、通知期日に変更があるか否かを判定する。ここで、クライアント２０において、インタフェース変更に要する期間の伸長がなされる実情を考慮し、変更通知依頼電文によりこれをサーバ１０に適宜通知することができる。そして、通知期日に変更があればステップ２７へと進み（Ｙｅｓ）、コンソール４０を介して、その旨をシステム管理者に通知する。一方、通知期日に変更がなければステップ２８へと進む（Ｎｏ）。
【００３２】
ステップ２８では、クライアント２０から応答電文を受信するまで待機する。
ステップ２９では、配信路情報ファイル１８Ａを更新する。即ち、応答電文のインタフェース名により特定されるインタフェースについて、アドレス情報に対応した変更可否を更新する。
ステップ３０では、応答電文の結果に基いて、インタフェース変更に伴う影響があるか否かを判定する。そして、影響があればステップ３１へと進み（Ｙｅｓ）、コンソール４０を介して、その旨をシステム管理者に通知する。一方、影響がなければステップ２１へと戻る（Ｎｏ）。
【００３３】
変更通知依頼電文が通知期日以降に送信されたものであるときの処理を行うステップ３２では、図１２に示す拒否電文を作成する。
ステップ３３では、クライアント２０に対して、作成した拒否電文を送信する。
かかるインタフェース保証装置によれば、クライアント２０が起動されるたびに、クライアント２０からサーバ１０に対して、各種サービスに係るインタフェースが変更される予定があるか否かが問い合わされる。そして、サーバ１０からクライアント２０に対して、その問い合わせに応答する定義通知電文又は変更通知電文が送信される。これらの電文を受信したクライアント２０では、各種サービスに係るインタフェースを定義した電文ポリシー定義ファイル２４Ｂを参照することで、インタフェースに影響があるか否かが判定され、その判定結果を含んだ応答電文がサーバ１０に送信される。一方、応答電文を受信したサーバ１０では、応答電文によりクライアント２０のインタフェースに影響があるか否かが判定され、影響があればその旨がシステム管理者に通知される。
【００３４】
このため、サーバ１０のシステム管理者は、各種サービスを利用するクライアント２０が起動するたびに、インタフェースの変更による影響があるか否かを把握することができる。そして、クライアント２０に影響があるときには、例えば、影響がプライマリ項目の場合は、サービス提供者は、インタフェースの整合性を保証する責任があるため、利用者側とで協議を行い、システム変更を行うための期間を確保することで、利用者のシステムとの整合性を保証しつつインタフェース変更を行うようにすればよい。一方、クライアント２０に影響がないときには、所定期日に自動又は手動で、修正モジュールを適用すればよい。
【００３５】
従って、サービス利用側でインタフェース変更に対応する時間が確保されることで、サービス提供側と利用側との間のインタフェースを保証することができる。また、サービス提供側と利用側との間のインタフェースが保証されることから、サービス利用側でサービスを利用できない期間が生じることがなく、サービスの質の低下を防止することができる。
【００３６】
次に、修正モジュールの登録依頼時に実行される処理概要について、図１８を参照しつつ説明する。
システム管理者が、コンソール４０を操作して、変更予約に係るインタフェースを定義する修正モジュールを作成した後、図１９に示す修正モジュール登録画面において、インタフェース名，インタフェース変更日時，電文スキーマ変更定義ファイル名及び修正モジュールを入力して「実行」ボタンを押すと、サーバ１０に対して変更依頼電文が送信される。変更依頼電文を受信したサーバ１０は、図１４に示す変更通知電文を作成し、各種サービスを利用するすべてのクライアント２０に対して変更通知電文を送信する。一方、変更通知電文を受信したクライアント２０は、電文ポリシー定義ファイル２４Ｂを参照することで、インタフェース変更により影響があるか否かを判定し、図１５に示すような応答電文をサーバ１０に送信する。応答電文を受信したサーバ１０は、その結果に基いて修正モジュールの登録が可能であるか否かを判定し、図２０（Ａ）又は（Ｂ）に夫々示す登録完了画面又は登録失敗画面を介して、登録結果をシステム管理者に通知する。
【００３７】
図２１は、システム管理者による修正モジュールの登録依頼を契機として、サーバ１０のインタフェース変更管理部１２で実行される処理詳細を示す。なお、かかる処理は、サーバ起動を契機として実行される図１７に示す処理と並行して実行される。
ステップ４１では、修正モジュールの登録依頼が通知期日を遵守しているか否かを判定する。即ち、インタフェースの変更にあたっては、クライアント２０における対応時間を確保する必要上、配信路情報ファイル１８Ａに設定されている通知期日内に変更通知電文を送信しなければならない。このため、修正モジュールの登録依頼が通知期日を遵守しているか否かを判定することで、クライアント２０における対応時間を確保することができる。そして、通知期日が遵守されていればステップ４２へと進む（Ｙｅｓ）。一方、通知期日が遵守されていなければステップ５３へと進み（Ｎｏ）、その修正モジュールの登録依頼が許容されないものであることを報知すべく、その旨がシステム管理者に通知される。
【００３８】
ステップ４２では、図１４に示す変更通知電文を作成する。
ステップ４３では、配信路情報ファイル１８Ａを参照し、変更予約に係るインタフェースにおけるアドレス情報により特定されるクライアント２０をすべて検索する。
ステップ４４では、検索されたすべてのクライアント２０に対して、作成した変更通知電文を送信する。
【００３９】
ステップ４５では、クライアント２０から応答電文を受信するまで待機する。
ステップ４６では、応答電文の結果に基いて、インタフェース変更による影響があるか否かを判定する。そして、影響がなければステップ４７へと進み（Ｙｅｓ）、応答電文を送信したクライアント及びその利用サービスについて、配信路情報ファイル１８Ａの変更可否を更新する。一方、影響があればステップ４８へと進み（Ｎｏ）、その旨をシステム管理者に通知する。
【００４０】
ステップ４９では、変更通知電文を送信したすべてのクライアント２０から応答電文があったか（全応答完了）、又は、変更通知電文を送信してから所定時間が経過したタイムアウトとなったか否かを判定する。そして、全応答完了又はタイムアウトとなればステップ５０へと進む一方（Ｙｅｓ）、全応答完了又はタイムアウトとならなければステップ４５へと戻る（Ｎｏ）。
【００４１】
ステップ５０では、すべての応答電文に基づいて、サーバ１０とクライアント２０との間のインタフェース整合性に問題があるか否かを判定する。即ち、すべての応答電文の結果が影響なしとなっているか否かを判定する。そして、整合性に問題がなければステップ５１へと進み（Ｙｅｓ）、適用スケジュールファイル１８Ｄに、変更予約に係るインタフェースの適用スケジュールを追加する。一方、整合性に問題があればステップ５２へと進む（Ｎｏ）。
【００４２】
ステップ５２では、図２０に示す登録完了画面又は登録失敗画面により、修正モジュールの登録結果をシステム管理者に通知する。ここで、修正モジュールの登録結果は、画面を介してシステム管理者に通知するだけではなく、図２２に示すような形式で、プリンタなどの印刷機器に出力するようにしてもよい。
かかるインタフェース保証装置によれば、システム管理者が、予約変更に係るインタフェースを定義した修正モジュールを登録しようとするたびに、サーバ１０からサービスを利用するすべてのクライアント２０に対して、変更しようとするインタフェースを示す変更通知電文が送信される。変更通知電文を受信したクライアント２０では、各種サービスに係るインタフェースを定義した電文ポリシー定義ファイル２４Ｂを参照することで、インタフェースに影響があるか否かが判定され、その判定結果を含んだ応答電文がサーバ１０に送信される。一方、応答電文を受信したサーバ１０では、応答電文によりクライアント２０のインタフェースに影響があるか否かが判定され、影響があればその旨がシステム管理者に通知される。また、サーバ１０では、すべての応答電文に基づいてインタフェース整合性に問題があるか否かが判定され、登録完了画面又は登録失敗画面により、修正モジュールの登録結果がシステム管理者に通知される。
【００４３】
このため、サーバ１０のシステム管理者は、登録完了画面又は登録失敗画面を介して、インタフェース変更による影響があるか否かを把握することができる。また、変更通知電文を受信すべきクライアント２０が起動されていないときには、図１０に示すクライアント起動時に実行される処理により、インタフェース変更による影響の有無が判定されるので、問題が生じることはない。なお、他の作用効果については、先のインタフェース保証装置と同様であるので、その説明を省略するものとする。
【００４４】
図２３は、サーバ起動を契機として、サーバ１０の適用スケジュール部１４で実行される処理詳細を示す。
ステップ６１では、適用スケジュール環境設定ファイル１８Ｃを読み込み、適用スケジュールファイル名及び適用スケジュール参照時間間隔を抽出する。
ステップ６２では、適用スケジュールファイル名により特定される適用スケジュールファイル１８Ｄを読み込む。
【００４５】
ステップ６３では、適用スケジュールファイル１８Ｄの各インタフェースについて、その適用日時となったか否かを判定する。そして、適用日時となったならばステップ６４へと進み（Ｙｅｓ）、適用モジュール名をパラメータとして修正適用部１６を起動させる。一方、適用日時となっていなければステップ６５へと進む（Ｎｏ）。
ステップ６５では、適用スケジュールファイル１８Ｄを参照してから、適用スケジュール参照時間間隔経過したか否かを判定する。そして、参照時間間隔経過したならばステップ６２へと戻る一方（Ｙｅｓ）、参照時間間隔経過していなければ待機する（Ｎｏ）。
【００４６】
図２４は、サーバ１０の修正適用部１６で実行される処理詳細を示す。
ステップ７１では、修正モジュールファイル１８Ｅから、適用モジュール名により特定される修正モジュールを読み込み、稼動システムファイル１８Ｆに登録されている稼動中のインタフェースに上書きする。
ステップ７２では、適用スケジュールファイル１８Ｄから、修正モジュールに係る該当エントリを削除する。
【００４７】
ステップ７３では、配信路情報ファイル１８Ａの適用日時に、修正モジュールを適用した日時を書き込む。
ステップ７４では、電文スキーマ変更定義ファイル１８Ｂにおける稼動中インタフェースに変更予約インタフェースを上書きし、変更予約インタフェースを削除する。
適用スケジュール部１４及び修正適用部１６により提供される機能によれば、予め設定された時間間隔で適用スケジュールファイル１８Ｄが参照され、変更予約に係る各インタフェースについて、その適用日時となったか否かが判定される。そして、適用日時となると、稼動中のインタフェースが自動更新され、その更新に伴って各種ファイルが更新される。
【００４８】
このため、サーバ１０のシステム管理者は、修正モジュールの適用日時を監視する必要がなく、その労力を大幅に軽減することができる。このとき、適用スケジュールファイル１８Ｄには、クライアント２０に影響がない変更予約に係るインタフェースが登録されているので、これが自動的に適用されたとしても、サービス提供側と利用側との間のインタフェース整合性に問題が生じることがない。
【００４９】
図２５は、サーバ起動を契機として、サーバ１０の適用スケジュール部１４で並行して実行される処理詳細を示す。
ステップ８１では、適用スケジュール環境設定ファイル１８Ｃを読み込み、配信路情報ファイル名及び配信路情報参照時間間隔を抽出する。
ステップ８２では、配信路情報ファイル名により特定される配信路情報ファイル１８Ａを読み込む。
【００５０】
ステップ８３では、メモリに記憶された従前の変更可否を参照し、配信路情報ファイル１８Ａの変更可否が変更されているか否かを判定する。そして、変更可否が変更されていればステップ８４へと進む一方（Ｙｅｓ）、変更可否が変更されていなければステップ８７へと進む（Ｎｏ）。
ステップ８４では、システム管理者に対して、図２６に示す適用可否変更画面を提示し、変更可否が変更されていることを通知する。
【００５１】
ステップ８５では、図２６に示す変更可否変更画面と同様な形式を用い、変更可否が変更されていることをプリンタなどの印刷機器で印刷する。
ステップ８６では、変更に係る変更可否をメモリに記憶させる。
ステップ８７では、配信路情報ファイル１８Ａを参照してから、配信路情報参照時間間隔経過したか否かを判定する。そして、参照時間間隔経過したならばステップ８２へと戻る一方（Ｙｅｓ）、参照時間間隔経過していなければ待機する（Ｎｏ）。
【００５２】
かかる処理によれば、予め設定された時間間隔で配信路情報ファイル１８Ａが参照され、変更可否が変更されたか否かが判定される。そして、変更可否が変更されていれば、その変更内容がシステム管理者に通知されると共に印刷される。このため、クライアント２０の都合により、修正モジュールの適用前にインタフェース変更可否が変更されても、その旨がシステム管理者に通知されるので、サービス提供側と利用側との間のインタフェース整合性を確実に確保することができる。
【００５３】
図２７は、システム管理者の明示的な依頼を契機として、サーバ１０のインタフェース変更管理部１２で実行される処理詳細を示す。
ステップ９１では、配信路情報ファイル１８Ａを読み込む。
ステップ９２では、インタフェース名ごとに最長の適用期日を抽出し、図２８に示す印刷形式の適用期日一覧をプリンタなどの印刷機器で印刷する。
【００５４】
かかる処理によれば、システム管理者は、各インタフェースについて、その変更に要する期間を容易に把握可能となり、サービス利用側が許容できない期間でのインタフェース変更を行うという不具合を回避することができる。このため、システム管理者における無駄な労力が軽減され、システムの管理コストなどを低減することができる。
【００５５】
（付記１）コンピュータネットワークにより相互接続され、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するインタフェース保証装置であって、前記サービス提供装置は、前記サービス利用装置に対して、各種サービスに係るインタフェースの変更内容を所定期日前に事前通知する事前通知手段と、該事前通知手段により事前通知されたインタフェースの変更内容の応答として、前記サービス利用装置から通知された影響判定結果に基づいて、前記インタフェースの変更が可能であるか否かを判定する変更可否判定手段と、を含んで構成されたことを特徴とするコンピュータネットワークにおけるインタフェース保証装置。
【００５６】
（付記２）前記サービス提供装置は、各種サービスに係るインタフェースごとに、複数のサービス利用装置に対してインタフェースの変更内容を事前通知する通知期日を夫々記憶する通知期日記憶手段と、該通知期日記憶手段に記憶された通知期日について、各インタフェースごとに最長のものを可視的に出力する通知期日出力手段と、を備えたことを特徴とする付記１記載のコンピュータネットワークにおけるインタフェース保証装置。
【００５７】
（付記３）前記事前通知手段は、各種サービスに係るインタフェースの変更内容の登録依頼があったときに、前記サービス利用装置に対してその変更内容を事前通知することを特徴とする付記１又は付記２に記載のコンピュータネットワークにおけるインタフェース保証装置。
【００５８】
（付記４）前記事前通知手段は、前記サービス利用装置から通知される通知依頼に応答して、該サービス利用装置に対してインタフェースの変更内容を事前通知することを特徴とする付記１〜付記３のいずれか１つに記載のコンピュータネットワークにおけるインタフェース保証装置。
【００５９】
（付記５）前記サービス提供装置は、前記通知依頼が所定期日以降に通知されたときに、前記サービス利用装置に対して前記通知依頼を拒否する旨を通知する拒否通知手段を備えたことを特徴とする付記４記載のコンピュータネットワークにおけるインタフェース保証装置。
【００６０】
（付記６）前記所定期日は、前記サービス利用装置からの要望に応じて適宜設定又は変更されることを特徴とする付記１〜付記５のいずれか１つに記載のコンピュータネットワークにおけるインタフェース保証装置。
【００６１】
（付記７）前記サービス提供装置は、前記変更可否判定手段による判定結果を記憶する判定結果記憶手段と、該判定結果記憶手段により判定結果が記憶された後、前記変更可否判定手段によりインタフェースの変更が可能であるか否かが再度判定されたときに、その判定結果と前記判定結果記憶手段に記憶された判定結果とが不一致であれば、その旨を通知する通知手段と、を備えたことを特徴とする付記１〜付記６のいずれか１つに記載のコンピュータネットワークにおけるインタフェース保証装置。
【００６２】
（付記８）前記サービス提供装置は、前記変更可否判定手段によりインタフェースの変更が可能であると判定されたときに、該インタフェースの変更日時を記憶する変更日時記憶手段と、該変更日時記憶手段に記憶されたインタフェースの変更日時となったときに、該インタフェースの変更を適用する変更適用手段と、を備えたことを特徴とする付記１〜付記７のいずれか１つに記載のコンピュータネットワークにおけるインタフェース保証装置。
【００６３】
（付記９）コンピュータネットワークにより相互接続され、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するインタフェース保証装置であって、前記サービス利用装置は、各種サービスに係るインタフェースの変更ポリシーを記憶するポリシー記憶手段と、前記サービス提供装置から所定期日前にインタフェースの変更内容の事前通知があったときに、前記ポリシー記憶手段に記憶された変更ポリシーに基づいて、該インタフェースの変更による影響があるか否かを判定する影響判定手段と、該影響判定手段による影響判定結果を前記サービス提供装置に通知する判定結果通知手段と、を含んで構成されたことを特徴とするコンピュータネットワークにおけるインタフェース保証装置。
【００６４】
（付記１０）コンピュータネットワークにより相互接続され、各種サービスを提供するサービス提供装置と各種サービスを利用するサービス利用装置との間のインタフェースを保証するインタフェース保証装置であって、前記サービス提供装置は、前記サービス利用装置に対して、各種サービスに係るインタフェースの変更内容を所定期日前に事前通知する事前通知手段と、該事前通知手段により事前通知されたインタフェースの変更内容の応答として、前記サービス利用装置から通知された影響判定結果に基づいて、前記インタフェースの変更が可能であるか否かを判定する変更可否判定手段と、を含んで構成される一方、前記サービス利用装置は、各種サービスに係るインタフェースの変更ポリシーを記憶するポリシー記憶手段と、前記サービス提供装置からインタフェースの変更内容の事前通知があったときに、前記ポリシー記憶手段に記憶された変更ポリシーに基づいて、該インタフェースの変更による影響があるか否かを判定する影響判定手段と、該影響判定手段による影響判定結果を前記サービス提供装置に通知する判定結果通知手段と、を含んで構成されたことを特徴とするコンピュータネットワークにおけるインタフェース保証装置。
【図面の簡単な説明】
【００６５】
【図１】本発明を具現化したインタフェース保証装置の全体構成図
【図２】配信路情報ファイルの説明図
【図３】電文スキーマ変更定義ファイルの説明図
【図４】ＸＭＬで記述した電文スキーマ変更定義の説明図
【図５】適用スケジュール環境設定ファイルの説明図
【図６】適用スケジュールファイルの説明図
【図７】電文編集環境設定ファイルの説明図
【図８】電文ポリシー定義ファイルの説明図
【図９】ＸＭＬで記述した電文ポリシー定義の説明図
【図１０】クライアント起動時に実行される処理概要の説明図
【図１１】変更通知依頼電文の説明図
【図１２】拒否電文の説明図
【図１３】定義通知電文の説明図
【図１４】変更通知電文の説明図
【図１５】応答電文の説明図
【図１６】クライアント起動を契機として電文編集部で実行される処理詳細を示すフローチャート
【図１７】サーバ起動を契機としてインタフェース変更管理部で実行される処理詳細を示すフローチャート
【図１８】修正モジュールの登録依頼時に実行される処理概要の説明図
【図１９】修正モジュール登録画面の説明図
【図２０】修正モジュールの登録結果を通知する画面を示し、（Ａ）は登録完了画面の説明図、（Ｂ）は登録失敗画面の説明図
【図２１】修正モジュールの登録依頼を契機としてインタフェース変更管理部で実行される処理詳細を示すフローチャート
【図２２】修正モジュール登録結果を印刷する形式の説明図
【図２３】サーバ起動を契機として適用スケジュール部で実行される処理詳細を示すフローチャート
【図２４】適用スケジュール部により起動される修正適用部の処理詳細を示すフローチャート
【図２５】サーバ起動を契機として適用スケジュール部で並行して実行される処理詳細を示すフローチャート
【図２６】適用可否変更通知及びその印刷形式の説明図
【図２７】システム管理者の依頼を契機としてインタフェース変更管理部で実行される処理詳細を示すフローチャート
【図２８】適用期日一覧の印刷形式の説明図
【符号の説明】
【００６６】
１０    サーバ
１２    インタフェース変更管理部
１４    適用スケジュール部
１６    修正適用部
１８Ａ  配信路情報ファイル
１８Ｂ  電文スキーマ変更定義ファイル
１８Ｃ  適用スケジュール環境設定ファイル
１８Ｄ  適用スケジュールファイル
１８Ｅ  修正モジュールファイル
１８Ｆ  稼動システムファイル
２０    クライアント
２２    電文編集部
２４Ａ  電文編集環境設定ファイル
２４Ｂ  電文ポリシー定義ファイル
３０    ＳＯＡＰ
４０    コンソール
【図１】
2006163783.tif 000003
【図２】
2006163783.tif 000004
【図３】
2006163783.tif 000005
【図４】
2006163783.tif 000006
【図５】
2006163783.tif 000007
【図６】
2006163783.tif 000008
【図７】
2006163783.tif 000009
【図８】
2006163783.tif 000010
【図９】
2006163783.tif 000011
【図１０】
2006163783.tif 000012
【図１１】
2006163783.tif 000013
【図１２】
2006163783.tif 000014
【図１３】
2006163783.tif 000015
【図１４】
2006163783.tif 000016
【図１５】
2006163783.tif 000017
【図１６】
2006163783.tif 000018
【図１７】
2006163783.tif 000019
【図１８】
2006163783.tif 000020
【図１９】
2006163783.tif 000021
【図２０】
2006163783.tif 000022
【図２１】
2006163783.tif 000023
【図２２】
2006163783.tif 000024
【図２３】
2006163783.tif 000025
【図２４】
2006163783.tif 000026
【図２５】
2006163783.tif 000027
【図２６】
2006163783.tif 000028
【図２７】
2006163783.tif 000029
【図２８】
2006163783.tif 000030