JP4709481B2 - サーバ、情報処理方法およびプログラム - Google Patents

Description

本発明は、ネットワークを介して所定のクライアントからの要求を受け付けてウェブアプリケーションを実行するウェブアプリケーションサーバおよびその情報処理方法に関する。

インターネット等、ネットワーク環境の充実に伴い、ウェブベースのネットワークシステム上でブラウザを利用して操作するウェブアプリケーションが普及してきている。ウェブアプリケーションの実現には、クライアント（ブラウザ）からの要求に応じてサーバで動的にウェブページを生成しクライアントに送信する機能が必要であるが、このための手段として一般的なものに、ＪＳＰ（Java Server Pages）がある。ＪＳＰは、Ｊａｖａ（米国サン・マイクロシステムズ社の商標）言語を利用して、上述したウェブページの動的生成を実現する技術である。

今日、インターネットに接続可能な端末装置の種類は非常に多岐に及んでいる。そのため、ウェブアプリケーションにおいても、当該ウェブアプリケーションを利用しようとする端末装置の種類に応じた適切な処理を行うことが必要となっている。
ウェブアプリケーションの設計時に多数の端末装置に対して、適切なＪＳＰおよび適切なアクションを用いてウェブアプリケーションの処理を実行することを可能とする従来技術としては、米国ＩＢＭ社のMulti-device Authoring Technology（以下、ＭＤＡＴ）がある（例えば、非特許文献１参照）。

ＭＤＡＴでは、ＪＳＰのモデル２（Model2）と呼ばれるアーキテクチャを基本として、ＭＶＣ（Model、View、Control）モデルに基づく多種の端末装置向けのウェブアプリケーション開発技術が提供されている。ＭＶＣモデルに基づくウェブアプリケーションでは、ウェブアプリケーションが業務ロジックを記述するモデル、ウェブ画面のデザインを記述するビュー、クライアントからの要求と業務処理の連携制御を記述するコントローラの３種の機能に分解され、例えばモデルとして抽象表現による定義を用い、ビューとしてＪＳＰを用い、コントローラとしてサーブレット（Servlet）を用いて作成される。

ウェブアプリケーションを多種の端末装置に適応させるには、例えば、処理の内容や結果を端末装置の表示手段に表示させるためのビュー部分において、各端末装置に適応させるために複数のＪＳＰのセットを用意する必要がある。ＭＤＡＴでは、このビュー部分であるＪＳＰファイルは、特定の端末装置に特化されていないダイアログという抽象表現に基づき、ビュー・スペシャライザによって自動的に生成される。この際、アプリケーションで対象とする端末装置が予め指定されなければならない。ビュー・スペシャライザは、指定された端末装置の属性（使用されるマークアップ言語、画面サイズ、表示可能色数など）を所定のプロファイルデータベースから取得し、これに応じてＪＳＰファイルを適切に生成する。

このように、対象となる端末装置を特定し、その属性に関する情報に基づいてＪＳＰファイルを生成する方法によれば、生成すべきＪＳＰがウェブアプリケーションの設計時に明らかとなり、特定の端末装置用のカスタマイズをＪＳＰに加えることが可能である。

"Everyplace Toolkit for WebSphere Studio"、［online］、ＩＢＭ、［平成１５年７月１５日検索］、インターネット＜URL : http://www-3.ibm.com/software/pervasive/products/mobile_apps/everyplace_toolkit.shtml＞

上記のように、ウェブアプリケーションによる処理をクライアントの端末装置の種類に応じて適切に実行するためには、ウェブアプリケーションを利用する各種の端末装置に対応したビューを用意することが必要である。しかし、インターネットに接続可能な、膨大な種類の端末装置の全てに対応してビューを生成することは、ウェブアプリケーション開発における負担の増大を招く。

また、インターネットに接続可能な端末装置の種類は日々増加しつつあり、ウェブアプリケーションの設計時に想定されていない端末装置に対応することは困難である。上述したＭＤＡＴ等のようにウェブアプリケーションの設計時にビュー（ＪＳＰ）を生成する手法では、ウェブアプリケーションの作成、テスト、デバッグを行うために、既存の端末装置を対象としてＪＳＰファイルを作成しておかなければならず、未知の端末装置には対応できない。

未知の端末装置からの要求に対応する方法として、アプリケーションサーバが、かかる端末装置から初回の要求を受け付けた際に、その端末装置向けの、ウェブアプリケーション全体に対応するビューを一度に生成してしまうことが考えられる。
しかし、未知の端末装置から初めて要求を受け付けた時点で対応するウェブアプリケーションの全体を生成しようとすると、当該初回の応答作成に多大な時間を要する。

また、端末装置の種類によっては、ウェブアプリケーションの機能の一部しか使用しない（もしくは使用できない）場合もあり得るが、ウェブアプリケーションの全体に対応するビューを生成すると、当該ウェブアプリケーションのデザインにしたがって、そのような使用されない機能についてもビューを生成することとなり、無駄が多い。

なお、上記の問題は、ウェブアプリケーションのビューの生成手段としてＪＳＰ以外の手段を用いる場合も同様であることは言うまでもない。
そこで本発明は、上記の課題に鑑み、ウェブアプリケーションの設計時に想定されていない端末装置からのアクセスに対しても適切に処理を行うことが可能なウェブアプリケーションサーバを提供し、ウェブアプリケーション開発時の負担を軽減することを目的とする。
また本発明は、上記のウェブアプリケーションサーバにおいて、未知の端末装置からの要求に対し、効率的かつ速やかな応答を可能とすることを他の目的とする。

