その２	その３	Ｎｏ Ｌｉｎｋ	Ｎｏ Ｌｉｎｋ	Ｎｏ Ｌｉｎｋ

　とはいえ、サーブレットが第一世代の技術であることには変わりありません。同世代の他の技術と同様に、ソースコードから出力されるＷｅｂページを想像しにくく、サーブレットですべてまかなおうとすると保守性を上げにくいという弱点があります。
　そこで、米Ｓｕｎ ＭｉｃｒｏｓｙｓｔｅｍｓはほどなくＪａｖａ環境に第二世代の仕組みを導入しました。それがＪＳＰです。ＪＳＰのプログラムはＡＳＰやＰＨＰのプログラムと同様に、ＨＴＭＬ文書に独自のタグでスクリプトを埋め込んだテキスト･ファイルです。（リスト１）。ＪＳＰページは実行時にコンパイルされ、サーブレットと同様にＪａｖａのクラスとして実行されます。
　当初リリースされたＪＳＰ １．ｘでは、ＪＳＰページに埋め込むプログラミング言語がＪａｖａ言語そのものであったため、デザイナが編集することは容易にはできませんでした。しかし、２００３年１１月にリリースされたＪＳＰ ２．０では、データの簡単な加工に特化した「式言語」という新しい言語が搭載されています。
　ＪＳＰ ２．０の登場で、プログラマはＪａｖａを駆使してロジックを作り、デザイナはプログラマが作ったロジックの処理結果を式言語で参照しながら使いやすいユーザー・インターフェイスをＪＳＰで構築する、という「第三世代」技術に沿った明確な役割分担が可能になりました。

●ＪＳＰ ２．０で第三世代の仕組みを実現した

　第三世代の技術の後、Ｗｅｂプログラミングは今後どのように進化していくのでしょうか。最後に、クライアントとＷｅｂサーバーそれぞれの視点から、Ｗｅｂプログラミング技術の未来を探ってみましょう。最初はクライアント側です。
　第三世代がもたらしたプレゼンテーションとロジックの分離は、クライアント側にも大きな影響を及ぼしました。クライアントに必ずＷｅｂブラウザを利用するという図式が崩れつつあるのです。
　これまでＷｅｂプログラムは、「Ｗｅｂサーバー側でＨＴＭＬデータを動的に生成する」という前提で進化してきました。ＨＴＭＬデータはパソコンや携帯電話などインターネットへアクセスできるほとんどのデバイスで解釈/表示されます。Ｗｅｂアプリケーションが盛んに開発されるようになった背景には、どこでも表示できて、そこそこ表現力が高いＨＴＭＬの存在が大きく貢献しています。
　ところが、実際にＷｅｂアプリケーションを作ってみると、ＨＴＭＬを表示するだけのブラウザよりも、専用のクライアント・アプリケーションの方がずっと使いやすいという状況もたくさんあることがわかってきました。多量のデータを素早く入力したり、帳票を紙に印刷する処理などはブラウザとＨＴＭＬの組み合わせではなかなか思うように作れないのです。
　そこで出てきたのが、ＨＴＴＰを使って通信するというＷｅｂの仕組みは保ちつつ、ブラウザより表現力が高く、操作性のよいクライアント・ソフトウェアを使うという動きです。このようなソフトウェアを「リッチ・クライアント（表現力が高いクライアント）」と呼びます。
　リッチ・クライアントの代表選手が米ＭａｃｒｏｍｅｄｉａのＦｌａｓｈです。Ｆｌａｓｈはアニメーションの作成/再生環境として有名ですが、最近ではリッチ・クライアントのアプリケーション開発ツールとして脚光を浴びています。ＡｃｔｉｏｎＳｃｒｉｐｔというスクリプト言語の処理系を備え、メニューや入力ボックスなど様々なユーザー・インターフェイス部品を用意しており、ＨＴＭＬを使うよりずっと操作性の良いクライアントを作れるからです。ページを書き換えることなくＨＴＴＰサーバーとデータをやり取りすることもできるので、ネットワークへの負担がいたずらに大きくなるという心配もいりません。
　Ｆｌａｓｈのプログラムは、ＦｌａｓｈＰｌａｙｅｒというブラウザ上のプラグインで実行しますが、リッチ・クライアントには、ブラウザとは別のソフトウェアをクライアントに配布する、というアプローチもあります。アクシスソフトの「Ｂｉｚ/Ｂｒｏｗｓｅｅｒ」や、．ＮＥＴ技術を使ったマイクロソフトの「スマート・クライアント」などです。どちらも、ＨＴＭＬベースのＷｅｂアプリケーションの限界を打ち破る方法として、今後、要注目の分野です。

