Insider's
Eye 2004/09/07 Copyright (C) 2004, Redmond Communications Inc. and Mediaselect Inc. |
|
限定的な普及にとどまるASP(Active Server Pages)
1997年にIIS 3.0の一部として登場したASPは、ISAPIをベースとしており、VBのプログラミング・モデルをWebアプリケーションに応用しようとするMicrosoftの試みの初の成果だった。VBでは、開発者が比較的シンプルなプログラミング言語を使い、Microsoftやサードパーティから提供される既製のCOMコンポーネントを組み合わせてクライアント・アプリケーションを開発できる。VBのようにASPでは、サーバ開発者はサーバ上でスクリプトを実行し、一連の既製のCOMコンポーネントを組み合わせて動作させることが可能だ。例えば、こうしたCOMコンポーネントの1つであるSessionオブジェクトにより、開発者はユーザー設定に関する情報を保存して、ユーザーがサイト内でページを移動する間、その情報を保持しておくことができる。VBとASPの大きな違いは、VBコードがクライアント上で実行されるのに対し、ASPコードはサーバ上で実行されてHTMLを生成し、それがクライアントに渡されブラウザでレンダリングされることだ。
MicrosoftはASPとともに、ASPアプリケーションの開発ツールとしてVisual InterDevをリリースした。Visual InterDevでは、開発者はHTMLページをビジュアルに設計してから、サーバ上で実行されるスクリプト・コードを挿入できた。例えば、広告をローテーションで表示する領域をレイアウトしたうえで、あらかじめ指定した一連の広告の中から実行時に1つずつ選択するコードを挿入できる。
しかしASPは、多様なブラウザで正しく動作するアプリケーションを作成するうえでは、ほとんど助けにならなかった。このため開発者は、どのバージョンのブラウザが使われているかを判断し、それに応じて出力を変更する「ブラウザ検出コード」を作成する必要があった。
Web技術に詳しい開発者の間では人気を博したものの、いくつかの要因から、ASPとVisual InterDevのアピール度は限定的なものだった。第1に、サーバ上で使われる信頼性の高いCOMオブジェクトを作成するのは、多くの人が思ったよりもはるかに困難なことが分かったからだ。ASPではISAPIを使用するため、サーバ側COMオブジェクトのクラッシュやメモリ・リークの危険が伴った。
第2に、スクリプトの作成に使われるVBScriptやJScriptは、VBやC#などの機能豊富な言語よりもシンプルである一方、開発者がコードを組織化して一般的なエラーを回避するのに役立つ重要な機能が欠けている。Webアプリケーションのコードが一定のサイズ(一般に数ページ分程度)を超えると、スクリプト・コードのメンテナンスの難しさが言語のシンプルさのメリットを上回ってしまう。
最後に、Visual InterDevは、もともとHTMLとスクリプティングに精通していた開発者には魅力的だったが、データ・グリッドなど高レベルのコンポーネントが欠けていた。このため、広範なVB開発者コミュニティにとっては使いにくかった。
IISの最近のバージョンはASPをサポートしており、今後のバージョンでもサポートは継続されるだろう。だが、すでにASPは、Microsoftが推奨するWebアプリケーション・プラットフォームとしての座をASP.NETに譲っている。さらに、Visual InterDevは販売が打ち切られており、その機能はほかのVisual Studioツールに統合されている。販売されていた最後のバージョンであるVisual InterDev 6.0は、2004年9月30日に延長サポートが終了する予定だ。
.NET開発に対応したASP.NET 1.0
ASP.NETはASPを完全に刷新したもので、2002年に.NET Frameworkのキー・コンポーネントとしてリリースされた。ASP.NETにおけるアーキテクチャ上の最も重要な変更点は、.NET FrameworkとCLR(共通言語ランタイム)が採用されたことだ。これらの採用は次のような大きなメリットにつながっている。
-
VBScriptとJScriptに加えてVB.NETやC#などの言語をサポート
-
強化されたデバッガなど、Visual Studio .NETを通じて開発ツールが大幅に充実
-
CLRがCOMと比べてより高い信頼性を実現
さらに、MicrosoftはASP.NETで、ユーザーが使用可能な各種ブラウザおよびプラットフォームすべてと、その個々の組み合わせでサポートされる機能に開発者が対応できるように支援する技術をついに導入した。ASP.NETのサーバ・コンポーネント(ASPの旧式なCOMオブジェクト・セットに取って代わるもの)は、使われているブラウザの機能に応じて、自身を多様な方法でレンダリングできる。例えば、カレンダー・コントロールは、IE 5.0からアクセスされている場合には、Dynamic HTMLとスクリプト・コードとして自身を表示し、ユーザーはサーバに何度も要求を送らなくても、スクロールしながらいろいろな月のカレンダーを見るといったことができる。一方、IE 3.0など機能が低いブラウザからアクセスされている場合には、静的なHTMLとして自身を表示する。ASP.NETでは、以前はWeb開発者が自前で作成しなければならなかったブラウザ検出コードが用意され、容易に利用できるようになっている。
しかし、ASP.NETで新たにVBやC#などの言語をサポートしたことに伴い、MicrosoftはVisual InterDevの単体販売を打ち切った。現在、Web開発機能はMicrosoftの各開発言語に組み込まれており、広範な開発者がWeb開発に取り組めるようになっているが、その一方で、Visual InterDevの販売中止により、Webに精通した開発者はVisual Studioの複雑さと格闘しなければならなくなった。例えばVisual InterDevでは、開発者はツール内でWebサーバを指定するだけで、アプリケーションを構成するファイルを直接表示して編集できた。これに対してVisual Studioでは、どんなにシンプルなWebアプリケーションを開発する場合でも、プロジェクト・ファイルとソリューション・ファイルの複雑なセットを扱う必要がある。これはVBやC#を使用する開発者には楽なことかもしれないが、Web開発者にとってはそうではない。
ASP.NETアプリケーションはASPアプリケーションと同じWebサーバ上で共存できるが、ASPとの互換性はない。だが、ASP.NETで追加された機能のメリットは、下位互換性の欠如というデメリットを上回るようだ。MicrosoftがWeb開発者を移行させることに成功してきたことがその証拠だ。実際、ASP.NETは、Microsoftの.NET戦略全体の中でもダントツの成功を収めている。また、SharePoint Portal Serverなど、同社のサーバ製品の多くはASP.NETを基盤としている。
ASP.NET 1.0は、Windows 2000 Server SP2以降、Windows XP Professional、Windows XP 64-Bit Edition、Windows Server 2003上のIISでサポートされており、利用するにはMDAC(Microsoft Data Access Components)2.7以降が必要だ。OSによってIISのバージョンは異なり、Windows 2000とXPでは5.0または5.1、Windows Server 2003では6.0となっている。
ASP.NET 1.0とVisual Studio .NETは、2007年6月30日までメインストリーム・サポートが提供されるため、新規のWeb開発のための安全な選択肢だ(Visual Studio .NET 2003とともにリリースされたマイナー・アップデート版のASP.NET 1.1は、2008年9月30日までメインストリーム・サポートが提供される)。
ASP.NET 2.0の革新的な進化
ASP.NETのメジャー・アップグレードとなるASP.NET 2.0は、Visual Studio 2005とともに2005年前半にリリースが予定されており、前バージョンの成功を土台にさらなる進化を遂げそうだ。ASP.NET 2.0では、Web開発でプロジェクト/ソリューション・ファイルが不要になるなど、ASP.NETとVisual Studioの周知の弱点が克服されているほか、開発者が記述しなければならないカスタム・コードの量を大幅に削減する重要なビルディング・ブロック・サービスが多数導入されている。
ASP.NET 2.0には、以下をはじめとするさまざまな新機能が盛り込まれている。
-
メンバーシップとパーソナライズ:ビルトインの「ログオン」コントロールや、エンド・ユーザーの設定に基づいてアプリケーションをカスタマイズする機能など
-
マスター・ページ:Web開発者はサイト上のすべてのページに一貫した外観を持たせ、マスター・ページを編集するだけでその外観を一括で変更できる
-
アダプティブ・レンダリング:Pocket PCなどの機能が低いブラウザやWAP(Wireless Application Protocol)などHTML以外の言語に対応するブラウザを搭載した携帯電話など、各種のモバイル・デバイスへのASP.NETのサポートを拡張する
ASP.NET 2.0はこうした新機能を備えるとともに、前バージョンからのアップグレードが容易な設計になっており、既存のASP.NET開発者は簡単に移行できる。ASP.NET 2.0はASP.NET 1.0および1.1との下位互換性があるため、既存のアプリケーションをASP.NET 2.0環境に組み込んでその新機能を利用可能だ。ただし、1つだけ注意点がある。開発者がASP.NETの新機能の一部(パーソナライズなど)を独自に構築していた場合は、それに代えてASP.NETの搭載機能を利用するには、自分のコードに変更を加える必要があるということだ。また、ASP.NET 2.0は前バージョンと並行して動作するため、1台のWebサーバで新旧のアプリケーションを同時にホストできる。
ASP.NET 2.0は、Windows 2000、Windows Server 2003、Windows XPをサポートしている。Visual Studio 2005とともに、現在ベータテストが行われており、2005年前半にリリースされる予定だ。MicrosoftはASP.NETの前バージョンでは、開発者がASP.NETのベータ版を用いてアプリケーションを開発、運用できる「Go Live」ライセンスを提供していた。このライセンスの利用条件は、正式版のリリースから15日以内に正式版にアップデートすることに同意することだった。ASP.NET 2.0の最初のベータ版ではGo Liveライセンスは用意されていないが、今後リリースされるベータ版では提供されると予想される。
なお、Visual Studioのフル・パッケージに加え、Visual Web Developer Expressなど、初心者やホビイスト向けの新しいツール・セットのベータテストも進められている。
必要だったVisual C++でのリスク・ヘッジ
ASP.NETの最終的な成功は約束されているように見えるが、最初のリリース時には、(Microsoftの社内外の)懐疑派は、マネージド・コードによる高パフォーマンスのサーバ・アプリケーションの構築について、実現性を疑問視していた。ASP.NETのパフォーマンスが推進派の期待を下回ることが判明した場合を想定し、Microsoftは二股をかけ、Visual C++ .NETとともに、Webサービス/アプリケーションを構築するためのネイティブコード・フレームワークを導入した。このフレームワークはATL Serverと呼ばれるもので、C++テンプレートに基づくプログラミング・モデルを提供している(ATL Serverの「ATL」は、ActiveX Template Libraryの頭文字を取ったもの。ActiveX Template Libraryは、COMオブジェクトやActiveXコントロールを作成するためのC++テンプレート・ライブラリだが、ATL自体はCOMやActiveXを必要とせず、ISAPIをベースに構築されている)。
ATL Serverの存在意義は希薄化
いくつかの要因が相まって、ATL Serverのライブラリは非戦略的なものになっており、新しいプロジェクトのための有効な選択肢ではない。第1に、ATL Serverは複雑な言語の複雑な言語機能をベースにしているため、一般の開発者向けではない。このフレームワークが適しているのは、何らかの理由でASP.NETを自分のアプリケーションで使用できない熟練したC++開発者に限られる。
第2に、Microsoftはサーバ製品の多くをASP.NET上で開発しており、ASP.NETでどのような課題が生じても、非常に意欲的に解決に当たる。これに対し、ATL Serverを使っていることが知られているMicrosoft社内の部門はなく、今後の開発の進展は見込み薄だ。
第3に、懐疑派が提起したASP.NETのパフォーマンスの問題は生じていない。ASP.NETは多くの大規模アプリケーションをホストするために使われており、一部の利用シナリオではキャッシング機能のおかげで、同様のネイティブ・コードよりも高いパフォーマンスを発揮している。このことからいえるのは、戦略的に重要でないことに起因するATL Serverのリスクを帳消しにして、このフレームワークを採用する積極的な理由となるものは、ほとんどないということだ。
参考資料
-
ASP.NET 2.0の新機能の詳細については、『Directions on Microsoft日本語版』2004年2月号の「ASP.NET 2.0で変貌するWebアプリの開発環境」を参照。
-
IIS 6.0の詳細については、『Directions on Microsoft日本語版』2002年7月号の「Windows .NET Serverを支えるIIS 6.0、再設計で信頼性とセキュリティが向上」を参照。
Directions on Microsoft日本語版 本記事は、(株)メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。 |
INDEX | ||
Insider's Eye | ||
マイクロソフトWebアプリケーション最新動向(1) | ||
コラム:ブラウザ間に残る非互換性の課題 | ||
マイクロソフトWebアプリケーション最新動向(2) | ||
「Insider's Eye」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|