Sun と Oracle について
続々とニュースが出てきていますね。
http://www.sun.com/third-party/global/oracle/
http://www.oracle.com/sun
IT media:Oracle、Sunを買収
CNET Japan: オラクル、サンの買収で最終合意
マイコミジャーナル:【速報】米Oracle、Sun Microsystemsを56億ドルで買収
slashdot: Oracle、Sunを74億ドルで買収
すいません、社員なので公にコメントしたくてもできないので、
本エントリに関してのみ、コメント欄も無効にさせていただいています。
GlassFish と Tomcat の違い Part 4
GlassFish と Tomcat の比較について何度か説明してきていますが、
(過去記事)
実際のところ、GlassFish は Tomcat より何が便利なのでしょうか?
今日は、Tomcat ユーザがかかえる問題である「管理の手間について」
管理作業を軽減するために、GlassFish の便利な管理機能について紹介します。
さて、皆様、まず Tomcat でシステムを構築したとしましょう。
この時、サービスが構築時に予想した範囲のアクセス数、処理数で
十分な場合は何も問題がありませんが、サービスが成長してきて
1台のマシンでは処理を裁ききれなくなった場合はどのようにして
システムを拡張していますか?
Tomcat を利用している方は、1台づつマシンにインストールして
1台づつ ログインしては設定を行っていると思います。

設定変更がさほどない環境であればこれでも我慢ができるかもしれません。
しかし、アプリケーションの開発において DB のリソースを追加したいことや、
新しいアプリケーションを追加したい場合も多々あるでしょう。
そのような時、Tomcat では毎回1台づつログインして設定を変更しなければ
なりませんでした。
同じ設定を行うのに1台づつログインして設定して再起動してというような
作業は面倒ではありませんか?
また、作業の数が増えれば増える程、XML ファイルの設定ミス等が発生します。
設定ミス等でアプリケーションが正常に起動しないなんてことで困ったことはありませんか?
GlassFish を利用するとこのような手間と設定ミスのリスクを大幅に軽減してくれます。
インストールは各マシンに行っていただく必要がありますが、リソースの追加や設定変更、
アプリケーションサーバの再起動のために、毎回各システムに対してログインをしなくても済みます。
GlassFish では “ドメイン管理サーバ”(DAS)と呼ばれる1つのアプリケーションから
全てのアプリケーションサーバの設定、たとえばリソースの追加や、起動、停止、
配備、配備取り消し等の操作を行うことができるようになるでしょう。

