ADF ToyStore
- 3: サンプル・アプリケーションの分析 「コントローラ層」 -

Apache Strutsフレームワークでのコントローラ層の実装

Strutsのアクションによって、モデルの相互作用とページ・フローを処理する

Strutsを使用し、次の内容を実行することによって、Webアプリケーションの「ページ・フロー」を記述します。

• アプリケーションで実行する必要のあるアクションに対して、論理名を割り当てる
• アクションの間を追跡可能な有効な「ルート」を提示する

簡単なページ・フローの例

たとえば、簡単なWebストアのアプリケーションでは、ユーザーは、 /yourcartという名前のアクションを使用して買い物かごの中身を調べるかもしれません。 一般に、Strutsを使用する場合、ブラウザから *.doという接尾辞と一致するURLをリクエストしたときにアクションが実行されるため、 /yourcartアクションのURLは、次のようになります。

http://yourcompany.com/ADFToyStore/yourcart.do

買い物かごを調べる一方で、ユーザーは、/reviewcheckoutアクションのリンクをクリックして、購入した内容を確認し、支払の処理を開始することもできます。

図34: Strutsのアクションとフォワード

点線は、Webページ内に、リンクまたは矢印の先のアクションをターゲットとするHTMLフォームがあることを表します。 これはほんの一例ですが、より複雑なアプリケーションに対するStrutsのアクションとページに対して、ビジュアル・ダイアグラムが、わかりやすい「ページ・フロー」を示してくれることは想像できるでしょう。このページ・フローでは、ユーザーが遷移できるページ、およびどのようにしてページ間を遷移するかが示されています。

ポストバック・パターン

図36: ポストバック・パターンを実装したページとアクション

ご想像どおり、「DataPage」のアプローチを使用した方が、大きいサイズのアプリケーションの場合に、ページ・フロー図の把握がより簡単になります。 後で確認しますが、ADF ToyStoreのコントローラ層は、このDataPageアプローチを使用して実装されています。

Strutsの構成ファイル

図37: Strutsの構成ファイルの場所

struts-config.xmlファイルをダブルクリックすると、デフォルトで、ビジュアルなページ・フロー図が表示されます。 ADF ToyStoreサンプル・アプリケーションのページ・フローを調べて、これらの図の1つ1つがどのように表示されるのかを検討します。

ADF ToyStoreのStrutsページ・フロー

struts-config.xmlファイルには、構成情報の他の部分とともに、アプリケーションのそれぞれのアクションに対応する <action>タグが含まれています。 Strutsのactionタグでネストされている <forward>要素は、たとえば、 /yourcartページからたどることができる有効なページ・ナビゲーション「ルート」である、 reviewcheckoutのような、論理的な名前を提供します。この例では、支払いする商品を確認するためのルートとして、フォワード先が1つだけ用意されています。

parameter属性の値は、 /yourcartアクションが、 /WEB-INF/jspディレクトリにある yourcart.jspページに関連していることを示しています。 また、このアクションが toystore.controller.strutsactionパッケージの YourCartActionクラスにマップされていることもわかります。 このアクションには、 UpdateCartおよび RemoveItemのイベントを処理するためのコントローラ・ロジックが含まれています。これらのイベントは、ユーザーがページで適切なボタンをクリックすると発生し、買い物かごの数量を調整するために、 ToyStoreServiceの adjustQuantitiesInCartAsStringArrays()を呼び出します。 このアクションには、ビジネス・サービスから買い物かごの合計を取得してページに表示するためのコードも含まれています。

YourCartActionクラスは、 FwkExtensionsプロジェクトの ToyStoreDataForwardActionクラスを拡張したものです。 このフレームワークの拡張クラスは、ADFの DataForwardAction からの多数の組込み動作を継承し、加えて、ToyStoreサンプル・アプリケーションの多くのアクションで有用なヘルパー・メソッドがいくつか追加されています。
アクション定義タグの中に登場する modelReferenceプロパティの値は、データ・バインディング機能のための定義情報を指しています。

その他のStrust設計時サポート

図40: JDeveloperのStruts構成エディタ

ここでわかるように、Strutsの構成情報を操作するために、Struts ページフロー図、構造ウィンドウおよびプロパティ・インスペクタの組合せを使用して、処理に必要なすべてのことを実現することができます。 逆に、XMLソースを編集したい場合には簡単に実施可能で、ユーザーが手動で行った編集内容とページ・フロー図を自動的に同期化します。 この選択は自由です。