上記の目的を達成する本発明は、ネットワークを介して所定のクライアントからの要求を受け付けてウェブアプリケーションを実行する、次のように構成されたウェブアプリケーションサーバとして実現される。このウェブアプリケーションサーバは、クライアントにおける表示形態とは独立のビュー定義である抽象ビューを格納した抽象ビュー格納部と、この抽象ビューを用いてクライアントからの要求に対する処理を実行する抽象ビュー処理実行部と、この抽象ビュー処理実行部による処理結果に基づいてクライアントの属性に対応したビューを生成するビュー生成部と、このビュー生成部にて生成されたビューを用いてクライアントへの応答を生成し返送する応答生成部とを備えることを特徴とする。

ここで、ビュー生成部はＪＳＰによりビューを生成することができ、また生成されたビューに含まれるハイパーリンクのリンク先は他のビューではなく抽象ビューとする。抽象ビューとしては、特定のクライアントのシステム構成に関わらない抽象表現によるビュー定義や、国際化ＪＳＰにて記述したビューを用いることができる。さらに、ビュー生成部にて生成されたビューを保持するビュー格納部を備えた構成とし、クライアントからの要求に応じて抽象ビュー処理実行部により行われた処理の結果に対応するクライアント用のビューがビュー格納部に保持されている場合に、ビュー生成部により改めてビューを生成することをせず、応答生成部が、ビュー格納部に保持されているビューを用いて応答を生成する構成とすることができる。

本発明による他のウェブアプリケーションサーバは、クライアントの属性に関わらない抽象表現による定義を用いてウェブアプリケーションの業務処理を実行する業務実行手段と、この業務実行手段による業務処理の結果に基づいてクライアントの属性に適合したＪＳＰファイルを生成するＪＳＰファイル生成手段と、このＪＳＰファイル生成手段にて生成されたＪＳＰファイルを用いてクライアントへの応答を生成し返送する応答手段とを備えることを特徴とする。

本発明による更に他のウェブアプリケーションサーバは、クライアントの属性に関わらない抽象表現による定義を格納した定義格納手段と、この抽象表現による定義を用いてクライアントからの要求に対する処理を実行する処理実行手段と、この処理実行手段による処理結果をクライアントにて表示可能とするためのテンプレートを生成するテンプレート生成手段と、このテンプレート生成手段にて生成されたテンプレートを用いて処理実行手段による処理結果をクライアントに表示させるための応答を生成し返送する応答手段とを備えることを特徴とする。

さらにまた、上記の目的を達成する本発明は、ネットワークに接続されたコンピュータを用いて、所定のクライアントからの要求を受け付けてウェブアプリケーションによる業務処理を実行する、次のような情報処理方法としても実現される。すなわち、この情報処理方法は、クライアントからの要求を受け付け、所定の記憶装置に格納されているクライアントの属性に関わらない抽象表現による定義を用いてウェブアプリケーションの業務処理を実行する第１のステップと、業務処理の結果をクライアントにて表示可能とするためのテンプレートを生成し、所定の記憶装置に格納する第２のステップと、記憶装置に格納されたテンプレートを用いて要求に対する応答を生成し返送する第３のステップとを含むことを特徴とする。

また本発明は、コンピュータを制御して上記のウェブアプリケーションサーバとして機能させるプログラム、または上述した情報処理方法における各ステップに相当する処理をコンピュータに実行させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。

以上のように構成された本発明は、ウェブアプリケーションの設計時に当該ウェブアプリケーションを使用する全てのクライアント（端末装置）に対するビューを生成するのではなく、クライアントからの要求を受け付けるたびに当該クライアントに対応するビューを生成することにより、ウェブアプリケーションの設計時に想定されていない端末装置からのアクセスに対しても適切に処理を行うことが可能となる。これにより、ウェブアプリケーション開発時における負担を軽減させることができる。

また本発明は、クライアントからの要求を受け付けた際に、当該クライアント用のウェブアプリケーション全体に対応するビューを全て生成してしまうのではなく、当該要求に対する応答を行うために必要なビューを生成することにより、当該要求に対する効率的かつ速やかな応答が可能となる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
本実施形態は、インターネット等のネットワークを介してクライアントからの要求を受け付け、ウェブアプリケーションによる処理を実行して応答を当該クライアントへ返送するウェブアプリケーションサーバとして実現される。ここで、クライアントは、ウェブアプリケーションを利用可能なソフトウェアを実行する情報端末（パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、携帯電話等）であり、以下の説明では、当該情報端末のハードウェアと当該情報端末で実行されるソフトウェアとを特に区別せずに端末装置と呼称する。例えば、クライアントの具体例として米国マイクロソフト社のインターネットブラウザであるインターネットエクスプローラを想定した場合、ソフトウェアであるインターネットエクスプローラおよび当該インターネットエクスプローラが動作するハードウェアを、いずれも端末装置と呼ぶ。

図１は、本実施形態のウェブアプリケーションサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図１に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０８およびキーボード／マウス１０９とを備える。

なお、図１は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。

図２は、本実施形態によるウェブアプリケーションサーバ１０の機能構成を示す図である。
図２を参照すると、本実施形態のウェブアプリケーションサーバ１０は、種々の端末装置（クライアント、User-Agent）の属性に関する情報を格納した端末プロファイルＤＢ（データベース）１１と、特定の端末装置に特化されない抽象的な表現でウェブアプリケーションを記述したダイアログのファイル（以下、ＤＬＧファイル）を格納したＤＬＧファイル格納部１２と、ウェブアプリケーションの実行時にＪＳＰを動的に生成するためのＤＬＧ実行部１３およびビュー・スペシャライザ１４と、生成されたＪＳＰを保持するＪＳＰファイル格納部１５と、ＪＳＰファイルを解釈してＨＴＭＬ文書等からなる応答を生成する応答生成部１６とを備える。

