JP2006053832A - フレームワーク間連携プログラム及び方法 - Google Patents

Abstract

【課題】ビジネスロジックを構築する第１アプリケーションフレームワークとＷｅｂ画面の遷移を定義する第２アプリケーションフレームワークとの間でのスムーズな連携を可能にする。
【解決手段】２つのフレームワークを連携して機能させるために第１コンピュータに、第１のフレームワークが第１データ用フィールドに対して用いる第１識別名と、第２のフレームワークが第１識別名に対応して用いる第２識別名との対応関係を示す第１対応表を第１コンピュータの記憶手段に記憶させ（Ｓ１２）、第２のフレームワークが第１ファイルをＷｅｂブラウザで閲覧可能な第２ファイルに変換する際に第２識別名に対応して用いる第３識別名と、第１識別名との対応関係を示す第２対応表を第１コンピュータの記憶手段に記憶させ（Ｓ１３）、第１のフレームワークが提供する機能と、第２対応表とを第２ファイルとともに、第１コンピュータの送信手段に送信させる（Ｓ１４〜１６）。
【選択図】 図３

Description

本発明は、第１フレームワークと第２フレームワークとの間でのスムーズな連携を可能にするプログラム及び方法に関する。

例えば、JSF（JavaServer Facesの略）とオブジェクトワークス（登録商標）という２つのアプリケーションフレームワークが存在する。

JSFとは、ビジネスロジックとプレゼンテーションデザインの分離を目的とした、Webアプリケーションのインターフェースのためのフレームワークである。従来のJSPでは、Webアプリケーションのインターフェースとインターフェース処理のロジックが同じレベルで記述され、ビジネスロジックとプレゼンテーションデザインを完全に分離するには至っていなかった点を改善している。

また、オブジェクトワークスは、株式会社野村総合研究所が提供するフレームワークであって、バックエンド接続、サーバサイドの機能が充実しており、大規模開発に向いている（例えば、特許文献１参照）。

このような異なる特徴を有する２以上のフレームワークをうまく連携させて使用することができれば、ソフトウェアシステムを効率よく開発することができる。

なお、フレームワークとは、複数のソフトウェアが複合して構成するある程度大規模なソフトウェアシステムを意味するものとする。
特開２００２−２８７９６２号公報

第１フレームワークと第２フレームワークという異なるフレームワークが存在する場合、第１フレームワークと第２フレームワークとでは、データフィールドを特定するための識別子に関して、異なるルールを持っている場合がある。このため、第１フレームワークで使用している識別子が、第２フレームワークでは使用できないことがある。

例えば、オブジェクトワークスというフレームワークとJSFというフレームワークが存在する。そして、オブジェクトワークスにおいては同一のDSB nameを複数使用することが可能であるが、JSFにおいては同一のidを複数使用することはできない。ここで、”DSB”とは、データ・ストア・ビーン(data store bean)を意味する。

例えば、オブジェクトワークスにおいては、自宅の電話番号、携帯電話の電話番号及び勤務先の電話番号という３種類の電話番号の全てに対して"tel_no"という共通のDSB nameを使用することができる。一方、JSFにおいては、３種類の電話番号の全てに対して同一のidを使用することはできないので、３種類の電話番号の各々に対して"tel_no_0", "tel_no_1", "tel_no_2"というような異なるidを使用しなければならない。

また、第１パーソナルコンピュータ（ＰＣ）と第２ＰＣとの間で所定のプロトコルに従って通信する場合に、送信側で使用される識別子と受信側で使用される識別子とが同一ではない場合もある。

例えば、サーバサイドからクライアントサイドへ送信するために、JSFタグライブラリを用いて記述されたJSPファイルをHTMLファイルへ変換した場合、JSPファイルで使用されている"id"とHTMLファイルで使用されている"name"とは、似て非なるものとなる。

例えば、JSPファイル中の
"id = kaiin_name"
という記述に基づいて、JSPファイルを変換して得られるHTMLファイル中では
"name = form1:kaiin_name"
という記述が生成される。このとき、"kaiin_name"の前に"form1:"が付加されている。

そして、第１フレームワークが単独で使用される場合は、サーバサイドに存在する第１フレームワークが提供する機能が、クライアントサイドに送信されて、クライアントサイドで有効に働くにもかかわらず、前記の如く、第１フレームワークと第２フレームワークとを連携させて使用するために、オブジェクトワークスでのDSB nameとJSPでのidとHTMLでのnameとが一致しないので、第１フレームワークが提供する機能が、クライアントサイドで有効に働かないということが生じうる。

例えば、第１フレームワークが提供するデータ型チェック機能がサーバサイドからクライアントサードへ送信され、クライアントサイドで入力されたデータのデータ型等がクライアントサイドでチェックされる場合に、前記のようにオブジェクトワークスでのDSB nameとHTMLでのnameとが一致しないことに起因してデータ型チェック機能が、有効に働かないということが生じうる。

そこで、本発明は、サーバサイドに存在する第１アプリケーションフレームワークによって提供される機能であって、クライアントサイドにおいて実行される機能が、クライアントサイドにおいて有効に働くことを可能とするプログラム及び方法を提供することを目的とする。

本発明の第１の特徴は、フレームワーク間連携のために、主としてビジネスロジックを構築する第１アプリケーションフレームワークと、主としてＷｅｂ画面の遷移を定義する第２アプリケーションフレームワークとを連携して機能させるために第１コンピュータに、（１）第１アプリケーションフレームワークが第１データ用フィールドに対して用いる第１識別名と、第２アプリケーションフレームワークが第１識別名に対応して用いる第２識別名との対応関係を示す第１対応表を第１コンピュータの記憶手段に記憶させる手順、（２）第２アプリケーションフレームワークが第１ファイルをＷｅｂブラウザで閲覧可能な第２ファイルに変換する際に第２識別名に対応して用いる第３識別名と、第１識別名との対応関係を示す第２対応表を第１コンピュータの記憶手段に記憶させる手順、（３）第１アプリケーションフレームワークが提供する機能と、第２対応表とを第２ファイルとともに、第１コンピュータの送信手段に送信させる手順を実行させることにある。