また、クラスタというアプリケーションサーバのインスタンスの共通グループを
作成する事で、同一クラスタ(グループ)に所属する全てのインスタンスに対して
同一の設定を行いたい場合、たった1回の操作で全てのインスタンスに対して
同じ設定を行うこともできるようになります。
これにより、XMLの編集ミスといった初歩的なミスを大幅に軽減することが
できるようになり、サービスの成長に伴い台数がいくら増えても管理の手間は
増えず、管理時間も大幅に軽減されるようになります。
Tomcat ユーザの皆様?
1台づつログインして設定して、設定をコピー&ペーストして面倒ではありませんか?
中規模から大規模なサービスを展開する場合、この GlassFish が持つ管理機能はとても
便利です。Tomcat の管理で面倒だと感じている管理者の皆様、是非一度
GlassFish を触ってみてください。
設定方法に関する参考資料:
GlassFish のクラスタと負荷分散構成
JavaSE6 と GlassFish で JSP の高速コンパイル
皆様、JSR-199 (Java Compiler API)をご存知でしょうか?
Java SE 6 で拡張された機能の一つなのですが、この API を
利用すると、Java のプログラム中から Java のソースコードを
コンパイルできるようになります。
一見すると、この機能と GlassFish どのような関連があるの?
と思われる方もいらっしゃるかと思いますが、JSR-199 に対応した
JSP コンパイラが GlassFish 上で実装されています。
そこで、JSP/JSF 等のコンパイルが非常に高速になります。
(一説によると3.5倍〜10倍早いとか)
今までは、JSP をコンパイルした後、Servletコードをファイルに
出力してロードしてとアプリケーションの起動までに結構時間が掛かった
りしましたが、GlassFish ではファイルに書き出さず直接メモり上で
コンパイル等の動作を行うことができます。
ですので、
GlassFish は Java SE 6 で動かすことをおすすめ致します。Java SE 5 を
ご使用中の方は、バージョンを変更したい場合、下記のファイルを修正し
変更してください。
# vi glassfish-v2.1/config/asenv.conf AS_JAVA=”/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home” |
また、開発者の方は、上の説明でではコンパイルされたコードを
見たい場合はどうすればいいのだろう?と思う方もいらっしゃると思います。
NetBeans をご使用されている方は、Web のプロジェクトを作成した際に
デフォルトでソースコードが出力される設定が追加されています。
具体的には、プロジェクト中の設定ファイル(sun-web.xml) に
下記の行が追加されています。
<jsp-config> <property name=”keepgenerated” value=”true”> <description>Keep a copy of the generated servlet class’ java code.</description> </property> </jsp-config> |
開発者の方はこれを消していただくことで、Java のコードは出力されなくなり
全てメモり上で作業が行われますので下記を消して再度配備してみてください。
逆に言うならば、NetBeans 等をご利用されていない場合は、上記のコードを
記載していない場合、Java のコードは出力されませんのでご注意ください。
ちなみに、Java のソースコードの出力先は下記になります。
glassfish-v2.1/domains/domain2/generated/jsp/j2ee-modules/APPLI_NAME/org/apache/jsp |
効果の程は、是非皆様ご自身の手で試してみてください。
参考資料の抜粋:
◎
http://blogs.sun.com/kchung/entry/speed_up_jsp_compilations_with
The performance gain for using JSR1 199 API is amazing! Preliminary measurement shows an order of magnitude improvement in raw Javac compilation speed, and a 3.5X improvement in overall execution when running JSP TCK tests! |
◎
https://glassfish.dev.java.net/ja/public/WP_GlassFish_Overview.pdf
GlassFish のもう 1 つの注目すべき変更点は、Java コンパイラの Jasper が Java SE 6 のコンパイラ API (JSR-199) を利用できるようになり、ファイル IO の回避とコンパ イル速度の大幅な向上 (非公式の計測では約 10 倍の高速化) が実現されたことで す。JSR-199 を使用する場合ほど高速ではありませんが、Eclipse JDT コンパイラを 使用するように Jasper を構成することもできます。残念なことに今は手元にベン チマーク結果がないのですが、JSF 実装も大幅に改善されました。 |
GlassFish v3 のスケジュール公開
GlassFish v3 のスケジュールがドラフトとして公開されたようです。
GlassFish v3 リリーススケジュール
ここ最近の私のプレゼンを聞いてくださった方にはリリースが遅れるかもしれない
ことを伝えておりましたが、上記でスケジュールドラフトが公開されたようです。
当初、GlassFish v3 は今年の JavaOne でリリース予定でした。
しかし Java EE 6 の仕様策定が今年までずれ込んだため
(本来は仕様は昨年末に FIX 予定でした)
Java EE 6 の参照実装である GlassFish v3 の開発スケジュールもリスケされ、
結果として今年の秋のリリースとなる予定です。
GlassFish v3.0 は Java EE 6 の参照実装を公開するという意味合いが強く、
エンタープライズ環境で必要なクラスタなどの管理機能が
含まれていません。
そこで、GlassFish v3.0 は開発者の皆様が Java EE 6 の開発に
なじんで頂くための製品としてとらえて頂ければと思います。
エンタープライズ環境でクラスタ等の機能が利用できるように
なるのは GlassFish v3.1 になってからになります。
GlassFish v3.1 のリリースは恐らく2010年以降になるかと思いますので
それまでは、現在の GlassFish v2.1 を本番環境でご使用頂ければと思います。
また、既存の GlassFish v2 のユーザには一つだけ残念なお知らせがあります。
GlassFish v3 は新しいアーキテクチャ(OSGi対応)となるために、
既存の GlassFish v2.x ユーザはアップグレード時に少しだけ
手間を掛けていただく必要があります。(2009年4月時点の方針)
今まで、Sun のアプリケーションサーバ (Sun Java System Application Server )を
使って頂いていた方は、GlassFish Enterprise Server のインストール時に既存の
インストールパスを指定すれば既存の、アプリケーションや設定等をそのまま自動的に
アップグレードしGlassFish 環境で動作させることが可能でしたが、GlassFish v2 から
GlassFish v3へはインストール時にそのような自動アップグレード機能が存在しません。
GlassFish v2 から GlassFish v3 へは手動で設定してアップデートしていただくか、
もしくはかんたんにアップデートできるようなツールが用意されるかと思いますが、
今までよりもインストール時のアップグレードに対して若干手間が掛かってしまいます。
アーキテクチャの大幅な変更のため、どうぞご理解頂ければと思います。
(まだ、開発中の製品ですので今後方針が変わる可能性もあります。
また、もちろん新規構築のシステムであればインストールや導入も非常にかんたんです。)
しかし、そのような手間が掛かったとしても、GlassFish v3 になると OSGi 対応、
モジュール化の恩恵が多いに受けられると思いますので、どうぞ楽しみにしてください。
GlassFish v3 は Java EE 6 の参照実装として位置づけられた製品ですが、
Java EE を動かすためだけのサーバではありません。
JRuby がネィティブで動作したり、EJB が必要なければ使わなくてもすむというような
ユーザのニーズに柔軟にこたえることができる、サーバに生まれ変わります。
(起動時間もたった数秒です。)
今まで、アプリケーションサーバは重たいし EJB が必要ないから Tomcat で十分と
思っていらっしゃる方も多いかと思います。
GlassFish v3 はアプリケーションサーバの常識が変わります。
是非、GlassFish v3 に期待していてください。
GlassFish の最新事例紹介
GlassFish & MySQL の最新事例(株式会社 マピオン)が紹介されました。