上記の構成のうち、端末プロファイルＤＢ１１、ＤＬＧファイル格納部１２およびＪＳＰファイル格納部１５は、例えば図１に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５にて実現される。また、ＤＬＧ実行部１３、ビュー・スペシャライザ１４および応答生成部１６は、例えば図１のプログラム制御されたＣＰＵ１０１の機能として実現される。ＣＰＵ１０１を制御するプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることができる。

図２に示した本実施形態において、端末プロファイルＤＢ１１は、ウェブアプリケーションサーバ１０にアクセスしウェブアプリケーションを利用すると想定される各種の端末装置に関して、その属性（使用されるマークアップ言語、画面サイズ、表示可能色数など）に関する情報（以下、属性情報）を格納している。ウェブアプリケーションサーバ１０にアクセスすることが想定される端末装置とは、例えば、パーソナルコンピュータ等のコンピュータ装置、ネットワーク機能を備えたＰＤＡ（Personal Digital Assistance）、携帯電話等の情報端末である。また、端末プロファイルＤＢ１１の内容は、ウェブアプリケーションサーバ１０にアクセス可能な端末装置の機種の増加に伴い、随時更新され、当該機種の属性情報が追加される。

ＤＬＧファイル格納部１２は、ウェブアプリケーションサーバ１０が提供するウェブアプリケーションの機能を、特定の端末に特化されない抽象的な表現であるダイアログで記述したＤＬＧファイルを格納している。このＤＬＧファイルは、ウェブアプリケーションにおける業務処理の内容や結果をクライアントに表示させるためのビューを、個々のクライアントにおける表示形態とは独立の抽象的な表現で記述したビュー定義（抽象ビュー）である。

ＤＬＧ実行部１３は、所定の端末装置からのウェブアプリケーションに対する要求（ＨＴＴＰリクエスト等）を受け付け、当該要求に対する処理をダイアログのレベルで行い、当該端末装置に対応するＪＳＰファイルの生成を制御するＤＬＧサーブレット（コントローラ）である。すなわち、ウェブアプリケーションによる業務処理を、抽象ビューであるＤＬＧファイルを用いて実行する業務（処理）実行手段である。具体的には、まず端末装置からの要求をダイアログレベルで解釈・実行して応答に必要なＤＬＧファイルを特定し、さらに要求ヘッダのUser-Agentフィールドの記述等から当該端末装置（User-Agent）を特定するキー情報を取得する。そして、これらの情報をビュー・スペシャライザ１４に与え、対応するＪＳＰファイルを生成させる。また、ＤＬＧ実行部１３は、端末装置から受け付けた要求およびキー情報を応答生成部１６にも転送（フォワード）する。

ビュー・スペシャライザ１４は、ＤＬＧ実行部１３にて特定されたＤＬＧファイルをＤＬＧファイル格納部１２から読み出し、同じくＤＬＧ実行部１３から取得したキー情報を用いて端末プロファイルＤＢ１１を検索して該当する端末装置の属性情報を取得する。そして、読み出したＤＬＧファイルを、当該端末装置に特化したビューであるＪＳＰファイルに変換する。すなわち、ビュー・スペシャライザ１４は、特定の端末装置の属性に関わらない抽象ビューであるＤＬＧファイルから特定の端末装置の属性に特化したビューであるＪＳＰファイルを生成するビュー生成手段である。ビュー・スペシャライザ１４にて生成されたＪＳＰファイルは、端末装置への応答を生成するために使用されるテンプレートとして、ＪＳＰファイル格納部１５に格納される。

本実施形態では、端末装置から要求があった場合に、ウェブアプリケーション全体に相当する当該端末装置に特化したＪＳＰファイルを全て生成するのではなく、当該要求への応答として必要なＪＳＰファイルのみを生成する。このとき、生成されるＪＳＰファイルに他のＪＳＰファイルへのリンクが存在し、かつリンク先のＪＳＰファイルが未生成である場合、ウェブアプリケーション全体のＪＳＰファイルを生成する場合と全く同様にリンク先を定義してＪＳＰファイルを生成すると、正常に実行できないこととなる。したがって、ＤＬＧファイル間のリンクやＤＬＧファイルへの遷移を、どのようにＪＳＰファイルに反映させるかが問題となる。本実施形態では、生成されたＪＳＰファイルのリンクを、ＪＳＰファイルではなくＤＬＧファイルへのリンクとすることで、この問題を解決する。この手法については、後で具体例を挙げて詳述する。

ＪＳＰファイル格納部１５は、ビュー・スペシャライザ１４にて生成されたＪＳＰファイルを格納する。一度格納されたＪＳＰファイルは、当該機種用のウェブアプリケーションとして、ＪＳＰファイル格納部１５に保存され、これ以後、同じ機種の端末装置から同じ要求が行われた場合に使用される。すなわち同種の端末装置からの２回目以降の要求に対しては、ＪＳＰファイルを改めて生成する必要はなくなる。

応答生成部１６は、上述した端末装置からの要求およびキー情報をＤＬＧ実行部１３から受け取り、当該要求に応じたＪＳＰファイルをＪＳＰファイル格納部１５から読み出して当該要求に対する応答（ＨＴＴＰレスポンス等）を生成し、当該端末装置に返送するＪＳＰサーブレットである。

次に、具体的なファイルの例を提示して、本実施形態の動作について説明する。
前提として、ＤＬＧファイル格納部１２には、図３に示すＤＬＧファイル（Hello.dlg、World.dlg）が格納されている。また、ＤＬＧ実行部１３の機能が、図４に示すＸＭＬファイル（controller.xml）で記述されているものとする。このHello.dlgから個々の端末装置に特化したHello.jspが生成され、同様にWorld.dlgからWorld.jspが生成されるとすると、このウェブアプリケーションは、Hello.jspに基づくウェブページからWorld.jspへ遷移することにより、端末装置のディスプレイに「Ｈｅｌｌｏ，Ｗｏｒｌｄ！」の文字が表示されるものである。