また、本発明の第２の特徴は、（１）第３識別名に対応付けられたデータを、第１コンピュータの受信手段に受信させる手順、（２）第２対応表を用いて、第３識別名に対応付けられたデータを、第２識別名に対応付けて第１コンピュータの記憶手段に記憶させる手順、（３）第１対応表を用いて、第２識別名に対応付けられたデータを、第１識別名に対応付けて第１コンピュータの記憶手段に記憶させる手順を、さらに実行させることにある。

さらに、第２アプリケーションフレームワークがJavaServer Facesであり、第１コンピュータがクライアント・サーバ・システムにおけるサーバであり、第１識別名がData Store Beanのnameであり、第２識別名がJavaServer Pagesのidであり、第３識別名がHTMLのnameであり、第１ファイルがJavaServer Pagesファイルであり、第２ファイルがHTMLファイルであることが好ましい。

本発明の第１の特徴によれば、第１アプリケーションフレームワーク用の第１識別名と、第２アプリケーションフレームワークによるファイル変換によって第２識別名から変換された第３識別名との対応関係が、第２対応表から明らかであるから、送信先において第３識別名に対応するデータとして入力されたデータを、第１アプリケーションフレームワークが処理可能な第１識別名に対応するデータとして認識することができる。これによって、送信先においても、第１アプリケーションフレームワークが提供する機能を有効に利用することができる。

また、本発明の第２の特徴によれば、送信先において第３識別名に対応するデータとして入力されたデータを、第２対応表に基づいて、第１アプリケーションフレームワークが処理可能な第１識別名に対応するデータとして認識することができる。これによって、第１コンピュータにおいても、第３識別名に対応するデータを適切に処理することが可能となる。

以下に図面に基づいて、本発明を実施するための最良の形態を説明する。なお、以下の説明は、単なる例示に過ぎず、本発明の技術的範囲は以下の説明に限定されるものではない。

図１は、実施例１におけるサーバの構成を示すブロック図である。同図に示すように、サーバ３０は、中央処理装置（ＣＰＵ）３１と、メモリ３２と、送受信装置３３と、ファイル装置３５ａ，３５ｂとを備え、それら各装置がバス３７を介してデータをやり取りすることができる。

送受信装置３３には、ネットワークインターフェースカード(NIC)が含まれる。この送受信装置３３を用いてリクエストメッセージの受信、レスポンスメッセージの送信などを行う。

ファイル装置３５には、ハードディスクドライブが含まれる。図１に示すように、ファイル装置３５ａには、第１フレームワーク３５１、第２フレームワーク３５２、JSPファイル３５３、JSPエンジン３５４、サーブレットエンジン３５５、メッセージ送受信プログラム３５６及びデータ定義３５７が記憶されている。また、ファイル装置３５ｂには、連携プログラム３５８、Server Id・DSB対応表３５９が記憶されている。

図１に示すように、連携プログラム３５８は、UIコンポーネントツリーを走査するUIコンポーネントツリー走査部３６１と、HTMLのnameとDSB nameとの対応表を作成するHTML・DSB対応表作成部３６２と、かかる対応表をHTMLファイルに埋め込む対応表埋込部３６３とを備える。これら各部については後述する。

なお、後述するように、例えば、第１フレームワークとはオブジェクトワークスであり、第２フレームワークとはJSFである。

なお、ファイル装置３５ａにフレームワーク等が、ファイル装置３５ｂに連携プログラム等が記憶されているとしたが、これは説明の都合上そのようにしただけである。ファイル装置３５ａのフレームワーク等の一部が、ファイル装置３５ｂに記憶されていても良い。また、ファイル装置３５ｂの連携プログラム等の一部が、ファイル装置３５ａに記憶されていても良い。さらに、ファイル装置３５ａのフレームワーク等の全てと、ファイル装置３５ｂの連携プログラム等の全てとが物理的に一つのファイル装置に記憶されていても良い。メインメモリ３２は、連携プログラムのワークエリアとして使用される。

図２は、実施例１におけるデータストア定義（アプリケーションのデータ定義）の内容を示す。同図に示すように、”kaiin_no”, ”kaiin_name”, ”kaiin_addr”, ”birth_day”, ”tel_no”などのDSBカラム名やそれぞれのデータ型、日本語名、必須か否かなどが定義されている。

図３は、実施例１における全体的な処理の流れを示すフローチャートである。ステップＳ１１からステップＳ１６はサーバサイドにおける処理、ステップＳ２１からステップＳ２３はクライアントサイドにおける処理、ステップＳ３１からステップＳ３８はサーバサイドにおける処理を示す。図３に示すように、
ステップＳ１１で、開発者が作成したJSPがコンパイルされServletとして実行され始める、
ステップＳ１２で、JSFタグのidとオブジェクトワークスのDSBカラム名とに関する第１テーブルが作成され、
ステップＳ１３で、JSFによって変換されたHTMLタグのnameとDSBカラム名とに関する第２テーブルが作成され、
ステップＳ１４で、第１テーブルをメモリに保存するか、もしくは画面にhidden項目として埋め込み、
ステップＳ１５で、第２テーブルがJavaScriptとして画面に埋め込まれ、
ステップＳ１６で、レスポンスメッセージがクライアントサイドに送られ、
ステップＳ２１で、アプリケーション利用者がクライアントサイドで入力を行い、
ステップＳ２２で、クライアント側入力チェックが行われ、この際、JavaScriptとして埋め込まれた第２テーブルを用いてnameがDSBカラム名に変換され、
ステップＳ２３で、アプリケーション利用者がリクエストメッセージを送信し、
ステップＳ３１で、サーバがリクエストメッセージを受信し、
ステップＳ３２で、第１フレームワークであるオブジェクトワークスの処理がある程度進んだ時点で、オブジェクトワークスから第２フレームワークであるJSFに処理が委譲され、
ステップＳ３３で、JSFの処理によってリクエストデータと画面部品が結び付けられ、
ステップＳ３４で、JSFの処理が終了し、
ステップＳ３５で、オブジェクトワークスに処理を戻す際に第１テーブルを用いてDSBにデータがマッピングされ、
ステップＳ３６で、ビジネスロジック（ＢＬ）が実行され、
ステップＳ３７で、画面遷移が決定され、
ステップＳ３８で、次画面のJSPが読み込まれる。各ステップの詳細は、後述する。

