GlassFish勉強会に参加してきました

会社帰りにオラクル青山で行われたGlassFish勉強会に参加してきました。

春先からJPAを使うようになり、JavaEEに関する様々な情報に触れていたのですが、今日は、断片化していた知識の隙間を埋めるような情報が多くあり、非常に有意義な勉強会でした。


以下、簡単なまとめと、思ったこと。

@den2snさん「GlassFishを４年間使ってきて思う事」

  • GlassFishV3の良いところ
    • JavaEEの参照実装
    • NetBeansとの相性が良い
    • asadminコマンドで何でもできる
      • 本番環境など、GUIが使えないところで有用
  • V3を使う動機
    • JAX-RSを使いたい
      • JSFがけっこうメモリを食うので
    • CDIを使いたい
    • GrizzlyでWebSocketが使える
      • JavaEE7(GlassFishV4)において標準化される #Project Avatarかな？
  • V4

今まで、管理コンソールからあーしてこーしてと、環境構築手順書を書いていたけど、asadminコマンドを使って設定スクリプトを書いておいた方がスマートだったな、と気づきました。

FullProfileより起動が速いWebProfileを使わない理由は、という質問への答えで、APサーバは容易に置き換えられないので、WebProfileにない機能を使いたくなった時のために、FullProfileにしておきたい、という意見が。その発想はなかったなぁ。

@megascusさん「JavaEE6 First Application」

  • NetBeansのコードジェネレートを用いて、簡単なCRUDアプリのライブコーディング＆コード解説
  • ウィザードで、使用するコンポーネントやフレームワークを選択するだけで、基本的なコードは出来上がり
  • JavaEE6ではJSF2.0がスタンダード。
  • JPAはHibernateの思想に大きく影響されている
    • #たしか、Hibernateの開発メンバーがJPAの開発にも携わっていたんじゃなかったかな？

JSFになじみがないので、ちょっとついていけませんでしたが、NetBeansがIDEとしてだけでなく、コードジェネレータとしても機能豊富なのは十分に感じました。あと、デモでは使わなかったけれど、NetBeansのフレームワークのテンプレに、SpringMVCがあったのには驚き。

JSPは後方互換性のためにJavaEEに残っているとのこと。と言われても、そもそもの概念に違いがあるので、いつの日かJSFへ移行せよ、となっても難しそう…。

@sugarlifeさん「Glassfishと他の (OSS) APP Server の取り巻く状況の比較」

  • 「触ってみる」の前に、コミュニティの観点から比較してみる
  • GlassFish
  • JBoss
    • 同期間で、1252issue／1157solved
    • 商用のEAP版が出ると、更新がほぼ停止しセキュリティパッチ等出にくくなる
    • 有償サポートはパッチ等も出て手厚い
  • Geronimo
    • 93issue／151solved
    • 2010年にIBMがサポートを停止、IBMに多くいたコミッタによる開発が止まった
      • IBMはWebSphereに注力
  • Apache TomEE
    • 78issue／67solved
    • 他がチケットの6割がバグなのに対し、TomEEは3割程度（他は新機能等）
    • 先日の1.0.0リリースの際に、多くのチケットが一斉クローズされた跡が見られる
  • Apache Tomcat
    • 153issue／130solved (Tomcat7)
    • 52issue／35solved (Tomcat6)
    • 他が3〜6ヶ月周期のリリースであるのに対し、Tomcatはほぼ毎月
  • まとめ
    • GlassFishとJBossはコミュニティ活動が盛ん
    • GeronimoとTomEEは不透明
    • 課題解決が見えるところで行われるのがTomcatの生き残れる理由ではないか

issueやsolvedの数を比較することで、コミュニティの盛り上がりを比較する手法が斬新で、興味深かったです。
以前、リリース頻度やバージョン番号でプロダクトの信頼性を計ろうとしたことがあったのですが、それよりもはるかに説得力のある指標だなと感じました。
#そもそもリリース頻度やバージョンなんか何の役にも立たないな、と今更ながら思う。。chromeなんて、もはやバージョン20だしw

@btnrougeさん「GlassFishユーザー認証ワンポイントレッスン」

  • 認証 Authentication (atn) ：サーバにアクセスしてきたユーザが本当にそのユーザかを確かめること
  • 認可 Authorization (atz) ：認証したユーザに対して、そのユーザができることできないことを設定すること
  • レルム Realm 認証を行う仕組み一式
    • ファイルレルム
      • 認証情報をファイルへ暗号化して保存、管理コンソールで編集する
      • Tomcatは平文保存
    • JDBCレルム
      • 認証情報をDBで管理
      • どのテーブルのどのカラムに、ユーザ名・パスワード・グループがあるかを指定でき、柔軟
    • LDAPレルム
      • 通常のOpenLDAP等だけでなく、ActiveDirectoryも使える
    • PAM/Solarisレルム
      • Unix系のOSの認証をそのまま使う
    • カスタムレルム
  • おすすめ・・・ファイル/JDBC/LDAP
    • 項目が多いけど、間違えづらい
  • おすすめしない・・・PAM/カスタム
    • 他はGlassFishの中で閉じるが、PAMはOSに依存するため、ハマるとどこが悪いかわかりづらい
    • カスタムはJAASで標準化されているが、将来バージョンアップした時に動作の保証ができない
  • 認可、ユーザロールマッピングは、下記のファイルで行う

PAMがおすすめされない理由が、関心事がGlassFishだけに収まらずOSまで広がるので良くないという話で、この前まで自分自身でも、アプリが動かない理由がAPサーバの設定なのかフレームワークの設定なのかわからずにハマってしまったので、関心事を限定するように設計するのは大事だなと、改めて感じました。

@makingさん「Pure Java EE or Spring?」

  • Spring vs EE6 は、感情論・宗教論になりつつある
  • 各種長所、短所、対抗技術
    • JSF vs SpringMVC
    • CDI vs Spring DI
    • 書籍
      • EE6の本は個別要素の説明が多い
      • Springはサンプルアプリ作成やクックブック的な本が多い
    • セキュリティ
      • Spring Securityがパワフル
    • コードジェネレータ
    • 最も大きな違い：jarの配置場所
      • EE：サーバ側・・・バージョンを自由に選べない／warが軽い
      • Spring：アプリ側・・・warが重い／好きなバージョンを選べる
    • Springはプロプライエタリ
      • 開発がオープンでなく、SpringSourceで作られてるのがリスクかも
  • いずれも、甲乙つけがたい
  • 使い慣れた技術を使えばいいじゃない
  • 一貫性が取れるなら、混ぜて使うも良し

最近、SpringMVC+JPAで開発していて、Springがいいのか、EE6がいいのか、悩むことも多かったのですが、どちらも一長一短で、その時々の最適なスタンダードを選択していけばいいのかな、と思いました。


ところで、今回のスピーカーの方の何名かは、社内フレームワーク作成が仕事、と仰っていました。以前どこかで「日本はフレームワークを作り込む、アメリカは転職社会だから標準を強く意識する」と聞いた事があったのですが、割と本当みたいです。
#…と言ってる自分も、ついついフレームワークの作り込みに走ってしまうけど。

どれも勉強になりましたが、特にissueによるAPサーバの比較や、SpringとEEの比較は興味深かったです。
ありがとうございました！