こうして、Javaアプレットが注目されなくなっていく中で、Webアプリ開発はサーブレットを使ったものが注目されるようになりました。
1997年にはサーブレットAPIが世の中に出てきていましたが、筆者は1999年ごろにサーブレットを本格的に使い始めています。当時、データベースアプリケーションを作っていたのですが、「データベースアプリケーションといえば、C/Sシステムとして作成」というのが大多数だった時代でした。
しかし、世の中でキャッチアップしている人たちは、いわゆる「3階層システム(3 tier システム、MVCモデル)」の時代へとシフトを始めている最中で、そこにうまくJavaサーブレットは乗ることができて、ブレイクしたように思います。ソフトウェア開発も、デスクトップアプリケーション開発やC/Sシステムの開発が主戦場だったのが、サーバサイドのWebアプリをどう開発をするのか、というところへ移っていったのです。
こういった流れができる前は、筆者は、Javaアプレットをクライアントサーバシステム(C/Sシステム)のクライアントとして位置付けたシステムが作れないかと、検討をしたこともありました。
Javaは登場した時期の早いうちから開発キット(JDK)がWindowsで無償提供されていたこともあり、JDBCによりデータベースアプリケーションも無償で開発できる状況でした。Microsoft Accessのようなデータベースソフトウェアを使ってデータベースアプリケーションを作る方法もありましたが、PostgreSQLなどの本格的なデータベースを使ったC/Sシステムを手軽に開発できる環境としても注目をしていたからです。しかし、Webベースのシステムが主流となり、Apache Tomcat(当時は、Jakarta Tomcat)の出現などもあり、Javaサーブレットを使うようになりました。
さて、3階層システムは、「プレゼンテーション層」「アプリケーション層」「データ層」の3層から構成されるシステムで、このような構成でシステムを構築すると、各層が疎結合となって置き換えがしやすくなり、開発効率が良くなる、運用コストが下がる、といったメリットがあります。業務システムにおいて、「アプリケーション層」にビジネスロジックを実装することにより、ビジネスロジックに変更があった場合の影響を最小限に収めることができます。
各層の実装については特に縛りがあったわけではありませんでした。しかし、Webブラウザの登場により、プレゼンテーション層はWebブラウザが担い、アプリケーション層はApache HTTP サーバと、CGIやサーブレットの組み合わせによるWebアプリケーションが担い、データ層はリレーショナルデータベース管理システム(RDBMS)が担う、という大まかな役割分担が決まってきました。
こうすることで、システムを開発するに当たり、プレゼンテーション層用のアプリケーションを一から開発する必要がありませんし、プレゼンテーション層とアプリケーション層の通信プロトコルを設計したり、通信を実現するソフトウェアを開発することも必要ありません。
Javaの場合は、サーブレットとRDBMSの通信には「JDBC」という仕様を使えばよいので、それを実装するJDBCドライバとRDBMSも選択できる状況でしたこのため、Windowsでデータベースを使ったWebアプリケーションが簡単に開発できました。これは大きな影響がありました。
ODBCデータソースを用意したうえで、JDBC-ODBCブリッジを使って、ローカルマシンでデータベースを利用するWebアプリケーションの開発ができましたから、教育の分野などでは助かったはずです。学習者はOracleのような本格的なRDBMSを用意しなくても気軽にデータベースを使ったWebアプリ開発を試してみることができたのです。
J2EE(いまのJava EE)のデザインパターンが早くから確立したことも影響がありますが、こういった手軽さがJavaサーブレットがブレイクした理由の1つとして挙げられるのではないかと筆者は考えています。
手軽さについて考えると、Javaの「Write Once, Run Anywhere」というキャッチフレーズも影響があったはずです。
デスクトップアプリケーションの開発においては、このキャッチフレーズは完全に有利に働いたとはいえませんでした。Javaの標準であるAWTのGUIライブラリでは、最も貧弱なGUI機能を持つプラットフォームに合わせるということになったからです。
AWTは豊富なGUIコンポーネントの利用に慣れてしまっていたWindows開発者を引き付けることはできませんでした。そのため、サン・マイクロシステムズは後で豊富なGUIコンポーネントをサポートするSwingライブラリを提供するようになっています。
一方で、サーバサイドのWebアプリを開発するために必要な機能については、Javaの「Write Once, Run Anywhere」は非常に有利に働いたと考えられます。当時はテキスト処理といえばPerlの方が圧倒的に有利でしたから、テキスト処理が多いWebアプリケーションの開発ではCGIを使ったものの方が多くありました。それを考えると、テキスト処理がそれほど強くなかったJavaがあそこまで成功したのは不思議な感じもありますが、筆者はWindows開発者を引き込めたというのが大きいと考えています。
PerlはUNIX系コマンドを利用した処理が得意であるため、Perlアプリケーションを開発するためには、自然とLinuxなどUNIX系のOSで開発することになります。Emacsなどを使えば、Perlアプリケーションの開発もかなり効率よくできますが、その環境をWindows上に構築するのは大変です。つまり、UNIX系開発者でないと、Perlアプリケーションを開発するのは難しかったのです。
一方、Javaであれば、普段からWindowsをよく使っている開発者が、わざわざLinuxマシンなどを用意しなくても、Windows上でWebアプリケーションを開発して、サービスを提供する段階になってからLinuxマシンへ開発したWebアプリケーションを配備すればいいだけです。
Windowsに慣れていて、Webアプリケーションに興味を持った人にとって、JDKとTomcatをインストールすれば、すぐにWebアプリケーション開発に挑戦できるというのは、非常に魅力的だったはずです。
さらに、「JDBCの手軽さ」で説明をしましたとおり、JavaではWindows上で気軽にデータベースを使ったWebアプリケーション開発が可能でした。PerlでもLinuxなどであれば気軽にデータベースを使ったWebアプリケーション開発が可能でしたが、WindowsでもLinuxでも、どちらでも使えるJavaに魅力を感じた人が多かったのでしょう。結局のところ、繰り返しとなりますが、「Write Once, Run Anywhere」がPerlとJavaの大きな差としてあったのだと筆者は考えています。
サーブレット開発が普及したころ、Javaの開発環境で革命的とも思える出来事がありました。Eclipseの爆発的な普及です。Eclipseを知るまでは、「JDK+Emacsを超える無償の良い開発ツールがなかなか出てこないなぁ」と思っていた覚えがあります。
JavaのIDEとしては、ボーランドの「JBuilder」やサン・マイクロシステムズの「Forte for Java」(NetBeans(後述)ベースのIDE、後に「Sun ONE Studio」、現在は「Sun Java Studio」)などがありましたが、こういったPure Java実装の開発環境は、実行するのにメモリが多く必要で、CPUも高性能なものが要求されるため、いま1つ使われないという状況でした。
そんな中、Eclipseがオープンソースとして登場したのです。
Eclipseは「SWT」という独自のGUIライブラリを使っているため、SWTが提供されているプラットフォームでないと動作しません。そのため、純粋なJavaデスクトップアプリケーションとはいえませんが、Pure Java実装の開発環境に比べて、圧倒的に速いというのがJava開発者たちに支持されました。
しかも、有償な開発環境が多く、無償であってもソースが公開されていないといった状況の中、あれだけの機能を持ったIDEがオープンソースで無償利用できるようになった、というのもインパクトが大きかったです。この影響からか、サン・マイクロシテムズは「NetBeans」をオープンソースコミュニティで育て、その成果を自社製品の「Sun Java Studio」へフィードバックするという方針に転換しました。ソフトウェア開発に当たって、こういった方針をとるものがいまはいくつかありますが、その流れは、このころにできたような気がします。
次ページではいよいよ、ドラッガブルアプレットの作成の仕方を解説します。
Copyright © ITmedia, Inc. All Rights Reserved.