 |
||||||||
 |
||||||||
|
||||||||
| 1 2 3 次のページ | ||||||||
|
||||||||
| 進化を続けるJBossの基盤プロダクト群 | ||||||||
|
JBossは買収という節目を迎えたものの、「JBoss World Las Vegas 2006」では業界の潮流に乗りながらさらに進展を続けていることを前回紹介した。前回に引き続き、各セッションを概説していく。 |
||||||||
| JBoss Seam | ||||||||
|
このセッションでは、JBossの新しいアプリケーションフレームワークである「JBoss Seam」の紹介がThomas Heute氏とGavin King氏（両氏ともにJBoss/Red Hat Inc.）によって行われた。 Java EE 5では、フロントエンドのAPIであるJSFとバックエンドのAPIであるEJB（3.0）を中心として、従来（J2EE 1.4以前）の開発スタイルの大幅な刷新がはかられている。これらの新しいAPIを利用することにより、コンポーネントの大部分を簡素なコード（POJO、アノテーション）で記述することができ、またDIやAOPによってコンポーネント間の複雑な連携を解消することができるようになる。また、ほぼすべてのコンポーネントにおいて厳密な単体テストを実施することも可能となる。 ただし改善の余地もある。JSFのマネージドBeanやEJBのステートレスセッションBeanは、生産性の面では冗長なコンポーネントであり、RIAやSOAといった新しいアーキテクチャにも適しているとはいえない。また、EJBのステートフルセッションBeanは、フェイルオーバーの実現に多くの（開発／運用両面での）コストを要するためスケーラビリティに劣るといえる。 ;これらの問題を解決するのが、JBoss Seamの中核コンセプトである「Contextual components」である。Contextual componentsでは、ステートフルなコンポーネントの状態を「Event／Page／Conversation／Session／Business process／Application」という6つの「コンテキスト」で管理することができる。これにより、複数のウィンドウを持つリッチクライアントや長期間状態を保持する必要のあるBPMエンジンに適応することができるようになる。 また、コンテキスト上のコンポーネントはアノテーションで付与される「コンポーネント名」に関連付けて管理される。これにより、例えばJSFページから直接ステートフルセッションBeanを呼び出せるようになり、冗長なコードを削減することができる。さらに、これらのコンポーネントは後述する「JBoss Cache」と連動することで、簡素なアーキテクチャによるクラスタリング環境を構築することも可能となる。  ステートレスなBeanを使用すべきか？ Sun Microsystems社が主導するエンタープライズアプリケーションの標準仕様（Java EE／J2EE）では、往々にしてフロントエンドとバックエンドのアーキテクチャが噛み合わず、結果としてアーキテクチャの複雑化やXMLの氾濫を招くことが多いが、JBoss Seamのようなアプリケーション全域をカバーするようなフレームワークを利用することで（内実はJava EEの実装であるが）、そのような問題を緩和することができる。 「コンテキスト」という概念は、前述のとおりRIAやSOAといったJBossが拡充を進めているアーキテクチャへの適応を狙うものであり、Java EEのSeam（繋ぎ目）だけではなく、JBossが基盤プロダクト群の統合をねらうJEMS（JBoss Enterprise Middleware Suite）の重要な連結点となるだろう。
参考
JBoss Seam（http://labs.jboss.com/portal/jbossseam） |
||||||||
|
1 2 3 次のページ |
||||||||
|
|
||||||||
|
|
||||||||
|
||||||||
|
|
||||||||
|
||||||||
-
人気記事ランキング
-
-
連載
