JBoss Seamのサンプルアプリを試す。その3

EJB

サンプルアプリケーションのBookingを見ていきます。以下もhttp://docs.jboss.com/seam/reference/en/html/tutorial.html#bookingの訳です。間違いなどあればご指摘して下さい。

1.Introduction


Bookingアプリケーションは下記の機能を備えたホテルルーム予約システムす。

    • ユーザ登録
    • ログイン
    • ログアウト
    • パスワード登録
    • ホテル検索
    • ホテル選択
    • ルーム予約
    • 予約確認
    • 予約リスト表示


BookingアプリケーションはJSF、EJB3.0、SeamとビューにはFaceletを使っています。又、このアプリケーションの一部はJSF、Facelet
Seam,JavaBeanやHivernate3です。


　このアプリケーションを十分試して頂くと非常に堅牢なことに気づいて頂けるでしょう。気の済むまで戻るボタン、ブラウザのリフレッシュ、
複数のウィンドウ開いたり、出鱈目なデータを入れたりしてもアプリケーションをクラッシュさせるのが難しいと気づいて頂けるでしょう。
このアプリケーションを完成するのにテストやバグ修正で数週間費やしたとお考えですか？実際はそうではありません、
Seamは堅牢なWebアプリケーションを容易に作成でき、堅牢さはあなたが書かなければならないコードに含まれたりSeamが自動的に不可します。


サンプルアプリケーションのソースコードを見てアプリケーションがどのように動作しているか見て、堅牢さをもるために状態管理を記述式にすること
や組み込まれた妥当性検査がどうなのか意見を述べて下さい。


2. Overview of the booking example



　プロジェクトの構成は前のサンプルアプリケーションregistrationとまったく同一です、インストール、デプロイはSection 1.1 Try the examplesを参考にして下さい。
アプリケーションをスタートしhttp://localhost:8080/seam-booking/へブラウザでアクセスして下さい。

　10のクラス(プラス6つのSessionBeanのLoacal Interfaceと一つのAnnotation Interface)を使用してこのアプリケーションを実装しています。6つのSessionBean Action Listenerは
以下にリストしたビジネスロジックを全て含んでいます。

    • BookingListActionは現在ログイン中のユーザの予約済みの記録を取出します。
    • ChangePasswordActionは現在ログイン中のユーザのパスワードを変更します。
    • HotelBookingActionはこのアプリケーションの中心的な機能を実装していす。ホテルの部屋を検索、選択、予約、予約確認です。この機能は対話的に実装しありますのでこのアプリケーションの中で最も興味深いクラスです。
    • LoginActionはログインデータの妥当性検証をログインユーザのデータを取出します。
    • LogoutActionはログインセッションを終了させます。
    • RegisterActionは新規にシステムユーザを登録します。



3つのEntityBeanがアプリケーションのデータ永続性ドメインへ実装されています。

    • Hotel EntityBeanはホテルを表します。
    • Booking EntityBeanは予約記録を表します。
    • Use EntityBeanはホテル予約を行うことができるユーザを表します。


3. Understanding Seam conversations



　私たちはソースコードを見て頂たいのです。このチュートリアルで際立った機能をに注目してみましょう。ホテル検索、選択、予約、予約確認です。ユーザの視点から見ると、これはひとつの連続的な作業の単位、Conversationです(対話と言う訳は合ってないような．．．．)


　ほとんどのWebアプリケーションの設計はConversationに相当する最も良い機構がありません。Conversationと状態管理との統合は大きな問題を引き起こすからです。通常Java Webアプリケーションは2つの技術を組み合わせたものです。最初に、ある状態はHttpSessionへ投げられ、次に永続的な状態は全てのリクエストの後にDatabaseを書換え、そして新しいリクエストが始まるときにDatabaseから状態を再構築します。


Databaseが最も拡張性に欠けるアプリケーション層であることが、しばしば容認出来ないほどの拡張性の欠如の原因になります。全てのリクエストに対しDatabaseとの余分な通信に起因する待ち時間が加わることも問題です。この助長な通信を無くすためにJavaアプリケーションはリクエスト間でよくアクセスされるデータをキャッシュする方法を導入します。キャッシュを無効にするポリシーがユーザが使用し終わったデータのかわりにLRU Policyが採用されているため、このキャッシュはどうしても非効率です、更に沢山の平行したトランザクション間で共有されるため、私たちの言うDatabaseと一貫性のあるキャッシュを保つことは多くの問題にぶつかります。


　HttpSessionでの状態を保つことを考えてみましょう。注意深くプログラムすればセッションデータのサイズをコントロールできるかもしれません。それはブラウザで、想定された以外の自由なナビゲーションを許すことを前提にすると、言われているよりはずっとむづかしいと思います。しかし私たち(私に起こったことですが)はシステム開発の途中で突然、ユーザは複数のConversationを同時に行うことが出来るようにシステムに求めていることを思いついたのです。同時に行われているそれぞれのConversationを分離するメカニズムを開発し、ユーザがブラウザのウィンドウを閉じたり、ブラウザのタブがアクティブにされないなどでConversationの状態が破棄されたことを明確にすることによってフェイルセーフ機能を盛込みます。


　こちらの方が良い方法です。


SeamはConversation Contextという構成を導入しています。これはContextに安全にConvarsationの状態を保存出き、明確なライフサイクルもつことを確実にします。より良いことに、Conversation Contextがユーザが現在作業しているデータを自然にキャッシュとしているため、DatabaseとApplication Server間でひっきりなしにDataを送ったり受取ったりする必要がありません。


　通常Conversation Contextに保存しているコンポーネントはステートフルなSessionBeanです(もちろんEntityBeanもJavaBeanもConvaersation Context内に保存できます)。JavaコミュニティにはステートフルSessionBeanが拡張性を犠牲にすると言う言い伝えがあります。これは1998年にWebFoobar 1.0がリリースされた頃は真実だったかもしれません。しかし今は違います。例えばJBoss 4.0のようなアプリケーションサーバであればステートフルSessionBeanの状態を複製する洗練されたメカニズムを持っています(例えばJBoss EJB3コンテナは粒度の細かいレプリケーションを行い、それらのBeanの属性値が変更された場合に複製されます)。なぜステートフルBeanは非効率なのかという古くからの議論はHttpSessionに対するものと同じです、状態をビジネス層のステートフルSessionBeanからWebセッションへ移行することはパフォーマンスを上げるための方向を信じれない方へ向かわせます。ステートフルBeanを間違った使い方をしたり、間違ったものをそれらに使ったりして拡張性のないアプリケーションを書くことは可能です。しかしそれらを決して使わないと言う意味ではありません。Seamは安全な使用モデルへあなたを導きます。ようこそ2005年へ。


　大げさに言うのはもう止してチュートリアルへ戻りましょう。


さあ、サンプルアプリケーションBookingでConversationに関する永続性データを自然にキャッシュとして用いるConversationスコープなステートフルSessionBeanをどのように使っているかみてみましょう。下記のコード(省略してますのでオリジナルを見てください。)は少々長いです。しかし、Conversationのいろいろな段階を実装したスクリプト化したアクションのリストだと考えると非常に理解し易いでしょう。物語だと思ってクラスを上から下へ読んで下さい。