●プレゼンテーションの独立　クライアントが非ＨＴＭＬ化

　サーバー側では誰にどのセッションＩＤを割り当てたかを覚えておけば、後はリクエストに含まれるセッションＩＤを見ることで誰からのリクエストなのかを判別できます。
　実は、第一世代の技術でもこの仕組みを作り込むことはできます。しかし、第二世代の技術は、特に意識しなくてもセッションを自動的に管理し、同じユーザーからのリクエストを連続的に処理できるのが大きな特徴です。
　複数のＷｅｂプログラムを統合的に運用できる第二世代の技術によって、ユーザー一人ひとりの操作に臨機応変に対応できる「Ｗｅｂアプリケーション」と呼ぶにふさわしいＷｅｂプログラムを簡単に作れるようになったわけです。

　ここでは、日経ソフトウェア２００４年８月号に掲載されていた『基礎からまるわかりWebプログラミング（後編）』斎藤国博氏の文書から抜粋したものを掲載します。あくまで私のメモですが、参考にされたい方があれば一見するのも価値があるかもしれません。
先ずは前編の内容はどんなものかというと以下のようになります。

〔ポイント１〕最初は動的なWebサイトから始まった
　一般的にWebプログラミングとは、WebブラウザとWebサーバーで構成された環境において、Webブラウザにデータ（レスポンス）を送り出すWebサーバー側のプログラムを作ることを意味します。（以下、Webプログラム）HTMLファイルなどの形で予めレスポンスを用意しておく「静的なWebサイト」に対し、Webプログラムを使ってレスポンスを生成するサイトを「動的Webサイト」と呼びます。（図１）

〔ポイント２〕第一世代では文字列出力機能でHTMLを生成していた
　初期のWebプログラムは、C言語のｐｒｉｎｔｆ（）関数やPealのｐｒｉｎｔ文など、汎用プログラミング言語の文字列出力機能を使ってＨＴＭＬを生成していました。これを便宜上「第一世代」技術と呼びます。この形態のＷｅｂプログラムは手軽に作れるため現在でも数多く作られていますが、機能が複雑になるとどのようなＷｅｂページを生成するのかわかりにくいという弱点があります。そのため、大規模なＷｅｂプログラムの開発には向きません。

〔ポイント３〕ＨＴＭＬの中にスクリプトを埋め込んだのが第二世代
　第一世代の技術の弱点を埋めるべく登場したのが、ＨＴＭＬの文書の中にスクリプト（ソースコード）を埋め込む形態の「第二世代」です。第二世代の技術では、プログラムを記述するファイル形式が、汎用プログラミング言語の実行形式（ｅｘｅ）ではなくＨＴＭＬ形式になりました。ブラウザからリクエストを受けると、サーバーはＨＴＭＬの部分をそのまま出力し、スクリプトが埋め込まれている部分をスクリプトの実行と結果に置き換えて出力しします。《ＡＳＰ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ）、オープンソース・ソフトウェアのＰＨＰ（Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ）》
どのようなＷｅｂページを生成するのかを想像しやすく、第一世代の技術に比べて保守しやすいコードを書くことができます。

●Webプログラミング技術の現在そして未来

　ここからは、上記とは視点を変えて、Ｗｅｂプログラムのコードを「どう実行するか」という視点からＷｅｂプログラミング技術を見ていきます。
すると、第二世代の技術が第一世代に比べ、コードの書き方を変えたこと以上に大きな進歩を遂げているのが見えてきます。
　それは、第二世代の技術によって「複数のＷｅｂプログラムをまとめて、全体を一本の”Ｗｅｂアプリケーション”として処理できるようになった」ということです。
　Ｗｅｂアプリケーションでは、クライアント（Ｗｅｂブラウザ）とＷｅｂサーバーのやり取りは、
（１）クライアントがサーバーにリクエストを送る
（２）サーバーがリクエストに対応したレスポンスを用意する
（３）サーバーがクライアントにレスポンスを送る
----でワンセットになります。クライアントとサーバーの間では、このようなやり取りが必要になるたびにＨＴＴＰで接続を確立し、理ックエストとレスポンスを送受信して、最後に接続を切るという処理を繰り返します。複数のページにまたがるサービスがあれば、ページが切り替わるごとにリクエストとレスポンスが発生するわけです。
　ところが、Ｗｅｂサーバーには何人もの人が同時に並行してアクセスルしてきます。リクエストが連続しているからといって、同じ人からのアクセスである保証はありません。静的なＷｅｂサイトならばリクエストを右から左へ処理していけば済みますが、情況に応じてレスポンスが変わる動的なＷｅｂサイトではそうはいかないでしょう。そこで、どのリクエストとどのリクエストが同じ人から来たものかをきちんと把握して、それぞれの人に向けて適切なレスポンスを返す必要が出てきます。これを「セッション管理」と呼びます。
　セッション管理の原理は単純です。セッションを識別するための合言葉（セッションＩＤ）をレスポンスに埋め込んでおいて、クライアントが次にアクセスしてくるときにそのセッションＩＤを言ってもらえればいいのです。（図２）

