グローバル変数、ローカル変数、そしてSeam
昔々、初期のBasic言語には「ローカル変数」というものが無く、そこで定義する変数はすべてグローバル変数でした。サブルーチン内で誤って変更してはならないグローバル変数と同じ変数名をテンポラリ変数として使うと痛い目に会いました。プログラムの規模が大きくなると、このような事故は起こりやすく、また、その原因を突き止めるために長い時間を要しました。
ローカル変数。メソッド内で定義された変数はグローバル変数とは別の領域に割付けられ、メソッド終了後には自動的に消え去る。スタックフレームに割付けられた、その変数は、メソッド内という「スコープ」によって生存期間が制御され、グローバルな変数とのコンフリクトという問題を解決しました。
話を現代のWebアプリケーションへ移しますと、Servlet/JSPのApplicationスコープ上の変数はグローバル変数、Requestスコープ上の変数はローカル変数に相当するでしょう。しかし、Webアプリケーションの場合、サーバ側に状態を保持するために、最も頻繁に使うのは、これらのスコープの間に相当するSessionスコープです。ここで登場するのがHTTPSessionです。
HTTPSessionへ登録されたオブジェクトはSessionスコープに登録されるわけですが、実際の処理（例：ショッピングカート）では、Sessionの生存期間に比べ、そこで使用されるオブジェクトの寿命は短い。同じセッション内でさまざまな処理をしたいわけですし、その処理に応じて使用するオブジェクトは異なりますから、当然、Sessionの生存期間というのは個々の処理に比べれば長すぎるのです。
つまり、WebアプリケーションにおけるSessionスコープというのは、グローバル変数が抱えていたのと同じ問題、すなわち、アプリケーションが必要とする適切な変数スコープと変数のライフサイクルの自動管理を提供できていないという問題を抱えているのだと思います。本当はSessionスコープより、粒度の低い、個々の処理に応じたスコープがあればもっと便利です。
Seamでは、ConversationスコープというSessionスコープより細かなスコープを提供してくれます。このスコープにバインドされたオブジェクトは、スコープが終了すると自動的に解放されますし、アクセススレッドごとに別々のメモリ領域（Conversationコンテキスト）が提供されるので、スレッド間で同じ変数に誤ってアクセスしてしまうという変数の衝突も回避されます。
ですから、Seamは、プログラミング言語にローカル変数が導入されたのと同じくらいのインパクトがあるし、Webアプリケーション作成を簡単にしてくれると信じています。サーバ上に状態を持つ。状態にはアプリケーション用途に応じたスコープあって、Webアプリケーションプログラマはスコープ内に集中してコーディングできる。だから、昔のBasicで起こったようなグローバル変数の衝突は、もう起こらない。
SeamはWebアプリケーションによりプログラマ寄りのスコープを導入しました。あとはWebアプリケーションプログラマがそれを使って設計するだけです。プログラマは必要最小限な狭いスコープでプログラムを組む。これが明らかな原則です。ローカル変数が使えるのに不必要な局面でグローバル変数を使うべきではありません。スコープ内で処理するコード(ビジネスロジック）はオブジェクトにカプセル化する。これもOO的には明らかでしょう。もともとのEJB仕様のSession Beanの目的はまさにソレです。
Seamを使ったWebアプリケーション開発では、コンポーネントがバインドされるスコープを意識する必要があります。これが難しい、と考えるのは早計のような気もします。だって、アプリケーションを組む人は、そのコンポーネントが使われる業務上の文脈(コンテキスト）を知っているはずでしょ。サーバ上で状態を保持するのは明らかにコストがかかります。Seamは、そのコストをどう扱うかという手段を設計に委ねていると思うのです。
その設計をどうするか、それをサポートするツールとしては何が必要か。もっと便利なスコープはないものか。そんなことを考えると、その先に広がる手付かずの領域が感じさせられます。JBossの開発者が生き生きとSeamの開発に取り組み、ユーザからはPositiveに受け入れられている。そこにはJava EEの未来への希望が感じられるからだと思います。
