Web Application Server の世界 (2000/10/13)
ここ数ヶ月の間、Web Application Server というものを色々と調べておりました。ブラウザをクライアントソフトとして、例えば、顧客データや商品データを検索し、一覧を HTML で返すというような作業を行うのが Web Application Server の仕事です。Microsoft の IIS や、Netscape iPlanet、IBM WebSphere、BEA WebLogic、Oracle Application Server 等、商用のものから、CGI を使った単純なものまで、様々な実行環境が存在します。
そういった中で、私が調べているのはオープンソースで実現する Web Application Server です。WWWサーバーとして Apache を使い、それに、Servlet と JSP(Java Server Pages) の環境として Tomcat (Apache Jakarta Project)を組み合わせます。EJB環境として JOnAS を、そしてデータベースは PostgreSQL を使います。
実はここ数ヶ月間、ここのサイトの更新が疎かになっていたのは、仕事が忙しかったこととともに、これにハマッていたからなんです。そもそも調べ始めたのは、オープンソースで実現する、Web Application Server が、どれだけ使い物になるんだろうかという興味からです。商用アプリケーションサーバーを導入すれば簡単な話なのかもしれませんが、開発者ライセンスでも云十万、運用ライセンスでは云百万もします。それだけ高価なものを個人の開発者が購入できるべくもありません。（涙） 開発プラットフォームとしても、オープンソースで実現できるのは魅力的です。さらに推し進めて、資金力の乏しい中小企業や商店等への適用ができないものかという思いもあります。
一度に書くには、あまりにも広範囲となりますので、今後、ポイントを絞りながら、少しづつ、環境構築の方法や実験について、このサイトに書き記していきたいと考えてます。
Web Application Server に必要なもの (2000/10/17)
Web Application Server に、まず必要なものは WWW サーバーです。これがないとブラウザとやりとりできません。しかし、これだけだと、基本的にはあらかじめ用意した HTML を表示することしかできません。例えば「検索条件を指定してデータベースから一覧を表示する。」というような機能を実現するためには CGI が必要です。CGI は、要求に応じて処理を実行して WWWサーバー経由でブラウザにデータを返します。
Web Application Server と呼ばれるには、WWWサーバーと CGI が最低限の機能となります。これだけで、たいがいの機能は実現できます。ただ、CGI にはいくつかの問題点があります。ひとつは実行効率の問題。もうひとつはセキュリティの問題です。CGI は、要求がくる度にプロセスが生成されます。この呼び出しコストは非常に大きいため実行効率が悪くなります。また、実行プログラムで作成された CGI 等は、バグによるセキュリティホールの懸念もでてきます。そこで最近では、Java の Servlet が注目されています。Servlet は、Web サーバーと連携して動作する JavaVM 上にクラスがロードされて動きます。ですから、生成されるプロセスは一つだけです。また、セキュリティは、JavaVM のサンドボックスで保護されています。Servlet は、構造上 CGI とは違いますが、CGI と同じ（それ以上の）機能を実現できます。Servlet は、JavaVM 上で動作します。ですから、JavaVM が動く環境であれば、Servlet は、どんなプラットフォームでも動作します。
さて、Servlet とともに、使われるものとして JSP (Java Server Page) があります。これは、HTML ファイルの中に Java のプログラムやコンポーネントを組み込むことができます。これは、動的にコンテンツを生成するために必要となります。Servlet だけでも、動的な HTML を生成できるのですが、これだと、静的なデータ、例えば HTML タグや、変更の必要がない文字列を Servlet プログラムに埋め込む必要があります。JSP を使えば、これら静的に提示する部分と動的に変更する部分を切り分けてページを作れるようになります。一般に今日言われている Web Application Server は、WWWサーバー + Servlet エンジン + JSP というのが最小セットとなるようです。例えば、商用の IBM WebSphere のエントリー版は、IBMがカスタマイズした Appache と Servlet エンジン、JSP 実行環境のセットです。
これらに、プラスして EJB (Enterprise Java Beans) があります。EJB は、Servlet や JSP から呼び出されます。この EJB は、EJB コンテナという環境で動作します。EJB コンテナはセッションやトランザクション、セキュリティの管理をやってくれるので、これら管理をまかせて、EJB 自体はビジネスロジックの実装に専念できるようになります。
Sun が提示している J2EE (Java 2 Platform Enterprise Edition) という、Web アプリケーションのフレームワーク仕様は、今まで述べてきた Servlet,JSP,EJB を統合したものです。J2EE 実装のアプリケーションサーバーならば、どのアプリケーションサーバーでも、開発した Web アプリケーションを動かすことができるそうです。私は経験値が低すぎるので、実際はどうなのかわからないのですが、仕様を読む限りはそういうことになってます。
では、Web Application Server に必要となるものがわかったところで、実際に物を用意してみましょう。私が用意したのは以下のものです。
| WWWサーバー | Apache | http://www.apache.org/ |
| Servlet エンジン、JSP | Tomcat | http://jakarta.apache.org/ |
| EJB | JOnAS | http://www.objectweb.org/jonas/ |
| JDK | J2SE,J2EE | http://java.sun.com/j2se/1.3/ja/ |
| http://java.sun.com/j2ee/j2sdkee/ja/ | ||
| データベース | PostgreSQL | http://www.jp.postgresql.org/ |
Apache と JDK は使用するプラットフォームごとに違います。また、データベースは、別に PostgreSQL でなくてもよいです。ただし JDBC ドライバがないものは使えません。
現在、この環境をベースに色々と調べているところです。日本語ドキュメントが少なくて苦戦しております。英語であれば J2EE のドキュメントやサンプルは豊富に存在します。Sun の Java Developer Connection には多くの情報が存在します。今のところ、これら英語ドキュメントを見るしかありません。最近、「Writing Enterprise Applications with JavaTM 2 Platform, Enterprise Edition（JavaTM 2 Platform, Enterprise Editionを使ったエンタープライズ・アプリケーションの開発方法）」の日本語訳も掲載されはじめました。全７レッスンのうち、まだ１つしか訳されてませんが、全訳されるのを楽しみにしています。
というわけで、今回は、Web Application Server について大雑把に紹介しました。まだまだ言葉足らずや、誤解もあることと思います。しかし、これが今の私のレベルです。また、敢えて Microsoft IIS については触れませんでした。IIS については機会をあらためて書きたいと思います。次回からは実際の環境構築について触れていきたいと考えてます。
Apache + Tomcat の環境構築 (2000/10/21)
Apache も Tomcat もインストール自体は簡単です。Windows ならば、Setup.exe を起動するだけです。Linux の場合、Windows 程簡単にはいきませんが、それほど難しいものではありません。インストール方法については、巷にいっぱい情報が溢れておりますので敢えて触れません。これら情報は、インターネットで検索すればゴロゴロとひっかかりますので、そちらをご覧ください。ここでは環境設定のコツや、巷に流れていない情報、誤解されていると思われる点に絞って書きたいと思います。
Apache と Tomcat の連携
Tomcat は Apache がなくても単体で動きます。これは、Tomcat の中に HTTPサーバーが組み込まれているからです。その証拠に Tomcat のみ起動して、ブラウザから http://localhost:8080/ にアクセスすれば、$TOMCAT_HOME/webapps/ROOT にある index.html が表示されます。Tomcat をちょっとだけ試してみたい場合や、開発時にはこれで十分です。ただし、運用時には、ちゃんとした WWW サーバーを立てて連携するほうがいいに決まってます。
Apache と Tomcat を連携する場合、Tomcat 用の mod_jserv を Apache に組み込んでやる必要があります。混同してはならないのが、この mod_jserv は、本家の JServ (mod_jserv) じゃないという点です。必ず、Tomcat 用の mod_jserv を使う必要があるのです。元々 JServ は、Servlet API 2.0 に対応したコンテナです。Tomcat は、Servlet API 2.2 と JSP.1.1 に対応しています。Tomcat用の mod_jserv は修正が加えられており、Apache と Tomcat の橋渡しをする役目を果たすようになってます。なお、Windows 版の場合は、mod_jserv.so に相当する、ApacheModuleJServ.dll というのがありますので、これを組み込んでやる必要があります。
さて、この Tomcat 用の mod_jserv.so は、The Jakarta Tomcat のサイトからバイナリダウンロードできるのですが、Apache のビルド方法によっては、組み込み時に警告が発せられることがあります。この場合は、Tomcat のソースを取得して、mod_jserv.so を作り直さないといけないかもしれません。Apache に含まれる apxs を使ってリビルドすることになるでしょう。
あとは、Apache の httpd.conf に、$TOMCAT_HOME/conf/tomcat.conf を組み込むだけです。たぶん、tomcat.conf は、環境に合わせて修正が必要でしょう。LoadModule jserv_module modules/mod_jserv.so の部分の修正で済むと思います。この tomcat.conf は httpd.conf の最後に Include してやればいいです。
server.xml の設定
server.xml に以下の設定があります。 <Connector className=”org.apache.tomcat.service.SimpleTcpConnector”> <Parameter name=”handler” value=”org.apache.tomcat.service.http.HttpConnectionHandler”/> <Parameter name=”port” value=”8080″/> </Connector> <Connector className=”org.apache.tomcat.service.SimpleTcpConnector”> <Parameter name=”handler” value=”org.apache.tomcat.service.connector.Ajp12ConnectionHandler”/> <Parameter name=”port” value=”8007″/> </Connector>
上が、Tomcat 自身の HTTPサーバーの設定で、下が、Apache と連携するための設定です。Tomcat 自身の HTTP サーバーが必要ない場合はコメントにしてやればよいです。
以下の記述は、ロードするWebコンポーネントの設定です。 <Context path=”/examples” docBase=”webapps/examples” debug=”0″ reloadable=”true” > </Context>
開発した Web コンポーネントは、この設定に従ってロードされ URL にマップされます。J2EE の仕様に従って、Web コンポーネントを作成し、WAR ファイルを webapps に置いておけば、Tomcat が展開してくれるという話なんですが、まだやったことがありません。（笑）
開発環境
VisualAge for Java に Tomcat を組み込んで開発することができます。なお、VisualAge for Java Entry Edition は無償でダウンロードできます。Tomcat の組み込みを手動で行いますので手順が煩雑なのですが、幸いにも IBM からセットアップ形式のものも提供されています。Tomcat の開発環境としてはお勧めです。
以上、あーだ、こーだと細かく書きませんでした。最も信頼できる情報は、$TOMCAT_HOME/doc の下にあるドキュメントです。ユーザーガイドが入ってますので、これを読めばもっと細かい設定方法がわかるはずです。
JOnAS の環境設定 (2000/10/21)
JOnAS を Tomcat とともに使うための環境設定です。
JOnAS (jonas2.tgz) を Get したら、ついでに、http://java.sun.com/products/jndi/ で jndi1_2_1.zip と rmiregistry1_2_1.zip を Get してください。この中の jndi.jar,providerutil.jar,rmiregistry.jar が必要です。また、使用するデータベースの JDBC ドライバが必要です。JDBC2.0 をサポートしたものじゃないと動かないようです。私が試した限りでは、Oracle と PostgreSQL は動きました。InterBase 6.0,MySQL はダメでした。ただ、PostgreSQL は、Windows から接続した際にちょっと不可解な現象が出てます。これについては、別の機会にお話します。
まずは展開
jonas2.tgz を展開します。私は /usr/local に展開しましたが、別にどこでもかまいません。
jndi1_2_1.zip, rmiregistry1_2_1.zip から、jndi.jar,providerutil.jar,rmiregistry.jar を展開します。私は、$JONAS_ROOT/lib/jndi というディレクトリを作成して配置しました。ドキュメントには、/usr/local/lib にすることを推奨してました。
環境変数とパスの設定
環境変数 JONAS_ROOT に JOnAS をインストールしたディレクトリをセットします。/usr/local に展開したならば、export JONAS_ROOT=/usr/local/jonas-2-1-1 です。PATH は、$JONAS_ROOT/bin/unix (Windows の場合 $JONAS_ROOT/bin/nt) を通しておきます。
config_env の編集
$JONAS_ROOT/bin には、nt と unix という２つのディレクトリがあります。nt なら、config_env.bat を unix ならば config_env を編集します。修正が必要な部分だけ書きます。
| OBJECTWEB_ORB | JEREMIE | Tomcat とともに動作させる場合は RMI ではなくこちらを使うようです。 |
| JNDI_HOME | $JONAS_ROOT/lib/jndi | JNDI 関連の JAR を配置したディレクトリをセットします。 |
| JDBC_CLASSES | /usr/lib/pgsql/jdbc7.0-1.2.jar | JDBCドライバです。 |
jonas.properties の編集
$JONAS_ROOT にあります。修正が必要な部分だけ書きます。
| jonas.datasources | PostgreSQL | データベースファイルの接続設定を記述したファイルを指定します。PostgreSQL.properties を使用する場合の設定です。.properties は必要ありません。 |
PostgreSQL.properties の編集
JDBCドライバや、実行環境によって記述は異なりますし、そもそも PostgreSQL.properties というファイル名でなくてもよいです。jonas.properties の jonas.datasources に指定したものと対応が取れていればよいのです。
以下は PostgreSQL を使った私の環境の場合です。最低限修正が必要な部分だけ書きます。なお、datasource.name jdbc_1 は変更しません。サンプルを動かすために必要です。
| datasource.url | jdbc:postgresql://localhost/test | 環境によって違います。 |
| datasource.classname | org.postgresql.Driver | JDBCドライバによって違います。PostgreSQL の場合はこれでOKです。 |
| datasource.username | test | データベースログインユーザー名 |
| datasource.password | test | データベースログインパスワード |
| jdbc.connteststmt | select 1 | 接続テストに使用するステートメントです。select 1 がエラーになるようなデータベースならば変更が必要です。例えば Oracle では select * from dual でしょう。 |
jndi.properties の編集
rmi を使う設定と Jeremie を使う設定が書かれてますが、Jeremie のほうはコメントとなってます。rmi の設定をコメントにして、Jeremie の設定のコメントはずします。
| java.naming.factory.initial | org.objectweb.jeremie.libs.services.registry.jndi.JRMIInitialContextFactory | |
| java.naming.provider.url | jrmi://localhost:12340 | サーバー名をちゃんと書かないとダメです。必要ならば、ポート番号も変更します。 |
jonathan.prop の編集
Tomcat のセキュリティと連動させるために必要です。tomcat-jonathan.prop というファイルがあるので、元々の jonathan.prop と置き換えます。
Tomcat server.xml の編集
<RequestInterceptor className=”org.objectweb.security.tomcat.interceptor.SecurityCtxInterceptor31″ />
を<RequestInterceptor className=”org.apache.tomcat.request.SecurityCheck” />
の後ろに追加します。
動作確認
まず、registry 12340 として Jeremie サーバーを起動ます。その後、別ターミナル（ウィンドウ）で $JONAS_ROOT にディレクトリを移って、EJBServer を起動します。正しく起動できればOKです。ただし、JDBC接続だけは、実際にやってみないと正しく設定できてるかどうかわかりません。
ちょっと変な現象があります。わざわざ、$JONAS_ROOT に移って EJBServer を起動したわけですが、本来どこからでもOKなはずなんです。実は、Windows だと、どこから起動しても大丈夫なんです。少なくとも私の Linux 環境ではダメみたいです。trace.properties と jndi.properties がカレントにないと見つけられないようなんですね。何故なのか原因がわかりません。
$JONAS_ROOT/examples の下には、Session Bean, Entity Bean とセキュリティのサンプルが入っています。ドキュメントを読んでコンパイルして動かしてみてください。Linux の場合、先ほどの変な現象のおかげで、カレントディレクトリに、trace.properties と jndi.properties のリンクを張らないといけないかもしれません。
補足：2000/10/25
jndi.properties と trace.properties を見つけられない問題が解決しました。ドキュメントによると、CLASSPATH を検索して見つけるようです。この CLASSPATH に $JONAS_ROOT が含まれていないことが原因でした。どうやら、$JONAS_ROOT/bin/unix/config_env に問題があるようです。「$JONAS_ROOT が CLASSPATH に含まれるかどうかを判定して、含まれていないならばセットする。」というロジックになっているのですが、この判定が甘いためにセットされないようです。これを修正してやれば、Windows 環境と同様に問題なく動くようになりました。
Web Application の開発 (2000/10/27)
オープンソースで整えた環境で Web Application を開発するにはどうしたらよいのか？商用の Web Application Server ならば、開発用の IDE やツールが付属していたり、サポートクラスが用意されていたりするんですが、オープンソースで、そこまでサポートされているものは知らないです。実は私自身、どうしたものかと思案しているところなのです。
まず、Tomcat (JSP, Servlet) の開発環境なんですが、商用の開発ツールを見ると、JSP と Servlet の開発環境がサポートされるのは、どれもラインナップの最上位版であり、簡単に手が出る価格じゃありません。前に紹介した、IBM Visual Age for Java + Tomcat は、実行環境で開発できる点が魅力です。ただ、実行とデバッグが可能というだけでして、例えば、JSP 構文チェックとか、ウィザードによる雛型の生成、簡単なデバッグなんてのはエンタープライズ版にならないと使えないみたいです。色々と調べてみたところ、Sun が提供している、Forte for Java の Internet Edition という次期バージョンが一通りの機能を備えているようです。現在ベータ版で英語版のみすけど、無償で手に入れることができます。もし、IDE に頼らないで Tomcat 流に開発を進めるというのならば、プロジェクトは Ant でビルドし、JSP は WatchDoc を使って検証、なんて方法が正当な流儀なんだと思います。私は軟派なんで（爆）、まず、Forte for Java Internet Edition を使って Web コンポーネントを作成するところから入ろうと考えております。
一方、JOnAS (EJB) の開発環境は、どうしようもありませんね。JOnAS に newbean というシェルスクリプトが用意されてますので、これを使って作成した雛型をもとにゴリゴリ作るしかありません。デバッグも昔ながらにトレースしてやるしかないでしょう。さて、newbean は $JONAS_ROOT/bin/unix にしか入ってます。 Windows 環境用の newbean はないんです。もし Windows でも使いたいのならば、検証したわけではありませんが Cygwin を入れれば使えると思います。そこまでしなくても、$JONAS_ROOT/bin/template から、必要な雛型をコピーして、中のテンプレート文字を修正してやってもいいでしょう。newbean スクリプトの内容を見ながら、自らが sh (or bash) となり編集してやればいいわけです。（笑） それも面倒という方で、暇をもてあましている方は、是非 Windows 版 newbean を作ってください。たぶん数時間あればできると思います。「お前がやれ」って。。。いえいえ、私は軟派なんで、Linux 環境を使います。（爆笑）
最後に、開発に必要なドキュメント類ですが、Tomcat, JOnAS ともに、インストール、使い方、開発の流れについてのドキュメントが入っているので一通り目を通しておくべきです。あとは、Sun の JDC を辿って集めることになります。中でも J2EE Blueprints の Pet Store Demo とドキュメントは非常に参考になります。このドキュメントの日本語訳が欲しいんですが、どっかにありませんかねえ。
PostgreSQL の注意点 (2000/10/29)
Windows 環境で PostgreSQL を使う、あるいは Windows 環境から PostgreSQL へ接続する際に注意しなければならないのは、エンコーディングの指定です。PostgreSQL は、マルチバイトサポートされていますが、データベースで日本語を使う時に指定できるエンコーディングは、EUC_JP, UNICODE, MULE_INTERNAL です。注意しなければならないは、SJIS がないということです。ただし、フロントエンドのエンコーディングとして SJIS を指定することができます。ここらへんの詳しい説明が、README.mb.jp に記述されていますので読んでおいたほうがよいでしょう。PGCLIENTENCODING 環境変数によるエンコーディング指定の方法や、set client_encoding SQL文による指定方法について解説されてます。
ちなみに、PostgreSQL は、Windows NT で動かすことができます。私は、ここで公開されているバイナリを使わせて頂きました。Cygwin の環境を整えなければならないのが難点なのと、postmaster 起動時に -i オプションを指定して、クライアントコマンド（psql 等）は、-h 127.0.0.1 を指定しなければ動かなかったりと面倒な点もあります。
私は、今回、PostgreSQL を選択したわけですが、データベースを選択するにあたって、他に InterBase 6.0, MySQL も評価してみました。これら２つに共通した問題点は JDBC ドライバの出来でした。ドライバの問題は、データベース本体の評価とは別の部分ですが、今回の目論見にとって JDBC 2.0 をサポートしたドライバの出来は重要でした。中でも MySQL は、データベースの性能が結構良かったけに残念です。
PostgreSQL に対して、商用データベースのような、高機能、高性能、一貫整合性保証を求めるのは酷だと思います。しかし、日頃 Oracle と付き合っていると自然と比べてしまいます。中でも、REDO LOG に相当するロギング機能が存在しないのは不安です。障害発生時に、どこまで一貫整合性が保証されるのか？どうなんでしょうね。SQL92 をフルサポートしてない点も PostgreSQL を使って開発する者としては気になります。また、外部参照キーのサポートはされているものの、トリガーで実現しているようで、これには少々違和感を持ってます。
と、色々と気になる点があるものの、現時点での選択してはベターじゃないかということです。適用範囲さえ間違えなければ使えるデータベースだと思います。MySQL の JDBC ドライバがなんとかなれば乗り換えるかもしれません。（笑）