（ア）クライアントサイドでの処理 ステップＳ１１〜Ｓ１６
＜JSPをHTMLに変換する処理の概要＞
図４にJSPファイルがHTMLファイルに変換される処理の流れを示す。JSPファイルからHTMLファイルへの変換は、JSPエンジン、サーブレットエンジンという、アプリケーションサーバの機能が行う。

図４に示すように、まずJSPファイル４１がJSPエンジンに読み込まれ、JSPエンジンによってサーブレット４３が中間生成物として作成される（ステップＳ４２）。JSPサーブレット４３は、サーブレットエンジンによって実行される（ステップＳ４４）。

また、JSPタグライブラリは、記述されたタグと対応付けたプログラムが動く仕組みになっている。例えば、JSPタグライブラリによって、タグＡに対して対応付けられたプログラムＡが動く。

JSPファイルの中に書かれたスクリプトや、JSPタグライブラリと関連付けられたクラスは、JSPサーブレットの一つの処理として実行される。そして、HTMLファイル４５が作成される。HTMLファイル４５はレスポンスメッセージとしてクライアントサイドに送信される。クライアントサイドで、HTMLファイル４５はWebブラウザによって解釈され、例えば図４に示すような登録画面４６がクライアントＰＣの表示手段の表示画面に表示される。

図４に示すように、登録画面４６は、氏名入力フィールド、住所入力フィールド、生年月日入力フィールド、及び電話番号入力用の第１、第２、第３のフィールド並びに「登録」ボタンから構成されている。次に、JSPサーブレットの実行のフェーズでどのように処理が行われるかの詳細を示す。

＜第１，第２のテーブル作成処理の詳細＞
JSPファイルがHTMLファイルに変換される過程において、後述するように、第１のテーブル及び第２のテーブルが作成される（第２フェーズ〜第５フェーズ）。

図５に実施例１におけるJSPファイルの一例を示す。同図に示すように、本実施例において用いるJSPファイル５０の構造は、オブジェクトワークスヘッダ部分５１とJSFタグ部分５２とオブジェクトワークスフッタ部分５４とを含む。ＪＳＦタグ部分５２内にオブジェクトワークスデータ埋め込み部分５３が存在する。

図６に実施例１におけるJSPファイルの一例とそれに対応するHTMLファイルの一例を示す。同図に示すように、JSPファイル５０は、JSPサーブレット６１を経て、ＨＴＭＬファイル６２に変換される。JSPファイル５０中のエリアＡ１１がＨＴＭＬファイル中のエリアＡ３１に対応し、JSPファイル中のエリアＡ１２がＨＴＭＬファイル中のエリアＡ３２に対応し、JSPファイル中のエリアＡ１３がＨＴＭＬファイル中のエリアＡ３３に対応し、ＪＳＰファイル中のエリアＡ１４がＨＴＭＬファイル中のエリアＡ３４に対応する。

＜オブジェクトワークスヘッダ部分について＞
図５に示すオブジェクトワークスヘッダ部分５１では、オブジェクトワークスのクライアントサイドの機能(入力チェック等)やオブジェクトワークスのデータを埋め込むように記述されたJSPファイルがインクルードされる。かかるインクルードによって、プログラムコードやJavaScriptが動的に埋め込まれる。図５の例では、COMMONHDR.jspがインクルードされる。

＜JSFタグ部分＞
図６に示す例では、<h:inputText...>などのJSFタグ部分（エリアＡ１３に対応）が<input type="text">などのHTMLタグ部分（エリアＡ３３に対応）に変換されていく。このような変換は、外部のJavaプログラムを呼び出して実行される（JSPタグライブラリの仕様）。そして、変換中に、各画面部品に対応する種類（例えば、テキストフィールド、ボタン、セレクトボックス）と状態（例えば、テキストが「入力されている／されていない」、ボタンが「押されている／押されていない」、セレクトボックスが「選択されている／選択されていない」）などを持つUIコンポーネントと呼ばれるオブジェクトが生成され、木構造のUIコンポーネントツリー（UI Component Tree）としてメモリ上に格納される。

図７に、実施例１におけるUIコンポーネントツリーの一例を示す。なお、同図はUIコンポーネントツリーの概要を示しているに過ぎない。また、同図には示していないが、各コンポーネントはHTMLとしてレスポンスメッセージが返された時にクライアントサイドで使用されるid属性及びname属性の各値が決定されていて、各コンポーネントが各属性値を保持している。

例えば、開発者が記述したJSPが、
氏名 <h:inputText id="kaiin_name" onBlur='blurEventHandler(this)' ><BR>
であるなら、
クライアントサイドに送られるHTMLは、
氏名 <input type="text" id="form1:kaiin_name" name="form1:kaiin_name"
onBlur='blurEventHandler(this)' ><BR>
となり、
”form1:kaiin_name”というid属性値とname属性値がメモリに保持される。