期間限定で(4月13日までに)導入事例をご参照いただいたお客様の中から
抽選で旅行券1万円分(10名様)と Sun のロゴグッズ詰め合わせ(20名様)
が当たるキャンペーンを実施しています。
是非、この機会に株式会社 マピオンでの GlassFish & MySQL の導入事例を
ご参照ください。
GlassFishのアンケートに答えてグルメカードをゲット!!
GlassFish のアンケートに答えてグルメカード・
サンオリジナルタオルをゲットしてください。

アンケートの内容を先ほど確認したら質問数は10箇所でしたので、
あまりお時間は掛からないと思います。
是非よろしくお願いします。
Tomcat の valve 機能を GlassFish で利用
GlassFish と Tomcat の違いについて説明したり、
マイグレーションについても説明してきましたが、
今日は、Tomcat でアドバンスドな管理を行っている方に
既存資産 (Tomcat valve) の流用について紹介します。
Tomcat の valve 機能を使ってアドバンスドな管理をなさって
いらっしゃる方はいらっしゃいますか?
もしくは、Tomcat の valve を独自に実装しているので他のサーバに
移行するのをためらっていらっしゃる方はいますか?
そのような方はご安心ください。
GlassFish でも Tomcat の valve 機能を利用することができます。
そもそも、valve とは何ぞや?という方もいらっしゃると
思いますので、かんたんに valve の機能について説明します。
Tomcat の valve は HTTP クライアントからのリクエストやレスポンスを
実際に処理する前(後)に、何か別の処理を行うことができる
機能です。これを利用することで、各リクエストに対する
デバッグなども行うことができるようになります。
例えば、Tomcat では リクエストダンプバルブという valve が
デフォルトで用意されておりますが、これはリクエストや
レスポンスのヘッダ、クッキーの情報をログファイルに
出力してくれます。そしてログを確認することでかんたんな
デバッグを行うことができます。
また、独自に実装した valve を設定することでより高度な
デバッグ/監視などを行うこともできるようになります。
Tomcat を高度に利用されている方は、この valve の機能を
独自に実装し、管理・監視を行っている方もいるかと思います。
その方は恐らく、既存の資産を捨てて GlassFish に移行するのを
躊躇するかもしれません。
でもご安心ください。若干の修正で GlassFish でも Tomcat の
valve を利用することができます。
Grizzly の開発者である Jean-Francois は元々 Tomcat も
開発していました。
そして、valve の機能を流用できるように、GlassFish 上で
Tomcat の valve を使用する方法を公開しています。
Jean-Francois Arcandのブログ:
Extending GlassFish’s WebContainer
GlassFish Wiki:Tomcat の Valve をどう変換すれば GlassFish で動作しますか?
PS.
Sun の Inner CIRCLE でも GlassFish vs Tomcat の記事がレポートされてます。
GlassFish vs Tomcat 徹底比較検証
~アプリケーションのパフォーマンスと使いやすさ、敏捷性を重視する方、必見!~
週末の散歩
この週末に、横浜の三渓園にお花見に行ってきました。
この三渓園という所、同じ横浜市内にあるにも関わらず今まで一度も行ったこと
無かったのですが、実際に行ってみるとなかなか良い所でした。



また、今日は日曜日にも関わらず殆ど駐車場を待たずに入れたので
とてもラッキーでした。(来週末はもっと混んでいるかな?)



水戸の偕楽園は2度程行ったことがあるのですが、あんなに遠くまで行かなくても
結構近場にすばらしい日本庭園?!があったので、これから散歩に来ようと思ってます。



まだ、桜は満開まではいってませんでしたが、ちらほら咲いていたので、
綺麗な景色を見たり、おしるこ等を食べて、良い週末のお散歩になりました。
赤坂サカス
春が近づいたと思えば、また冬に逆戻りの寒さですね。
昨日、赤坂で飲んでいたのですが、帰りに赤坂サカスの
写真を撮ってきました。
今、OLYMPUSのE-510は修理に出しているので、RICOHのGR-II
を片手にちょっと一枚。
週末はどこかで桜を撮ってこよっかなぁ?