ここで、比較のために、ウェブアプリケーションの設計時や端末装置から要求があった際に当該ウェブアプリケーションの全体のＪＳＰファイルを生成する場合に、どのようなファイルが生成されるかを示す。端末装置が「MSIE」というキー情報で特定されるとすると、かかる手法では、図３のＤＬＧファイルから図５に示すＪＳＰファイル（MSIE/Hello.jsp、MSIE/World.jsp）が生成され、図６に示すＳｔｒｕｔｓ設定ファイル（struts-config.xml）が生成される。そして、これらのＪＳＰファイルとＳｔｒｕｔｓ設定ファイルとにより、キー情報「MSIE」で特定される端末装置の属性に適応した応答（ＨＴＭＬファイル）が生成されて当該端末装置に返送されることとなる。

一方、本実施形態では、要求を受けるたびに必要なＪＳＰファイルのみを生成していくため、Hello.dlgからHello.jspが生成された時点では、まだWorld.jspは生成されていない。そのため、図６のようにＳｔｒｕｔｓ設定ファイルを生成してしまうと、これを実行することができずエラーとなってしまう。すなわち、Hello.jspに基づくウェブページからgotoWorldアクションが呼ばれた場合に、World.jspというこの時点では存在しないファイルへ転送してしまうためである。この場合、gotoWorldアクションを実行する前に、まずWorld.dlgからWorld.jspを生成しなくてはならない。

そこで、本実施形態では、ウェブアプリケーションにＪＳＰファイルではなくダイアログ自体を配置する。これに応じて、当該ウェブアプリケーション内の全てのリンク（ｗｅｌｃｏｍｅファイル、ＨＴＭＬのＡタグなどの静的リンク、アクションの結果としてのフォワードとリダイレクトなど）は、ＪＳＰファイルへではなくダイアログへと張られる。
図７は、本実施形態にて構築されるウェブアプリケーションにおけるウェブアプリケーション配置記述子の例を示す図である。
上記のようにＤＬＧファイルのファイル拡張子がdlgであり、ＤＬＧサーブレットのクラスがcom.ibm.hopi.runtime.struts.DLGServletであったとすると、そのウェブアプリケーション配置記述子は、図７に示すようになる。

また図８は、当該ウェブアプリケーションの設計時に生成されるＳｔｒｕｔｓ設定ファイル（struts-config.xml）を示す図である。
図８のＳｔｒｕｔｓ設定ファイルを図６のＳｔｒｕｔｓ設定ファイルと比較すると、アクションの転送先がキー情報「MSIE」で特定される端末装置に特化したＪＳＰファイルではなく、ＤＬＧファイルとなっている。このＳｔｒｕｔｓ設定ファイルは、特定の端末装置に特化されていないので、ウェブアプリケーションの設計時に生成しておくことができる。

図９は、図７に示したＤＬＧサーブレット、すなわちＤＬＧ実行部１３が所定の端末装置から所定の要求を受け付けた場合の動作（doGet、doPostメソッド）を示すフローチャートである。
図９を参照すると、ＤＬＧ実行部１３は、まず所定の端末装置（User-Agent）から要求を受け付ける（ステップ９０１）。この要求はＤＬＧファイルに対する要求であるが、必ずしもＤＬＧファイルが直接要求されるとは限らず、ウェブアプリケーションのルートがアクセスされたときに、予めウェルカムファイル（welcome-file）として定義されたＤＬＧファイルによって間接的に要求されたり、コントローラ・サーブレットであるＤＬＧ実行部１３自身がビジネス・ロジックの結果としてＤＬＧファイルに要求を転送したりすることができる。

ＤＬＧファイルへの要求を受け取ったＤＬＧ実行部１３は、ウェブアプリケーションに定義されたサーブレットマッピング（ServletMapping）により、このＤＬＧファイルへの要求を処理する。これにより、当該要求に対する応答に用いられるＤＬＧファイルが特定される（ステップ９０２）。さらにＤＬＧ実行部１３は、当該要求が含まれるセッションに対して設定されたセッションオブジェクトに端末装置の種類を特定するキー情報が存在するかどうかを調べる（ステップ９０３）。そして、存在しない（すなわち新たなセッションにおける最初の受信）ならば、当該要求に含まれているUser-Agentヘッダの文字列を用いて端末プロファイルＤＢ１１へ問い合わせてキー情報を作成し、セッションオブジェクトに保存する（ステップ９０４）。

ステップ９０３でセッションオブジェクトからキー情報が取得された場合、またはステップ９０４でキー情報が作成された後、ＤＬＧ実行部１３は、当該キー情報を用いてＪＳＰファイル格納部１５を検索し、ステップ９０２で特定されたＤＬＧファイルが当該端末装置に対してスペシャライズされているか、すなわち、当該ＤＬＧファイルに対応し当該端末装置に特化したＪＳＰファイルが既に生成されているかどうかを調べる（ステップ９０５）。ＪＳＰファイル格納部１５に該当するＪＳＰファイルが格納されていないならば、ビュー・スペシャライザ１４に、当該ＪＳＰファイルの生成を指示する。

ビュー・スペシャライザ１４は、ＤＬＧ実行部１３から、キー情報とＤＬＧファイルを特定する情報を取得し、キー情報に基づいて端末プロファイルＤＢ１１から該当する端末装置の属性情報を取得すると共に、ＤＬＧファイル格納部１２からステップ９０２で特定されたＤＬＧファイルを読み出す。そして、端末プロファイルＤＢ１１から取得した端末装置の属性情報に基づいて、ＤＬＧファイル格納部１２から読み出したＤＬＧファイルを当該端末装置に特化したＪＳＰファイルに変換する（ステップ９０６）。

