(57)【要約】【課題】ＥＳＢ実行計算機が、サービス実行計算機とリクエスタ実行計算機との間で送受信される情報を予め把握して、リクエスタ実行計算機に対応するリクエスト受付や、サービス実行計算機に対応するアダプタを事前に生成しておかなければならず、サービス実行計算機と通信プロトコルの異なるリクエスタ実行計算機に対して、動的にサービスの機能を提供することができない。【解決手段】ＥＳＢ実行計算機１１０のメモリ１７０にリクエスタ実行計算機１６０およびサービス実行計算機１００からの公開情報を登録し、ＥＳＢ実行計算機１１０のＣＰＵ１８０が、メモリ１７０の公開情報からリクエスタ１６０Ａおよびサービス１００Ａのそれぞれに対応するリクエスト受付１５０およびアダプタ１４０を生成する。【選択図】図１
2008186105.tif 000002
【特許請求の範囲】
【請求項１】
サービスの実行を要求するリクエスタ実行計算機および前記サービスを実行するサービス実行計算機と通信可能なサービス機能提供装置であって、
前記サービス実行計算機と通信を行う際に用いるアダプタを記憶する記憶部を備えるとともに、
前記リクエスタ実行計算機から前記リクエスタ実行計算機との通信に用いるプロトコルおよび電文のフォーマットの種別をそれぞれ指定するプロトコル情報および電文情報を受け取ることにより、リクエスタ公開情報エントリとして前記記憶部に記憶し、
前記記憶部の前記プロトコル情報および前記電文情報を用いて、前記リクエスタ実行計算機と通信を行う際に用いるリクエスト受付を生成して前記記憶部に記憶し、
前記記憶部の前記リクエスト受付を用いて、前記リクエスタ実行計算機から前記サービスを実行する旨の要求を受け付け、前記記憶部の前記アダプタを用いて、前記サービス実行計算機に当該要求を行う処理部
を備えることを特徴とするサービス機能提供装置。
【請求項２】
サービスの実行を要求するリクエスタ実行計算機および前記サービスを実行するサービス実行計算機と通信可能なサービス機能提供装置によるサービス機能提供方法であって、
前記サービス機能提供装置は、
前記サービス実行計算機と通信を行う際に用いるアダプタを記憶する記憶部と、情報を処理する処理部とを備え、
前記処理部は、
前記リクエスタ実行計算機から前記リクエスタ実行計算機との通信に用いるプロトコルおよび電文のフォーマットの種別をそれぞれ指定するプロトコル情報および電文情報を受け取ることにより、リクエスタ公開情報エントリとして前記記憶部に記憶し、
前記記憶部の前記プロトコル情報および前記電文情報を用いて、前記リクエスタ実行計算機と通信を行う際に用いるリクエスト受付を生成して前記記憶部に記憶し、
前記記憶部の前記リクエスト受付を用いて、前記リクエスタ実行計算機から前記サービスを実行する旨の要求を受け付け、前記記憶部の前記アダプタを用いて、前記サービス実行計算機に当該要求を行う
ことを特徴とするサービス機能提供方法。
【請求項３】
前記処理部は、
前記リクエスト受付を生成する際、前記プロトコル情報によって指定される通信プロトコルに従って、非同期用のリクエスト受付を作成するか同期用のリクエスト受付を生成するかを判定する
ことを特徴とする請求項２に記載のサービス機能提供方法。
【請求項４】
サービスの実行を要求するリクエスタ実行計算機および前記サービスを実行するサービス実行計算機と通信可能なサービス機能提供装置によるサービス機能提供方法であって、
前記サービス機能提供装置は、
前記リクエスタ実行計算機と通信を行う際に用いるリクエスト受付を記憶する記憶部と、情報を処理する処理部とを備え、
前記処理部は、
前記サービス実行計算機から前記サービス実行計算機との通信に用いるプロトコルおよび電文のフォーマットの種別をそれぞれ指定するプロトコル情報および電文情報を受け取ることにより、サービス公開情報エントリとして前記記憶部に記憶し、
前記記憶部の前記プロトコル情報および前記電文情報を用いて、前記サービス実行計算機と通信を行う際に用いるアダプタを生成して前記記憶部に記憶し、
前記記憶部の前記リクエスト受付を用いて、前記リクエスタ実行計算機から前記サービスを実行する旨の要求を受け付け、前記記憶部の前記アダプタを用いて、前記サービス実行計算機に当該要求を行う
ことを特徴とするサービス機能提供方法。
【請求項５】
サービスの実行を要求するリクエスタ実行計算機および前記サービスを実行するサービス実行計算機と通信可能なサービス機能提供装置によるサービス機能提供方法であって、
前記サービス機能提供装置は、
前記リクエスタ実行計算機と通信を行う際に用いるリクエスト受付を記憶する記憶部と、情報を処理する処理部とを備え、
前記処理部は、
前記サービス実行計算機から前記サービス実行計算機との通信に用いるプロトコルおよび電文のフォーマットの種別をそれぞれ指定するプロトコル情報および電文情報を受け取ることにより、サービス公開情報エントリとして前記記憶部に記憶し、
前記サービス実行計算機と通信を行う際に用いるアダプタが生成されているか否かを判定し、生成されていない場合には、前記記憶部の前記プロトコル情報および前記電文情報を用いて、前記アダプタを生成して前記記憶部に記憶し、
前記記憶部の前記リクエスト受付を用いて、前記リクエスタ実行計算機から前記サービスを実行する旨の要求を受け付け、前記記憶部の前記アダプタを用いて、前記サービス実行計算機に当該要求を行う
ことを特徴とするサービス機能提供方法。
【請求項６】
前記処理部は、
前記サービス実行計算機から前記プロトコル情報および前記電文情報を受け取るとともに、前記サービスを提供可能な稼動時間を受け取って、前記サービス公開情報エントリに含めて前記記憶部に記憶し、
現在時刻が前記記憶部の前記稼動時間内である前記記憶部の前記サービス公開情報エントリに基づいて、前記サービス実行計算機に前記要求を行うアダプタを選択する
ことを特徴とする請求項４または請求項５に記載のサービス機能提供方法。
【請求項７】
前記記憶部は、
前記サービス実行計算機に前記要求を行うアダプタを選択する際の優先度をさらに記憶し、
前記処理部は、
前記リクエスタ実行計算機から前記プロトコル情報および前記電文情報を受け取るとともに、前記サービスの負荷容量を受け取って、前記サービス公開情報エントリに含めて前記記憶部に記憶し、
前記優先度および前記負荷容量に従って、前記記憶部の前記サービス公開情報エントリに基づいて、前記サービス実行計算機に前記要求を行うアダプタを選択する
ことを特徴とする請求項４ないし請求項６のいずれか１項に記載のサービス機能提供方法。
【請求項８】
前記記憶部は、
前記サービスに障害が起きた際の動作である障害時の動作をさらに記憶し、
前記処理部は、
前記障害時の動作に従って、前記サービス実行計算機に前記サービスの起動要求を出す
ことを特徴とする請求項４ないし請求項７のいずれか１項に記載のサービス機能提供方法。
【請求項９】
前記処理部は、
前記記憶部の前記アダプタを用いて、前記サービス実行計算機に前記要求を行う際、前記プロトコル情報で指定された通信プロトコルを使用する
ことを特徴とする請求項４ないし請求項８のいずれか１項に記載のサービス機能提供方法。
【請求項１０】
請求項２ないし請求項９のいずれか１項に記載のサービス機能提供方法をコンピュータに実行させるためのサービス機能提供プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス実行計算機からリクエスタ実行計算機にサービスの機能を提供する技術に関するものである。
【背景技術】
【０００２】
近年、システムの効率的な再利用を目的に、サービスと呼ばれるソフトウェアコンポーネントを構築し、それらのサービスを組み合わせて活用するＳＯＡ（Service Oriented Architecture）というシステムアーキティクチャが注目されている。ＳＯＡシステムは、サービスの実行をサービス実行計算機に要求するプログラムであるリクエスタを備えたリクエスタ実行計算機と、その要求に従ってサービスを実行するサービス実行計算機とを含んで構成される。そして、リクエスタ実行計算機がサービスを要求し、サービス実行計算機が要求を受け付けるが、サービス実行計算機とリクエスタ実行計算機との間で使用される通信プロトコルが異なる場合がある。
【０００３】
サービス実行計算機とリクエスタ実行計算機との間で異なる通信プロトコルを用いる場合に対応する技術として、ＥＳＢ（Enterprise Service Bus）を用いる技術が挙げられる（非特許文献１など）。このＥＳＢを実行するＥＳＢ実行計算機によれば、使用する通信プロトコルが異なるサービス実行計算機とリクエスタ実行計算機との間においても、リクエスタ実行計算機にサービスの機能を提供することが可能である。
【０００４】
また、このＥＳＢ実行計算機を用いたシステムには、サービス実行計算機の通信プロトコルに対応したアダプタを有し、リクエスタ実行計算機の通信プロトコルに対応したリクエスト受付を有する技術がある（非特許文献２など）。
【非特許文献１】日本ＢＥＡシステムズ株式会社  著「ＳＯＡ  サービス指向アーキテクチャ」翔泳社出版２００５年５月１５日発行  Ｐ１７〜３９
【非特許文献２】ｈｔｔｐ：／／ｗｗｗ−０６．ｉｂｍ．ｃｏｍ／ｊｐ／ｄｅｖｅｌｏｐｅｒｗｏｒｋｓ／ｗｅｂｓｅｒｖｉｃｅｓ／０６０１２０／ｊ＿ｗｓ−ｓｏａ−ｐｒｏｇｍｏｄｅｌ４．ｓｈｔｍｌ
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、前記従来技術を用いる場合には、リクエスタ実行計算機からの要求を受け付けるリクエスト受付や、サービス実行計算機を呼び出すアダプタを予め用意しておかなければならない。このためには、ＥＳＢ実行計算機が、サービス実行計算機とリクエスタ実行計算機との間で送受信される情報を予め把握して、リクエスタ実行計算機に対応するリクエスト受付や、サービス実行計算機に対応するアダプタを事前に生成しておかなければならず、サービス実行計算機と通信プロトコルの異なるリクエスタ実行計算機に対して、動的にサービスの機能を提供することが不可能であるという問題がある。
【０００６】
そこで本発明は、サービス実行計算機と通信プロトコルの異なるリクエスタ実行計算機に対して、動的にサービスの機能を提供することを可能にすることを目的とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するため、本発明は、サービス機能提供装置の記憶部にリクエスタ実行計算機およびサービス実行計算機からの公開情報を登録し、サービス機能提供装置の処理部が、記憶部の公開情報からリクエスタおよびサービスのそれぞれに対応するリクエスト受付およびアダプタを生成する。
【発明の効果】
【０００８】
本発明によれば、サービス実行計算機と通信プロトコルの異なるリクエスタ実行計算機に対して、動的にサービスの機能を提供することが可能になる。
【発明を実施するための最良の形態】
【０００９】
次に、本発明を実施するための最良の形態（以下、「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
図１は、本実施形態におけるサービス機能提供システムの構成を示す図である。図１に示すように、サービス機能提供システム１０は、サービス実行計算機１００と、リクエスタ実行計算機１６０と、ＥＳＢ実行計算機（サービス機能提供装置）１１０とがネットワーク１２００を介して相互に通信することが可能に構成される。
【００１０】
リクエスタ実行計算機１６０は、記憶部としてのメモリ１１０５と、処理部としてのＣＰＵ（Central Processing Unit）１１０４とを含んで構成される。メモリ１１０５は、スタブ１１０６と、サービス１００Ａの実行をサービス実行計算機１００に要求するプログラムであるリクエスタ１６０Ａとを格納しており、ＣＰＵ１１０４は、リクエスタ１６０Ａを実行することによって、ＥＳＢ実行計算機１１０を介して、サービス１００Ａの実行をサービス実行計算機１００に要求する。図１では、リクエスタ実行計算機１６０が３台示されているが、リクエスタ実行計算機１６０の台数は特に限定されるものではない。スタブ１１０６は、ユーザがリクエスタ１６０Ａを作成する際にＪ２ＥＥ（Java（登録商標） 2 Enterprise Edition）サーバなどの実行環境が提供しているコマンドを入力して生成することとしてもよいし、Ｊ２ＥＥサーバなどの製品が提供しているものを取り込むことによって生成することとしてもよい。スタブ１１０６については、図１４のステップＳ７０１の処理などで用いられる。
【００１１】
サービス実行計算機１００は、メモリ１１０２と、ＣＰＵ１１０１とを含んで構成される。メモリ１１０２は、リクエスタ実行計算機１６０に機能を提供するためのプログラムであるサービス１００Ａを格納しており、ＣＰＵ１１０１は、リクエスタ実行計算機１６０からの要求に従ってサービス１００Ａを実行することによって、サービス１００Ａの機能をリクエスタ実行計算機１６０に提供する。サービス１００Ａには、例えば、入金処理、出金処理を実行するためのコードが記述されている。図１では、サービス実行計算機１００が３台示されているが、サービス実行計算機１００の台数は特に限定されるものではない。
【００１２】
ＥＳＢ実行計算機１１０は、メモリ１７０と、ＣＰＵ１８０とを含んで構成される。メモリ１７０は、ＥＳＢプログラム（サービス機能提供プログラム）１３０と、サービスレジストリ１９０と、電文フォーマット１３００とを格納している。ＥＳＢプログラム１３０は、アダプタ生成処理部１２０と、リクエスト受付生成処理部１２１と、運用制御部１２２と、アダプタ選択制御部１２３と、マッチング制御部１２４と、アダプタ１４０と、リクエスト受付１５０とを含んで構成される。サービスレジストリ１９０は、リクエスタ公開情報テーブル１９１と、サービス公開情報テーブル１９２とを含んで構成される。
【００１３】
リクエスト受付１５０は、リクエスタ１６０Ａからサービス要求を受け取り、アダプタ１４０に転送し、処理結果をアダプタ１４０から受け取り、リクエスタ１６０Ａに返す処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。図１では、リクエスト受付１５０が３つ示されており、リクエスト受付１５０の数は特に限定されるものではないが、リクエスト受付１５０は、リクエスタ１６０Ａと１対１で対応している。
【００１４】
アダプタ１４０は、リクエスト受付１５０からサービス要求を受け取り、サービス１００Ａに転送し、処理結果をサービス１００Ａから受け取り、リクエスト受付１５０に返す処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。図１では、アダプタ１４０が３つ示されており、アダプタ１４０の数は特に限定されるものではないが、アダプタ１４０は、サービス１００Ａと１対１で対応している。
【００１５】
アダプタ生成処理部１２０は、アダプタ１４０を生成する処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。アダプタ生成処理部１２０についての詳細は後記する（図１８参照）。
【００１６】
リクエスト受付生成処理部１２１は、リクエスト受付１５０を生成する処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。リクエスト受付生成処理部１２１についての詳細は後記する（図８参照）。
【００１７】
運用制御部１２２は、サービス１００Ａの起動を制御する処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。運用制御部１２２についての詳細は後記する（図２４参照）。
【００１８】
アダプタ選択制御部１２３は、アダプタ１４０を選択する処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。アダプタ選択制御部１２３についての詳細は後記する（図１６参照）。
【００１９】
マッチング制御部１２４は、複数のサービス１００Ａの中から最適なサービス１００Ａを選択する処理が記述されたプログラムである。このプログラムは、ＣＰＵ１８０によって実行される。マッチング制御部１２４についての詳細は後記する（図１７参照）。
【００２０】
図２は、本実施形態におけるリクエスタ公開情報テーブルのデータ構造を示す図である。図２に示すように、リクエスタ公開情報テーブル１９１は、公開情報エントリ２０１を含んで構成される。公開情報エントリ２０１の数は特に限定されるものではない。公開情報エントリ２０１は、リクエスタ１６０Ａの公開情報を示しており、リクエスタ名２０２と、Ｉ／Ｆ（インタフェース）情報２０３と、運用ポリシ２０４とを含んで構成される。
【００２１】
リクエスタ名２０２は、リクエスタ１６０Ａ（図１参照）を一意に識別するための情報である。
【００２２】
Ｉ／Ｆ情報２０３は、プロトコル情報２０５と、電文情報２０６と、宛先情報２０７とを含んで構成される。プロトコル情報２０５は、ＨＴＴＰ（HyperText Transfer Protocol）、ＳＯＡＰ（Simple Object Access Protocol）、ＪＭＳ（Java（登録商標） Message Service）などの通信プロトコルを示すものである。電文情報２０６は、リクエスタ実行計算機１６０（図１参照）がＥＳＢ実行計算機１１０（図１参照）に送信する電文のフォーマット種別を示すものである。宛先情報２０７は、リクエスタ実行計算機１６０（図１参照）が送信する電文の宛先となるリクエスト受付１５０（図１参照）のＩＰ（Internet Protocol）アドレスや、ＵＲＬ（Uniform Resource Locator）、キューの名前などを示すものである。
【００２３】
運用ポリシ２０４は、優先度２０８と、障害時の動作２０９とを含んで構成される。優先度２０８は、ＥＳＢ実行計算機１１０（図１参照）がサービス実行計算機１００（図１参照）に電文を送信する際の優先度を示すものである。障害時の動作２０９は、ＥＳＢ実行計算機１１０（図１参照）がサービス実行計算機１００（図１参照）に電文を送信する際に障害が発生した場合の動作を示すものである。
【００２４】
図３は、本実施形態におけるリクエスタ公開情報テーブルに登録されるデータおよび電文フォーマットの例を示す図であり、図３（ａ）は、リクエスタ公開情報テーブルに登録されるデータの例であり、図３（ｂ）は、ＸＳＤ形式で記述された電文フォーマットの例を示す図であり、図３（ｃ）は、ＷＳＤＬ（Web Services Description Language）形式で記述された電文フォーマットの例を示す図である。
【００２５】
図３（ａ）に示すように、リクエスタ公開情報テーブル１９１にデータが２件登録されているが、登録される情報の件数はこれに限定されない。図３（ｂ）は、電文フォーマット１３００（図１参照）がＸＭＬ Ｓｃｈｅｍａ（Extensible Markup Language Schema）で定義されている場合の例を示している。これは、図３（ａ）の１件目のデータ（♯１）の電文情報に対応するフォーマットである。また、図３（ｃ）は、電文フォーマット１３００（図１参照）がＷＳＤＬ（Web Services Description Language）で定義されている場合の例を示している。これは、図３（ａ）の２件目のデータ（♯２）の電文情報に対応するフォーマットである。
【００２６】
図４は、本実施形態におけるサービス公開情報テーブルのデータ構造を示す図である。図４に示すように、サービス公開情報テーブル１９２は、公開情報エントリ３０１を含んで構成される。公開情報エントリ３０１の数は特に限定されるものではない。公開情報エントリ３０１は、サービス１００Ａの公開情報を示しており、サービス名３０２と、Ｉ／Ｆ情報３０３と、運用ポリシ３０４と、アダプタ情報３０５とを含んで構成される。
【００２７】
サービス名３０２は、サービス１００Ａ（図１参照）を一意に識別するための情報である。
【００２８】
Ｉ／Ｆ情報３０３は、プロトコル情報３０６と、電文情報３０７と、宛先情報３０８とを含んで構成される。プロトコル情報３０６は、ＨＴＴＰ、ＳＯＡＰ、ＪＭＳなどの通信プロトコルを示すものである。電文情報３０７は、ＥＳＢ実行計算機１１０（図１参照）がサービス実行計算機１００（図１参照）に送信する電文のフォーマット種別を示すものである。宛先情報３０８は、ＥＳＢ実行計算機１１０（図１参照）が送信する電文の宛先となるサービス１００Ａ（図１参照）のＩＰアドレスや、ＵＲＬ、キューの名前などを示すものである。
【００２９】
運用ポリシ３０４は、稼動時間３０９と、負荷容量３１０とを含んで構成される。稼動時間３０９は、サービス１００Ａ（図１参照）の稼働している時間を示すものである。負荷容量３１０は、アダプタ１４０（図１参照）がリクエスト受付１５０（図１参照）から受け付けた電文を処理し、サービス実行計算機１００（図１参照）に送信することが可能な量を示すものである。
【００３０】
アダプタ情報３０５は、生成情報３１１と、アドレス情報３１２とを含んで構成される。生成情報３１１は、アダプタ１４０（図１参照）が生成されているか否かを示すものである。アドレス情報３１２は、生成されたアダプタ１４０（図１参照）の転送先であるサービス１００ＡのアドレスをＩＰアドレスや、ＵＲＬなどで示すものである。
【００３１】
図５は、本実施形態におけるサービス公開情報テーブルに登録されるデータの例を示す図である。図５に示すように、サービス公開情報テーブル１９２にデータが２件登録されているが、登録されるデータの件数はこれに限定されない。
【００３２】
図６は、本実施形態におけるリクエスタがＥＳＢ実行計算機に送信するリクエスト要求を示す図である。図６に示すように、リクエスト要求４００は、制御部４０１と、データ部４０２とを含んで構成される。さらに、制御部４０１は、リクエスタ名４０３と、宛先サービス名４０４とを含んで構成される。
【００３３】
リクエスタ名４０３は、リクエスト要求４００の送信元のリクエスタ実行計算機１６０（図１参照）を一意に識別するための情報である。宛先サービス名４０４は、リクエスト要求４００の送信先のサービス１００Ａ（図１参照）を一意に識別するための情報である。データ部４０２は、リクエスタ実行計算機１６０（図１参照）が要求するサービス機能の内容を示す電文である。
【００３４】
図７は、図６のリクエスト要求の例を示す図である。データ部４０２には例として、ＸＭＬで記述されたデータが設定されている。
【００３５】
図８は、本実施形態におけるリクエスタ公開情報登録処理を示すフローチャートである。このリクエスタ公開情報登録処理は、リクエスト受付生成処理部１２１がＣＰＵ１８０によって実行されることによって行われる。以下、図８を参照して（適宜図１ないし図７参照）、リクエスタ公開情報登録処理Ｓ５００の流れを説明する。
【００３６】
まず、ＣＰＵ１８０は、リクエスト受付生成処理部１２１の実行により、リクエスタ実行計算機１６０からリクエスタ公開情報を受け取る（ステップＳ５０１）。リクエスタ公開情報を受け取る方法としては、リクエスタ実行計算機１６０が、リクエスト受付生成処理部１２１の提供するコマンドなどを実行することにより受け取る方法などがある。次に、ＣＰＵ１８０は、受け取ったリクエスタ公開情報をリクエスタ公開情報テーブル１９１に公開情報エントリ２０１として登録し（ステップＳ５０２）、受け取ったリクエスタ公開情報のＩ／Ｆ情報２０３からリクエスト受付を生成する（ステップＳ５０３）。ＣＰＵ１８０は、生成したリクエスト受付を開始し（ステップＳ５０４）、リクエスタ実行計算機１６０に登録完了を通知して（ステップＳ５０５）、処理を終了する（ステップＳ５０６）。
【００３７】
図９は、図８のリクエスト受付生成処理の詳細を示すフローチャートである。このリクエスト受付生成処理は、リクエスト受付生成処理部１２１がＣＰＵ１８０によって実行されることによって行われる。以下、図９を参照して（適宜図１ないし図７参照）、リクエスタ公開情報のＩ／Ｆ情報２０３からリクエスト受付１５０を生成する処理Ｓ５０３の流れを説明する。
【００３８】
まず、ＣＰＵ１８０は、リクエスタ公開情報のプロトコル情報２０５を判定する（ステップＳ１５００）。プロトコル情報２０５が「ＳＯＡＰ」または「ＥＪＢ（登録商標）（Enterprise JavaBeans（登録商標）））」である場合（ステップＳ１５００で「ＳＯＡＰ」または「ＥＪＢ（登録商標）」）、同期リクエスト受付の生成処理を行い（ステップＳ１５０１）、処理を終了する（ステップＳ１５０３）。プロトコル情報２０５が「ＪＭＳ」である場合は、非同期リクエスト受付の生成処理を行い（ステップＳ１５０２）、処理を終了する（ステップＳ１５０３）。ここでは、プロトコル情報２０５が「ＳＯＡＰ」「ＥＪＢ（登録商標）」または「ＪＭＳ」の場合について説明したが、その他の場合であっても、プロトコル情報２０５が同期の通信プロトコルの場合にはステップＳ１５０１を実行し、プロトコル情報２０５が非同期の通信プロトコルの場合にはステップＳ１５０２を実行する。
【００３９】
図１０は、本実施形態におけるリクエスト受付生成処理で生成されるリクエスト受付の構造を示す図である。
【００４０】
ＥＪＢ（登録商標）リクエスト受付２２００は、リクエスト受付定義ファイル２２０２と、ＥＪＢ（登録商標）アプリケーション２２０３とを含んで構成される。リクエスト受付定義ファイル２２０２は、リクエスト受付１５０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図１１参照）。ＥＪＢ（登録商標）アプリケーション２２０３は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取り、処理する際に用いるアプリケーションである。
【００４１】
ＳＯＡＰリクエスト受付２２０５は、リクエスト受付定義ファイル２２０６と、ＳＯＡＰアプリケーション２２０７とを含んで構成される。リクエスト受付定義ファイル２２０６は、リクエスト受付１５０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図１１参照）。ＳＯＡＰアプリケーション２２０７は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取り、処理する際に用いるアプリケーションである。
【００４２】
ＪＭＳリクエスト受付２２０８は、キュー２２１０と、リクエスト受付定義ファイル２２０９と、ＪＭＳアプリケーション２２１１とを含んで構成される。リクエスト受付定義ファイル２２０９は、リクエスト受付１５０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図１２参照）。キュー２２１０は、リクエスト要求（図６参照）のデータ部４０２（図６参照）を格納するものである。ＪＭＳアプリケーション２２１１は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取ると、キュー２２１０に格納し、順番に従ってキュー２２１０からサービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を取り出し、処理する際に用いるアプリケーションである。
【００４３】
図１１は、図９の同期リクエスト受付を生成する処理の詳細を示すフローチャートである。以下、図１１を参照して（適宜図１ないし図７参照）、同期リクエスト受付を生成する処理Ｓ１５０１の流れを説明する。
【００４４】
まず、ＣＰＵ１８０は、リクエスタ公開情報のリクエスタ名２０２およびプロトコル情報２０５をリクエスト受付定義ファイル１７００に定義する（ステップＳ１７０１）。リクエスト受付定義ファイル１７００には、図３の＃２の公開情報エントリのデータ（リクエスタ名およびプロトコル情報）がそれぞれ、リクエスタ名１７１０およびプロトコル情報１７１１に設定されている例が示されている。なお、リクエスト受付定義ファイル１７００の最初の２行の内容については予め決められている。次に、ＣＰＵ１８０は、リクエスタ公開情報の電文情報２０６が示すＷＳＤＬファイルから宛先情報を取得し、リクエスト受付定義ファイル１７００に定義する（ステップＳ１７０２）。リクエスト受付定義ファイル１７００の例では、図３の＃２の公開情報エントリの電文情報が「service1.wsdl」であるので、図３（ｃ）に示した「service1.wsdl」から宛先情報を取得する。リクエスト受付定義ファイル１７００の宛先情報１７１２には「http://aaa」が設定されている例が示されている。
【００４５】
ＣＰＵ１８０は、電文情報２０６が示すＷＳＤＬファイルからすべてのオペレーションを取得し（ステップＳ１７０３）、すべてのオペレーションに対して処理（ステップＳ１７０４〜ステップＳ１７０６）を行う（ステップＳ１７０９）。すなわち、電文情報１７１３の＜ｎａｍｅ＞タグにオペレーション名を定義し（ステップＳ１７０４）、電文情報１７１３の＜ｉｎｐｕｔ＞タグに要求情報を定義し（ステップＳ１７０５）、電文情報１７１３の＜ｏｕｔｐｕｔ＞タグに応答情報を定義する（ステップＳ１７０６）。リクエスト受付定義ファイル１７００の例では、図３の＃２の公開情報エントリの電文情報が「service1.wsdl」であるので、図３（ｃ）に示した「service1.wsdl」からオペレーションを取得する。オペレーション名、要求情報および応答情報は、取得したオペレーションに記述されている。リクエスト受付定義ファイル１７００では、ＷＳＤＬファイルによって生成される要求情報の電文フォーマットが＜ｉｎｐｕｔ＞タグの＜ｆｏｒｍａｔ−ｆｉｌｅ＞に定義され、フォーマットの種別が＜ｉｎｐｕｔ＞タグの＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞に定義されている。また、ＷＳＤＬから生成される応答情報の電文フォーマットが＜ｏｕｔｐｕｔ＞タグの＜ｆｏｒｍａｔ−ｆｉｌｅ＞に定義され、フォーマットの種別が＜ｏｕｔｐｕｔ＞タグの＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞に定義されている。＜ｆｏｒｍａｔ−ｆｉｌｅ＞がｘｓｄ形式の場合、＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞にはＸＭＬが設定されるが、ｘｓｄ形式には限定されず、ｘｓｄ形式以外の形式でも固有のフォーマット種別が設定される。
【００４６】
生成したリクエスト受付定義ファイル１７００（リクエスト受付定義ファイル２２０２（図１０参照）または２２０６（図１０参照））とプロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２２０３（図１０参照）またはＳＯＡＰアプリケーション２２０７（図１０参照））とをパッケージングして（ステップＳ１７０７）、処理を終了する（ステップＳ１７０８）。このパッケージングによって、リクエスト受付１５０（ＥＪＢ（登録商標）リクエスト受付２２００（図１０参照）またはＳＯＡＰリクエスト受付２２０５（図１０参照））が生成される。ここで、プロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２２０３（図１０参照）またはＳＯＡＰアプリケーション２２０７（図１０参照））は、例えば、Ｊ２ＥＥサーバなどの製品が提供しているアプリケーション（不図示）がメモリ１７０に格納されている場合、そのアプリケーションをコピーすることによって取得される。電文情報１７１３は、プロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２２０３（図１０参照）またはＳＯＡＰアプリケーション２２０７（図１０参照））が実行される際に用いられる。
【００４７】
図１２は、図９の非同期リクエスト受付を生成する処理の詳細を示すフローチャートである。以下、図１２を参照して（適宜図１ないし図７参照）、非同期リクエスト受付を生成する処理Ｓ１５０２の流れを説明する。
【００４８】
まず、ＣＰＵ１８０は、リクエスタ公開情報のリクエスタ名２０２およびＩ／Ｆ情報２０３をリクエスト受付定義ファイル１８００に定義する（ステップＳ１８０１）。リクエスト受付定義ファイル１８００には、図３の＃１の公開情報エントリのデータ（リクエスタ名、プロトコル情報、電文情報および宛先情報）がそれぞれ、リクエスタ名１８１０、プロトコル情報１８１１、電文情報１８１３の＜ｉｎｐｕｔ＞タグおよび宛先情報１８１２に設定されている例が示されている。電文情報１８１３のオペレーションの＜ｎａｍｅ＞タグには固定でｓｅｎｄを定義する。なお、リクエスト受付定義ファイル１８００の最初の２行の内容については予め決められている。ここで、Ｉ／Ｆ情報２０３の宛先情報２０７に宛先が設定されていない場合、＜ｕｒｌ＞の行を省略する方法や、＜ｕｒｌ＞と＜／ｕｒｌ＞との間に何も設定しない方法などがある。要求の情報として＜ｉｎｐｕｔ＞タグに、電文情報で定義した要求の電文フォーマットとフォーマットの種別を定義する。次に、ＣＰＵ１８０は、宛先情報のＵＲＬの有無を判定する（ステップＳ１８０２）。ＵＲＬが存在する場合（ステップＳ１８０３で「有り」）、ＣＰＵ１８０は、ＵＲＬを転送先とした転送用のキュー２２１０（図１０参照）を作成し(ステップＳ１８０４)、ステップＳ１８０６に進む。ＵＲＬが存在しない場合（ステップＳ１８０３で「無し」）、ＣＰＵ１８０は、ローカル用のキュー２２１０（図１０参照）を作成し（ステップＳ１８０５）、ステップＳ１８０６に進む。
【００４９】
ＣＰＵ１８０は、ステップＳ１８０６では、生成したリクエスト受付定義ファイル１８００（リクエスト受付定義ファイル２２０９（図１０参照）と、作成したキュー２２１０（図１０参照）と、アプリケーション（ＪＭＳアプリケーション２２１１（図１０参照））とをパッケージングして（ステップＳ１８０６）、処理を終了する（ステップＳ１８０７）。このパッケージングによって、リクエスト受付１５０（ＪＭＳリクエスト受付２２０８（図１０参照））が生成される。ここで、アプリケーション（ＪＭＳアプリケーション２２１１（図１０参照））は、例えば、Ｊ２ＥＥサーバなどの製品が提供しているアプリケーション（不図示）がメモリ１７０に格納されている場合、そのアプリケーションをコピーすることによって取得される。電文情報１８１３は、アプリケーション（ＪＭＳアプリケーション２２１１（図１０参照））が実行される際に用いられる。
【００５０】
図１３は、本実施形態におけるサービス公開情報登録処理を示すフローチャートである。このサービス公開情報登録処理は、アダプタ生成処理部１２０がＣＰＵ１８０によって実行されることによって行われる。以下、図１３を参照して（適宜図１ないし図７参照）、サービス公開情報登録処理Ｓ６００の流れを説明する。
【００５１】
まず、ＣＰＵ１８０は、アダプタ生成処理部１２０の実行により、サービス実行計算機１００からサービス公開情報を受け取る（ステップＳ６０１）。サービス公開情報を受け取る方法としては、サービス実行計算機１００が、アダプタ生成処理部１２０の提供するコマンドなどを実行することにより受け取る方法などがある。次に、ＣＰＵ１８０は、受け取ったサービス公開情報をサービス公開情報テーブル１９２に公開情報エントリ３０１として登録する（ステップＳ６０２）。このとき、生成情報３１１は「未配備」に設定される。ＣＰＵ１８０は、登録が完了したらサービス実行計算機１００に登録完了を通知して（ステップＳ６０３）、処理を終了する（ステップＳ６０４）。
【００５２】
図１４は、本実施形態におけるサービス呼び出し処理を示すフローチャートである。このサービス呼び出し処理は、ＥＳＢプログラム１３０がＣＰＵ１８０によって実行されることによって行われる。以下、図１４を参照して（適宜図１ないし図７参照）、サービス呼び出し処理Ｓ７００の流れを説明する。
【００５３】
まず、ＣＰＵ１８０は、リクエスタ実行計算機１６０からリクエスト要求４００を受け取り、リクエスト受付１５０が、サービス要求（リクエスト要求４００のデータ部４０２）を受け取る（ステップＳ７０１）。ここで、リクエスタ実行計算機１６０は、例えば通信プロトコルとしてＥＪＢ（登録商標）を用いる場合、スタブ１１０６を呼び出すことによってリクエスト要求４００を送信する。ＣＰＵ１８０は、サービスレジストリ１９０のリクエスタ公開情報テーブル１９１からリクエスト要求４００のリクエスタ名４０３に該当する公開情報エントリ２０１を取り出す（ステップＳ７０２）。次に、ＣＰＵ１８０は、リクエスト要求４００から宛先サービス名４０４を取り出し（ステップＳ７０３）、アダプタ選択制御処理を実行する（ステップＳ７０４）。ＣＰＵ１８０は、アダプタ選択制御処理によって選択された公開情報エントリ３０１内のアダプタ情報３０５の生成情報３１１を判定する（ステップＳ７０５）。生成情報３１１が「開始済み」の場合（ステップＳ７０６で「開始済み」）、ステップＳ７０８に進む。生成情報３１１が「未配備」の場合（ステップＳ７０６で「未配備」）、アダプタ生成処理を実行し（ステップＳ７０７）、ステップＳ７０８に進む。
【００５４】
リクエスト受付１５０は、アダプタ選択制御処理によって選択された公開情報エントリ３０１内のアダプタ情報３０５のアドレス情報３１２で指定されるアダプタ１４０にサービス要求（リクエスト要求４００のデータ部４０２）を出す（ステップＳ７０８）。アダプタ１４０は、サービス要求（リクエスト要求４００のデータ部４０２）を受け取る（ステップＳ７０９）。その後、アダプタ１４０によってサービス要求（リクエスト要求４００のデータ部４０２）がサービス１００Ａに送信され、サービス実行計算機１００によってサービス１００Ａが実行される。サービス１００Ａは、例えば、図７のデータ部４０２を受信した場合、＜ｉｎ０＞タグで囲まれた文字列である「Ｈｅｌｌｏ！」をリクエスタ１６０Ａに返し、リクエスタ実行計算機１６０のブラウザウィンドウ（不図示）に表示する。リクエスト受付１５０は、サービス実行計算機１００からの応答を判定し（ステップＳ７１０）、応答が無い場合（ステップＳ７１０で「無し」）、処理を終了する（ステップＳ７１３）。例えば、非同期で要求した場合などに応答データがない場合がある。応答が正常な場合（ステップＳ７１０で「正常」）、リクエスタ１６０Ａに応答データを返し、処理を終了する（ステップＳ７１３）。応答がエラーの場合（ステップＳ７１０で「エラー」）、運用制御部１２２が運用制御処理を実行して（ステップＳ７１１）、処理を終了する（ステップＳ７１３）。
【００５５】
図１５は、図１４のリクエスト受付がサービス要求を受け取る処理の詳細を示すフローチャートである。この処理は、ＥＳＢプログラム１３０がＣＰＵ１８０によって実行されることによって行われる。また、この処理によって、リクエスト受付１５０はサービス要求を受け取ることができる。以下、図１５を参照して（適宜図１ないし図７参照）、リクエスト受付１５０がサービス要求を受け取る処理Ｓ７０１の流れを説明する。
【００５６】
まず、ＣＰＵ１８０は、リクエスト要求４００のリクエスタ名４０３を取り出し（ステップＳ２３０１）、該当するリクエスト受付１５０のリクエスト受付定義ファイル１７００（図１１参照）または１８００（図１２参照）（リクエスト受付定義ファイル２２０２、２２０６または２２０９（図１０参照））からプロトコル情報１７１１（図１１参照）または１８１１（図１２参照）を取り出す（ステップＳ２３０２）。ここで、該当するリクエスト受付１５０とは、リクエスタ名４０３と一致するリクエスタ名１７１０（図１１参照）または１８１０（図１２参照）が定義されているリクエスト受付定義ファイル２２０２、２２０６または２２０９（図１０参照）を検索することで取得される。
【００５７】
プロトコル情報１８１１（図１２参照）が「ＪＭＳ」の場合（ステップＳ２３０３で「ＪＭＳ」）、該当するリクエスト受付１５０（ＪＭＳリクエスト受付２２０８（図１０参照））のキュー２２１０（図１０参照）にリクエスト要求４００のデータ部４０２を書き込み（ステップＳ２３０４）、処理を終了する（ステップＳ２３０７）。
【００５８】
プロトコル情報１７１１（図１１参照）が「ＳＯＡＰ」の場合（ステップＳ２３０３で「ＳＯＡＰ」）、ＳＡＡＪ（SOAP with Attachments API for Java（登録商標））のＡＰＩ（Application Program Interface）を用いたＳＯＡＰ通信によって、該当するリクエスト受付１５０（ＳＯＡＰリクエスト受付２２０５（図１０参照））のリクエスト受付定義ファイル２２０６（図１０参照）に定義された宛先（宛先情報１７１２（図１１参照））にリクエスト要求４００のデータ部４０２を送信し（ステップＳ２３０５）処理を終了する（ステップＳ２３０７）。
【００５９】
プロトコル情報１７１１（図１１参照）が「ＥＪＢ（登録商標）」の場合（ステップＳ２３０３で「ＥＪＢ（登録商標）」）、該当するリクエスト受付１５０（ＥＪＢ（登録商標）リクエスト受付２２００（図１０参照））のリクエスト受付定義ファイル２２０２で定義した宛先（宛先情報１７１２（図１１参照））にリクエスト要求４００のデータ部４０２を送信し（ステップＳ２３０６）、処理を終了する（ステップＳ２３０７）。
【００６０】
ここでは、プロトコル情報１７１１（図１１参照）（プロトコル情報１８１１（図１２参照））が「ＳＯＡＰ」「ＥＪＢ（登録商標）」または「ＪＭＳ」の場合について説明したが、その他の場合であっても、各種の通信プロトコルに基づいてリクエスト要求４００のデータ部４０２を送信する処理を実行する。
【００６１】
図１６は、図１４のアダプタ選択制御処理の詳細を示すフローチャートである。この処理は、アダプタ選択制御部１２３がＣＰＵ１８０によって実行されることによって行われる。以下、図１６を参照して（適宜図１ないし図７参照）、アダプタ選択制御処理Ｓ７０４の流れを説明する。
【００６２】
まず、ＣＰＵ１８０は、サービスレジストリ１９０のサービス公開情報テーブル１９２からリクエスト要求４００のリクエスタ名４０３と一致するサービス名３０２の公開情報エントリ３０１を選択する（ステップＳ８０１）。ＣＰＵ１８０は、取り出した公開情報エントリ３０１が複数存在するか否かを判定する（ステップＳ８０２）。複数存在しない場合（ステップＳ８０２で「Ｎｏ」）、ステップＳ８０４に進む。複数存在する場合（ステップＳ８０２で「Ｙｅｓ」）、マッチング制御処理を実行して（ステップＳ８０３）、ステップＳ８０４に進む。
【００６３】
ステップＳ８０４では、選択された１つの公開情報エントリ３０１をリクエスト受付１５０に返す（ステップＳ８０４）、処理を終了する（ステップＳ８０５）。
【００６４】
図１７は、図１６のマッチング制御処理の詳細を示すフローチャートである。この処理は、マッチング制御部１２４がＣＰＵ１８０によって実行されることによって行われる。以下、図１７を参照して（適宜図１ないし図７参照）、マッチング制御処理Ｓ８０３の流れを説明する。
【００６５】
まず、ＣＰＵ１８０は、ステップＳ８０１（図１６参照）で選択された公開情報エントリ３０１から運用ポリシ３０４の稼動時間３０９を取得し、現在時刻が稼動時間３０９内である公開情報エントリ３０１を選択する（ステップＳ９０１）。ＣＰＵ１８０は、選択された公開情報エントリ３０１が複数であるか否かを判定する（ステップＳ９０２）。複数でない場合（ステップＳ９０２で「Ｎｏ」）、処理を終了する（ステップＳ９０７）。複数の場合（ステップＳ９０２で「Ｙｅｓ」）、ステップＳ７０２（図１４参照）で取り出された公開情報エントリ２０１の優先度２０８を判定する（ステップＳ９０３）。優先度が「高」の場合（ステップＳ９０４で「高」）、選択された公開情報エントリ３０１のうち、運用ポリシ３０４の負荷容量３１０の値が最も大きい公開情報エントリ３０１を選択し（ステップＳ９０５）、処理を終了する（ステップＳ９０７）。優先度が「低」の場合（ステップＳ９０４で「低」）、選択された公開情報エントリ３０１のうち、運用ポリシ３０４の負荷容量３１０の値が最も小さい公開情報エントリ３０１を選択し（ステップＳ９０６）、処理を終了する（ステップＳ９０７）。
【００６６】
このように、サービス実行計算機１００が、公開情報エントリ３０１に稼動時間３０９を登録することによって、ＥＳＢ実行計算機１１０が稼動時間３０９と現在時刻とを比較し、複数のサービス１００Ａから稼動時間３０９の範囲内のサービス１００Ａを選択することができる。つまり、リクエスタ１６０Ａが優先して呼び出すサービス１００Ａの運用ポリシを予めＥＳＢ実行計算機１１０に登録しておく必要がなくなるという効果がある。
【００６７】
また、リクエスタ実行計算機１６０が、公開情報エントリ２０１に優先度２０８を登録し、サービス実行計算機１００が、公開情報エントリ３０１に負荷容量３１０を登録することによって、ＥＳＢ実行計算機１１０が優先度２０８に合った負荷容量３１０のサービス１００Ａを選択することができる。つまり、リクエスタ１６０Ａが優先して呼び出すサービス１００Ａの運用ポリシを予めＥＳＢ実行計算機１１０に登録しておく必要がなくなるという効果がある。
【００６８】
図１８は、図１４のアダプタ生成処理の詳細を示すフローチャートである。この処理は、アダプタ生成処理部１２０がＣＰＵ１８０によって実行されることによって行われる。以下、図１８を参照して（適宜図１ないし図７参照）、アダプタ生成処理Ｓ７０７の流れを説明する。
【００６９】
まず、ＣＰＵ１８０は、サービス公開情報のＩ／Ｆ情報３０３からアダプタ１４０を生成する（ステップＳ６１０）。ＣＰＵ１８０は、生成したアダプタ１４０を開始して（ステップＳ６１１）、生成したアダプタの情報をアダプタ情報３０５に記録する（ステップＳ６１２）。ここでは、アダプタ情報３０５の生成情報３１１を「開始済み」に設定し、生成したアダプタのアドレスをアドレス情報３１２に設定する。その後、処理を終了する（ステップＳ７１２）。
【００７０】
図１９は、図１８のサービス公開情報のＩ／Ｆ情報からアダプタを生成する処理の詳細を示すフローチャートである。このリクエスト受付生成処理は、アダプタ生成処理部１２０がＣＰＵ１８０によって実行されることによって行われる。以下、図１９を参照して（適宜図１ないし図７参照）、サービス公開情報のＩ／Ｆ情報３０３からアダプタ１４０を生成する処理Ｓ６１０の流れを説明する。
【００７１】
まず、ＣＰＵ１８０は、サービス公開情報のプロトコル情報３０６を判定する（ステップＳ１６００）。プロトコル情報３０６が「ＳＯＡＰ」または「ＥＪＢ（登録商標）」である場合（ステップＳ１６００で「ＳＯＡＰ」または「ＥＪＢ（登録商標）」）、同期アダプタの生成処理を行い（ステップＳ１６０１）、処理を終了する（ステップＳ１６０３）。プロトコル情報３０６が「ＪＭＳ」である場合は、非同期アダプタの生成処理を行い（ステップＳ１６０２）、処理を終了する（ステップＳ１６０３）。ここでは、プロトコル情報３０６が「ＳＯＡＰ」「ＥＪＢ（登録商標）」または「ＪＭＳ」の場合について説明したが、その他の場合であっても、プロトコル情報３０６が同期の通信プロトコルの場合にはステップＳ１６０１を実行し、プロトコル情報３０６が非同期の通信プロトコルの場合にはステップＳ１６０２を実行する。
【００７２】
図２０は、本実施形態におけるアダプタ生成処理で生成されるアダプタの構造を示す図である。
【００７３】
ＥＪＢ（登録商標）アダプタ２１００は、スタブ２１０１と、アダプタ定義ファイル２１０２と、ＥＪＢ（登録商標）アプリケーション２１０３とを含んで構成される。アダプタ定義ファイル２１０２は、アダプタ１４０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図２１参照）。ＥＪＢ（登録商標）アプリケーション２１０３は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取り、処理する際に用いるアプリケーションである。
【００７４】
ＳＯＡＰアダプタ２１０５は、アダプタ定義ファイル２１０６と、ＳＯＡＰアプリケーション２１０７とを含んで構成される。アダプタ定義ファイル２１０６は、アダプタ１４０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図２１参照）。ＳＯＡＰアプリケーション２１０７は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取り、処理する際に用いるアプリケーションである。
【００７５】
ＪＭＳアダプタ２１０８は、キュー２１１０と、アダプタ定義ファイル２１０９と、ＪＭＳアプリケーション２１１１とを含んで構成される。アダプタ定義ファイル２１０９は、アダプタ１４０で必要となる情報を定義したファイルであるが、詳細な説明は後記する（図２２参照）。キュー２１１０は、リクエスト要求（図６参照）のデータ部４０２（図６参照）を格納するものである。ＪＭＳアプリケーション２１１１は、サービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を受け取ると、キュー２１１０に格納し、順番に従ってキュー２１１０からサービス要求（リクエスト要求４００（図６参照）のデータ部４０２（図６参照））を取り出し、処理する際に用いるアプリケーションである。
【００７６】
図２１は、図１９の同期アダプタを生成する処理の詳細を示すフローチャートである。以下、図２１を参照して（適宜図１ないし図７参照）、同期アダプタを生成する処理Ｓ１６０１の流れを説明する。
【００７７】
まず、ＣＰＵ１８０は、サービス公開情報のサービス名３０２およびプロトコル情報３０６をアダプタ定義ファイル１９００に定義する（ステップＳ１９０１）。アダプタ定義ファイル１９００には、図５の＃１の公開情報エントリのデータ（サービス名およびプロトコル情報）がそれぞれ、サービス名１９１０およびプロトコル情報１９１１に設定されている例が示されている。なお、アダプタ定義ファイル１９００の最初の２行の内容については予め決められている。次に、ＣＰＵ１８０は、サービス公開情報の電文情報３０７が示すＷＳＤＬファイルから宛先情報を取得し、アダプタ定義ファイル１９００に定義する（ステップＳ１９０２）。アダプタ定義ファイル１９００の例では、図５の＃１の公開情報エントリの電文情報が「service2.wsdl」であるので、「service2.wsdl」（不図示）から宛先情報を取得する。アダプタ定義ファイル１９００の宛先情報１９１２には「http://yyy/」が設定されている例が示されている。
【００７８】
ＣＰＵ１８０は、電文情報３０７が示すＷＳＤＬファイルからすべてのオペレーションを取得し（ステップＳ１９０３）、すべてのオペレーションに対して処理（ステップＳ１９０４〜ステップＳ１９０６）を行う（ステップＳ１９０９）。すなわち、電文情報１９１３の＜ｎａｍｅ＞タグにオペレーション名を定義し（ステップＳ１９０４）、電文情報１９１３の＜ｉｎｐｕｔ＞タグに要求情報を定義し（ステップＳ１９０５）、電文情報１９１３の＜ｏｕｔｐｕｔ＞タグに応答情報を定義する（ステップＳ１９０６）。アダプタ定義ファイル１９００の例では、図５の＃１の公開情報エントリの電文情報が「service2.wsdl」であるので、「service2.wsdl」（不図示）からオペレーションを取得する。オペレーション名、要求情報および応答情報は、取得したオペレーションに記述されている。アダプタ定義ファイル１９００では、ＷＳＤＬファイルによって生成される要求情報の電文フォーマットが＜ｉｎｐｕｔ＞タグの＜ｆｏｒｍａｔ−ｆｉｌｅ＞に定義され、フォーマットの種別が＜ｉｎｐｕｔ＞タグの＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞に定義されている。また、ＷＳＤＬから生成される応答情報の電文フォーマットが＜ｏｕｔｐｕｔ＞タグの＜ｆｏｒｍａｔ−ｆｉｌｅ＞に定義され、フォーマットの種別が＜ｏｕｔｐｕｔ＞タグの＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞に定義されている。＜ｆｏｒｍａｔ−ｆｉｌｅ＞がｘｓｄ形式の場合、＜ｍｅｓｓａｇｅ−ｔｙｐｅ＞にはＸＭＬが設定されるが、ｘｓｄ形式には限定されず、ｘｓｄ形式以外の形式でも固有のフォーマット種別が設定される。
【００７９】
アダプタ定義ファイル１９００（アダプタ定義ファイル２１０２（図２０参照）または２１０６（図２０参照））とプロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２１０３（図２０参照）またはＳＯＡＰアプリケーション２１０７（図２０参照））とをパッケージングして（ステップＳ１９０７）、処理を終了する（ステップＳ１９０８）。このパッケージングによって、アダプタ１４０（ＥＪＢ（登録商標）アダプタ２１００（図２０参照）またはＳＯＡＰアダプタ２１０５（図２０参照））が生成される。ここで、プロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２１０３（図２０参照）またはＳＯＡＰアプリケーション２１０７（図２０参照））は、例えば、Ｊ２ＥＥサーバなどの製品が提供しているアプリケーション（不図示）がメモリ１７０に格納されている場合、そのアプリケーションをコピーすることによって取得される。電文情報１９１３は、プロトコル別のアプリケーション（ＥＪＢ（登録商標）アプリケーション２１０３（図２０参照）またはＳＯＡＰアプリケーション２１０７（図２０参照））が実行される際に用いられる。なお、ＥＪＢ（登録商標）アダプタ２１００にはスタブ２１０１もパッケージングする必要がある。スタブ２１０１は、Ｊ２ＥＥサーバなどの実行環境が提供しているコマンドを実行して生成することとしてもよいし、Ｊ２ＥＥサーバなどの製品が提供しているものを取り込むことによって生成することとしてもよい。
【００８０】
図２２は、図１９の非同期アダプタを生成する処理を示すフローチャートである。以下、図２２を参照して（適宜図１ないし図７参照）、非同期アダプタを生成する処理Ｓ１６０２の流れを説明する。
【００８１】
まず、ＣＰＵ１８０は、サービス公開情報のサービス名３０２およびＩ／Ｆ情報３０３をアダプタ定義ファイル２０００に定義する（ステップＳ２００１）。アダプタ定義ファイル２０００には、図５の＃２の公開情報エントリのデータ（サービス名、プロトコル情報、電文情報および宛先情報）がそれぞれ、サービス名２０１０、プロトコル情報２０１１、電文情報２０１３の＜ｉｎｐｕｔ＞タグおよび宛先情報２０１２に設定されている例が示されている。電文情報２０１３のオペレーションの＜ｎａｍｅ＞タグには固定でｓｅｎｄを定義する。なお、アダプタ定義ファイル２０００の最初の２行の内容については予め決められている。ここで、Ｉ／Ｆ情報３０３の宛先情報３０８に宛先が設定されていない場合、＜ｕｒｌ＞の行を省略する方法や、＜ｕｒｌ＞と＜／ｕｒｌ＞との間に何も設定しない方法などがある。要求の情報として＜ｉｎｐｕｔ＞タグに、電文情報で定義した要求の電文フォーマットとフォーマットの種別を定義する。次に、ＣＰＵ１８０は、宛先情報のＵＲＬの有無を判定する（ステップＳ２００２）。ＵＲＬが存在する場合（ステップＳ２００３で「有り」）、ＣＰＵ１８０は、ＵＲＬを転送先とした転送用のキュー２１１０（図２０参照）を作成し(ステップＳ２００４)、ステップＳ２００６に進む。ＵＲＬが存在しない場合（ステップＳ２００３で「無し」）、ＣＰＵ１８０は、ローカル用のキュー２１１０（図２０参照）を作成し（ステップＳ２００５）、ステップＳ２００６に進む。
【００８２】
ステップＳ２００６では、生成したアダプタ定義ファイル２０００（アダプタ定義ファイル２１０９（図２０参照）と、作成したキュー２１１０（図２０参照）と、アプリケーション（ＪＭＳアプリケーション２１１１（図２０参照））とをパッケージングして（ステップＳ２００６）、処理を終了する（ステップＳ２００７）。このパッケージングによって、アダプタ１４０（ＪＭＳアダプタ２１０８（図２０参照））が生成される。ここで、アプリケーション（ＪＭＳアプリケーション２１１１（図２０参照））は、例えば、Ｊ２ＥＥサーバなどの製品が提供しているアプリケーション（不図示）がメモリ１７０に格納されている場合、そのアプリケーションをコピーすることによって取得される。電文情報２０１３は、アプリケーション（ＪＭＳアプリケーション２１１１（図２０参照））が実行される際に用いられる。
【００８３】
図２３は、図１４のアダプタがサービス要求を受け取る処理の詳細を示すフローチャートである。この処理は、リクエスト受付１５０がＣＰＵ１８０によって実行されることによって行われる。また、この処理によって、アダプタ１４０はサービス要求を受け取ることができる。以下、図２３を参照して（適宜図１ないし図７参照）、アダプタ１４０がサービス要求を受け取る処理Ｓ７０９の流れを説明する。
【００８４】
まず、Ｓ７０８でサービス要求を出されたアダプタ１４０のアダプタ定義ファイル１９００（図２１参照）または２０００（図２２参照）（アダプタ定義ファイル２１０２、２１０６または２１０９（図２０参照））からプロトコル情報１９１１（図２１参照）または２０１１（図２２参照）を取り出す（ステップＳ２４０１）。
【００８５】
プロトコル情報２０１１（図２２参照）が「ＪＭＳ」の場合（ステップＳ２４０２で「ＪＭＳ」）、該当するアダプタ１４０（ＪＭＳアダプタ２１０８（図２０参照））のキュー２１１０（図２０参照）にリクエスト要求４００のデータ部４０２を書き込み（ステップＳ２４０３）、処理を終了する（ステップＳ２４０６）。
【００８６】
プロトコル情報１９１１（図２１参照）が「ＳＯＡＰ」の場合（ステップＳ２４０２で「ＳＯＡＰ」）、ＳＡＡＪのＡＰＩを用いたＳＯＡＰ通信によって、該当するアダプタ１４０（ＳＯＡＰアダプタ２１０５（図２０参照））のアダプタ定義ファイル２１０６（図２０参照）に定義された宛先（宛先情報１９１２（図２１参照））にリクエスト要求４００のデータ部４０２を送信し（ステップＳ２４０４）、処理を終了する（ステップＳ２４０６）。
【００８７】
プロトコル情報１９１１（図２１参照）が「ＥＪＢ（登録商標）」の場合（ステップＳ２４０２で「ＥＪＢ（登録商標）」）、スタブ２１０１を呼び出すことによって、アダプタ定義ファイル２１０２で定義した宛先（宛先情報１９１２（図２１参照））にリクエスト要求４００のデータ部４０２を送信し（ステップＳ２４０５）、処理を終了する（ステップＳ２４０６）。
【００８８】
このような処理によって、アダプタ１４０がサービス要求（リクエスト要求４００のデータ部４０２）をサービス１００Ａに送信し、サービス実行計算機１００によってサービス１００Ａが実行される。
【００８９】
ここでは、プロトコル情報１９１１（図２１参照）（プロトコル情報２０１１（図２２参照））が「ＳＯＡＰ」「ＥＪＢ（登録商標）」または「ＪＭＳ」の場合について説明したが、その他の場合であっても、各種の通信プロトコルに基づいてリクエスト要求４００のデータ部４０２を送信する処理を実行する。
【００９０】
図２４は、図１４の運用制御処理の詳細を示すフローチャートである。この運用制御処理は、運用制御部１２２がＣＰＵ１８０によって実行されることによって行われる。以下、図２４を参照して（適宜図１ないし図７参照）、運用制御処理Ｓ７１１の流れを説明する。
【００９１】
まず、ＣＰＵ１８０は、ステップＳ７０２（図１４参照）で取り出した公開情報エントリ２０１の運用ポリシ２０４から障害時の動作２０９を取得する（ステップＳ１０００）。障害時の動作２０９が「リトライ」の場合（ステップＳ１００１で「リトライ」）、サービス実行計算機１００にサービス起動要求（サービス１００Ａを起動する要求）を出す（ステップＳ１００２)。サービス１００Ａが起動され、サービス１００Ａが実行されて、サービス１００Ａから応答が返ってくると、ＣＰＵ１８０は、リクエスタ１６０Ａに応答を返し（ステップＳ１００４）、処理を終了する（ステップＳ１００６）。障害時の動作２０９が「エラー」の場合（ステップＳ１００１で「エラー」）、リクエスタ１６０Ａにエラーを返し（ステップＳ１００５）、処理を終了する（ステップＳ１００６）。
【００９２】
このように、サービス１００Ａの呼び出し要求があった場合、サービス１００Ａが開始されていなくても、ＥＳＢ実行計算機１１０がサービス１００Ａの起動を行い、サービス１００Ａを開始することができる。
【００９３】
本実施形態によれば、ＥＳＢ実行計算機１１０内のサービスレジストリ１９０にリクエスタ１６０Ａおよびサービス１００Ａからの公開情報を登録し、サービスレジストリ１９０の公開情報からリクエスタ１６０Ａおよびサービス１００Ａのそれぞれに対応するリクエスト受付およびアダプタを生成することができる。これにより、サービス実行計算機１００と通信プロトコルの異なるリクエスタ実行計算機１６０に対して、動的にサービス１００Ａの機能を提供することが可能になる。
【図面の簡単な説明】
【００９４】
【図１】本実施形態におけるサービス機能提供システムの構成を示す図である。
【図２】本実施形態におけるリクエスタ公開情報テーブルのデータ構造を示す図である。
【図３】本実施形態におけるリクエスタ公開情報テーブルに登録されるデータおよび電文フォーマットの例を示す図であり、（ａ）は、リクエスタ公開情報テーブルに登録されるデータの例であり、（ｂ）は、ＸＳＤ形式で記述された電文フォーマットの例を示す図であり、（ｃ）は、ＷＳＤＬ形式で記述された電文フォーマットの例を示す図である。
【図４】本実施形態におけるサービス公開情報テーブルのデータ構造を示す図である。
【図５】本実施形態におけるサービス公開情報テーブルに登録されるデータの例を示す図である。
【図６】本実施形態におけるリクエスタがＥＳＢ実行計算機に送信するリクエスト要求を示す図である。
【図７】図６のリクエスト要求の例を示す図である。
【図８】本実施形態におけるリクエスタ公開情報登録処理を示すフローチャートである。
【図９】図８のリクエスト受付生成処理の詳細を示すフローチャートである。
【図１０】本実施形態におけるリクエスト受付生成処理で生成されるリクエスト受付の構造を示す図である。
【図１１】図９の同期リクエスト受付を生成する処理の詳細を示すフローチャートである。
【図１２】図９の非同期リクエスト受付を生成する処理の詳細を示すフローチャートである。
【図１３】本実施形態におけるサービス公開情報登録処理を示すフローチャートである。
【図１４】本実施形態におけるサービス呼び出し処理を示すフローチャートである。
【図１５】図１４のリクエスト受付がサービス要求を受け取る処理の詳細を示すフローチャートである。
【図１６】図１４のアダプタ選択制御処理の詳細を示すフローチャートである。
【図１７】図１６のマッチング制御処理の詳細を示すフローチャートである。
【図１８】図１４のアダプタ生成処理の詳細を示すフローチャートである。
【図１９】図１８のサービス公開情報のインタフェース情報からアダプタを生成する処理の詳細を示すフローチャートである。
【図２０】本実施形態におけるアダプタ生成処理で生成されるアダプタの構造を示す図である。
【図２１】図１９の同期アダプタを生成する処理の詳細を示すフローチャートである。
【図２２】図１９の非同期アダプタを生成する処理を示すフローチャートである。
【図２３】図１４のアダプタがサービス要求を受け取る処理の詳細を示すフローチャートである。
【図２４】図１４の運用制御処理の詳細を示すフローチャートである。
【符号の説明】
【００９５】
１０    サービス機能提供システム
１００  サービス実行計算機
１００Ａ  サービス
１１０  ＥＳＢ実行計算機
１２０  アダプタ生成処理部
１２１  リクエスト受付生成処理部
１２２  運用制御部
１２３  アダプタ選択制御部
１２４  マッチング制御部
１３０  ＥＳＢプログラム
１４０  アダプタ
１５０  リクエスト受付
１６０  リクエスタ実行計算機
１６０Ａ  リクエスタ
１７０  メモリ
１８０  ＣＰＵ
１９０  サービスレジストリ
１９１  リクエスタ公開情報テーブル
１９２  サービス公開情報テーブル
２０１  公開情報エントリ
２０２  リクエスタ名
２０３  Ｉ／Ｆ（インタフェース）情報
２０４  運用ポリシ
２０５  プロトコル情報
２０６  電文情報
２０７  宛先情報
２０８  優先度
２０９  障害時の動作
３０１  公開情報エントリ
３０２  サービス名
３０３  Ｉ／Ｆ（インタフェース）情報
３０４  運用ポリシ
３０５  アダプタ情報
３０６  プロトコル情報
３０７  電文情報
３０８  宛先情報
３０９  稼動時間
３１１  生成情報
３１２  アドレス情報
４００  リクエスト要求
４０１  制御部
４０２  データ部
４０３  リクエスタ名
４０４  宛先サービス名
１１０１  ＣＰＵ
１１０２  メモリ
１１０４  ＣＰＵ
１１０５  メモリ
１１０６  スタブ
１２００  ネットワーク
１３００  電文フォーマット
【図１】
2008186105.tif 000003
【図２】
2008186105.tif 000004
【図３】
2008186105.tif 000005
【図４】
2008186105.tif 000006
【図５】
2008186105.tif 000007
【図６】
2008186105.tif 000008
【図７】
2008186105.tif 000009
【図８】
2008186105.tif 000010
【図９】
2008186105.tif 000011
【図１０】
2008186105.tif 000012
【図１１】
2008186105.tif 000013
【図１２】
2008186105.tif 000014
【図１３】
2008186105.tif 000015
【図１４】
2008186105.tif 000016
【図１５】
2008186105.tif 000017
【図１６】
2008186105.tif 000018
【図１７】
2008186105.tif 000019
【図１８】
2008186105.tif 000020
【図１９】
2008186105.tif 000021
【図２０】
2008186105.tif 000022
【図２１】
2008186105.tif 000023
【図２２】
2008186105.tif 000024
【図２３】
2008186105.tif 000025
【図２４】
2008186105.tif 000026