kagamihogeの日記

kagamihogeの日記です。

ナイトセミナー「JBossセミナー・シリーズ」第2回

ナイトセミナー「JBossセミナー・シリーズ」第2回 に行ってきました。ちなみに俺は JBoss 関連のテクノロジーはマッタクさわったことがありません。なんとなく行きたくなったので行ってきただけです、ハイ。

なので、下記のレポートは正確性に欠けていたりトチ狂った記述を書いている可能性が非常に高いことに注意してください。

Open source Middleware Tokyo JBoss User Group

JBoss コミュニティの歴史と活動についてカンタンな紹介。英語だったんで自信がないけど、活発に活動してますよーと言ってたと思います。

JBoss Enterprise Middleware の概要。設計開発のツールの提供や、JBoss ESB なんかの SOA プラットフォームの提供、などなど色々やってますよ的な紹介。

将来的にどうしていくか、JBoss のエンタープライズのアーキテクチャはどういう方向性でいこうとしているのか、Roadmap 2009、の話。英語わっかんねーんでよくわかりませんでしたw

JBoss Seam

最近の情報として、今は JBoss Seam を始める良い機会だそうで。その理由として、Seam のマニュアルが翻訳される(2.1.0 ベース)、Eclipse ベースのツール(JBoss Tools 3.0 のリリースが間近)、Seam は将来的に Web Beans をさわる際の基礎として有用、という理由を挙げていました。

Seam とは何ぞや。一口に言うのは難しい代物。もともとの始まりは Gavin 氏の作成した Web アプリのフレームワーク。元々の目的は、エンタープライズ用の Javaオープンソースフレームワークを目指して開発が始まったものらしい。そこから発展して色んなフレームワークを統合する代物として進化してきたのが Seam らしい(よくわかっていない)

Seam の特徴。

  1. JSF/EJB3 のシームレスな統合。JSF から EL式で EJB コンポーネント操作、EJB インスタンスの自動作成・自動解放(ステートフルセッションBeanのインスタンスの寿命が勝手に出来て勝手に消滅とか)、JNDI の不要化。
  2. コンテキストによる「宣言的状態管理」 コンポーネントはコンテキスト上で管理。コンテキストってのは、Servlet でいうところのリクエストとかセッションみたいなスコープのような概念のこと。
  3. ステートフルアーキテクチャ で、1と2の機構によってコレを実現する。Seam のでかい特徴ってやっぱコレかねぇ。

Seam の機能と歴史。Seam 1 > Seam 2 > Seam 3(Web Beans)

なぜ Java EE プログラミングが大変か? JSFEJB の「つなぎ」を書くのがめんどい。EJBの生成や破棄なんかのインスタンス管理、JNDIルックアップ、トランザクション、セキュリティ、などなど。JSFJSFEJBEJB で独自に発展してるんで、そいつらをつなぎ合わせるコードを考えるのは非常にめんどい、という背景事情がある。

で、Seam による解。コンポーネントアノテーションでコンテキスト情報とかを付加することでその辺の「つなぎ」を Seam が勝手に処理してくれる。

Seam によるフレームワーク統合。最初は JSFEJB の統合だけだったんだけど、オモテ側は Web Servie や Wicket 、裏側も色々なものを使えるように進化。

ステートレス vs ステートフルの話。Seam の特徴は、DI もあるんだけどコンテキストによる状態管理も大きいですよ、的な話。

動的な依存性注入。たとえば、変数に @In のアノテーションつけとくと、コンテキストに応じて、特定のメソッド実行時にインスタンスを入れたり状態変化をやってくれたりする。

ふーむ。コンポーネントとコンテキストの関係を抑えるのが肝要なのかな? で、コンテキストはアノテーションで定義する。そんでもって、JBoss はどんなコンテキストを用意していて、どのアノテーションを定義したときどんな動作になるのか、ってとこらへんを知るのが重要っぽい感じ?

