(57)【要約】【課題】クライアント実装技術の差を吸収して、アプリケーションの開発効率を向上させる。【解決手段】本発明の一態様に係るフレームワーク９は、コンピュータ３を、クライアント実装技術に依存するデータと、このデータのデータ形式を表すデータ形式情報と、クライアント実装技術を表すクライアント実装技術識別子とを含む受信データに基づいて、クライアント実装技術を特定する特定手段１６、クライアント実装技術と変換依頼先とを関係付けた関係データ１４Ａと特定されたクライアント実装技術とに基づいて、クライアント実装技術に対応する変換依頼先を決定する変換管理手段１７１、変換管理手段１７１によって決定された変換依頼先に該当する場合に、受信データのデータ形式情報に基づいて、受信データに含まれているクライアント実装技術に対応する形式のデータを、アプリケーション８用の共通形式のデータに変換する変換手段１３２Ａとして機能させる。【選択図】      図１
2011096112.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
「クライアントのクライアント実装技術に依存するデータと、前記データのデータ形式を指定するデータ形式情報と、前記クライアント実装技術を表すクライアント実装技術識別子とを含み第１の記憶装置に記憶されている受信データ」に基づいて、前記クライアント実装技術を特定するクライアント特定手段、
「第２の記憶装置に記憶されており前記クライアント実装技術と受信データ変換依頼先とを関係付けている関係データ」と、前記クライアント特定手段によって特定された前記クライアント実装技術とに基づいて、前記クライアント実装技術に対応する前記受信データ変換依頼先を決定する受信データ変換管理手段、
前記受信データ変換管理手段によって決定された前記受信データ変換依頼先に該当する場合に、前記受信データのデータ形式情報に基づいて、前記受信データに含まれている前記クライアント実装技術に対応する形式のデータを、アプリケーションで用いられている共通形式のデータに変換し、前記共通形式のデータを第３の記憶装置に記憶する受信データ変換手段
として機能させるためのフレームワーク。
【請求項２】
請求項１記載のフレームワークにおいて、
前記コンピュータを、さらに、
複数の受信データ変換先に対する共通のインタフェースを、前記受信データ変換管理手段に対して提供する受信データ変換インタフェースとして機能させるためのフレームワーク。
【請求項３】
請求項１又は請求項２記載のフレームワークにおいて、
前記関係データは、さらに、前記クライアント実装技術と返信データ変換依頼先とを関係付けており、
前記コンピュータを、さらに、
前記アプリケーションによって共通形式の返信データが生成された場合に、前記第２の記憶装置に記憶されている前記関係データと、前記クライアント特定手段によって特定された前記クライアント実装技術とに基づいて、前記クライアント実装技術に対応する前記返信データ変換依頼先を決定する返信データ変換管理手段、
前記返信データ変換管理手段によって決定された前記返信データ変換依頼先に該当する場合に、第４の記憶装置に記憶されている前記共通形式の返信データを、前記クライアント実装技術に対応する形式の返信データに変換し、前記クライアント実装技術に対応する形式の返信データを第５の記憶装置に記憶する返信データ変換手段
として機能させるためのフレームワーク。
【請求項４】
請求項３記載のフレームワークにおいて、
前記コンピュータを、さらに、
複数の返信データ変換依頼先に対する共通のインタフェースを、前記返信データ変換管理手段に対して提供する返信データ変換インタフェースとして機能させるためのフレームワーク。
【請求項５】
請求項１乃至請求項４のいずれか１項に記載のフレームワークにおいて、
前記関係データは、さらに、前記クライアント実装技術と例外データ変換依頼先とを関係付けており、
前記コンピュータを、さらに、
前記アプリケーションにおいて例外処理が発生した場合に、前記第２の記憶装置に記憶されている前記関係データと、前記クライアント特定手段によって特定された前記クライアント実装技術とに基づいて、前記クライアント実装技術に対応する前記例外データ変換依頼先を決定する例外データ変換管理手段、
前記例外データ変換管理手段によって決定された前記例外データ変換依頼先に該当する場合に、第６の記憶装置に記憶されている前記アプリケーションの共通形式の例外データを、前記クライアント実装技術に対応する形式の例外データに変換し、前記クライアント実装技術に対応する形式の例外データを第７の記憶装置に記憶する例外データ変換手段
として機能させるためのフレームワーク。
【請求項６】
請求項５記載のフレームワークにおいて、
前記コンピュータを、さらに、
複数の例外データ変換依頼先に対する共通のインタフェースを、前記例外データ変換管理手段に対して提供する例外データ変換インタフェースとして機能させるためのフレームワーク。
【請求項７】
クライアントのクライアント実装技術に依存するデータと、前記データのデータ形式を指定するデータ形式情報と、前記クライアント実装技術を表すクライアント実装技術識別子とを含み第１の記憶装置に記憶されている受信データに基づいて、前記クライアント実装技術を特定するクライアント特定手段と、
第２の記憶装置に記憶されており前記クライアント実装技術と受信データ変換依頼先とを関係付けている関係データと、前記クライアント特定手段によって特定された前記クライアント実装技術とに基づいて、前記クライアント実装技術に対応する前記受信データ変換依頼先を決定する受信データ変換管理手段と、
前記受信データ変換管理手段によって決定された前記受信データ変換依頼先に該当する場合に、前記受信データのデータ形式情報に基づいて、前記受信データに含まれている前記クライアント実装技術に対応する形式のデータを、アプリケーションで用いられている共通形式のデータに変換し、前記共通形式のデータを第３の記憶装置に記憶する受信データ変換手段と
を具備する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション・ソフトウェアを開発する際に頻繁に必要とされる汎用的な機能をまとめて提供するフレームワーク及び情報処理装置に関する。
【背景技術】
【０００２】
Ｗｅｂアプリケーションの開発において、ユーザによって操作される画面の操作性を向上させるため、クライアントアプリケーションの実装にリッチクライアント技術が利用される場合がある。
【０００３】
リッチクライアント技術には、例えば、ブラウザ上で動作するAjax（Asynchronous JavaScript（登録商標）＋XML）、ブラウザへのプラグインで実現されるFlash（登録商標）、クライアントのコンピュータにインストールされるWindows（登録商標）アプリケーションなど様々な種別がある。リッチクライアント技術では、サーバ側がJava（登録商標）言語（Java EE）で生成される場合が多い。
【０００４】
そして、近年のエンタープライズシステムにおいて、サーバアプリケーションは、Java EE（Java Platform、Enterprise Edition）によって実装されることが多い。
【０００５】
なお、クライアントにリッチクライアント技術が利用されているＷｅｂアプリケーションは、RIA（Rich Internet Application）と呼ばれるが、RIAのクライアントとサーバとの間を繋ぐためのOSS（Open Source Software）又は製品のライブラリ（通信ライブラリ）が多数リリースされている。RIAは、一般的に、このようなライブラリを用いて開発される。
【０００６】
例えば、AjaxではOSSのDWRが利用され、WindowsアプリケーションではOSSのApache Axis（登録商標）が利用され、FlashではBlazeDSが利用される。
【０００７】
データ形式変換に関する技術として、特許文献１（特開２００６−２６８１２１号公報）と、特許文献２（特開２００６−１４６６７７号公報）がある。
【０００８】
特許文献１には、少なくともクライアントとのインタフェース層とビジネスロジックを実行する層とに分離されたＷｅｂアプリケーションシステムにおいて、プレゼンテーションレイヤがビジネスロジックを呼び出す際に、このビジネスロジックが必要とするデータのみを抽出して渡すようにし、あるいはビジネスレイヤによる応答の中にマッピングクラスのインスタンスが含まれている場合でも、プレゼンテーションレイヤ側に渡すことを可能とすることが、記載されている。
【０００９】
特許文献２には、データを入力する入力画面を有するアプリケーションの開発支援システム及び該システムを用いたデータフォーマット生成方法であって、前記入力画面から入力された入力データを処理する業務プログラムが対象とする業務データのフォーマットから前記入力画面が利用するための入力データのフォーマットを生成し、さらに該入力データから前記業務データを生成するためのフォーマット変換定義を生成するデータフォーマット変換定義モジュールと、該データフォーマット変換定義モジュールで生成された入力データフォーマットにおけるデータを入力するための入力画面を定義する入力画面定義モジュールと、該入力画面定義モジュールで定義された入力画面定義及び前記データフォーマット変換定義モジュールで生成されたフォーマット変換定義を入力して、前記入力画面定義を一意に特定するＩＤを有する入力画面識別ＩＤ付きフォーマット変換定義を生成するフォーマット変換関連定義モジュールとを有することが、記載されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００６−２６８１２１号公報
【特許文献２】特開２００６−１４６６７７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
多くのリッチクライアント技術では、サーバ側がJava言語で生成される。
【００１２】
しかしながら、クライアントとサーバとの間の通信プロトコル及び送受信されるデータの形式は、リッチクライアント技術ごとに異なる。例えば、クライアントとサーバとの間の通信に使用されるライブラリが異なれば、送受信可能なデータの形式も異なる。
【００１３】
このため、サーバのアプリケーションを例えばJava EEという統一したプラットフォームで開発する場合であっても、それぞれのクライアントの種別に対応するアプリケーションをサーバ側に実装させる必要があり、サーバ側のアプリケーションについてそれぞれのリッチクライアント技術に依存した開発を行う必要がある。
【００１４】
したがって、以下のような問題が発生する。
【００１５】
第１に、新たなリッチクライアント技術を採用してシステムを開発する場合に、その新たなリッチクライアント技術を使ったサーバアプリケーションの開発方法を開発者が学習する必要があり、開発労力及び時間が過大となる。
【００１６】
第２に、同じ仕様のRIAであっても、採用するリッチクライアント技術が異なると、サーバ側のアプリケーションを別々に開発する必要があり、開発労力及び時間が過大となる。
【００１７】
第３に、あるリッチクライアント技術によって開発されたRIAに対して、クライアントのバリエーションを追加すると、サーバアプリケーションの作り直しが必要になり、開発労力及び時間が過大となる。
【００１８】
上記の特許文献１，２は、フレームワークにおいて、複数のクライアント実装技術に対応する形式の受信データを統一した共通形式のデータに自動的に変換し、クライアント実装技術の違いを吸収する技術ではない。
【００１９】
本発明は、以上のような実情に鑑みてなされたもので、クライアント実装技術の差を吸収して、アプリケーションの開発効率を向上させることを目的とする。
【課題を解決するための手段】
【００２０】
本発明の第１の態様に係るフレームワークは、コンピュータを、クライアントのクライアント実装技術に依存するデータと、前記データのデータ形式を指定するデータ形式情報と、前記クライアント実装技術を表すクライアント実装技術識別子とを含み第１の記憶装置に記憶されている受信データに基づいて、前記クライアント実装技術を特定するクライアント特定手段、第２の記憶装置に記憶されており前記クライアント実装技術と受信データ変換依頼先とを関係付けている関係データと、前記クライアント特定手段によって特定された前記クライアント実装技術とに基づいて、前記クライアント実装技術に対応する前記受信データ変換依頼先を決定する受信データ変換管理手段、前記受信データ変換管理手段によって決定された前記受信データ変換依頼先に該当する場合に、前記受信データのデータ形式情報に基づいて、前記受信データに含まれている前記クライアント実装技術に対応する形式のデータを、アプリケーションで用いられている共通形式のデータに変換し、前記共通形式のデータを第３の記憶装置に記憶する受信データ変換手段として機能させる。
【００２１】
なお、上記の態様はフレームワーク、すなわちプログラムとして表現されている。しかしながら、これに限らず、上記の態様は、情報処理装置、情報処理方法、コンピュータ読み取り可能な記憶媒体などで表現されるとしてもよい。
【発明の効果】
【００２２】
本発明においては、クライアント実装技術の差を吸収して、アプリケーションの開発効率を向上させることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の第１の実施の形態に係る情報処理システムの一例を示すブロック図。
【図２】第１の実施の形態において、受信データに、クライアント実装技術識別子とデータ形式とが付加されたデータが、クライアントフレームワークによって生成される状態の一例を示す図。
【図３】関係データを記憶する記憶装置の一例を示す図。
【図４】第１の実施の形態に係るサーバフレームワークによるリクエストの変換の一例を示す図。
【図５】クライアント実装技術「Ajax」に対応する通信ライブラリとしてDWRを用いた場合に、サーバ側で利用可能なデータの形式の一例を示す図。
【図６】クライアント実装技術「Windowsアプリケーション」に対応する通信ライブラリとしてApach Axisを用いた場合に、サーバ側で利用可能なデータの形式の一例を示す図。
【図７】第１の実施の形態に係るクライアントマシンにおけるリクエスト送信処理の一例を示すシーケンス図。
【図８】第１の実施の形態に係るサーバマシンによってリクエストが受信・変換される処理の一例を示すシーケンス図。
【図９】第１の実施の形態に係るサーバマシンからクライアントマシンに返信される返信データに対する処理の一例を示すシーケンス図。
【図１０】第１の実施の形態に係るサーバマシンからクライアントマシンに送信される例外データに対する処理の一例を示すシーケンス図。
【図１１】従来のサーバ側のソフトウェア構成の一例を示すブロック図。
【図１２】第１の実施の形態に係るサーバ側のソフトウェア構成の一例を示すブロック図。
【図１３】第１の実施の形態に係るサーバマシンのハードウェア構成の一例を示すブロック図。
【図１４】本発明の第２の実施の形態に係る情報処理システムの一例を示すブロック図。
【発明を実施するための形態】
【００２４】
以下、図面を参照しながら本発明の実施の形態について説明する。なお、以下の各図において同一又はほぼ同一の要素には同一の符号を付して説明を省略するか又は簡単に説明し、異なる部分についてのみ詳しく説明する。
【００２５】
（第１の実施の形態）
本実施の形態においては、例えばリッチクライアント技術などのようなクライアント実装技術（例えばアプリケーション実装技術でもよい）の違いを吸収するサーバ側のフレームワークについて説明する。
【００２６】
なお、本実施の形態においては、クライアントマシンからサーバマシンへリクエストが送信され、このリクエストに応じてサーバマシンで処理が実行される場合を例に説明する。本実施の形態において、リクエストにはデータが含まれているとする。しかしながら、クライアントマシンからサーバマシンへ、リクエストではない他の各種データ又は情報が送信され、サーバマシンに受信されたデータ又は情報に応じてサーバマシンによって処理が実行される場合でも同様である。
【００２７】
図１は、本実施の形態に係る情報処理システムの一例を示すブロック図である。
【００２８】
情報処理システム１は、１台以上のクライアントマシン（クライアント側の情報処理装置）２と、サーバマシン（サーバ側の情報処理装置）３を具備する。クライアントマシン２とサーバマシン３とは、ネットワーク経由で接続される。
【００２９】
クライアントマシン２は、クライアントアプリケーション４Ａ、クライアントフレームワーク５Ａ、クライアント側の通信ライブラリ６Ａ、記憶装置７を具備する。クライアントアプリケーション４Ａ、クライアントフレームワーク５Ａ、クライアント側の通信ライブラリ６Ａは、記憶装置７をアクセスしつつ、各種の処理を実行する。
【００３０】
サーバマシン３は、サーバアプリケーション８、サーバフレームワーク９、サーバ側の通信ライブラリ１０Ａ、記憶装置１１を具備する。サーバアプリケーション８、サーバフレームワーク９、サーバ側の通信ライブラリ１０Ａは、記憶装置１１をアクセスしつつ、各種の処理を実行する。
【００３１】
サーバフレームワーク９は、リッチクライアント技術ごとに異なるクライアント・サーバ間のデータ形式の違いを吸収する処理を実行し、リッチクライアント技術に依存しない共通データ形式のデータを生成する。これにより、リッチクライアント技術に依存しないサーバアプリケーション８を開発することができる。
【００３２】
以下に、情報処理システム１の各構成要素について説明する。
【００３３】
本実施の形態に係るRIAにおいて、サーバアプリケーション８は、業務処理（実体的な処理）を実行し、クライアントアプリケーション４Ａは、この業務処理への入力又は処理結果の出力を実行する。
【００３４】
サーバアプリケーション８とサーバ側の通信ライブラリ１０Ａとの間にサーバフレームワーク９を備えることにより、サーバアプリケーション８において、クライアント実装技術に依存したコードを排除可能である。
【００３５】
クライアントアプリケーション４Ａは、第１のクライアント実装技術に基づいて生成されたアプリケーションである。
【００３６】
クライアント側の通信ライブラリ６Ａ及びサーバ側の通信ライブラリ１０Ａは、第１のクライアント実装技術に対応したクライアントマシン２とサーバマシン３との間のデータ送受信を行うためのライブラリである。クライアント側の通信ライブラリ６Ａ及びサーバ側の通信ライブラリ１０Ａとして、例えば、AjaxのDWR、WindowsアプリケーションのApache Axis、FlashのBlazeDSなどが用いられる。
【００３７】
クライアントアプリケーション４Ａ、クライアントフレームワーク５Ａ、クライアント側通信ライブラリ６Ａは、第１のクライアント実装技術に対応する。
【００３８】
クライアントアプリケーション４Ｂ、クライアントフレームワーク５Ｂ、クライアント側通信ライブラリ６Ｂは、第２のクライアント実装技術に対応する。
【００３９】
本実施の形態においては、第１のクライアント実装技術に基づいてリクエストが発行される場合を例として説明するが、他のクライアント実装技術に基づいてリクエストが発行される場合についても同様である。
【００４０】
例えば、クライアント実装技術の種別としては、Ajax、Windowsアプリケーション、Flash、Flexなどがある。
【００４１】
クライアントフレームワーク５Ａは、クライアントマシン２で動作するフレームワークである。クライアントフレームワーク５Ａは、クライアントアプリケーション４Ａに必要とされる汎用的な機能を提供する。
【００４２】
クライアントフレームワーク５Ａは、クライアントアプリケーション４Ａがサーバマシン３にリクエストを送信する際に実行される。クライアントフレームワーク５Ａは、クライアントマシン２からサーバマシン３に送信されるリクエストに、クライアント実行技術識別子と、データ形式情報を付加する。
【００４３】
クライアント実装技術識別子は、リクエストを発行したクライアント実装技術（例えば、Ajax、Windows、Flexなど）を特定するための情報である。
【００４４】
データ形式情報は、例えば、文字列、リスト、表などのような各種データの形式を表す情報である。
【００４５】
サーバフレームワーク９は、サーバマシン３で動作するフレームワークである。サーバフレームワーク９は、サーバアプリケーション８に必要とされる汎用的な機能を提供する。本実施の形態において、サーバフレームワーク９は、１以上のクライアントマシンのいずれか（本実施の形態ではクライアントマシン２）から送信された例えば、Ajax、Windowsアプリケーション、Flexなどのように形式の異なるリクエストを受信し、リクエストのデータを、クライアント実装技術に依存しない形式のデータに変換し、共通受信データ格納部１２１に格納する。
【００４６】
本実施の形態において、共通受信データ格納部１２１は、共通形式の受信データを含むオブジェクトである。例えば、変換後の共通形式の受信データは、記憶装置１１に記憶される。
【００４７】
サーバアプリケーション８は、共通受信データ格納部１２１に格納された共通形式の受信データを用いて業務処理を実行する。サーバアプリケーション８からクライアントマシンに返却されるデータは、クライアント実装技術に依存しない共通返信データ格納部１２２に格納される。
【００４８】
本実施の形態において、共通返信データ格納部１２２は、共通形式の返信データを含むオブジェクトである。例えば、サーバアプリケーション８によって生成された共通返信データは、記憶装置１１に記憶される。
【００４９】
サーバフレームワーク９は、この共通返信データ格納部１２２に格納されたデータを、リクエストを発行したクライアント実装技術に対応する形式に変換し、返信先のクライアントマシン２に返信する。
【００５０】
サーバアプリケーション８で例外処理が発生した場合（例えば、異常が発生した場合）、例外データは共通例外データ格納部１２３に格納される。
【００５１】
本実施の形態において、共通例外データ格納部１２３は、共通形式の例外データを含むオブジェクトである。例えば、サーバアプリケーション８によって生成された共通例外データは、記憶装置１１に記憶される。
【００５２】
サーバフレームワーク９は、この共通例外データ格納部１２３に格納されたデータを、リクエストを発行したクライアント実装技術に対応する形式に変換し、返信先のクライアントマシン２に返信する。
【００５３】
サーバアプリケーション８で扱われるデータは、クライアント実装技術に依存しない形式で共通受信データ格納部１２１、共通返信データ格納部１２２、共通例外データ格納部１２３に格納される。このため、サーバアプリケーション８は、クライアント実装技術に依存せず、各種のクライアント実装技術に対して共通に適用される。
【００５４】
本実施の形態に係るサーバフレームワーク９において、第１のクライアント実装技術に対しては、関係データ（クライアント技術変換部対応定義）１３１Ａ、受信データ変換部１３２Ａ、返信データ変換部１３３Ａ、例外データ変換部１３４Ａの組み合わせである第１の変換部１４Ａが適用される。
【００５５】
第２のクライアント実装技術に対しては、関係データ１３１Ｂ、受信データ変換部１３２Ｂ、返信データ変換部１３３Ｂ、例外データ変換部１３４Ｂの組み合わせである第２の変換部１４Ｂが適用される。
【００５６】
新規のクライアント実装技術にサーバフレームワーク９を対応させる場合には、新規の関係データ、受信データ変換部、返信データ変換部、例外データ変換部の組み合わせである新規の変換部を追加する。既存のクライアント実装技術が変更された場合には、この変更されたクライアント実装技術に対応する変換後の変換部が備えられる。
【００５７】
このように、本実施の形態においては、クライアント実装技術の種別に応じて、関係データ、受信データ変換部、返信データ変換部、例外データ変換部がサーバフレームワーク９に備えられる。
【００５８】
サーバフレームワーク９は、クライアント実装技術の種別に応じて、関係データ及びデータ変換に用いられるデータ変換部を切り換える機構を備える。これにより、サーバフレームワーク９は、今後のクライアント実装技術の追加に柔軟に対応可能となる。
【００５９】
サーバフレームワーク９は、共通リクエスト処理部１５、クライアント特定部１６、受信データ変換管理部１７１、受信データインタフェース１８１、関係データ１３１Ａ，１３１Ｂ、受信データ変換部１３２Ａ，１３２Ｂ、共通受信データ格納部１２１を具備する。
【００６０】
また、サーバフレームワーク９は、共通返信データ格納部１２２、返信データ変換管理部１７２、返信データ変換インタフェース１８２、返信データ変換部１３３Ａ，１３３Ｂを具備する。
【００６１】
さらに、サーバフレームワーク９は、共通例外データ格納部１２３、例外データ変換管理部１７３、例外データ変換インタフェース１８３、例外データ変換部１３４Ａ，１３４Ｂを具備する。
【００６２】
共通リクエスト処理部１５は、クライアントマシン２とサーバマシン３との間で送受信されるすべてのリクエスト及びデータを処理する。
【００６３】
サーバ側通信ライブラリ１０Ａによってクライアントマシン２からのリクエストが受信されると、サーバ側通信ライブラリ１０Ａは、処理を共通リクエスト処理部１５に委譲する。
【００６４】
本実施の形態に係るサーバマシン３は、それぞれ、第１及び第２のクライアント実装技術に対応するサーバ側通信ライブラリ１０Ａ，１０Ｂを備える。なお、サーバマシン３は、他のクライアント実装技術に対応するサーバ側通信ライブラリをさらに備えているとしてもよい。
【００６５】
共通リクエスト処理部１５は、クライアント特定部１６を用いて、リクエストから、このリクエストを発信したクライアント実装技術を特定するクライアント実装技術識別子を取得する。
【００６６】
共通リクエスト処理部１５は、クライアント実装技術識別子と受信されたリクエストとを、受信データ変換管理部１７１に渡し、共通受信データ格納部１２１の生成処理を依頼する。
【００６７】
すると、受信データ変換管理部１７１は、受信されたリクエストを、受信データ変換インタフェース１８１経由で、受信データ変換部１３２Ａに渡す。
【００６８】
受信データ変換部１３２Ａでは、受信されたリクエストに基づいて、共通受信データ格納部１２１が生成される。
【００６９】
共通リクエスト処理部１５は、生成された共通受信データ格納部１２１をサーバアプリケーション８に渡して業務処理の実行を依頼する。
【００７０】
また、共通リクエスト処理部１５は、サーバアプリケーション８の処理結果として生成され返却された共通返信データ格納部１２２とクライアント実装技術識別子を、返信データ変換管理部１７２に渡し、共通返信データ格納部１２２に格納されている共通形式のデータを返信先のクライアント実装技術に対応するデータ形式に変換する返信データの生成処理を依頼する。
【００７１】
すると、返信データ変換管理部１７２は、共通返信データ格納部１２２を、返信データ変換インタフェース１８２経由で、返信データ変換部１３３Ａに渡す。
【００７２】
返信データ変換部１３３Ａでは、共通返信データ格納部１２２に格納されている共通形式の返信データが変換され、返信先のクライアント実装技術に対応するデータ形式の返信データが生成される。
【００７３】
共通リクエスト処理部１５は、変換された返信データを、サーバ側の通信ライブラリ１０Ａに返却する。
【００７４】
さらに、共通リクエスト処理部１５は、サーバアプリケーション８の処理中に例外処理が発生した場合に、発生した例外データを格納した共通例外データ格納部１２３とクライアント実装技術識別子を例外データ変換管理部１７３に渡し、共通例外データ格納部１２３に格納されている共通形式のデータを返信先のクライアント実装技術に対応するデータ形式に変換する例外データの生成処理を依頼する。
【００７５】
すると、例外データ変換管理部１７３は、共通例外データ格納部１２３を、例外データ変換インタフェース１８３経由で、例外データ変換部１３４Ａに渡す。
【００７６】
例外データ変換部１３４Ａでは、共通例外データ格納部１２３に格納されている共通形式の例外データが変換され、返信先のクライアント実装技術に対応するデータ形式の例外データが生成される。
【００７７】
共通リクエスト処理部１５は、この変換された例外データを、サーバ側の通信ライブラリ１０Ａに返却する。
【００７８】
クライアント特定部１６は、クライアントフレームワーク５Ａによってリクエストに付加されたクライアント実装技術識別子を抽出し、クライアント実装技術の種別を特定する。
【００７９】
受信データ変換管理部１７１は、リクエストに含まれるデータを変換して共通受信データ格納部１２１へ格納する処理を受け付ける。
【００８０】
受信データ変換管理部１７１は、関係データ１３１Ａとクライアント特定部１６によって抽出されたクライアント実装技術識別子とに基づいて、このクライアント実装技術識別子に対応する受信データ変換部１３２Ａを特定し、受信データ変換インタフェース１８１を経由して、この特定された受信データ変換部１３２Ａに変換処理を依頼する。
【００８１】
受信データ変換インタフェース１８１は、各種の受信データ変換部１３２Ａ，１３２Ｂに共通したインタフェースを受信データ変換管理部１７１に提供する。
【００８２】
受信データ変換管理部１７１は、受信データ変換インタフェース１８１を用いることにより、複数の受信データ変換部のうちの選択された受信データ変換部１３２Ａに処理実行を依頼可能となる。
【００８３】
受信データ変換部１３２Ａは、クライアントフレームワーク５Ａによってリクエストに付加されたデータ形式情報に基づいて、クライアント実装技術に依存しない共通形式のデータを生成し、この共通形式のデータを共通受信データ格納部１２１に格納する。
【００８４】
共通受信データ格納部１２１は、クライアント実装技術に依存しない共通形式の受信データが格納される入れ物である。本実施の形態において、共通受信データ格納部１２１はオブジェクトであり、記憶装置１１に記憶される。
【００８５】
共通返信データ格納部１２２は、サーバアプリケーション８から返信先のクライアントマシン２に返信されるデータを格納する入れ物である。本実施の形態において、共通返信データ格納部１２２はオブジェクトであり、記憶装置１１に記憶される。
【００８６】
返信データ変換管理部１７２は、サーバアプリケーション８によって生成され返却される共通返信データ格納部１２２のデータを、返却先のクライアント実装技術に対応する形式に変換する処理を受け付ける。
【００８７】
返信データ変換管理部１７２は、関係データ１３１Ａとクライアント特定部１６によって特定されたクライアント実装技術識別子とに基づいて、このクライアント実装技術識別子に対応する返信データ変換部１３３Ａを特定し、返信データ変換インタフェース１８２を経由して、この特定された返信データ変換部１３３Ａに変換処理を依頼する。
【００８８】
返信データ変換インタフェース１８２は、各種のクライアント実装技術識別子に対応する返信データ変換部１３３Ａ，１３３Ｂに共通したインタフェースを、返信データ変換管理部１７２に提供する。
【００８９】
返信データ変換管理部１７２は、返信データ変換インタフェース１８２を用いることにより、複数の返信データ変換部のうちの選択された返信データ変換部１３３Ａに処理実行を依頼可能となる。
【００９０】
返信データ変換部１３３Ａは、共通返信データ格納部１２２のデータを、リクエストを発信したクライアント実装技術に依存する形式に変換する。
【００９１】
共通例外データ格納部１２３は、サーバアプリケーション８で発生された例外データを格納する入れ物である。本実施の形態において、共通例外データ格納部１２３はオブジェクトであり、記憶装置１１に記憶される。
【００９２】
例外データ変換管理部１７３は、サーバアプリケーション８によって発生された例外データを、返信先のクライアント実装技術に対応するデータ形式に変換する処理を受け付ける。
【００９３】
例外データ変換管理部１７３は、関係データ１３１Ａとクライアント特定部１６によって特定されたクライアント実装技術識別子とに基づいて、このクライアント実装技術識別子に対応する例外データ変換部１３４Ａを特定し、例外データ変換インタフェース１３４Ａを経由して、この特定された例外データ変換部１３４Ａに変換処理を依頼する。
【００９４】
例外データ変換インタフェース１８３は、各種のクライアント実装技術識別子に対応する例外データ変換部１３４Ａ，１３４Ｂに共通したインタフェースを、例外データ変換管理部１７３に提供する。
【００９５】
例外データ変換管理部１７３は、例外データ変換インタフェース１８３を用いることにより、複数の例外データ変換部のうちの選択された例外データ変換部１３４Ａに処理実行を依頼可能となる。
【００９６】
例外データ変換部１３４Ａは、共通例外データ格納部１２３のデータを、リクエストを発信したクライアント実装技術に依存する形式に変換する。
【００９７】
関係データ１３１Ａは、第１のクライアント実装技術識別子に対応する受信データ変換部１３２Ａ、返信データ変換部１３３Ａ、例外データ変換部１３４Ａが定義されているデータである。
【００９８】
関係データ１３１Ｂは、第２のクライアント実装技術識別子に対応する受信データ変換部１３２Ｂ、返信データ変換部１３３Ｂ、例外データ変換部１３４Ｂが定義されているデータである。
【００９９】
これらの関係データ１３１Ａ，１３１Ｂは、記憶装置１１内であり、サーバフレームワーク９によって参照可能なパス上に配置される。
【０１００】
例えば、関係データ１３１Ａのファイル名には、第１のクライアント実装技術識別子が含まれる。新規のクライアント実装技術が追加された場合には、新規のクライアント実装技術識別子をファイル名に含む関係データがパス上に配置される。これにより、新規のクライアント実装技術識別子から、この新規のクライアント実装技術識別子に対応する関係データを検索することが可能であり、さらに、新規のクライアント実装技術に対応する受信データ変換管理部、返信データ変換管理部、例外データ変換管理部を特定可能である。
【０１０１】
本実施の形態に係るサーバフレームワーク９は、第１のクライアント実装技術を示すクライアント実装技術識別子を含むリクエスト（各種のデータ又は情報を含む）を受信すると、クライアント特定部１６によってリクエストを発行した第１のクライアント実装技術（リッチクライアント技術）を特定する。
【０１０２】
受信データ変換管理部１７１は、特定された第１のクライアント実装技術に対応する関係データ１３１Ａに基づいて、第１のクライアント実装技術に対応する受信データ変換部１３２Ａを生成する。
【０１０３】
受信データ変換部１３２Ａは、リクエストを、クライアント実装技術に依存しない共通データ形式に変換し、共通データ形式のデータを共通受信データ格納部１２１に格納する。
【０１０４】
サーバアプリケーション８は、共通受信データ格納部１２１に格納された受信データに基づいて処理を実行する。
【０１０５】
サーバアプリケーション８の処理が正常に実行された場合、サーバアプリケーション８は、共通返信データ格納部１２２を生成し、この共通返信データ格納部１２２に共通形式の返信データを格納する。
【０１０６】
返信データ変換管理部１２２は、関係データ１３１Ａに基づいて、第１のクライアント実装技術に対応する返信データ変換部１３３Ａを生成する。
【０１０７】
返信データ変換部１３３Ａは、共通返信データ格納部１２２に格納されている共通形式の返信データを、第１のクライアント実装技術に対応するデータ形式の返信データに変換する。
【０１０８】
そして、サーバフレームワーク９は、サーバ側通信ライブラリ１０Ａを用いて、第１のクライアント実装技術に対応するデータ形式の返信データを、リクエストを発信したクライアントマシン２に送信する。
【０１０９】
一方、サーバアプリケーション８の処理が正常終了しなかった場合、サーバアプリケーション８は、共通例外データ格納部１２３を生成し、この共通例外データ格納部１２３に共通形式の例外データを格納する。
【０１１０】
例外データ変換管理部１７３は、関係データ１３１Ａに基づいて、第１のクライアント実装技術に対応する例外データ変換部１３４Ａを生成する。
【０１１１】
例外データ変換部１３４Ａは、共通例外データ格納部１２３に格納されている共通形式の例外データを、第１のクライアント実装技術に対応するデータ形式の例外データに変換する。
【０１１２】
そして、サーバフレームワーク９は、サーバ側通信ライブラリ１０Ａを用いて、第１のクライアント実装技術に対応するデータ形式の例外データを、クライアントマシン２に送信する。
【０１１３】
図２は、本実施の形態において、クライアント実装技術識別子とデータ形式情報とが付加されたリクエストが、クライアントフレームワーク５Ａによって生成される状態の一例を示す図である。
【０１１４】
この図２は、クライアント実装技術がAjaxの場合を例として図示しているが、他のクライアント実装技術であってもよい。
【０１１５】
例えば、クライアントアプリケーション４Ａは、文字列データ「○○会社」、リストデータ[ＡＡＡ部品，ＢＢＢ部品，ＣＣＣ部品]、項目[コード，商品名，在庫数]に関する表データ[Ａ００１，ＸＸＸテレビ，１００]，[Ａ００２，ＹＹＹテレビ，２００]を含むリクエストを、サーバマシン３に送信するとする。
【０１１６】
この場合、まず、クライアントフレームワーク５Ａは、クライアントアプリケーション４Ａから送信対象のデータ１９を取得する。
【０１１７】
次に、クライアントフレームワーク５Ａは、この送信対象のデータ１９に対して、クライアント実装技術「Ajax」に対応するクライアント実装技術識別子「ajax」を付加し、さらに、送信対象のデータ１９に対して、文字列を表すデータ形式情報「String」を文字列データ「○○会社」に付加し、リストを表すデータ形式情報「List」をリストデータ[ＡＡＡ部品，ＢＢＢ部品，ＣＣＣ部品]に付加し、表であることを示すデータ形式情報「table」を表データ[Ａ００１，ＸＸＸテレビ，１００]，[Ａ００２，ＹＹＹテレビ，２００]に付加し、リクエスト２０を生成する。
【０１１８】
クライアントフレームワーク５Ａによって、送信対象データ１９に対してクライアント実装技術識別子「ajax」とデータ形式情報「String」「List」「table」とが付加されたリクエスト２０は、サーバマシン３へ送信される。
【０１１９】
図３は、関係データ１３１Ａ，１３１Ｂ，１３１Ｃを記憶する記憶装置１１の一例を示す図である。この図３については、クライアント実装技術「Ajax」に対応する関係データ１３１Ａについて説明するが、他のクライアント実装技術に対応する関係データ１３１Ｂ，１３１Ｃも同様の特徴を持つ。
【０１２０】
関係データ１３１Ａのファイル名には、第１のクライアント実装技術「Ajax」のクライアント実装技術識別子「ajax」が含まれる。そして、この関係データ１３１Ａは、このクライアント実装技術識別子「ajax」を含むリクエストに対して適用されるべき受信データ変換部１３２Ａ「AjaxRequestConverter」、返信データ変換部１３３Ａ「AjaxResponseConverter」、例外データ変換部１３４Ａ「AjaxExceptionConverter」を特定している。
【０１２１】
受信データ変換管理部１７１は、リクエストに含まれていたクライアント実装技術識別子「ajax」をファイル名に含む関係データ１３１Ａを検索し、検索された関係データ１３１Ａで特定されている受信データ変換部１３２Ａを認識する。
【０１２２】
返信データ変換管理部１７２は、返信先のクライアントアプリケーション４Ａのクライアント実装技術識別子「ajax」をファイル名に含む関係データ１３１Ａを検索し、検索された関係データ１３１Ａで特定されている送信データ変換部１３３Ａを認識する。
【０１２３】
例外データ変換管理部１７３は、返信先のクライアントアプリケーション４Ａに対応するクライアント実装技術識別子「ajax」をファイル名に含む関係データ１３１Ａを検索し、検索された関係データ１３１Ａで特定されている例外データ変換部１３４Ａを認識する。
【０１２４】
図４は、本実施の形態に係るサーバフレームワーク９による受信データの変換の一例を示す図である。
【０１２５】
サーバ側通信ライブラリ１０Ａは、例えば、上記図２に示すような、クライアント実装技術識別子「ajax」とデータ形式情報「String」「List」「table」とが付加されたリクエスト２０（受信データ）を受信する。
【０１２６】
次に、サーバ側通信ライブラリ１０Ａは、リクエスト２０を、対応する例えばJavaの形式のデータ２１に変換する。サーバ側通信ライブラリ１０Ａは、リクエスト２０の内容を、そのまま対応するJavaのデータ形式にマッピングする。
【０１２７】
そして、サーバフレームワーク９の受信データ変換部１３２Ａは、リクエスト２０からJava形式に変換されたデータ２１を、Javaのサーバアプリケーション８で扱いやすい共通形式のデータ２２に変換する。
【０１２８】
図５は、クライアント実装技術「Ajax」に対応する通信ライブラリ１０ＡとしてDWRを用いた場合に、サーバ側で利用可能なデータの形式の一例を示す図である。
【０１２９】
DWRを利用したAjaxでは、リスト、表などのような複雑なデータを、JavaのList型、Map型を使用して、送受信することができる。
【０１３０】
図６は、クライアント実装技術「Windowsアプリケーション」に対応する通信ライブラリ１０ＢとしてApach Axisを用いた場合に、サーバ側で利用可能なデータの形式の一例を示す図である。
【０１３１】
Apach Axis を利用したWindowsアプリケーションにおいても、リスト、表などのような複雑なデータを、JavaのList型、Map型を使用して、送受信することができる。
【０１３２】
以下に、情報処理システム１の動作について説明する。
【０１３３】
図７は、本実施の形態に係るクライアントマシン２におけるリクエスト送信処理の一例を示すシーケンス図である。
【０１３４】
この図７は、クライアントマシン２からサーバマシン３へデータが送信されるまでの処理を示している。
【０１３５】
クライアントアプリケーション４Ａは、クライアントフレームワーク５Ａに対して、リクエスト送信処理（Ｓ１）を依頼する。
【０１３６】
クライアントフレームワーク５Ａは、リクエストに対してクライアント実装技術を特定する識別子を付加する（Ｓ２）。
【０１３７】
クライアントフレームワーク５Ａは、サーバマシン３に送信するデータ１９を例えば画面から取得する（Ｓ３）。
【０１３８】
クライアントフレームワーク５Ａは、送信対象データ１９に含まれるそれぞれのデータに対して、データ形式情報を付加する（Ｓ４）。
【０１３９】
クライアントフレームワーク５Ａは、クライアント実装技術識別子、送信対象データ１９、データ形式情報をまとめたリクエスト２０を、クライアント側通信ライブラリ６Ａを利用してサーバマシン３に送信するためのクライアント送信処理（Ｓ５）を実行する。
【０１４０】
クライアントマシン２とサーバマシン３との間では、クライアント実装技術に対応するクライアント側通信ライブラリ６Ａとサーバ側通信ライブラリ１０Ａとを用いて、ネットワークを経由したリクエスト２０の通信（Ｓ６）が行われる。
【０１４１】
図８は、本実施の形態に係るサーバマシン３によってリクエストが受信・変換される処理の一例を示すシーケンス図である。
【０１４２】
サーバ側通信ライブラリ１０Ａは、受信したリクエストに対する処理を共通リクエスト処理部に委譲する（Ｔ１）。
【０１４３】
共通リクエスト処理部１５は、クライアント特定部１６に対して、リクエストを送信したクライアント実装技術を特定するクライアント実装技術識別子の取得を依頼する（Ｔ２）。
【０１４４】
クライアント特定部１６は、リクエストに付加されたクライアント実装技術識別子を、リクエストから抽出し（Ｔ３）、クライアント実装技術識別子を共通リクエスト処理部１５に返す。
【０１４５】
共通リクエスト処理部１５は、リクエストに含まれている受信データとクライアント実装技術識別子とを、受信データ変換管理部１７１に渡し、受信データ変換処理を依頼する（Ｔ４）。
【０１４６】
受信データ変換管理部１７１は、クライアント実装技術識別子をキーワードとして、参照可能なパス上から関係データ（クライアント技術対応定義部）１３１Ａを検索する（Ｔ５）。
【０１４７】
受信データ変換管理部１７１は、検索された関係データ１３１Ａにおいて特定されている受信データ変換部１３２Ａの名称を取得する（Ｔ６）。
【０１４８】
受信データ変換管理部１７１は、取得した受信データ変換部１３２Ａの名称に基づいて受信データ変換部１３２Ａを生成する。例えば、受信データ変換部１３２Ａの名称に基づいて、受信データ変換オブジェクトが生成される（Ｔ７）。
【０１４９】
受信データ変換管理部１７１は、受信データ変換インタフェース１８１へ受信データ変換を依頼する（Ｔ８）。
【０１５０】
受信データ変換インタフェース１８１は、受信データ変換部１３２Ａへ受信データ変換を依頼する（Ｔ９）。
【０１５１】
受信データ変換部１３２Ａは、受信データを取得し、この受信データをクライアント実装技術に依存しない共通形式のデータに変換する。データ変換の際に、受信データ変換部１３２Ａは、クライアントフレームワーク５Ａによって付加されたデータ形式情報を参照する（Ｔ１０）。
【０１５２】
受信データ変換部１３２Ａは、データ形式を変換した受信データを格納する入れ物として、共通受信データ格納部１２１を生成する（Ｔ１１）。
【０１５３】
受信データ変換部１３２Ａは、共通受信データ格納部１２１に、データ形式を変換した受信データを格納する（Ｔ１２）。
【０１５４】
共通リクエスト処理部１５は、共通受信データ格納部１２１をサーバアプリケーション８に渡して、サーバアプリケーション８を実行させる（Ｔ１３）。
【０１５５】
サーバアプリケーション８は、共通受信データ格納部１２１から受信データを取得する（Ｔ１４）。
【０１５６】
サーバアプリケーション８は、エンタープライズシステムの業務処理を実行する（Ｔ１５）。
【０１５７】
図９は、本実施の形態に係るサーバマシン３からクライアントマシン２に返信される返信データに対する処理（レスポンス処理）の一例を示すシーケンス図である。
【０１５８】
サーバアプリケーション８は、エンタープライズシステムの業務処理を実行する（Ｕ１）。
【０１５９】
サーバアプリケーション８は、業務処理の結果を格納する共通返信データ格納部１２２を生成する（Ｕ２）。
【０１６０】
サーバアプリケーション８は、共通返信データ格納部１２２に、業務処理の結果を格納する（Ｕ３）。
【０１６１】
サーバアプリケーション８の処理結果が格納された共通返信データ格納部１２２は、サーバアプリケーション８から共通リクエスト処理部１５に渡される（Ｕ４）。
【０１６２】
共通リクエスト処理部１５は、クライアント特定部１６に対して、クライアント実装技術識別子の取得を依頼する（Ｕ５）。クライアント特定部１６は、受信されたリクエストに付加されていたクライアント実装技術識別子を、共通リクエスト処理部１５に返す。
【０１６３】
共通リクエスト処理部１５は、共通返信データ格納部１２２とクライアント実装技術識別子とを、返信データ変換管理部１７２に渡し、返信データ変換処理を依頼する（Ｕ６）。
【０１６４】
返信データ変換管理部１７２は、クライアント実装技術識別子を検索のキーワードとして用いて、参照可能なパス上から、関係データ（クライアント技術対応定義部）１３１Ａを検索する（Ｕ７）。
【０１６５】
返信データ変換管理部１７２は、関係データ１３１Ａにおいて定義されている返信データ変換部１３３Ａの名称を取得する（Ｕ８）。
【０１６６】
返信データ変換管理部１７２は、取得された名称の返信データ変換部１３３Ａを生成する（Ｕ９）。
【０１６７】
返信データ変換管理部１７２は、返信データの変換を依頼するために、返信データ変換インタフェース１８２に、共通返信データ格納部１２２を渡す（Ｕ１０）。
【０１６８】
返信データ変換インタフェース１８２は、返信データ変換部１３３Ａに共通返信データ格納部１２２を渡し（Ｕ１１）、返信データ変換部１３３Ａに返信データ変換を依頼する。
【０１６９】
返信データ変換部１３３Ａは、共通返信データ格納部１２２から、変換対象の返信データを取得する（Ｕ１２）。
【０１７０】
返信データ変換部１３３Ａは、返信データを、リクエストを発信したクライアント実装技術に返信可能な形式に変換する（Ｕ１３）。
【０１７１】
返信可能な形式に変換された返信データは、返信データ変換部１３３Ａから、返信データ変換インタフェース１８２、返信データ変換管理部１７２経由で、共通リクエスト処理部１５に返却され、さらに、共通リクエスト処理部１５からサーバ側通信ライブラリ１０Ａに渡される（Ｕ１４）。
【０１７２】
サーバ側の通信ライブラリ１０Ａは、返信先のクライアント実装技術に対応するクライアント側通信ライブラリ６Ａに、返信データを返却する（Ｕ１５）。
【０１７３】
図１０は、本実施の形態に係るサーバマシン３からクライアントマシン２に送信される例外データに対する処理の一例を示すシーケンス図である。
【０１７４】
サーバアプリケーション８は、エンタープライズシステムの業務処理を実行する。ここで、例外イベントが発生する（Ｖ１）
サーバアプリケーション８は、例外データが格納された共通例外データ格納部１２３を生成する（Ｖ２）。
【０１７５】
共通例外データ格納部１２３は、サーバアプリケーション８から共通リクエスト処理部１５に渡される（Ｖ３）。
【０１７６】
共通例外データ格納部１２３を受け取った共通リクエスト処理部１５は、例外データに対する処理を開始する。共通例外データ格納部１２３は、例えばJavaの例外クラスが該当する。
【０１７７】
共通リクエスト処理部１５は、クライアント特定部１６に対して、クライアント実装技術識別子の取得を依頼する（Ｖ４）。クライアント特定部１６は、受信されたリクエストに付加されていたクライアント実装技術識別子を、共通リクエスト処理部１５に返す。
【０１７８】
共通リクエスト処理部１５は、共通例外データ格納部１２３とクライアント実装技術識別子とを、例外データ変換管理部１７３に渡し、例外データ変換処理を依頼する（Ｖ５）。
【０１７９】
例外データ変換管理部１７３は、クライアント実装技術識別子を検索のキーワードとして用いて、参照可能なパス上から関係データ（クライアント技術対応定義部）１３１Ａを検索する（Ｖ６）。
【０１８０】
例外データ変換管理部１７３は、関係データ１３１Ａにおいて定義されている例外データ変換部１３４Ａの名称を取得する（Ｖ７）。
【０１８１】
例外データ変換管理部１７３は、取得された名称の例外データ変換部１３４Ａを生成する（Ｖ８）。
【０１８２】
例外データ変換管理部１７３は、例外データの変換を依頼するために、例外データ変換インタフェース１８３に、共通例外データ格納部１２３を渡す（Ｖ９）。
【０１８３】
例外データ変換インタフェース１８３は、例外データ変換部１３４Ａに共通例外データ格納部１２３を渡し（Ｖ１０）、例外データ変換部１３４Ａに例外データの変換を依頼する。
【０１８４】
例外データ変換部１３４Ａは、変換対象の例外データを、共通例外データ格納部１２３から取得する（Ｖ１１）。
【０１８５】
例外データ変換部１３４Ａは、例外データを、例外返信先のクライアント実装技術で取り扱い可能な形式に変換する（Ｖ１２）。リクエストを発信したクライアント実装技術で取り扱い可能な例外データには、例えば、例外クラス名、例外メッセージ、例外のスタックトレース情報が含まれる。
【０１８６】
リクエストを発信したクライアント実装技術で取り扱い可能な形式に変換された例外データは、例外データ変換部１３４Ａから、例外データ変換インタフェース１８３、例外データ変換管理部１７３経由で、共通リクエスト処理部１５に返却され、さらに、共通リクエスト処理部１５からサーバ側通信ライブラリ１０Ａに渡される（Ｕ１３）。
【０１８７】
サーバ側の通信ライブラリ１０Ａは、リクエストを発信したクライアント実装技術に対応するクライアント側通信ライブラリ６Ａに、例外データを返却する（Ｕ１４）。
【０１８８】
以下に、サーバマシン３における従来のソフトウェア構成と本実施の形態に係るソフトウェア構成との相違点について説明する。
【０１８９】
図１１は、従来のサーバマシン３側のソフトウェア構成の一例を示すブロック図である。
【０１９０】
従来のサーバマシン３側においては、オペレーティングシステム２３、ミドルウェア２４、第１のクライアント実装技術「Ajax」に対応するアプリケーション８Ａ、第２のクライアント実装技術「Windowsアプリケーション」に対応するアプリケーション８Ｂが動作する。
【０１９１】
この図１１に示すように、従来においては、複数のクライアント実装技術「Ajax」「Windowsアプリケーション」に対してたとえ同じ業務処理を実行させる場合であっても、クライアント実装技術「Ajax」「Windowsアプリケーション」ごとにアプリケーション８Ａ，８Ｂを備える必要がある。
【０１９２】
図１２は、本実施の形態に係るサーバマシン３側のソフトウェア構成の一例を示すブロック図である。
【０１９３】
サーバマシン３側では、オペレーティングシステム２３、ミドルウェア２４、サーバフレームワーク９、サーバアプリケーション８が動作する。
【０１９４】
本実施の形態においては、第１のクライアント実装技術「Ajax」から送信されたリクエスト、第２のクライアント実装技術「Windowsアプリケーション」から送信されたリクエストは、まずサーバフレームワーク９で処理される。
【０１９５】
サーバフレームワーク９は、受信されたリクエストを共通形式のデータに変換し、サーバアプリケーション８に渡す。
【０１９６】
さらに、本実施の形態において、サーバフレームワーク９は、サーバアプリケーション８から共通形式の返信データ又は例外データを受け付け、この共通形式の返信データ又は例外データを返信先のクライアント実装技術に対応した形式に変換し、変換後のデータを返信先のクライアント実装技術に返す。
【０１９７】
このように、本実施の形態に係るサーバフレームワーク９は、クライアント実装技術の相違を柔軟に吸収する。
【０１９８】
図１３は、本実施の形態に係るサーバマシン３のハードウェア構成の一例を示すブロック図である。なお、クライアントマシン２のハードウェア構成についても、この図１３のサーバマシン３と同様の構成を用いることができる。
【０１９９】
サーバマシン３は、情報処理装置であり、例えば、少なくとも一つのプロセッサ２５、記憶装置１１、バス２６、通信装置２７を備えている。
【０２００】
通信装置２７は、クライアントマシン２からのリクエストその他各種のデータを受信し、記憶装置１１に記憶する。
【０２０１】
プロセッサ２５は、記憶装置１１に記憶されている各種のプログラム（例えば、オペレーティングシステム２３、ミドルウェア２４、サーバフレームワーク９、サーバアプリケーション８）とリクエスト又はデータに基づいて各種の処理を実行し、実行結果データを記憶装置１１に記憶する。
【０２０２】
通信装置１１は、クライアントマシン２に、記憶装置１１に記憶されている実行結果データを送信する。
【０２０３】
記憶装置１１は、例えば、キャッシュメモリ、主記憶装置、２次記憶装置などを含む。
【０２０４】
なお、クライアントマシン２とサーバマシン３とのうちの少なくとも一方は、複数の情報処理装置が連携して動作することにより実現されるとしてもよい。
【０２０５】
以上説明した本実施の形態においては、クライアント実装技術に依存しないサーバアプリケーション８を用いることができる。本実施の形態においては、業務処理の核となる処理を行うサーバアプリケーション８を一つ生成するのみで、様々なクライアント実装技術に対応させることができる。
【０２０６】
本実施の形態においては、異なる複数のクライアント実装技術に対して共通のサーバアプリケーション８を開発すればよいため、RIAの開発工程及び開発労力を削減することができる。
【０２０７】
本実施の形態に係る情報処理システム１におけるアプリケーション開発においては、リッチクライアント技術の学習工程を削減させることができ、リッチクライアント技術の追加又は変更に対する開発工程を削減させることができる。
【０２０８】
例えば、新たなリッチクライアント技術を採用する場合に、そのリッチクライアント技術を使ったサーバアプリケーション８の開発方法を開発者が新たに学習する必要はなく、開発労力及び時間を削減することができる。
【０２０９】
例えば、クライアントマシン２側で採用されるリッチクライアント技術が異なる場合であってもサーバマシン３側を別々に開発する必要がなく、開発労力及び時間を削減することができる。
【０２１０】
例えば、あるリッチクライアント技術によって開発されたRIAに対して、さらにクライアント実装技術のバリエーションを追加しても、サーバアプリケーション８を作り直す必要がなく、開発労力及び時間を削減することができる。
【０２１１】
本実施の形態に係る情報処理システム１におけるソフトウェア開発においては、適用可能なクライアント実装技術（リッチクライアント技術）を増やす場合に、その追加されるクライアント実装技術に対応する受信データ変換部、返信データ変換部、例外データ変換部、関係データのセットを備えればよく、サーバアプリケーション８を変更・追加する必要はない。これにより、サーバフレームワーク９の拡張性、保守性を向上させることができる。
【０２１２】
（第２の実施の形態）
本実施の形態に係る情報処理システムにおいては、クライアントとサーバとの間で通信されるリクエストを一意に特定するための情報（例えばトークン）を管理する。
【０２１３】
図１４は、本実施の形態に係る情報処理システムの一例を示すブロック図である。この図１４では、トークンの管理の説明に必要な構成要素のみを図示しており、他の構成要素については省略している。
【０２１４】
本実施の形態に係る情報処理システム２８では、少なくとも一つのクライアントマシンから一つのサーバマシン３０へ複数のリクエストが送信され、サーバマシン３０によって複数のリクエストが処理される。
【０２１５】
なお、この図１４では、複数のクライアントマシン２９１〜２９ｎからサーバマシン３０に複数のリクエストが発信されているが、一つのクライアントマシンからサーバマシン３０に複数のリクエストが発信される場合についても同様である。
【０２１６】
クライアントマシン２９１〜２９ｎとサーバマシン３０とのうちの少なくとも一方は、複数の情報処理装置が連携して動作することにより実現されるとしてもよい。
【０２１７】
クライアントフレームワーク３１１〜３１ｎは、主に、リクエストの送信前及びリクエストに対する返信データ又は例外データの受信後に動作する。このクライアントフレームワーク３１１〜３１ｎは、クライアントとサーバとの間の通信（リクエスト）を一意に特定するトークンとログ情報とを関係付けて記憶装置３２１〜３２ｎに記憶する。
【０２１８】
サーバフレームワーク３３及びサーバアプリケーション３４は、上記第１の実施の形態に係るサーバフレームワーク９及びサーバアプリケーション８と同様の機能を具備し、リクエストを解析し、返信データ（レスポンス）を生成する。
【０２１９】
サーバフレームワーク３３及びサーバアプリケーション３４は、さらに、リクエストに付加されたトークンとログ情報とを関係付けて記憶装置１１に記憶する。
【０２２０】
このように、本実施の形態においては、クライアントフレームワーク３１１〜３１ｎとサーバフレームワーク３３との間で送受信されるリクエスト及びデータに、このリクエスト及びデータに対する処理を追跡可能とするための情報が付加される。
【０２２１】
これにより、アプリケーション開発時及びアプリケーション運用時において問題が発生した場合に、クライアントマシン２９１〜２９ｎに記憶されているログ情報とサーバマシン３０に記憶されているログ情報とをつき合わせえて処理を特定し、発生した問題の解析を行うことができ、解析効率を向上させることができる。
【０２２２】
上記各実施の形態において説明した各構成要素は、自由に組み合わせることができ、自由に分割することができる。例えば、本実施の形態に係る記憶装置１１は、複数の記憶装置に分割し、各種のリクエスト及び処理結果などのデータは、複数の記憶装置のいずれかに記憶されるとしてもよい。各処理部の間のデータのやり取りは、記憶装置を介して行われるとしてもよい。
【０２２３】
本発明は、上記実施の形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で、種々に変形することが可能である。さらに、上記実施の形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【産業上の利用可能性】
【０２２４】
本発明は、クライアントマシンからサーバマシンにリクエスト又はデータを送信し、サーバマシンにおいてこのリクエスト又はデータに基づいて処理を実行する情報処理システムの技術分野に有効である。
【符号の説明】
【０２２５】
１，２８…情報処理システム、２，２９１〜２９ｎ…クライアントマシン、３，３０…サーバマシン、４Ａ，４Ｂ…クライアントアプリケーション、５Ａ，５Ｂ，３１１〜３１ｎ…クライアントフレームワーク、６Ａ，６Ｂ…クライアント側通信ライブラリ、７，１１，３２１〜３２ｎ…記憶装置、８，３４…サーバアプリケーション、９，３３…サーバフレームワーク、１０Ａ，１０Ｂ…サーバ側通信ライブラリ、１２１…共通受信データ格納部、１２２…共通返信データ格納部、１２３…共通例外データ格納部、１３１Ａ，１３１Ｂ…関係データ、１３２Ａ，１３２Ｂ…受信データ変換部、１３３Ａ，１３３Ｂ…返信データ変換部、１３４Ａ，１３４Ｂ…例外データ変換部、１４Ａ…第１の変換部、１４Ｂ…第２の変換部、１５…共通リクエスト処理部、１６…クライアント特定部、１７１…受信データ変換管理部、１７２…返信データ変換管理部、１７３…例外データ変換管理部、１８１…受信データ変換インタフェース、１８２…返信データ変換インタフェース、１８３…例外データ変換インタフェース、２０…リクエスト、２２…共通形式のデータ。
【図１】
2011096112.tif 000003
【図２】
2011096112.tif 000004
【図３】
2011096112.tif 000005
【図４】
2011096112.tif 000006
【図５】
2011096112.tif 000007
【図６】
2011096112.tif 000008
【図７】
2011096112.tif 000009
【図８】
2011096112.tif 000010
【図９】
2011096112.tif 000011
【図１０】
2011096112.tif 000012
【図１１】
2011096112.tif 000013
【図１２】
2011096112.tif 000014
【図１３】
2011096112.tif 000015
【図１４】
2011096112.tif 000016