これによって生成されたＪＳＰファイルには、アプリケーション・フローに対応するリンクが多数含まれるが、上述したように本実施の形態では、リンク先はＪＳＰファイルではなくＤＬＧファイルとする。リンク先のＤＬＧファイルを特定する情報は、例えばステップ９０２の処理において得ることができる。
図１０は、本実施形態により図３（Ａ）のＤＬＧファイルから変換され生成されたＪＳＰファイルを示す図である。
ここでは、図５の場合と同様に、端末装置がキー情報「MSIE」で特定された場合のＪＳＰファイルを示している。図５（Ａ）のＪＳＰファイルと比較すると、アクションの転送先がキー情報「MSIE」で特定される端末装置に限定されていないことがわかる。
以上のようにして生成されたＪＳＰファイルは、ＪＳＰファイル格納部１５に格納される。

ステップ９０５で所望のＪＳＰファイルが既に存在していた場合、またはステップ９０６で当該ＪＳＰファイルが生成された後、応答生成部１６が、ＪＳＰファイル格納部１５から当該ＪＳＰファイルを読み出し、ＤＬＧ実行部１３が、端末装置から受け付けた要求を当該ＪＳＰファイルに転送（フォワード）する（ステップ９０７）。
この後、応答生成部１６は、読み出したＪＳＰファイルに基づき、端末装置からの要求に対する、ＨＴＭＬ文書等からなる応答を生成し、当該端末装置に返送する（ステップ９０８）。

図１１は、本実施形態により、図１０のＪＳＰファイルに基づいて生成されるキー情報「MSIE」の端末装置への応答（ＨＴＭＬ文書）を示す図である。
図１１に示した文書をキー情報「MSIE」の端末装置（User-Agent：米国マイクロソフト社のインターネットエクスプローラ）で実行すると、表示画面にSubmitボタンが表示される。端末装置のユーザがこのSubmitボタンをマウスクリックすると、gotoWorldアクションが呼ばれ、ＤＬＧファイルであるWorld.dlgへの転送（フォワード）が行われる。ウェブアプリケーションサーバ１０のＤＬＧ実行部１３は、この要求を受け付けると、図９に示した処理を行うこととなるが、図３（Ａ）のＤＬＧファイル（Hello.dlg）から図１０のＪＳＰファイル（MSIE/Hello.jsp）を生成した際に取得されたキー情報「MSIE」がセッションオブジェクトに保存されているので、ステップ９０３でキー情報が取得でき、ステップ９０４のキー情報の生成は行わずに直接ステップ９０５へ移行する。
以前の操作や他のユーザによる同様の端末装置を用いた操作によって、ＤＬＧファイルHello.dlgやWorld.dlgに対し、当該端末装置に特化したＪＳＰファイルが既に生成されている場合は、ＪＳＰファイル格納部１５に当該ＪＳＰファイルが格納されているので、ステップ９０６の処理は行われずに直接ステップ９０７へ移行する。

以上のようにして、本実施形態によれば、所定の種類の端末装置がウェブアプリケーションを初めて利用しようとした時点で、当該端末装置に特化したＪＳＰファイルを生成して応答するため、ウェブアプリケーションの設計時に当該ウェブアプリケーションを利用可能な全ての種類の端末装置に対するＪＳＰファイルを用意する必要が無く、アプリケーション設計における負担を軽減することができる。また、設計時に想定されていなかった端末装置に対しても、最初のアクセス時に、当該端末装置に対応するＪＳＰファイルを生成して対応し、適切に処理を行うことが可能である。
さらに本実施形態は、要求された処理に応答するためのＪＳＰファイルのみを、その都度生成するため、最初の要求があった時点でウェブアプリケーションの全体に相当するＪＳＰファイルを全て生成する場合のように多大な時間を要することなく、遅延時間の増大を防止できる。また、結果的に使用されないＪＳＰファイルを生成してしまう無駄を省くことができる。

さて、上記の実施形態では、ウェブアプリケーションを多種の端末装置に対応させることを目的としたが、本発明の本質は、ビュー部分のＪＳＰが抽象的な定義である抽象ビューに基づいてクライアント（端末装置）の属性に応じて生成されるようなウェブアプリケーションにおいて、抽象ビューを直接用いて処理を行うことにより、コントローラ部分の煩雑化を防ぐことにある。そこで、本発明のウェブアプリケーションサーバ１０は、多種の端末装置への対応にとどまらず、例えば、抽象表現として国際化ＪＳＰファイルを考え、この国際化ＪＳＰファイルからローカル化ＪＳＰファイルを生成する場合の実行速度を向上させるためにも適用できる。

国際化ＪＳＰファイルの生成は、ＪＳＴＬ（JSP Standard Tag Library）やＳｔｒｕｔｓのタグ・ライブラリを用いれば実現できる。しかし、この場合、各単語、文、段落ごとにタグ・ライブラリが呼ばれるので実行速度が遅い。
これに対して、ウェブアプリケーションの設計時に、各言語リソースをバインドして、国際化ＪＳＰファイルからローカル化ＪＳＰファイルを生成してしまうことが考えられる。例えば、図１２に示すような国際化されたＪＳＰファイル（hello.jsp）があって、図１３に示すような日本語リソース（MyResource_ja.properties）があるならば、図１４に示すような日本語のローカル化ＪＳＰファイル（hello_ja.jsp）をウェブアプリケーションの設計時に生成してしまえば良い。バインドされるテキストはウェブアプリケーション設計時に決まっており変化がないので、タグ・ライブラリを使用する場合と実行結果は同じであるが、この方法ではタグ・ライブラリを呼んでいないので、実行速度が速い。