＜オブジェクトワークスのデータ埋め込み部分＞
オブジェクトワークスのデータ埋め込み部分には、次のリクエストメッセージに引き継ぎたい情報を埋め込む。例えば、DSBの値などが埋め込まれる。例えば、
kaiin_name=”野村太郎”
kaiin_age=”27”
が埋め込まれる。

＜オブジェクトワークスフッタ部分＞
前記の如く、メモリ上には既にクライアント側に送られるID("form1:kaiin_name"等)を保持したUIコンポーネントツリーが作成されている。オブジェクトワークスフッタ部分では、このUIコンポーネントツリーを走査することで、第１マッピングテーブル及び第２マッピングテーブルを作成する。

＜作成された木構造からマッピングテーブルを作成する＞
前記の如くJSFタグ部のHTML変換の際にJSFによって自動的に作成されたUIコンポーネントツリーの各コンポーネントを、JSPに記述したJavaプログラムによって、再帰的に順次たどり、メモリ上にテーブルを作成していく。

図８に、実施例１におけるUIコンポーネントツリーの各コンポーネントを再帰的に順次たどる様子を示す。同図に示す例では、まず第１コンポーネントｃ１を、次に第２コンポーネントｃ２を、次に第３コンポーネントｃ３を、次に第４コンポーネントｃ４を、次に第５コンポーネントｃ５を、次に第６コンポーネントｃ６を、次に第７コンポーネントｃ７を、次に第８コンポーネントｃ８を、次に第９コンポーネントｃ９を、順次たどる。

JSFが持つ関数を用いて各コンポーネントを再帰的に順次たどることができる。具体的には、
（１）対象となるUIコンポーネントの子ノードを探索し、
（２）探索された子ノードについてテーブルを作成し、
（３）探索された子ノードを対象として（１）から（２）を行い、
（４）子ノードがなくなったら次の子ノードを対象に（１）から（３）を行い、
（５）すべてのノードがなくなるまで（１）〜（４）を繰り返す。

＜第１のマッピングテーブルの内容＞
図９に、実施例１における第１マッピングテーブル及び第２マッピングテーブルの一例をそれぞれ示す。第１マッピングテーブルＴ１は、開発者がJSPに記したid（第１マッピングテーブルＴ１に示す”Server Id”）とDSB（第１マッピングテーブルＴ１に示す”DSB name”）を、ネーミングルールを元に対応付けたテーブルである。

開発者が名づけたIDと、オブジェクトワークスのDSBカラム名とが所定の関係を有する場合も、そのＩＤとDSBカラム名とは対応づけられて第１マッピングテーブルに記入される。

前記の如く、図２に示したデータストア定義（アプリケーションのデータ定義）の例では、”kaiin_no”, ”kaiin_name”, ”kaiin_addr”, ”birth_day”, ”tel_no”などのDSBカラム名やそれらに対応するデータ型などが定義されている。

図５に示すJSPファイルの例では、”kaiin_no”, ”kaiin_name”, ”kaiin_addr”, ”birth_day”, ”tel_no__0” , ”tel_no__1” , ”tel_no__2”などのIDが定義されている。

そして、"kaiin_name", "kaiin_addr", "birth_day"などのServer Idに対しては、同じ名前のDSB nameが存在するので、
"kaiin_name"というServer Id と"kaiin_name"というDSB name、
"kaiin_addr"というServer Idと"kaiin_addr"というDSB name、
"birth_day"というServer Idと"birth_day"というDSB name、
がそれぞれ第１のマッピングテーブルにおいて対応づけられている。

また、"tel_no__0", "tel_no__1", "tel_no__2"などのServer Idに対しては、末尾の"__(アンダースコア又はアンダーライン)数字"を取り除いたDSB nameが存在するので、
"tel_no__0"というServer Idと"tel_no"というDSB name、
"tel_no__1"というServer Idと"tel_no"というDSB name、
"tel_no__2"というServer Idと"tel_no"というDSB name、
がそれぞれ第１のマッピングテーブルにおいて対応づけられている。

＜第２のマッピングテーブルの内容＞
図９に示すように、第２マッピングテーブルＴ２は、JSFが自動的に変換して付けたHTMLのnameとDSB nameとを対応付けたテーブルである。第１マッピングテーブルＴ１、第２マッピングテーブルＴ２ともにサーバサイドのメモリ上に生成される。

JSFはServer Idに基づいてHTMLのnameを決定する。例えば、図５のJSFタグ部分５２に関しては、
“kaiin_name”というServer Idから“form1:kaiin_name”というHTMLのnameを、
“kaiin_addr”というServer Idから“form1:kaiin_addr”というHTMLのnameを、
“birth_day”というServer Idから“form1:birth_day”というHTMLのnameを、
"tel_no__0"というServer Idから"form1:tel_no__0"というHTMLのnameを、
"tel_no__1"というServer Idから"form1:tel_no__1"というHTMLのnameを、
"tel_no__2"というServer Idから"form1:tel_no__2"というHTMLのnameを、
それぞれ決定する。

そして、かかるServer IdとHTMLのnameとの対応関係、及び第１マッピングテーブルＴ１のServer IdとDSB nameとの対応関係に基づいて、HTMLのnameとDSB nameとの対応関係が決定される。

具体的には、図９に示すように
“form1:kaiin_name”というHTMLのnameと“kaiin_name”というDSB name、
“form1:kaiin_addr”というHTMLのnameと”kaiin_addr”というDSB name、
“form1:birth_day”というHTMLのnameと”birth_day”というDSB name、
"form1:tel_no__0"というHTMLのnameと”tel_no"というDSB name、
"form1:tel_no__1"というHTMLのnameと”tel_no"というDSB name、
"form1:tel_no__2"というHTMLのnameと”tel_no"というDSB name、
がそれぞれ第２マッピングテーブルＴ２において対応づけられている。

