Fusayuki Minamoto
miki.****@nifty*****
2006年 4月 23日 (日) 23:52:24 JST
>結局、Container => Context => Componentの順で管理構成されているものと >理解しました。 私は、Contextって、エンタープライズJavaの根幹にかかわるコンセプトだと 思っています。 JBoss Inc.のJBoss Seamのページを見ると次のように書いてあります。 declarative application state management for POJO components この「宣言的に」にアプリケーションのステートを管理するというところが、 宣言的にトランザクションを管理したり、宣言的にセキュリティを管理する というEJBの思想にマッチします。 EJBコンテナはコンポーネント間の通信にインターセプトとしてサービスを 提供します。コンポーネントはコンテナに対して宣言という形で制御情報 を提供しますが、コンテナはコンポーネントの背後でサービスを実行します。 Seamもそうですよね。 EJB上でContextのスコープや@In, @outを「宣言」することで、EJB間を Contextを介して間接的に関連づけます。そのときに@In, @Outを機能させる ためにEJB3のインターセプタが使われています。コンテナが背後で頑張って コンポーネント間のデータの伝達やライフサイクル管理をしているわけです。 Miki >おおさわです。 > >皆本さん、貴重なアドバイスありがとうございます。 > >アドバイスのおかげでだいぶ体に馴染んできたように思います。 >自分なりに混乱した（している）原因をまとめてみました。 > >１）ServletコンテナでのScopeというコンセプト(?)は、Seamにおいては > はContextの部分集合として説明されていた。 > > #Sessionスコープという言葉は聞くが、SessionContextは聞いたことが > なかったため、最初、馴染めかった。 > ・SeamではRequestスコープに相当するだろうものはEventコンテキストと > 一般化された名称になっています。 > ・SeamではStatefulが当たり前のものとして設計されています。 > (SpringはStatelessなものの対照としてしばしば登場します。) > >２）EJBではコンテナではContextでは、これらはインスタンス変数とて > コンテナとお話しするための単なる道具程度にしか考えていなかった。 > いつもお世話になっているのはコンテナだと思い込みがあったのですが > Contextにもお世話になっていたものと再認識します。 > >３）SeamではStatefulが前提となっており、Servlet、EJBなどのコンテナの > 区別の意識がありません。 > >結局、Container => Context => Componentの順で管理構成されているものと >理解しました。 > >WebinarやGavin Kingのブログも見てみます。 > > > > >Fusayuki Minamoto wrote: >> SeamのContextについては、WebinarやGavin Kingのブログが参考になります。 >> これらの方がリファレンスマニュアルより、Seamを生み出した背景やメリット >> が明確に書いてあるからです。 >> >> JBoss Seam Webinar: >> http://www.jboss.com/services/online_education >> >> The Seam Component Model: >> http://blog.hibernate.org/cgi-bin/blosxom.cgi/Gavin%20King/components.html >> >> >> 例えば、このブログではstatefulのコンポーネントのinjectionのサポート >> について次のように言及しています。 >> >> At this time, most other IoC frameworks have the same two limitations, >> and this is perfectly defensible in the case of something like Spring >> where the components being injected are understood to be stateless, and >> hence any two instances of a component are interchangeable. It's not >> so good if components are stateful, as they are in JSF. >> >> statefulということは、同じクラスのインスタンスであっても、内容は異なる >> わけですから、同じクラスのインスタンスであればどれでも"interchangeable" >> ではありません。そこで、個々のインスタンスに名前をつけてContextで管理 >> する必要がでてきます。そうして、ContextへのIn, Outはコンテナが自動的 >> に、ダイナミックに、関連コンポーネントに反映させます。 >> >> このブログでは最後に3つのウリでまとめています。 >> >> First, it allows us to bind stateful components, expecially entity beans, d ire >> ctly to the webpage. >> (略) >> Second, it means that the container (Seam) can guarantee cleanup of state f rom >> ended or abandoned conversations. >> (略) >> Finally, the model allows stateful components to interact in a relatively l oos >> ly coupled way. >> (略) >> >> 最後の、コンポーネント間を疎結合し、それぞれが互いのライフサイクルを >> 意識しなくて良いというのは便利ですね。 >> >> Miki >> >>> Java EEでは、 >>> >>> Transaction Context >>> Security Context >>> Persistence Context >>> >>> などの用語があります。 >>> 他にも、EJBのSessionContextのようなのもありますね。 >>> >>> これらのContextに共通するのは、 >>> >>> (1) メッセージの呼び出し間で、メッセージパラメタとして明示的に渡す >>> のではなく、システムによってコンポーネント間で伝達される情報です。 >>> (2) Contextのライフサイクルはコンテナによって管理されます。 >>> >>> SeamのContextは、おそらく、コンポーネント間のやり取り >>> をまたがって参照可能な情報です(そう、会話情報です）。 >>> >>> そのスコープはSeam Contextの種類によって規定され、その生滅は >>> スコープに応じてコンテナによって管理されるのでしょう。 >>> >>> だから、Seam Contextも、上の(1),(2)を満たしていると思います。 >>> >>> Miki ---- 皆本 房幸 <miki.****@nifty*****> http://d.hatena.ne.jp/neverbird/about