●第二世代から、複数のＷｅｂページを一つのシステムに統合できるようになった

　第一世代の代表的なシステムが、Ｊａｖａサーバーサイド技術であるサーブレットとＪＳＰ（ＪａｖａＳｅｒｖｅｒＰａｇｅｓ）です。これらのサーバーサイドＪａｖａ技術はいきなり登場したわけではなく、他のＷｅｂプログラム技術と同様に段階を追って進化してきました。サーバーサイドＪａｖａは現在のＷｅｂアプリケーション構築プラットフォームとして非常に重要ですから、復習もかねてサーブレットとＪＳＰの進化を少し詳しく解説します。

（----プレゼンテーションとロジックの分離は、Ｗｅｂプログラミングに共通する課題です。サーバーサイドＪａｖａのほか、ＡＳＰの後継技術であるＡＳＰ．ＮＥＴには、論理的な一枚のページをプレゼンテーションとロジックに分けて別々のファイルに記述できる「コード・ビハインド」という仕組みが組み込まれています。ＰｅｒｌやＰＨＰなどでも、ＨＴＭＬ部分を最終的な出力に近い形で作り、可変部分を一括して置き換えられるためのライブラリなどが作られています。----）

　初めに登場したのはサーブレットです。サーブレットはＪａｖａ版の第一世代Ｗｅｂプログラミング技術です。つまり、出力メソッドでＨＴＭＬ形式の文字列を一行ずつ書き出していくことでレスポンスを作ります。例えば”Ｈｅｌｌｏ、Ｗｏｒｌｄ”というメッセージをサーブレットで出力する場合は、ｐｒｉｎｔｌｎ（）メソッドの引数が生成されるＨＴＭＬデータになります。
　このプログラムの実行速度はＣＧＩ（ＣｏｍｍｏｎＧａｔｅｗａｙＩｎｔｅｒｆａｃｅ）のプログラムに比べてずっと高速です。ＣＧＩではリクエストがあるたびに実行形式ファイルを起動するので、極めて大きなオーバーヘッドが掛かります。一方、サーブレットの実体はＪａｖａのクラス・ファイルです。Ｗｅｂサーバーに「サーブレット・コンテナ」と呼ぶプログラムをあらかじめ組み込んで運用します。個々のサーブレットでの処理が必要になると、サーブレット・コンテナがそのサーブレットを読み込んで実行し、サーブレットが生成したＨＴＭＬデータを受け取ってクライアント（ブラウザ）に送り返します。
　一度読み込まれたサーブレットは、コンテナが動いている間は基本的にそのままシステム上に残っています。つまり、最初の一回を除けば、単なるＪａｖａのメソッド呼び出しと同じだけのオーバーヘッドで動作するので高速なのです。（図３）

●サーバーサイドＪａｖａも第一世代から始まった

