入門 Active Server Pages+Web アプリケーションの導入、スケーラビリティ、セキュリティ、信頼性を改善する ASP+
Active Server Pages+: ASP+ Improves Web App Deployment, Scalability, Security, and Reliability
(September 2000 Vol.15 No.9)
Dave Sussman
Dave Sussman は、データアクセスとインターネット技術を専門とする著述家。執筆活動の大部分を、Wrox Press の書籍の執筆に当てている。貴重な空き時間には、音楽や曲芸を楽しんでいる (一度に両方を楽しむことも)。
この記事は、Visual Basic と ASP の知識があることを前提に書かれています。
WAP については、MSDN Magazine 日本語版 No.4 の記事「いつでもどこでも最新の情報を： ASP、XML、SQL Server を使った、ワイヤレスなインターネットデータベース接続」、(原著テキストは、https://msdn.microsoft.com/msdnmag/issues/0600/wireless/wireless.asp) を参照してほしい。
C# の詳細については、今号の Joshua Trupin の記事「入門 C# ： C+ + のパワーと Visual Basic の簡潔性を兼ね備えた新言語 C#」を参照してほしい。
背景情報として、ASP の COM オブジェクトについては、https://msdn.microsoft.com/workshop/server/asp/comtutorial.aspを参照。ASP の規則については、https://msdn.microsoft.com/workshop/server/asp/aspconv.aspを参照すること。
このアーティクルは、株式会社アスキー .gif)
より 2000 年 9 月 18 日に発刊された MSDN Magazine No.7 (ISBN4-7561-3574-9) に収録されています。
ASP+ は、Web アプリケーションを開発するためのフレームワークを実現するものであり、インフラストラクチャ全体が、構造化アプリケーションの開発を可能にしている。ASP+ は単なる ASP 4.0 ではなく、まったく新しい Web 開発のフレームワークとして生まれ変わったものだ。
本稿では、コンパイル言語や、Web Forms、Page イベントと Page オブジェクト、Web Control、Web サービス、キャッシング、デバッグ、コードとコンテンツの分割、ネームスペースに用意される共通ライブラリ、簡単な構成と導入のサポートなど、ASP+ の特徴について解説する。
また、より直感的で実に使いやすい開発モデルを提供する「Web Form」、共通の機能を提供する能力を追加し、既存の機能の拡張と強化を支援する「Server Control」、データバウンドアプリケーションの開発を支援する「データバインディング」などの特徴についても解説する。
Summary
ASP を最初から作り直したらどうなるか。その結果が、Active Server Pages+ である。
新しい機能を満載した ASP+ は、再利用や共有に適した、すっきりとした開発しやすいコードを提供する。ASP+ はコンパイル言語へのアクセスを提供することで、パフォーマンスとスケーラビリティを大きく改善する。Web Form のおかげで開発はますます直感的となり、オブジェクト指向をベースとしたことで再利用も容易になっている。このほか、Page イベントや、Web Control、キャッシングも重要な機能だ。
Server Control とデータバインディングの改善も、ASP+ の新たな特徴である。ASP で利用可能なライブラリと Microsoft.NET Framework は Web を通じたカスタムビジネス機能の公開を可能にし、新たな開発チャンスを増やしている。
ASP (Active Server Pages) を最初から作り直したら、いったい何ができるだろうか。それが、ASP+ (Active Server Pages+) である。ASP+ は、単なる ASP 4.0 ではない。そうであれば、新しい機能がいくつか追加されて終わりだっただろう。いつものスキーマに新しい機能をいくつか押し込む代わりに、ASP+ はまったく新しい Web 開発のフレームワークとして生まれ変わった。ASP+ の詳細に入る前に、その目標を調べてみよう。
ASP+ の利点
ASP+ はコードをすっきりさせる。どれだけ慎重に書いても、既存の ASP アプリケーションはスパゲッティコードだらけになってしまう。ASP+ のコードは書きやすいだけではない。ASP コードよりもすっきりしていて読みやすい。こうした ASP+ コードが構造化される仕組みも、その再利用性と共有性を高めている。
ASP+ は、導入、スケーラビリティ、セキュリティ、信頼性を向上させる。簡単なアプリケーションなら、導入はそれほど問題にはならないが、コンポーネントを利用する n 階層設計へと移行したとたんに問題が浮上する。こうしたアプリケーションを導入して管理しなければならないユーザーは、DLL 地獄 (コンポーネントの登録、バージョン管理、ロックされた DLL など) に突き落とされる。ASP+ は、コンポーネントの登録や、DLL のロックをなくし、XML 構成ファイルを使用することで、この問題に対処する。これにより、ディレクトリをコピーするだけで、Web アプリケーションを導入できるようになる。
ASP+ では、いろいろなブラウザのサポートも強化されている。ブラウザの互換性問題は、ASP 開発者にとって永遠に逃れられない問題であるかに見えた。ASP 開発者は、下位レベルのブラウザ (HTML 3.2 を使用するものなど) を対象にコーディングするか、サポート範囲を制限するしかなかった。WAP (Wireless Application Protocol) デバイスの登場は、この問題を悪化させただけだった。ASP+ がブラウザの互換性問題にどのように対処するのかについては、Web Form のセクションで説明しよう。
ASP+ はまったく新しい Web アプリケーションを可能にする。現在の Web アプリケーションは、どれも似たりよったりだ。すなわち、ロジックがどれか 1 つに組み込まれた、リニアアプリケーションの集合なのだ。ASP+ を利用すれば、この型を打ち破って、企業のビジネスニーズを満たし、充実した開発環境を実現する、より動的でスケーラブルなアプリケーションを開発することができる。
最初の印象では壮大な目標に見えるため、アプリケーションの開発が難しくなるのではと考えたかもしれない。だが、それは間違いだ。個人的には、ASP+ での開発が、あらゆる面ではるかに簡単であることを実感している。
次は、コンパイル言語や、Web Form、Page イベントと Page オブジェクト、Web Control、Web Service、キャッシング、デバッグ、コードとコンテンツの分割、ネームスペースに用意される共通ライブラリ、簡単な構成と導入のサポートなど、ASP+ の特徴について調べてみよう。
コンパイル言語の使用
ASP のこれまでのバージョンは、VBScript や JScript といったスクリプト言語に基づいている。スクリプト言語自体に問題はないが、それらは大きな欠点を 2 つ抱えている。それらはインタープリタ言語であり、そして型の定義が弱い。これらがもたらすパフォーマンスの低下は割に合わない。ASP+ はスクリプト言語という概念を捨ててはいないが、完全なコンパイル言語のサポートを取り入れ、たとえば Visual Basic でサーバサイドのコードを記述できるようにしている。
<script language="vb" runat="server">
Visual Basic の最大のメリットは、厳密に型指定された変数をサポートすることだ。したがって、ASP+ では、次のコードが可能となる。
Dim FirstName As String
サーバサイドコードの記述には、Visual Basic や C+ + のほかに、最新の Microsoft 言語、C# を利用することができる。C# は、C+ + から面倒な部分をすべて剥ぎ取って、理解しやすくしたものだ。私でさえ理解できるのだから、難しいはずがない。
ASP+ のコンパイルは、ページが最初にロードされたときに発生する。スクリプト言語でさえ、実行前にコンパイルされるため、JScript ページにもパフォーマンスの改善が見られる。実際、これは Microsoft.NET Framework の新しい基本機能の 1 つである。これまでの言語のコンパイラは、データ型とオブジェクトを別々に処理していたため、クロス言語開発を実行するとしたら、COM オブジェクトを生成するしかなかった。Microsoft.NET Framework の新しい共通言語ランタイムは、共通ランタイムサポートでコンパイルされたコードの密接なやり取りを可能にする。これこそが、実行時に管理できるコードを生成するという、新しい Visual Basic コンパイルと C# コンパイルの機能なのだ。
最大の利点は、本当の意味でのクロス言語開発が実現することだ。共通ランタイムのおかげで、C# で生成したオブジェクトを、継承を通じて Visual Basic に拡張することができる。それでは、どうすればこれが可能になるのだろうか。種を明かすと、Visual Basic.NET は継承をサポートするようになったのだ。このため、C# で開発したコンポーネントを、Visual Basic でサブクラス化できるようになった。
β 1 の段階では、Visual Basic、C#、スクリプトのみがサポートされている言語だったが、ほかの言語 (Smalltalk、Eiffel、Pascal など) もサポートされる予定だ。Microsoft.NET Framework の利点の 1 つは、拡張が簡単であることだ。したがって、新しい言語を追加したければ、ランタイム互換の出力を生成するコンパイラサポートを提供するだけでいい。
Web Form
ASP+ の Web Form は、現在の ASP と同じように、コードを開発できる Web ページだ。だが、それ以上に重要なのは、オブジェクト指向プログラミング言語の上に設計されているため、コードの再利用やアプリケーションコードとページコンテンツの分割が可能になることだ。Visual Basic では、フォームの上にコントロールを配置して、その下にイベントプロシジャを実装することになる。従来の ASP では、UI コントロールとサーバサイドコードとの間にリンクがないため、このようなことは不可能だ。しかし、ASP+ にはリンクがある。フォーム変数から手動で値を取り出す代わりに、Figure 1 のようなコードを記述することができる。
| Figure 1 簡単な ASP+ Web Form |
Figure 1 には、重要なポイントが 2 つある。まずは、フォームでの runat="server"属性の使用と、asp:textbox コントロールの使用だ。これは、これらのコントロールにサーバとクライアントの両方からアクセスできることを ASP+ に伝えるものだ。このように使用するコントロールを、「サーバコントロール」という。コントロール名のプレフィックスとして使用される asp: は、コントロールが存在する場所を識別する。これについては、後ほど説明しよう。
次のポイントは、OnClick イベントだ。DHTML コードの開発では、ブラウザでのイベントの発行に、OnClick イベントを使用する場合が多い。原理はこれと同じだが、コントロールに runat="server"属性が設定されているため、イベントはサーバだけで発行される。このサンプルは、Response を削除するだけで、簡単に拡張できる。Figure 2 に示すように、これをサーバベースコントロールに置き換えてみよう。
| Figure 2 サーバベースコントロールの使用 |
コードのふるまいは従来のクライアントや Visual Basic フォームと同じだが、コードははるかに直感的だ。サーバコントロールを利用すれば、イベントプロシジャとサーバベースコードをリンクすることができる。こうしたサーバベースコントロールは、純粋な HTML をブラウザに送信する。すなわち、クライアントサイドスクリプトはこれに関与しない。実際のところ、ブラウザの互換性を最大限に維持するため、HTML 3.2 の基本的な要素にこだわることは、重要な設計目標の 1 つだった。たとえば、Figure 2 のコードは、次の HTML を生成する。
<html>
<body>
<FORM name="HtmlForm2" method="post" action="Test.aspx"
id="HtmlForm2">
<INPUT type="hidden" name="__VIEWSTATE"
value="a0z664351470__x">
Name: <input name="txtName" type="text"
id="txtName"><br>
<input type="submit" name="Button5" value="Enter">
<br>
<span id="lblYouEntered"></span>
</FORM>
</body>
</html>
生成されたコードは、HTML 3.2 である。このコードは、ユーザー入力を同じファイルに送り返す、標準的なフォームポストを実行する。サーバの状態が維持されることも、状態を管理するクライアントサイドスクリプトもない。Hidden フィールドがコントロールの状態を管理する。つまり、プログラミングによる介入なしに、コントロールはページをポストする側と受け取る側の間の状態を自動的に管理する。
ASP+ Web Control のデフォルト出力は HTML 3.2 だが、Internet Explorer 5.0 といった上位レベルのブラウザに対しては、DHTML で出力することもできる。ブラウザの種類に応じて、出力の種類をコントロール自身に判断させることが可能となるため、単一セットのサーバコントロールでページをオーサリングできるようになる。これにより、Internet Explorer の新しいバージョンには DHTML やクライアントサイドスクリプトを送信させ、ほかのブラウザには HTML 3.2 をそのまま送信させることが可能となる。
Page イベント
ASP+ が一から開発されたことはすでに述べたとおりだが、それがオブジェクト指向を念頭に置いて再構築されたことについては、まだ説明していなかった。オブジェクトツリーの先頭には Page オブジェクトが位置する。ASP+ コントロールや、アプリケーション、ページはそれぞれ、Pages オブジェクトを継承する。つまり、各ページは Page オブジェクトのインスタンスだ。Figure 3 が示すように、Page オブジェクトの Load イベントが応答可能なイベントであることが分かったとたんに、このことが重要性を帯びてくる。
| Figure 3 Page イベントの使用 |
Figure 3には、Visual Basic ではおなじみの Load ／ Unload がある。Load イベントは、ページがロードされ、サーバベースのすべてのコントロールが利用可能となる瞬間に発行される。ユーザーとのやり取りではほかのイベントが発行され、ページのアンロード時には Unload イベントが発行される。
Web Controls
<asp:TextBox> といったコントロールは、これから習得しなければならないまったく新しいコントロールセットを表わしているのだろうか。コントロールは新しいが、習得は難しくない。それらに相当する HTML のコントロールだと考えればいい。たとえば、テキストボックスといった簡単なものについて考えてみよう。HTML では、次のように記述する。
<input type="text" value="Your Name"></input>
これに相当する Web Control は、次のようになる。
<asp:TextBox Text="Your Name" runat="server" />
すぐに気がつくのは、Web Control が asp: コードネームスペースによって識別されること、XML と同じように、エレメントをスラッシュで閉じることだ。だが、この XML スタイルを使用せずに、終了タグを別に使用する HTML スタイル (</asp:TextBox>) を使用してもかまわない。ただし、XML スタイルのほうが多くのコードサンプルに使用されており、また入力しやすい。ネームスペースは TextBox コントロールが存在する場所を識別するため、必要不可欠となっている。標準の Web Control はすべて、ASP ネームスペースに属している。このことは、独自のコントロールをオーサリングする場合に重要となるが、これについては後ほど説明しよう。
TextBox コントロールの利点は、標準の入力ボックスの利点とそれほど変わらないように見える。だが、次の 3 つの入力コントロールについて考えてみよう。
<input type="text" ...>
<input type="password" ...>
<textarea rows="5" ...>
どれも HTML の入力に使用されるものだが、一貫性がない。次のように記述するほうが簡単ではないだろうか。
<asp:TextBox runat="server" ...>
<asp:TextBox TextBoxMode="Password" ...>
<asp:TextBox Rows="5" ...>
たった 1 つの簡単なコントロールが、使いようによっては 3 つの機能を提供できる。実際、HTML の TextBox コントロールと ASP+ の TextBox コントロールは、同じ HTML を出力する。違いは、覚えたりコーディングするのがはるかに簡単であることだ。
ASP+ には、次の 5 つの Web Control ファミリが組み込まれる。
- HTML のコントロールに相当するビルトインコントロール・ページ全体にデータフローを提供するリストコントロール・充実した UI コンテンツと UI 機能を提供するリッチコントロール・さまざまなフォームの検証を行なうバリデーションコントロール・ WAP デバイスの WML をカプセル化したモバイルコントロール (β 1 以降の機能)
ビルトインのサーバコントロールは、HTML コントロールに相当するものだが、使用法の一貫性を強化するために合理化されている。こうしたコントロールとしては、LinkButton、ImageButton、HyperLink、TextBox、CheckBox、RadioButton、DropDownList、ListBox、Image、Label、Panel、Table、TableRow、および TableCell があげられる。
リストコントロールには、Repeater、DataList、DataGrid (次のセクションで詳しく説明する) が含まれる。また、ラジオボタンや、チェックボックスのリストを簡単に作成できるように、RadioButtonList と CheckBoxList が用意されている。
リッチコントロールは、Calender と AdRotator で構成される。Calender コントロールは、下位レベルのブラウザには純粋な HTML を出力し、上位レベルのブラウザ (Internet Explorer 5.0 など) には DHTML を出力する。AdRotator はイメージを出力するほか、ローテーションコードを組み込んでいる。β 1 以降に、リッチコントロールの追加が予定されている。
バリデーションコントロールには、RequiredFieldValidator、CompareValidator、RangeValidator、RegularExpressionValidator、CustomValidator、および ValidationSummary が含まれる。これらを利用すれば、フォーム処理に検証機能を簡単に組み込むことができる。
モバイルコントロールの詳細はまだ発表されていないが、WAP 対応の Web サイトの構築を支援するものになるだろう。
新しいコントロールのオーサリング
提供されているコントロールにこだわる必要はない。独自のコントロールをオーサリングするのは非常に簡単だ。たとえば、2 つのテキストボックス (姓と名の入力フィールドなど) をカプセル化して、1 つのコントロールにまとめたい場合は、次のようなコードを記述すればいい。
<asp:Panel runat="server">
<asp:Textbox id="txtFirstName" text="First Name"
runat="server" />
<asp:Textbox id="txtLastName" text="Last Name"
runat="server" />
</asp:Panel>
このコードを Name.aspc というファイルに保存し (新しい拡張子に注目)、Web Form コントロールとして処理する。たとえば、Web Form に次のコードを追加することができる。
<%@ Register TagName="NameControl" TagPrefix="Foo"
src=" >
</form>
画期的なのは、再利用可能なコードを簡単に作成できることだ。また、Visual Basic や C# でコントロールを作成すれば、それらをほかのコントロールからサブクラス化し、必要な出力をレンダリングすることもできる。コントロールはネームスペースで識別されるため、コントロール同士が衝突することはないはずだ。実際には、ネームスペースが違っていれば、同じ名前のコントロールを持つことも可能である。これが ASP+ の拡張性を高め、プログラミング環境をますます充実させることが分かる。実際、リッチコントロールに関しては、大規模なサードパーティ市場の誕生が見込まれている。
データバインディングのコントロール
新しい Web Control の 1 つに、DataGrid がある。DataGrid は、Dataset をレンダリングするためのビルトインサポートだ。SQL が生成したデータから HTML テーブルを作成するには、Figure 4が示すように、ADO+ オブジェクトを生成し、グリッドのソースとなるデータを取得するためのコマンドを実行すればいい。データグリッドにデータをバインドするだけで、見事な HTML テーブルが生成される (Figure 5)。データバインディングはデータベースのデータに限られない。ハッシュテーブルや、配列、ほかのサーバコントロール、ページのプロパティなど、何でもバインドできる。
<%@ Import Namespace="System.Data.SQL" %> |
| Figure 4 DaveSGrid1.aspx |
.gif)
** Figure 5 DaveSGrid1.aspx の出力
デフォルトの列セットを使用したくない場合は、必要な部分だけを表示するようにカスタマイズできる。
<asp:DataGrid id="DataGrid1"
AutoGenerateColumns="false" runat="server">
<property name="Columns">
<asp:BoundColumn HeaderText=" Name"
DataField="ProductName"/>
<asp:BoundColumn HeaderText="Description"
DataField="ProductDescription"/>
</property>
</asp:DataGrid>
単に列を選択するには BoundColumn コントロールを使用し、列のタイトルとバインドする列を指定する。AutoGenerateColumns="false"属性を追加すると、グリッドはすべての列を生成しなくなる。もっと複雑なテーブルが必要なら、列にテンプレートを使用するという方法もある。
先ほど紹介した Repeater コントロールと DataList コントロールも、コントロールの外見をカスタマイズする手段として、テンプレートをサポートする。実際、Repeater コントロールには外見がないため、UI はユーザーが提供しなければならない。つまり、テンプレートを使用することになる。これに対し、DataList コントロールのほうは、デフォルトの外見と充実したふるまいを持つデータバウンドリストである。テンプレートを追加する方法は、どちらも同じだ。
<asp:DataList is="DataList1" runat="server">
<template name="HeaderTemplate">
ここにタイトルのリストを定義 <br>
</template>
<template name="ItemTemplate">
<%# DataBinder.Eval(Container.DataItem, "Title") %>
<br>
</template>
</asp:DataList>
この形式のテンプレートには、データバウンドコントロールの各部分を構成する HTML コントロールが指定できる。DataList コントロールの場合は、利用できるテンプレート名が 5 つ用意されている。コントロールの最上部には HeaderTemplate、各アイテムには ItemTemplate、1 つおきのアイテムには AlternatingItemTemplate、アイテム間の領域には SeparatorTemplate、コントロールの最下部には FooterTemplate を使用する。
このシステムの長所は、インターフェイスの表示をかなり厳密に制御できることだ。たとえば、製品リストの場合は、Figure 7のコードを使って、Figure 6 の出力を生成することができる。このコードは実にシンプルで、先ほど紹介した DataList 以外のコードは要求されない。Figure 7 のコードについて 1 つ指摘しておくと、表示する列の数を指定すれば、リストが列の列の揃え方を自動的に処理する。
.gif)
** Figure 6 DaveSGrid2.aspx の出力
| Figure 7 DaveSGrid2.aspx |
要するに、フォーマットコードを少し追加するだけで、Web ページは見違えるようになる。数多くの Web ぺージに使われている従来のグリッドはもはや不要となり、ほんのわずかの作業で、魅力的なページが完成する。
Web Service の開発
インターネットを通じたサービスとして提供されるソフトウェアは、Web Service の重要なテーマだ。ASP+ は、このサービスモデルのサービスを開発するための、Web Service インフラストラクチャを提供する。
簡単な例として、注文の追跡について考えてみよう。オンライン書店から本を購入したとしよう。そのオンライン書店には、注文の処理状況を参照できる追跡システムがある。そのオンライン書店では、注文の発送をある輸送会社に委託している。その輸送会社にも追跡システムがあるため、注文の正確な処理状況をつきとめるには、2 つのサイトを確認しなければならない。だとすれば、オンライン書店が独自の注文処理状況と輸送会社の処理状況の両方を提供するほうが便利ではないだろうか。
Web Service は、Web から一般ユーザーへのカスタムビジネス機能 (小包の追跡情報など) の公開を可能にする。この場合は、このメソッドを URI として公開し、データを XML で返すオブジェクトを開発する。これで、オンライン書店は輸送会社の追跡サービスを呼び出して、その追跡結果を自分の注文追跡アプリケーションに取り込むことができる。次のように、輸送会社は C# を使ってサービスを開発することができる。
<%@ WebService language="c#" %>
using System.Web.Services;
public class Shipping {
[WebMethod]
public String OrderStatus(String OrderNumber) {
// データストアから注文情報を取り出すコード
return Status;
}
}
これを、輸送会社の Web サイトのアプリケーションディレクトリに、Tracking.asmx というファイルとして配置すればいい。これで、オンライン書店はいくつかの方法で、この Web Service を呼び出せるようになる。たとえば、HTTP-GET を使用する場合は、メソッドパラメータをクエリー文字列と一緒に渡す。
http://orders.ups.com/orders/Tracking.asmx/OrderStutus?
OrderNumber=BRU123
オンライン書店は、HTTP-POST を使用することもできる。この場合は、メソッドパラメータをポスト文のフォームの値として渡す。HTTP-SOAP を使用する場合は、メソッドパラメータを業界標準の XML フォーマットとしてパッケージ化する。
これで、ユーザーがオンライン書店に注文の処理状況を照会すると、オンライン書店の Web アプリケーションが輸送会社から追跡情報を収集し、本の注文情報と一緒に返すようになる。また、オンライン書店はその注文情報をほかのユーザーに Web Service として公開することもできる。
Web Service の画期的な部分は、データやベンダー独自のビジネスルールを公開せずに、サービスを公開できる点だ。ビジネスサービスが自動的に提供される一方で、コードやデータは安全に守られる。B2B ソリューションの規模が拡大するにつれ、Web Service の市場は今後数年間で急速に成長するだろう。
キャッシングの改善
パフォーマンスとスケーラビリティに優れた Web サイトの構築には、何らかのキャッシュを使用する確率が高い。ページの構築作業によっては、リソースの消費が激しい。一度構築されたページをキャッシュしておけば、サーバリソースが節約され、ページをすぐに提供できるようになる。既存の ASP アプリケーションを高速化する手段はいろいろあるが、機能の幅広さという点で、以下の機能を提供する ASP+ の右に出るものはいない。
最も単純なのはページキャッシュだ。動的なページを出力キャッシュに保存し、個々のリクエストに応じてページを構築する代わりに、それらをキャッシュから取り出せるようにする。ページをキャッシュに保存する期間は、絶対時間 (午前 0 時など) または相対時間 (ページが最後にアクセスされてから 20 分後など) で厳密に制御できる。フラグメントキャッシュは、ASP+ ページの部分ごとに、同じレベルの制御を提供する。これらのテクニックは、どちらもキャッシュ API を使用する。キャッシュ API は、リクエストの度ごとにオブジェクトを再生成する代わりに、オブジェクトをキャッシュに保存できるように、プログラマに公開される API だ。キャッシュを効果的に使用すれば、パフォーマンスを大幅に改善することができる。
製品カタログといったサイトにとって、キャッシュはかけがえのない機能だ。こうしたサイトのコンテンツは動的でなければならないが、それほど頻繁には変更されない。ASP の場合、動的なカタログが必要であれば、ページがリクエストされるたびにデータベースから再構築するか、それを HTML に変換するしかない。ASP+ のページキャッシュを利用すれば、動的なページの 1 日キャッシュを指定することができる。つまり、その日の最初のヒットが、ページの出力をキャッシュする。それ以降のヒットでは、ページがキャッシュから取り出される。
デバッグとトレース
Response.Write を主なデバッグツールとして使用することに飽き飽きしているのではないだろうか。きっとそうだろう。ASP+ の目標の 1 つは、アプリケーションの開発を容易にすることだが、できれば避けたい作業であるとはいっても、デバッグは開発に欠かせない部分だ。ASP+ ページがコンパイルされるようになったことで、それらの実行時に COM+ をフックさせ、充実したデバッグ環境を実現することが可能になった。そして忘れてならないのは、これが Microsoft.NET Framework であることだ。すなわち、デバッグはクロス言語となる。Visual Basic ベースの Web ページから、C# で書かれたコントロールのステップ実行が可能となる。
利用できるデバッグ機能は、使用するツールによって決まる。Microsoft.NET Framework サービスにはデバッガが組み込まれ、幅広い機能が提供されているが、それらはローカルコンピュータに限られている。Visual Studio の次のバージョンには、リモートアプリケーションのデバッグを可能にする、拡張バージョンのデバッガが搭載される予定だ。
プロファイリングとトレースも、開発の重要なテクニックだ。Response.Write のほかに、ASP アプリケーションの進行状況を簡単に監視する手だてはない。これはアプリケーションの流れを監視するためだけに重要なのではない。パフォーマンスの悪いコードをつきとめるために、アプリケーションをテストするという面でも重要だ。
トレースは、Page オブジェクトの Trace メソッドとして、ASP+ に組み込まれている。たとえば、イベントプロシジャへの進入と退出をトレースするには、次のコードを使用する。
Sub Page_Load(Source As Object, E As EventArgs)
Trace.Write "Page_Load", "Start"
' コードの残りの部分
Trace.Write "Page_Load", "End"
End Sub
このトレース情報の出力を有効にするには、次のような Page ディレクティブを使用する。
<%@ Page Trace="True" %>
このページを実行すると、ページの最後にFigure 8 のようなテーブルが表示される。
.gif)
** Figure 8 トレース情報の出力**
トレースはデフォルトで、デフォルトメソッドの時間を表示するが、Trace.Write を追加すれば、これに独自の詳細情報を追加することができる。トレース情報が必要だが、ユーザーが参照できないようにしたいという場合は、トレース情報を別の場所に送信するようにアプリケーションを設定し、そこで情報を調べればいい。また、ページのすべてのコントロールやサーバコントロール変数などで構成される、完全なトレースツリーを取り出すこともできる。これは開発者の生産性に大きく貢献するだろう。
また、ASP+ は Windows NT と Windows 2000 のパフォーマンスモニタに統合されており、ASP+ の状態や ASP+ アプリケーションの状態の監視するための PerfMon カウンタを完備している。
コードとコンテンツの分割
ASP+ には、コードとコンテンツを分割するという、すばらしい機能がある。すべてのインラインコードをページから切り分けて、クラスモジュールに配置することができる。これなら、デザイン部門がサイトの外観を整えている間に、プログラマは自分たちの作業を進めることができる。
コンテンツとスタイルの分割には、ほかにも利点がある。1 つは、標準のデザインツールを使って UI を構築しても、コードを荒らす心配がないことだ。もう 1 つは、UI ページが UI だけで構成され、UI とコードが混ざらないことから、ローカライズがかなり楽になることだ。
ライブラリ
ASP+ の機能はモジュール化されているため、標準的な機能はライブラリとしてパッケージ化されている。従来の ASP では、インクルードファイルや DLL を通じて使用されていたものだ。ASP+ では、ASP+ コードの処理に使用されるものすべてが階層型のネームスペースに収められ、システムコードのみならず、ユーザーのコードも含めて整理するための、構造的な手段が提供されている。つまり、コードを含んだネームスペースをインポートすることで、ページのなかからそれらにアクセスできるようになる。
<%@ Import Namespace="System.ASP.Util" %>
このコードは、Util ネームスペースをインポートして、ASP+ ユーティリティへのアクセスを可能にする。ユーティリティパッケージの活用法としては、電子メールの送信があげられる。ASP ニュースグループを覗いてみれば、「ASP ページからメールを送信するにはどうすればいいか」という質問の多さに驚くだろう。何をインストールしているかによって、いろいろな手段が考えられるが、だいたいは必要以上に難しい。ASP+ は、SMTP SendMail コンポーネントを組み込んでいるため、次のコードが示すように、これを簡単に実現する。
<% Import Namespace="System.ASP.Util" %>
<html>
<script language="vb" runat="server">
Sub SendMail_Click(Source As Object, E As EventArgs)
Dim myMessage As New MailMessage
Dim myMail As New SmtpMail
myMessage.From = "me@here.com"
myMessage.To = "you@there.com"
myMessage.Subject = "Great News"
myMessage.Body = "ASP+ rocks"
myMail.Send (myMessage)
End Sub
</script>
<form runat="server">
<asp:button id="SendMail" text="Send Mail"
OnClick="SendMail_Click" runat="server">
</form>
</html>
Util アセンブリは、ネットワーク通信や、暗号化、イベントログライタなど、数多くのコードを含んだ、あらかじめビルドされたコードライブラリの 1 つだ。
こうしたライブラリの利点は、ASP+ のほかの機能と同じようにクロス言語であることから、開発に使用する言語や、外部の呼び出し言語が制限されないことである。
構成と導入
HTTP リクエストを処理するアプリケーションの名前やアクセス許可データといった ASP+ の構成情報は、XML ファイルに保存される。これらのファイルの 1 つを変更して構成を更新すると、共通ランタイムが変更を自動的に検出し、それらを伝播させる。
簡単なサイトの導入ならそれほど問題はないが、コンポーネントを使用する 3 層アプリケーションを開発するとなると、とたんに問題に巻き込まれる。開発段階であれば、新しいバージョンの DLL をインストールするために Web サーバを停止しても、それほど問題にはならない。面倒ではあるが、もっとひどい作業はいくらでもある。だが、それがライブサイトとなると、Web サーバを簡単にシャットダウンするわけにはいかない (たとえば、Hotmail には 5,000 台のサーバがある)。また、サイトの導入にあたっては、DLL の登録プロセスを管理するのも面倒だ。
ASP+ アプリケーションの導入は、ディレクトリをコピーするだけである。そう、それだけなのだ。アプリケーションの bin ディレクトリに配置されたコンポーネントは、自動的に使用可能となる。ロックファイルといった問題もなければ、登録もいっさい要求されない。すべてをコピーすれば、それで終わりだ。コンポーネントの更新が必要になった場合は、もう一度コンパイルしてコピーすればいい。ASP+ のデモを最初に観たときは、この部分が最も喝采を浴びていた。
ASP+ は完全にコンパイルされたアプリケーションの導入にも対応する。メリットは、ソースコードが Web サーバの管理者から見えないことだ。アプリケーションのホストをほかの会社に依頼する場合は、重要な機能である。
まとめ
ASP+ は、Windows 2000 の IIS (Internet Information Services) 5.0 と Windows NT 4.0 の IIS 4.0 のほかに、Windows 95 と Windows 98 用のバーソナルバージョンが無料で提供される予定だ。β 1 段階では (2000 年 7 月以降)、Windows 2000 のバージョンのみが提供されている。そのほかのプラットフォームは、後日サポートされる予定だ。
ASP+ はこれまでの ASP アーキテクチャから大きく前進している。インフラストラクチャ全体が、構造化アプリケーションの開発を可能にしている。Web Form は、より直感的で実に使いやすい開発モデルを提供する。Server Control は、共通の機能を提供する能力を追加し、既存の機能の拡張と強化を支援する。データバインディングは、データバウンドアプリケーションの開発を支援する。
ASP+ はまさに感動的だ。優れた新機能を満載していることはもちろん、Web アプリケーションを開発するための本当のフレームワークがついに実現したのである。これまでの ASP アプリケーションには、粘着力のあるテープや細紐を感じさせる部分があった。クライアント／サーバシステムのプロフェッショナル開発者として、私はこれまで優れた開発環境と充実したツールや機能に囲まれてきたが、ASP+ はこれらをも凌いでいる。
本稿の執筆に協力してくれた、Scott Guthrie、RobHoward、そして ASP チームのメンバーに感謝している。