J2EEの肝はEJBではあると思いますが、それ以外にも多くのComponentsがあります、それらの習得のためにはここもOSSの素材を活用していきます。OSSのEJBコンテナJBossはリソースが少なくとも動作するらしいので、Cel400程度のマシンでも何とかなりそうです。
Application Serverとは簡単にいうとクライアントインターフェースを担当するWebサーバ（HTML、JSP等のプレゼンテーション）、バックエンドに存在するDBシステムの間にあって、独立したビジネスロジックを実行するサーバという風にいえます。WebサーバとバックエンドのDBとの間にあるという点からはMiddlewareという用語も使われるようです。世の中のWebサービス、ここではXMLベースでデータ交換を行うSOAPとかではなく普通のインターネットサービスの意味、がHTTPプロトコルを利用して構築されることが大半になってくると、表現としてのHTMLドキュメントをXML文書やDBから”作成”とする手段が重要となってきますが、その手段としては処理の重たい、拡張性のないCGIではありえません。Enterprizeなシステム構築では、"write once, run anywhere"つまり互換性、移植性の保持というのは重要な命題になりますから、Application ServerといわれるものもJavaベースのものが主流と考えます 。
実際の業務システムでは各サーバが一台だけという場合は少ないでしょうから、各サーバへのアクセスを平準化調整するload balancerのようなものが介在するのでしょうが、概念的には上のような構造になるのでしょうか。このように機能を階層ごとに明確に分離してアプリケーションを構成する手法がn-tier（n階層構成）と呼ばれ、各層ごとのAPIを明確に定義する事で、拡張性と移行性を保証できるようにしていると考えられます。もちろん層毎のAPIを各ベンダーが独自に定義してしまっては、互換性は確保できなくなるので、これらのAPIを標準化したものがJ2EEである、と考えてもいいと思います。
さてJ2EEの場合、Web systemの構成と言うのは以下のような構造となるでしょうか。もちろん以下の図は論理的な概念ですから、物理的にはそれぞれのComponentsはもちろん同一のサーバである必要は無く、分散環境が常でしょう。また、EJBを象徴的に表現していますが、J2EEそのものは多くの機能／コンポーネントから成るフレームワークです。
単一のVM上で動作するアプリケーションから、J2EEのような分散環境アプリケーションへの拡張により以下のポイントについてはより一層考慮されるべき要件となってきます、
ところで、通常言われるJ2EEはアプリケーションサーバが実装すべき仕様定義であり、J2EE SDKはそのリファレンス実装ですが、J2EE SDKの用途は教育、デモ等の商用以外であり商用使用は禁止されています。各アプリケーションサーバベンダは、J2EE SDK上でアプリケーションを動作させることにより、アプリケーションサーバ自身のJ2EE仕様との互換検証目的に使うことになるでしょう。ところで、JBossのHPによれば、J2EEというのはWeb用のOSという解釈なのだそうです。
"J2EE: AN OPERATING SYSTEM FOR THE WEB Enterprise web applications, which live on networks and are accessible through browsers, are redefining Enterprise Web Software. This is the next wave of computing. "
ではこのようなApplication serverが動作する基本となっているものはもちろんJ2EEでは有りますが、すでに述べたように分散環境を前提で扱うために、J2SEからJ2EEには割と大きなGAPがありますから、まずは基本的な用語の理解、そして用語を理解するためには、自分でコードを書いて動かして見る必要があるのはもちろんです。
J2EEを理解するための必要と思われる用語と概念
ほぼ、上の図のWebサーバ、Application Server、DB systemに対応しているとは思いますが、このような多層モデルが最近の方向です。それはthin client、つまりApplication開発はServer側に集約する、そしてClientからEISを直接見せないことでEIS側のSecurity確保という面もあるでしょう。
1) Presentation
JSPやServlet、つまりHTMLの動的なgeneratorです。もちろん動的な変更が必要ない場合も多くありますから、その場合にはHTMLで十分です。
2) Business Logic
EJBで記述される、J2EEでの中核機能といえます。
3) EIS(Enterprise Information System)
ネットショッピング、顧客管理等のデータになりますから、大半の場合はDBになります。
J2EEのコアともいえる機能だと思いますが、大きく2種類(J2EE 1.3では3種類?)あります。
- Session Bean : クライアントが必要に応じて呼び出す処理を纏めたコンポーネントだそうです。クライアントとのSession(State)を保存するStatefull Session Beanと、保存しなくとも良い場合に使われるStateless Session Beanに分類されます。
- Entity Bean : クライアントの状態に依存せずに存在、端的に言えばDB上のデータに対応して存在すると考えれば良いようです。
分散object、アプリケーションでの関連用語
J2EEとの直接の関連はありませんが、分散オブジェクトやアプリケーションを考えるときには知っておく必要がありそうな概念です。
※ RPC（Remote Procedure Call）
CORBAJ2EEはN_Tier（N階層）コンポーネントベースのアプリケーション構築のためのフレームワークと言われます。つまり、各層のインターフェース（API）を明確に定義することで、開発も分散して出来るようになるわけです。もちろんこの思想はJ2EEシステム（各実行環境、コンテナ）を構成するコンポーネント、そしてEJB開発でのロールの考え方にもあるのですが、ここではJ2EEアプリケーション開発に絞った話題です。
このようなコンポーネントベースにすることで、開発の効率化とアプリケーションの移植性、メンテナンスの容易性というメリットを受けることが出来るようになるわけですが、アプリケーションの動作効率（性能）の観点からは、各層ごとのAPIを経由することによるオーバヘッドにより、マイナスに働くでしょう。しかし、アプリケーション開発する上でのメリットの方が勝るという考え方です。もちろんアプリケーションサーバというのは通常高価なハードウエアリソースですから、効率的なアプリケーションの作り方の考慮は必要なわけで、この観点からはデザインパターンの考え方が必要になってくるわけです。
以下は、J2EEでの各層と各々の層に対応するコンポーネントの代表的な例を整理した図です。ここでEJB（SessionBean）がビジネスロジックを記述するということから、Business層に属するのは当然ともいえるのですが、EntityBeanは実はBusiness層ではないことに注意が必要かと思います。つまりEntityBeanはO/Rマッピングを行うものという定義からすると、ビジネスロジックとResource(データベース)を結びつけるものということになりますから、Integration層に属するのです。従ってEntityBeanにビジネスロジックを記述するのは、邪道ということです。あと一点、サーブレット(Servlet)がMVCモデルでいうところのControllerとすると、なぜPresentationなの？という疑問も湧くのですが、Servletの役割がPresentation(JSP)とBusinessロジックを結びつけるものであってビジネスロジックでは無いと考えられるので、Presentation層に属すると考えるのが自然と思います。
もちろん全てのアプリケーションがこのような層構成を取るとは限らず、servletからEntityBeanを呼び出す場合もあるのですが、それらは単純なロジックの場合だけであって、”エンタープライズなアプリケーション”という場合には、多かれ少なかれここに挙げた層を要素として持つと思います。またこのような階層構造をとることで、セキュリティ的にも強固なものになることは容易に想像できますから、EntityBeanのような重要なデータへのアクセスメソッドは、出来る限りClientから離したレイヤーに配置しておくべきと思います。
J2EEの実例としてSunからはPetStoreというApplicationがリリースされています。Windows上にInstallして動かしてみました。
このApplicationはCloudscapeというDB、そしてJ2EE Serverを起動させBrowserからPort8000でRequestすることで動作します。立ち上げて動作させて気づいたこと。
ともかく、単純そうに見えるサンプルアプリケーションなのですが、EJBの機能を理解するには好適であり、また奥の深いものがあります。
このSample ApplicationはJ2SEの版数が1.4だと動作せず、1.3を要求してきます。
EJB containerの動作環境構築のため、専用のサーバ（Linux RedHat7.2）を用意しました。Cel400、128MBですから、CPU性能はともかくメモリサイズはまったく足りないと思います。j2seとj2ee、それにEJB containerと言うのは独立した存在ではなく、お互い連続した理解が必要なので、まずはJNDIやRMIなどの分散環境を扱う道具を理解していくことにします。まずはj2eeのRI(Reference Implementation)としてSunから提供されているj2sdkeeをインストールして見ます。
j2sdkse install
RedHat7.2でサーバ立ち上げ時に、現在の最新1.4.0をinstallしてあります。http://nemuneko.com/nifty/RH7.2/renew.html#label002を参照してください。Tomcat4.0.2のお勧めは1.3.1なのですが、今後は1.4が主流となっていくでしょうから。
j2sdkee install
j2eeとはseから独立して存在しているわけではなく、アドオンのような位置付けです。現在の最新版は1.3.1になるのでSunのサイトからダウンロードしてseと同じく/usr/local/srcディレクトリで自己解凍しました。
# cd /usr/local/src # tar zxvf j2sdkee-1_3_1-linux[1].tar.gz
このあとで、$J2EE_HOME/bin/j2ee &とコマンド入力するとJ2EEが立ち上がります。この状態でJ2EEのデモアプリケーションのDeployment toolやデモアプリケーションは動作できる状態と考えていいと思います。しかし、Tomcatと同時に立ち上げると128MBでは完全にSWAPも発生してしまいます。またJ2EE起動時には & を付加してback ground動作としないとConsolが占有されてしまいます。まあ、これはInstallしてみただけ、EJBはJBoss上で動かしてみます。
Tomcat4.0.2 install
j2eeのreference実装とTomcatの協調動作はできないようですが、世の中のフリーのアプリケーションサーバではTomcatをServlet containerとして利用する場合が多いので、最新版である4.0.xをInstallしてみました。特にSource版から作成する必要は感じないので、Binary版をダウンロードしてきました。これも同じく/usr/local/srcディレクトリで展開します。
# cd /usr/local/src # tar zxvf jakarta-tomcat-4.0.2.tar.gz # cd /usr/local/src/jakarta-tomcat-4.0.2/bin # ./startup.sh
動作確認はhttp://192.168.0.9:8080/でページが表示されれば大丈夫です。TomcatのHTTPサービスにはPort8080を使っています。
Apacheのinstall
性能や堅牢性においてTomcatのHTTPサーバに比較してApacheのほうが優れているので、Apacheとの連携動作をさせます。現在のApacheの最新版数は1.3.23となります。
# cd /usr/local/src # tar zxvf apache_1.3.23.tar.gz # cd apache_1.3.23 # ./configure --enable-rule=SHARED-CODE --enable-module=so // DSO付でのCompileが必須です。 # make # make install # /usr/local/apache/bin/apachectl start
以上でブラウザからhttp://192.168.0.9/でrequestするとApacheの起動が確認できます。
TomcatとApacheの連携動作設定
TomcatとApacheのコネクタには従来と異なり、新しいModuleが使われるようになりました。同じくTomcatのダウンロードセンタからwebapp-module-1.0-tc40-linux-glibc2.2.tar.gzをダウンロードします。
# cd /usr/local/src # tar zxvf webapp-module-1.0-tc40-linux-glibc2.2.tar.gz # cd webapp-module-1.0-tc40 # cp mod_webapp.so /usr/local/apache/libexec
httpd.confへの設定
server.xml(Tomcatの設定ファイル)に、以下のように記述されていますから、要請とおりにhttpd.confファイルの一番最後にModule load指定を記述します。
The MOD_WEBAPP connector is used to connect Apache 1.3 with Tomcat 4.0
as its servlet container. Please read the README.txt file coming with
the WebApp Module distribution on how to build it.
(Or check out the "jakarta-tomcat-connectors/webapp" CVS repository)
To configure the Apache side, you must ensure that you have the
"ServerName" and "Port" directives defined in "httpd.conf". Then,
lines like these to the bottom of your "httpd.conf" file:
LoadModule webapp_module libexec/mod_webapp.so
WebAppConnection warpConnection warp localhost:8008
WebAppDeploy examples warpConnection /examples/
The next time you restart Apache (after restarting Tomcat, if needed)
the connection will be established, and all applications you make
visible via "WebAppDeploy" directives can be accessed through Apache.
LoadModule webapp_module libexec/mod_webapp.so WebAppConnection warpconn warp localhost:8008 WebAppDeploy examples warpconn /examples/
と言うことは、Web applicationを新規にdeploymentする場合には、WebAppDeploy行を追加しないといけないようです。
検証のために、＄TOMCAT_HOME/webapps以下のdirectoryを以下のようにhttpd.confに追加してみると、きちんとApache経由で出力されています。たとえば、http://dsl.nemuneko.com/tomcat-docs/index.htmlのようにです。ただし、ここで存在しないWebAppをhttpd.confで指定してしまうとApacheの動作が異常になってしまうようです。Port80は開いているのですがHTTPリクエストに対して応答しなくなります。尚ここで$TOMCAT_HOME=/usr/local/src/jakarta-tomcat-4.0.2です。
WebAppDeploy webdav warpconn /webdav/ WebAppDeploy tomcat-docs warpconn /tomcat-docs/
TomcatのHTTPサーバ動作停止設定
server.xmlの中のPort8080の設定部分をComment outします。
<!--
<Connector className="org.apache.catalina.connector.http.HttpConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="60000"/>
-->
動作確認
以上で条件は整いましたが、起動や停止ScriptのPathを通しておいたほうが便利ですので、.bash_profileもしくは.bashrcに以下の記述を追加しておきます。ここにはj2sdkのための設定も含まれています。
export JAVA_HOME=/usr/local/src/j2sdk1.4.0 export J2EE_HOME=/usr/local/src/j2sdkee1.3.1 export PATH=$PATH:$JAVA_HOME/bin:$J2EE_HOME/bin:/usr/local/src/jakarta-tomcat-4.0.2 /bin:/usr/local/apache/bin
Pathの設定を有効にした後で、startup.sh, apachectl startとTomcat, Apacheの順で起動すると、http://192.168.0.9/examples/jsp/index.htmlのようなアクセスが可能になり、ApacheのHTTPサーバにDispatchされたことが分かります。ちなみにこの状態でPort Scanを実行すると、以下のようなPortが開いているはずです。
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Interesting ports on java2.nemuneko.com (127.0.0.1): (The 1538 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 80/tcp open http 8009/tcp open ajp13 Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
しかしさすがにCel400、128MBではメモリもぎりぎり、JSPのコンパイルも遅さを感じます。でもちょっと遅めサイトと思えば我慢できる範囲、メモリだけはJBossのためには増設しないとだめでしょうが。
以上はTomcat(Catalina)がスタンドアローンの場合ですが、JBossと同一VMで動作するように提供されている場合には、設定方法がTomcatのserver.xmlではなくJBossのMBeanを使ったものに変わっています。
HPからも無償ででていますが、ここはOSSで行きたいところです。