Struts Form Beansを使用してHTMLフォームの入力を処理する

コントローラ層のアクション・クラスの管理に関連する補足機能関として、Strutsでは、アクションでのHTMLフォームの入力処理のサポート機能があります。 Strutsのコントローラ・サーブレットは、フォームBean と呼ばれるオブジェクトの属性に、送信されたHTMLフォームのデータを移入します。 そこで、アクション・クラスを記述する開発者は、Beanのgetterおよびsetterメソッドを使用して、HTMLフォームの値を操作することができます。 ユーザーがHTMLフォームで入力したデータは文字列として受け取られ、入力されたデータにおける検証エラーなどは、ユーザーの再入力（修正）の際に、そのまま再表示して値を示すことが期待されるため、通常、フォームBeanのすべてのプロパティはString型として処理します。

これらの追加属性セットによって、Strutsのコントローラは、実行時にユーザーがフォームを送信したとき、サインイン・ページのHTMLフォームのusernameとpasswordの値を LoginForm Beanへ移入します。 これらの値は、 SignInActionクラスの onVerifySignin()イベントハンドラ・メソッドによってアクセスされます。このメソッドは、ユーザーがフォームを送信したときに、そのポストバック処理の中でコールされます。

前述のログイン・フォームの送信に対して、検証に失敗すると、再入力のためにsigninページがユーザーに提示されます。 検証で成功すると、前述のコードによってヘルパー・メソッドがコールされ、対象ユーザーがサインインしたことを示すフラグが設定され、適切なページが返されます。 また、このアクションでは、 targetパラメータを設定していますが、これは、このサンプル・アプリケーション内の他の任意のアクションで、次の処理の前にユーザーのログインを要求したい場合に使用します。このような場合、 targetパラメータで適切な「次の」ページを指定した上で、 signinページにフォワードすると、ログイン認証の後、指定した「次の」ページに転送されるようになります。

ADF/Strutsの統合について

ADFデータ・バインディングとコントローラのコンセプトの概要

ADFデータ・バインディング・コンセプトの概要

Oracle ADFの主なデータ・バインディング概念は次のとおりです。

• データ・コントロール

  データ・コントロールは、ビジネス・サービス実装を抽象化し、バインディング層が一貫した方法ですべてのサービスからデータをアクセスできるようにしています。

• イテレータ・バインディングとコントロール・バインディング

  バインディングは、バックエンド・データとフロントエンドUI表示を分離する軽量オブジェクトです。 イテレータ・バインディングは、データ・コントロールによって提供されたデータ・オブジェクトのコレクションを扱う一貫した方法を提供します。 コントロール・バインディングはUIコンポーネントに対する標準インタフェースを提供して、そのインターフェースを通して、イテレータ・データのやりとりや、モデル・データの設定/イベント処理を行う「アクション」メソッドの呼び出しなどを可能にします。 バインディングは、動的な、多言語対応のユーザー・インタフェースを容易に構築可能にするための主要メタデータも公開しています。

• バインディング・コンテナ

  バインディング・コンテナは、アプリケーションの特定のページ（またはパネル）用に使用する、イテレータ・バインディングおよびコントロール・バインディングの名前付きグループです。 バインディング・コンテナはUI用にモデル・データの適切なサブセットを提供するため、「UIモデル」とも呼ばれます。

• バインディング・コンテキスト

  バインディング・コンテキストはユーザー・アプリケーションに対してデータ環境を提供します。 ユーザー・アプリケーションからアクセスできるすべてのデータ・コントロールおよびバインディング・コンテナが含まれます。

Strutsに対するADFのコントローラ層機能

Apache StrutsアプリケーションでADFバインディング層の利用を簡単にするために、Oracle ADFには、Strutsのためのコントローラ層コンポーネントが用意されており、StrutsとADFバインディング層をシームレスに統合することができます。 これらのコンポーネントには、次のものが含まれています。

