(57)【要約】【課題】プロバイダが応答メッセージを生成するのにかかる時間を短縮する。【解決手段】クライアント装置に対して送信する送信データの構造を定義するテンプレートと、テンプレート内における実行結果の挿入箇所を示す位置情報と、がアプリケーションに関連付けて格納されているか否かを判断する。格納されていると判断した場合には、テンプレートと、位置情報と、を取得する。格納されていないと判断した場合には、アプリケーションについて予め作成され且つテンプレート及び位置情報を規定するインタフェース定義文書を取得し、取得したインタフェース定義文書を用いてテンプレート及び位置情報を生成すると共に、生成したテンプレート及び位置情報をアプリケーションに関連付けて格納する。【選択図】図２
2012008885.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの実行結果を取得する実行手段と、
クライアント装置に対して送信する送信データの構造を定義するテンプレートと、該テンプレート内における前記実行結果の挿入箇所を示す位置情報と、が前記アプリケーションに関連付けて格納手段に格納されているか否かを判断する判断手段と、
格納されていると前記判断手段が判断した場合には、前記テンプレートと、前記位置情報と、を取得する第１の取得手段と、
格納されていないと前記判断手段が判断した場合には、前記アプリケーションについて予め作成され且つ前記テンプレート及び前記位置情報を規定するインタフェース定義文書を取得し、該取得したインタフェース定義文書を用いて前記テンプレート及び前記位置情報を生成すると共に、該生成したテンプレート及び位置情報を前記アプリケーションに関連付けて前記格納手段に格納する第２の取得手段と、
前記第１の取得手段若しくは前記第２の取得手段により得られたテンプレート中の、前記第１の取得手段若しくは前記第２の取得手段により得られた位置情報が示す箇所に、前記実行結果を挿入することによって前記送信データを生成する挿入手段と、
前記送信データを前記クライアント装置に対して送信する送信手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記インタフェース定義文書はＷＳＤＬ文書であることを特徴とする、請求項１に記載の情報処理装置。
【請求項３】
前記送信データはＸＭＬ文書であることを特徴とする、請求項１又は２に記載の情報処理装置。
【請求項４】
前記位置情報はＸＰａｔｈ式であることを特徴とする、請求項３に記載の情報処理装置。
【請求項５】
情報処理装置が行う情報処理方法であって、
前記情報処理装置の実行手段が、アプリケーションを実行することで実行結果を取得する実行工程と、
前記情報処理装置の判断手段が、クライアント装置に対して送信する送信データの構造を定義するテンプレートと、該テンプレート内における前記実行結果の埋め込み箇所を示す位置情報と、が前記アプリケーションに関連付けられているか否かを判断する判断工程と、
前記情報処理装置の第１の取得手段が、関連付けられていると前記判断工程で判断した場合には、前記テンプレートと、前記位置情報と、を取得する第１の取得工程と、
前記情報処理装置の第２の取得手段が、関連付けられていないと前記判断工程で判断した場合には、前記アプリケーションについて予め作成され且つ前記テンプレート及び前記位置情報を規定するインタフェース定義文書を取得し、該取得したインタフェース定義文書を用いて前記テンプレート及び前記位置情報を生成すると共に該生成したテンプレート及び位置情報を前記アプリケーションに関連付ける第２の取得工程と、
前記情報処理装置の埋め込み手段が、前記第１の取得工程若しくは前記第２の取得工程で得られたテンプレート中の、前記第１の取得工程若しくは前記第２の取得工程で得られた位置情報が示す箇所に、前記実行結果を埋め込む埋め込み工程と、
前記情報処理装置の送信手段が、前記埋め込み工程で得られる埋め込み後のテンプレートを、前記送信データとして前記クライアント装置に対して送信する送信工程と
を備えることを特徴とする情報処理方法。
【請求項６】
コンピュータを、請求項１乃至４の何れか１項に記載の情報処理装置が有する各手段として機能させるための、コンピュータプログラム。
【請求項７】
請求項６に記載のコンピュータプログラムを格納した、コンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスにおいて、アプリケーションの実行結果を含む応答メッセージを生成する技術に関する。
【背景技術】
【０００２】
コンピュータネットワークの普及によって、今日では様々なサービスがコンピュータネットワークを介して提供されている。例えばクライアントは、プロバイダに対して、Ｗｅｂサービスの処理の実行を要求することができる。このときクライアントは、プロバイダに対して、要求メッセージとして、ＸＭＬ文書の形でパラメータを与えることができる。こうして、プロバイダは与えられたパラメータに従って処理を行うことができる。そして、プロバイダは処理結果を含むＸＭＬ文書を応答メッセージとしてクライアントに送信する。
【０００３】
従来は、例えばＷｅｂサービスのインタフェースを定義するインタフェース定義文書に従って、クライアントから処理要求を受ける度に、プロバイダは処理結果を含むＸＭＬ文書を組み立てていた。しかしながら、Ｗｅｂサービスの分野においてはクライアントへの応答にかかる時間を短縮することが求められている。このために、ＸＭＬ文書をキャッシングする技術が開示されている。
【０００４】
例えば特許文献１によれば、クライアントから送られたパラメータに対応づけて、処理結果を含むＸＭＬ文書が格納（キャッシュ）される。次にクライアントから同じパラメータが送られた場合に、プロバイダは格納されたＸＭＬ文書を送信することができる。また、特許文献２によれば、処理結果が含まれるコンテンツを複数含むＸＭＬ文書について、プロバイダはそれぞれのコンテンツを別々にキャッシュすることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２３４６９０号公報
【特許文献２】特開２００７−２００３１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら特許文献１及び特許文献２の方法では、キャッシュされたＸＭＬ文書には処理結果も含まれている。したがって、異なるパラメータが与えられた場合には、プロバイダは新たにＸＭＬ文書を組み立てる必要があった。さらに特許文献２の方法では、コンテンツ毎にキャッシュした情報を使用するか否かが判断される。したがって、応答メッセージが大きくなると、処理に時間がかかってしまう。
【０００７】
本発明は、プロバイダが応答メッセージを生成するのにかかる時間を短縮することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の目的を達成するために、例えば、本発明の情報処理装置は以下の構成を備える。すなわち、
アプリケーションの実行結果を取得する実行手段と、
クライアント装置に対して送信する送信データの構造を定義するテンプレートと、該テンプレート内における前記実行結果の挿入箇所を示す位置情報と、が前記アプリケーションに関連付けて格納手段に格納されているか否かを判断する判断手段と、
格納されていると前記判断手段が判断した場合には、前記テンプレートと、前記位置情報と、を取得する第１の取得手段と、
格納されていないと前記判断手段が判断した場合には、前記アプリケーションについて予め作成され且つ前記テンプレート及び前記位置情報を規定するインタフェース定義文書を取得し、該取得したインタフェース定義文書を用いて前記テンプレート及び前記位置情報を生成すると共に、該生成したテンプレート及び位置情報を前記アプリケーションに関連付けて前記格納手段に格納する第２の取得手段と、
前記第１の取得手段若しくは前記第２の取得手段により得られたテンプレート中の、前記第１の取得手段若しくは前記第２の取得手段により得られた位置情報が示す箇所に、前記実行結果を挿入することによって前記送信データを生成する挿入手段と、
前記送信データを前記クライアント装置に対して送信する送信手段と
を備えることを特徴とする情報処理装置。
【発明の効果】
【０００９】
プロバイダが応答メッセージを生成するのにかかる時間を短縮することができる。
【図面の簡単な説明】
【００１０】
【図１】実施例１に係るクライアントとプロバイダとの関係を示す図。
【図２】実施例１に係るプロバイダの構成を示すブロック図。
【図３】実施例１に係るメッセージテンプレートの生成方法を説明する図。
【図４】実施例１に係る挿入部の構成を示すブロック図。
【図５】実施例２に係るプロバイダの構成を示すブロック図。
【図６】実施例１に係るハードウェア構成の一例を示す図。
【図７】実施例１に係る処理の一例を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【実施例１】
【００１２】
以下に、実施例１に係る情報処理装置について説明する。本実施例に係る情報処理装置は、クライアントから取得したパラメータに従ってアプリケーションを実行し、アプリケーションの実行結果をクライアントに送信する。本実施例におけるアプリケーションとは、Ｗｅｂサービスを提供するＷｅｂアプリケーションでありうる。この場合本実施例に係る情報処理装置とは典型的にはＷｅｂサービスを提供するプロバイダであって、例えばサーバでありうる。以下では、本実施例に係る情報処理装置であるプロバイダが、例えば個人用のＰＣであるクライアントに対してＷｅｂサービスを提供する場合について説明する。
【００１３】
本実施例においてプロバイダはさらに、アプリケーションの実行結果をクライアントに送信する。このときプロバイダは、アプリケーションに対応するインタフェース定義文書に従って、アプリケーションの実行結果を含む送信データを作成する。インタフェース定義文書は、クライアントに送信される送信データのデータ構造を定義する。それぞれのアプリケーションには、対応するインタフェース定義文書が決められている。また、送信データのデータ構造は、人間が読み取り可能な構造化文書でありうる。例えば、ＸＭＬ形式であってもよい。さらには、送信データはＳＯＡＰ形式であってもよい。
【００１４】
インタフェース定義文書とは、データ構造を規定するために、例えば世界共通に、規格化されたものでありうる。例えばインタフェース定義文書は、ＷＳＤＬ(Web Service Description Language)形式の文書（ＷＳＤＬ文書）であってもよい。インタフェース定義文書は、プロバイダが格納していてもよい。またインタフェース定義文書は、プロバイダがアクセス可能なネットワーク上、例えばインターネット上で公開されていてもよい。また、インタフェース定義文書を変更することにより、クライアントに送信される送信データのデータ構造を変更することもできる。インタフェース定義文書は例えば、クライアントからプロバイダへと送信されるパラメータを含む要求データのデータ構造を定義することができる。またインタフェース定義文書は、例えばアプリケーションを呼び出すためのメソッド名を定義することにより、アプリケーションを呼び出す方法を定義することができる。
【００１５】
アプリケーションに対応するインタフェース定義文書を参照することにより、クライアントは、そのアプリケーションに対してどのような形式の要求データを送ればよいのかを知ることができる。また、アプリケーションに対応するインタフェース定義文書を参照することにより、クライアントはアプリケーションから送られた送信データをどのように解釈すればよいのかを知ることができる。
【００１６】
クライアントがアプリケーションによる処理を要求するためには、それぞれのクライアントは要求データ及び送信データの形式を知っているべきである。アプリケーションに対応するインタフェース定義文書を公開することにより、不特定多数のクライアントが要求データ及び送信データの形式を知ることができる。このようなインタフェース定義文書を有することは、不特定多数のクライアントによってアクセスされうるＷｅｂアプリケーションにとって特に有利である。
【００１７】
本実施例においては、要求データ及び送信データがＳＯＡＰ形式であるものとして説明を行う。そのため本実施例では、クライアントがプロバイダに対して処理の実行を要求する際に、クライアントはＳＯＡＰメッセージをプロバイダへ送信する。このＳＯＡＰメッセージには、アプリケーションに対して与えるパラメータが含まれる。またプロバイダは、アプリケーションの処理結果を含むＳＯＡＰメッセージをクライアントに送信する。本実施例においては、クライアントからプロバイダへと送信するＳＯＡＰメッセージを「要求メッセージ」、プロバイダがクライアントへと送信するＳＯＡＰメッセージを「応答メッセージ」とする。
【００１８】
図１は、本実施例に係るプロバイダ１０２とクライアント１０１とを含むシステムを示す。クライアント１０１が実行するアプリケーション１０３は、プロバイダ１０２に対して、プロバイダ１０２が有するアプリケーション１０５による処理を要求する。具体的にはクライアント１０１は、プロバイダ１０２に対し、要求メッセージ１０４を送信する。
【００１９】
プロバイダ１０２は複数のアプリケーション１０５を有していてもよい。この場合アプリケーション１０３はどのアプリケーション１０５を介した処理を要求するのかを指定することができる。本実施例においては、この指定は要求メッセージ１０４内で行われるものとする。しかしながらこの指定は別個のメッセージによって行うことも可能である。また、指定が行われていない場合にも、要求メッセージ１０４の内容を解析することにより、プロバイダ１０２がどのアプリケーション１０５を実行するのかを判断することもできる。
【００２０】
プロバイダ１０２が要求メッセージ１０４を受信すると、要求メッセージ１０４は、プロバイダ１０２が実行するアプリケーション１０５へと渡される。アプリケーション１０５は、例えばＷｅｂサービスを提供するためのプログラムであり、要求メッセージ１０４に応じた処理を行う。アプリケーション１０５による処理結果は、プロバイダ１０２が有する生成部１０６へと渡される。
【００２１】
生成部１０６は、アプリケーション１０５による処理結果を含む応答メッセージ１０７を生成する。そして生成部１０６は、応答メッセージ１０７をクライアント１０１へと送信する。この結果、アプリケーション１０３へと、アプリケーション１０５による処理結果が通知される。
【００２２】
次に、本実施例に係るプロバイダ１０２について詳しく説明する。図２は、本実施例に係るプロバイダ１０２が有する各部が示されている。入力部２０３はクライアントから、要求メッセージ１０４を取得する。特定部２０４は、要求メッセージ１０４をどのアプリケーション１０５を用いて処理するのかを、上述のように要求メッセージ１０４に従って特定する。実行部２０５は、特定部２０４が特定したアプリケーションに対して要求メッセージ１０４内のパラメータを渡すことにより、アプリケーション１０５を実行する。そして実行部２０５は、アプリケーション１０５から処理結果２０６を受け取る。
【００２３】
生成部１０６は、実行部２０５から処理結果２０６を受け取る。そして生成部１０６は、処理結果２０６を含む応答メッセージ１０７を生成する。図２には生成部１０６が有する各部が示されている。以下に生成部１０６が行う処理について詳しく説明する。取得部２０７は、処理結果２０６を実行部２０５から受け取る。さらに取得部２０７は、アプリケーション１０５に対応するメッセージテンプレート２１２を取得する。
【００２４】
メッセージテンプレート２１２とは、処理結果２０６を含む応答メッセージ１０７を生成するためのテンプレートである。具体的には、メッセージテンプレート２１２とは、アプリケーション１０５に対応するインタフェース定義文書２０９に従って構築された応答メッセージ１０７であって、処理結果２０６を含まないものでありうる。したがって、メッセージテンプレート２１２に対して処理結果２０６を挿入することにより、応答メッセージ１０７を生成することができる。
【００２５】
取得部２０７が行うことができる具体的な処理について説明する。取得部２０７は、構築部２１０に対して処理結果２０６を生成したアプリケーション１０５がどれであるのかを通知する。構築部２１０は、アプリケーション１０５に対応するメッセージテンプレート２１２を取得し、取得したメッセージテンプレート２１２を取得部２０７に送信する。
【００２６】
具体的には構築部２１０は、アプリケーション１０５に関連付けられたメッセージテンプレート２１２が記憶領域２１１に格納されているか否かを判断する（判断手段）。アプリケーション１０５に対応するメッセージテンプレート２１２が格納されていると判断した場合、構築部２１０はそのメッセージテンプレート２１２を取得する（第１の取得手段）。
【００２７】
一方で構築部２１０が、アプリケーション１０５に対応するメッセージテンプレート２１２が記憶領域２１１に格納されていないと判断した場合、構築部２１０はアプリケーション１０５に対応するメッセージテンプレート２１２を生成する（第２の取得手段）。具体的には構築部２１０は、アプリケーション１０５に対応するインタフェース定義文書２０９を取得する。本実施例においては、インタフェース定義文書２０９は記憶領域２１１に格納されている。そして構築部２１０は、インタフェース定義文書２０９に従って、アプリケーション１０５に対応するメッセージテンプレート２１２を生成する。そして構築部２１０は、生成したメッセージテンプレート２１２を、アプリケーション１０５に関連付けて記憶領域２１１に格納する。インタフェース定義文書に従ってメッセージテンプレート２１２を生成する処理の詳細については後述する。
【００２８】
取得部２０７は、構築部２１０から取得したメッセージテンプレート２１２と、処理結果２０６とを、挿入部２１４に渡す。挿入部２１４は、メッセージテンプレート２１２に対して、処理結果２０６を挿入することにより、応答メッセージ１０７を生成する（挿入手段）。挿入部２１４が行う処理については後に詳しく説明する。そして送信部２１５は、挿入部２１４によって生成された応答メッセージ１０７を、クライアント１０１へと送信する（送信手段）。
【００２９】
図３を用いて、構築部２１０が行う、メッセージテンプレート２１２を生成する処理について詳しく説明する。図３には、アプリケーション１０５の処理を呼び出すためのインタフェースの一例が示されている。図３の例においては、ＷＳＤＬ形式のインタフェース定義文書２０９が用いられている。図３の説明においては、アプリケーション１０５は、プログラム中の次のメソッド３０１（インタフェース）を用いて呼び出されるものとする。
String value = getData(String key)
【００３０】
このように、メソッド名３０３と、パラメータ名３０５と、アプリケーションから送られた処理結果を格納する変数名３０６とを指定することにより、アプリケーション１０５を呼び出すことができる。メソッド３０１の形式は、インタフェース定義文書２０９を解析することにより知ることができる。例えば、＜operation name="getData"＞という記述３０４から、アプリケーション１０５はgetDataというメソッド名を用いて呼び出されるべきであることを知ることができる。
【００３１】
また、インタフェース定義文書２０９は、パラメータ名３０５によって指定される要求メッセージの形式を示す情報を含む。さらにインタフェース定義文書２０９は、変数名３０６によって指定される格納領域に格納される、応答メッセージ１０７の形式を示す情報を含む。従来から、インタフェース定義文書に従って応答メッセージ１０７を生成する方法が知られている。本実施例においても従来技術と同様に、インタフェース定義文書２０９を解析することにより応答メッセージ１０７の形式を知ることができる。
【００３２】
例えば応答メッセージ１０７の形式は、インタフェース定義文書２０９から次のように導き出されうる。例えば＜output message="SampleServiceResponseMessage" /＞という記述３２１から、"SampleServiceResponseMessage"というメッセージ形式で処理結果がクライアントへと返されることを知ることができる。そして、記述３２０から、"SampleServiceResponseMessage"というメッセージ形式には"response"という要素を含むべきであることを知ることができる。さらに、記述３０８から、"response"という要素には"string"形式である"output"という要素が含まれるべきであることを知ることができる。同様に、ここでは省略するが、記述３１９及び記述３０７を用いることにより、要求メッセージ１０４の形式を知ることもできる。
【００３３】
以上のように、ＳＯＡＰメッセージである応答メッセージ１０７には、"response"という名前のタグが含まれ、"response"タグの中には"output"タグが含まれることが、インタフェース定義文書２０９から導き出される。また、"output"タグの中にはstring型の値が含まれることも、インタフェース定義文書２０９から導き出される。図３には、このような解析結果がＸＭＬ文書３０９として示されている。処理結果２０６は、ＸＭＬ文書３０９内の挿入位置３１０に挿入される。また、応答メッセージ１０７はＳＯＡＰメッセージであるから、さらに必要なタグ（envelop, body等）が追加される。このように、構築部２１０はメッセージテンプレート２１２を生成する。
【００３４】
挿入部２１４はメッセージテンプレート２１２に対して処理結果２０６を挿入するが、メッセージテンプレート２１２のどの部分に処理結果を挿入するのかが特定されていることが有利である。図３のようにメッセージテンプレート２１２が比較的単純である場合には、処理結果２０６を挿入できる場所が限定されうる。このような場合には、挿入部２１４は処理結果２０６を挿入すべき位置を検索できるかもしれない。しかしながら構築部２１０が、インタフェース定義文書２０９からメッセージテンプレート２１２を生成する際に、処理結果２０６を挿入すべき位置（挿入箇所）を特定する位置情報２１３を同時に生成することもできる。インタフェース定義文書２０９は、メッセージテンプレート２１２に加えて、位置情報２１３を規定することができる。この場合、挿入部２１４による挿入処理をより高速に行うことができる。
【００３５】
位置情報２１３は、処理結果２０６を挿入すべき位置を特定できる情報であればどのようなものでも用いることができる。例えば、位置情報２１３としては、例えば予約語を用いることができる。この場合、メッセージテンプレート２１２内の挿入位置３１０に、予約語を挿入しておけばよい。また、文書が構造化されている場合、例えばＸＭＬ形式である場合には、ＸＰａｔｈ式を用いることもできる。
【００３６】
図３に示される例においては、位置情報２１３としてＸＰａｔｈ式が用いられる。例えば、上で説明したようにこの実施例においては、処理結果２０６は＜output＞タグ内に挿入され、＜output＞タグは＜response＞タグに含まれる。したがって構築部２１０は「/response/output」というＸＰａｔｈ式３１２を生成する。また、ＳＯＡＰの仕様として、ＸＭＬ文書３０９は＜body＞タグに含まれ、さらに＜body＞タグは＜envelop＞タグに含まれる。したがって構築部２１０は、「/envelop/body」というＸＰａｔｈ式を生成する。そして構築部２１０は、ＸＰａｔｈ式３１２とＸＰａｔｈ式３１３とから、位置情報２１３として「/envelop/body/response/output」というＸＰａｔｈ式３１４を生成する。
【００３７】
ＸＰａｔｈ式３１４を使用することにより、挿入部２１４は、処理結果２０６が挿入されるべきメッセージテンプレート２１２内の位置を迅速に発見することができる。位置情報２１３は、メッセージテンプレート２１２とともに、記憶領域２１１に格納されることができる。位置情報２１３とメッセージテンプレート２１２とは別個の情報として格納されてもよい。この場合、位置情報２１３はアプリケーション１０５に関連づけて格納されてもよいし、メッセージテンプレート２１２に関連づけて格納されてもよい。
【００３８】
本実施例においてはメッセージテンプレート２１２は、アプリケーション１０５に関連づけられて記憶領域２１１に保存される。例えば、メソッド名３０３である"getData"をキーとしてメッセージテンプレート２１２が保存されてもよい。この場合、同様にメソッド名３０３である"getData"をキーとして位置情報２１３を保存することもできる。このように、メッセージテンプレート２１２と位置情報２１３とを関連づけて保存することができる。一方で、位置情報２１３はメッセージテンプレート２１２の一部として格納されてもよい。例えばメッセージテンプレート内に設けられた特別のタグ内に、位置情報２１３が記述されてもよい。
【００３９】
図３に示した例では、処理結果２０６は１つの文字列である。しかしながら処理結果２０６は、２つ以上の値の集合であってもよく、例えばリストであってもよい。また、処理結果２０６が、メッセージテンプレート２１２内の、互いに離れた２つ以上の位置に挿入されてもよい。この場合位置情報２１３は、メッセージテンプレート２１２内の２つ以上の位置を特定する。さらに位置情報２１３は、メッセージテンプレート２１２内の２つ以上のそれぞれの位置に、どの値が挿入されるべきであるかを特定してもよい。
【００４０】
図４は、挿入部２１４が行う処理の一例を示す。図４には、挿入部２１４が備える各部が示されている。受信部４０３は、メッセージテンプレート２１２と、位置情報３１４と、処理結果２０６とを取得する。この例においては、処理結果２０６は"sample"という文字列であるものとする。挿入処理部４０４は、メッセージテンプレート２１２中（メッセージテンプレート中）の、位置情報３１４が示す位置に、処理結果２０６を挿入する。挿入処理部４０４は、位置情報処理部４０５が有する位置情報３１４を解釈する機能を利用して、挿入処理を行うことができる。本実施例においては、位置情報処理部４０５はＸＰａｔｈ式を解釈する機能を有する。こうして、応答メッセージ１０７が生成される。
【００４１】
以下に図７を参照しながら、本実施例に係るプロバイダが行う処理の一例を説明する。ステップＳ７０１で入力部２０３は、クライアント１０１から要求メッセージ１０４を取得する。ステップＳ７０２で特定部２０４は、要求メッセージ１０４を解析することにより、実行するアプリケーション１０５を特定する。ステップＳ７０３で実行部２０５は、ステップＳ７０４で特定されたアプリケーション１０５を実行し、処理結果２０６を受け取る。ステップＳ７０４で取得部２０７は、アプリケーション１０５に対応するメッセージテンプレート２１２を構築部２１０に要求する。
【００４２】
ステップＳ７０５で構築部２１０は、アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３が、記憶領域２１１に格納されているか否かを判定する。アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に格納されている場合、処理はステップＳ７０６に進む。アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に格納されていない場合、処理はステップＳ７０７に進む。
【００４３】
ステップＳ７０６で構築部２１０は、アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３を記憶領域２１１から取得する。そして構築部２１０は、メッセージテンプレート２１２及び位置情報２１３を取得部２０７に送る。ステップＳ７０７で構築部２１０は、アプリケーション１０５に対応するインタフェース定義文書２０９を取得する。ステップＳ７０８で構築部２１０は、ステップＳ７０７で取得したインタフェース定義文書２０９を解析することにより、メッセージテンプレート２１２及び位置情報２１３を生成する。そして構築部２１０は、メッセージテンプレート２１２及び位置情報２１３を取得部２０７に送る。
【００４４】
ステップＳ７０９で挿入部２１４は、メッセージテンプレート２１２の、位置情報２１３によって指定される位置に、処理結果２０６を挿入することにより、応答メッセージ１０７を生成する。ステップＳ７１０で送信部２１５は、ステップＳ７０９で生成された応答メッセージ１０７を、クライアント１０１に送信する。
【００４５】
本実施例においては、各アプリケーション１０５が、処理要求を取得するためのインタフェースをそれぞれ１つずつ持つものとして説明を行った。しかしながら、各アプリケーション１０５は、複数のインタフェースを有していてもよい。すなわち、実行部２０５は、要求メッセージ１０４において特定されたインタフェースに要求メッセージを渡す。
【００４６】
この場合、構築部２１０は、実行部２０５によって呼び出されたインタフェースに対応するメッセージテンプレート２１２及び位置情報２１３を、記憶領域２１１から取得する。また構築部２１０は、実行部２０５によって呼び出されたインタフェースに対応するメッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に存在しない場合、このインタフェースに対応するインタフェース定義文書２０９を取得する。記憶領域２１１には、それぞれのインタフェースに対応したインタフェース定義文書２０９が、記憶領域２１１に格納されている。この場合構築部２１０は、実行部２０５によって呼び出されたインタフェースに対応するインタフェース定義文書２０９に基づいて、メッセージテンプレート２１２と位置情報２１３とを生成する。そして構築部２１０は、生成されたメッセージテンプレート２１２と位置情報２１３とを、実行部２０５によって呼び出されたインタフェースに対応づけて記憶領域２１１に格納する。
【００４７】
本実施例を応用することにより、クライアント１０１が指定したデータ形式で、プロバイダ１０２が応答メッセージ１０７を送信することもできる。例えば、クライアント１０１は要求メッセージ１０４を送信する際に、応答メッセージ１０７のデータ形式を定義するインタフェース定義文書２０９を指定してもよい。
【００４８】
本実施例においては、メッセージテンプレート２１２及び位置情報２１３は、アプリケーション１０５に対応づけて記憶領域２１１に格納される。しかしながら、メッセージテンプレート２１２及び位置情報２１３は、インタフェース定義文書２０９に対応づけて記憶領域２１１に格納されてもよい。この場合構築部２１０はステップＳ７０５において、使用するインタフェース定義文書２０９を取得し、インタフェース定義文書２０９に対応するメッセージテンプレート２１２及び位置情報２１３が存在するか否かを判断することができる。
【００４９】
以上のように、本実施例においては、アプリケーション１０５に対応するメッセージテンプレート２１２が、記憶領域２１１に格納される。従来技術においては、要求メッセージ１０４を受け取る度に、アプリケーション１０５に対応するインタフェース定義文書２０９に従って、処理結果２０６を含む応答メッセージ１０７が構築された。応答メッセージ１０７を構築する際には、処理結果２０６の値を挿入する位置に達したかどうかを判断しながら、１つ１つタグを組み立てていた。
【００５０】
しかしながら本実施例においては、予め格納されているメッセージテンプレート２１２に対して、位置情報２１３によって示される位置に処理結果２０６が挿入される。このために、本実施例の方法によれば、応答メッセージ１０７を生成するためにかかる時間を短縮できる。さらには、クライアント１０１が要求メッセージ１０４を送信してから、クライアント１０１が応答メッセージ１０７を受信するまでにかかる時間を短縮することができる。
【００５１】
さらに本実施例においては、構築部２１０は、アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に格納されているか否かを判断する。メッセージテンプレート２１２及び位置情報２１３が格納されている場合、構築部２１０はこれらを生成する処理を行わない。すなわち、以前に起動したことがあるアプリケーション１０５と同じアプリケーション１０５による処理をクライアント１０１が要求する場合、プロバイダ１０２は、以前に生成したメッセージテンプレート２１２及び位置情報２１３を再利用する。このように、メッセージテンプレート２１２及び位置情報２１３を再度生成する処理を省くことができる。さらに、再度生成されたメッセージテンプレート２１２及び位置情報２１３を、プロバイダ１０２が記憶領域２１１に格納することもない。したがって、記憶領域２１１の容量が足りなくなる可能性を減らすことができる。
【００５２】
また、プロバイダ１０２が複数のＷｅｂサービス（アプリケーション１０５）を提供することが考えられる。この場合、それぞれのアプリケーション１０５に対してクライアント１０１から処理が要求されると、それぞれのアプリケーション１０５についてのメッセージテンプレート２１２と位置情報２１３とが生成され、記憶領域２１１に格納される。このために、記憶領域２１１の容量が足りなくなる可能性がある。しかしながら本実施例に係るプロバイダ１０２は、プロバイダ１０２が有する全てのアプリケーション１０５についてのメッセージテンプレート２１２及び位置情報２１３を格納しなくてもよいという利点を有する。
【００５３】
したがって本実施例においては、記憶領域２１１の容量が足りなくなった場合、メッセージテンプレート２１２及び位置情報２１３を削除することができる。メッセージテンプレート２１２及び位置情報２１３を削除しても、必要な際にプロバイダ１０２はこれらを再び生成することができるためである。例えば、メッセージテンプレート２１２及び位置情報２１３のデータ量が所定量に達した場合に、これらを削除することができる。また、クライアント１０１側への応答が終了した際に、メッセージテンプレート２１２及び位置情報２１３を削除することもできる。さらには、クライアント１０１側への応答が終了してから所定の時間が経過した際に、メッセージテンプレート２１２及び位置情報２１３を削除することもできる。
【００５４】
これらのデータを削除する際には、最も古いメッセージテンプレート２１２及び位置情報２１３を削除することができる。これらのデータ削除処理、例えばプロバイダ１０２が有する非図示のアプリケーションを用いて行うこともできる。あるいは、記憶領域２１１内のデータをユーザが操作することが可能な場合は、ユーザの操作に従ってメッセージテンプレート２１２及び位置情報２１３を削除することもできる。
【実施例２】
【００５５】
以下に、実施例２に係る情報処理装置について説明する。実施例１においては、クライアント１０１から要求メッセージ１０４を受け取った際に、メッセージテンプレート２１２と位置情報２１３とが生成された。本実施例においては、プロバイダ１０２にアプリケーション１０５が登録される際に、メッセージテンプレート２１２と位置情報２１３とが生成される。
【００５６】
本実施例に係る情報処理装置（プロバイダ１０２）は実施例１に係る情報処理装置と類似している。また、本実施例に係る処理も、実施例１に係る処理と類似している。図５は、本実施例に係る情報処理装置の一例を示す。図５において、実施例１で説明された構成と類似する構成については、同一の参照符号が付されている。以下で、本実施例と実施例１との違いについて説明する。以下では、実施例１と同様の構成及び処理については、説明を省略する。
【００５７】
一般的なＷｅｂサービス環境においては、プロバイダ１０２には、複数のアプリケーション１０５がＷｅｂサービスとして登録される。そして、登録されたそれぞれのアプリケーション１０５についてのインタフェース定義文書が公開される。プロバイダ１０２にアプリケーション１０５が登録されると、アプリケーション１０５を用いた処理の要求を、プロバイダ１０２はクライアント１０１から受けることができるようになる。
【００５８】
本実施例においては、構築部２１０は、プロバイダ１０２にアプリケーション１０５が登録される際に、アプリケーション１０５に対応するメッセージテンプレート２１２と位置情報２１３とを生成する。そして構築部２１０は、生成されたメッセージテンプレート２１２及び位置情報２１３を、記憶領域２１１に格納する。したがって、取得部２０７が、要求メッセージ１０４に従う処理結果２０６を受け取った際には、すでに必要なメッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に格納されている。
【００５９】
以下に、図７を参照して、本実施例に係る処理を説明する。
【００６０】
以上、メッセージテンプレートと位置情報を事前に生成して保持しておき、クライアントからのリクエスト時に、それらを使用することで、応答メッセージの生成時間を、さらに短縮することができる。ステップＳ７０１〜ステップＳ７０３の処理は実施例１と同様である。ステップＳ７０４において取得部２０７は、アプリケーション１０５に対応するメッセージテンプレート２１２及び位置情報２１３を記憶領域２１１から取得する。そしてステップＳ７０４に続けて、実施例１と同様にステップＳ７０９〜Ｓ７１０の処理が行われる。
【実施例３】
【００６１】
本実施例においては、プロバイダ１０２にアプリケーション１０５が登録される際に、ユーザが手動でメッセージテンプレート２１２と位置情報２１３とを生成する。本実施例に係る情報処理装置（プロバイダ１０２）は実施例２に係る情報処理装置と類似している。また、本実施例に係る処理も、実施例２に係る処理と類似している。以下で、本実施例と実施例２との違いについて説明する。以下では、実施例２と同様の構成及び処理については、説明を省略する。
【００６２】
本実施例に係るプロバイダ１０２は、構築部２１０を有さなくてもよい。すなわち、ユーザがアプリケーション１０５に対応するインタフェース定義文書２０９を読み、その内容を理解する。そしてユーザは、インタフェース定義文書２０９に従って、アプリケーション１０５に対応するメッセージテンプレート２１２と位置情報２１３とを作成する。そしてユーザは、作成したメッセージテンプレート２１２と位置情報２１３とを、アプリケーション１０５に対応づけて、記憶領域２１１に手動で保存する。
【００６３】
本実施例においては、プロバイダ１０２にアプリケーション１０５が登録される際に、ユーザが手動でメッセージテンプレート２１２と位置情報２１３とを生成し、記憶領域２１１に保存した。しかしながら、全てのアプリケーション１０５について、メッセージテンプレート２１２と位置情報２１３とが作成される必要はない。例えば、一部のアプリケーション１０５についてのみ、ユーザが手動でメッセージテンプレート２１２と位置情報２１３とを生成してもよい。この場合、残りのアプリケーション１０５については、プロバイダ１０２がメッセージテンプレート２１２と位置情報２１３とを自動生成してもよい。
【００６４】
このような構成は、実施例１に係る情報処理装置を用いることにより実現することができる。例えば、アプリケーション１０５をプロバイダ１０２に登録する際に、メッセージテンプレート２１２及び位置情報２１３をユーザが作成するか否かを決定してもよい。この決定はユーザが行ってもよいし、プロバイダ１０２が行ってもよい。例えばプロバイダ１０２がインタフェース定義文書２０９からメッセージテンプレート２１２及び位置情報２１３を自動的に生成できない場合に、プロバイダはユーザに対してメッセージテンプレート２１２及び位置情報２１３を要求してもよい。
【００６５】
この場合、ユーザによって生成された（又は構築部２１０によって生成された）メッセージテンプレート２１２及び位置情報２１３が記憶領域２１１に格納されているのなら、構築部２１０は記憶領域２１１からこれらを取得するだろう。そうでなければ、構築部２１０はインタフェース定義文書２０９に従ってメッセージテンプレート２１２及び位置情報２１３を生成するだろう。
【実施例４】
【００６６】
本実施例においては、情報処理装置がソフトウェア（コンピュータプログラム）を実行することにより、上述の各実施例の機能が実現される。本実施例に係る情報処理装置６００が有するハードウェア構成の一例を、図６に示す。情報処理装置６００は、例えばコンピュータである。情報処理装置６００は、入力装置６０１と、表示装置６０２と、ドライブ６０３と、を含む。さらに情報処理装置６００は、ＲＯＭ６０５と、ＲＡＭ６０６と、ＣＰＵ（又はＭＰＵ）６０７と、インタフェース装置６０８と、ＨＤ（ハードディスク）６０９と、を含む。
【００６７】
入力装置６０１は、キーボード及びマウスなどを含みうる。情報処理装置６００の操作者（オペレータ）は、入力装置６０１を操作することにより、情報処理装置６００に対して各種の情報を入力することができる。表示装置６０２は、ディスプレイなどを含みうる。表示装置６０２は、情報処理装置６００の操作者に対して、各種情報（又は画面）などを表示する。インタフェース装置６０８は、情報処理装置６００をネットワークなどに接続することができる。
【００６８】
上述の各実施例の機能を実現するプログラムは、例えばＣＤ−ＲＯＭなどの記憶媒体６０４によって、情報処理装置６００に提供されることができる。また、上述の各実施例の機能を実現するプログラムは、ネットワークを介して外部の装置からダウンロードされることもできる。記憶媒体６０４をドライブ６０３にセットすると、ＣＰＵ６０７の制御の下で、プログラムが記憶媒体６０４からＨＤ６０９へとインストールされる。
【００６９】
ＲＯＭ６０５は、情報処理装置６００の電源を入れたときに読み込まれる制御プログラムなどを格納することができる。ＲＡＭ６０６は、情報処理装置６００のメインメモリである。ＣＰＵ６０７は、ＨＤ６０９に格納されたプログラムを読み取り、ＲＡＭ６０６に格納する。そして、ＲＡＭ６０６に格納されたプログラムに従ってＣＰＵ６０７が処理を行うことにより、上述の各実施例に係る処理を実現することができる。
【００７０】
［その他の実施形態］
以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００７１】
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムコードを読み出して実行する。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
【図１】
2012008885.tif 000003
【図２】
2012008885.tif 000004
【図３】
2012008885.tif 000005
【図４】
2012008885.tif 000006
【図５】
2012008885.tif 000007
【図６】
2012008885.tif 000008
【図７】
2012008885.tif 000009