JP4034235B2

JP4034235B2 - Method and apparatus for detecting path loop in service

Info

Publication number: JP4034235B2
Application number: JP2003168804A
Authority: JP
Inventors: 裕奈良; 剛根本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-06-13
Filing date: 2003-06-13
Publication date: 2008-01-16
Anticipated expiration: 2023-06-13
Also published as: JP2005006139A

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークにおいて、分散している複数のサービス提供実体が連携して処理を行うようなＷｅｂサービスの技術に係わり、特にメッセージの経路を監視する技術に関する。
【０００２】
【従来の技術】
Ｗｅｂサービスの通信経路に関する技術として、マイクロソフト社が提唱しているＷＳ−Ｒｏｕｔｉｎｇは、メッセージの経路の定義仕様を規定している（非特許文献１参照）。また同じくマイクロソフト社が提唱しているＷＳ−Ｒｅｆｅｒｒａｌは、メッセージの経路を動的に構成するための仕様を規定している（非特許文献２参照）。
【０００３】
【非特許文献１】
マイクロソフト、ＷＳ−Ｒｏｕｔｉｎｇ仕様、２００１年１０月２３日
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp（原文）
http://www.microsoft.com/japan/msdn/webservices/dnsrvspec/ws-routing.asp（日本語訳）
【非特許文献２】
マイクロソフト、ＷＳ−Ｒｅｆｅｒｒａｌ仕様、２００１年１０月２３日
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-referral.asp（原文）
http://www.microsoft.com/japan/msdn/webservices/dnsrvspec/ws-referral.asp（日本語訳）
【０００４】
【発明が解決しようとする課題】
上記従来技術は、メッセージの経路の定義方法、経路の追加、変更方法などについて規定しているが、メッセージの経路の正当性については配慮していない。メッセージの経路が誤っていた場合、最悪メッセージの通過する経路がループし、無駄な通信によるネットワーク負荷の増大を引き起こすという問題があった。またこのような経路ループは容易に事象が発見できないため、回復に時間を要するという問題点があった。
【０００５】
本発明は、このような経路ループを検出し、無駄な通信によるネットワーク負荷の増大を防止することを目的とする。
【０００６】
【課題を解決するための手段】
上記目的を達成するために本発明は、Ｗｅｂサービスのメッセージにメッセージの経路を表現する経路履歴情報を付帯させるものである。本発明のＷｅｂサービスは、受信した経路履歴情報に基づいて経路の検証を行う技術を特徴とする。
【０００７】
【発明の実施の形態】
以下、本発明の実施形態について図面を用いて説明する。
【０００８】
図１は、本実施形態に係る複数のサービスが連携して処理を行うシステムの具体例を示す図である。この具体例は、リクエスタ１０１、対象サービス１０２、認証サービス１０３および認可サービス１０４が連携して処理を行う。対象サービス１０２、認証サービス１０３および認可サービス１０４は、サーバ計算機あるいはサーバ計算機上で実行されるサービス提供プログラムである。リクエスタ１０１はクライアント端末である。リクエスタ１０１は、対象サービス１０２が提供しているサービスを利用するために、対象サービス１０２にサービス要求のメッセージを送信する。このメッセージは、リクエスタ１０１が作成するものであっても良いし、他のサービスから転送されてきたメッセージ、またはＷｅｂブラウザから送信された情報を基にリクエスタ１０１が組み立てたメッセージであっても良い。対象サービス１０２は、リクエスタ１０１からサービス要求メッセージを受信し、サービスの要求者が正しいユーザであるかどうかの認証とサービスの要求者がサービスを利用可能かどうかの判定に基づいて認可を行うために、認証サービス１０３および認可サービス１０４にサービス要求メッセージを転送する前に経路情報を設定する。
【０００９】
対象サービス１０２は、設定した経路情報に基づき、まず認証サービス１０３に要求メッセージを転送する。認証サービス１０３は、対象サービス１０２から受信したメッセ−ジに含まれるサービス要求者の情報を基に認証を行う。認証が成功した場合は、認証サービス１０３は、認可サービス１０４に要求メッセージを転送する。認可サービス１０４は、認証サービス１０３から受信したメッセージに含まれるサービス要求者の情報と要求されているサービスの情報からサービスを許可するか否かを判定する。認可が成功した場合は、認可サービス１０４は、対象サービス１０２にサービス許可を示すメッセージを送信する。対象サービス１０２は、このメッセージを受信して、要求されているサービスを実行し、そのサービス処理の結果の情報をリクエスタ１０１に送信する。本具体例において、対象サービス１０２は、サービス要求メッセージまたは認可メッセージを受信して次の送信先を決定するときに、認証および認可がされていない場合は、認証サービス１０３へ、認証および認可されている場合はリクエスタ１０１へ送信するという決定を行っている。この送信先の決定は、一般的にＷｅｂサービスの管理者の経路の設定に基づいて行われるものであるが、この設定に誤りがあると予期しないメッセージの転送が行われてしまう。特に本具体例において、認証および認可がされている場合でも、再びサービス要求メッセージを認証サービス１０３へ転送するような設定が行われている場合、メッセージは認証サービス１０３および認可サービス１０４を経て再び対象サービス１０２に戻ってくる。この動作の繰り返しは、メッセージの転送についての経路ループを引き起こすことになる。本発明は、本具体例における対象サービス１０２やその他のＷｅｂサービスに適用することにより、このような経路ループを回避することを目的とする。
【００１０】
図２は、一実施例であるＷｅｂサービスを行うサーバ計算機あるいはサービス提供プログラムの構成を表す図である。このＷｅｂサービス２０１は、メッセージ２０２を受信して処理を行った後に、いずれかの送信先にメッセージ２１１を送信する。また管理者端末２１３は、このＷｅｂサービス２０１に接続され、管理者が操作する端末である。
【００１１】
Ｗｅｂサービス２０１は、メッセージ２０２を受信して解析を行うメッセージ受信・解析部２０３、メッセージが要求しているサービスを実行するサービス実行処理部２０４、次のメッセージ送信先を決定する送信先決定部２０５、決定した送信先から経路を検証する経路検証部２０７、メッセージ２１１を生成し、決定した送信先に送信するメッセージ生成・送信部２１０および経路の誤りが検出された場合、管理者端末２１３に通知を行なう経路誤り通知部２１２から構成される。送信先決定部２０５は、次の送信先を決定するために、あらかじめ管理者端末２１３より登録されたルーティングテーブル２０６の情報を参照する。また経路検証部２０７は、メッセージ受信・解析部２０３が作成した履歴情報２０８と、あらかじめ管理者端末２１３によって登録された経路検証ルール２０９とを突き合わせ、経路の検証を行う。
【００１２】
Ｗｅｂサービス２０１に係わるサーバ計算機は、ハードウェアとしてＣＰＵ、メモリ、ディスク装置などの外部記憶装置を備える。メッセージ受信・解析部２０３、サービス実行処理部２０４、送信先決定部２０５、経路検証部２０７およびメッセージ生成・送信部２１０は、メモリに格納され、ＣＰＵによって実行されるプログラムである。ルーティングテーブル２０６、履歴情報２０８および経路検証ルール２０９は、メモリ又は外部記憶装置に格納されるデータである。
【００１３】
図３は、Ｗｅｂサービス２０１が受信するメッセージ２０２あるいは送信するメッセージ２１１のデータ構成例を示す図である。メッセージ２０２，２１１は、ＸＭＬ（Extensible Markup Language）で表現されており、要素としてヘッダ部３０２とボディ部３０３を含む。ヘッダ部３０２は、主にＷｅｂサービスの制御データを含み、本発明で特徴とする履歴情報ヘッダ３０４とその他複数のヘッダ３０５で構成されている。ボディ部３０３は、Ｗｅｂサービスのサービス内容についての要求やその結果に関するデータが含まれる。
【００１４】
メッセージ受信・解析部２０３は、メッセージ２０２の受信時に履歴情報ヘッダ３０４の読み込みと解析を行う。またメッセージ受信・解析部２０３は、履歴情報ヘッダ３０４の解析結果を履歴情報２０８に格納する。またメッセージ生成・送信部２１０は、履歴情報２０８を読み込み、新たな履歴情報を加えて送信するメッセージ２１１の履歴情報ヘッダ３０４を生成する。
【００１５】
図４は、履歴情報ヘッダ３０４の具体例を示す図である。履歴情報ヘッダ３０４は、複数個の送信履歴情報を含む。図４の例では３個の送信履歴情報４０１，４０２および４０３を含んでいる。送信履歴情報は、Ｗｅｂサービスが次のＷｅｂサービスへメッセージを送信する時に履歴情報ヘッダ３０４に追加する情報である。送信履歴情報４０１は、送信時刻４０４、送信元情報４０５、送信先情報４０６及び送信メッセージのダイジェスト値４０７を含む。送信元情報４０５と送信先情報４０６は、ＵＲＬ（Universal Resource Location）の形式で表現され、ホスト名称やサービスを特定する情報を含む。また送信メッセージのダイジェスト値４０７は、メッセージ２０２，２１１のボディ部３０３の内容をハッシュ関数を使って求めた計算値である。ハッシュ関数としてはＳＨＡ−１（Secure Hash Algorithm 1）やＭＤ５(Message Digest 5)等を使用することができる。ダイジェスト値４０７は、ボディ部３０３が同じメッセージに対しては同じ値となり、ボディ部３０３が異なるメッセージに対しては異なる値となる。
【００１６】
図５は、履歴情報２０８を表現するテーブルのデータ構成例を示す図であり、メッセージ受信・解析部２０３が履歴情報ヘッダ３０４を解析した結果である。履歴情報２０８は、テーブル形式で表現され、テーブルの各行は、送信時刻５０１、送信元５０２、送信先５０３および送信メッセージのダイジェスト値５０４の各データ項目で構成される。送信時刻５０１は、履歴情報ヘッダ３０４の送信時刻４０４を表したものである。送信元５０２は送信元４０５を表したものである。送信先５０３は送信先４０６を表したものである。ダイジェスト値５０４はダイジェスト値４０７を表したものである。
【００１７】
履歴情報２０８をテーブル形式で表現することにより、経路検証部２０７は、テーブルのデータ項目を参照して経路検証をする。たとえばＷｅｂサービスの次の送信先が履歴情報２０８の送信先５０３の値と一致している行があれば、過去の経路で通過したＷｅｂサービスと同一のＷｅｂサービスに送信されると判断することができる。
【００１８】
図６は、ルーティングテーブル２０６を表現するテーブルのデータ構成例を示す図である。ルーティングテーブル２０６は、サービス種別６０１、条件６０２及び送信先６０３の各項目から構成される。サービス種別６０１は、リクエスタ１０１の指定したサービスの種別であり、最終の宛先を示す。条件６０２はメッセージを送信先６０３に転送する条件であり、送信先６０３はその送信先である。たとえばテーブルのレコード６０４は、対象サービス１０２がリクエスタ１０１から自サーバ宛のサービス要求を受信したがまだその要求者の認証をしていない場合に、認証サービス１０３にメッセージを転送する場合のルールである。レコード６０５は、リクエスタ１０１から最終宛先がホストＸであるメッセージを受信し、その処理が正常に終了した場合にホストＹに転送するルールを設定する。レコード６０６は、リクエスタ１０１から最終宛先がホストＸであるメッセージを受信し、その処理の結果、エラーとなった場合にホストＺに転送するルールを設定する。
【００１９】
ルーティングテーブル２０６の各レコードは、管理者端末２１３より登録される情報である。よって人為的なミス等により、不正な情報が登録される可能性がある。
【００２０】
図７は、Ｗｅｂサービス２０１がメッセージ２０２を受信してからメッセージ２１１を送信するまでの一連の処理動作例を示すフローチャートである。メッセージ受信・解析部２０３は、メッセージ２０２を受信する（ステップ７０１）。次にメッセージ２０２に含まれる履歴情報ヘッダ３０４を読み込んで、ヘッダの解析を行い、得られた各送信履歴情報を履歴情報２０８に格納する（ステップ７０２）。次にサービス実行処理部２０４は、サービスを提供するために必要な処理を行う（ステップ７０３）。サービス処理終了後、送信先決定部２０５は、ルーティングテーブル２０６を参照して次のＷｅｂサービスの送信先を決定する（ステップ７０４）。次に経路検証部２０７は、経路検証ルール２０９と履歴情報２０８を参照し、ステップ７０３で決定した送信先が経路として正しいかどうか検証を行う（ステップ７０５）。検証の結果、正しい送信先と判定された場合、メッセージ生成・送信部２１０は、これまでの履歴情報２０８を読み込み、この履歴情報２０８にステップ７０４で決定した送信先を含む履歴情報を追加した履歴情報ヘッダ３０４を生成し、送信するメッセージ２１１を生成して、次の送信先にメッセージ２１１を送信する（ステップ７０６）。検証の結果、不正な送信先と判定された場合、経路誤り通知部２１２は、その旨を管理者端末２１３に通知する。
【００２１】
図７に示す処理動作によれば、ステップ７０５で、決定された送信先が正しいか否かを検証できるので、ルーティングテーブル２０６の設定が誤っている場合の経路ループを回避できる。
【００２２】
図８は、経路検証部２０７の処理動作例を示すフローチャートである。経路検証部２０７は、送信メッセージ２１１に含まれるボディ部３０３の内容からハッシュ関数を使用して、メッセージのダイジェスト値を計算する（ステップ８０１）。ここで送信メッセージ２１１に含まれるボディ部３０３の内容は、受信メッセージ２０２のボディ部３０３がそのまま使用されるか、またはサービス処理実行部２０４で行なったサービスの処理結果として生成されるものである。
【００２３】
次に経路検証部２０７は、履歴情報２０８の各レコードの送信元５０２、送信先５０３およびダイジェスト値５０４を参照し、送信元５０２が当該Ｗｅｂサービス２０１を表現するＵＲＬ(ホスト名、サービス名)と一致し、かつ送信先５０３が送信先決定部２０５で決定した次のＷｅｂサービスの送信先のＵＲＬと一致し、かつダイジェスト値５０４がステップ８０１で計算したダイジェスト値と一致している履歴情報２０８のレコード件数を調べる(ステップ８０２)。次にこのレコード件数が０件かどうか調べる（ステップ８０３）。ステップ８０２とステップ８０３の処理により、過去に通過した経路と同じでかつ、送信しようとしているメッセージのボディ部３０３も同一であるものが存在しているかどうかが判断できる。同一経路、同一メッセージが過去の履歴情報に存在する場合、ループする可能性があると判断する。
【００２４】
ステップ８０３で件数が０件、つまり同一経路、同一メッセージの履歴情報が存在しない場合は、経路検証部２０７は、ループしないと判断し送信決定部２０５が決定した送信先にメッセージを送信するように、メッセージ生成・送信部２１０に指示する(ステップ８０４)。一方、ステップ８０３で件数が０件ではない、つまり同一経路、同一メッセージの履歴情報が存在する場合は、ループすると判断し、あらかじめ指定された送信先にエラーメッセージを送信する（ステップ８０５）。あらかじめ指定された送信先は、リクエスタ１０１であっても良いし、あるいはエラーが発生したときの記録を収集する専用のＷｅｂサービスであっても良い。次に経路検証部２０７は、エラーが発生したことを管理者に通知するために経路誤り通知部２１２にメール送信を指示する（ステップ８０６）。ここで管理者に通知するための手段はメール送信に限らず、携帯端末への通知や専用の運用管理プログラムへの通知であっても構わない。
【００２５】
ステップ８０２において、同一経路だけでなく、同一内容のメッセージであるかどうかを検証しないと、経路ループの存在を検出したことにはならない。すなわち同一経路であってもメッセージの内容が異なる場合は、ループしない可能性が高いからである。たとえば図１のシステムの具体例において、複数のユーザを認証するために、対象サービス１０２は、複数回、認証サービス１０３を呼び出すことが考えられる。この場合、認証すべきユーザごとに、メッセージの内容は異なる。
【００２６】
図９は、経路検証ルール２０９を表現する一つの具体例であり、図８のフローチャートに示す処理動作をスクリプト言語で表したものである。
【００２７】
行９０１はステップ８０１に相当し、変数ＤＩＧＥＳＴにメッセージのボディ部のダイジェスト値の計算結果を格納する。行９０２はステップ８０２に相当し、履歴情報２０８より条件に一致する行の集合を変数ＬＩＳＴへ格納する。行９０３はステップ８０３に相当し、変数ＬＩＳＴに含まれる選択行の集合の件数が０件かどうか判定する。行９０４はステップ８０４に相当し、次のＷｅｂサービスへメッセージを送信する。行９０５はステップ８０５に相当し、指定された送信先へエラーメッセージを送信する。行９０６はステップ８０６に相当し、指定されたメールアドレスの管理者へメール送信する。
【００２８】
図９に示すように、経路検証ルール２０９をスクリプト言語形式で表現することにより、経路検証を柔軟に変更することができる。たとえば行９０３では件数が０件かどうか判定しているが、２件以下かどうかという条件に変更することによって、２回まで同一経路、同一メッセージのループを許可し、３回目の同一経路、同一メッセージは送信しないといった設定が可能になる。
【００２９】
図１０は、管理者端末２１３から経路検証ルール２０９を設定する設定画面例を示す。テキスト入力エリア１００１は、同一経路、同一メッセージのループを許可する回数を表しており、「０」の場合は、同一経路かつ同一メッセージの送信を許可しないことを表す。チェックボックス１００２はループするようなメッセージを検出した場合に、エラーメッセージを送信するかどうかを表し、チェックされている場合は、エラーメッセージを送信する。テキスト入力エリア１００３は、エラーメッセージの送信先を表し、送信先とするＷｅｂサービスのＵＲＬを入力する。チェックボックス１００４は、ループするようなメッセージを検出した場合に、管理者へメールを送信するかどうかを表し、チェックされている場合は、管理者へメールを送信する。テキスト入力エリア１００５は、管理者へのメールの送信先を表し、送信先とする管理者のメールアドレスを入力する。ボタン１００６を押すことによって、画面で設定した内容を経路検証ルール２０９へ反映して設定を終了する。ボタン１００７を押すことによって、画面で設定した内容を経路検証ルール２０９へ反映せずに設定を終了する。
【００３０】
図１０に示すように、経路検証ルール２０９を設定画面で設定できるようにすることで、管理者は、管理者端末２１３を介して容易に経路検証ルール２０９の設定・変更を行なうことができる。ただし経路検証ルール２０９の設定方法は、図１０の例に示すようなグラフィカルな設定画面に限ったものではなく、例えば図９に示したスクリプト形式の設定を直接編集するものであっても良い。
【００３１】
【発明の効果】
本発明によれば、経路ループを引き起こすようなメッセージの経路を自動的に検証することができるため、無駄な通信によるネットワーク負荷の増大を防止できる。
【図面の簡単な説明】
【図１】実施形態の複数のサービスが連携して処理を行うシステムの構成図である。
【図２】実施形態のサービス提供実体の構成図である。
【図３】Ｗｅｂサービスが送受信するメッセージの構成例を示す図である。
【図４】履歴情報ヘッダの具体例を示す図である。
【図５】履歴情報を表現するテーブルの構成例を示す図である。
【図６】ルーティングテーブルの構成例を示す図である。
【図７】Ｗｅｂサービスの処理動作例を示すフローチャートである。
【図８】経路検証部の処理動作例を示すフローチャートである。
【図９】経路検証ルールを表現する具体例を示す図である。
【図１０】経路検証ルールを設定する画面例を示す図である。
【符号の説明】
２０１：Ｗｅｂサービス、２０２：受信メッセージ、２０３：メッセージ受信・解析部、２０４：サービス処理実行部、２０５：送信先決定部、２０６：ルーティングテーブル、２０７：経路検証部、２０８：履歴情報、２０９：経路検証ルール、２１０：メッセージ生成・送信部、２１１：送信メッセージ、２１２：経路誤り通知部、２１３：管理者端末[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a Web service technology in which a plurality of distributed service providing entities cooperate in a computer network, and more particularly to a technology for monitoring a message path.
[0002]
[Prior art]
WS-Routing advocated by Microsoft as a technology related to communication paths of Web services defines the definition specifications of message paths (see Non-Patent Document 1). Similarly, WS-Reference proposed by Microsoft Corporation defines specifications for dynamically configuring message paths (see Non-Patent Document 2).
[0003]
[Non-Patent Document 1]
Microsoft, WS-Routing specification, October 23, 2001
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp¶
http://www.microsoft.com/japan/msdn/webservices/dnsrvspec/ws-routing.asp
[Non-Patent Document 2]
Microsoft, WS-Reference specification, October 23, 2001
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-referral.asp¶
http://www.microsoft.com/japan/msdn/webservices/dnsrvspec/ws-referral.asp
[0004]
[Problems to be solved by the invention]
The above-described prior art stipulates a message path definition method, a path addition / change method, and the like, but does not consider the validity of the message path. When the message path is wrong, the path through which the worst message passes loops, causing a problem of increasing the network load due to useless communication. In addition, such a route loop has a problem that it takes time to recover because an event cannot be easily found.
[0005]
An object of the present invention is to detect such a route loop and prevent an increase in network load due to useless communication.
[0006]
[Means for Solving the Problems]
In order to achieve the above object, the present invention attaches route history information representing a message route to a Web service message. The Web service of the present invention is characterized by a technique for verifying a route based on the received route history information.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0008]
FIG. 1 is a diagram illustrating a specific example of a system in which a plurality of services according to the present embodiment perform processing in cooperation. In this specific example, the requester 101, the target service 102, the authentication service 103, and the authorization service 104 perform processing in cooperation. The target service 102, the authentication service 103, and the authorization service 104 are a server computer or a service providing program that is executed on the server computer. The requester 101 is a client terminal. The requester 101 transmits a service request message to the target service 102 in order to use the service provided by the target service 102. This message may be created by the requester 101, or may be a message transferred from another service or a message assembled by the requester 101 based on information transmitted from a Web browser. The target service 102 receives the service request message from the requester 101, and performs authorization based on authentication of whether the service requester is a correct user and determination of whether the service requester can use the service. The path information is set before the service request message is transferred to the authentication service 103 and the authorization service 104.
[0009]
The target service 102 first transfers a request message to the authentication service 103 based on the set route information. The authentication service 103 performs authentication based on the information of the service requester included in the message received from the target service 102. If the authentication is successful, the authentication service 103 transfers the request message to the authorization service 104. The authorization service 104 determines whether to permit the service from the information of the service requester included in the message received from the authentication service 103 and the information of the requested service. If the authorization is successful, the authorization service 104 transmits a message indicating service permission to the target service 102. The target service 102 receives this message, executes the requested service, and transmits information on the result of the service processing to the requester 101. In this specific example, when the target service 102 receives the service request message or the authorization message and determines the next transmission destination, if the authentication and authorization are not performed, the target service 102 is authenticated and authorized to the authentication service 103. If so, it is determined to transmit to the requester 101. The determination of the transmission destination is generally performed based on the route setting of the administrator of the Web service, but if this setting is incorrect, an unexpected message is transferred. In particular, in this specific example, even if authentication and authorization are performed, if the setting is made so that the service request message is transferred to the authentication service 103 again, the message is again processed through the authentication service 103 and the authorization service 104. Return to service 102. Repeating this operation will cause a path loop for message transfer. An object of the present invention is to avoid such a route loop by being applied to the target service 102 and other Web services in this specific example.
[0010]
FIG. 2 is a diagram illustrating a configuration of a server computer or a service providing program that performs a Web service according to an embodiment. The Web service 201 transmits the message 211 to any one of the transmission destinations after receiving and processing the message 202. The administrator terminal 213 is a terminal connected to the Web service 201 and operated by the administrator.
[0011]
The Web service 201 receives a message 202 and analyzes it, a message reception / analysis unit 203, a service execution processing unit 204 that executes a service requested by the message, and a transmission destination determination unit 205 that determines a next message transmission destination. The path verification unit 207 that verifies the path from the determined transmission destination, the message 211 is generated, the message generation / transmission unit 210 that transmits the message to the determined transmission destination, and an error in the path are detected, the administrator terminal 213 is notified Is constituted by a route error notification unit 212. The transmission destination determination unit 205 refers to the information in the routing table 206 registered in advance from the administrator terminal 213 in order to determine the next transmission destination. Also, the route verification unit 207 matches the history information 208 created by the message reception / analysis unit 203 with the route verification rule 209 registered in advance by the administrator terminal 213, and performs route verification.
[0012]
A server computer related to the Web service 201 includes an external storage device such as a CPU, a memory, and a disk device as hardware. The message reception / analysis unit 203, service execution processing unit 204, transmission destination determination unit 205, path verification unit 207, and message generation / transmission unit 210 are programs stored in a memory and executed by the CPU. The routing table 206, history information 208, and route verification rule 209 are data stored in a memory or an external storage device.
[0013]
FIG. 3 is a diagram illustrating a data configuration example of the message 202 received by the Web service 201 or the message 211 to be transmitted. The messages 202 and 211 are expressed in XML (Extensible Markup Language) and include a header portion 302 and a body portion 303 as elements. The header section 302 mainly includes control data of the Web service, and is composed of a history information header 304 and a plurality of other headers 305 that are characteristic of the present invention. The body part 303 includes a request for the service content of the Web service and data related to the result.
[0014]
The message reception / analysis unit 203 reads and analyzes the history information header 304 when the message 202 is received. The message reception / analysis unit 203 stores the analysis result of the history information header 304 in the history information 208. The message generation / transmission unit 210 reads the history information 208 and generates a history information header 304 of the message 211 to be transmitted by adding new history information.
[0015]
FIG. 4 is a diagram illustrating a specific example of the history information header 304. The history information header 304 includes a plurality of transmission history information. In the example of FIG. 4, three pieces of transmission history information 401, 402, and 403 are included. The transmission history information is information added to the history information header 304 when a Web service transmits a message to the next Web service. The transmission history information 401 includes a transmission time 404, transmission source information 405, transmission destination information 406, and a digest value 407 of the transmission message. The transmission source information 405 and the transmission destination information 406 are expressed in a URL (Universal Resource Location) format, and include information for specifying a host name and a service. The digest value 407 of the transmission message is a calculated value obtained by using the hash function for the contents of the body part 303 of the messages 202 and 211. As a hash function, SHA-1 (Secure Hash Algorithm 1), MD5 (Message Digest 5), or the like can be used. The digest value 407 is the same value for messages with the same body part 303 and different values for messages with different body parts 303.
[0016]
FIG. 5 is a diagram illustrating a data configuration example of a table expressing the history information 208, and is a result of analysis of the history information header 304 by the message reception / analysis unit 203. The history information 208 is expressed in a table format, and each row of the table includes data items of a transmission time 501, a transmission source 502, a transmission destination 503, and a digest value 504 of a transmission message. The transmission time 501 represents the transmission time 404 of the history information header 304. A transmission source 502 represents the transmission source 405. A transmission destination 503 represents the transmission destination 406. The digest value 504 represents the digest value 407.
[0017]
By expressing the history information 208 in a table format, the route verification unit 207 performs route verification by referring to the data items in the table. For example, if there is a line in which the next transmission destination of the Web service matches the value of the transmission destination 503 of the history information 208, it may be determined that the transmission is made to the same Web service as the Web service passed through the past route. it can.
[0018]
FIG. 6 is a diagram illustrating a data configuration example of a table representing the routing table 206. The routing table 206 includes items of a service type 601, a condition 602, and a transmission destination 603. The service type 601 is the type of service designated by the requester 101 and indicates the final destination. The condition 602 is a condition for transferring a message to the transmission destination 603, and the transmission destination 603 is the transmission destination. For example, the table record 604 is a rule for transferring a message to the authentication service 103 when the target service 102 receives a service request addressed to the server from the requester 101 but has not yet authenticated the requester. . The record 605 sets a rule to be transferred to the host Y when the message whose final destination is the host X is received from the requester 101 and the processing is normally completed. A record 606 sets a rule for receiving a message whose final destination is the host X from the requester 101 and transferring it to the host Z when an error occurs as a result of the processing.
[0019]
Each record of the routing table 206 is information registered from the administrator terminal 213. Therefore, there is a possibility that illegal information is registered due to human error.
[0020]
FIG. 7 is a flowchart illustrating a series of processing operation examples from when the Web service 201 receives the message 202 to when the Web service 201 transmits the message 211. The message receiving / analyzing unit 203 receives the message 202 (step 701). Next, the history information header 304 included in the message 202 is read, the header is analyzed, and the obtained transmission history information is stored in the history information 208 (step 702). Next, the service execution processing unit 204 performs processing necessary for providing the service (step 703). After the service processing ends, the transmission destination determination unit 205 determines the transmission destination of the next Web service with reference to the routing table 206 (Step 704). Next, the path verification unit 207 refers to the path verification rule 209 and the history information 208, and verifies whether the transmission destination determined in step 703 is correct as a path (step 705). As a result of the verification, when it is determined that the destination is correct, the message generation / transmission unit 210 reads the history information 208 so far and adds history information including the destination determined in step 704 to the history information 208. An information header 304 is generated, a message 211 to be transmitted is generated, and the message 211 is transmitted to the next transmission destination (step 706). As a result of the verification, when it is determined that the destination is an unauthorized destination, the path error notification unit 212 notifies the administrator terminal 213 to that effect.
[0021]
According to the processing operation shown in FIG. 7, since it is possible to verify whether or not the determined transmission destination is correct in step 705, a route loop when the setting of the routing table 206 is incorrect can be avoided.
[0022]
FIG. 8 is a flowchart illustrating an example of processing operation of the path verification unit 207. The path verification unit 207 calculates the digest value of the message using the hash function from the contents of the body part 303 included in the transmission message 211 (step 801). Here, the content of the body part 303 included in the transmission message 211 is generated as a result of the service processing performed by the service processing execution unit 204 using the body part 303 of the received message 202 as it is.
[0023]
Next, the path verification unit 207 refers to the transmission source 502, transmission destination 503, and digest value 504 of each record of the history information 208, and the URL (host name, service name) that the transmission source 502 represents the Web service 201 and In the history information 208, the transmission destination 503 matches the URL of the transmission destination of the next Web service determined by the transmission destination determination unit 205, and the digest value 504 matches the digest value calculated in step 801. The number of records is checked (step 802). Next, it is checked whether the number of records is 0 (step 803). By the processing in step 802 and step 803, it can be determined whether there is an existing message that is the same as the route that has passed in the past and that has the same body part 303 of the message to be transmitted. When the same route and the same message exist in the past history information, it is determined that there is a possibility of looping.
[0024]
When the number of cases is 0 in step 803, that is, when there is no history information of the same route and the same message, the route verification unit 207 determines that no loop occurs and transmits the message to the transmission destination determined by the transmission determination unit 205. The message generation / transmission unit 210 is instructed (step 804). On the other hand, if the number of cases is not 0 in step 803, that is, if there is history information of the same route and the same message, it is determined that the loop will occur, and an error message is sent to a destination designated in advance (step 805). The transmission destination designated in advance may be the requester 101 or a dedicated Web service that collects records when an error occurs. Next, the path verification unit 207 instructs the path error notification unit 212 to send an email in order to notify the administrator that an error has occurred (step 806). Here, the means for notifying the administrator is not limited to mail transmission, but may be notification to a portable terminal or notification to a dedicated operation management program.
[0025]
If it is not verified in step 802 whether the messages have the same content as well as the same route, the presence of a route loop is not detected. That is, if the message contents are different even in the same route, there is a high possibility that the message does not loop. For example, in the specific example of the system of FIG. 1, in order to authenticate a plurality of users, the target service 102 may call the authentication service 103 a plurality of times. In this case, the content of the message is different for each user to be authenticated.
[0026]
FIG. 9 is one specific example of expressing the route verification rule 209, and represents the processing operation shown in the flowchart of FIG. 8 in a script language.
[0027]
A row 901 corresponds to step 801, and the calculation result of the digest value of the body part of the message is stored in the variable DIGEST. A row 902 corresponds to the step 802, and a set of rows matching the condition from the history information 208 is stored in the variable LIST. A row 903 corresponds to step 803, and it is determined whether or not the number of selected rows included in the variable LIST is zero. Line 904 corresponds to step 804, and transmits a message to the next Web service. A line 905 corresponds to step 805 and transmits an error message to the designated transmission destination. Line 906 corresponds to step 806, and mail is transmitted to the administrator of the designated mail address.
[0028]
As shown in FIG. 9, the route verification can be flexibly changed by expressing the route verification rule 209 in a script language format. For example, in row 903, it is determined whether or not the number of cases is 0, but by changing to the condition of whether or not the number is 2 or less, the same route and the same message loop are permitted up to 2 times, and the same route is the same as the third Settings such as not sending messages are possible.
[0029]
FIG. 10 shows an example of a setting screen for setting the route verification rule 209 from the administrator terminal 213. The text input area 1001 represents the number of times that the same route and the same message are permitted to be looped, and “0” represents that transmission of the same route and the same message is not permitted. A check box 1002 indicates whether an error message is to be transmitted when a looping message is detected. If the message is checked, an error message is transmitted. A text input area 1003 represents a transmission destination of the error message, and inputs a URL of a Web service as a transmission destination. A check box 1004 indicates whether or not to send an email to the administrator when a looping message is detected. If the message is checked, the email is sent to the administrator. A text input area 1005 represents a mail transmission destination to the administrator, and inputs the mail address of the administrator as the transmission destination. By pressing a button 1006, the content set on the screen is reflected in the route verification rule 209, and the setting is completed. By pressing a button 1007, the setting is finished without reflecting the contents set on the screen to the route verification rule 209.
[0030]
As shown in FIG. 10, by allowing the route verification rule 209 to be set on the setting screen, the administrator can easily set / change the route verification rule 209 via the administrator terminal 213. However, the setting method of the route verification rule 209 is not limited to the graphical setting screen as shown in the example of FIG. 10, and for example, the script format setting shown in FIG. 9 may be directly edited.
[0031]
【The invention's effect】
According to the present invention, since it is possible to automatically verify a message path that causes a path loop, it is possible to prevent an increase in network load due to useless communication.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of a system in which a plurality of services according to an embodiment perform processing in cooperation.
FIG. 2 is a configuration diagram of a service providing entity according to the embodiment.
FIG. 3 is a diagram illustrating a configuration example of a message transmitted / received by a Web service.
FIG. 4 is a diagram illustrating a specific example of a history information header.
FIG. 5 is a diagram illustrating a configuration example of a table expressing history information.
FIG. 6 is a diagram illustrating a configuration example of a routing table.
FIG. 7 is a flowchart illustrating an example of processing operation of a Web service.
FIG. 8 is a flowchart illustrating an example of processing operation of a path verification unit.
FIG. 9 is a diagram illustrating a specific example of expressing a route verification rule.
FIG. 10 is a diagram illustrating an example of a screen for setting a route verification rule.
[Explanation of symbols]
201: Web service, 202: received message, 203: message reception / analysis unit, 204: service processing execution unit, 205: transmission destination determination unit, 206: routing table, 207: route verification unit, 208: history information, 209: Route verification rule, 210: Message generation / transmission unit, 211: Transmission message, 212: Route error notification unit, 213: Administrator terminal