• サーブレット・フィルタ ADFBindingFilter。このフィルタは、ビジネス・デリゲート、ビジネス・サービス・プーリング、およびステート管理の使用を調整します。
• Struts DynaActionFormを拡張した、汎用で利用可能な BindingContainerActionForm。これを使用すると、作成するそれぞれのページに対して、StrutsのフォームBeanを作成する必要がなくなります。
• Struts Actionクラスを強化したDataAction。このクラスは、リクエスト処理の中で、ADFのデータ・バインディング機能を利用できるようにライフサイクルを実装しています。もちろん、このライフサイクルは、簡単にカスタマイズ可能です。
• Struts ActionMapping の拡張クラスであるDataActionMapping。このクラスは、データ・バインディングの自動処理のために使用される追加の宣言的な定義情報を、アクション・マッピングの拡張プロパティから取得します。

DataForwardActionによる宣言的機能の概要

StrutsとADFを使用したWebページ・リクエストのライフサイクル

図45: StrutsとADFを使用したWebページ・リクエストのライフサイクル

1. http://yourserver/yourapp/some.doに対してWebリクエストされます。

2. ADFBindingFilterは、HTTPセッション内でADFバインディング・コンテキストを検索し、見つからない場合は、最初に初期化します。
   バインディング・コンテキストを初期化する際に、 ADFBindingFilterは次の処理を行います。

   • CpxFileNameという名前のサーブレット・コンテキスト初期化パラメータを調べて、その値に拡張子として .cpxを追加した名前で、バインディング・コンテキスト定義ファイルの名前を特定します。 デフォルトでは、パラメータの値は DataBindingsになっているため、ファイル名は DataBindings.cpxになります。
   • バインディング・コンテキスト定義ファイルを読み込んで、データ・コントロール定義およびバインディング・コンテナの名前を検出します。
   • 各データ・コントロールのインスタンス、および各バインディング・コンテナに対する参照を作成します。 このように、バインディング・コンテナに対して作成されるのは、この時点では参照だけで、各バインディング・コンテナの中身は、それらが最初に（どこかのページから）使用されるタイミングでロードされます。
      

3. ADFBindingFilterが、バインディング・コンテキストのそれぞれのデータ・コントロールで beginRequest()メソッドを呼び出します。 これによって、すべてのデータ・コントロールに対して、リクエストの開始点にきたことが通知されます。この通知により、各データ・コントロールで必要なセットアップ作業が実施されます。

4. ADFアプリケーション・モジュールをベースとしているデータ・コントロールは、この beginRequest通知によって、アプリケーション・モジュール・プールからインスタンスを取得します。

5. Strutsの RequestProcessorは、 struts-config.xmlに構成されている /someアクションに対応したアクション・クラスに対して、制御を転送します。

   注意	正確には、最初はStrutsのActionServletが RequestProcessorへ制御を転送しますが、 実質、RequestProessorがその後のすべての処理を実施するため、図の中には ActionServletを省略しています。

   
   

6. Strutsのアクション・クラスがADFの DataActionクラスである、またはそれを拡張している場合は、次の内容を含む一連の処理手順（まとめてリクエスト処理の「ライフサイクル」と呼ばれる）が実行されます。

   • バインディング・コンテナを検索します。
     または、使用したのが初めての場合は、それを初期化します。 初期化の際に、 *UIModel.xmlメタデータ・ファイルに対応するバインディング・コンテナに対して、バインディング・オブジェクトが作成されます。
   • イテレータ・バインディングがまだ実行されていない場合は、 prepareModel()フェーズでそれを実行します。
   • 送信されてきたデータがある場合は、 processUpdateModel()フェーズで、対応するバインディング・オブジェクトに対してそのデータで更新処理をします。
   • invokeCustomMethod()フェーズでコントローラ層のカスタム・ロジックが（あれば）実行されます。
   • findForward()フェーズで、次に表示するページを決定します。

   ライフサイクルの各フェーズは、開発者が上書きすることができます。また、それぞれのメソッドは、 DataActionContextオブジェクトに渡されますが、このオブジェクトでは、バインディング・コンテキスト、バインディング・コンテナ、およびStrutsに関するすべての要素（サーブレット・リクエストやレスポンス、アクション・マッピング、アクション・フォームなど）にアクセスできます。 アクションは、Strutsの ActionForwardを返し、これによって、次にナビゲートするアクションまたはページを表します。

   注意	Strutsのアクション・クラスがDataActionを拡張していない場合は、アクション・クラスはバインディング・コンテナを手動で検索（および必要な場合は初期化）し、バインディングとの処理を自身で管理する必要があります。 『Oracle ADFによるデータ・バインディング』のホワイト・ペーパーには、この処理を行うためのコード例が記載されています。

   
   

