(57)【要約】【課題】  送信装置からのデータに関して、受信装置でデータ解析等を行う前に負荷評価を行うことを課題とする。【解決手段】  送信装置から受信装置に送信するデータに関して、送信装置あるいは受信装置において、データの検索対象範囲内でキーワードが所定回数以上存在したか否かなどを判定することにより、データの受信装置に対する負荷を、従来のデータ処理よりも前に、データの構造等に関係なく高速で評価することを特徴とする。【選択図】      図１
2006155123.tif 000002
【特許請求の範囲】
【請求項１】
送信装置からのデータを受信する受信装置によるデータの事前負荷評価方法であって、
前記受信装置は演算手段と記憶手段とを有し、
前記記憶手段は、データの検索条件として、データの検索対象範囲、キーワード及び所定回数を記憶し、
前記演算手段は、前記送信装置からデータを受信するステップと、受信したデータに関して前記検索対象範囲において前記キーワードが前記所定回数以上存在するか否か判定するステップと、前記キーワードが前記所定回数以上存在したときに前記受信装置への負荷が大きいと判断するステップとを実行することを特徴とするデータの事前負荷評価方法。
【請求項２】
送信装置からのデータを受信する受信装置によるデータの事前負荷評価方法であって、
前記受信装置は演算手段と記憶手段とを有し、
前記記憶手段は、データの検索条件として、データの検索対象範囲及びキーワードを記憶し、
前記演算手段は、前記送信装置からデータを受信するステップと、受信したデータに関して前記検索対象範囲において前記キーワードが存在するか否か判定するステップと、前記キーワードが存在しなかったときに前記受信装置への負荷が大きいと判断するステップとを実行することを特徴とするデータの事前負荷評価方法。
【請求項３】
送信装置からのデータを受信する受信装置によるデータの事前負荷評価方法であって、
前記受信装置は演算手段と記憶手段とを有し、
前記記憶手段は、データの検索条件として、データの検索対象範囲、第一キーワード、第二キーワード及び所定長を記憶し、
前記演算手段は、前記送信装置からデータを受信するステップと、受信したデータに関して前記検索対象範囲において前記第一キーワードが存在するか否か判定するステップと、前記第一キーワードが存在したときに前記所定長以内に第二キーワードが存在するか否か判定するステップと、前記所定長以内に第二キーワードが存在しなかったときに前記受信装置への負荷が大きいと判断するステップとを実行することを特徴とするデータの事前負荷評価方法。
【請求項４】
送信装置からのデータを受信する受信装置によるデータの事前負荷評価方法であって、
前記受信装置は演算手段と記憶手段とを有し、
前記記憶手段は、データの検索条件として、データの検索対象範囲、第一キーワード、第二キーワード、第一所定回数及び第二所定回数を記憶し、
前記演算手段は、前記送信装置からデータを受信するステップと、受信したデータに関して前記検索対象範囲において前記第一キーワードが存在するか否か判定するステップと、前記第一キーワードが存在したときに次の前記第一キーワードまでに前記第二キーワードが前記第一所定回数以上存在するか否かを判定するステップと、前ステップで前記第二キーワードが前記第一所定回数以上存在した回数が第二所定回数以上か否かを判定するステップと、前ステップでその回数が第二所定回数以上であったときに前記受信装置への負荷が大きいと判断するステップとを実行することを特徴とするデータの事前負荷評価方法。
【請求項５】
前記記憶手段は、さらに、受信データによる前記受信装置への負荷に関して、受信データごとの前記受信装置への負荷値を含む過去の実行結果、負荷上限値及び負荷下限値を記憶し、
前記演算手段は、所定のタイミングで、前記過去の実行結果における前記受信装置への負荷値の最大値が前記負荷下限値から前記負荷上限値までの間に含まれるか否か判定するステップと、前ステップで含まれないと判定されたときに前記検索条件が妥当でないと判断するステップと、前ステップで前記検索条件が妥当でないと判断されたときに前記検索条件のうち少なくとも１つを変更するステップとを実行することを特徴とする請求項１から請求項４までのいずれか１項に記載のデータの事前負荷評価方法。
【請求項６】
データを送信する送信装置と、前記送信装置からのデータを受信する受信装置とを含んで構成されるデータの事前負荷評価システムによるデータの事前負荷評価方法であって、
前記送信装置は送信側演算手段と送信側記憶手段とを有し、
前記送信側記憶手段は、データの検索条件として、データの検索対象範囲、キーワード及び所定回数を記憶し、
前記送信側演算手段は、前記受信装置への送信予定データに関して前記検索対象範囲において前記キーワードが前記所定回数以上存在したか否かを検索するステップと、その検索結果を前記受信装置に送信するステップとを実行し、
前記受信装置は受信側演算手段と受信側記憶手段とを有し、
前記受信側記憶手段は、前記検索結果に対応する方法である対応方法情報を記憶し、
前記受信側演算手段は、前記送信装置から前記検索結果を受信するステップと、前記検索結果と前記対応方法情報に基いて前記送信予定データに対する対応を行うステップとを実行することを特徴とするデータの事前負荷評価方法。
【請求項７】
送信装置からのデータを受信する受信装置によるデータの事前負荷評価システムであって、
前記受信装置は演算手段と記憶手段とを有し、
前記記憶手段は、データの検索条件として、データの検索対象範囲、キーワード及び所定回数を記憶し、
前記演算手段は、前記送信装置から受信したデータに関して、前記検索対象範囲において前記キーワードが前記所定回数以上存在したか否かを判定することによって負荷評価を行うことを特徴とするデータの事前負荷評価システム。
【請求項８】
前記記憶手段は、さらに、受信データによる前記受信装置への負荷に関して、受信データごとの前記受信装置への負荷値を含む過去の実行結果、負荷上限値及び負荷下限値を記憶し、
前記演算手段は、所定のタイミングで、前記過去の実行結果における前記受信装置への負荷値の最大値が前記負荷下限値から前記負荷上限値までの間に含まれるか否か判定し、含まれない場合に、前記所定回数を変更することを特徴とする請求項７に記載のデータの事前負荷評価システム。
【請求項９】
データを送信する送信装置と、前記送信装置からのデータを受信する受信装置とを含んで構成されるデータの事前負荷評価システムであって、
前記送信装置は送信側演算手段と送信側記憶手段とを有し、
前記送信側記憶手段は、データの検索条件として、データの検索対象範囲、キーワード及び所定回数を記憶し、
前記送信側演算手段は、前記受信装置への送信予定データに関して、前記検索対象範囲において前記キーワードが前記所定回数以上存在したか否かを検索して、その検索結果を前記受信装置に送信し、
前記受信装置は受信側演算手段と受信側記憶手段とを有し、
前記受信側記憶手段は、前記検索結果に対応する方法である対応方法情報を記憶し、
前記受信側演算手段は、受信した前記検索結果と前記対応方法情報に基いて前記送信予定データに対する対応を行うことを特徴とするデータの事前負荷評価システム。
【請求項１０】
請求項１から請求項６までのいずれか１項に記載のデータの事前負荷評価方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信したデータあるいは受信する予定のデータについて、従来の解析等の処理をする前に行う負荷評価の方法、システム及びそのプログラムに関する。
【背景技術】
【０００２】
インターネットを介したシステム間の通信では、ＸＭＬ（Extensible Markup Language）で記述されたメッセージ（データ）を交換するＷｅｂサービスが多く実現されている（非特許文献１参照）。
そして、Ｗｅｂサービスでは、前記したように、メッセージはＸＭＬで記述されており、メッセージ交換の形式に関するフォーマットはＳＯＡＰ（Simple Object Access Protocol）に基づいたものが利用されている。また、通信するメッセージ（ＳＯＡＰメッセージ）の内容は、ＷＳＤＬ（Web Services Description Languege）形式及びＸＭＬスキーマにより定義される。
【０００３】
Ｗｅｂサービスで利用されるＸＭＬデータは、データ構造を表すために、階層構造を持つタグ情報を利用して表現される。そのため、メッセージ受信側はＸＭＬデータの解析処理が必要であり、また、バイナリデータによる通信に比べて処理が複雑であり、解析処理に時間がかかる。そして、解析処理の時間は、通信データ全体のデータ量にも影響されるが、ＸＭＬデータのデータ構造の複雑さによっても影響される。
【０００４】
しかし、個々のＳＯＡＰメッセージは、事前にＷＳＤＬ及びＸＭＬスキーマによってデータ構造が定義されているため、そのデータ構造によりある程度の処理の複雑さを判定することができる
また、従来から、通信データのデータ構造の複雑さやデータ表現形式を考慮してのネットワークシステムの定量的な評価方法が行われている（特許文献１参照）。
【特許文献１】特開２００２−７７１５６号公報
【非特許文献１】デビッド・Ａ・チャペル（David A Chappell）他著、「ジャバ（Ｒ）・ウェブ・サービス（Java(R) Web Services）」、（米国）、オーレイリー＆アソシエイツ社（O'Reilly & Associates Inc.）、２００２年３月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、ＷＳＤＬ及びＸＭＬスキーマによるデータ形式の定義から判断できる程度は限られており、実際に通信する通信データのサイズや、可変長のデータのサイズ、データ中の特定項目のくり返し、省略可能な項目の有無などといった、実際に通信を行うまではわからない情報もある。そのため、実際にＸＭＬデータを受信して解析を行うまでは、解析処理にかかる時間の長さがわからない。
【０００６】
また、ＷｅｂサービスではＸＭＬデータの解析後、その要求に応じてデータベースを利用、あるいは他のシステムと連携するなどして、サービスを実現するための処理を行う。このサービスを実現するための処理においても、通信するデータの形式あるいはデータの内容によっては処理時間が異なる可能性がある。
このように、ＸＭＬデータを実際に処理しなければシステムに対する負荷を判定できないため、事前にシステムに対して負荷の高いメッセージだけを選択的に拒否するなどといったことができなかった。
【０００７】
次に、従来技術に関する問題点を、図面を参照しながら説明する。図２は、システム構成図であり、Ｗｅｂサービスを提供するサーバ１０３が、サーバであるＳＯＡＰクライアント１０１から送付されたＳＯＡＰメッセージ１０２を受信する様子を表している。サーバ１０３では、Ｗｅｂサーバ用プログラムであるＨＴＴＰＤ１０４が、ＳＯＡＰメッセージ１０２を受け付ける。
【０００８】
そして、ＨＴＴＰＤ１０４は、ＳＯＡＰメッセージ１０２の処理を、プログラムであるＳＯＡＰエンジン１０６に要求する。
要求されたＳＯＡＰメッセージ１０２に対応するＷｅｂサービスの実際の処理は、プログラムである各種のＳＯＡＰアプリケーション１０７で実行される。
また、ＳＯＡＰエンジン１０６では、ＸＭＬデータ解析・データ構造オブジェクト構築部１０８により、受け取ったＳＯＡＰメッセージ１０２のＸＭＬデータを解析し、ＳＯＡＰアプリケーション１０７に処理の要求を行うために必要なデータ構造オブジェクトを構築する。
【０００９】
図３は、ＳＯＡＰメッセージ１０２の例を示したものである。図３に示すＳＯＡＰメッセージ例３０１は、メソッド名echoUserDataのパラメタにuserDataがあり、その中に文字列の配列型であるitem項目のデータを複数有するdata1を持つメッセージである。そして、ＳＯＡＰメッセージ３０１を受け取ったＳＯＡＰエンジン１０６のＸＭＬデータ解析・データ構造オブジェクト構築部１０８では、ＳＯＡＰアプリケーション１０７へ渡すためのデータ構造オブジェクトを構築する。
【００１０】
図４は、そのデータ構造オブジェクトの例を示したものである。ＳＯＡＰアプリケーション１０７へ渡すためのデータ構造オブジェクト４０１は、ＳＯＡＰメッセージ例３０１に対応した、UserDataオブジェクト４０２、data1オブジェクト４０３、及びitem項目の配列データのオブジェクトであるitem1４０４、item2４０５、item3４０６、item4４０７で構成される。ＳＯＡＰエンジン１０６は、ＸＭＬデータ解析・データ構造オブジェクト構築部１０８により構築されたデータ構造オブジェクト４０１を、ＳＯＡＰアプリケーション１０７に引き渡す。
【００１１】
そして、ＳＯＡＰメッセージ例３０１ではitem項目が４つなのでデータ構造オブジェクト４０１のサイズはそれほど大きくはないが、ＳＯＡＰメッセージによっては、もっと大きなデータ構造オブジェクトの構築が必要な可能性がある。
また、データ構造オブジェクトは、ＳＯＡＰメッセージ１０２の中のＸＭＬデータに対応するデータをコンピュータ記述言語で扱いやすい形式で表現したものであり、一般にＸＭＬデータのサイズよりも大きなメモリを必要とする。
さらに、データ構造オブジェクトを構築するために必要なＸＭＬデータの解析処理では、バイナリデータを扱うのに比較して、時間及びリソースが多く必要となる。
このように、従来は、システムに対する負荷の大きいＸＭＬデータを、実際に処理を行う前に負荷が大きいかどうかを判別することができないという課題があった。
【課題を解決するための手段】
【００１２】
前記課題を解決するために、本発明は、送信装置からのデータに関して、送信装置あるいは受信装置において、データの検索対象範囲内でキーワードが所定回数以上存在したか否かなどを判定することにより、受信装置に対するデータの事前負荷評価を行う。
【発明の効果】
【００１３】
本発明によれば、受信装置に対して負荷の大きいデータを、受信装置が従来の処理を行う前に判別することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明に係る４つの実施形態を、図面を参照しながら説明する。実施形態１は受信サーバでデータの事前負荷評価を行うものであり、実施形態２は受信サーバでデータの事前負荷評価を行うときにその検索条件を動的に変更させるものであり、実施形態３はロードバランサでデータの事前負荷評価を行うものであり、実施形態４は送信サーバで行ったデータの事前負荷評価の結果を受信サーバが受信して対応するものである。
【００１５】
＜実施形態１＞
図１は、実施形態１の全体構成を示したブロック図である。
図１のＳＯＡＰクライアント１０１、ＳＯＡＰメッセージ１０２、サーバ１０３、ＨＴＴＰＤ１０４、ＳＯＡＰエンジン１０６、ＳＯＡＰアプリケーション１０７及びＸＭＬデータ解析・データ構造オブジェクト構築部１０８は、図２の場合と同様である。また、ＳＯＡＰクライアント１０１及びサーバ１０３は、少なくとも、各種演算や処理を行う演算手段と、各種データやテーブル等を記憶する記憶手段とを有している。
【００１６】
実施形態１では、ＳＯＡＰエンジン１０６でＸＭＬデータの解析処理を実施する前に、ＸＭＬデータの処理の負荷を評価するメッセージ事前負荷評価部１０５で、ＸＭＬデータの処理の負荷を評価することが特徴である。
以下、評価するプログラムであるメッセージ事前負荷評価部１０５における負荷の評価方法について、詳細を説明する。
【００１７】
図５は、本実施形態におけるメッセージ事前負荷評価部１０５の論理構成を示すブロック図である。
メッセージ事前負荷評価部１０５は、ＨＴＴＰＤ１０４からＳＯＡＰメッセージ１０２を受け取るメッセージ受信部５０１、受け取ったＳＯＡＰメッセージ１０２がどのＷｅｂサービス（図６の対象サービス６０１）に対する要求かを判定するサービス識別部５０２、ＳＯＡＰメッセージに対して事前（ＸＭＬデータ解析・データ構造オブジェクト構築部１０８による処理の前）に実施する検索方法を定義する検索方法管理テーブル５０７、検索方法管理テーブル５０７から対応する検索方法に関する情報を取得する検索方法情報取得部５０３、現在のシステムの稼動状況を管理するシステム稼動状況管理情報５０８、システム稼動状況管理情報５０８から現在の稼動状況を取得する状況情報取得部５０４、ＳＯＡＰメッセージに対して検索を実施する事前検索実施部５０５、受信したメッセージに関する負荷情報に対してどのような対応を行うかを管理する対応方法管理テーブル５０９、並びに、メッセージの事前検索による負荷評価の結果及び対応方法管理テーブル５０９を元に対応方法を判定する対応方法判定部５０６により構成される。
【００１８】
なお、図５のシステム稼動状況管理情報５０８は、“メモリ”、“Ｉ／Ｏ”、“ＣＰＵ”、“処理時間”、“ＤＢアクセス”、“他システム”、“スループット”など、システムの負荷状況に関する情報である。本実施形態では、システムの運用によって決定する基準値からの差異をパーセントで示すことで情報を管理するが、項目ごとの単位で絶対量を管理するなどの別の方法でもよい。
【００１９】
図６は、事前に検索する方法を定義しておくための検索方法管理テーブル５０７の内容を示すデータ構造図である。
対象サービス６０１のカラムは、事前に検索する方法の対象Ｗｅｂサービス名を示す項目である。図６に示す例では、対象のＷｅｂサービスとして“UserInfo”サービス及び“AdminInfo”サービスを対象にした例を示している。また、このカラムで“−”と指定された場合には、特定のＷｅｂサービスに関わらず全てのサービスに対して評価を行うことを示す。
【００２０】
検索種別６０２のカラムは、ＳＯＡＰメッセージに対してどの様な種類の検索を実施するかを示す項目である。図６の例では、サイズだけを指定する“DataSize”や特定のキーワードの出現回数を検索する“Count”などの検索種別を示す。なお、本実施形態では個別の検索種別を例に示したが、複数の検索種別を組み合わせてもよい。
【００２１】
影響６０３のカラムは、その検索種別６０２によってシステムのどの様なリソースに関しての影響が大きいかを示す項目である。影響６０３のカラムには、“メモリ”、“Ｉ／Ｏ”、“ＣＰＵ”、“処理時間”、“ＤＢアクセス”、“他システム”、“スループット”などシステムの負荷状況を測る指標が入っている。また、“−”は特定のリソースではなく、全体に影響することを示す。本実施形態では、現在のシステム状況に関する情報（システム稼働状況管理情報５０８）及び影響６０３のカラム情報を、同じ対象サービス６０１に複数の検索種別６０２が定義されている場合に優先して実施する検索種別６０２を選択するために利用する。また、他の条件により事前に実施する検索種別６０２の選択を行ったり、検索種別６０２の追加を行ってもよい。
【００２２】
条件６０４のカラムは、検索種別６０２で指定された検索を実施するために定義された条件を示す項目である。たとえば、それ以上のサイズのデータを受信したら、システムに対する負荷が大きいと判定するための“datalength”や、検索するキーワードを定義する“keyword"などの項目がある。
【００２３】
次に、事前に検索する方法を示す図６の検索種別６０２及びその条件６０４の組合せの例を説明する。なお、以下の検索及び判定方法は例であり、他の方法を追加したり切り替えたりしてもよい。
【００２４】
検索種別６０２が“DataSize”の場合は、受信するＸＭＬデータの構造の複雑さによらず、データサイズそのものが大きいことによりシステムへの負荷が大きいデータか判定することを示す。この検索種別の場合、条件６０４の“datalength”項目の値よりＸＭＬデータのサイズが大きいかで該当か否かを判定する。この“datalength”項目の単位は、たとえば“バイト”である。なお、検索種別６０２がこの“DataSize”の場合は、ＸＭＬデータに対する検索を行わなくとも、ＨＴＴＰプロトコルのContentsLength項目などを利用して判定してもよい。
また、本実施形態では、条件６０４の“datalength”項目は、“DataSize”以外の検索種別６０２においても指定可能な条件項目としている。
【００２５】
検索種別６０２が“Count”の場合は、条件６０４の“keyword”項目で指定される文字列が、“base”項目（検索対象範囲）で指定される範囲までの間の出現回数を数える。文字列の出現回数が“limit”項目（所定回数）で指定された数値を上回った場合、該当と判定する。この図６の例の場合では、データの長さが7000（バイト）以下で、かつ、最初の3000（バイト）のうちに“item”の文字列が50回以内であれば、負荷が大きくないと判定することになる。なお、“base”項目は、検索処理の対象範囲を示す項目であり、他の検索種別６０２でも共通の項目である。
【００２６】
図３に示すＳＯＡＰメッセージ例３０１中の配列データ項目であるitem項目が上限なしで定義されている場合には、データによってはitem項目が０個の可能性から1000個以上である可能性もある。この数が多い場合には、構築されるデータ構造オブジェクトのサイズも大きくなり、細かいオブジェクトが大量にできてシステム負荷が大きくなる可能性もある。このような場合には、条件６０４の“keyword”項目に“item”と指定する。検索種別６０２の“Count”では、ＸＭＬデータを単なる大きな文字列データと見なして、文字列“item”を条件に単純で高速な複数回の文字列検索を行うことでitem項目の出現回数を数え、その数により負荷が高いＸＭＬデータか否か判定している。このようにすることで、ＸＭＬのデータ構造に依存しない高速な検索により負荷の大きいＸＭＬデータか否かの評価を行うことができる。
【００２７】
また、検索種別６０２が“Count”の場合では、ＸＭＬの特徴だけでなくＷｅｂサービスの実装方式の特徴から、“keyword”の項目を決定してもよい。たとえば、オプション項目である“Fax”名称のデータ項目がある場合には、アクセスするデータベースの領域が増える、または、処理に時間のかかる他のシステムとの連携が発生するなどといったシステム負荷に関する判断ができる場合には、検索種別６０２の“Count”を利用して事前評価を行うことができる。
【００２８】
検索種別６０２が“StartPos”（StartPositionの略）の場合は、条件６０４の“keyword”項目で指定される文字列が、“pos”項目で指定される範囲までの間に出現しなかった場合、負荷が大きいと判定する。
検索種別６０２が“StartPos”による評価は、ＸＭＬのスキーマ定義において必ず存在する項目である項目が、“pos"項目で指定される範囲までに出現しない場合には、それ以前の項目のデータ量が多く、ＸＭＬデータ全体のデータ量が多くシステムへの負荷が大きいデータと判断できるような場合に使用する。
【００２９】
検索種別６０２が“Space”の場合は、条件６０４の“keyword1”項目で指定される文字列の出現位置と、条件６０４の“kyeword2”項目で指定される文字列の出現間隔が、“size”項目で指定される値より大きい場合に、負荷が大きいと判定する。
検索種別６０２が“Space”による評価は、たとえば、ＸＭＬのスキーマ定義において必ず存在する項目である“keyword1"項目及び“kyeword2”項目の間隔から、ＸＭＬデータ全体のデータ量が多く、システムへの負荷が大きいデータと判断できるような場合に使用する。また、“keyword1"項目及び“kyeword2”項目の間隔から想定されるデータ量により、データベースアクセスなどの他のリソースに与える影響が大きく、システム全体に大きな負荷を与えると判断できるような場合にも使用する。
【００３０】
検索種別６０２が“ComplexCount”の場合は、条件６０４の“keyword1”項目で指定される文字列が出現したあと、“child"項目の数以上の“kyeword2”項目で指定される文字列が出現するという組合せのパターンが、全体で“count"項目で指定した数以上出現するかによりＸＭＬデータの複雑度を判定する。
検索種別６０２が“ComplexCount”による評価は、条件６０４の“keyword1"項目で特定されるデータ項目に子及びその孫項目など下位のデータ項目において、配列データなどがある場合に“kyeword2”項目の有無及び数により、ＸＭＬデータのデータ量が多いまたは、生成されるデータ構造オブジェクトが複雑でありシステムへの負荷が大きいと判断できるような場合に使用する。
なお、検索種別６０２が“ComplexCount”で示した例以外にも、単純な検索の組合による検索及び評価を行ってもよい。
【００３１】
検索種別６０２が“Interval”の場合は、条件６０４の“keyword”項目で指定される文字列が複数回出現するとき、“keyword”項目で指定される項目間の平均間隔が、“size”項目で指定された値より小さい場合には、負荷が大きいと判断する。
検索種別６０２が“Interval”による評価は、ＸＭＬデータのトータルのサイズは小さいが、小さなデータが大量にあり、データ構造オブジェクトが複雑あるいは、効率が悪いと判断できるような場合に使用する。
【００３２】
検索種別６０２が“TagCount”の場合は、条件６０４の“base”項目で指定される範囲において、ＸＭＬのタグ開始を示す文字列“<”の出現回数が“limit”項目で指定された値より大きい場合には、負荷が大きいと判断する。なお、検索種別６０２の“Count”において、条件６０４の“keyword”項目に“<”を指定することで、同等の検索及び評価が可能である。
検索種別６０２が“TagCount”による評価は、ＸＭＬデータのトータルのサイズに関わらず、タグの数によってデータ構造オブジェクトが複雑あるいは、効率が悪いと判断できるような場合に使用する。
【００３３】
検索種別６０２が“TagRate”の場合は、条件６０４の“base”項目で指定される範囲において、ＸＭＬのタグ開始を示す文字列“<”の出現回数が“limit”項目で指定された値より大きい場合には、負荷が大きいと判断する。
検索種別６０２が“TagRate”による評価では、ＸＭＬデータのトータルのサイズは小さいがタグの数が多くそれによりデータ構造オブジェクトが複雑あるいは、効率が悪いと判断できるような場合に使用する。
【００３４】
検索種別６０２が“AttributeCount”の場合は、条件６０４の“base”項目で指定される範囲において、ＸＭＬのアトリビュート（属性）の指定を示す文字列“=”の出現回数が“limit”項目で指定された値より大きい場合には、負荷が大きいと判断する。
ＸＭＬ解析処理及びデータ構造オブジェクトの構築処理及びＷｅｂサービスのビジネスロジックの実装において、ＸＭＬの属性の項目が多いことにより、システムの負荷が高くなることがある。検索種別６０２が“AttributeCount”による評価では、ＸＭＬデータの内容に“="が多く、ＸＭＬデータに多くの属性項目の指定があることにより、データ構造オブジェクトが複雑あるいは、効率が悪いと判断できるような場合に使用する。
【００３５】
図７は、事前の評価を実施した後の対応方法を定義する対応方法管理テーブル５０９のデータ構造図である。
図７の対象サービス６０１及び検索種別６０２のカラムは図６のものと同じで、事前検索を実施した対象のＷｅｂサービス及び実施した検索種別を識別するためのカラムであり、それに応じた条件及び対処方法の定義と事前検索とを対応させるためのキーである。
【００３６】
図７の対応方法７０２のカラムは、対象サービス６０１及び検索種別６０２に対応して実施した検索が負荷の高いデータを識別するための条件に該当した場合に、対処方法を定義しておくためのものである。図７の条件７０１のカラムは、対応方法７０２を現在のシステム状況に応じて切り分けるための定義であり、図７の例に示すように、メモリ状況が５０％を超えた場合にはメッセージの“受付拒否”であるが、メモリ状況が２０％より大きく５０％以下の場合であれば、“リソース確保”を試みるといった対応方法７０２を切り替える場合に利用する条件である。
【００３７】
図８は、事前評価の処理の流れを示すフローチャートである（適宜図１及び図５参照）。
Ｗｅｂサービスを提供するサーバ１０３が、ＳＯＡＰクライアント１０１からＳＯＡＰメッセージ１０２を受け取った後の処理の流れを以下に示す。
まず、ステップ８０１（Ｓ８０１：以下同様）で、ＳＯＡＰメッセージ１０２を受信したＨＴＴＰＤ１０４は、メッセージ事前負荷評価部１０５のメッセージ受信部５０１に、受け取ったＳＯＡＰメッセージ１０２を渡す。
メッセージ受信部５０１は、ステップ８０２で、ＳＯＡＰメッセージ１０２を受信し、受け取ったＳＯＡＰメッセージ１０２がどのＷｅｂサービスに対する要求かを判定するサービス識別部５０２へ渡す。
【００３８】
ステップ８０３で、サービス識別部５０２は、受信したＳＯＡＰメッセージを元にどのＷｅｂサービスに対する要求かを識別する。
ステップ８０４で、検索情報取得部５０３は、ステップ８０３で識別した対応Ｗｅｂサービス情報をキーに検索情報管理テーブル５０７から対応する検索方法に関する情報を取得する。
ステップ８０５で、状況情報取得部５０４は、システム稼動状況管理情報５０８から現在のシステムの稼動状況に関する情報を取得する。
ステップ８０６で、事前検索実施部５０５は、ステップ８０４で取得した検索方法に関する情報に基いて、ステップ８０２で受け取ったＳＯＡＰメッセージ１０２に対して、事前検索を実施する。事前検索の種別は、図６の検索種別６０２で指定された方法に従う。
【００３９】
続いて、ステップ８０７で、ＳＯＡＰメッセージ１０２に対する事前検索の結果が図６の条件６０４のカラムに定義した条件に該当するか否かによって処理の分岐を行う。その事前検索の結果が非該当の場合には、ステップ８１０で、ＸＭＬデータ解析・データ構造オブジェクト構築部１０８にＳＯＡＰメッセージ１０２を渡し、通常の処理を実施する。そして、ステップ８１１で、サーバ１０３は、返信ＳＯＡＰメッセージをＳＯＡＰクライアント１０１に送信する。
ステップ８０７による事前検索の結果が該当の場合には、ステップ８０８で、対応方法判定部５０６が対応方法管理テーブル５０９から対応方法定義の情報を取得する。そして、ステップ８０９で、対応方法定義に基づいた対応処理を実施する。
【００４０】
このように、受信したＳＯＡＰメッセージ１０２に関して、データ構造やデータ表現形式に依存しない検索を行うことで、高速な検索が実現できる。また、対応方法を定義しておくことで、負荷が大きくないと評価された場合は通常の処理を行い、負荷が大きいと評価された場合はその負荷の種類や程度に応じた対応を行うことができる。
【００４１】
＜実施形態２＞
実施形態１では、図６の検索条件は予め決定しておく必要があるが、決定した検索条件が妥当でないこともありえる。したがって、実際にはサーバ１０３で処理できるメッセージも、初期検索条件によっては誤った処理（対応方法７０２における「受付拒否」など）を行ってしまう可能性がある。この問題を解決するためには、検索条件を動的に変更することが望ましい。
実施形態２では、メッセージ事前負荷評価部１０５ａに、過去の実行結果ログを持たせ、動的に検索条件を変更することが特徴である。
以下、メッセージ事前負荷評価部１０５ａにおける、検索条件を動的に変更する方法の詳細を説明する。
【００４２】
図９は、本実施形態におけるメッセージ事前負荷評価部１０５ａの論理構成を示すブロック図である。
図９のメッセージ受信部５０１、サービス識別部５０２、検索方法情報取得部５０３、状況情報取得部５０４、事前検索実施部５０５、対応方法判定部５０６、検索方法管理テーブル５０７、システム稼動状況管理情報５０８、対応方法管理テーブル５０９は図５の場合と同様である。
そして、メッセージ事前負荷評価部１０５ａは、さらに、過去の実行結果を持つ実行結果ログテーブル９０２と実行結果ログテーブル９０２の情報から検索条件を変更するための検索条件変更部９０１とを加えて構成される。
【００４３】
図１０は過去の実行結果を持つ実行結果ログテーブル９０２の内容を示すデータ構造図である。
対象サービス１００１のカラム、および検索種別１００２のカラムは、それぞれ図６の対象サービス６０１のカラム、検索種別６０２のカラムと同様である。
条件１００３のカラムは、図６の条件６０４のカラムで指定した検索条件で動的に変更する項目と現在までに最も負荷が大きかった場合の値を示す。
実行結果１００４のカラムは、条件１００３のカラムで指定した値で実行した時の実際の負荷結果を示す。
しきい値１００５のカラムは、各対象サービス、検索種別で想定している負荷のしきい値を示す。
【００４４】
たとえば、図１０の対象サービス１００１が“UserInfo”、検索種別が“Count”の例（１段目）では、条件１００３のカラムが現在までに最大30回の“keyword”が出現していることを示し、また、実行結果１００４のカラムは負荷結果が40%であることを示している。このとき、負荷結果がしきい値１００５のカラムの値50%以内に収まっていることから、検索の条件６０４が妥当であると判断できる。
一方、対象サービス１００１が“UserInfo”、検索種別が“StartPos”の例（２段目）では、実行結果50%がしきい値40%を上回っており、検索の条件６０４の“pos”の値をもっと小さく設定する必要があると判断できる。
また、対象サービス１００１が“AdminInfo”、検索種別が“Space”の例（３段目）では、実行結果20%がしきい値80%を大きく下回っており、検索条件の“size”をもっと大きく設定する必要があると判断できる。
【００４５】
図１１は、検索条件の変更処理の流れを示すフローチャートである（適宜図１及び図９参照）。
まず、Ｗｅｂサービスを提供するサーバ１０３は、ステップ１１０１で、ＳＯＡＰクライアント１０１からＳＯＡＰメッセージ１０２を受け取り、ＳＯＡＰメッセージ１０２に関して通常の解析・実行・返信を行う。
ステップ１１０２で、状況情報取得部５０４は、システム稼動状況管理情報５０８から実行時の稼動状況（負荷）に関する情報を取得する。
ステップ１１０３で、検索条件変更部９０１は、実行結果ログテーブル９０２に実行時のログを格納する。
ステップ１１０４で、検索条件変更部９０１は、実行結果ログテーブル９０２に格納した結果から実行結果１００４としきい値を比較し、大きくしきい値を上回ったり、下回ったりしていないか否かによって、処理の分岐を行う。たとえば、しきい値がメモリ５０％の場合はメモリ３０％〜６０％を正常範囲とするなど、それぞれのしきい値に対して正常範囲の上限値と下限値として決定してある数値と、実行結果１００４とを比較することによって、判断することができる。その場合、その正常範囲の上限値と下限値は、実行結果ログテーブル９０２に記憶されている（図示なし）。
ステップ１１０４で比較した結果が範囲外の場合は、ステップ１１０５で検索情報更新部９０１は検索方法管理テーブル５０７の検索条件を変更する。なお、この検索条件の変更は、検索情報更新部９０１が行わなくても、管理者などが適宜変更値を入力するなどにより行ってもよい。
ステップ１１０４で比較した結果が範囲内の場合は、ステップ１１０６で処理を終了する。
【００４６】
このように、実際の検索結果に基いて検索の条件を動的に変更することで、受信したＳＯＡＰメッセージ１０２に関して、より的確な負荷評価及びその対応を行うことができる。
【００４７】
＜実施形態３＞
図１２は、実施形態３に関する全体構成を示したブロック図である。本実施形態では、メッセージ事前負荷評価部１０５をロードバランサ１２０１上に設置している。
図１２のＳＯＡＰクライアント１０１、ＳＯＡＰメッセージ１０２、サーバ１０３、メッセージ事前負荷評価部１０５は、図１の場合と同様である。ロードバランサ１２０１は、いわゆる負荷分散装置であり、受け付けたＳＯＡＰメッセージ１０２を各サーバ１０３に振り分けるためのもので、少なくとも、各種演算や処理を行う演算手段、各種データやテーブル等を記憶する記憶手段、及び、メッセージ事前負荷評価部１０５を有している。
【００４８】
本実施形態では、メッセージ事前負荷評価部１０５をロードバランサ１２０１上に設置し、複数台で構成されたサーバシステムにおいても事前負荷評価が可能であることが特徴である。評価するメッセージ事前負荷評価部１０５における、負荷の評価方法は実施形態１の場合と同様である。
【００４９】
このように、ＳＯＡＰメッセージ１０２の事前負荷評価及びその対応を、各サーバ１０３ではなくロードバランサ１２０１で行うことで、ＳＯＡＰメッセージ１０２の処理の効率化を実現することができる。
【００５０】
＜実施形態４＞
図１３は、実施形態４の全体構成を示したブロック図である。本実施形態では実施形態１のメッセージ事前負荷評価部を２つに分け、クライアントメッセージ事前評価部１３０３及びサーバメッセージ事前負荷評価部１３０４として、ＳＯＡＰクライアント１０１上及びサーバ１０３上に設置する。
図１３のＳＯＡＰクライアント１０１、サーバ１０３、ＨＴＴＰＤ１０４、ＳＯＡＰエンジン１０６、ＳＯＡＰアプリケーション１０７、ＸＭＬデータ解析・データ構造オブジェクト構築部１０８は、図１の場合と同様である。
【００５１】
図１３の検索方法情報１３０１は、ＳＯＡＰクライアント１０１のクライアントメッセージ事前評価部１３０３でＳＯＡＰメッセージ１０２を評価するために使用する情報であり、図６の検索方法管理テーブル５０７の内容が該当する。
図１３の事前検索結果１３０２は、サーバ１０３のサーバメッセージ事前負荷評価部１３０４で評価するために使用する情報である。
【００５２】
本実施形態では、予めＳＯＡＰクライアント１０１に検索方法情報１３０１を通知しておき、ＳＯＡＰクライアント１０１上でＳＯＡＰメッセージ１０２を事前検索後、事前検索結果１３０２をサーバ１０３に送信し、サーバ１０３上で評価することで、ＳＯＡＰメッセージ１０２を受信することなく事前負荷評価が可能であることが特徴である。
以下、クライアントメッセージ事前負荷評価部１３０３、サーバメッセージ事前負荷評価部１３０４における負荷の評価方法を説明する。
【００５３】
図１４は、本実施形態のクライアントメッセージ事前負荷評価部１３０３の論理構成を示すブロック図である。
クライアント事前負荷評価部１３０３は、サーバメッセージ事前負荷評価部１３０４から事前に通知される検索方法情報１３０１を受信する検索情報受信部１４０１、ＳＯＡＰクライアント１０１から受信するＳＯＡＰメッセージ１０２に対して検索を実施する事前検索実施部５０５、検索結果である事前検索結果１３０２を送信する検索結果送信部１４０２により構成される。
【００５４】
図１５は、本実施形態のサーバメッセージ事前負荷評価部１３０４の論理構成を示すブロック図である。
サーバメッセージ事前負荷評価部１３０４は、クライアントメッセージ事前負荷評価部１３０３に事前に通知する検索方法情報１３０１を送信する検索方法情報送信部１５０１、クライアントメッセージ事前負荷評価部１３０３から送信される事前検索結果１３０２を受信する検索結果受信部１５０２、状況情報取得部５０４、対応方法判定部５０６、検索方法管理テーブル５０７、システム稼動状況管理情報５０８、対応状況管理テーブル５０９により構成される。
【００５５】
図１６は、事前負荷評価の処理の流れを示すフローチャートである。
Ｗｅｂサービスを提供するサーバ１０３が、ＳＯＡＰクライアント１０１からＳＯＡＰメッセージ１０２を受け取る前に事前評価する処理の流れを以下に示す（適宜図１３〜図１５参照）。
まず、ステップ１６０１で、検索方法情報受信部１４０１は、検索方法情報送信部１５０１から検索方法情報１３０１を受信する。
事前検索実施部５０５は、ステップ１６０２で、ステップ１６０１で取得した検索方法に関する情報に基づいて、ＳＯＡＰメッセージ１０２に関する事前検索を実施する。
ステップ１６０３で、検索結果送信部１４０２は、ステップ１６０２で検索した事前検索結果１３０２を検索結果受信部１５０２に送信する。
【００５６】
ステップ１６０４で、検索結果受信部１５０２は事前検索結果１３０２を受信する。
ステップ１６０５で、状況情報取得部５０４は、システム稼動状況管理情報５０８から現在のシステムの稼動状況に関する情報を取得する。
ステップ１６０６で、対応方法判定部５０６は対応方法管理テーブル５０９から対応方法の情報を取得する。
ステップ１６０７で、ステップ１６０４で取得した事前検索結果１３０２とステップ１６０６で取得した対応方法の情報から対応方法定義に基づいた対応処理を実施する。
【００５７】
このように、ＳＯＡＰメッセージ１０２に関して、送信側のＳＯＡＰクライアント１０１で事前の負荷評価を行うことにより、たとえば、負荷が大きいと判定された場合には送信を中止するなど、より効率的な対応をとることができる。
【００５８】
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。たとえば、実施形態３や実施形態４においても、実施形態２のときと同様に、検索条件を動的に変更させることができる。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００５９】
【図１】実施形態１の全体構成を示したブロック図である。
【図２】従来技術の全体構成を示したブロック図である。
【図３】ＳＯＡＰメッセージの例を示すデータの構造図である。
【図４】ＳＯＡＰメッセージに応じて作成されるデータオブジェクトの構造図である。
【図５】実施形態１のメッセージ事前負荷評価部の論理構成を示すブロック図である。
【図６】検索方法管理テーブルのデータ構造図である。
【図７】対応方法管理テーブルのデータ構造図である。
【図８】実施形態１の事前評価の処理の流れを示すフローチャートである。
【図９】実施形態２のメッセージ事前負荷評価部の論理構成を示すブロック図である。
【図１０】実行結果ログテーブルの内容を示すデータ構造図である。
【図１１】実施形態２の処理の流れを示すフローチャートである。
【図１２】実施形態３の全体構成を示したブロック図である。
【図１３】実施形態４の構成全体を示したブロック図である。
【図１４】実施形態４のクライアントメッセージ事前負荷評価部の論理構成を示すブロック図である。
【図１５】実施形態４のサーバメッセージ事前負荷評価部の論理構成を示すブロック図である。
【図１６】実施形態４の処理の流れを示すフローチャートである。
【符号の説明】
【００６０】
１０１  ＳＯＡＰクライアント
１０３  サーバ
３０１  ＳＯＡＰメッセージ例
４０１  データ構造オブジェクト
５０７  検索方法管理テーブル
１２０１  ロードバランサ
【図１】
2006155123.tif 000003
【図２】
2006155123.tif 000004
【図３】
2006155123.tif 000005
【図４】
2006155123.tif 000006
【図５】
2006155123.tif 000007
【図６】
2006155123.tif 000008
【図７】
2006155123.tif 000009
【図８】
2006155123.tif 000010
【図９】
2006155123.tif 000011
【図１０】
2006155123.tif 000012
【図１１】
2006155123.tif 000013
【図１２】
2006155123.tif 000014
【図１３】
2006155123.tif 000015
【図１４】
2006155123.tif 000016
【図１５】
2006155123.tif 000017
【図１６】
2006155123.tif 000018