＜第１マッピングテーブルの利用＞
第１マッピングテーブルＴ１は、Hidden項目としてHTMLファイル中に、またはメモリに保持される。次回のリクエストメッセージ受信時に、画面が遷移しなければ、第１マッピングテーブルは、UIコンポーネントツリーに代入された値をDSBに代入する際に再び利用される。

＜第２マッピングテーブルの利用＞
第２マッピングテーブルＴ２は、JavaScriptとしてHTMLファイルに埋め込まれて、レスポンスメッセージとしてクライアントサイドに送信される。第１フレームワークが提供し、クライアントサイドで実行される機能として、チェック機能、フォーマット機能などがある。これらの機能がクライアントサイドで実行される際に、第２マッピングテーブルＴ２は利用される。埋め込まれるJavaScriptの例を以下に記す。

<Script>
<!--
var map = new Object();
map["form1:kaiin_name"] = "kaiin_name";
map["form1:kaiin_addr"] = "kaiin_addr";
map["form1:birth_day"] = "birth_day";
map["form1:tel_no__0"] = "tel_no";
map["form1:tel_no__1"] = "tel_no";
map["form1:tel_no__2"] = "tel_no";
//-->
</Script>

このようなJavaScriptによって、"form1:kaiin_name"というname属性を有するHTMLファイルのフィールドに入力されたデータが、"kaiin_name"というname属性を有するDSBにマッピングされて、第１フレームワークが提供するチェック機能等が実行される。これらデータ入力、データマッピング及びチェック機能等の実行は、全てクライアントサイドで行われる。

JSPファイルに書かれた全ての処理が終了すると、レスポンスメッセージがクライアントサイドに送信される。

(イ)クライアントサイドでの処理 ステップＳ２０〜Ｓ２３
図１０に、実施例１においてクライアントサイドでチェック処理が行われる場合の処理の流れを示す。図１０のステップＳ２１〜２３は、図３のステップＳ２１〜２３に対応している。

図１０に示すように、クライアントＰＣがレスポンスメッセージを受信したら、レスポンスメッセージに含まれるHTMLファイルがWebブラウザによって解釈され、液晶ディスプレイ、ＣＲＴなどの表示装置の画面にHTMLファイルの内容が表示され（ステップＳ２０）、
クライアントサイドのユーザがデータフィールドにデータを入力したら（ステップＳ２１）、
入力されたデータのデータ型等に関するチェック処理が実行され（ステップＳ２２）、
ユーザによって送信ボタンなどがクリックされたら、リクエストメッセージがサーバサイドへ送信される（ステップＳ２３）。

＜サーバサイドからレスポンスメッセージが戻り、ブラウザに表示：ステップＳ２０＞
図１１は、実施例１において、レスポンスメッセージを受信したクライアントサイドのWebブラウザによって表示装置の表示画面に表示される画面と、メモリに展開されているJavaScript等とを示す概念図である。同図に示す例では、entry.jspというJSPファイルを変換して得られるHTMLファイルに基づいて「登録画面」１１０１が表示される。また、ブラウザが「登録画面」１１０１を表示する際に、例えば図６のエリアＡ３１のJavaScriptがクライアントPC(パーソナルコンピュータ)のメモリ１１０３上に展開される。この際、onLoad属性に書かれたJavaScriptが実行されるが、本実施例ではonLoad属性は使用しないため、「登録画面」１１０１が表示される際にはメモリ上に格納されるのみとなる。図１１に示すように、「登録画面」１１０１は、氏名入力フィールド、住所入力フィールド、生年月日入力フィールド、第１電話番号入力フィールド、第２電話番号入力フィールド、第３電話番号入力フィールド、及び登録ボタンから構成されている。

＜データ入力：ステップＳ２１＞
図１２に、実施例１において、クライアント側でユーザが入力フィールドにデータを入力している途中の登録画面の状態を示す。入力フィールドに書き込みがなされている最中は、チェック処理やフォーマット処理などは実行されない。

＜チェック処理：ステップＳ２２＞
onBlur属性にJavaScriptの関数名（例えば、blurEventHandler(this)と記述する。）が書かれている場合は、入力フィールドからフォーカスがはずれた時に、メモリに格納されている関数が呼び出される。

図１３は、入力フィールドからフォーカスが外れた場合に、関数が呼び出されることを示す概念図である。同図に示す例では、入力フィールドからフォーカスがはずれた際に、クライアントＰＣのメモリに格納されているチェック処理機能やフォーマット処理機能が呼び出される。

例えば、チェック処理が呼び出された場合、HTMLファイルの各フィールドのname属性が、どのDSB nameに対応するかが、HTMLファイルにJavaScriptとして埋め込まれている第２マッピングテーブルＴ２に基づいて判断され、
HTMLファイルの各フィールドに入力されたデータが、対応するDSB nameのデータとして、第１フレームワークが提供するチェック機能に渡され、値の不正がチェックされる。

図１４は、実施例１において、HTMLのname属性を引数にして関数を呼び出す場合に、HTMLのname属性をDSBの名前に変換することを説明するための概念図である。同図に示す例では、入力フィールドからフォーカスがはずれた際に、name属性を引数にして所定の関数を呼び出す。

次に、第２マッピングテーブルＴ２に対応する図６のエリアＡ３４に示したJavaScriptを利用して、例えばname属性が"form1:birth_day"であるフィールドに入力されたデータを、nameが"birth_day"であるDSB用のデータとして扱う。

そして、図６のエリアＡ３１に示したJavaScriptにより提供されるチェック機能（日付形式YYMMDDを満たしているか調べるものとする）によって、データが不正か否かをチェックする。