Claims

Information processing including a plurality of service processing units capable of communication and including the service processing unit and a storage device in a service processing system that provides services to a service requester in cooperation with messages transmitted and received between the service processing units In the device loop detection method ,
The service processing unit
A body part including a request relating to service contents of service processing and a processing result thereof, route information indicating a route of the processed service processing part, and process identification information relating to a body part of the message processed in the processed service process Receiving a message having a header portion including path history information having the information stored in the storage device ;
Executing a process related to service provision with reference to the stored message ;
A destination of a message to be transmitted corresponding to the stored message is determined with reference to a routing table for managing communication with other service processing units stored in advance in a storage device, and transmitted to the destination Generating a message to be
The processing identification information generated from the determined transmission destination and the body part of the generated message is compared with the transmission destination and the processing identification information included in the stored route history information to confirm the validity of the transmission destination. A determining step;
A route loop in a service , comprising : the message to be transmitted; and route history information obtained by adding a route portion of the service processing unit to the route history information to the determined destination. Detection method.

2. The route loop detection method for a service according to claim 1, wherein the step of determining the validity of the destination is determined based on a rule for route verification.

3. The route loop detection method for a service according to claim 2, wherein the rule is created and changed via a rule setting screen.

2. The route loop detection method for a service according to claim 1 , wherein the process identification information is a digest value of the body part .

