３．Java applet と Java Servlet
４．各種アプリケーションサーバー(2000.07.30追記)
５．Java Servlet + JSP + EJBが本命か？(2000.12.30追記)
６．具体的な開発例 (工事中)
WebブラウザからOracle等のRDBへリンクして接続する方法としてはCGI(Common Gateway Interface)を利用する手法が最も古典的です。しかしこの手法はCGIで呼び出されるプログラム例えばPERLなどのプロセスがサーバープログラムの外部プロセスとして起動される事からパフォーマンス上の問題があります。アクセス頻度の大きいサーバーとなるとすぐ破たんしてしまいます。
そこでＣＧＩに変わるものとして幾つかのミドルウェアと呼んでよいソフトウェアが出現しました。例えばNetscape社のServer Side Javascript(SSJS)であったりMicrosoft社のActive Server Pages(ASP)などです。サーバーの内部プロセスとして処理するこれら手法の出現で、CGIより格段に良いアクセス環境が出現した訳ですが、更に最近ではServerプログラムそのものにミドルウェアを組み込んだ統合環境とも言うべきアプリケーションサーバーへ流れが移っているようです。例えばNetscape社はNAS(Netscape Application Server)、Oracle社はOWS,WASの後継であるOAS(Oracle Application Server)といった製品です。アプリケーションサーバーは機能面で優れているものの価格的には高い側面もあり、それぞれの利用場面に応じて選択して行くこととなります。
2.1 SSJS (Server Side Javascript)
SSJSは以前はLivewireの呼称で呼ばれていたNetscape社のEnterpriseサーバー等で利用可能な技術です。Javascriptは基本的にブラウザ側のものと同じ文法ですが、事前コンパイルが必要です。Oracleとの接続はネイティブで可能な他、ODBCドライバ経由（WindowsNTの場合）でも可能です。ODBCドライバを経由してACCESSやEXCELなどともリンクできます。
Netscapeサーバーを元々利用しているユーザーであれば新規の投資が全く不要で且つ設定も容易であるため、検討に値する手法であると言えます。
参考書 「LiveWire入門」ネティズム工房著 プレンティスホール出版
2.2 ASP (Active Server Pages)
ASPはMicrosof社のIISサーバー等で利用可能な技術です。Microsoft社という事でWindows環境しか提供しておらず、SSJS等と比較して適応範囲が狭くなります。
ASPでOracleと接続する場合ODBCドライバかOracle社のOO4O(Oracle Object for OLE)を利用します。言語としてはVBscriptかJscript(Microsot版のJavascript)が選択出来ます。デバッグが割と容易であるので、Windows環境に限定しているユーザーであれば選択の余地があります。
参考書 「IIS ASPスクリプティング」佐藤親一著 オーム社
3.1 Javaアプレット
長所
① サーバーサイドの資源を必要としない。
② JDBCという標準APIが使える。短所
① ブラウザの種類・JVMのバージョンの制約を受ける。
② クラスファイル(含むJDBCドライバ)転送の時間が必要。仮にイントラネット環境での利用の場合は、ブラウザを固定してしまいクラスファイルを事前配布してしまう事も可能なので上記の短所は無くなります。一方でクラスファイルのバージョンアップ時の保守性など新たな問題も発生します。
Oracleの場合JDK1.1に対応するタイプ４のOracle Thin Driverが標準で添付されており、サンプルプログラムも付いています。開発上の問題は全くありません。参考書 「実践JDBC」菊田英明著 オーム社
3.2 Java Servlet
Java2以降標準APIとなったServlet APIを利用します。JDK1.1の場合は別途JSDK(Java Servlet Development Kit)が必要です。Oracleとの接続にはJDBCドライバを利用します。前述のアプレットと異なりブラウザに依存しないほか、クラスファイルの転送時間といった問題もありません。Javaに拘って選択するのであれば有力な候補と言えます。但しアプレットと比較して話題性が無かったせいか、実例が少ない面はあります。
ServletはSun Microsystems社のJavaWebServerで使用するのが設定不要で楽ですが、jserv + ApacheあるいはJRun + Apaxhe,IIS,Netscapeといった環境等で利用可能です。後者の場合jservやJRunを各サーバープログラムに組み入れる設定作業が必要となります。
参考書 「Java Servlet」原田洋子著 秀和システム社
4.1 概要
さて2.でSSJSやASPにて直接DBをハンドリンクする方法をご紹介して間が空いているうちに新しい技術が進展してしまいました。SSJSやASPで直接DBをハンドリングする手法は小規模向けには問題が無いものの、大規模向けにはJSP/Servlet/EJBという流れとASP/COM+という二つの流れに集約されてきました。
ASP/COM+のCOM+はComponent Object Model plusの略称ですが、従来はCOM/DCOMと呼ばれていたマイクロソフト社の技術です。よってこの手法はWindows環境では有力なものの、他の環境での適用には問題があります。
JSP/Servlet/EJBはJava環境での手法ですが、Javaそのものがマルチプラットフォームということで各種環境への適用が可能です。
4.2 具体的なアプリケーションサーバー
4.2.1 ASP/COM+系
－Microsoft Windows 2000 DNA Server
4.2.2 JSP/Servlet/EJB系
－Silver Stream Application Server
－iPlanaet Netscape Application Server
－Inprise Application Server
－Oracle Application Server
－IBM Websphere Application Server
－Fujitsu INTERSTAGE
－NEC WebOTX (ASP/COM+にも対応)
５．Java Servlet + JSP + EJBが本命か？(2000.12.30)
さてこの章のタイトルは随分前につけたもので当時は本命なのかどうか自信はなかったのですが、今や数多くのアプリケーションサーバーがServlet+JSP+EJBという組合せを実装してしまったのであり、本命と捉えて間違いありません。
5.1 開発効率面
CGIと比較したServletのパフォーマンス面はさておいて、開発効率面を見てみます。既にJavaが言語面での優位性を獲得した現在Java Servletの選択に迷いはないでしょう。しかもJSPの登場でWeb上での表現というプレゼンテーション部分を切り分ける事が可能となり開発効率を上げています。それからEJB(Enterprise JavaBeans)ですが、これは従来のJavaBeansとは別物と考えた方が混乱がなくて良いでしょう。EJBはシステム側でユーザーセッションやトランザクション管理などの機能を提供し、開発者がこうした詳細なコーディングを行なう必要を無くしています。当然その分開発効率を上げています。
5.2 他技術との比較
前章で書いたようにServlet+JSP+EJBの対抗馬はASP/COM+ですが、これはマルチプラットフォームを選択するかWindows環境に限定するのかという所に集約されます。限定的に使うB2Bシステムなら良いかも知れませんが、B2Cだとするとある日突然大量アクセスに遭遇する不幸(いや幸運か？)も当然予想されます。当初WindowsNTでスタートしたとしても、そうした際にNTからUNIXマシンへ切替えられる可能性を残すのかどうかです？ 仮に私がシステム構築するのであれば当初Linuxのアプリケーションサーバーで稼動させ、事後必要に応じて商用UNIXサーバーへの移行を考えます。仮にNTでスタートさせるとしてもWindowsに限定される技術(ASP/COM+)の採用は控えます。つまり結論的にServlet+JSP+EJBの組合せが本命だと考えます。