JSFとEJBといえば、JavaEEの二大基盤技術
といっても過言ではないでしょう。 そして
当然ながらそれら両者を如何にスムースに
繋げるか？といったことは今後のWEBアプリ
ケーション開発のキーポイントの一つと
言えるのではないかと思います。
JSFはUIコンポーネントフレームワークと
考えられがちですが、実際にはそれに加え
MVCで言うところのコントローラに相当する
フレームワークも持っていると捉えています。
Backing Bean内もしくは他のクラスにアクション
やイベントハンドラを実装することもできますし
それらが呼び出されるタイミングを指定することも
できます。
ですが、複数のBacking Bean同士を参照させると
いったことになると、それらのコーディングは自前
でやらないといけません。ある程度複雑なアプリ
ケーションになれば、異なるBaking Beanが互いを
参照するようなことは十分考えられますが、慎重に
設計しないとゴチャゴチャになってしまう恐れが
あります。つまり、アプリケーション内の一連の
流れやデータ参照について複数のBacking Beanを
網羅的に管理する「コンテキストマネジメント」
みたいなものがあったらいいなと思っています。
EJBの方へ目を転じると「POJO化」はEJBに限らず
大きな流れの一つです。Baking Beanもある意味
strutsにおけるActionクラスを一般化させてPOJO
適なものにしたと捉えることもできるかと思います。
そうなると、EJBの各種BeanをBacking Beanとして
しかもPOJO的にシンプルに扱えたらいいな、という
考えも自然と出てきます。
上に挙げた二つのポイント
・複数のBacking Beanを管理できるコンテキスト
マネジメントのような仕組みが欲しい
・JSFのBacking BeanとEJBの各種BeanをPOJOの
手軽さを失わないまま、手軽に繋ぐ仕組みが欲しい
を実現してくれそうなフレームワークとして、ちょっと
気になっているものの一つが「JBOSS Seam」です。
http://www.jboss.com/products/seam
Backing Bean間の参照をDI的に宣言できたり、Baking Bean
と同じような作法でEJBの各種Beanを使えるみたいです。
複雑なビジネスロジックの随所でBacking Beanがコールされる
となると、JSFとEJBが繋がっている下にBPM的なフレームワーク
がさらに必要になってくるのではないかと思いますが、Seamでは
この部分はjBPMがカバーしてくれるようです。BPMが必要になる
レベルの複雑なコンテキストについてもきちんと考えている点は
評価できると思います。
SeamはJBOSSによるオープンソースフレームワークの一つ
ということになりますが、今後JavaEEの仕様としてJSFと
EJBの「繋ぎ」の部分はどう詰められていくのか？という
今後の方向性については是非確かめておきたいところです。
もちろんサービス単位での「繋ぎ」であればJBIの出番ですが
単一のAPサーバー内でのローカルな「繋ぎ」における仕様が
あってもいいかなという気もします。もっとも、サービス間
であれ、ローカルであれ、それらを全て抽象化して単一的に
扱えるというのがJBIの基本的な考え方でもあるので、上記
の問いに対する答えが実際のところJBIなのかも知れません。
その辺りについてもJavaOneTokyoでは是非キーマンに尋ねて
みたいと思います。
