当時Perlという言語がプログラミングで主に使用されていましたが、テキストを処理することに特化した言語であったため、大規模で複雑化したWebアプリケーションの開発にはあまり向いていませんでした。

当時のCGIはWebブラウザからリクエストが発生したタイミングでプロセスを起動していましたが、当然リクエストの発生ごとにプロセス起動の時間が発生してしまいます。

1日に100件程度のアクセスでは問題ないのですが、数万件のアクセスが発生した場合プロセスの起動回数が多くなり、処理が追いつかない事態が発生しました。

この結果Webサイトにアクセスしても画面の表示が遅く、ユーザーが目的の情報を得られない事が多く発生するようになりました。

CGIと比較したJavaサーブレットの利点を説明しましたが、その他にもJavaはソースコードを直接コンピュータの機械語にコンパイルせず、仮想的なコンピュータの機械語（JavaVM）にコンパイルするため特定のOSやベンダーに縛られずにプログラムが動作するという利点があります。


例えばデスクトップアプリケーションの場合、Windows用、Mac用といった形に分かれて販売・配布されており、それぞれ異なるプラットフォーム上では動作しませんが、Javaはそのような制限が無く、
異なる環境で同一のプログラムを実行することが出来ます。


また、開発者にとっても利点があり、従来はアプリケーションを動作させるプラットフォームと同じ環境で開発することが原則でしたが、Javaは開発は使い慣れたWindowsの開発PCで行い、動作環境は本番稼働環境と同一のLinuxマシンで行うという方法も出来るようになりました。

JavaサーブレットはCGIに変わる技術として広く普及しましたが、開発者の間で前述のような問題点が認知されるようになり、それらを解決するため「JSP」という技術が開発されました。

以下は税込価格を表示させるプログラムをサーブレットとJSPで比較したソースコードです。


JSPでは「<%」「%>」で囲われた箇所に動的に出力したいJavaプログラムを記述することが出来ます。

JSP内部に記述されたJavaプログラムは「スクリプトレット」と呼ばれます。（上図の太字部分）

ページを構成するHTMLをベースとし、変更の可能性がある箇所を上記のようにJavaで記述することにより、プログラマとWebデザイナが効率的に分業出来るようになりました。


サーブレットの記述言語はJavaで、JSPのメイン言語はHTMLという点が大きく異なる部分ですが、両者の弱点を補うように使用されるプログラムと言えるでしょう。

そのため「サーブレット／JSP」と一括りにして語られることが多いです。


また、サーブレットはコントローラー的役割を、JSPはビュー的役割を担うので、指示出しが得意なサーブレット、画面表示が得意なJSPとなりそれぞれ得意分野が異なります。

サーブレット／JSPの登場によりWebアプリケーション開発はとても楽になりました。

しかしネットショッピングサイトや証券取引システムなどを筆頭に、Webアプリケーションが複雑で大規模になるにつれ開発は非常に大変な作業を伴うようになります。


また、システムの大規模化に伴い開発プロジェクトに携わる人員が非常に多くなったことにより、開発者間の意思疎通がおろそかになり、各々で独自の処理を実装することも増えてきます。

その結果それぞれのプログラムを結合しようとした際に上手く結合できなかったり、同じような処理がいくつも作成されていたりと、様々な不整合が発生し始めます。

大規模システムの開発には大人数の開発者が必要ですが、前述のコミュニケーション不足も含め、開発者それぞれの知識量やアルゴリズムの考え方がバラバラな事もあり、前述の通り効率の良い開発が難しくなってきます。

このような状態を解消するためには、頻繁に使用される処理を部品化し再利用する考え方が有効で、この部品化された処理を「ライブラリ」と呼びます。


例えば消費税を計算する処理を必要とする画面が複数存在し、それぞれの画面の開発者が各々で計算処理を実装したとします。

そして同じ金額で消費税計算した結果、全員の計算結果が異なってしまいました。

この時点でどの開発者が作成した処理が正しいのか検証する必要があり、正しい処理が判明した後は誤った処理を実装した開発者は修正作業に追われ、本来の業務に支障をきたすことになります。


仕様変更により計算処理の内容を修正する場合も、該当する全ての画面に手を加える必要があり、対象画面の調査と修正作業に多くの時間を費やすかもしれません。

また、複雑なアプリケーションの場合は調査不足により修正漏れが発生することもあります。


ここで消費税の計算処理を部品化（ライブラリ）し、計算処理を行う画面からこの部品を呼び出すようにコーディングすることで、実装に伴うテストや不具合の修正、仕様変更に費やす時間を大幅に短縮する事ができるだけでなく、アプリケーションの品質向上にもつながります。