(57)【要約】【課題】ネットワーク上に分散する複数のサービスが連携して処理を行うようなＷｅｂサービスにおいて、メッセージが通過する経路のループを検出する。【解決手段】Ｗｅｂサービス２０１のメッセージ受信・解析部２０３は、メッセージと経路履歴情報を受信する。サービス処理実行部２０４は、サービス提供に係わる処理を実行する。送信先決定部２０５は、送信されるメッセージの送信先を決定する。経路検証部２０７は、受信した経路履歴情報と決定した送信先に経路検証ルールを適用してメッセージ送信先の正当性を判定する。送信先が正しいと判定された場合に、メッセージ生成・送信部２１０は、メッセージと当該経路分を追加した経路履歴状態を送信先へ送信する。【選択図】図２
2005006139.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に分散する複数のサービス提供プログラムが連携してサービス要求者にサービスを提供するＷｅｂサービスにおいて、前記サービス提供プログラム間に転送されるメッセージは通過した前記サービス提供プログラムの経路を示す経路履歴情報を付帯し、
前記サービス提供プログラムは、前記ネットワークを介してメッセージと前記経路履歴情報とを受信するステップと、サービス提供に係わる処理を実行するステップと、ルーティングテーブルを参照して前記メッセージに対応して送信されるメッセージの送信先を決定するステップと、決定された前記送信先と受信した前記経路履歴情報とを突き合わせて前記送信先の正当性を判定するステップと、前記送信先が正しいと判定された場合に送信されるメッセージと、前記経路履歴情報に当該サービス提供プログラムの経路分を追加した経路履歴情報とを決定された前記送信先に送信するステップとを備えたことを特徴とするＷｅｂサービスにおける経路ループ検出方法。
【請求項２】
前記送信先の正当性を判定するステップは、経路検証のためのルールに基づいて判定することを特徴とする請求項１記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項３】
前記ルールは、ルール設定画面を介して作成及び変更されることを特徴とする請求項２記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項４】
前記経路履歴情報は、送信元、送信先及びメッセージ内容のダイジェスト値の各データ項目値を含み、前記送信先の正当性を判定するステップは、送信されるメッセージについて前記データ項目値の各々との一致を検証することを特徴とする請求項１記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項５】
前記送信先の正当性を判定するステップは、所定回数までの同一経路及び同一内容のメッセージの通過を正しいと判定することを特徴とする請求項１記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項６】
さらに前記送信先が正しくないと判定された場合に、指定された他のサービス提供プログラムにエラーメッセージを送信するステップを有することを特徴とする請求項１記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項７】
さらに前記送信先が正しくないと判定された場合に、管理者端末にエラーメッセージを送信するステップを有することを特徴とする請求項１記載のＷｅｂサービスにおける経路ループ検出方法。
【請求項８】
ネットワーク上に分散する複数のサービス提供プログラムが連携してサービス要求者にサービスを提供するＷｅｂサービスにおいて、前記サービス提供プログラム間に転送されるメッセージは通過した前記サービス提供プログラムの経路を示す経路履歴情報を付帯し、サーバ計算機に、
前記ネットワークを介してメッセージと前記経路履歴情報とを受信する機能、サービス提供に係わる処理を実行する機能、ルーティングテーブルを参照して前記メッセージに対応して送信されるメッセージの送信先を決定する機能、決定された前記送信先と受信した前記経路履歴情報とを突き合わせて前記送信先の正当性を判定する機能、および前記送信先が正しいと判定された場合に送信されるメッセージと、前記経路履歴情報に当該サービス提供プログラムの経路分を追加した経路履歴情報とを決定された前記送信先に送信する機能を実現させるためのサービス提供プログラム。
【請求項９】
ネットワーク上に分散する複数のサーバ計算機が連携してサービス要求者にサービスを提供するシステムのうちの前記サーバ計算機において、前記サーバ計算機間に転送されるメッセージは通過した前記サーバ計算機の経路を示す経路履歴情報を付帯し、
前記サーバ計算機は、前記ネットワークを介してメッセージと前記経路履歴情報とを受信する手段と、サービス提供に係わる処理を実行する手段と、ルーティングテーブルを参照して前記メッセージに対応して送信されるメッセージの送信先を決定する手段と、決定された前記送信先と受信した前記経路履歴情報とを突き合わせて前記送信先の正当性を判定する手段と、前記送信先が正しいと判定された場合に送信されるメッセージと、前記経路履歴情報に当該サーバ計算機の経路分を追加した経路履歴情報とを決定された前記送信先に送信する手段とを有することを特徴とする経路ループを検出するサーバ計算機。
【請求項１０】
ネットワーク上に分散する複数のサービス提供プログラムが連携してサービス要求者にサービスを提供するシステムにおいて、前記サービス提供プログラム間に転送されるメッセージは通過した前記サービス提供プログラムの経路を示す経路履歴情報を付帯し、前記ネットワーク上に分散し前記サービス提供プログラムを実行するサーバ計算機は、前記サービス提供プログラムに係わる手段として、
前記ネットワークを介してメッセージと前記経路履歴情報とを受信する手段と、サービス提供に係わる処理を実行する手段と、ルーティングテーブルを参照して前記メッセージに対応して送信されるメッセージの送信先を決定する手段と、決定された前記送信先と受信した前記経路履歴情報とを突き合わせて前記送信先の正当性を判定する手段と、前記送信先が正しいと判定された場合に送信されるメッセージと、前記経路履歴情報に実行中の当該サービス提供プログラムの経路分を追加した経路履歴情報とを決定された前記送信先に送信する手段とを有することを特徴とする経路ループを検出するシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークにおいて、分散している複数のサービス提供実体が連携して処理を行うようなＷｅｂサービスの技術に係わり、特にメッセージの経路を監視する技術に関する。
【０００２】
【従来の技術】
Ｗｅｂサービスの通信経路に関する技術として、マイクロソフト社が提唱しているＷＳ−Ｒｏｕｔｉｎｇは、メッセージの経路の定義仕様を規定している（非特許文献１参照）。また同じくマイクロソフト社が提唱しているＷＳ−Ｒｅｆｅｒｒａｌは、メッセージの経路を動的に構成するための仕様を規定している（非特許文献２参照）。
【０００３】
【非特許文献１】
マイクロソフト、ＷＳ−Ｒｏｕｔｉｎｇ仕様、２００１年１０月２３日
ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｄｎｇｌｏｂｓｐｅｃ／ｈｔｍｌ／ｗｓ−ｒｏｕｔｉｎｇ．ａｓｐ（原文）
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｍｓｄｎ／ｗｅｂｓｅｒｖｉｃｅｓ／ｄｎｓｒｖｓｐｅｃ／ｗｓ−ｒｏｕｔｉｎｇ．ａｓｐ（日本語訳）
【非特許文献２】
マイクロソフト、ＷＳ−Ｒｅｆｅｒｒａｌ仕様、２００１年１０月２３日
ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｄｎｇｌｏｂｓｐｅｃ／ｈｔｍｌ／ｗｓ−ｒｅｆｅｒｒａｌ．ａｓｐ（原文）
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｍｓｄｎ／ｗｅｂｓｅｒｖｉｃｅｓ／ｄｎｓｒｖｓｐｅｃ／ｗｓ−ｒｅｆｅｒｒａｌ．ａｓｐ（日本語訳）
【０００４】
【発明が解決しようとする課題】
上記従来技術は、メッセージの経路の定義方法、経路の追加、変更方法などについて規定しているが、メッセージの経路の正当性については配慮していない。メッセージの経路が誤っていた場合、最悪メッセージの通過する経路がループし、無駄な通信によるネットワーク負荷の増大を引き起こすという問題があった。またこのような経路ループは容易に事象が発見できないため、回復に時間を要するという問題点があった。
【０００５】
本発明は、このような経路ループを検出し、無駄な通信によるネットワーク負荷の増大を防止することを目的とする。
【０００６】
【課題を解決するための手段】
上記目的を達成するために本発明は、Ｗｅｂサービスのメッセージにメッセージの経路を表現する経路履歴情報を付帯させるものである。本発明のＷｅｂサービスは、受信した経路履歴情報に基づいて経路の検証を行う技術を特徴とする。
【０００７】
【発明の実施の形態】
以下、本発明の実施形態について図面を用いて説明する。
【０００８】
図１は、本実施形態に係る複数のサービスが連携して処理を行うシステムの具体例を示す図である。この具体例は、リクエスタ１０１、対象サービス１０２、認証サービス１０３および認可サービス１０４が連携して処理を行う。対象サービス１０２、認証サービス１０３および認可サービス１０４は、サーバ計算機あるいはサーバ計算機上で実行されるサービス提供プログラムである。リクエスタ１０１はクライアント端末である。リクエスタ１０１は、対象サービス１０２が提供しているサービスを利用するために、対象サービス１０２にサービス要求のメッセージを送信する。このメッセージは、リクエスタ１０１が作成するものであっても良いし、他のサービスから転送されてきたメッセージ、またはＷｅｂブラウザから送信された情報を基にリクエスタ１０１が組み立てたメッセージであっても良い。対象サービス１０２は、リクエスタ１０１からサービス要求メッセージを受信し、サービスの要求者が正しいユーザであるかどうかの認証とサービスの要求者がサービスを利用可能かどうかの判定に基づいて認可を行うために、認証サービス１０３および認可サービス１０４にサービス要求メッセージを転送する前に経路情報を設定する。
【０００９】
対象サービス１０２は、設定した経路情報に基づき、まず認証サービス１０３に要求メッセージを転送する。認証サービス１０３は、対象サービス１０２から受信したメッセ−ジに含まれるサービス要求者の情報を基に認証を行う。認証が成功した場合は、認証サービス１０３は、認可サービス１０４に要求メッセージを転送する。認可サービス１０４は、認証サービス１０３から受信したメッセージに含まれるサービス要求者の情報と要求されているサービスの情報からサービスを許可するか否かを判定する。認可が成功した場合は、認可サービス１０４は、対象サービス１０２にサービス許可を示すメッセージを送信する。対象サービス１０２は、このメッセージを受信して、要求されているサービスを実行し、そのサービス処理の結果の情報をリクエスタ１０１に送信する。本具体例において、対象サービス１０２は、サービス要求メッセージまたは認可メッセージを受信して次の送信先を決定するときに、認証および認可がされていない場合は、認証サービス１０３へ、認証および認可されている場合はリクエスタ１０１へ送信するという決定を行っている。この送信先の決定は、一般的にＷｅｂサービスの管理者の経路の設定に基づいて行われるものであるが、この設定に誤りがあると予期しないメッセージの転送が行われてしまう。特に本具体例において、認証および認可がされている場合でも、再びサービス要求メッセージを認証サービス１０３へ転送するような設定が行われている場合、メッセージは認証サービス１０３および認可サービス１０４を経て再び対象サービス１０２に戻ってくる。この動作の繰り返しは、メッセージの転送についての経路ループを引き起こすことになる。本発明は、本具体例における対象サービス１０２やその他のＷｅｂサービスに適用することにより、このような経路ループを回避することを目的とする。
【００１０】
図２は、一実施例であるＷｅｂサービスを行うサーバ計算機あるいはサービス提供プログラムの構成を表す図である。このＷｅｂサービス２０１は、メッセージ２０２を受信して処理を行った後に、いずれかの送信先にメッセージ２１１を送信する。また管理者端末２１３は、このＷｅｂサービス２０１に接続され、管理者が操作する端末である。
【００１１】
Ｗｅｂサービス２０１は、メッセージ２０２を受信して解析を行うメッセージ受信・解析部２０３、メッセージが要求しているサービスを実行するサービス実行処理部２０４、次のメッセージ送信先を決定する送信先決定部２０５、決定した送信先から経路を検証する経路検証部２０７、メッセージ２１１を生成し、決定した送信先に送信するメッセージ生成・送信部２１０および経路の誤りが検出された場合、管理者端末２１３に通知を行なう経路誤り通知部２１２から構成される。送信先決定部２０５は、次の送信先を決定するために、あらかじめ管理者端末２１３より登録されたルーティングテーブル２０６の情報を参照する。また経路検証部２０７は、メッセージ受信・解析部２０３が作成した履歴情報２０８と、あらかじめ管理者端末２１３によって登録された経路検証ルール２０９とを突き合わせ、経路の検証を行う。
【００１２】
Ｗｅｂサービス２０１に係わるサーバ計算機は、ハードウェアとしてＣＰＵ、メモリ、ディスク装置などの外部記憶装置を備える。メッセージ受信・解析部２０３、サービス実行処理部２０４、送信先決定部２０５、経路検証部２０７およびメッセージ生成・送信部２１０は、メモリに格納され、ＣＰＵによって実行されるプログラムである。ルーティングテーブル２０６、履歴情報２０８および経路検証ルール２０９は、メモリ又は外部記憶装置に格納されるデータである。
【００１３】
図３は、Ｗｅｂサービス２０１が受信するメッセージ２０２あるいは送信するメッセージ２１１のデータ構成例を示す図である。メッセージ２０２，２１１は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）で表現されており、要素としてヘッダ部３０２とボディ部３０３を含む。ヘッダ部３０２は、主にＷｅｂサービスの制御データを含み、本発明で特徴とする履歴情報ヘッダ３０４とその他複数のヘッダ３０５で構成されている。ボディ部３０３は、Ｗｅｂサービスのサービス内容についての要求やその結果に関するデータが含まれる。
【００１４】
メッセージ受信・解析部２０３は、メッセージ２０２の受信時に履歴情報ヘッダ３０４の読み込みと解析を行う。またメッセージ受信・解析部２０３は、履歴情報ヘッダ３０４の解析結果を履歴情報２０８に格納する。またメッセージ生成・送信部２１０は、履歴情報２０８を読み込み、新たな履歴情報を加えて送信するメッセージ２１１の履歴情報ヘッダ３０４を生成する。
【００１５】
図４は、履歴情報ヘッダ３０４の具体例を示す図である。履歴情報ヘッダ３０４は、複数個の送信履歴情報を含む。図４の例では３個の送信履歴情報４０１，４０２および４０３を含んでいる。送信履歴情報は、Ｗｅｂサービスが次のＷｅｂサービスへメッセージを送信する時に履歴情報ヘッダ３０４に追加する情報である。送信履歴情報４０１は、送信時刻４０４、送信元情報４０５、送信先情報４０６及び送信メッセージのダイジェスト値４０７を含む。送信元情報４０５と送信先情報４０６は、ＵＲＬ（Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｉｏｎ）の形式で表現され、ホスト名称やサービスを特定する情報を含む。また送信メッセージのダイジェスト値４０７は、メッセージ２０２，２１１のボディ部３０３の内容をハッシュ関数を使って求めた計算値である。ハッシュ関数としてはＳＨＡ−１（Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ  １）やＭＤ５（Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  ５）等を使用することができる。ダイジェスト値４０７は、ボディ部３０３が同じメッセージに対しては同じ値となり、ボディ部３０３が異なるメッセージに対しては異なる値となる。
【００１６】
図５は、履歴情報２０８を表現するテーブルのデータ構成例を示す図であり、メッセージ受信・解析部２０３が履歴情報ヘッダ３０４を解析した結果である。履歴情報２０８は、テーブル形式で表現され、テーブルの各行は、送信時刻５０１、送信元５０２、送信先５０３および送信メッセージのダイジェスト値５０４の各データ項目で構成される。送信時刻５０１は、履歴情報ヘッダ３０４の送信時刻４０４を表したものである。送信元５０２は送信元４０５を表したものである。送信先５０３は送信先４０６を表したものである。ダイジェスト値５０４はダイジェスト値４０７を表したものである。
【００１７】
履歴情報２０８をテーブル形式で表現することにより、経路検証部２０７は、テーブルのデータ項目を参照して経路検証をする。たとえばＷｅｂサービスの次の送信先が履歴情報２０８の送信先５０３の値と一致している行があれば、過去の経路で通過したＷｅｂサービスと同一のＷｅｂサービスに送信されると判断することができる。
【００１８】
図６は、ルーティングテーブル２０６を表現するテーブルのデータ構成例を示す図である。ルーティングテーブル２０６は、サービス種別６０１、条件６０２及び送信先６０３の各項目から構成される。サービス種別６０１は、リクエスタ１０１の指定したサービスの種別であり、最終の宛先を示す。条件６０２はメッセージを送信先６０３に転送する条件であり、送信先６０３はその送信先である。たとえばテーブルのレコード６０４は、対象サービス１０２がリクエスタ１０１から自サーバ宛のサービス要求を受信したがまだその要求者の認証をしていない場合に、認証サービス１０３にメッセージを転送する場合のルールである。レコード６０５は、リクエスタ１０１から最終宛先がホストＸであるメッセージを受信し、その処理が正常に終了した場合にホストＹに転送するルールを設定する。レコード６０６は、リクエスタ１０１から最終宛先がホストＸであるメッセージを受信し、その処理の結果、エラーとなった場合にホストＺに転送するルールを設定する。
【００１９】
ルーティングテーブル２０６の各レコードは、管理者端末２１３より登録される情報である。よって人為的なミス等により、不正な情報が登録される可能性がある。
【００２０】
図７は、Ｗｅｂサービス２０１がメッセージ２０２を受信してからメッセージ２１１を送信するまでの一連の処理動作例を示すフローチャートである。メッセージ受信・解析部２０３は、メッセージ２０２を受信する（ステップ７０１）。次にメッセージ２０２に含まれる履歴情報ヘッダ３０４を読み込んで、ヘッダの解析を行い、得られた各送信履歴情報を履歴情報２０８に格納する（ステップ７０２）。次にサービス実行処理部２０４は、サービスを提供するために必要な処理を行う（ステップ７０３）。サービス処理終了後、送信先決定部２０５は、ルーティングテーブル２０６を参照して次のＷｅｂサービスの送信先を決定する（ステップ７０４）。次に経路検証部２０７は、経路検証ルール２０９と履歴情報２０８を参照し、ステップ７０３で決定した送信先が経路として正しいかどうか検証を行う（ステップ７０５）。検証の結果、正しい送信先と判定された場合、メッセージ生成・送信部２１０は、これまでの履歴情報２０８を読み込み、この履歴情報２０８にステップ７０４で決定した送信先を含む履歴情報を追加した履歴情報ヘッダ３０４を生成し、送信するメッセージ２１１を生成して、次の送信先にメッセージ２１１を送信する（ステップ７０６）。検証の結果、不正な送信先と判定された場合、経路誤り通知部２１２は、その旨を管理者端末２１３に通知する。
【００２１】
図７に示す処理動作によれば、ステップ７０５で、決定された送信先が正しいか否かを検証できるので、ルーティングテーブル２０６の設定が誤っている場合の経路ループを回避できる。
【００２２】
図８は、経路検証部２０７の処理動作例を示すフローチャートである。経路検証部２０７は、送信メッセージ２１１に含まれるボディ部３０３の内容からハッシュ関数を使用して、メッセージのダイジェスト値を計算する（ステップ８０１）。ここで送信メッセージ２１１に含まれるボディ部３０３の内容は、受信メッセージ２０２のボディ部３０３がそのまま使用されるか、またはサービス処理実行部２０４で行なったサービスの処理結果として生成されるものである。
【００２３】
次に経路検証部２０７は、履歴情報２０８の各レコードの送信元５０２、送信先５０３およびダイジェスト値５０４を参照し、送信元５０２が当該Ｗｅｂサービス２０１を表現するＵＲＬ（ホスト名、サービス名）と一致し、かつ送信先５０３が送信先決定部２０５で決定した次のＷｅｂサービスの送信先のＵＲＬと一致し、かつダイジェスト値５０４がステップ８０１で計算したダイジェスト値と一致している履歴情報２０８のレコード件数を調べる（ステップ８０２）。次にこのレコード件数が０件かどうか調べる（ステップ８０３）。ステップ８０２とステップ８０３の処理により、過去に通過した経路と同じでかつ、送信しようとしているメッセージのボディ部３０３も同一であるものが存在しているかどうかが判断できる。同一経路、同一メッセージが過去の履歴情報に存在する場合、ループする可能性があると判断する。
【００２４】
ステップ８０３で件数が０件、つまり同一経路、同一メッセージの履歴情報が存在しない場合は、経路検証部２０７は、ループしないと判断し送信決定部２０５が決定した送信先にメッセージを送信するように、メッセージ生成・送信部２１０に指示する（ステップ８０４）。一方、ステップ８０３で件数が０件ではない、つまり同一経路、同一メッセージの履歴情報が存在する場合は、ループすると判断し、あらかじめ指定された送信先にエラーメッセージを送信する（ステップ８０５）。あらかじめ指定された送信先は、リクエスタ１０１であっても良いし、あるいはエラーが発生したときの記録を収集する専用のＷｅｂサービスであっても良い。次に経路検証部２０７は、エラーが発生したことを管理者に通知するために経路誤り通知部２１２にメール送信を指示する（ステップ８０６）。ここで管理者に通知するための手段はメール送信に限らず、携帯端末への通知や専用の運用管理プログラムへの通知であっても構わない。
【００２５】
ステップ８０２において、同一経路だけでなく、同一内容のメッセージであるかどうかを検証しないと、経路ループの存在を検出したことにはならない。すなわち同一経路であってもメッセージの内容が異なる場合は、ループしない可能性が高いからである。たとえば図１のシステムの具体例において、複数のユーザを認証するために、対象サービス１０２は、複数回、認証サービス１０３を呼び出すことが考えられる。この場合、認証すべきユーザごとに、メッセージの内容は異なる。
【００２６】
図９は、経路検証ルール２０９を表現する一つの具体例であり、図８のフローチャートに示す処理動作をスクリプト言語で表したものである。
【００２７】
行９０１はステップ８０１に相当し、変数ＤＩＧＥＳＴにメッセージのボディ部のダイジェスト値の計算結果を格納する。行９０２はステップ８０２に相当し、履歴情報２０８より条件に一致する行の集合を変数ＬＩＳＴへ格納する。行９０３はステップ８０３に相当し、変数ＬＩＳＴに含まれる選択行の集合の件数が０件かどうか判定する。行９０４はステップ８０４に相当し、次のＷｅｂサービスへメッセージを送信する。行９０５はステップ８０５に相当し、指定された送信先へエラーメッセージを送信する。行９０６はステップ８０６に相当し、指定されたメールアドレスの管理者へメール送信する。
【００２８】
図９に示すように、経路検証ルール２０９をスクリプト言語形式で表現することにより、経路検証を柔軟に変更することができる。たとえば行９０３では件数が０件かどうか判定しているが、２件以下かどうかという条件に変更することによって、２回まで同一経路、同一メッセージのループを許可し、３回目の同一経路、同一メッセージは送信しないといった設定が可能になる。
【００２９】
図１０は、管理者端末２１３から経路検証ルール２０９を設定する設定画面例を示す。テキスト入力エリア１００１は、同一経路、同一メッセージのループを許可する回数を表しており、「０」の場合は、同一経路かつ同一メッセージの送信を許可しないことを表す。チェックボックス１００２はループするようなメッセージを検出した場合に、エラーメッセージを送信するかどうかを表し、チェックされている場合は、エラーメッセージを送信する。テキスト入力エリア１００３は、エラーメッセージの送信先を表し、送信先とするＷｅｂサービスのＵＲＬを入力する。チェックボックス１００４は、ループするようなメッセージを検出した場合に、管理者へメールを送信するかどうかを表し、チェックされている場合は、管理者へメールを送信する。テキスト入力エリア１００５は、管理者へのメールの送信先を表し、送信先とする管理者のメールアドレスを入力する。ボタン１００６を押すことによって、画面で設定した内容を経路検証ルール２０９へ反映して設定を終了する。ボタン１００７を押すことによって、画面で設定した内容を経路検証ルール２０９へ反映せずに設定を終了する。
【００３０】
図１０に示すように、経路検証ルール２０９を設定画面で設定できるようにすることで、管理者は、管理者端末２１３を介して容易に経路検証ルール２０９の設定・変更を行なうことができる。ただし経路検証ルール２０９の設定方法は、図１０の例に示すようなグラフィカルな設定画面に限ったものではなく、例えば図９に示したスクリプト形式の設定を直接編集するものであっても良い。
【００３１】
【発明の効果】
本発明によれば、経路ループを引き起こすようなメッセージの経路を自動的に検証することができるため、無駄な通信によるネットワーク負荷の増大を防止できる。
【図面の簡単な説明】
【図１】実施形態の複数のサービスが連携して処理を行うシステムの構成図である。
【図２】実施形態のサービス提供実体の構成図である。
【図３】Ｗｅｂサービスが送受信するメッセージの構成例を示す図である。
【図４】履歴情報ヘッダの具体例を示す図である。
【図５】履歴情報を表現するテーブルの構成例を示す図である。
【図６】ルーティングテーブルの構成例を示す図である。
【図７】Ｗｅｂサービスの処理動作例を示すフローチャートである。
【図８】経路検証部の処理動作例を示すフローチャートである。
【図９】経路検証ルールを表現する具体例を示す図である。
【図１０】経路検証ルールを設定する画面例を示す図である。
【符号の説明】
２０１：Ｗｅｂサービス、２０２：受信メッセージ、２０３：メッセージ受信・解析部、２０４：サービス処理実行部、２０５：送信先決定部、２０６：ルーティングテーブル、２０７：経路検証部、２０８：履歴情報、２０９：経路検証ルール、２１０：メッセージ生成・送信部、２１１：送信メッセージ、２１２：経路誤り通知部、２１３：管理者端末
【図１】
2005006139.tif 000003
【図２】
2005006139.tif 000004
【図３】
2005006139.tif 000005
【図４】
2005006139.tif 000006
【図５】
2005006139.tif 000007
【図６】
2005006139.tif 000008
【図７】
2005006139.tif 000009
【図８】
2005006139.tif 000010
【図９】
2005006139.tif 000011
【図１０】
2005006139.tif 000012