しかし、このウェブアプリケーション設計時にローカル化ＪＳＰファイルを生成してしまう方法では、コントローラもローカル化されたＪＳＰにフォワードするように書き換えなければならない。この作業は、対象の言語・地域設定（言語環境等、例えばマイクロソフト社のオペレーティングシステムにおけるロケール）の数が増えるにしたがって煩雑になる。
そこで、本発明を用いて、ウェブアプリケーションの実行時にローカル化ＪＳＰを生成することを考える。

図１５は、端末装置からの要求に対して国際化ＪＳＰファイルからローカル化ＪＳＰファイルを生成して応答を行うウェブアプリケーションサーバの機能構成を示す図である。
上述したようにこの実施形態では、業務処理の内容や結果をクライアントに表示させるためのビューを記述する抽象的表現（抽象ビュー）として国際化ＪＳＰが用いられる。したがって、図１５に示すウェブアプリケーションサーバ２０は、図２に示したウェブアプリケーションサーバ１０と比較すると、抽象ビューとしてのＤＬＧファイルを格納したＤＬＧファイル格納部１２の代わりに、国際化ＪＳＰファイルを格納した国際化ＪＳＰファイル格納部２１を備え、ダイアログを対象として処理を行うＤＬＧ実行部１３の代わりに、国際化ＪＳＰを対象として処理を実行する国際化ＪＳＰ実行部２２を備えている。その他の構成要素（端末プロファイルＤＢ１１、ビュー・スペシャライザ１４、ＪＳＰファイル格納部１５および応答生成部１６は、図２に示したウェブアプリケーションサーバ１０の構成要素と同様であるので、同一の符号を付して説明を省略する。

図１５に示したウェブアプリケーションサーバ２０において、国際化ＪＳＰファイル格納部２１は、例えば図１に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５にて実現される。また、国際化ＪＳＰ実行部２２は、例えば図１のプログラム制御されたＣＰＵ１０１の機能として実現される。この国際化ＪＳＰ実行部２２は、所定の端末装置からのウェブアプリケーションに対する要求（ＨＴＴＰリクエスト等）を受け付け、当該要求に対する処理を国際化ＪＳＰのレベルで行い、当該端末装置の言語・地域設定に対応するＪＳＰファイルの生成を制御するローカル化ＪＳＰサーブレット（コントローラ）である。

図１６は、かかる実施形態におけるウェブアプリケーションサーバ２０の動作を説明するフローチャートである。
図１６を参照すると、国際化ＪＳＰ実行部２２は、まず所定の端末装置（User-Agent）から国際化ＪＳＰファイルに対する要求を受け付ける（ステップ１６０１）。
要求を受け取った国際化ＪＳＰ実行部２２は、ウェブアプリケーションに定義されたサーブレットマッピング（ServletMapping）により、この国際化ＪＳＰファイルへの要求を処理する。これにより、当該要求に対する応答に用いられる国際化ＪＳＰファイルが特定される（ステップ１６０２）。さらに国際化ＪＳＰ実行部２２は、当該要求を行った端末装置の言語・地域設定の情報を取得する（ステップ１６０３）。この言語・地域設定の情報は、doGetメソッドやdoPostメソッドにおける第１引数のjavax.servlet.http.HttpServletRequest型のrequestインスタンスに対してgetLocaleメソッドを呼ぶことによって容易に得られる。

次に、国際化ＪＳＰ実行部２２は、ステップ１６０３で取得した言語・地域設定を用いてＪＳＰファイル格納部１５を検索し、ステップ１６０２で特定された国際化ＪＳＰファイルが当該言語・地域設定で既にローカル化されているか、すなわち、当該国際化ＪＳＰファイルに対応するローカル化ＪＳＰファイルが生成されているかを調べる（ステップ１６０４）。ＪＳＰファイル格納部１５に該当するローカル化ＪＳＰファイルが格納されていないならば、ビュー・スペシャライザ１４に、当該ローカル化ＪＳＰファイルの生成を指示する。

ビュー・スペシャライザ１４は、国際化ＪＳＰ実行部２２から言語・地域設定と国際化ＪＳＰファイルを特定する情報を取得し、言語・地域設定の情報に基づいて国際化ＪＳＰファイル格納部２１からステップ１６０２で特定された国際化ＪＳＰファイルを読み出す。そして、当該言語・地域設定に対応するローカル化ＪＳＰファイルに変換する（ステップ１６０５）。これによって生成されたローカル化ＪＳＰファイルには、アプリケーション・フローに対応するリンクが多数含まれるが、リンク先はローカル化ＪＳＰファイルではなく国際化ＪＳＰファイルとする。リンク先の国際化ＪＳＰファイルを特定する情報は、例えばステップ１６０２の処理において得ることができる。

ステップ１６０４で所望のローカル化ＪＳＰファイルが既に存在していた場合、またはステップ１６０５で当該ローカル化ＪＳＰファイルが生成された後、応答生成部１６が、ＪＳＰファイル格納部１５から当該ローカル化ＪＳＰファイルを読み出し、国際化ＪＳＰ実行部２２が、端末装置から受け付けた要求を当該ローカル化ＪＳＰファイルに転送（フォワード）する（ステップ１６０６）。
この後、応答生成部１６は、読み出したローカル化ＪＳＰファイルに基づき、端末装置からの要求に対する、ＨＴＭＬ文書等からなる応答を生成し、当該端末装置に返送する（ステップ１６０７）。

