JSF と EJB 3.0 の 2 つは Java EE 5 の最良の新機能です。 EJB3 はサーバー側の機能や永続ロジックに対するまったく新しいコンポーネントモデルとなります。 一方、 JSF はプレゼンテーション層に対して優れたコンポーネントモデルとなります。 残念ながら、 どちらのコンポーネントモデルも単独ではコンピュータの問題のすべてを解決することはできません。 実際に、 JSF と EJB3 は併用した場合に最も効果的に動作します。 しかしながら、 Java EE 5 の仕様はこの 2 つのコンポーネントモデルを統合する標準の方法を提供していません。 幸い、 両モデルの開発者はこの状況を予感し、 他のソリューションの拡張や統合を可能にする標準の拡張ポイントを提供してくれていました。

Seam は JSF と EJB3 のコンポーネントモデルを統一し、 接着剤としてのコードを取り除き開発者がビジネス関連の問題により重点をおけるようにしてくれています。

Seam は、 ICEfaces および Ajax4JSF という JSF ベースのオープンソースな AJAX ソリューションをサポートしています。 これらのソリューションにより、 JavaScript コードを記述することなくユーザーインターフェースに AJAX 機能を追加することができるようになります。

また、 Seam は EJB3 コンポーネントに対して組み込みの JavaScript リモーティング層を提供します。 これにより、 中間のアクション層を必要とすることなく、 AJAX クライアントは簡単にサーバ側のコンポーネントを呼び出して JMS topic をサブスクライブすることができるようになります。

いずれの方法もうまく動作しない場合、 それは多くの並列同期の微細な AJAX リクエストがサーバー側で安全且つ効率的に処理される Seam のビルトイン並行処理状態管理ではないはずです。

オプションで、 Seam は jBPM を使って透過的なビジネスプロセス管理を統合します。 jBPM と Seam を使った複雑なワークフローの実装ががいかに容易であるか信じられないほどです。

Seam はまた、 同じ手段でプレゼンテーション層の対話フローの定義をも可能にします。

JSF はプレゼンテーション層に対して信じられないほど豊富なイベントモデルを提供しています。 Seam は全く同じイベント処理メカニズムを使って jBPM のビジネスプロセス関連のイベントを公開し、 Seam 均一コンポーネントモデルに対して一貫したイベントモデルを提供することでこのモデルの機能を拡張しています。

Seam は一貫したコンポーネントモデルを提供します。 長期のビジネスプロセスから単一の WEB リクエストに至るまで、 いずれのコンテキストに関連付けられた状態でも Seam コンポーネントをステートフルとすることが可能です。

Seam では、 プレゼンテーション層のコンポーネントとビジネスロジックのコンポーネントの区別はありません。 EJB であれば、「どこでも」 Seam アプリケーションを書くことが可能です。 EJB は細かな調整ができず、 作成に苦労する小回りのきかないオブジェクトだと考えていた人にとっては驚きとして映るかもしれません。 しかし、 開発者の観点から見ると EJB 3.0 はその EJB としての性質を完全に変化させています。 EJB は微細な調整が可能なオブジェクトになり、 アノテーション付き Java Bean と同様に簡単になりました。 Seam でさえ JSF のアクションリスナとしてセッション Bean の使用を推奨しています。