7. Strutsの RequestProcessorは、次に制御を渡すようアクションが指定したアクションまたはページに転送します。

8. 転送先がJSPページであるとします。この場合、ページは、コントロール・バインディングからデータ転送オブジェクトのコレクションへアクセスして反復処理を行い、書式化されたWebページへと書き出されます。

9. Strutsの RequestProcessorは、 ActionServletへ制御を返します。さらに、サーブレット・コンテナへ制御を戻します。

10. ADFBindingFilterは、バインディング・コンテキストのそれぞれのデータ・コントロールで endRequest()メソッドを呼び出します。これによって、すべてのデータ・コントロールに対して、リクエストの終了点にきたことが通知されます。この通知により、各データ・コントロールで必要なリソースのクリーンアップ作業が実施されます。

11. ADFアプリケーション・モジュールをベースとしているデータ・コントロールは、この endRequest通知によって、アプリケーション・モジュール・プールへインスタンスを解放します。

12. ユーザーは、結果ページをブラウザで参照できます。

このシーケンス図をみると、バインディング・コンテナが、コントローラ層によるモデル・データの操作の際も、ビュー層によるモデル・データの反復処理とレンダリングの際も、使用できるということがわかります。

StrutsとADFを使用できるようにJ2EE Webアプリケーションを構成する

JDeveloperを使用してADFベースのStrutsアプリケーションを作成する場合には、設計時のサポート機能によってWebアプリケーションが自動的に構成されます。 ただし、ツールが設定する内容を理解しておくと、個々の設定がどのように統合されるのかを理解するうえで有効です。 J2EE Webアプリケーションでは、いくつかの構成手順において標準の web.xmlファイルを使用します 。 この項では、設定の手順でいくつか興味深い点を中心に説明します。

StrutsのサーブレットとADFのバインディング・フィルタ

まずStrutsを使用するためには、 ActionServletという名前のStrutsのフロントコントローラ・サーブレットを構成し、URLパターンにマップする必要があります。 ADF ToyStoreでは、一般的な *.doというURLパターンを使用して、リクエストを ActionServletへマップしています。 ToyStoreViewControllerプロジェクトの 「Webコンテンツ」フォルダの WEB-INFディレクトリにある web.xmlファイルの該当個所は、次のようになっています。

<web-app>
  :
  <servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
      <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
   :
  <servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>
   :
</web-app>

2番目の手順は、 ADFBindingFilterを設定して、 *.jspまたはStrutsの ActionServletに関するURLが処理されたときに、これを連動させることです。 web.xmlファイルの該当個所は、次のようになります。