上述した各実施形態は、いずれもウェブアプリケーションのコントローラ部分をサーブレットにて実現した。しかしながら、例えばポータルサーバでは、サーブレットではなくポートレット（Portlet）により、上述したダイアログや国際化ＪＳＰファイルといった抽象表現による定義に対する処理を行うことが要求される。この場合、ＰｏｒｔａｌＳｔｒｕｔｓを用いてこの機能を実現することができる。ＰｏｒｔａｌＳｔｒｕｔｓは、コントローラにおけるアクションによってフォワードされたファイル（ビューに相当）を処理するコマンド（ViewCommand：以下、ビューコマンドと記述）を自由に定義して拡張できる仕組みを提供している。この仕組みを用いてサーブレットの代わりにビューコマンドを実装することにより、ポートレットにおいて、抽象表現による定義に対する処理が可能となる。具体的には、配置記述子でＤＬＧサーブレット（ＤＬＧ実行部１３）を宣言する代わりに、ビューコマンドのファクトリを宣言し、ＤＬＧファイルには、図９に示したアルゴリズムをexecuteメソッドで実装したビューコマンドを生成するように設定する。生成するＳｔｒｕｔｓ設定ファイルとしては、上述したサーブレットを用いた実施形態と同じものを使用することができる。

このように、本発明は、ビュー部分が抽象的な定義に基づいてクライアント（端末装置）の属性に応じて生成されるようなウェブアプリケーションにおいて、クライアントからの要求に対して抽象ビューを直接用いて処理を行った後に当該クライアントに対応する適切なビューを用いて当該クライアントへの応答を行う機能を実現するものであれば、その構成は、必ずしも上述したサーブレットやＪＳＰを用いた構成には限らない。

本発明の実施形態のウェブアプリケーションサーバを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。 本実施形態によるウェブアプリケーションサーバの機能構成を示す図である。 本実施形態にて用いられるＤＬＧファイルの例を示す図である。 本実施形態のＤＬＧ実行部の機能を記述したＸＭＬファイルの例を示す図である。 ウェブアプリケーションの設計時や端末装置から要求があった際に当該ウェブアプリケーションの全体のＪＳＰファイルを生成する手法で生成されるＪＳＰファイルの例を示す図である。 ウェブアプリケーションの設計時や端末装置から要求があった際に当該ウェブアプリケーションの全体のＪＳＰファイルを生成する手法で生成されるＳｔｒｕｔｓ設定ファイルの例を示す図である。 本実施形態にて構築されるウェブアプリケーションにおけるウェブアプリケーション配置記述子の例を示す図である。 本実施形態においてウェブアプリケーションの設計時に生成されるＳｔｒｕｔｓ設定ファイル（struts-config.xml）を示す図である。 本実施形態のＤＬＧ実行部の動作を示すフローチャートである。 本実施形態により図３（Ａ）のＤＬＧファイルから変換され生成されたＪＳＰファイルを示す図である。 本実施形態の応答生成部により生成される端末装置への応答の例を示す図である。 本発明の他の実施形態にて用いられる国際化ＪＳＰファイルの例を示す図である。 本実施形態にて用いられる日本語リソースの例を示す図である。 本実施形態において図１３の日本語リソースを用いて図１２の国際化ＪＳＰファイルをローカル化した例を示す図である。 本実施形態によるウェブアプリケーションサーバの機能構成を示す図である。 本実施形態の国際化ＪＳＰ実行部の動作を示すフローチャートである。

符号の説明

１０、２０…ウェブアプリケーションサーバ、１１…端末プロファイルＤＢ（データベース）、１２…ＤＬＧファイル格納部、１３…ＤＬＧ実行部、１４…ビュー・スペシャライザ、１５…ＪＳＰファイル格納部、１６…応答生成部、２１…国際化ＪＳＰファイル格納部、２２…国際化ＪＳＰ実行部、１０１…ＣＰＵ（中央処理装置）、１０３…メインメモリ、１０５…磁気ディスク装置（ＨＤＤ）、１０６…ネットワークインターフェイス

Claims (18)

1. ネットワークを介して所定のクライアントからの要求を受け付けてウェブアプリケーションを実行するサーバにおいて、
   クライアントにおける表示形態とは独立に画面のデザインを記述したＭＶＣ（Model、View、Control）モデルのビュー定義である抽象ビューを格納した抽象ビュー格納部と、
   前記抽象ビューを用いて前記クライアントからの要求に対する処理を実行する抽象ビュー処理実行部と、
   前記抽象ビュー処理実行部による処理結果に基づいて前記クライアントの属性に対応したビューを生成するビュー生成部と、
   前記ビュー生成部にて生成された前記ビューを用いて前記クライアントへの応答を生成し当該クライアントへ返送する応答生成部と
   を備えることを特徴とするサーバ。
2. 前記ビュー生成部は、ＪＳＰ（Java Server Pages）により前記ビューを生成することを特徴とする請求項１に記載のサーバ。
3. 前記ビュー生成部は、生成された前記ビューに含まれるハイパーリンクのリンク先を前記抽象ビューとすることを特徴とする請求項１に記載のサーバ。
4. 前記ビュー生成部にて生成された前記ビューを保持するビュー格納部をさらに備え、
   前記クライアントからの要求に応じて前記抽象ビュー処理実行部により行われた処理の結果に対応する当該クライアント用のビューが前記ビュー格納部に保持されている場合に、前記ビュー生成部によるビューの生成を行わず、前記応答生成部が、当該ビュー格納部に保持されているビューを用いて前記クライアントへの応答を生成することを特徴とする請求項１に記載のサーバ。
5. 前記抽象ビュー処理実行部は、ウェブアプリケーションを利用可能なクライアントのシステム構成に関わらない抽象表現で記述された抽象ビューに対して処理を実行し、
   前記ビュー生成部は、前記クライアントのシステム構成に適合したビューを生成することを特徴とする請求項１に記載のサーバ。
6. 前記抽象ビュー処理実行部は、国際化ＪＳＰにて記述された抽象ビューに対して処理を実行し、
   前記ビュー生成部は、前記クライアントの言語・地域設定に対応したローカル化ＪＳＰによるビューを生成することを特徴とする請求項１に記載のサーバ。