コンテキストを使う利点。コンテキストに応じた状態管理、コンポーネントのライフサイクル管理(スコープ終了時に勝手に破棄される・キャッシュ)。この辺のキャッシュ機構は O/R マッピングや AJAX と相性が良いんだとか。確かに、こういう風にサーバ側ステートフルならそうなるかもなぁ。

「JBoss Seam 2.1」の新機能と今後

JBoss 実際に使ってるわけじゃないんで、新機能はともかく今後についてはそこまで興味なかったり。なので、気になったとこらへんだけテキトーにメモ。

今んとこ Seam は 2.1 系が主流(でいいのかな?) 最新版は 2008/12/22 に出た 2.1.1。2.0 系と 2.1 系っていう大きな流れがあるようです。

2.1 で追加された機能の大まかな概要。ACL スタイルのパーミッション制御、Excel ベースで色んな情報のレポーティングを生成するモジュール、Seam-gen ていう自動生成系機能の強化(scaffold や Seasar でいうところの Dolten みたいな代物かな?プロジェクトの初期生成うんぬんいってたし)、Web アプリのフロントに JSF でなく Wicket のサポート、URL リライティング(PRG パターンというか URL をブックマーク可能にするアレ)、RESTful なアプリを作るためのサポート。

Seam 2.0.x 系の機能強化。Groovy 対応、Hot deploy サポート、JSF 依存の排除、JSF 1.2 のサポート、JBoss EL のサポート。開発そのもののサポートでは Maven 対応、non-EE でも(Java SE 環境でも)テストや実行ができるように改良。

JSR-299: Web Beans の現在のステータスと流れについて。俺はこの辺の流れゼンゼン追ってないんでアレだけど、正直言うとなぁんかややこしくて良くわからんというか……

OpenJDK

まず、Sun JDK と各ベンダ製 JDK の関係から。Sun からライセンスをもらって、各ベンダごとに必要な機能を付与した VM を開発、という構図。Sun の VM がいちばん汎用性が高くて、個々のベンダが開発してるやつは、GC 周りいじってたり、サーバ用途なんで Intel CPU に個別最適化をかけてみたりとか、IBM だと自前の AIX 用に最適化とか、HP だと HP-UX 用に最適化とか、Apple なんかはクライアント使用向けに最適化(してたらしい)とか。一重に JVM といっても結構個性あるのね。

OpenJDK。クローズドなバイナリコードを含まない、完全にオープンソースJDK。現在はすべて GPL べースのコードで構成。

注目のプロジェクトについていくつか。

JDK7 - Sun 主導で OpenJDK7/JDK7 はほぼ同じコード・ベースから始める計画があるのだとか。ただ、残念ながら SunJDK6 != OpenJDK6 だそうで。

ZERO - アセンブラ言語を取り除き、x86/sparc チップセット以外の環境でもビルド可能にするためのプロジェクト。

Shark - ZERO みたいなことをすると汎用性は高くなるけど遅くなるわけで。その処理速度の低下を補うためのプロジェクト。高速な JIT とか、LLVM とか。ただ、コイツはまだ概念段階のようで、詳しいことはまだあまり出てきてないらしい。

OpenJDK6 について。プラットフォーム的には、今の所 Ubuntu 8.04/8.10 Fedora 9/10 Redhat Enterprise Linux5.3 あたり。

Java オプションのチューニング。既存の SunJDK6 の知識はある程度使えるようなので、そっから入るのがオススメらしい。

OpenJDK6 トラブルシュート。

  • ハング - スローダウン。JavaVM のプロセスはあるのに動いてない(ようにみえる) 原因は Java プログラム側にあるので、様々な要因が考えられる。
  • ダウン - JavaVM ごと死ぬ。原因は JNI ライブラリ or JVM で、Java プログラム側でなく JVM か JNI ライブラリのバグで落ちるんだとか。ただ、この辺のトラブルシュートの方向性は SunJDK と同じでいいんだとか。

トラブルシュート(ハング) - スレッドダンプを取って解析。解説ツールとして「侍」が有名なんだとか。

トラブルシュート(ダウン) - JVM ログと Core ファイルを解析。