2. The route loop detection method for a service according to claim 1, wherein the step of determining the legitimacy of the destination determines that the passage of the same route and the same content message up to a predetermined number of times is correct.

Further, when the destination is determined to be incorrect, path loop detection method in the service according to claim 1, characterized by the step of sending an error message to the other service providing program specified.

Further when said destination is determined to be incorrect, path loop detection method in the service according to claim 1, characterized by the step of sending an error message to the administrator terminal.

A server computer comprising a plurality of service processing units capable of communication and including the service processing unit and a storage device in a service processing system that provides services to a service requester in cooperation with messages transmitted and received between the service processing units in, the server computer,
A body part including a request relating to service contents of service processing and a processing result thereof, route information indicating a route of the processed service processing part, and process identification information relating to a body part of the message processed in the processed service process A function of receiving a message having a header portion including path history information having the information and storing the message in the storage device ,
A function of referring to the stored message and executing processing related to service provision;
A destination of a message to be transmitted corresponding to the stored message is determined with reference to a routing table for managing communication with other service processing units stored in advance in a storage device, and transmitted to the destination The ability to generate messages to be
The processing identification information generated from the determined transmission destination and the body part of the generated message is compared with the transmission destination and the processing identification information included in the stored route history information to confirm the validity of the transmission destination. A service providing program for realizing a function of determining, and a function of transmitting the message to be transmitted and route history information obtained by adding a route portion of the service processing unit to the route history information to the determined transmission destination .