<web-app>
  :
  <filter>
    <filter-name>ADFBindingFilter</filter-name>
    <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
   <init-param>
     <param-name>encoding</param-name>
     <param-value>UTF-8</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>action</servlet-name>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <url-pattern>/*.jsp</url-pattern>
  </filter-mapping>
   :
</web-app>

ADFBindingFilterは、アプリケーションに対するバインディング・コンテキスト定義情報を記述したファイルの場所を認識している必要があります。 ここでは、 CpxFileNameというサーブレット・コンテキストの初期化パラメータを読み込んで、ファイル名を特定します。 ADF ToyStoreの web.xmlファイルでは、このパラメータがデフォルトの DataBindingsという値を使用していることがわかります。 これは、 ADFBindingFilterが DataBindings.cpxファイルを使用して、この情報を読み込むことを意味しています。

<!-- web.xml file -->
<web-app>
  <description>web.xml file for the ADF Toy Store demo application</description>
  <context-param>
    <param-name>CpxFileName</param-name>
    <param-value>DataBindings</param-value>
  </context-param>
    :
</web-app>

データ・バインディング・コンテキスト定義ファイル

ToyStoreViewControllerプロジェクトの 「アプリケーション・ソース」フォルダに、 DataBindings.cpxファイルがあります。 これは、ADFのデータ・コントロール、およびADF ToyStoreアプリケーションで使用するバインディング・コンテナの定義情報をすべて記述しているXMLファイルです。 このファイルを見てみると、ADF ToyStoreサンプル・アプリケーションには ToyStoreServiceという1つのデータ・コントロールがあることがわかります。 ナビゲータまたはコード・エディタで DataBindings.cpxファイルが選択されている場合には、同じ情報が構造ウィンドウのツリーで表示されます。

<!-- DataBindings.cpx File -->
<JboProject id="DataBindings" ... >
  <Contents>
      <DataControl
         id="ToyStoreService"
         SubType="DCBC4J"
         SupportsFindMode="true"
         SupportsTransactions="true"
         Package="toystore.model.services"
         FactoryClass="oracle.adf.model.bc4j. DataControlFactoryImpl"
         Configuration="ToyStoreServiceLocal" >
         <Parameters >
            <Parameter
               name="Sync"
               value="Immediate" >
            </Parameter>
         </Parameters>
      </ DataControl>
       :
   </Contents>
</JboProject>

ADF Business Componentsベースのこのデータ・コントロールには、 Packageおよび Configurationという名前のプロパティがあります。 これらの属性の値は、ADFのBusiness Delegateパターン実装ロジックによって、適切なビジネス・サービスのインスタンスを検索するために使用されます。この例では、このビジネス・サービスの構成プロパティは、 ToyStoreServiceLocalという構成によって定義されています。 パッケージ名を指定すると、ADFは実行時に、パッケージ名に対応するディレクトリの commonサブディレクトリで、 bc4j.xcfgファイルを最初に検索します。 前述の例では、指定されたパッケージ名が toystore.model.servicesであるため、実行時のクラスパスから ./toystore/model/services/common/bc4j.xcfgというリソースを開いて読み込みます。 そのファイルには、 ToyStoreServiceLocalという構成定義の中に、ビジネス・サービスの実装として使用される、アプリケーション・モジュールの完全修飾名を表すプロパティが含まれています。

ビジネス・サービスへの参照を、このようなベスト・プラクティスな抽象的方法によって実施できることにより、アプリケーションの残りの部分に影響を与えずに、モデル層の配置の方針を簡単に変更することができます。 ADF Business Componentsを使用してモデル層を構築していれば、後でADF/Strutsのアプリケーションを、簡単なJavaBeanベースのビジネス・サービスの使用から、EJB Session Beanとして配置されているアプリケーション・モジュールの使用へ変更する場合も、データ・コントロールの定義情報で前述のConfiguration属性の値を変更するだけです。 このときに置き換える構成定義には、EJB Session Bean設定に関するさまざまな情報が含まれることになりますが、それはXMLの構成情報の中に明確に切り出されており、コード内の変更を必要としません。 もちろん、設計時には、これらの複数の構成の初期設定の自動化や、構成パラメータ編集用の専用ダイアログといった支援機能が提供されます。

ADFのDataActionとBindingContainerActionFormの概要

ユーザーがアプリケーション・データを入力または編集できるようなHTMLフォームを作成する場合には、前述のように、Strutsによって、FormBeanのインスタンスへフォーム・データが抽出され、ユーザーのアクションで簡単に処理できるようになります。 HTMLフォームとのやり取りに関して、アクションでの、比較的頻度の高いタスクとして、次の3つがあります。

1. データ入力フォームを表示する場合に、FormBeanに適切な初期値を移入する
2. データ編集フォームを表示する場合に、FormBeanに現行の行データを移入する
3. ユーザーが送信した変更データを含むFormBeanを使って、モデル層を更新する

Oracle ADFには、連携するための重要な2つの要素が用意されており、これらのシナリオを簡単に実装することができます。

• Struts DynaActionFormを拡張した、汎用で利用可能な BindingContainerActionForm。これを使用すると、作成するそれぞれのページに対して、StrutsのフォームBeanを作成する必要がなくなります。
• Struts Actionクラスを強化した DataAction 。このクラスは、リクエスト処理の中で、ADFのデータ・バインディング機能を利用できるようにライフサイクルを実装しています。もちろん、このライフサイクルは、簡単にカスタマイズ可能です。

図46: 新しいアカウント情報をデータベースに登録する仕組み

具体的にいうと、ブラウザからデータベースへ、変更データを送信すると、次の手順が実施されます。

1. Strutsの RequestProcessorは、フォームBeanのプロパティに、送信されたフォーム・プロパティの値を移入し、 RegisterActionへ制御を転送します。
2. ADFの DataForwardAction のライフサイクルの処理機能を継承している RegisterActionは、バインディング・コンテナを検索し、 BindingContainerActionFormフォームBeanの対応する値を使用して、バインディング・コンテナ内のモデル・バインディングを更新します。
3. コントロール値バインディングは、 Accountsビュー・オブジェクトに基づくイテレータ・バインディング内のターゲットの行にバインドされています。そのため、バインディングに対して値を設定することによって、ベースとなるビュー行の属性にこれらの値が設定されることになります。
4. ビュー行は、ベースとなるエンティティ・オブジェクトに、属性のsetterコールを委譲します。これがコールされると、エンティティ・オブジェクトに定義されているビジネス・ルールが評価されることになります。
5. 「(Save Changes)」ボタンが event_Saveという名前であるため、 RegisterActionは、 onSave()イベント処理メソッドを呼び出します。 この動作は、ADFの DataForwardAction が持つイベント処理機能を継承した結果です。この onSave()メソッドでは invokeEventAction()ヘルパー・メソッドをコールし、バインディング・コンテナの Saveという名前のアクションを呼び出しています。 このアクション・バインディングは、 ToyStoreServiceデータ・コントロールの組込みの Commit操作にバインドされているため、トランザクションがコミットされます。
6. トランザクションをコミットしたときに検証エラーがない場合は、エンティティ・オブジェクトは、ベースとなる表に変更を書き込みます。

ビュー・オブジェクトはベースとなるエンティティ・オブジェクトと関連付けられているため、ビュー・オブジェクト行にデータが移入されると、フレームワークは属性の設定作業をエンティティ・オブジェクトに委譲します。 これらのエンティティ・オブジェクトには、ユーザーが入力した値の評価を行うビジネス・ルールが定義されています。 いずれかのビジネス・ルールに違反している場合は、フレームワークが、それらの例外を一つにまとめてラッピングして DataActionContextに保存します。その後、DataActionのライフサイクル・メソッドである reportErrors()がコールされたときに、Strutsの ActionErrors に変換され、ユーザーにレポートされます。

自動ステート管理を使用して複数ページの作業単位を作成する

アプリケーションで、複数のWebページにデータを入力して処理を完了するエンドユーザーのタスクをサポートする必要がある場合は、ページ間に保留されているデータを保持するための仕組みを検討する必要があります。 たとえば、従業員ファイルで経費をレポートするWebアプリケーションについて考えてみます。 このタスクでは、多くの経費明細を入力することが必要で、このタスクを完成させるには複数のページに明細を入力する必要があるでしょう。 ユーザーがこれらの詳細を入力している間に、徐々に増えていく保留中の経費レポートのデータは、どこに保存されているのでしょうか?

現在、最も一般的なアプローチは、保留データを次の場所へ保存しておくことです。

1. HTTPセッション・オブジェクト
2. HTMLフォームの非表示フィールド
3. データベース表への一時的な格納

これらのすべてのアプローチには、デメリットがあります。ただし、

1. いくつかのJ2EEアプリケーション・サーバーでは、HTTPセッションに格納されているデータに対して、サーバー・ファーム（アプリケーション・サーバーのクラスタリング構成における一単位）内での確実なアクセスができません。 クラスタリングおよびセッション・ステートのレプリケーションをサポートしている Oracle Application Serverのようなサーバーを使用しても、HTTPセッションに追加するオブジェクトが多くなったり、規模が大きくなったりすると、他のHTTPセッション・オブジェクトと相互に同期をとるために、サーバー間で生成されるトラフィックが増えます。
2. HTMLフォームの非表示フィールドに保留データを格納するということは、非表示のフィールド名に対応するオブジェクトのフィールド構造を準備する必要が出てくるということです。また、データ内容がHTML内に記述されることとなり、結果としてダウンロードするページのサイズが増えます。
3. 保留データは完全に入力完了な状態になっていない場合があるため、それをそのままベースとなるデータベース表に直接格納できないことがありえます（格納すると、データベースの制約違反が発生する場合があるためです）。 そこで、保留データは、一時格納用の表に保存し、いつでも再ロードできるようにしておく手法があります。格納する保留データのそれぞれの種類に対して個別に表セットを作成するか、または、保留データを汎用的に共用のスキーマで格納する方法がありますが、どちらにしても、これらの作業は簡単ではありません。

ADF Business Componentsフレームワークには、ビジネス・サービスに対する組込みのステート管理機能が用意されており、これらのすべての問題にすぐに対処することができます。 すべてのアプリケーション・モジュールのインスタンスは、保留中のステートをデータベースに一時保存でき、そのステートを後でデータベースから再有効化することができます。 保留中のステートは、汎用的なフレームワーク・コードによって1つのXMLドキュメントにシリアライズされます。このXMLドキュメントには、保留中の変更情報のみが含まれ、 PS_TXNという汎用データベース表に対して1回のラウンドトリップで保存されます。 このアプローチには、次のメリットがあります。

• J2EEに準拠している任意のアプリケーション・サーバーで機能する
• 任意の規模のアプリケーション・サーバー・ファームで機能する
• オーバーヘッドが少なく、1つの要求に対して1回のデータベース・ラウンドトリップのみが発生する
• アプリケーション・サーバーのHTTPセッションで同期化のトラフィックが不要になる
• ユーザーに提示されるWebページのサイズが大きくならない
• 作成するすべてのアプリケーションに対して汎用的な同じメカニズムを使用できる

データベースによるセッション管理のため、アプリケーション内でのデータ・アクセスおよび永続性管理の目的で使用されるものとは別のJDBC接続が発生します。 一般的には、ステート管理表はアプリケーション表とは別のデータベース・ユーザーに定義したいものです。ユーザーは、 jbo.server.internal_connection構成プロパティの値に、JDBCデータソースの名前、または JDBC URLの接続文字列を設定することによって、これを制御できます。 ADF ToyStoreサンプル・アプリケーションでは、 jdbc/toystore_statemgmtDS JDBC データソースの名前を使用するように、 jbo.server.internal_connectionの値を設定しているため、アプリケーション表が存在する TOYSTORE データベース・ユーザーではなく、 TOYSTORE_STATEMGMTデータベース・ユーザーの中に PS_TXN表が作成され、管理されています。

ADF Business Componentsのアプリケーション・モジュール・プールでは、ブラウザからのユーザー・リクエストに対するアプリケーション・モジュール・コンポーネントの使用方法に関して、3つのパターンをサポートしています。 3つのモードは次のとおりです。

• ステートレス・モード

  ビジネス・サービス・コンポーネントのステートを保持せずに、現行のリクエスト内で変更内容を強制的にコミット/ロールバックします。

• ステートフル・モード

  組込みのステート管理メカニズムを使用して、保留中のステートを複数のページ・リクエストに渡って保持します。

• リザーブ・モード

  後でステートレス・モードで解放されるまで、またはブラウザ・セッションがタイムアウトになるまで、アプリケーション・モジュール・コンポーネントのインスタンスを、現在のブラウザ・セッションで占有します。

「ステートフル・モード」という名前は、実は適切な用語ではないのかもしれません。 名前をつけた後で、Web開発者にとって「ステートフル」という言葉が、スケーラビリティに関して限界がありそうなことを連想させるということに気付いたからです。 ただし、この「ステートフル」は名前と違い、実際の機能は非常にすぐれています。 「ステートフル・モード」とは、「ステートレスなパフォーマンスでステート管理できるモード」といった意味合いで理解してください。

「ステートフル・モード」を使用すると、完全にステートレスなアプリケーションとほとんど同程度のパフォーマンスを備えたうえで、ステートフル・アプリケーションのプログラミングの簡潔さを実現するWebアプリケーションを作成することができますが、 このことを実現するために、ADF Business Componentsのアプリケーション・モジュール・プールは、「Stateless with Session Affinity：セッション・アフィニティな（セッションに対する配慮のある）ステートレス」として知られているアルゴリズムを実装します。 「ステートフル・モード」のページ・フローでの複数ページにわたるリクエストでは、プールは、現行セッションのページ・フロー内で、最も新しいリクエストで使用されたものと同じインスタンスを返そうとします。 このインスタンスがプール内でまだ有効であり、現在、他のセッションで使用されていない場合は、このシナリオによって最高のパフォーマンスが得られます。

ただし、他のブラウザのユーザー・セッションへこのインスタンスを分配しなければならい場合、またはリクエストがサーバー・ファーム内の別のサーバーへ割り振られた場合は、プールは、他の有効なビジネス・コンポーネント・インスタンスを取得し、データベースに保存されているユーザーの保留中のステートを使って「再有効化」します。 たとえば、ユーザーが新しく5行分のデータを作成し、そのうちの2行を更新して、1行を削除した場合は、これらの同じ変更情報が、ステートを再有効化した後でも提示されることになります。 また、ビュー・オブジェクトのイテレータ・ポジション情報も、ステートの情報として含まれています。このため、最後のリクエストで、イテレータが、コレクションの20行のうち3番目の行にある場合は、ステートを再有効化した後でも現在行はまだ行番号3に位置することになります。

まとめると、アプリケーションで処理しなければならない負荷に対してアプリケーション・モジュール・プールを適切にサイジングすると、 最高のパフォーマンスとスケーラビリティが得られるということになります。

ステートフル・モード は、ADF Business Componentsの処理のデフォルト・モードです。 ユーザーの買い物かごを商品を入れて、商品を購入するタスクは、論理的な1つのトランザクションの部分であるため、このデフォルトのモードは、ToyStoreサンプル・アプリケーションで適切に機能します。

1つの例を見るために、ADF ToyStoreサンプル・アプリケーションの買い物かごを使用してみます。 買い物かごは、 ToyStoreModelプロジェクトの toystore.model.dataaccess.ShoppingCartという名前のビュー・オブジェクトとして実装されており、このビュー・オブジェクトには、一時的なすべての属性 およびSQL問合せが定義されています。 Strutsのアクション・クラス YourCartActionは、 ToyStoreServiceビジネス・インタフェース・メソッドの adjustQuantitiesInCartAsStringArrays()をコールして、買い物かごに対して商品を追加、変更、または削除します。 「ステートフル・モード」を使用しているため、アプリケーション・コードでは買い物かごで保留中のデータをどのように保存しておくかは意識する必要はありません。 ここでは、単に、ShoppingCartオブジェクトに対して、ビュー・オブジェクト・エディタで 「チューニング」パネルから、すべての一時属性（transient属性）をフレームワークのステート管理メカニズムによって非活性化（受動化）できるように設定します。 この機能は、チェックボックスをオンにするだけで使用できます。

これ以降のそれぞれのリクエストにおけるアクションでは、なにも意識することなく ShoppingCartビュー・オブジェクトにアクセスして、データ転送オブジェクトのコレクションを処理したり、ビュー・オブジェクトのデフォルト行セットの内容を調整することができます。

サンプル・アプリケーションのページ・フローにおける最後のアクション、 /thankyouでは、「ステートレス」なリリース・モードを使用して、これ以上は保留ステートを管理する必要がないことを提示します。 ステートレス・モードで解放するために、このアクションは、 DataForwardActionのメインの handleLifecycle()メソッドをオーバーライドし、ヘルパー・メソッド releaseToyStoreServiceStateless()のコールを追加します。これは、 ToyStoreServiceDataForwardAction から継承されたメソッドです。

/* From ToyStoreServiceDataForwardAction */
  protected void releaseToyStoreServiceStateless(DataActionContext ctx) {
    releaseDataControlStateless(DATACONTROLNAME, ctx);
  }

このメソッドは、ステートレス・モードで解放するために、データ・コントロールの名前を引数として、 ToyStoreDataForwardActionのヘルパー・メソッドを呼び出します。次のメソッド・コードをみてわかるように、名前からデータ・コントロールを検出し、 releaseState()メソッドを呼び出します。これにより、保留中のすべてのステート管理情報は、リクエストの最後に解放されます。

/* From ToyStoreDataForwardAction */
  protected void releaseDataControlStateless(String dcName,
    DataActionContext ctx) {
    DC DataControl dc = ctx.getBindingContext().findDataControl(dcName);
    if (dc != null) {
      dc.resetState();
    }
  }

アプリケーション・モジュールをステートレス・モードでプールに解放すると、フレームワークによって管理されていたデータベース内の保留中のステートは、すべて自動的にクリーンアップされます。

• 本書はOracle Corporation発行の「Building a Web Store with Struts & ADF Frameworks」を翻訳し、再構成したものです。
• この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 万一、誤植などにお気づきの場合は、オラクル社までお知らせください。オラクル社は本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。