(57)【要約】【課題】障害が発生した場合の障害復旧を容易にできるようにする。【解決手段】ＷＳＤＬサーバ２は、ＷＳＤＬ文書の要求メッセージをクライアント１から受け付けるネットワークインタフェース部２１と、Ｗｅｂサービスの情報が記憶されたＷｅｂサービステーブル２３と、要求メッセージとＷｅｂサービステーブル２３を参照しＷＳＤＬ文書を生成するＷＳＤＬ生成部２２と、各ＡＰサーバ３の稼動状態を監視するＡＰサーバ監視部２５と、ＡＰサーバ監視部２５が収集した各ＡＰサーバ３の稼動情報を記憶する監視情報ファイル２６と、監視情報ファイル２６の稼動情報に基づき各ＡＰサーバ３にＷｅｂサービスのリクエストを振り分ける負荷分散処理部２４と、を有する。【選択図】  図１
2005078339.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置が提供するＷｅｂサービスのリクエストに用いるＷＳＤＬ文書を、端末装置に提供するＷＳＤＬ文書生成装置であって、
ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記端末装置から受け付けるメッセージ受付手段と、
少なくとも１つのＷｅｂサービス毎に、当該Ｗｅｂサービスのサービス名、インタフェース情報、および、少なくとも１つのアドレス情報が記憶されたサービス情報記憶手段と、
前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されているインタフェース情報およびアドレス情報を用いて、ＷＳＤＬ文書を生成するＷＳＤＬ生成手段と、
前記ＷＳＤＬ生成手段により生成されたＷＳＤＬ文書を、前記要求メッセージの送信元である前記端末装置に送信するＷＳＤＬ送信手段と、を有すること
を特徴とするＷＳＤＬ文書生成装置。
【請求項２】
請求項１記載のＷＳＤＬ文書生成装置であって、
前記アドレス情報が複数ある場合、前記複数のアドレス情報は、それぞれ異なる複数の情報処理装置に割り当てられていて、
前記複数のアドレス情報から１つのアドレス情報を選択する選択手段と、前記複数の情報処理装置各々の稼動情報が記憶された稼動情報記憶手段と、をさらに有し、
前記選択手段は、前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されている複数のアドレス情報に対応する情報処理装置各々の稼動情報を前記稼動情報記憶手段から検索し、検索した稼動情報に基づいて１つのアドレス情報を選択し、
前記ＷＳＤＬ生成手段は、前記選択手段により選択されたアドレス情報を用いて、当該ＷｅｂサービスのＷＳＤＬ文書を生成すること
を特徴とするＷＳＤＬ文書生成装置。
【請求項３】
請求項１記載のＷＳＤＬ文書生成装置であって、
前記複数のアドレス情報から１つのアドレス情報を選択する選択手段をさらに有し、
前記選択手段は、前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されている複数のアドレス情報を、所定の順番に従って１つ選択し、
前記ＷＳＤＬ生成手段は、前記選択手段により選択されたアドレス情報を用いて、当該ＷｅｂサービスのＷＳＤＬ文書を生成すること
を特徴とするＷＳＤＬ文書生成装置。
【請求項４】
請求項１乃至３のいずれか１項に記載のＷＳＤＬ文書生成装置であって、
前記サービス情報記憶手段には、前記アドレス情報に、当該Ｗｅｂサービスが用いるプロトコル種別が対応付けられて記憶されており、
前記メッセージ受付手段は、サービス名およびプロトコル種別を含む前記要求メッセージを、前記端末装置から受け付け、
前記ＷＳＤＬ生成手段は、前記メッセージ受付手段が受け付けた要求メッセージに含まれているサービス名およびプロトコル種別に対応付けられて前記サービス情報記憶手段に記憶されているアドレス情報を用いて、当該ＷｅｂサービスのＷＳＤＬ文書を生成すること
を特徴とするＷＳＤＬ文書生成装置。
【請求項５】
情報処理装置が提供するＷｅｂサービスのリクエストに用いるＷＳＤＬ文書を、端末装置に提供するＷＳＤＬ文書生成装置において動作するプログラムであって、
前記プログラムは、前記ＷＳＤＬ文書生成装置に、
ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記端末装置から受け付けるメッセージ受付手段、
少なくとも１つのＷｅｂサービス毎に、当該Ｗｅｂサービスのサービス名、インタフェース情報および少なくとも１つのアドレス情報が記憶されたサービス情報記憶手段、
前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されているインタフェース情報およびアドレス情報を用いて、ＷＳＤＬ文書を生成するＷＳＤＬ生成手段、および、
前記ＷＳＤＬ生成手段により生成されたＷＳＤＬ文書を、前記要求メッセージの送信元である前記端末装置に送信するＷＳＤＬ送信手段、として機能させること
を特徴とするプログラム。
【請求項６】
情報処理装置が提供するＷｅｂサービスのリクエストに用いるＷＳＤＬ文書を生成し、端末装置に提供するＷＳＤＬ文書生成方法であって、
ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記端末装置から受け付ける受付ステップと、
少なくとも１つのＷｅｂサービス毎に、当該Ｗｅｂサービスのサービス名、インタフェース情報および少なくとも１つのアドレス情報が記憶された記憶手段を、参照する参照ステップと、
前記受付ステップで受け付けた要求メッセージに含まれているサービス名に対応付けられて前記記憶手段に記憶されているインタフェース情報およびアドレス情報を用いて、ＷＳＤＬ文書を生成するＷＳＤＬ生成ステップと、
前記ＷＳＤＬ生成ステップにより生成されたＷＳＤＬ文書を、前記要求メッセージの送信元である前記端末装置に送信する送信ステップと、を有すること
を特徴とするＷＳＤＬ文書生成方法。
【請求項７】
情報処理装置に、当該情報処理装置が提供するＷｅｂサービスのリクエストを行う端末装置であって、
前記Ｗｅｂサービスのリクエストに用いるＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、ＷＳＤＬ文書生成装置に送信して、前記ＷＳＤＬ文書生成装置より、前記ＷｅｂサービスのＷＳＤＬ文書を受信するＷＳＤＬ要求手段と、
前記ＷＳＤＬ要求手段が受信したＷＳＤＬ文書を用いて、前記Ｗｅｂサービスのリクエストに用いるスタブを生成するスタブ生成手段と、
前記スタブ生成手段が生成したスタブを用いて、前記Ｗｅｂサービスを提供する情報処理装置に、前記Ｗｅｂサービスのリクエストを送信するリクエスト手段と、を有すること
を特徴とする端末装置。
【請求項８】
情報処理装置に、当該情報処理装置が提供するＷｅｂサービスのリクエストを行う端末装置において動作するプログラムであって、
前記プログラムは、前記端末装置に、
前記Ｗｅｂサービスのリクエストに用いるＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、ＷＳＤＬ文書生成装置に送信して、前記ＷＳＤＬ文書生成装置より、前記ＷｅｂサービスのＷＳＤＬ文書を受信するＷＳＤＬ要求手段、
前記ＷＳＤＬ要求手段が受信したＷＳＤＬ文書を用いて、前記Ｗｅｂサービスのリクエストに用いるスタブを生成するスタブ生成手段、および、
前記スタブ生成手段が生成したスタブを用いて、前記Ｗｅｂサービスを提供する情報処理装置に、前記Ｗｅｂサービスのリクエストを送信するリクエスト手段、として機能させること
を特徴とするプログラム。
【請求項９】
情報処理装置に、当該情報処理装置が提供するＷｅｂサービスのリクエストを行う方法であって、
前記Ｗｅｂサービスのリクエストに用いるＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、ＷＳＤＬ文書生成装置に送信して、前記ＷＳＤＬ文書生成装置より、前記ＷｅｂサービスのＷＳＤＬ文書を受信するＷＳＤＬ要求ステップと、
前記ＷＳＤＬ要求ステップで受信したＷＳＤＬ文書を用いて、前記Ｗｅｂサービスのリクエストに用いるスタブを生成するスタブ生成ステップと、
前記スタブ生成ステップで生成したスタブを用いて、前記Ｗｅｂサービスを提供する情報処理装置に、前記Ｗｅｂサービスのリクエストを送信する送信ステップと、を有すること
を特徴とするＷｅｂサービスのリクエストを行う方法。
【請求項１０】
情報処理装置が提供するＷｅｂサービスのリクエストに用いるＷＳＤＬ文書を、端末装置に提供するＷＳＤＬ文書生成システムであって、
前記ＷＳＤＬ文書生成システムは、ＷＳＤＬ文書生成装置と、少なくとも１つの端末装置とを有し、
前記ＷＳＤＬ文書生成装置は、
ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記端末装置から受け付けるメッセージ受付手段と、
少なくとも１つのＷｅｂサービス毎に、当該Ｗｅｂサービスのサービス名、インタフェース情報、および、少なくとも１つのアドレス情報が記憶されたサービス情報記憶手段と、
前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されているインタフェース情報およびアドレス情報を用いて、ＷＳＤＬ文書を生成するＷＳＤＬ生成手段と、
前記ＷＳＤＬ生成手段により生成されたＷＳＤＬ文書を、前記要求メッセージの送信元である前記端末装置に送信するＷＳＤＬ送信手段と、を有し、
前記端末装置は、
ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記ＷＳＤＬ文書生成装置に送信して、前記ＷＳＤＬ送信手段が送信したＷＳＤＬ文書を受信するＷＳＤＬ要求手段と、
前記ＷＳＤＬ要求手段が受信したＷＳＤＬ文書を用いて、前記Ｗｅｂサービスのリクエストに用いるスタブを生成するスタブ生成手段と、
前記スタブ生成手段が生成したスタブを用いて、前記Ｗｅｂサービスのアドレス情報を有する情報処理装置に、前記Ｗｅｂサービスのリクエストを送信するリクエスト手段と、を有すること
を特徴とするＷＳＤＬ文書生成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスのリクエストを分散して処理するための技術に関し、特にＷＳＤＬ（Web Services Description Language）を利用した負荷分散を行う技術に関する。
【背景技術】
【０００２】
Ｗｅｂ関連技術の１つにＷｅｂサービス技術がある。Ｗｅｂサービス技術は、ＸＭＬ（eXtensible Markup Language）形式のメッセージ交換により、ネットワーク上に存在するアプリケーションを連携させる技術をいう。また、Ｗｅｂサービス技術を用いたアプリケーションをＷｅｂサービスという。そして、Ｗｅｂサービスのインタフェース、宛先等を記述するための言語として、ＸＭＬ形式のＷＳＤＬ（Web Services Description Language）が存在する。Ｗｅｂサービスには、ＷＳＤＬで記述したＷＳＤＬ文書が用意され、Ｗｅｂサービスを利用するため必要なインタフェース情報等が記述されている。
【０００３】
また、Ｗｅｂサービスの負荷分散の方法としては、クライアントからのリクエストを複数のサーバに振り分ける負荷分散装置を用いることが一般的である（例えば、非特許文献１）。
【０００４】
【非特許文献１】「日経インターネットソリューション」，日経ＢＰ社，２００３年５月号，ｐ７４−８２
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、Ｗｅｂサービスは、クライアントからのリクエストをサーバが処理し、この処理結果をクライアントに送信する従来のＷｅｂシステムと異なり、Ｗｅｂサービス自身がさらに別の複数のＷｅｂサービスを呼び出し、複数のＷｅｂサービスを１つの処理（１トランザクション）で行うことが可能である。つまり、Ｗｅｂサービス自体がクライアントとなって他のサーバにリクエストすることができる。
【０００６】
しかし、従来の負荷分散装置は、１つの処理（１トランザクション）で複数のＷｅｂサービスを呼び出す際に障害が発生した場合の障害復旧について、考慮されていない。例えば、クライアントからコミット指示を受け付けたＷｅｂサービスが、２相コミットで処理を行う場合において、第１フェーズ終了後、第２フェーズ終了前に障害が発生する場合がある。この場合、クライアントからのリクエストは従来の負荷分散装置により複数のサーバに振り分けられるため、クライアント自身は、Ｗｅｂサービスを提供するサーバの宛先を知らない。このため、この障害復旧処理を行うことは非常に困難である。
【０００７】
また、従来の負荷分散装置をＷｅｂサービスに適用する場合、図８に示すように、Ｗｅｂサービス毎に少なくとも１台の負荷分散装置を用いる必要がある。図８に示す例では、クライアント１は、サービスＡまたはサービスＤのＷｅｂサービスを呼び出す。サービスＡのＷｅｂサービスは、当該Ｗｅｂサービス自身がサービスＢのＷｅｂサービスを呼び出し、さらに、サービスＢのＷｅｂサービスがサービスＣのＷｅｂサービスを呼び出す。この場合は、サービスＡを提供する複数のサーバ８１にリクエストを振り分けるサービスＡ用の負荷分散装置８ａと、サービスＢを提供する複数のサーバ８２にリクエストを振り分けるサービスＢ用の負荷分散装置８ｂと、サービスＣを提供する複数のサーバ８３にリクエストを振り分けるサービスＣ用の負荷分散装置８ｃとが、それぞれ少なくとも１台ずつ必要である。また、サービスＤのＷｅｂサービスは、当該Ｗｅｂサービス自身がサービスＥのＷｅｂサービスを呼び出す。この場合も、サービスＤ用の負荷分散装置８ｄと、サービスＥ用の負荷分散装置８ｅとが、それぞれ少なくとも１台ずつ必要である。
【０００８】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、障害が発生した場合の障害復旧を容易にすることである。また、本発明の他の目的は、冗長構成のシステムの投資負担を軽減し、Ｗｅｂサービスのリクエストを分散することである。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明では、ＷＳＤＬ文書を動的に生成するＷＳＤＬ文書生成装置を用いて、端末装置が直接サーバにＷｅｂサービスをリクエストするようにする。
【００１０】
例えば、本発明のＷＳＤＬ文書生成装置は、ＷＳＤＬ文書を要求する、サービス名を含む要求メッセージを、前記端末装置から受け付けるメッセージ受付手段と、少なくとも１つのＷｅｂサービス毎に、当該Ｗｅｂサービスのサービス名、インタフェース情報、および、少なくとも１つのアドレス情報が記憶されたサービス情報記憶手段と、前記メッセージ受付手段で受け付けた要求メッセージに含まれているサービス名に対応付けられて前記サービス情報記憶手段に記憶されているインタフェース情報およびアドレス情報を用いて、ＷＳＤＬ文書を生成するＷＳＤＬ生成手段と、前記ＷＳＤＬ生成手段により生成されたＷＳＤＬ文書を、前記要求メッセージの送信元である前記端末装置に送信するＷＳＤＬ送信手段と、を有する。
【００１１】
また、本発明のＷＳＤＬ文書生成装置は、複数の前記アドレス情報から、１つのアドレス情報を選択する選択手段を、さらに有することとしてもよい。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態について説明する。
【００１３】
図１は、本発明の一実施形態が適用されたＷｅｂサービスシステム１０の全体構成図である。
【００１４】
図示するように、本実施形態のＷｅｂサービスシステム１０は、複数のクライアント１と、ＷＳＤＬサーバ２と、複数のアプリケーションサーバ（以下、ＡＰサーバという）３とを備える。クライアント１は、ＷＳＤＬサーバ２およびＡＰサーバ３と、インターネットなどのネットワーク９ａによりそれぞれ接続されている。また、ＷＳＤＬサーバ２と各ＡＰサーバ３間は、ＷＳＤＬサーバ２がＡＰサーバ３の稼動状態を監視するため、イントラネットなどのネットワーク９ｂにより接続されている。
【００１５】
クライアント１は、Ｗｅｂサービス利用者の端末装置である。クライアント１は、Ｗｅｂサービスを呼び出す（リクエストする）際に、まず、ネットワーク９ａを介してＷＳＤＬサーバ２に、Ｗｅｂサービスの呼び出しに必要なスタブを生成するためのＷＳＤＬ文書を要求する。そして、クライアント１は、ＷＳＤＬサーバ２が生成したＷＳＤＬ文書からスタブを動的に生成し、このスタブを用いてＡＰサーバ３に対してＷｅｂサービスを呼び出す。スタブとは、クライアント上で動作する、他の装置のアプリケーションと通信を行うためのオブジェクトである。
【００１６】
ＷＳＤＬサーバ２は、ネットワーク９ａを介してクライアント１からの要求を受け付け、当該要求に基づいてＷｅｂサービスを呼び出すためのＷＳＤＬ文書を生成し、生成したＷＳＤＬ文書を要求元のクライアント１に送信する装置である。そして、ＷＳＤＬサーバ２は、ＡＰサーバ３間での負荷を分散するために、ＡＰサーバ３の宛先を設定してＷＳＤＬ文書を生成する。
【００１７】
ＡＰサーバ３は、Ｗｅｂサービス技術を用いたアプリケーションであるＷｅｂサービスを提供する装置である。ＡＰサーバ３は、Ｗｅｂサービスに必要なアプリケーションプログラムおよびデータを格納し、クライアント１からのリクエストに応じて、各種のＷｅｂサービスを提供する。例えば、図１のＷｅｂサービスシステム１０では、ＡＰサーバ（Ａ）３およびＡＰサーバ（Ｂ）３は、サービスＡのＷｅｂサービスを提供する。また、ＡＰサーバ（Ｎ）３は、サービスＢのＷｅｂサービスを提供する。
【００１８】
次に、クライアント１およびＷＳＤＬサーバ２の各構成について説明する。
【００１９】
まず、クライアント１について説明する。図１に示すように、クライアント１は、ネットワークインタフェース部１１と、ＷＳＤＬ要求部１２と、スタブ生成部１３と、Ｗｅｂサービス呼出部１５と、業務処理部１６と、を有する。
【００２０】
ネットワークインタフェース部１１は、ネットワーク９ａとの間でメッセージまたはデータの送受信を行う。
【００２１】
ＷＳＤＬ要求部１２は、ネットワークインタフェース部１１を介して、ＷＳＤＬサーバ２にＷＳＤＬ文書を要求する。具体的には、ＷＳＤＬ要求部１２は、図示しない入力装置により、Ｗｅｂサービスのサービス名およびプロトコル種別（通信手順）を伴うＷｅｂサービスの呼び出し指示を受け付け、サービス名およびプロトコル種別を含んだＷＳＤＬ要求メッセージを送信する。
【００２２】
スタブ生成部１３は、ネットワークインタフェース部１１を介して、ＷＳＤＬサーバ２から取得したＷＳＤＬ文書から、スタブ１４を動的に生成する。また、スタブ生成部１３は、ＷＳＤＬ要求部１２が動的に取得したＷＳＤＬ文書からＡＰサーバ３の宛先を取り出し、あらかじめ汎用的に生成されたスタブに当該ＡＰサーバ３の宛先を設定することとしてもよい。ここで、スタブ１４は、スタブ生成部１３により生成されるＷｅｂサービスと通信を行うためのオブジェクトである。
【００２３】
Ｗｅｂサービス呼出部１５は、スタブ生成部１３が動的に生成したスタブ１４を用いて、ＷＳＤＬ文書に設定されたＷｅｂサービスを提供するＡＰサーバ３に、Ｗｅｂサービスの呼び出し（リクエスト）を行う。そして、業務処理部１６は、当該ＡＰサーバ３からＷｅｂサービスの処理結果を受け取り、所定の業務処理を行う。
【００２４】
次に、ＷＳＤＬサーバ２について説明する。図１に示すように、ＷＳＤＬサーバ２は、ネットワークインタフェース部２１と、ＷＳＤＬ生成部２２と、Ｗｅｂサービステーブル２３と、負荷分散処理部２４と、ＡＰサーバ監視部２５と、監視情報ファイル２６と、を有する。
【００２５】
ネットワークインタフェース部２１は、ネットワーク９ａとの間でメッセージまたはデータの送受信を行う。例えば、ネットワークインタフェース部２１は、ネットワーク９ａを介してクライアント１からＷＳＤＬ要求メッセージを受け付け、また、このＷＳＤＬ要求メッセージに基づいて生成したＷＳＤＬ文書を出力する。
【００２６】
ＷＳＤＬ生成部２２は、ネットワークインタフェース部２１が受け付けたＷＳＤＬ文書の要求メッセージに基づいて、Ｗｅｂサービステーブル２３を参照し、ＷＳＤＬ文書を生成する。ＷＳＤＬ文書の生成については、図５および図６で後述する。
【００２７】
Ｗｅｂサービステーブル２３は、図示しない記憶装置に記憶されており、本Ｗｅｂサービスシステム１０で提供されるＷｅｂサービスの情報が登録されている。例えば、Ｗｅｂサービステーブル２３は、図２に示すような構造を有する。すなわち、Ｗｅｂサービステーブル２３は、Ｗｅｂサービスのサービス名２３１と、当該サービス名２３１に対応して、インタフェース定義２３２、プロトコル種別２３３およびアドレス２３４が、それぞれ登録されている。
【００２８】
サービス名２３１には、Ｗｅｂサービスの名称が登録され、図２に示す例ではサービスＡとサービスＢとが登録されている。
【００２９】
インタフェース定義２３２には、Ｗｅｂサービスを要求するための入力メッセージおよびサービス結果を提供するための出力メッセージのフォーマットが記述されている。例えば、メッセージ毎のデータの型（string、string、decimal  等）や、入力メッセージに埋め込まれるパラメータ等が記述されている。また、関連するメッセージを組み合わせたポートの情報が記述されている。具体的には、後述するＷＳＤＬ文書（図６参照）のメッセージ定義およびポート定義が、ＷＳＤＬで記述されている。
【００３０】
プロトコル種別２３３には、ＡＰサーバ３に対してＷｅｂサービスを呼び出す際に使用する通信手順（遠隔呼び出し手順）が登録される。例えば、ＳＯＡＰ（Simple Object Access Protocol）プロトコル、ＥＪＢ（Enterprise JavaBeans）呼び出し、Ｊａｖａ（登録商標）のローカル関数呼び出し、などがある。図２に示す例では、サービスＡを呼び出すための通信手順として、ＳＯＡＰプロトコル、ＥＪＢ呼び出し、および、Ｊａｖａローカル関数呼び出しが登録されている。
【００３１】
アドレス２３４には、サービス名とプロトコル種別に対応したＷｅｂサービスの提供場所が登録される。そして、このアドレス２３４には当該Ｗｅｂサービスを提供するＡＰサーバ３を特定する情報（ＡＰサーバ３の宛先）が含まれている。例えば、ＵＲＬ（Uniform Resource Locator）を、アドレス２３４に用いることが考えられる。図２に示す例では、サービスＡをＳＯＡＰプロトコルにより提供するＷｅｂサービスのアドレスとして、ＡＰサーバ（Ａ）、ＡＰサーバ（Ｂ）およびＡＰサーバ（Ｃ）のそれぞれのＵＲＬが登録されている。なお、本実施形態においては、各ＡＰサーバ３は、それぞれ１つのＷｅｂサービスを提供するものとする。すなわち、ＡＰサーバ３各々は、対応する１つのＷｅｂサービスのアドレス２３４を有するものとする。
【００３２】
ＡＰサーバ監視部２５は、各ＡＰサーバ３の稼動状態、例えば、ＣＰＵ利用率、メモリ利用率、単位時間当たりの接続要求回数等を継続的に測定（あるいは、各ＡＰサーバ３から定期的に収集）して、監視する。例えば、ＡＰサーバ監視部２５は、所定の時間間隔で各ＡＰサーバ３に対しＣＰＵ利用率等を測定するためのコマンドを発行してＣＰＵ利用率等を測定する。あるいは、各ＡＰサーバ３のＯＳ（Operating System）の機能により出力されるログ情報を定期的に参照し、ＣＰＵ利用率等を取得する。
【００３３】
そして、ＡＰサーバ監視部２５は、これらの測定または収集した情報を監視情報ファイル２６に記憶する。また、ＡＰサーバ監視部２５は、各ＡＰサーバ３に障害が発生した否かについても監視し、障害が発生した場合には障害フラグを監視情報ファイル２６に設定する。
【００３４】
監視情報ファイル２６は、図示しない記憶装置に記憶されていて、前述のＡＰサーバ監視部２５が測定または収集した各ＡＰサーバ３の稼動情報が記憶されている。例えば、監視情報ファイル２６は、図３に示すような構造を有する。すなわち、監視情報ファイル２６には、ＡＰサーバ３毎に、前述したＷｅｂサービスのアドレス２６１、ＣＰＵ利用率２６２、メモリ利用率２６３、および、障害フラグ２６４が記憶されている。
【００３５】
負荷分散処理部２４は、クライアント１からのＷＳＤＬ要求メッセージに指定されたサービス名で、指定されたプロトコル種別（通信手順）のＷｅｂサービスのアドレスが複数存在する場合に、これら複数のアドレスにそれぞれ対応するＡＰサーバ３間の負荷が分散されるように、１つのＡＰサーバ３を特定する。例えば、負荷分散処理部２４は、前述した監視情報ファイル２６（図３参照）を参照し、対象となる複数のＡＰサーバ３各々のＣＰＵ使用率を比較して、最もＣＰＵ使用率の低いＡＰサーバ３を特定する。また、負荷分散処理部２４は、監視情報ファイル２６を参照し、メモリ利用率を比較して、最もメモリ使用率の低いＡＰサーバ３を特定することとしてもよい。あるいは、ＣＰＵ使用率とメモリ使用率とを合計した値が最も低いＡＰサーバ３を特定するなど、ＣＰＵ使用率とメモリ使用率の両方を用いてＡＰサーバ３各々の負荷を判定することとしてもよい。そして、負荷分散処理部２４は、１つのＡＰサーバ３を特定することにより、対応する１つのＷｅｂサービスのアドレスを特定することができる。また、負荷分散処理部２４は、障害フラグが設定されているＡＰサーバ３については、対象から除外する。
【００３６】
このように、負荷分散処理部２４は、監視情報ファイル２６を参照して、正常なＡＰサーバ３のみを対象とし、かつ、正常なＡＰサーバ３各々の負荷を判定して、最も負荷の低いＡＰサーバ３を特定する。これにより、ＡＰサーバ３の処理能力に応じたきめ細かな負荷分散を実現することができる。
【００３７】
また、負荷分散処理部２４は、ラウンドロビンにより、ＡＰサーバを特定してもよい。すなわち、負荷分散処理部２４は、クライアント１から指定されたサービス名およびプロトコル種別（通信手順）により定まる複数のＷｅｂサービスのアドレスを、あらかじめ決められた順序で順番に特定する。例えば、Ｗｅｂサービステーブル２３を参照し、Ｗｅｂサービステーブル２３のアドレス２３４欄の登録されている順番で、順次、当該Ｗｅｂサービスのアドレスを特定することとしてもよい。
【００３８】
これにより、１台のＡＰサーバ３にリクエストが集中することを防ぎ、複数のＡＰサーバ３間での接続要求回数を均等にし、負荷を分散させることが可能となる。
【００３９】
なお、本実施形態において、上記のような構成を備えるＷＳＤＬサーバ２を複数台備えていてもよい。この場合、各ＷＳＤＬサーバ２は、それぞれ独立に各クライアント１からＷＳＤＬ要求メッセージを受け付け、生成したＷＳＤＬ文書を要求元のクライアント１に送信する。
【００４０】
上記説明した、クライアント１、ＷＳＤＬサーバ２およびＡＰサーバ３は、いずれも、例えば図４に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、モニタやプリンタなどの出力装置９０５と、ネットワーク接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより実現される。例えば、ＷＳＤＬサーバ２およびクライアント１の各機能は、クライアント１用のプログラムの場合、クライアント１のＣＰＵ９０１が、ＷＳＤＬサーバ２用のプログラムの場合、ＷＳＤＬサーバ２のＣＰＵ９０１が、それぞれ実行することにより、実現される。この場合、ＷＳＤＬサーバ２のＷｅｂサービステーブル２３や監視情報ファイル２６には、メモリ９０２または外部記憶装置９０３が用いられる。
【００４１】
次に、ＷＳＤＬサーバ２の処理手順を、図５に示すフローチャートを用いて説明する。
【００４２】
まず、ネットワークインタフェース部２１は、クライアント１より、サービス名およびプロトコル種別を含んだＷＳＤＬ要求メッセージを受信し（Ｓ１１）、受信したメッセージをＷＳＤＬ生成部２２に送出する。そして、ＷＳＤＬ生成部２２は、Ｗｅｂサービステーブル２３を参照して（Ｓ１２）、ＷＳＤＬ要求メッセージに含まれるサービス名およびプロトコル種別から対象となるＷｅｂサービスのアドレスを選択する（Ｓ１３）。
【００４３】
次に、ＷＳＤＬ生成部２２は、選択したＷｅｂサービスのアドレスが複数存在するか否かを判定する（Ｓ１４）。Ｗｅｂサービスのアドレスが複数存在する場合（Ｓ１４：ＹＥＳ）、ＷＳＤＬ生成部２２は、負荷分散処理部２４に選択した複数のアドレスの情報を引き渡す。負荷分散処理部２４は、前述したように、監視情報ファイル２６を参照して、選択された複数のアドレスにそれぞれ対応する複数のＡＰサーバ３の中から、最も負荷の少ないＡＰサーバ３を特定する。そして、負荷分散処理部２４は、この特定したＡＰサーバ３に対応するＷｅｂサービスのアドレスを特定する（Ｓ１５）。あるいは、負荷分散処理部２４は、選択された複数のＷｅｂサービスのアドレスの中から、ラウンドロビンにより順番にＷｅｂサービスのアドレスを特定する（Ｓ１５）。
【００４４】
そして、ＷＳＤＬ生成部２２は、負荷分散処理部２４が特定したＷｅｂサービスのアドレスを、ＷＳＤＬ文書のＷｅｂサービスの宛先として決定する（Ｓ１６）。また、対象となるＷｅｂサービスのアドレスが１つの場合（Ｓ１５：ＮＯ）、ＷＳＤＬ生成部２２は、当該Ｗｅｂサービスのアドレスを、ＷＳＤＬ文書のＷｅｂサービスの宛先として決定する（Ｓ１６）。
【００４５】
次に、ＷＳＤＬ生成部２２は、ＷＳＤＬ文書を生成する（Ｓ１７）。図６に示すＷＳＤＬ文書を例に、ＷＳＤＬ文書の生成について説明する。ＷＳＤＬ文書は、図示するように、ＸＭＬ形式で記述され、ＸＭＬの宣言６０、メッセージ定義６１、ポート定義６２、バインディング定義６３、および、サービス定義６４を含む構成となっている。
【００４６】
ＸＭＬの宣言６０は、ＷＳＤＬサーバ２の図示しない記憶装置にあらかじめ記憶されており、ＷＳＤＬ生成部２２は、当該記憶されたＸＭＬの宣言６０を用いてＸＭＬの宣言６０を生成する。
【００４７】
メッセージ定義６１は、Ｗｅｂサービスで使用する入力メッセージおよび出力メッセージのインタフェース（フォーマット）を、それぞれ定義したものである。また、ポート定義６２は、メッセージ定義６１で定義されたメッセージを組み合わせたポートを定義したものである。このメッセージ定義６１およびポート定義６２は、前述のとおりＷｅｂサービステーブル２３のインタフェース定義２３２に、あらかじめ登録されている。ＸＭＬの宣言６０を生成後、ＷＳＤＬ生成部２２は、ＷＳＤＬ要求メッセージに含まれるサービス名に対応するインタフェース定義２３２を用いてメッセージ定義６１およびポート定義６２を生成する。
【００４８】
バインディング定義６３は、ポート定義６２で定義されたポートのプロトコル種別（通信手順）を定義したものである。図６に示す例では、バインディング定義６３でＳＯＡＰプロトコルを用いることが記述されている。メッセージ定義６１およびポート定義６２を生成後、ＷＳＤＬ生成部２２は、ＷＳＤＬ要求メッセージに含まれるサービス名およびプロトコル種別と、メッセージ定義６１と、ポート定義６２とを用いて、当該プロトコル種別のＷＳＤＬ記述形式で、バインディング定義６３を生成する。
【００４９】
サービス定義６４は、バインディング定義６３で定義されたポートに、Ｗｅｂサービスの宛先（アドレス）を定義するものである。図６に示す例では、「soap:address location」の後に記述されたＵＲＬが定義されている。バインディング定義６３を生成後、ＷＳＤＬ生成部２２は、Ｓ１６において決定されたＷｅｂサービスのアドレスと、ＷＳＤＬ要求メッセージに含まれるサービス名およびプロトコル種別と、メッセージ定義６１と、ポート定義６２と、バインディング定義６３とを用いて、当該プロトコル種別のＷＳＤＬ記述形式で、サービス定義６４を生成する。
【００５０】
このように、ＷＳＤＬ生成部２２は、ＷＳＤＬ要求メッセージに含まれる情報、Ｗｅｂサービステーブル２３に登録されている情報、ＷＳＤＬの記述形式などのＷＳＤＬ文書の生成に必要な情報から、ＷＳＤＬ文書を生成する（Ｓ１７）。そして、ＷＳＤＬ生成部２２は、生成したＷＳＤＬ文書を、要求元のクライアント１へ、ネットワークインタフェース部２１を介して送信する（Ｓ１８）。
【００５１】
次に、クライアント１の処理について、図７に示すフローチャートを用いて説明する。
【００５２】
ＷＳＤＬ要求部１２は、図示していない入力装置から、サービス名およびプロトコル種別（通信手順）を伴うＷｅｂサービスの呼び出し指示を受け付ける。この呼び出し指示を受け取ると、ＷＳＤＬ要求部１２は、ネットワークインタフェース部１１を介して、ＷＳＤＬサーバ２へＷＳＤＬ要求メッセージを送信する（Ｓ２１）。このＷＳＤＬ要求メッセージには、サービス名およびプロトコル種別（通信手順）が含まれている。そして、ＷＳＤＬ要求部１２は、前述のＷＳＤＬサーバ２の処理（図５参照）により生成されたＷＳＤＬ文書を、ＷＳＤＬサーバ２から受信する（Ｓ２２）。
【００５３】
次に、スタブ生成部１３は、受信したＷＳＤＬ文書からスタブ１４を生成する（Ｓ２３）。そして、Ｗｅｂサービス呼出部１５は、生成されたスタブ１４を用いて、ＷＳＤＬ文書に設定されたＷｅｂサービスのアドレスを宛先としてＷｅｂサービスの呼び出しを行う（Ｓ２４）。そして、業務処理部１６は、Ｗｅｂサービスの処理結果を受け取り、所定の業務処理を行う（Ｓ２５）。
【００５４】
なお、クライアント１が呼び出したＷｅｂサービス自身が、さらに他のＷｅｂサービスの呼び出しを行う場合、当該呼び出されたＷｅｂサービスを提供するＡＰサーバ３は、クライアント１と同様の処理（図７参照）を行い、次に呼び出すＷｅｂサービスのＷＳＤＬ文書を取得する。すなわち、ＡＰサーバ３は、ＷＳＤＬサーバ２に対してＷＳＤＬ要求メッセージを送信することでＷＳＤＬ文書を取得し、当該ＷＳＤＬ文書に設定されているＷｅｂサービスのアドレスを取得する。そして、ＡＰサーバ３は、このＷｅｂサービスのアドレスを宛先として、次のＷｅｂサービスを呼び出す。この場合、ＡＰサーバ３は、クライアント１と同様の機能（図１参照）を有する必要がある。
【００５５】
これにより、１トランザクションで複数のＷｅｂサービスを呼び出す場合であっても、各Ｗｅｂサービスを提供する複数のＡＰサーバ間で、それぞれ負荷分散処理を行うことが可能となる。また、クライアント１またはＡＰサーバ３は、２相コミットの第１フェーズ終了後、常に自分が呼び出したＷｅｂサービスを提供するＷｅｂサービスのアドレスを取得しているため、２相コミットの第１フェーズ終了後、第２フェーズ終了前に障害が発生した場合であっても、容易に障害復旧処理を行うことができる。
【００５６】
また、クライアント１が呼び出したＷｅｂサービス自身が、さらに他のＷｅｂサービスの呼び出しを行う方法としては、クライアント１により呼び出されたＷｅｂサービスが、次に呼び出すＷｅｂサービスを提供するＷｅｂサービスのアドレスを、あらかじめ設定しておくこととしてもよい。これにより、ＷＳＤＬサーバ２にアクセスすることなく、簡易に他のＷｅｂサービスの呼び出しを行うことができる。
【００５７】
本実施形態では、クライアント１は、ＷＳＤＬサーバ２から負荷状況を鑑みて動的に取得したＷＳＤＬ文書に記述されたＷｅｂサービスのアドレスのＡＰサーバ３に、直接、Ｗｅｂサービスの呼び出し（リクエスト）を行う。これにより、１つの処理（１トランザクション）で複数のＷｅｂサービスを呼び出す際に障害が発生した場合であっても、容易に障害復旧作業を行うことができる。
【００５８】
また、本実施形態では、ＷＳＤＬサーバ２が、全てのＷｅｂサービスに対するリクエスト（Ｗｅｂサービスがクライアントとなって他のＷｅｂサービスに発行するリクエストを含む）に対して、Ｗｅｂサービス毎にそれぞれ負荷分散処理を行う。すなわち、本実施形態のＷＳＤＬサーバ２は、複数のＷｅｂサービスにおいて共用可能な負荷分散装置である。これにより、Ｗｅｂサービス毎に負荷分散装置を備える必要はなくなり、シンプルなシステム構成を実現することができる。
【００５９】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記の実施形態のＷｅｂサービステーブル２３（図２参照）では、インタフェース定義２３２の欄にＷＳＤＬ文書のインタフェース定義の内容を、そのまま格納している。しかしながら、インタフェース定義内容を格納したファイルを、別途、記憶装置に記憶しておき、Ｗｅｂサービステーブル２３では、インタフェース定義２３２の欄にインタフェース定義を記憶したファイル名を格納することとしてもよい。
【００６０】
また、上記実施形態のクライアント１が送信するＷＳＤＬ要求メッセージには、サービス名とプロトコル種別とが含まれている。しかしながら、ＷＳＤＬ要求メッセージにプロトコル種別を含まないこととしてもよい。この場合、Ｗｅｂサービステーブル２３に、Ｗｅｂサービス毎のデフォルトのプロトコル種別があらかじめ設定されており、ＷＳＤＬ生成部２２は、このデフォルトのプロトコル種別のＷＳＤＬ文書を生成することとしてもよい。
【００６１】
また、上記の実施形態のＡＰ監視部２５および監視情報ファイル２６は、ＷＳＤＬサーバ２内に含まれている。しかしながら、ＷＳＤＬサーバ２とは別の運用サーバを備え、この運用サーバがＡＰ監視部２５および監視情報ファイル２６の機能を実現することとしてもよい。また、ＡＰ監視部２６は、各ＡＰサーバ３の稼動情報の測定または収集を行うだけでなく、Ｗｅｂサービステーブル２３の登録に必要な情報を所定のタイミングで各ＡＰサーバから収集し、Ｗｅｂサービステーブル２３の追加、変更、削除等のメンテナンスを自動的に行うこととしてもよい。
【００６２】
また、上記実施形態では、各ＡＰサーバ３は、１つのＷｅｂサービスを提供するものとし、各ＡＰサーバ３は、それぞれ１つのＷｅｂサービスのアドレスを有するものとしている。しかしながら、１つのＡＰサーバ３が、複数のＷｅｂサービスを提供することとしてもよい。この場合、ＡＰサーバ３は、複数のＷｅｂサービスのアドレスを有することになる。
【図面の簡単な説明】
【００６３】
【図１】図１は、本発明の一実施形態が適用されたＷｅｂサービスシステムの全体構成を示す図である。
【図２】図２は、Ｗｅｂサービステーブルのデータ構造の一例を示す図である。
【図３】図３は、監視情報ファイルのデータ構造の一例を示す図である。
【図４】図４は、クライアント、ＷＳＤＬサーバおよびＡＰサーバのハードウェア構成例を示す図である。
【図５】図５は、ＷＳＤＬサーバの処理手順を示すフローチャートである。
【図６】図６は、ＷＳＤＬ文書の例を示す図である。
【図７】図７は、クライアントの処理手順を示すフローチャートである。
【図８】図８は、従来の負荷分散装置を用いたＷｅｂサービスシステムの構成を示す図である。
【符号の説明】
【００６４】
１…クライアント、２…ＷＳＤＬサーバ、３…ＡＰサーバ、９ａ…ネットワーク、９ｂ…ネットワーク、１０…Ｗｅｂサービスシステム、１１…ネットワークインタフェース部、１２…ＷＳＤＬ要求部、１３…スタブ生成部、１４…スタブ、１５…Ｗｅｂサービス呼出部、１６…業務処理部、２１…ネットワークインタフェース部、２２…ＷＳＤＬ生成部、２３…Ｗｅｂサービステーブル、２４…負荷分散処理部、２５…ＡＰサーバ監視部、２６…監視情報ファイル
【図１】
2005078339.tif 000003
【図２】
2005078339.tif 000004
【図３】
2005078339.tif 000005
【図４】
2005078339.tif 000006
【図５】
2005078339.tif 000007
【図６】
2005078339.tif 000008
【図７】
2005078339.tif 000009
【図８】
2005078339.tif 000010