Seam は、エンタープライズ Java 向けのアプリケーションフレームワークです。以下のような原則に開発意欲を奮起 (インスパイア) されました:
- 一種類の "材料" (一貫したコンポーネントモデル)
Seam は、アプリケーションのすべてのビジネスロジックのために一貫したコンポーネントモデルを定義します。Seam コンポーネントは、明確に定義された数種類のコンテキストの一つに関係付けられた状態を持つステートフルなものであるかもしれません。これらのコンテキストには、長時間に渡って実行され永続化される ビジネスプロセスコンテキスト や、複数の Web リクエストに跨る一連のユーザインタラクション間で保持される 対話コンテキスト が含まれます。
Seam においては、プレゼンテーション層コンポーネントとビジネスロジック層コンポーネントとに区別はありません。アプリケーションを自分で工夫したどんなアーキテクチャにも則って階層化することができます。今日使用している煙突型(スタック型)フレームワークのいかなる組み合わせによっても要求される不自然な階層化構造に、アプリケーションロジックを詰め込むようなことは強制されません。
単純な Java EE あるいは J2EE コンポーネントと違って、Seam コンポーネントは、(メソッドパラメータによって Web リクエスト状態を手動で引き継ぐことがなくても) Web リクエストに関連した状態やトランザクションリソースに保持された状態に 同時に アクセスすることがあるかもしれません。古い J2EE プラットホームによって強制されたアプリケーションの階層化の方が良い方法だったと反論するかもしれません。そうです、何も Seam を利用して同等の階層化アーキテクチャを開発するのを止めたりはしません — 違いは、開発者 が自分自身のアプリケーションのアーキテクチャを設計できるようになり、階層はどうあるべきで、それらがどう連携して動作すべきかを決定するということなのです。
- JSF と EJB 3.0 の統合
JSF と EJB 3.0 は、Java EE 5 の最も素晴らしい2つの新機能です。EJB3 は、サーバサイドのビジネスロジックと永続化ロジックのための全く新しいコンポーネントモデルです。一方、JSF はプレゼンテーション層のための優れたコンポーネントモデルです。残念なことに、どちらのコンポーネントモデルも片方だけではすべてのコンピューティング問題を解決することはできません。その代わりに、JSF と EJB3 を一緒に使用すれば最も良く働かせることができます。しかし、Java EE 5 仕様では、2つのコンポーネントモデルを統合するための標準的な方法を提供していません。幸いにも、両方のモデルの策定者はこの状況を予見していて、モデルを拡張したり他のフレームワークと統合したりを可能にするための標準拡張ポイントを提供しています。
Seam は JSFと EJB3 のコンポーネントモデルを統一し、 コンポーネント間の接着剤としてのコード (glue code) を取り除き、開発者がビジネス関連の問題解決に重点を置けるようにしてくれます。
Seam アプリケーションでは、 "すべて"を EJB で記述することが可能です。EJB は粗粒度のいわゆる "重量 (heavyweight)" のオブジェクトであると考えるのに慣れている人にとっては、驚きかもしれません。しかし、EJB のバージョン 3.0 は、開発者の観点から完全にその性質を変えました。EJB は、細粒度のオブジェクトです — 単なるアノテーション付きの JavaBeans に過ぎないのです。Seam は、JSF アクションリスナとしてセッション Bean を使用することさえ奨励します!
一方で、もし現時点では EJB 3.0 を採用しない方を好めば、EJB 3.0 を使用する必要はありません。事実上はどんな Java クラスでも、Seam コンポーネントになることができます。さらに Seam は、EJB であろうとなかろうといかなるコンポーネントに対しても、"軽量 (lightweight)" コンテナに期待されるすべての機能を提供します。
- 統合 AJAX
Seamは、最も素晴らしいオープンソースの JSF ベース AJAX ソリューション: JBoss RichFaces と ICEfaces をサポートします。これらのソリューションは、一切 JavaScript コードを記述する必要なしで、ユーザインタフェースに AJAX 機能を追加させることができます。
もう一つの方法として、Seam は組み込みの JavaScript リモーティングレイヤを提供していて、中間のアクションレイヤを必要とせずに、クライアント側の JavaScript から非同期にコンポーネントと呼び出すことができます。サーバ側の JMS トピックをサブスクライブして、AJAX プッシュによってメッセージを受信することもできます。
これらのアプローチのどちらも、Seam の組み込みの並行処理制御や状態管理に対してのものではないので、それらの機能に対してはうまく動作しません。しかし、並列に実行される多くの細粒度の非同期の AJAX リクエストがサーバサイドで安全にそして効率的に処理されるということを保証します。
- 一級構成要素としてのビジネスプロセス
オプションとして、Seam は jBPM による透過的なビジネスプロセス管理を提供します。jBPM と Seam を利用した複雑なワークフロー、コラボレーション、タスク管理の実装がいかに簡単であるか信じられないことでしょう。
Seam は、jBPM がビジネスプロセス定義に使用するのと同じ言語 (jPDL) をプレゼンテーション層のページフローの定義にも利用することを可能にします。
JSFは、プレゼンテーション層のために信じられないほど豊富なイベントモデルを提供します。Seam の一貫したコンポーネントモデルに対して一貫したイベントモデルを提供することにより、Seam は全く同様のイベント処理メカニズムを jBPM のビジネスプロセス関連イベントにも適用するによってこのモデルを改良します。
- 宣言的な状態管理
EJB は初期の頃から、宣言的なトランザクション管理と宣言的なセキュリティのコンセプトを採用しています。EJB 3.0 では、宣言的な永続化コンテキスト管理さえも導入します。これら３つは、特定のコンテキストに関連付けられたより広範囲での状態管理の問題の例で、コンテキストが終わるときには、それらはすべての確実に破棄することが必要となります。Seamは、宣言的な状態管理のコンセプトをはるかに広く捉えて、アプリケーション状態にもそれを適用します。伝統的にJ2EE アプリケーションでは、サーブレットセッションとリクエスト属性を 保存 (set) そして取得 (get) することによって、状態管理を手動で実装します。状態管理に対するこの手法は、アプリケーションがセッション属性をきれいにし損ねたり、あるいは異なるワークフローに関連したセッションデータが複数ウィンドウのアプリケーションで衝突したりしたときに、多くのバグとメモリリークの発生源となります。Seam には、この種類のバグをほとんど完全に削除できる潜在能力があります。
宣言的なアプリケーションの状態管理は、Seam によって定義された豊富なコンテキストモデルによって可能となります。Seamは、サーブレット仕様によって定義されたコンテキストモデル — リクエスト、セッション、アプリケーション— を拡張して、ビジネスロジックの観点からより意味のある２つの新しいコンテキスト — 対話とビジネスプロセス — を提供します。
対話コンテキストを利用し始めると、いかに多くのことがより簡単になるか驚かされるでしょう。Hibernate あるいは JPA のようにな ORM ソリューションで遅延関連フェッチを利用して、障害を経験したことがありませんか? Seam の対話スコープ永続化コンテキストを使用すると、めったに
LazyInitializationExceptionを見ることがなくなるということになります。リフレッシュボタンで問題が発生したことがありませんか? 戻るボタンで問題が発生したことがありません? 送信フォームの二重送信で問題が発生したことがありません? post-then-redirect を跨ったメッセージ引継ぎで問題が発生したことがありません? Seam の対話管理は、これらの問題を個別に考える必要なしに解決します。これらはすべて、Web の最も初期の頃以来蔓延している中途半端な状態管理アーキテクチャが原因の症状なのです。- バイジェクション
制御の反転 (IoC: Inversion of Control) あるいは 依存性注入 (DI: Dependency Injection) の概念は、多くのいわゆる"軽量コンテナ (lightweight container)"と同様に、JSF と EJB3 の両方に存在します。これらのコンテナのほとんどは、ステートレスなサービス を実装するコンポーネントのインジェクションに力点が置かれています。たとえステートフルなコンポーネントのインジェクションがサポートされるとていたとしても (例えば JSF において)、アプリケーション状態を扱う場合においては事実上役に立ちません。なぜならば、ステートフルなコンポーネントのスコープが十分な柔軟性を持って定義されていないので、より広いスコープに属しているコンポーネントをより狭いスコープに属するコンポーネントへインジェクションすることができないからです。
バイジェクション (Bijection) は、それが動的であり、コンテキスト依存であり、そして双方向的であるという点で IoC とは異なります。コンテキスト上の変数(現在のスレッドに括り付けられた様々なコンテキストでの名前)をコンポーネントの属性にエイリアスするのためのメカニズムだと考えることができます。バイジェクションは、コンテナによるステートフルなコンポーネントの自動アセンブリを可能にします。それは、ちょうどコンポーネントの属性に割り当てることによって、コンポーネントが安全にそして簡単にコンテキスト変数の値を操作することをまさに可能にします。
- ワークスペース管理と複数ウィンドウアクセス
Seam アプリケーションは、それぞれが別々の安全に分離された対話に関連付けられた複数のブラウザタブ間を、ユーザが自由にスイッチすることを可能にします。アプリケーションは、さらにワークスペース管理を利用して、一つのブラウザタブ内で対話 (ワークスペース) の間をユーザがスイッチすることも可能にします。Seam は、正しい複数ウィンドウの操作のみを提供するのはでなく、一つのウィンドウ内での複数ウィンドウ風の操作も提供するのです!
- XMLよりもアノテーションの方が好き
伝統的にJavaコミュニティは、どのような種類のメタ情報をコンフィグレーションとして考慮すべきかについて深い混乱の状態にいました。J2EE と人気がある "軽量の (lightweight)"コンテナは、XML ベースのデプロイメントディスクリプタを提供し、システムの異なるデプロイメントの間で本当にコンフィグレーションと、Java では簡単に表されることができない宣言との両方をメタ情報として提供しました。Java 5 のアノテーションがこのすべてを変えました。
EJB 3.0 は、 宣言的な形式でコンテナに情報を提供する最も簡単な方法としてアノテーションと"例外による設定"を採用しています。 残念ながら、 JSF はまだ冗長な XML 設定ファイルに大きく依存しています。 Seam は、 EJB 3.0 によって提供されるアノテーションに宣言的状態管理および宣言的コンテキスト区分用のアノテーション一式を提供することにより機能拡張しています。 これにより、 うっとうしい JSF 管理の Bean 宣言を取り除き、 必要とされる XML を減少させ、本当に XML で定義すべき情報 (JSF ナビゲーション規則) だけになるようにします。
- 結合テストを簡単に
Seam コンポーネントは、単純な Java クラスであって、本来ユニットテストで十分テストできるものです。しかし複雑なアプリケーションでは、ユニットテストだけは不十分です。伝統的にJava の Web アプリケーションにおいては、結合テストは繁雑で困難な作業でした。それゆえに、Seam はフレームワークのコア機能として、Seam アプリケーションのテスト機能を提供します。システムのすべてのコンポーネントをビュー (JSP ページまたは Facelets ページ)から切り離して動作させることにより、ユーザとのすべての相互作用を再現する JUnit あるいは TestNG のテストを簡単に記述することができます。これらのテストを直接 IDE の内部で実行することができます。そこでは、Seam が 組み込み型 JBoss を利用して EJB コンポーネントを自動的にデプロイします。
- 仕様は完璧ではない
Java EEの最新の実装は素晴らしいと思います。しかし、それが決して完全ではないということも知っています。どの仕様にも欠点はあるので(例えば、GET リクエストにおける JSF ライフサイクルの制限)、Seam はそれを修正します。Seam の作者らは、JCP エキスパートグループと一緒に活動していて、それらの修正が標準仕様の次の改訂版に確実に反映されるようにしています。
- WebアプリケーションにはHTMLページを供給すること以上の役割がある
今日の Web フレームワークは、あまりにも小さく考え過ぎます。Web フレームワークは、フォームからユーザ入力を取り出し、Java のオブジェクトへ代入します。そしてそのままにしておきます。本当に完全な Web アプリケーションフレームワークは、永続化、並行処理、非同期処理、状態管理、セキュリティ、Eメール、メッセージング、PDFとチャートの生成、ワークフロー、してwiki テキスト、Web サービス、キャッシングその他多数の問題を処理すべきです。一旦 Seam を使用してみれば、いかに多くの問題がより簡単になることに驚くでしょう...
Seamは、永続化のために JPA や Hibernate3 を統合します。軽量な非同期処理のためには EJB タイマサービスや Quartz、ワークフローのために jBPM、ビジネスルールのために JBoss Rules、Eメールのために Meldware Mail、 フルテキスト検索のために Hibernate Search や Lucene、メッセージングのために JMS、ページフラグメントキャッシュのために JBoss Cache を統合します。Seam は、JAAS とJBoss Rules を連携した革新的なルールベースのセキュリティーフレームワーク層を提供します。さらに、PDF レンダリングやメール送信、チャート、wiki テキスト のための JSF タグライブラリもあります。Seam コンポーネントは、Web サービスとして同期的に呼び出されるかもしれません。クライアント側の JavaScript あるいは Google Web Toolkit 、またもちろん直接 JSF から非同期的に呼び出されるかもしれません。
- さあ、はじめましょう !
Seam は、どの Java EE アプリケーションサーバでも動作します。さらに、Tomcat でさえも動作します。もしあなたの環境が EJB 3.0 をサポートしているのであれば、すばらしい完璧です！もしサポートしていなくても、問題ありません。永続化のための JPA あるいは Hibernate3 と Seam の組み込みトランザクション管理を使用することができます。あるいは、Tomcat に組み込み型 JBoss をデプロイして、EJB 3.0 に対するフルサポートを受けることもできます。
Seam と JSF と EJB3 の組み合わせが Java で複雑な Web アプリケーションを記述する最もシンプルな方法であることが明らかになります。あなたは、どのように小さなコードが必要とされるかと信じないでしょう!
Seam へコントリビュートする方法を知るには SeamFramework.org にアクセスしてください!