　第三世代技術によって、プレゼンテーションとロジックを明確に分けて記述できるようになり、より大規模なWebアプリケーションを効率よく開発できるようになりました。しかし、Ｗｅｂプログラミング技術の進歩が止まったわけではありません。新たにまた一つ問題が出てきました。
　Ｗｅｂアプリケーションの処理内容が複雑になると、そこに含まれる多数のページの流れを管理するのが難しくなってしまうという問題です。
　一般にＷｅｂアプリケーション内では、あるページの次ぎの処理がどのページにあるかという情報は、呼び出し元のページに＜ＦＯＲＭ＞タグのＡｃｔｉｏｎ属性などを使って書き込みます。つまり、ページ同士の関係を記述したリンクは個々のページに分散した状態になっているわけです。関係を変更したい場合には個別のページを修正しなければなりません。つまりページ数が多くなるほど保守性はどんどん低下します。
　この問題を回避するため、サーバーサイドＪａｖａなどではリクエストを処理する機能を一個のサーブレットに集中し、状況に応じてレスポンスを適切なＪＳＰページに振り分けるのが定番のテクニックになっています（図４）。ＪＳＰページからは必ずこのサーブレットにリクエストを送り、次にどのＪＳＰページを呼び出すかの判断はサーブレットに任せてしまうのです。
　問題は、このサーブレットの実装が容易ではないことです。どのページから来たリクエストかを判断し、対応する処理を実行して次ぎのＪＳＰページをレスポンスとして送り返す、と書いてしまえば簡単ですが、大きなＷｅｂアプリケーションになれば、処理を振り分けるためのｉｆ文が延々と続く複雑なコードになってしまいます。しかもこのサーブレットは使い回しがきかず、Ｗｅｂアプリケーションを作るたびに同じような構造のサーブレットを何度も作る羽目になります。
　そこで登場したのが「フレームワーク」という考え方です。リクエストを受け付けるサーブレットの機能から動作の枠組み（フレームワーク）部分を残して、実際のページ同士の関係を設定ファイルとして与えようというわけです。こうすれば、ページ・フロー（Ｗｅｂページの画面遷移）が変わっても、設定ファイルを編集するだけで済みます。
　フレームワークには、アプリケーションの品質を向上させ、開発期間を短縮できるというメリットもあります。Ｗｅｂアプリケーションは、社会インフラから企業の各種サービスまで、あらゆるジャンルのシステムで使われていますが、大規模・複雑化するにつれ、高品質への要求は強まる一方です。また１ヶ月〜３ヶ月という短納期の開発も少なくありません。フレームワークを利用することで、プログラマがコードを書く部分を最小限に済ませ、高品質と短納期をいっぺんに実現しようというわけです（図５）。
　サーバーサイドＪａｖａ向けのフレームワークではＴｈｅ Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎの「Ｊａｋａｒｔａ Ｓｔｒｕｔｓ（ジャカルタ・ストラッツ）」が有名です。またＡＳＰの後継技術であるＡＳＰ．ＮＥＴは、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ．ＮＥＴを使うことでページ・フローをほとんど意識することなく複雑なＷｅｂアプリケーションを構築できるフレームワーク「Ｗｅｂ Ｆｏｒｍｓ」を搭載しています。このように、今後のＷｅｂプログラミングは、フレームワーク抜きには語れなくなるでしょう。

●ページ同士の関係を集中管理する

　クライアント側がリッチ・クライアントというアプローチを志向しはじめたように、Ｗｅｂサーバー側も新しいアプローチを探り始めています。プレゼンテーションの機能そのものを公開してしまおうとする考え方「Ｗｅｂサービス」です。
　Ｗｅｂサービスは、ネットワーク越しに別のプログラムからアクセスされることを想定したＷｅｂプログラムです。Ｗｅｂアプリケーションが、人間が「目で見て操作する」形態を想定しているのに比べ、Ｗｅｂサービスはコンピュータ同士が利用し合うためのプログラムと考えればいいでしょう。Ｗｅｂアプリケーションは複数のＷｅｂサービスによって構成されるようになるわけです（図６）。
　あるコンピュータが、ネットワーク上にある別のコンピュータからＷｅｂサービスを使って呼び出した情報をどのように加工するかは、呼び出したコンピュータ（クライアント）の自由です。例えば、天気情報を公開しているＷｅｂサービスを呼び出して、天気予報を見やすく加工して表示してもいいですし、定期的に情報を引き出して気温変化の統計をとっても構いません。使われ方は、Ｗｅｂサービスは規定していないのです。
　この仕組みを利用すれば、アプリケーションの大部分をＯＳのネイティブ・コードで実装し、Ｗｅｂサーバーでの処理が必要な部分だけＷｅｂサービスを利用して処理するといったシステムを開発することも現実になるでしょう。
　このようなＷｅｂサービスの考え方は、最近ではＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ；サービス指向アーキテクチャ）として体系化され、米ＩＢＭはじめとする多くのソフトウェア・ベンダーが次世代のＷｅｂアプリケーション構築技術として普及を進めています。リッチ・クライアントと並んで、今後、ますます重要になる技術と言えるでしょう。
　　　　　　　　☆　　　　　　　　☆　　　　　　　　☆
　以上、過去のＷｅｂプログラミングから最新のＷｅｂサービスまで、複雑に見えるＷｅｂプログラミング技術がどうして今のような形になったのかを解説してきました。ここまで読んでいただけた方なら、Ｗｅｂプログラミングの基本知識は身に付いているはずです。ぜひ、興味のある分野から、Ｗｅｂプログラミングの勉強を始めてみてください。

●ＷｅｂサービスはＳＯＡへさらに進化