このように、HTMLファイルのname属性とDSB nameとが一致しない場合であっても、HTMLファイルのデータフィールドに入力されたデータは、第２マッピングテーブルＴ２に基づいて、所定のDSBに渡され、クライアントサイドにおいて第１フレームワークが提供するチェック機能等によって適切に処理される。

なお、フォーカスがはずれてチェック機能の実行が開始される場合について説明したが、submitボタンが押された場合にチェック機能等が実行されるとしても良い。例えば、onSubmit属性にJavaScriptの関数名（例えば、submitEventHandler(this)と記述する。）が書かれている場合は、submitボタンが押されるとメモリに格納されている関数が呼び出される。関数の呼び出し方が異なるが、その他の点はonBlur属性の場合と同様であるため説明を省略する。

＜リクエストの送信：ステップＳ２３＞
ユーザがsubmitボタンなどを押下することにより、サーバサイドへリクエストメッセージが送信される。

(ウ) サーバサイド ステップＳ３１〜Ｓ３８
図１５は、実施例１において、リクエストメッセージを受信してからサーバサイドで行われる処理の流れを示す。図１５（ａ）は処理の流れの概要を示し、図１５（ｂ）は処理の流れの詳細を示す。図１５（ａ）及び（ｂ）に示すように、
ステップＳ１５０１で、第１のオブジェクトワークス処理が実行され、
ステップＳ１５０２で、コネクタが呼び出され、
ステップＳ１５０３で、第１のコネクタ処理が実行され、
ステップＳ１５０４で、JSF呼び出し処理が実行され、
ステップＳ１５０５で、JSFの処理が実行され、
ステップＳ１５０６で、第２のコネクタ処理が実行され、
ステップＳ１５０７で、第２のオブジェクトワークス処理が実行され、
ステップＳ１５０８で、JSPへディスパッチされ、
ステップＳ１５０９で、サーバサイド（下り）の処理が実行される。

図３で示した処理フローのステップＳ３２以降が、図１５で示した処理フローのJSF呼び出し処理Ｓ１５０４以降に相当する。以下、図１５にしたがって説明する。

＜第１のオブジェクトワークス処理：Ｓ１５０１＞
まず、リクエストメッセージを受け付ける。リクエストデータには以下のものが入っている。

・オブジェクトワークス用のデータ、コントロールを行うために必要な情報
・JSF用のデータ、コントロールを行うために必要な情報
（UIコンポーネントツリーの状態、構造を含む）
リクエストデータは、常にname=valueというデータ形式で送られてくる。例えば、kaiin_name=野村太郎などである。

オブジェクトワークス用のデータとは、オブジェクトワークスのDSBカラム名をname属性に持つデータのことであり、JSFの保持しているUIコンポーネントツリーとは関連の無いデータのことである。例えば、図６に示した例であれば、エリアＡ３２に示した
<INPUT type='hidden' name='_DSBCONTENT' value = 'E80AA7C4090AA84C7 85015E3079DF7645FBB1046E8568B73346A9052811A67F4CD2A35856E9F544D9BB6E73901C99C4EF9B5D0C872D2CCCB71EDD13150EA547F2B9EAD9D199D85BADE3E1E9CB22D80B2681EF07E9361FBE89761CA96922931667ACA84963D62C992A1DCF896A3FF596693E31255D7185D8B6D9E9A0AD4E679C4B38AE85A67DDA579EB2D7B4ACE104F5F347B6D46B588DD341A067DC43DA39D0614AFAFFDD88BC3C363ACCBFF415367954124BAAF083F1381B524F09EE88A18A66E02ED8E4C5B084'>
などである。DSBなど、オブジェクトワークスで引き継ぐ情報を変換（シリアライズ）したものである。

また、オブジェクトワークス用のコントロールを行うために必要な情報とは、例えば、図６に示した例であれば、エリアＡ３５に示した
<INPUT TYPE='hidden' name='_WindowName' value=''>
<INPUT TYPE='hidden' name='_ReturnPageInfo' value='null'>
などである。

JSF用のデータとは、JSFによってServer Idから変更されたHTML name（例えば、form1:kaiin_name）が持つデータのことであり、前回のレスポンスメッセージの一部として、クライアントサイドへ返したUIコンポーネントツリーの部品と関連付けられる。

また、JSF用のコントロールを行うために必要な情報とは、例えば、
<input type="hidden" name="com.sun.faces.VIEW" value="rO0ABXNyACBjb20uc3 VuLmZhY2VzLnV0aWwuVHJlZVN0cnVjdHVyZRRmG0QclWAgAgAETAAIY2hpbGRyZW50ABVMamF2YS91dGlsL0FycmF5TGlzdDtMAAljbGFzc05hbWV0ABJMamF2YS9sYW5nL1N0cmluZztMAAZmYWNldHN0ABNMamF2YS91dGlsL0hhc2hNYXA7TAACaWRxAH4AAnhwc3IAE2phdmEudXRpbC5BcnJheUxpc3R4gdIdmcdhnQMAAUkABHNpemV4cAAAAAF3BAAAAApzcQB+AABzcQB+AAUAAAAGdwQAAAAKc3EAfgAAcHQAKGphdmF4LmZhY2VzLmNvbXBvbmVudC5odG1sLkh0bWxJbnB1dFRleHRwdAALa2FpaW5fbm9fXzBz
＜中略＞
4AGgAAAAJ1cQB+ABoAAAAddXEAfgAaAAAABnVxAH4AGgAAAAhzcQB+AB4/QAAAAAAADHcIAAAAEAAAAAB4cHQAEXRlc3Q6QUNUX2RvU2VhcmNocQB+ABZxAH4AInEAfgAjdAASamF2YXguZmFjZXMuQnV0dG9ucHNyACZqYXZheC5mYWNlcy5jb21wb25lbnQuU3RhdGVIb2xkZXJTYXZlclnKsz2TnM1NAgACTAAJY2xhc3NOYW1lcQB+AAJMAApzYXZlZFN0YXRldAASTGphdmEvbGFuZy9PYmplY3Q7eHB0AChjb20uc3VuLmZhY2VzLnV0aWwuQ29uc3RhbnRNZXRob2RCaW5kaW5ndAABMHBxAH4AI3EAfgAidAASSlNG44K/44Kw44Gn6YCB5L+hcHBwcQB+ACNxAH4AI3BwcHBwcHBwcHBwcHBwcHBxAH4AI3EAfgAjcHBwcHQABnN1Ym1pdHVxAH4AGgAAAAA=" />
<input type="hidden" name="test" value="test" />
などである。これはJSFの画面情報をシリアライズしたものである。