単なる Java EE あるいは J2EE コンポーネントとは異なり、 Seam コンポーネントは WEB リクエストに関連した状態と、 トランザクション的なリソースに維持された状態とに同時にアクセスすることも可能です (メソッドパラメータを使って手作業で WEB リクエストの状態を伝播させる必要なく）。 昔なじみの J2EE プラットフォームにより必要とされたアプリケーションの階層化は良いことだと反対される方もいらっしゃるかもしれません。 Seam を使って同等の階層アーキテクチャを作成しても構いません。 違いは、 あなたが、 独自のアプリケーションを設計し、 どの層がどのように相互的に働くかを決定するということです。

EJB 2.x. 以降の宣言的トランザクション管理や、 J2EE の宣言的セキュリティの概念には既に慣れてきていいます。 EJB 3.0 は宣言的永続コンテキスト管理も導入しています。 コンテキストが終了するときに必要なすべてのクリーンアップが行われることは保証される一方、 特定のコンテキストと関連する状態を管理する上で広範囲に渡る問題があります。 次に 3 つの例を示します。 Seam は、宣言的状態管理の概念をさらに広範囲に取り入れ、 それをアプリケーションの状態にも応用しています。 従来、 J2EE のアプリケーションは必ずと言っていいほどサーブレットセッションとリクエスト属性を取得し設定することにより手動で状態管理を実装しています。 状態管理を行うためのこの手段は、 アプリケーションがセッション属性のクリーンアップに失敗した場合やマルチウィンドウアプリケーションで異なるワークフローに関連付けられたセッションデータ同士が衝突する場合に多くのバグやメモリリークを生む源となります。 Seam にはほぼ完全にこのクラスのバグを解消する可能性が備わっています。

宣言的なアプリケーションの状態管理は Seam で定義されるコンテキストモデルの豊富さにより実現されます。 Seam は、 サーブレット仕様 — request、 session、 application — で定義されるコンテキストモデルに、 ビジネスロジック的により有意義である 2 つの新たなコンテキスト — 対話とビジネスプロセス — を加えることで機能拡張しました。

制御の反転あるいは依存性のインジェクションの概念は JSF や EJB3 だけでなく、 多くのいわゆる「軽量コンテナ」にも存在します。 これらのコンテナのほとんどがステートレスサービスを実装するコンポーネントのインジェクションを重視しています。 ステートフルなコンポーネントのインジェクションがサポートされる場合であっても (JSF のように)、 ステートフルなコンポーネントのスコープは十分な柔軟性を持って定義できないため、 現実的にはアプリケーションの状態を扱うには役に立ちま せん。

バイジェクションは、 動的 (dynamic)、 コンテキスト依存 (contextual)、 双方向的 (bidirectional) という点において IoC とは異なります。 コンテキスト上の変数 (現在のスレッドと結びついた各種コンテキスト中の名前) をコンポーネントの属性の別名として対応させる機構と考えることができます。 バイジェクションはコンテナによるステートフルなコンポーネントの自動アセンブリを可能にします。 コンポーネントの属性を設定するだけで、 安全かつ容易にコンテキスト変数の値を操作することさえ可能になります。

オプションで、 Seam アプリケーションはワークスペース管理機能を利用することも可能で、 ユーザは 1 つのブラウザウィンドウの中で異なる対話(ワークスペース)間を自由に行き来することができます。 Seam は正確なマルチウィンドウ操作だけでなく、 シングルウィンドウ内でマルチウィンドウのような操作も行うことができます。

EJB 3.0 は、 宣言的な形式でコンテナに情報を提供する最も簡単な方法としてアノテーションと「例外による設定」を採用しています。 残念ながら、 JSF はまだ冗長な XML 設定ファイルに大きく依存しています。 Seam は、 EJB 3.0 によって提供されるアノテーションに宣言的状態管理および宣言的コンテキスト区分用のアノテーション一式を提供することにより機能拡張しています。 これにより、 うっとうしい JSF 管理の Bean 宣言を取り除き、 必要とされる XML を減少させ、本当に XML で定義すべき情報 (JSF ナビゲーション規則) だけになるようにします。

POJO である Seam コンポーネントはそもそもユニットテストが可能です。 しかし、 複雑なアプリケーションの場合はユニットテストだけでは不十分になります。 以前から、 統合テストは Java の WEB アプリケーションにとって煩雑でやっかいな作業となっていました。 このため、 Seam はフレームワークの中核機能として Seam アプリケーションのテスト容易性を提供しています。 ユーザーとのやりとり全体を再生し、 ビュー (JSP や Facelets ページ) 以外のシステムの全コンポーネントを作動させる JUnit テストや TestNG テストを容易に記述することができます。 Seam よって自動的に EJB コンポーネントが JBoss の組み込み可能 EJB3 コンテナにデプロイされる IDE の内部で、 これらのテストを直接実行することができます。

Seam は、EJB 3.0 をサポートするアプリケーションサーバーならいずれでも動作します。 新しい JBoss 組み込み可能 EJB3 コンテナを利用することで、 Tomcat のようなサーブレットコンテナや J2EE アプリケーションサーバーでも Seam を使用することができます。

ただし、 すべての人が EJB 3.0 に移行準備が整っているわけではないことも認識しています。 このため、 しばらくの間、 プレゼンテーションに JSF、永続に Hibernate (またはプレーン JDBC)、 アプリケーションロジックに JavaBeans を使用するアプリケーションに対しては Seam をフレームワークとして使用することができます。 これで、 EJB 3.0 への移行準備が整った時点での以降が簡単になります。