本講義では、Webコンピューティングに関する様々なトピックを扱います。初日はWebコンピューティングの基礎として、WWWの歴史と仕組み、Webの表現技術としてのHTML、CSS、JavaScript等について解説し、実際にWebのコンテンツを作成する演習に取り組みます。
２日目は、Webアプリケーションを理解するために必要な知識を学びます。Webアプリケーションを記述する各種の言語を紹介し、さらにWebアプリケーションの基本的な構造や要素技術を学びます。また具体的なWebコンピューティングの事例を説明し、実際にCMSアプリケーションの構築を演習で学びます。
３日目は関連知識や最新の動向について学習します。Webアプリケーションと密接に関連するオープンソースソフトウェアの動向、リッチクライアント化するWebコンピューティングの潮流、Web 2.0と呼ばれる最新動向とその基礎を成すXMLの概論など、様々な話題を扱います。
本講義では、WebアプリケーションやWWW環境を高度に利用したコンピュータ活用のことを「Webコンピューティング」と定義します。
現代では、コンピュータ活用方法は多岐にわたっています。デスクトップアプリケーションの利用、クライアント・サーバシステムといった比較的身近なものから、基幹システム、レガシーシステムといった企業の基幹部分で利用されるコンピューティングもあります。あるいは様々な機器に組み込まれて利用される組込みシステムや、新しいコンピュータ利用方法として着目されているウェアラブルコンピューティング、ユビキタスコンピューティングといった利用方法があります。
Webコンピューティングは、クライアント・サーバシステムの延長線上に位置付けられるシステムと考えることもできます。サーバとは、ネットワーク経由でアクセスすることによって何らかのサービスを提供するコンピュータのことを指し、そのサービスを利用する側のコンピュータがクライアントです。一般的にクライアントはユーザインタフェースを備えており、ユーザはクライアントから「リクエスト」を入力します。ネットワークを介して送られたリクエストはサーバで処理されてクライアントに返送され、クライアント側で画面に表示することでユーザに処理結果を伝えます。
Webコンピューティングにおいて、サーバとクライアントは、それぞれWebサーバとWebブラウザが相当します。
Webアプリケーションとは、Webの仕組みを利用してイントラネットやインターネット上で提供されるアプリケーションサービスのことを言います。様々なサービスがWebアプリケーションとして提供されており、電子商取引やオンラインバンキング、オンライントレードといったビジネスの中心的アプリケーションは代表的なWebアプリケーションのひとつです。また電子掲示板やSNS (Social Network Service)、コンテンツ管理システム（CMS, Contents Management System）やe-LearningなどもWebアプリケーションとして提供されています。これらのWebアプリケーションは全て、端末としてWebブラウザを利用することが想定されています。
Webコンピューティング以前は、サーバとクライアントにそれぞれ専用のシステムを用いるクライアント・サーバシステムが主流でした。専用端末が用いられたように、ハードウェアのレベルで専用のクライアントが利用されていたものもあります。その後PCが一般的になりPCで動作する専用クライアントに切り替わり、さらにWebのプロトコルを用いたWebコンピューティングに移るようになりました。WebコンピューティングではWebサーバとWebブラウザの利用が主流でしたが、最近になりリッチクライアントが注目されています。このシステムではまた個別のクライアントが利用されるようになり、一見、先祖返りのように見えます。ただし標準的なプロトコルで様々なクライアントを実現しようという考え方が昔と異なります。
Webコンピューティングの詳細を解説する前に、インターネットとWWWの歴史を振り返ります。インターネットは1970年前後にその原型が現れました。もともとは米国のDARPAが研究開発を進めたコンピュータネットワークであるARPANETがその発端です。まず大学間のコンピュータを結ぶことから、インターネットの研究開発が始まりました。日本では1984年に東京大学や慶應義塾大学が参加したJUNETがその始まりです。
その後、ARPANETがNSFnetに移行し、90年代には商用利用が拡がりました。日本ではさらにWIDEプロジェクトが始まりNTTが積極的にネットワーク化を進めました。90年代半ばにネットワーク機能を標準で搭載したWindows 95が登場し、爆発的に普及したためインターネットの個人利用が拡がりました。同時に、当初は学術利用が中心だったインターネットも商用利用が主流となり、現在の状況に至っています。
さらにWWWの歴史を振り返る前に、WWW以前の状況はどうだったかを、簡単に紹介しましょう。WWWが登場する前は、あるデータを他人に公開する手段として一般的に利用されていたサービスはanonymous（匿名）FTPと呼ばれるものでした。FTP（File Transfer Protocol）とはファイル転送のプロトコルであり、通常は一対一のファイル転送を実現するプロトコルです。通常は、特定のアカウントを利用して信頼できる相手の間でファイルをやりとりするものですが、匿名のゲストアカウントを用いて不特定多数にファイルを公開するサービスの提供を実現していました。
コマンドラインによる対話でありユーザインタフェースはそっけなく、またファイル名をベースとしたやりとりで、気の利いた検索機能もありません。また性善説に基づいた牧歌的な運用がなされていました。
基本的にはサーバとクライアントの間で一対一にファイルのやりとりを行うFTPに対し、複数のサーバを渡り歩いてアクセスできたり、サーバ間をまたがってファイル検索を可能にしたり、というanonymous FTPの概念を拡張したサービスが1991年に登場したgopherです。FTPとWWWの中間的なサービスともいえます。やはり素っ気ないインタフェースとファイル名ベースのやりとりであり、FTPを置き換えて普及するまでには至りませんでした。不幸なことにその後すぐにWWWが大流行したため、今では徒花的存在になってしまいました。
WWWは、その起源を1983年に遡ります。同年、WWWの父親とされるティム・バーナーズ=リー（CERN）が基本的なアイデアとされているENQIREシステムを開発しました。90年の秋には"World Wide Web: Proposal for a HyperText Project"を発表し、世界初のWebブラウザとWebサーバが開発されています。さらに翌年にはWWWがインターネットで利用できるようになりました。
1992年にはイリノイ大学のNCSA（National Center for Supercomputing Applications）のマーク・アンドリーセンらがMosaicを発表しました。このWebブラウザは文書の中に画像も交えてWWWのハイパーテキストを表現することができ、たいへん人気を博しました。Mosaicはそのソースコードも無料で公開されたことから、爆発的に普及することになります。その後、WWW自体を無料で利用できることが明らかにされ、またその普及を促し技術の標準化を推進するための団体としてWWWコンソーシアムが設立されました。
図は、Mosaic登場時の様子を示す貴重な資料です。1994年末から1995年にかけて三菱総合研究所が公開したWebサイトをMosaicで閲覧した際のスクリーンショットです。スクリーンショットの電子データ自体は残っておらず、スクリーンショットのプリントアウトだけが残っていました。図は、その印刷をスキャンしたデータです。今の華やかなデザインと比べると、実に素朴なデザインです。しかしこの時点で既に画像を交えてハイパーテキストを表現できていたことが分かります。
WWWがハイパーテキスト文書のやりとりに関する標準的な手続きを定めたため、世の中には様々なクライアントとサーバの実装が出回ることとなりました。とくに著名なのが「ブラウザ戦争」と呼ばれる競争です。当初、WebブラウザはMosaicの流れを汲むNetscapeが圧倒的なシェアを誇っていました。しかし、MicrosoftがWindowsにInternet Explorerを組み込んで提供したことにより、現在ではそのシェアが逆転し、Internet Explorerのシェアが圧倒的となっています。
ブラウザ戦争では、ブラウザベンダが独自の機能を盛り込むことによりその優位性をユーザにアピールしていました。その結果、技術革新が進んだ反面、独自拡張が互換性を損ね、相互運用性を低下させる状況を招くことになりました。現在ではその反省を活かし、標準に従ったプロトコルを準拠した上でレンダリング性能やユーザインタフェースの優劣で競うようになっています。
現在は第2次ブラウザ戦争の時代だという人々もいます。Internet Explorerだけでなく、Netscapeから派生したFirefox、Googleが提供するChrome、AppleによるSafariなど、それぞれ個性的なブラウザが提供されるようになりました。特殊なものとしては、文字端末の中でクライアントを動作させるWebブラウザ（w3m）も存在します。その他、携帯電話からのアクセスや専用機器に搭載された独自のWebブラウザなど、コンテンツ提供者もブラウザ独立性を無視できない時代になりました。
ブラウザの相互運用性については後ほど説明します。ここでは「ブラウザの相互運用性」とは何かということを簡単に紹介しておきます。ブラウザのバグや仕様解釈の曖昧性など、様々な理由から、コンテンツのレンダリング結果や動作の様子に不具合が生じる場合があります。図で示した状況は、様々なブラウザでレンダリング結果が異なっている（相互運用性が損なわれている例）です。このような状況が起こらないように、どのような原因で不具合が生じるのかを知り、可能な限り避ける努力が重要です。
先に説明したように、WWWが爆発的に普及した原因のひとつは、画像交じりのハイパーテキストをインターネット上に展開することができた面白さにあります。ここでは、そもそもハイパーテキストとは何だ？という点をおさらいしておきましょう。
「ハイパーテキスト」は、コンピュータを利用した文書セットのひとつであり、文書中に埋め込まれた「ハイパーリンク」を辿ることによって複数の文書を渡り歩きながら気ままに閲覧することができるという特徴を持っています。図中、丸で示した点はすべて文書中に埋め込まれたハイパーリンクです。通常のハイパーリンクは、ユーザがクリックできるようにハイパーリンクであることが分かるように表現されるべきです。
なおHTMLのファイルは単なるテキストファイルなので、基本的には文書データしか保存できません。HTMLに埋め込まれた画像データは、実際にはハイパーリンクで表現されていることには注意しておきましょう（表示した文書を保存する際に「Webページ(HTML)、完全」という形式で保存できるブラウザもあります。この形式で保存すると、HTMLファイルの他に画像データを格納したディレクトリが作成される場合があります。HTMLファイルの実体がテキストファイルであることから、画像を含むHTMLでは完全に保存しようとするとこのような処置をとらないといけません）。
Webブラウザを使って、ハイパーリンクをクリックしていくと次々とリンク先のページを表示することができます。ここでの例ではすべて文書の先頭に対してリンクが張られていますが、文書の途中に対してリンクを張ることも可能です。
WWWを構成する各ページは、ハイパーリンクによってグラフ構造を作ります。グラフ構造はひとつのサーバ内部に限らず、サーバを越えたハイパーリンクを介して複数のサーバに跨がるグラフ構造を作り出します。またいくつかのリンクを辿っていくと、元のサーバに戻ることもあり得ます。このように、Webページの描くグラフ構造には循環する構造がしばしば見られます。
循環グラフがしばしば見られるという事実は、頭の隅に入れておくとよいでしょう。例えばリンクを辿って自動的に情報を収集しようとするロボットプログラムを作成することを考えてみます。ページをダウンロードし、文書を解析してリンクを辿りつつ処理を続けるプログラムは比較的簡単に書くことができるでしょう。しかしそれだけでは、循環グラフに迷い込んだ際、無限ループに陥ることになってしまいます。
ここまで、ハイパーテキストとは「画像とハイパーリンクを含んだ文章」で代表させて説明してきました。しかし現在のWebコンピューティングは、もはやテキストデータと静止画データだけを扱う世界ではありません。実際にはマルチメディアデータが豊富に利用されており、それが故にWWWが爆発的に流行したともいえる状況です。このような状況を鑑みると、ハイパーテキストというよりは「ハイパーメディア」と呼ぶほうが適切でしょう。
ネット上に散らばる文書やマルチメディアデータを総称して、「リソース（資源）」と呼びます。端的には、情報の参照先をリソースといい、その実体は何でも構いません。すなわちテキストデータやマルチメディアデータに止まらず、データベースに格納されたデータでもよく、また電子データである必要もありません。例えば、全ての書籍に付けられているISBNや雑誌に振られているISSN、雑誌コードもリソースです。メールアドレスや住所もリソースになり得ます。またコンピュータのCPUそれ自体が、分散コンピューティングの文脈などでは「計算リソース（計算資源）」として扱われます。
オンラインのリソースを特定する際には、まずコンピュータの場所を指定できなくてはいけません。ネットワーク上に存在するコンピュータを「ノード」と呼びます。ここではクライアントやサーバといった種類を問いません。いずれもネットワーク上に存在するノードです。
インターネット上のノードは「IPアドレス」と呼ばれるアドレスで区別されます。現在は、IPv4と呼ばれるアドレスの仕組みが利用されています。IPv4によるアドレスは、個別に割り当てられた32ビット（2進数で32桁）の数値を4つに区切った表現で示します。現在、IPv4はアドレス割り当ての枯渇が危惧されており、それに代わる新しいアドレスの仕組みとして、IPv6の利用が勧められています。IPv6は128ビットの数値で表されるため、IPv4と比べると遥に大きなアドレス空間を持ちます。ほぼ無限に割り当てが可能になるといっても過言ではありません。
IPv4やIPv6のいずれにしても、数値の羅列はなかなか覚えにくいという問題があります。「人間が簡単に暗記できる数値は7桁まで」という指摘もあります（余談ですが、そのため世界各国どこへ行っても市内電話は7桁前後にされているそうです）。そこで、数値ではなく意味のある文字列で表現することによって覚えやすくしようとする仕組みが用意されています。これを、ドメインネームシステム（DNS, Domain Name System）といいます。
例えば、東京農工大学のWebサーバは165.53.11.108というIPアドレスを持っています。これをドメインネームで表現すると、www.tuat.ac.jpです。また三菱総合研究所の情報技術研究センターが公開しているWebサーバは133.148.32.17というアドレスが付けられています。名前で表現すると、it-center.mri.co.jpとなり、IPアドレスよりもドメインネームのほうが格段に覚えやすいといえるでしょう。
ここで、www.tuat.ac.jpやit-center.mri.co.jpといった表現は、ドメイン名やホスト名（マシン名）をすべて記載したFQDN（Fully Qualified Domain Name）という正式名称です。また実際にはこれらの名称とIPアドレスが一対一対応すると定められているのではなく、負荷分散や仮想マシンなどの環境では、ひとつの名称に複数のIPアドレスが対応していたり、ひとつのIPアドレスに複数の名前が付けられていたりすることもあります。
DNSにおいてホスト名とIPアドレスの対応をとり、変換処理のサービスを提供するサーバをDNSサーバといいます。全てのDNSサーバが世界中のIPアドレスについて対応関係を保持しているわけではありません。DNSは柔軟なシステムであり、階層構造で情報を管理する仕組みになっています。
例えば東京農工大学のネットワークに接続されているノードで、it-center.mri.co.jpのIPアドレスを知りたくなったとしましょう。まずtuat.ac.jpを管理しているDNSサーバに問い合わせをします。以前に変換したことがありその情報が残っていればすぐに答えを返しますが、その情報が無い場合には上位のサーバに問い合わせを行います。上位のac.jpを管理しているサーバでも同様です。対象とするノードはco.jp以下にあるので、さらに上位に問い合わせます。そこから先はco.jp、mri.co.jpと下位方向に問い合わせを進めていきます。mri.co.jpは直接管理しているのでIPアドレスを知っています。このように、階層的に問い合わせを処理することで、柔軟なネットワークを実現しているのです。
Webコンピューティングでは、この仕組みをさらに進めてURI（Uniform Resource Identifier）や、URL（Uniform Resource Locator）、URN（Uniform Resource Name）といった考え方が使われます。URIは、インターネット上のリソースを特定する仕組みの総称で、もっとも抽象的に表現するための表現手段です。URLはもう少し具体的なリソースの指定方法です。URLでは、プロトコル、ドメイン名（ホスト名）、ポート番号、ファイル名を組み合わせて、ひとつのリソースを特定します。プロトコルはWWW（http://やhttps://）に限らず、FTP（ftp://）やメールアドレスの参照（mailto:）、ニュース記事（news:）など、様々なものを選ぶことができます。URNはリソースそのものに付けられる名前です。リソースの場所が移動するとそのリソースを指すURLは代わりますが、URNそれ自体は不変でなければなりません。
URLに記載されたホスト名やIPアドレスで個々のサーバを区別することができます。またURLには、ポート番号と呼ばれる数値が記載されていました。これを利用して、ひとつのサーバが複数のサービスを提供している場合に各サービスを区別することができます。メールサーバやウェブサーバ、ファイル共有サーバなど、様々なサービスをまとめて提供するケースはよくある話です。とくに小規模な構内ネットワークでは、コスト削減のためにしばしば活用される手法です。
様々なサービスは、それぞれ異なるポート番号でリクエストを受け付けます。このことによって同じサーバが提供する複数のサービスを区別して利用することができるようになるのです。
このように、ホスト名やIPアドレスによるノードの特定とポート番号による対象プログラムの特定で、利用したいサービスを定めることができます。実はポート番号とはノード間で数多くやりとりされる通信の識別番号を与えているにすぎません。特定のサービスは慣習的にそれぞれの番号が割り当てられているため、ユーザは利用したいサービスを番号で指定することができるという仕掛けです（ユーザ側のポート番号は、ある数以上の大きな数値が適宜割り当てられるという仕組みになっています）。
このような、特定サービスのために予約されている番号のことを「Well Known Port」番号といいます。例えばHTTP（次項で説明するWWWでの通信）であれば80番、メールを転送するSMTPサービスであれば25番、セキュアな通信を利用したHTTP（SSL）であれば443番といった具合です。
Webコンピューティングで使われる主要な通信方式がHTTP（Hyper-Text Transfer Protocol）です。図に示した通信の例は、HTTP 1.0による最も簡単な通信の様子です。クライアント側から「GET / HTTP1.0」というリクエストを送付すると、「HTTP/1.0 200 OK」で始まるデータがサーバから戻されます。ここで示した通信例は、HTTP 1.0でのやりとりの様子ですが、現在はHTTP 1.1の利用が主流です。なおHTTPはOSIの7層モデルに当てはめると上位のセッション層からアプリケーション層までのレイヤーに相当します。
リクエストの内容やサーバの状態によっては、様々なレスポンスが返されることとなります。上記の例では正常なやりとりだったため、レスポンスコードとして「OK」を意味する200番が返されました。
図に挙げた表は、レスポンスコードを一覧にしたものです。URLを打ち間違えたりリンクが切れていたりして、「404 Not Found」というメッセージを目にした経験は一度ならずとあるでしょう。その他、わりと目にしやすいコードとしては、アクセス許可が得られていないリソースへアクセスしようとした際の「403 Forbidden」や、サーバの内部設定や状態がおかしくなっているときの「500 Internal Server Error」、「503 Server Unavailable」などがあるでしょうか。また同じクライアントから同一のリソースへ複数回アクセスがあった際に「304 Not Modified」が返され、内容そのものは返されないこともあります。
イントロダクションの最後として、セキュリティの話題をざっと紹介します。ネットワークセキュリティの話題はそれだけでひとつの科目になり得るテーマです。ここではWebコンピューティングで必要になるセキュリティについて、ほんの一端だけを説明します。
そもそもインターネットの黎明期、あるいはWWWが登場した時代は、性善説に基づく運用がなされており、研究者の信頼に依存したネットワークでした。しかしインターネットが商用化し、Webコンピューティングが一般化するに従ってセキュリティの話題は避けて通れないものとなりました。それはインターネットそれ自体が社会的インフラとなり、社会に与える影響力が無視できないものとなったからです。
オンラインバンキングに不正アクセスする犯罪や、なりすましや不正な侵入による詐欺行為、掲示板への殺人予告など、いまや様々な脅威がネットワーク上にあふれています。このような悪意ある行為を防止するために、本人認証や通信の暗号化といったセキュリティ技術が求められているのです。
Webコンピューティングでしばしば利用される認証技術として最も簡単なものがパスワード認証（パスフレーズ認証）です。これはIDとパスワードの組で認証するもので、あらゆるシーンで利用されています。簡単で古くから使われている技術ですが、一方で安易なパスワードをつけてしまうと推察されてセキュリティが破られやすいとか、多種多様なサービスが提供されている今、IDとパスワードの組み合わせを覚えきることができなくなっているというデメリットがあります。
セキュリティを強化したパスワード技術のひとつに、ワンタイムパスワードがあります。これは時刻等の情報を利用してその場限りのパスワードを生成することによりセキュリティを高めようというもので、不正アクセスには強い手段です。しかしワンタイムパスワードを生成するための機器を持ち歩く必要があるなど、利用時の煩わしさも大きくなってしまいます。
またパスワードのセキュリティを高めるもうひとつの方法として、マトリクス認証があります。これはオンラインバンキングなどでよく利用されています。ワンタイムパスワードと同様、その場だけで通用するトークンを乱数表に似たマトリクスから生成するもので、比較的簡易かつ安全な方法です。しかしこの方式を採用した場合は、マトリクスを持ち歩かねばなりません。
様々なサービスが提供するIDとパスワードの組み合わせをいちいち覚えていられないという悩みを解決する技術がSSO（Single Sign On）です。イントラネットではSSOを利用した認証の一元化が実現しているケースも多いのですが、インターネット上に存在する不特定多数のサービスではまだそこまで普及が進んでいません。この問題を解決すべく、認証サービスを統合しようという動きも出てきています。
本人を認証する技術が重要であるとともに、「人間であること」を認証するための技術も重要です。spamをばら撒くためにメールアドレスを収集するロボットや、電子掲示板やブログへのコメントスパムの自動生成ボットなど、世の中には困った自動化プログラムが存在します。
これらへの対策として、メールアドレスをイメージで表示したり、メールアドレスに含まれる「@（アットマーク）」を「__at__」と表現し読み替えを求めたり、といった工夫が行われています。システム的な解決策として、人間の文字認識能力を活用したCAPTCHAと呼ばれる仕組みもしばしば利用されます。
しかしいずれにしても「いたちごっこ」であるという点は否めません。画像認識技術を多用して複雑なCAPTCHAを解読するボットも出現しています。
フォームから入力した文字列を処理するWebアプリケーションでは、XSS（クロスサイトスクリプティング）と呼ぶ攻撃を防いでおく必要があります。
例えばユーザからの入力に「<」や「>」が含まれるときは、それぞれの文字を表す「<」や「>」に置き換えてHTMLの要素を無効化する処理を施さなければなりません。この処理を怠ると、アプリケーションは予想外の動作をする可能性があります。図の例では、HTML要素が埋め込まれた入力をそのまま出力したために予想外の表示が出てきてしまった例を示しています。
HTMLの要素を無効化したり、次に述べるSQLやOSのコマンドを含む文字列を無効化したりという処理を、「サニタイジング」といいます。
WebアプリケーションのバックエンドでDBが動作している場合は、DBの保護も重要です。XSSのように、DBを操作するSQLコマンドがそのままアプリケーションに渡らないようにサニタイジングをしなければなりません。
またOSのコマンドが実行されるような環境も危険です。万が一、不正な入力で自由にコマンドが実行されてしまえば、サーバそのものが改変されたり、最悪の場合は破壊されたりする恐れもあります。この場合も、コマンド文字列に対するサニタイジングをする対策が必要です。
その他、認証が不十分な通信におけるクライアントのなりすましやセッションを乗っ取るセッションハイジャックなど、Webアプリケーションに対する脅威には様々なものがあります。Webコンピューティングの利用やWebアプリケーションの構築では、これらの脅威が存在することと対策は十分になされているかをしっかりと確認することが大切です。
まずは本講義のガイダンスとWWWを支える要素技術の概要を説明しました。この後、第2回と第3回ではWebサイトから提供するコンテンツを表現するための技術について学びます。