前記のような所定のデータや情報を受信し、サーバサイドの機能（ブラウザの不正操作対応等）を実行する。HttpSessionもしくはhidden項目にDSBがある場合はそのDSBを取得し、ない場合はDSBを作成して、メモリに格納する。そして、オブジェクトワークス用のリクエストデータをメモリ上のDSBに格納する。

＜第１のコネクタの処理：ステップＳ１５０３＞
第１フレームワークであるオブジェクトワークスのデータを、第２フレームワークであるJSFで使用するなら、JSF用のデータにマッピングする。ただし、本実施例ではJSFでオブジェクトワークスのデータを使用しないこととするため、マッピングしない。

＜JSFの処理：ステップＳ１５０４〜１５０５＞
JSFを呼び出して（Ｓ１５０４）、JSFの処理を実行する（Ｓ１５０５）。JSFの処理とは以下のようなものである。

1. 前回のレスポンスで保存したUIコンポーネントツリーを取り出す。ない場合はこの後の処理は何もしないで処理を抜ける。

2. リクエストメッセージに含まれているデータの各々を、UIコンポーネントツリーの所定のノードに当てはめる。

3. UIコンポーネントに入れられた値の入力チェック、型変換を行う（コンポーネントにチェック機能、フォーマット機能が登録されていた場合）。

4. Java Beanと呼ばれるデータ領域に値を格納する。

5. BL（ビジネスロジック）を呼び出す。

6. 画面遷移を決定し、次の画面へディスパッチする。

7. 上記の処理の途中で、値が変更されたといった、イベントと呼ばれる前もって設定しておいた事象が発生するとそれに応じた処理が行われる。

BL呼び出し、次画面へのディスパッチなどの上記５，６の処理はオブジェクトワークスで行うため、本実施例では実行しないで処理を抜ける。

このようにして、JSFによる入力チェックや型変換を終えた値が、UIコンポーネントツリーに格納される。

＜第２のコネクタ処理：ステップＳ１５０６＞
図１６は、実施例１において、JSFによってUIコンポーネントに格納されたデータを、DSBにマッピングする処理の概要を示す。このデータマッピングのために使用する第１テーブルＴ１は、前回のレスポンスメッセージ送信時に生成されているため、ここでは参照するだけでよい。図１６に示すように、Javaプログラムは、name属性を用いて、UIコンポーネントに格納されたデータを、メモリ上に展開されているDSBに値をセットする。また、Javaプログラムは、名前の変換を行う。名前変換（又は名前解決）及びDSBへの値のセット（又はデータマッピング）については、以下に詳述する。

図１７は、実施例１において、第２マッピングテーブルＴ２を作成した時と同様に、各コンポーネントを再帰的に走査して、データマッピングすることを示す概念図である。各コンポーネント毎に以下の処理を行う。

（１）名前変換（又は名前解決）
（１−１）走査中に対象となったUIコンポーネントのIdと、メモリ上の第２テーブルＴ２のServerIdとを比較する。

（１−２）第２テーブルＴ２内に、UIコンポーネントのIdと一致するServerIdが存在した場合は、第２テーブルＴ２内においてそのServerIdに対応付けられているDSB nameをDSBの名前とみなして、次の処理に移る。

（１−３）第２テーブルＴ２内に、UIコンポーネントのIdと一致するServerIdが存在しない場合には処理を抜ける。

（２）データマッピング
名前変換処理で、第２テーブルＴ２内に、UIコンポーネントのIdと一致するServerIdが存在した場合には、UIコンポーネントの値をDSBにセットする。

従って、UIコンポーネントの種類に応じて、アルゴリズムを変更しDSBに値をセットしていく。

すべてのコンポーネントに対して、名前変換及びデータマッピングの処理が終わったら第２のコネクタ処理Ｓ１５０６を抜ける。

＜第２のオブジェクトワークス処理：ステップＳ１５０７〜１５０９＞
BL（ビジネスロジック）が呼び出され、第２のオブジェクトワークス処理を実行する（Ｓ１５０７）。レスポンスがJSFによってコミットされていた場合は、第２のオブジェクトワークス処理は行わない。

BLや、バックエンドの処理（図１１〜１３に例示した登録処理など）は、第２のコネクタ処理Ｓ１５０６によってDSBにセットされた値に基づいて実行される。

BLの戻り値と画面遷移定義に基づいて、画面を遷移する／しない、さらに画面を遷移する場合はどの画面に遷移するかを決定し、JSPにディスパッチする（Ｓ１５０８）。つまり、次のJSPを読み込む。そして、図３のステップＳ１１以降のサーバサイドの処理（下り）へ移行する。