A server computer comprising a plurality of service processing units capable of communication and including the service processing unit and a storage device in a service processing system that provides services to a service requester in cooperation with messages transmitted and received between the service processing units In
The service processing unit
A body part including a request relating to service contents of service processing and a processing result thereof, route information indicating a route of the processed service processing part, and process identification information relating to a body part of the message processed in the processed service process Means for receiving a message having a header portion including path history information having the information and storing the message in the storage device ;
Means for referring to the stored message and executing processing related to service provision;
A destination of a message to be transmitted corresponding to the stored message is determined with reference to a routing table for managing communication with other service processing units stored in advance in a storage device, and transmitted to the destination Means for generating a message to be
The processing identification information generated from the determined transmission destination and the body part of the generated message is compared with the transmission destination and the processing identification information included in the stored route history information to confirm the validity of the transmission destination. Means for determining;
A route loop is detected, characterized by comprising means for transmitting the message to be transmitted and route history information obtained by adding the route of the service processing unit to the route history information to the determined destination. Server computer.

In a service processing system having a plurality of communicable service processing units and providing services to a service requester in cooperation with messages transmitted and received between the service processing units ,
The service processing unit
A body part including a request relating to service contents of service processing and a processing result thereof, route information indicating a route of the processed service processing part, and process identification information relating to a body part of the message processed in the processed service process Means for receiving a message having a header portion including path history information having and storing the message in a storage device ;
Means for referring to the stored message and executing processing related to service provision;
A destination of a message to be transmitted corresponding to the stored message is determined with reference to a routing table for managing communication with other service processing units stored in advance in a storage device, and transmitted to the destination Means for generating a message to be
The processing identification information generated from the determined transmission destination and the body part of the generated message is compared with the transmission destination and the processing identification information included in the stored route history information to confirm the validity of the transmission destination. Means for determining;
A route loop comprising : the message to be transmitted; and route history information obtained by adding a route portion of the service processing unit being executed to the route history information to the determined destination. Detecting system.