7. ネットワークを介して所定のクライアントからの要求を受け付けてウェブアプリケーションを実行するサーバにおいて、
   前記クライアントの属性に関わらない抽象表現によってＭＶＣ（Model、View、Control）モデルにおけるビューである画面のデザインを記述した定義を用いて前記ウェブアプリケーションの業務処理を実行する業務実行手段と、
   前記業務実行手段による業務処理の結果に基づいて前記クライアントの属性に適合したＪＳＰ（Java Server Pages）ファイルを生成するＪＳＰファイル生成手段と、
   前記ＪＳＰファイル生成手段にて生成されたＪＳＰファイルを用いて前記クライアントへの応答を生成し当該クライアントに返送する応答手段と
   を備えることを特徴とするサーバ。
8. 前記ＪＳＰファイル生成手段は、生成するＪＳＰファイル内の他のファイルへのハイパーリンクのリンク先を前記抽象表現による前記定義とすることを特徴とする請求項７に記載のサーバ。
9. 前記ＪＳＰファイル生成手段にて生成された前記ＪＳＰファイルを保持するＪＳＰファイル格納手段をさらに備え、
   前記業務実行手段による業務処理の結果に基づく前記クライアントの属性に適合したＪＳＰファイルが前記ＪＳＰファイル格納手段に保持されている場合に、前記ＪＳＰファイル生成手段によるＪＳＰファイルの生成を行わず、前記応答手段が、当該ＪＳＰファイル格納手段に保持されているＪＳＰファイルを用いて前記クライアントへの応答を生成することを特徴とする請求項７に記載のサーバ。
10. ネットワークを介して所定のクライアントからの要求を受け付けてウェブアプリケーションを実行するサーバにおいて、
    前記クライアントの属性に関わらない抽象表現によってＭＶＣ（Model、View、Control）モデルにおけるビューである画面のデザインを記述した定義を格納した定義格納手段と、
    前記抽象表現による前記定義を用いて前記クライアントからの要求に対する処理を実行する処理実行手段と、
    前記処理実行手段による処理結果を前記クライアントにて表示可能とするためのテンプレートを生成するテンプレート生成手段と、
    前記テンプレート生成手段にて生成されたテンプレートを用いて前記処理実行手段による処理結果を前記クライアントに表示させるための応答を生成し当該クライアントへ返送する応答手段と
    を備えることを特徴とするサーバ。
11. 前記テンプレート生成手段は、生成するテンプレートに含まれるハイパーリンクのリンク先を前記抽象表現による前記定義とすることを特徴とする請求項１０に記載のサーバ。
12. ネットワークに接続されたコンピュータを用いて、所定のクライアントからの要求を受け付けてウェブアプリケーションによる業務処理を実行する情報処理方法であって、
    前記クライアントからの要求を受け付け、所定の記憶装置に格納されている前記クライアントの属性に関わらない抽象表現によってＭＶＣ（Model、View、Control）モデルにおけるビューである画面のデザインを記述した定義を用いて前記ウェブアプリケーションの業務処理を実行する第１のステップと、
    前記業務処理の結果を前記クライアントにて表示可能とするためのテンプレートを生成し、所定の記憶装置に格納する第２のステップと、
    前記記憶装置に格納された前記テンプレートを用いて前記要求に対する応答を生成し前記クライアントへ返送する第３のステップと
    を含むことを特徴とする情報処理方法。
13. 前記第２のステップでは、前記第１のステップにおける業務処理の結果に対応する前記テンプレートが既に前記所定の記憶装置に格納されている場合に、改めて当該テンプレートを生成しないことを特徴とする請求項１２に記載の情報処理方法。
14. ネットワークに接続されたコンピュータを制御して、所定のクライアントからの要求を受け付けてウェブアプリケーションによる業務処理を実行させるプログラムであって、
    前記クライアントからの要求を受け付け、所定の記憶装置に格納されている前記クライアントの属性に関わらない抽象表現によってＭＶＣ（Model、View、Control）モデルにおけるビューである画面のデザインを記述した定義を用いて前記ウェブアプリケーションの業務処理を実行する第１の処理と、
    前記業務処理の結果を前記クライアントにて表示可能とするためのテンプレートを生成し、所定の記憶装置に格納する第２の処理と、
    前記記憶装置に格納された前記テンプレートを用いて前記要求に対する応答を生成し前記クライアントへ返送する第３の処理と
    を前記コンピュータに実行させることを特徴とするプログラム。
15. 前記第２の処理では、前記テンプレートとしてＪＳＰ（Java Server Pages）ファイルを生成することを特徴とする請求項１４に記載のプログラム。
16. 前記第２の処理では、前記第１の処理における業務処理の結果に対応する前記テンプレートが既に前記所定の記憶装置に格納されている場合に、改めて当該テンプレートを生成しないことを特徴とする請求項１４に記載のプログラム。
17. 前記第２の処理では、生成するテンプレートに含まれるハイパーリンクのリンク先を前記抽象表現による前記定義とすることを特徴とする請求項１４に記載のプログラム。
18. ネットワークに接続されたコンピュータを制御して、所定のクライアントからの要求を受け付けてウェブアプリケーションによる業務処理を実行させるプログラムであって、
    前記クライアントからの要求を受け付け、所定の記憶装置に格納されている、クライアントにおける表示形態とは独立に画面のデザインを記述したＭＶＣ（Model、View、Control）モデルのビュー定義である抽象ビューを用いて、当該要求に対する処理を実行する処理実行手段と、
    前記処理の結果に基づいて前記クライアントの属性に対応したビューを生成し、所定の記憶装置に格納するビュー変換手段と、
    前記所定の記憶装置に格納された前記ビューを用いて前記クライアントへの応答を生成し当該クライアントへ返送する応答生成手段として
    前記コンピュータを機能させることを特徴とするプログラム。

Images