実施例１におけるサーバの構成を示すブロック図である。 実施例１におけるデータストア定義（アプリケーションのデータ定義）の内容を示す図である。 実施例１における全体的な処理の流れを示すフローチャートである。 実施例１において、JSPファイルがHTMLファイルに変換される処理の流れを示す図である。 実施例１におけるJSPファイルの一例を示す図である。 実施例１におけるJSPファイルの一例とそれに対応するHTMLファイルの一例を示す図である。 実施例１におけるUIコンポーネントツリーの一例を示す図である。 実施例１におけるUIコンポーネントツリーの各コンポーネントを再帰的に順次たどる様子を示す図である。 実施例１における第１マッピングテーブル及び第２マッピングテーブルの一例をそれぞれ示す図である。 実施例１において、クライアントサイドでチェック処理が行われる場合の処理の流れを示す図である。 実施例１において、レスポンスメッセージを受信したクライアントサイドのWebブラウザによって表示装置の表示画面に表示される画面と、メモリに展開されているJavaScript等とを示す概念図である。 実施例１において、クライアント側でユーザが入力フィールドにデータを入力している途中の登録画面の状態を示す図である。 入力フィールドからフォーカスが外れた場合に、関数が呼び出されることを示す概念図である。 実施例１において、HTMLのname属性を引数にして関数を呼び出す場合に、HTMLのname属性をDSBの名前に変換することを説明するための概念図である。 実施例１において、リクエストメッセージを受信してからサーバサイドで行われる処理の流れを示すフローチャートであって、（ａ）は処理の流れの概要を示し、（ｂ）は処理の流れの詳細を示す。 実施例１において、JSFによってUIコンポーネントに格納されたデータを、DSBにマッピングする処理の概要を示す図である。 実施例１において、第２マッピングテーブルＴ２を作成した時と同様に、各コンポーネントを再帰的に走査して、データマッピングすることを示す概念図である。

符号の説明

３０…サーバ装置、 ３１…中央処理装置、
３２…メインメモリ、 ３３…送受信装置、
３５…ファイル装置、 ３７…バス、

Claims (6)

1. 主としてビジネスロジックを構築する第１アプリケーションフレームワークと、主としてＷｅｂ画面の遷移を定義する第２アプリケーションフレームワークとを連携して機能させるために第１コンピュータに、
   前記第１アプリケーションフレームワークが第１データ用フィールドに対して用いる第１識別名と、前記第２アプリケーションフレームワークが前記第１識別名に対応して用いる第２識別名との対応関係を示す第１対応表を前記第１コンピュータの記憶手段に記憶させる手順、
   前記第２アプリケーションフレームワークが第１ファイルをＷｅｂブラウザで閲覧可能な第２ファイルに変換する際に前記第２識別名に対応して用いる第３識別名と、前記第１識別名との対応関係を示す第２対応表を前記第１コンピュータの記憶手段に記憶させる手順、
   前記第１アプリケーションフレームワークが提供する機能と、前記第２対応表とを前記第２ファイルとともに、前記第１コンピュータの送信手段に送信させる手順を実行させるためのフレームワーク間連携プログラム。
2. 前記第３識別名に対応付けられたデータを、前記第１コンピュータの受信手段に受信させる手順、
   前記第２対応表を用いて、前記第３識別名に対応付けられたデータを、前記第２識別名に対応付けて前記第１コンピュータの記憶手段に記憶させる手順、
   前記第１対応表を用いて、前記第２識別名に対応付けられたデータを、前記第１識別名に対応付けて前記第１コンピュータの記憶手段に記憶させる手順を、さらに実行させる請求項１記載のフレームワーク間連携プログラム。
3. 前記第２アプリケーションフレームワークがJavaServer Facesであり、前記第１コンピュータがクライアント・サーバ・システムにおけるサーバであり、前記第１識別名がData Store Beanのnameであり、前記第２識別名がJavaServer Pagesのidであり、前記第３識別名がHTMLのnameであり、前記第１ファイルがJavaServer Pagesファイルであり、前記第２ファイルがHTMLファイルである請求項１又は２記載のフレームワーク間連携プログラム。
4. 主としてビジネスロジックを構築する第１アプリケーションフレームワークと、主としてＷｅｂ画面の遷移を定義する第２アプリケーションフレームワークとを連携して機能させるために第１コンピュータに、
   前記第１アプリケーションフレームワークが第１データ用フィールドに対して用いる第１識別名と、前記第２アプリケーションフレームワークが前記第１識別名に対応して用いる第２識別名との対応関係を示す第１対応表を前記第１コンピュータの記憶手段に記憶させる手順、
   前記第２アプリケーションフレームワークが第１ファイルをＷｅｂブラウザで閲覧可能な第２ファイルに変換する際に前記第２識別名に対応して用いる第３識別名と、前記第１識別名とを対応付ける第２対応表を前記第１コンピュータの記憶手段に記憶させる手順、
   前記第１アプリケーションフレームワークが提供する機能と、前記第２対応表とを前記第２ファイルとともに、前記第１コンピュータの送信手段に送信させる手順を含むフレームワーク間連携方法。
5. 前記第３識別名に対応付けられたデータを、前記第１コンピュータの受信手段に受信させる手順、
   前記第２対応表を用いて、前記第３識別名に対応付けられたデータを、前記第２識別名に対応付けて前記第１コンピュータの記憶手段に記憶させる手順、
   前記第１対応表を用いて、前記第２識別名に対応付けられたデータを、前記第１識別名に対応付けて前記第１コンピュータの記憶手段に記憶させる手順を、さらに含む請求項４記載のフレームワーク間連携方法。
6. 前記第２アプリケーションフレームワークがJavaServer Facesであり、前記第１コンピュータがクライアント・サーバ・システムにおけるサーバであり、前記第１識別名がData Store Beanのnameであり、前記第２識別名がJavaServer Pagesのidであり、前記第３識別名がHTMLのnameであり、前記第１ファイルがJavaServer Pagesファイルであり、前記第２ファイルがHTMLファイルである請求項４又は５記載のフレームワーク間連携方法。
   

Images