ASP.NET と Struts : Web アプリケーションのアーキテクチャ

M. Keith Mortensen、Infusion Development
Rob McGovern、Infusion Development
Charles Liptaak、Microsoft Corporation

December 2003
日本語版最終更新日 2004 年 2 月 6 日

適用対象 :
    Microsoft® ASP.NET
    Microsoft .NET Framework
    Jakarta Struts

概要 : .NET Framework をベースとする ASP.NET と Java 2 Enterprise Edition をベースとする Struts との類似点、相違点について説明します。また、開発者に共通する問題を解決するためのそれぞれの機能について説明します。さらに、それぞれの長所と短所についても述べ、次世代の Web 開発に利用できるユーティリティについて示します。

目次

はじめに
プラットフォームの概要
Web フレームワークの類似点
フレームワークのパターン
今後の動向
Struts と J2EE のアプリケーションを ASP.NET に移行する
まとめと結論
補足

はじめに

この 10 年間でビジネスの形と情報へのアクセス方法は様変わりしました。1990 年代の初めに単純な情報ポータルが出現して以来、インターネットはビジネス、商取引にとって重要かつ収益性の高いフォーラムへと急速な進歩を遂げました。こうした進歩により、エンタープライズ Web アプリケーションを構築するための重要な標準が 2 つ生まれました。1 つは Microsoft® ASP.NET (および Microsoft .NET Framework) で、もう １ つは Apache の Struts (J2EE フレームワークを含む) です。

.NET および Java の各コミュニティに属している設計者と開発者は、現在、この 2 つのテクノロジの適用範囲、機能性、基本アーキテクチャにおける違いを探っています。ここでは各プラットフォームの概要を述べ、その類似点と相違点を詳しく説明し、開発者に共通する問題を解決するための機能について検討します。ASP.NET と Struts に実装されている業界標準パターンのおかげでコードの複雑さが軽減され、開発期間が短縮されたことを示します。さらに、それぞれの長所と短所を確認し、次世代の開発に利用できるユーティリティについても述べます。

Web 開発の簡単な来歴

Web が登場して間もないころ、ビジネス Web サイトのほとんどは単に広告の形をとり、ユーザー マニュアルやパンフレット、カタログを顧客に提供するものにすぎませんでした。ドットコム革命が起こり、企業各社では顧客にオンライン サービスを提供できることも認識しました。今や、顧客はただ商品一覧を眺めるだけでなく、商品を買えるようにもなったのです。こうしてドットコム革命が新たな段階にさしかかったことで、多くの新たな必要条件が生じました。つまり Web サイトは、信頼性が高く、可用性があり、安全でなければならず、高速であればさらに好ましいというわけです。

このような初期の電子商取引 Web サイトは、多くの場合、Java ベースのテクノロジ (JSP、EJB、サーブレット、JDBC など) または Microsoft ベースのテクノロジ (ASP、VBScript、MTS、ADO、COM、COM+ など) のいずれかで動作していました。確かにこれらのテクノロジは機能しましたが、ほとんどの Web サイトはスケーラビリティ、信頼性、セキュリティのどれもがそれほど考慮されずに、あわただしく構築されました。

Java 2 Enterprise Edition

1990 年代の終わりに、ドットコム現象は本格化しました。しかし両陣営の設計者たちは、Web 開発が自然に発展していくためには、その当時使用されていたさまざまなテクノロジを標準化するしかないことに気付きました。

1999 年の春、Sun は J2EE 標準をリリースしました。これは、種類の異なる非常に多くの Java テクノロジを一本化したものです。この標準化を受け、相当数のサードパーティ各社では、J2EE アプリケーションの構築に特化したツールが開発できるようになり、エンタープライズ Web の開発プロセスが大幅に短縮できるようになりました。

しかし J2EE 標準が登場してもなお、いくつかの重要な問題点が残りました。特に新規の Web アプリケーションや改良した Web アプリケーションは、バックエンドの受発注システム、処理システム、料金請求システムとの統合によく失敗しました。たとえフロントエンドがしっかりした設計で、スケーラブルであっても、バックエンドのビジネス ロジックとデータの永続性が Web からの新しいオーダーの殺到に対応できる作りになっていないことが多かったため、やはりシステムは停止しました。一体化されたビジネス ツールと Web サービスがより必要であることが明らかになりました。さらに、それとは別の傾向がより明白になってきました。アプリケーションの規模が大きくなればなるほど、保守と拡張が困難になってきたのです。信頼性を備えたスケーラブルなアプリケーションのコード ベースは、きわめて複雑で管理の難しいものになろうとしていました。

このような背景から J2EE におけるパターン革命の基盤が生まれたのです。開発者や設計者はどのようにして、前述した既製のテクノロジで構築されたシステムを設計し、なおかつ複雑さに絡む問題を避け得たのでしょうか。

ASP.NET の起源

そうした動きと並行して Microsoft は別の道に進むことを決定し、各種のテクノロジをただ再編して別の名前を付けるのではなく、設計を変更するという選択をしました。完全に一体化された環境を作り上げることにしたのです。その結果生まれたのが Microsoft .NET Framework です。これは初期のアプリケーション モデルとは根本から異なるものです。コードの複雑さを減らすため、この新しい柔軟なフレームワークは必然的に Model View Controller (MVC) デザイン パターンを採用し、インターネットのオープン スタンダード (HTML、XML、SOAP) を軸に構築され、Web サービスの新たなパラダイムを支えました。設計をし直す過程では、セキュリティ、パフォーマンス、可用性、信頼性、保守性、拡張性、相互運用性など、企業にとって核となる必要条件がかなり配慮されました。

パターン革命から J2EE へ

2000 年の春、Bill Gates と Steve Ballmer の各氏が .NET を発表しているちょうどそのころ、Craig McClanahan 氏は Java プラットフォームをベースとする企業規模の Web アプリケーションのコードの複雑さを軽減する活動として、Struts プロジェクトに取り組み始めました。ここで作成された Struts エクステンションは Model View Controller (MVC) パターンを実装したものであり、基本的には Front Controller パターンと Intercepting Filter パターンを利用して目的を達成するというものです。MVC の各種実装の違いについては後述します。

第 3 世代の Web アプリケーション

現在 ASP.NET と Struts は、開発作業で日常的に発生する問題に強力なソリューションを提供する段階にさしかかっているところです。この両者から提供されるエンタープライズ アプリケーション フレームワークは、非常に重要であることが証明済みであり、企業にとっての開発サイクルが一層短くなり、これまで以上に信頼性が高まることは確実です。J2EE および .NET という各プラットフォームを支えているテクノロジや方法論には相当大きな違いがありますが、ASP.NET と Struts を利用すれば、過去の Web 開発はまるで産業化以前の労働のように思えるでしょう。

プラットフォームの概要

.NET および Struts/J2EE という開発環境と実行環境には、多くの類似点といくつかの大きな相違点があります。図 1 に、この 2 つの環境の関係を示しました。

図 1. ASP.NET と J2EE (Struts を含む) のプラットフォームの階層構造

次の各セクションでは、各エリアの主要な類似点と相違点を見ていきます。

言語と IDE

言語/開発環境の階層構造における主な違いは概念的なものです。J2EE の場合、言語は 1 つしか (Java のみ) 選択できませんが、開発環境は幅広く選択できます。IDE はそれぞれ、言語と Web のツールキットに対するサポートのレベルが異なります。たとえば、キーワードを色付きで表示できる単純なテキスト エディタ、またはデバッグのできる十分な環境のどちらでも作業ができます。当然、IDE とそれ以外のコンポーネント (OS、アプリケーション サーバーなど) との統合の度合いはベンダによって大きく異なります。

ASP.NET では、開発言語の選択肢は多くありますが、開発環境は主として 1 つしかありません。ASP.NET は、軽い Web Matrix 製品を使用したテキスト エディタでもサードパーティ製の別のエディタでも開発できますが、主な開発環境は Microsoft Visual Studio® .NET です。Visual Studio .NET は非常に高度な IDE の 1 つであり、コンソール、ワイヤレス、Web、Web サービス、Windows アプリケーションの開発に対応しているだけでなく、BizTalk® Server 2004、Office 2003、Content Management Server など、他の Microsoft 製品の IDE としても働きます。このように Visual Studio .NET は活用範囲がかなり広い環境であるため、長期にわたって絶えず改善し、発展していくことが約束されます。サードパーティのツール開発者もこの IDE を活用して、Visual Studio .NET で動作するツールが作成できます。たとえば Crystal Reports と Rational XDE では、同製品に特に関係のある .NET 開発を加速するため、Visual Studio .NET に各種モジュールを組み込みました。このレベルまで統合を図れば Visual Studio .NET は非常に強力な開発ツールとなります。

アプリケーション サーバーとオペレーティング システム

J2EE および .NET Framework はどちらも、Web アプリケーションのホストとして動作し、基本的なサービスを提供するのに、サーバーが 1 台は必要です。このサーバーとランタイム自体も同様に、ベースとなるオペレーティング システムが必要です。

J2EE フレームワークはプラットフォームの種類を問わず機能するよう設計されました。そのような設計思想に基づいて、これまで多くのベンダがさまざまなオペレーティング システムで動作する J2EE アプリケーション サーバーを構築してきました。プラットフォームの種類を問わないことは有益ではありますが、同時にオーバーヘッドと複雑さも著しく増します。複数のオペレーティング システム (OS) をサポートするにはアブストラクション層が必要なため、アクセスできる OS 機能の数がやむなく制限されます。ベンダによって統合の度合いは異なることがあり、どのアプリケーション サーバーを選択するか、それをどのオペレーティング システムで実行するかによっても、パフォーマンスが大きく異なる可能性があります。結局、ベンダが混在していると、各ベンダのアップグレード/パッチのサイクルに目を配らなければならず、ベンダによる変更が生じた場合には、それ以外のすべての製品を確認しなければならないため、多くの場合サポートが複雑化します。プラットフォームの種類を問わないことは有益ではありますが、関連するコストが必ず生じます。

アプリケーション サーバーが OS から完全に独立している J2EE とは異なり、.NET アプリケーション サーバーは、Microsoft Windows® オペレーティング システム (および Windows から提供される各種サービス) です。.NET Framework は IIS および COM+ に緊密に統合できるよう設計されたため、アプリケーション ホスティング サービスが確実にでき、XML、SOAP、UDDI、WSDL のような Web サービス標準をネイティブ サポートすることができます。このような統合は .NET アプリケーションのパフォーマンスを飛躍的に高めはしますが、プラットフォームの種類は 1 つに限定されます。どの J2EE サーバーの場合と比べても統合の度合いははるかに高く、そのため多くの機能が得られ、より高速になります。

ランタイム

J2EE と .NET Framework はどちらもランタイム エンジンを土台にして動作します。ランタイムは、コードを読み取って翻訳し、メモリ管理など重要なサービスを提供します。両者のランタイムは、設計思想が異なるため、その目標も大きく異なります。

Java ランタイムは異なるオペレーティング システム間で移植できるよう設計されました。このことは移植の必要な場合には有利に働きますが、コードは実行については最適化できても、特定のオペレーティング システムや特定のアプリケーション サーバーについては最適化できないため、アプリケーションのパフォーマンスを上げるにも限度があります。サードパーティ製の製品の中には、特定の OS に最適化してあることを謳ったものがよくあり、多くの場合、その移植性は犠牲にされています。

一方、共通言語ランタイム (CLR) は 2 つの目標が達成できるよう設計されました。1 つは Windows オペレーティング システムで最適性能を発揮することで、もう 1 つは複数のプログラミング言語に対応できることです。CLR では、共通タイプ システムを利用することで、種類の異なるプログラミング言語にいくつでも対応でき、オペレーティング システムに変化が生じてもアプリケーションは影響を受けずに済みます。

クラス ライブラリ

Struts は J2EE と J2SE と両方のクラス ライブラリを大いに利用しています。このクラス ライブラリは、さまざまなベース パッケージ グループ (java、javax、org) に応じて区分けされた約 135 個のパッケージから成ります。Struts フレームワークでは、Struts の働きに特有の新しい基本クラスを通じて機能を組み込むために、ライブラリ セットが若干拡張されています。J2EE、J2SE のどちらのライブラリも完全に機能しますが、ライブラリは絶えず拡張しているため (J2EE ライブラリはバージョン 1.2 から 2 倍以上に拡張しました)、今では複雑さが増し、本来のわかりやすさが失われてしまいました。たとえば、XML アクセスに org.xml または java.xml をいつ使用すればいいのか、あるいはリモート メソッド機能に java.rmi、javax.rmi、org.omg.stub.java.rmi のいずれかをいつ使用すればいいのかは、常にはっきり決められるわけではありません。ライブラリの一部は、互換性を維持するためにバージョンによって分かれていますが、その区分けに明確な理由があるわけではなく、慣れない人が見てもすぐにはわかりません。

.NET Framework には、豊富で大規模な基本クラス ライブラリ (BCL) があります。各クラスは、パッケージとほぼ同じ論理グループである機能名前空間ごとに整理されています。たとえば System.Web.UI には Web のユーザー インターフェイス用のクラスがすべて含まれています。System.Web.UI.Page クラスには ASP.NET ページに必要なメソッドとプロパティが含まれています。.NET Framework (1.1) BCL には 200 個をわずかに上回るほどの必須の (System.*) 名前空間が含まれています。

バージョン管理

Java プラットフォームと .NET Framework との大きな違いの 1 つは、.NET には厳密に適用されるバージョン管理スキームが元来備わっていることであり、このスキームは .NET Framework と .NET Framework をベースに構築されたアプリケーションの両方に適用されます。Java の場合、フレームワークのバージョンはドキュメントに記録され、特殊な "deprecation" タグを通じて適用を受けるのは一部に限られます。ほとんどの場合、新規の Java パッケージは下位互換性を考慮して作成されます。Web 配置ディスクリプタに XML タグを使用すれば、アプリケーション レベルでその他のバージョン管理を使用することができます。ただし、そのバージョン管理システムは厳密に適用されるわけではなく、side-by-side 配置は管理が困難です。

.NET の場合は、.NET Framework がバージョンの識別を行うため、バージョン管理はほとんど問題になりません。BCL の各アセンブリにはバージョン番号を含んだ厳密な名前が付いているため、さまざまなバージョンが競合せずに並行して作動できます。言い換えれば、.NET の新規バージョンは新規の名前空間を含んでいなくても既存のクラスが修正できるということです。同じアセンブリの両方のバージョンを当該コンピュータ 1 台にロードすることができるうえに、CLR により、アプリケーションをコンパイルするとき利用したバージョンのライブラリにそのアプリケーションが自動的にバインドされます。新しい方のバージョンにアプリケーションをリダイレクトする場合は、グラフィカル ツールかコマンド ライン ツールを使用してリダイレクトを設定することができます。これと同じシステムがアプリケーション レベルで使用されます。つまり、どのアセンブリにも厳密な名前を付けることができ、どのアセンブリも、CRL から適用されるバージョン管理が利用できるというわけです。

Web コンポーネント

J2EE と .NET Framework はどちらも非常にバラエティに富んだ Web アプリケーション テクノロジを備えています。J2EE の場合はサーブレット、JavaServer Page、タグ ライブラリの中から選択できます。ブラウザ検出を実行したり、ブラウザに固有の出力を生成したりするため、これまで多くのタグ ライブラリ セットが作成されました。ただし、ブラウザ検出は現在 J2EE フレームワークには組み込まれていません。この機能は今後 JavaServer Faces 仕様に組み込まれる可能性があります。

.NET サイドでは、ASP.NET を使用して Web アプリケーションが構築されます。ASP.NET ページには Web コントロールが含まれます。Web コントロールの多くは、テキスト ボックス、ボタン、その他フォーム要素などの機能を備えたコンポーネントのうち、マウスでドラッグ アンド ドロップできるグラフィカル コンポーネントです。Web コントロールにはブラウザ検出や出力の自動生成などの機能が豊富にあります。既存の Web コントロールはすべて拡張も可能であり、新しい Web コントロールを作成できるので、独自の機能が実行できます。

データ アクセス

J2EE Framework と .NET Framework のどちらにもデータ アクセス ライブラリがあります。どちらのライブラリでも、中核を成している機能を使用すれば同じようにデータベースに直接アクセスできます (たとえばコマンドを発行して結果を受信するなど) が、拡張機能と基本的なパラダイムは大きく異なります。

Java JDBC の中核を成すライブラリでは、ごく普通の方法でデータベースにアクセスできます。ステートメント (通常はクエリやストアド プロシージャ コール) を発行すると、データベースとのライブ接続により ResultSet という形で結果が受信できます。データベースのコールと結果は、開いている接続によって常に異なります。いくつか高度なクラスは、切断されたデータセットに対応していますが、JDBC ライブラリは、Web アプリケーションではごく普通の断続接続という状態に対応できるような設計にはなっていません。さらに、JDBC は XML データの読み書きに直接は対応していません。これまでいくつかのベンダが XML ベースのデータベース アクセスを目的とする JDBC ラッパーを作成してきましたが、J2EE の中核を成すクラスはそれに対応していません。

ADO.NET は、ADO および JDBC と同様の機能が発揮できる一方で、その土台にあるのは非接続というパラダイムです。データベースから取り出されたデータが、DataSet という名前のオブジェクトに格納されると、そのデータベースとの接続が閉じます。その後はデータベースにライブ接続していなくても、DataSet に格納されたデータにアクセスして操作をすることができます。変更が済んだら、単一の瞬時トランザクションとして ADO.NET を通じて DataSet を元通りデータベースに同期せさることができます。切断時のこういう動作は、Web アプリケーションのような分散環境を相手にするときはきわめて有利で効果的であり、必須条件であることがほとんどです。

ADO.NET は XML も扱えるよう設計されています。ADO.NET は、どのようなデータセットでも自動的に XML 変換できるだけでなく、データセットをベースにして XML スキーマを抽象化することもできます。こうした機能は、Web サービスや、その他 XML ベースのデータ配信メカニズムにとって特に便利です。

Web フレームワークの類似点

インターネットの発展に伴う課題を解決するため、.NET および J2EE のどちらでも、アプリケーションに共通する問題を解決するためのフレームワーク コンポーネントが作成されました。ASP.NET と Struts では、そうしたコンポーネントの充実を図り、Web 開発手順が一層確実なものになるよう努めています。次のセクションでは、妥当性検査、キャッシング、状態管理、セキュリティ、構成、国際化、トレーシング/インスツルメンテーションに特に注目して、各種フレームワーク コンポーネントの比較をします。

妥当性検査

重要なアプリケーションはほぼすべて、何らかの形でユーザー入力の妥当性を検査する必要があります。データの妥当性検査をしないと、アプリケーションはおびただしい件数の攻撃にさらされて、簡単に破壊されるおそれがあります (たとえば数値入力用のフィールドに数字以外の値が入力される、など)。ユーザー入力の妥当性を検査すれば、ありがちな問題を防げるだけでなく、アプリケーションのセキュリティも向上します。

Struts と ASP.NET はどちらも、ユーザー入力を検査したり、妥当性検査ロジックの実装を短期化するために、包括的な妥当性検査構造を備えています。ただし、どちらのフレームワークも問題の解決方法はまったく違うものの、同じような結果が出ますが、ソリューションとツールセットはそれぞれ独自のものです。

Struts Validator

Struts フレームワークは、Struts 1.1 のときに Struts Validator (英語) が組み込まれました。Struts Validator は、XML ファイルを利用して構成できる新たなデータ フォーム スーパー クラスです。この XML ファイルには、データ型 (integer、string など) や文字列形式 (電子メール アドレス、クレジット カード番号など) のような標準的な妥当性検査を行うための規則が記述されています。基本的な規則は簡単にカスタマイズでき、新たな規則を追加することもできます。妥当性検査の必要なフォーム アクションは、すべて Struts Validator から引き継がなければならず、 XML のフォーマット規則は正規表現の形式にのっとっている必要があります。フォームが発行されると、無効な値とエラー メッセージはすべてビューに返されますが、独自のコードが記述されていないと、妥当性検査のエラー メッセージは表示されません。

Struts フォームに妥当性検査の機能を追加するには、フォーム クラスを書き換え、XML ファイルを編集し、JSP コードを記述して、妥当性検査のどのエラー メッセージもユーザーに返されるようにする必要があります。このため、妥当性検査の機能は初期設計のときに追加するのが最適です。既存のアプリケーションに妥当性検査の機能を追加するためには、継承ツリーの変更が必要となり、場合によってはそのアプリケーションが壊れるおそれがあります。

ASP.NET の妥当性検査コントロール

ASP.NET での妥当性検査機能の設定は簡単です。設計時にサーバー側のコントロールを目的のページ上にドラッグ アンド ドロップしてから、そのコントロールのプロパティをいくつか設定するだけです。ASP.NET には、必須フィールドの検査、値の比較、範囲/パターン マッチングの確認ができるよう、そのままで使用できる妥当性検査コントロールがいくつか用意されています。パターン マッチング コントロールは、標準的な正規表現チェック (電話番号や電子メール アドレスなど) から成る大規模なライブラリを備えていて、どのような正規表現でも使用できるよう設定できます。妥当性検査は、プログラムにより実行することも可能ですが、適切なイベントの作成や妥当性検査コントロールの起動を手動で行うにはもう少し時間が必要です。

これら妥当性検査コントロールは、すべてサーバー側のコントロール (すなわちサーバー上で実行される) ですが、各コントロールはクライアント側の妥当性検査も実行できるよう自動的に設定されます。クライアント側で妥当性検査をすれば、サーバーにページを発行して処理を受けなくても、ユーザーは自分の起こしたアクションに対するフィードバックが直ちに得られます。実際には、そのページのエラーがすべて解決するまで、ユーザーはそのページをサーバーに戻すことができません。コンパイル時に ASP.NET は、クライアント側の妥当性検査をするのに必要な JavaScript を自動的に生成します (これはブラウザが Internet Explorer 4.0 以上の場合です。それ以外の場合妥当性検査はサーバー側で実行されます)。クライアント側の妥当性検査が実行されたかされなかったか、またどのように実行されたかにかかわらず、ページのなりすまし攻撃を防ぐため、フォームが受信されるとサーバー側の妥当性検査も実行されます。

キャッシング

Web アプリケーションでは、クライアントのアクセス速度を上げるために、キャッシングがよく使用されます。Struts の場合、コンテンツのキャッシングは開発者、または JCACHE のようなサードパーティ製のキャッシング システムのいずれかに委ねられます。すなわち、開発者は独自のキャッシング システムを構築するか、サードパーティ製品をアプリケーションに組み込まなければならないということです。ほとんどの場合、開発者はキャッシング機能をカスタム タグ ライブラリに組み込みます。一部の J2EE サーバーは元からキャッシング機能を備えていますが、それでも Java コミュニティでは、標準的なキャッシング インターフェイスを開発しなければなりません。将来、J2EE Tiles 機能により、ページ レベル、オブジェクト レベルでキャッシングのできる組み込みシステムが実現されるでしょう。

しかし ASP.NET には、オブジェクト レベル キャッシング (コード オブジェクトを格納する)、入力パラメータ ベースのキャッシング (入力パラメータに従って動的ページを格納する)、時間ベースのキャッシング (指定の時間にコンテンツを格納する) など、膨大な数の組み込みキャッシング機能があります。必要に応じて、データ オブジェクトでも動的ページ全体でも、キャッシュに入れることができます。ユーザー入力に応じて表示が変わるようになっているのに、実際の表示がほとんど変化しないような場合は、HTTP 要求の入力パラメータに基づいてページをキャッシュに入れることさえ可能です。言い換えれば、製品 ID によって左右される製品ページをキャッシュに入れることができるということです。ASP.NET は、要求される入力パラメータ (製品) ごとにページを 1 枚自動的にキャッシュに入れます。その後同じ製品に対して要求がなされた場合は、ページを一から作り直すのではなく、キャッシュに入っている方のページを持ってきます。ASP.NET のキャッシング メカニズムはすべて、各種の属性を使用して宣言文のような形で設定することができます (すなわちコード化は不要です)。また、プログラムを組んで単純な API からキャッシュにアクセスするのも可能です。ASP.NET のキャッシング システムには、静的もしくは半静的なコンテンツを相手とするユーザー応答の改善や、アクセス時間の短縮化を図るためのオプションが豊富に揃っています。

状態管理

状態管理を利用すると、複数の Web 要求/応答サイクルの最中に、Web アプリケーションがユーザーとユーザー のデータ両方の動きを監視することができます。状態管理は、クライアント側 (たとえばクッキーや隠しフィールドを使う) でも、サーバー側 (たとえば Session オブジェクト内で行う) でも実行できます。ただしクライアント側、サーバー側のいずれであっても、状態管理を行うためには、複数の要求の中から目的のユーザーを見分けるための何らかのメカニズムが必要です。通常、これにはクッキーかURL に埋め込まれたセッション ID のいずれかを利用します。

サーバー側

Struts も ASP.NET も、ホストされた似たようなオブジェクト (Session および Application) を利用して、複数の要求間の状態を維持しています。ただし次に示すように、ASP.NET にはセッション情報を格納するためのメカニズムが 3 とおりあります。

1. イン メモリ : この方式を選択した場合は、要求を受信したコンピュータのメモリに状態が格納されます。1 台のサーバーで実行する小規模のアプリケーションならこれで問題ないでしょうが、同じユーザーから続いて要求が送られてきた場合、その要求が同じサーバーに届く保証がないため、Web ファームにとって満足できるソリューションではありません。
2. セッションステート ストア : Web ファームでセッション状態を使用するときは、ステート ストアと呼ばれるものを使用できます。このステート ストアは、Web ファームのいずれかのメンバにセットアップされます。 これは基本的には、ローカルにコールできるサービスか、あるいはその Web ファームの他のメンバからコールできるサービスのいずれかです。Web ファームのすべてのメンバは、中央に置かれたこのステート ストアを処理できるよう設定する必要があります。そして、そこからそれぞれのセッション情報の格納/取り出しを行います。これは、セッション状態を格納するには非常に効率的な方法ではありますが、確実性に欠けます。状態情報はメモリにしか格納されないため、ステート ストアをホストしているコンピュータがクラッシュすると状態情報はすべて失われます。
3. データベース : セッション状態を格納するうえでこれ以上ないほど確実で信頼できるのは、データベースに格納する方法です。Visual Studio .NET には、Microsoft SQL(TM) Server でステート ストアをセットアップするためのデータベース スクリプトがあります。

同じような機能は一部の J2EE ベンダも提供していますが、こうした機能は J2EE、Struts のどちらのフレームワークにも最初からは付いていません。

クライアント側

クライアント側では、Struts と ASP.NET のどちらのフレームワークも、要求のたびにそのユーザーを確認するという方法により、クッキーと隠しフィールドを使用して状態を維持しています。ただし Struts フレームワークは、ID を管理するのに J2EE アプリケーション サーバーに全面的に依存しているため、サーバーごとに動作の異なることがあります。その他すべての状態については、開発者が隠しフィールドとして手動でエンコードするか、カスタム クッキーの中にドロップする必要があります。

J2EE とは異なり、ASP.NET フレームワークはただ 1 つのメカニズムにより、クッキーと隠しフィールドを通じてクライアント ID の管理を自動的に行います。開発者は、簡単に使用できるプログラミング インターフェイスを通じてその処理を見ることができます。クッキーはコレクションに格納されます。また、開発者はクッキーにより通常の収集処理構文を使用することができます。ASP.NET はクッキーを利用しないセッション状態にも対応しています。その場合は、アプリケーションの構成ファイルによる設定が可能で、複数の要求にまたがってセッション ID を維持するのにクエリ文字列が使用されます。

ASP.NET には、View State プロパティという独特の形式のクライアント側状態管理機能もあります。View State は、各 ASP.NET コントロールのプロパティの 1 つであり、サーバーへ行って返ってくるまでコントロールの値を保持するのに使用されます。このストレージにより、要求が次々と変わってもユーザー入力を保持しておくのが非常に簡単になります。しかし開発者は、要不要にかかわらず、どのコントロールにも View State プロパティが 1 つずつあること、その値が埋まっていることを覚えておく必要があります。View State は、隠しフィールドとして実装され、要求があれば毎回クライアントに送信されるため、本当にメモリを必要としているフィールドに対してのみ有効になるよう設定する必要があります。

セキュリティ

セキュリティは、設計から開発、導入、日常的な使用に至るまで、アプリケーションのあらゆる段階で、大切な役割を演じます。Struts は、JSP/Servlet と J2EE の各フレームワークに組み込まれているセキュリティ機能を利用するため、特に具体的なセキュリティ機能はありません。J2EE フレームワークには、認証と認可を行うための基本的なサービスがありますが、多くの場合、正確な実装は J2EE サーバーによって異なります。一方、.NET Framework と特に ASP.NET には、認証と認可のような単純なタスクでは及びもつかない高度なセキュリティ機能が多くあります。

認証

ASP.NET は何も設定をしなくても、Windows、Microsoft Passport、フォームの各認証機能が発揮できます。Windows と Passport の認証は、ASP.NET ランタイムの外で実行されるので、この資料では説明していません。

フォーム認証とは、認証を受けていない要求を ASP.NET がログイン フォームにリダイレクトするときのメカニズムのことです。ユーザーの提供した資格情報が検証されると、そのユーザーは、最初に要求したページにダイレクトされて戻ります。その後の要求は、ユーザーに操作を求めることなく自動的に認証されます。単純なアプリケーションの場合は、ASP.NET アプリケーションの構成ファイルに収録されている、ユーザー、役割、認可といった各エントリに照らしてユーザーの資格情報を認証することができます。それよりも複雑なアプリケーションの場合は通常、外部の資格情報ストアが使用できるようフォーム認証が拡張されます (「フォーム認証の拡張」を参照)。

認可

ユーザーの認証が済むと、URL 認可機能により、要求されたリソースへのアクセスを許可するか否かが決定されます。URL 認可機能は、あらかじめ設定しておいた情報に従って働きます。つまり、アプリケーションの構成ファイルに記述してあるエントリに従って、どのユーザー/役割にどのリソースへのアクセスを許可するかが決定されます。認可機能は、ロールベースのセキュリティ モデル全体に簡単に適用できます。

偽装

偽装すると、ページを要求したユーザーの ID で ASP.NET アプリケーションを実行することができます。ASP.NET は、認証を受ける、受けないにかかわらず IIS から受け取ったトークンを使用するだけなので、偽装をすると、認証および認可は IIS にまで及びます。偽装中、ASP.NET は、個々のリソースへのアクセスを許可するべきか拒否するべきかを決めるために、ファイルとフォルダに関する標準的な NTFS パーミッションを利用します。

構成

Struts も ASP.NET も、細かなところまで設定でき、アプリケーションの設定用として XML ベースの一元化構成ファイルを持っています。J2EE アプリケーション サーバーの一部は XML ベースでのサーバー設定にも対応しています。ただし、それぞれの J2EE ベンダによって、サーバーとアプリケーションの両方の設定をいつどのようにして読み取るかを決めるためのメカニズムは異なります。J2EE は多くのさまざまな構成ファイル (struts-config.xml、web.xml、server config files など) を使用するため、デバッグ構成が非常に難しくなることがあります。また J2EE アプリケーションには、構成ファイルを読み取るための共通のメカニズムがありません。一部のオブジェクト (ServletContext など) には自動アクセスという機能があるのに対し、他のオブジェクト (Struts Controller など) は独自のコードが必要です。

一方 ASP.NET には、アプリケーションごとに XML ファイルが 1 個あり、当該コンピュータについては全体で XML ファイルが 1 個あります。どの ASP.NET ページも、アプリケーション レベルの XML ファイルに格納されているすべての部分に対して、ネイティブ アクセスができます。このように単純化された構成構造をしている方が、デバッグとアクセスははるかに簡単です。さらに ASP.NET は、自動的に構成ファイルになされた変更点をすべて拾い集め、それをその場で適用します。ランタイムは、構成ファイルに生じた変化を見つけると、ASP.NET ワーカー プロセスをリサイクルして新たな構成をロードしている間、入ってきた要求をキューの中に入れておきます。要求は失われることなく、プロセスはきわめて迅速です。一部の J2EE サーバーはこのように機能しますが、多くの場合、構成ファイルになされた変更点を拾い集めるには、完全にリブートをかける必要があります。

国際化

どのようなサイトであっても、書式設定および言語に関する国際化機能を盛り込むにはかなりの努力が必要です。テキストをこと細かに見なければならないだけでなく、1 つ 1 つの表示データ (価格や住所などの情報) や、1 つ 1 つのイメージについてはもちろんのこと、可能ならアプリケーション全体の配色さえ良し悪しを決めなければなりません。さいわいなことに、Struts と ASP.NET のどちらにも、国際化の作業を支援するフレームワークが用意されています。

Struts (Java 全般) の場合、ユーザーの地理的な場所と言語はロケールとして定義されます。ロケールは、他のさまざまなクラスに渡され、情報を構文解析してユーザーの国に適した形式に変換するのに使用されます。その言語ロケーション ペアの語、句、画像は、キー値のペアという形でリソース バンドルの中に格納されます。"greeting" のような重要な語を、US-English ロケールでは "hello world!" として、また DK-Danish ロケールでは "goddag verden!" として対応付けることができます。リソース バンドルは、どのタイプのリソースが必要であるかに応じて、テキスト ファイルか Java クラスのいずれかにできます。

ASP.NET と .NET Framework の場合は、ユーザーのロケールを包括的に記述したものがカルチャ オブジェクトに内蔵されます。カルチャ別の書式設定は、日付/時刻、数字、テキスト情報の各クラスから成るカルチャ別インスタンスから自動的に指定されます。テキストやイメージなどのカルチャ別リソースを取得するため、ランタイムはリソース マネージャを使用し、リソース マネージャはリソース ファイルを読み取ってから、現在のカルチャに基づいて適切なリソースを返します。

各種のリソースは、開発中は 1 個の XML ファイルの中に入れられていますが、実際の稼動環境で最適性能が得られるよう、コンパイルにかけて複数のサテライト アセンブリにすることができます。既定のカルチャはメイン アセンブリにコンパイルされ、さらにカルチャごとにもう 1 つ別にサテライト アセンブリが 1 つずつあります。

トレーシングとインスツルメンテーション

トレーシングを行うと、アプリケーションの実行に関する有益なメッセージが実行時に表示されるので、障害の診断が容易になります。一方、インスツルメンテーションは、パフォーマンス カウンタを使用してアプリケーションのパフォーマンスを計ったり、監視するのに必要です。

Struts は、Log4J コンポーネントによるロギング機能を備えており、いくつかのアプリケーション サーバーから提供される機能を利用した一応のトレーシング機能も備えています。こうした機能は、実際のアプリケーション サーバーによって異なることが多く、システムが違えばその機能は大きく異なります。J2EE、Struts のいずれも、はっきりとは示していませんが、パフォーマンス カウンタ、ランタイム トレーシング、その他組み込みインスツルメンテーションを備えていません。トレーシングとインスツルメンテーションの機能を実現するために、サードパーティ製品を選択するか、独自のシステムを構築するかは、開発者が決めることです。

トレース リスナとトレース スイッチ

ASP.NET は、.NET 基本クラス ライブラリを使用することにより、トレース リスナとトレース スイッチの原理に基づいて総合的なトレーシング機能を実現しています。Trace および Debug の各クラスには、トレース リスナが受信して処理にかけるトレースを生成するために、オーバーロードされたメソッドが多くあります。ファイル、イベント ログ、IDE のデバッグ ウィンドウのいずれかにトレース メッセージを書き込むため、ランタイムからさまざまな種類のリスナが提供されます。開発者は、キューやデータベースなどさまざまなターゲットにトレース メッセージを書き込むための、独自のトレース リスナを作成することができます。トレース スイッチを使用すると、トレース スイッチの値に従ってトレースを有効または無効にしたり、フィルタにかけることができます。このフレームワークは、特に設定をしなくても最初から 4 段階のトレース レベル (Error、Warning、Info、Verbose) を備えていますが、独自のトレース スイッチ階層の作成にも対応できます。トレース リスナとトレース スイッチは、アプリケーションの web.config ファイルにより設定できます。デバッグ ステートメントとトレース ステートメントが所定のビルドにコンパイルされるかどうかは、コンパイラ スイッチが制御します。

アプリケーションレベル トレーシング

ASP.NET のもう 1 つ大切なトレーシング機能は、構成ベースのアプリケーションレベル トレーシングです。単に web.config ファイルでこの機能を有効にするだけで、ASP.NET は大量の診断情報を収集し、それを要求されたページに追加します。収集される情報の中には、実行時刻、コントロール ツリー、セッション状態、アプリケーション状態、クッキー、ヘッダー、フォーム、クエリ文字列、サーバー変数などがあります。

パフォーマンス カウンタ

ASP.NET には、多くのパフォーマンス カウンタがあります。パフォーマンス カウンタからは、要求、セッション、エラー、キャッシングなどに関して、ASP.NET のランタイム パフォーマンスの詳しいデータが得られます。これら組み込み済みのカウンタの他にも、たとえば受信したオーダー、承認したオーダー、拒否したオーダーの各件数など、アプリケーション固有のデータを得るための独自のパフォーマンス カウンタを作成できます。

エラー診断

エラー診断については、アプリケーションの問題の原因を特定する操作がこれまでにないほど容易になりました。ブレークポイントを設定して、ページを 1 枚 1 枚、バックエンド コンポーネントを 1 個 1 個順にたどっていけるだけでなく、エラー発生時には、スタック トレースすべてを含んだ詳しいエラーメッセージが ASP.NET から生成されます。これにより、問題の原因を見つけるための時間と労力が大幅に削減されます。

フレームワークのパターン

Struts と ASP.NET が登場する前は、Java の開発者にも Microsoft の開発者にも、アプリケーションの複雑さを解消するためのガイドラインはありませんでした。J2EE や ASP の大規模なアプリケーションの多くは、その最たる例です。1 個のアプリケーションに含まれている膨大な数の層が互いに依存関係にあるため、変更、更新、拡張のどれをとっても困難でした。データベースの結果をキャッシュに入れる機能を、J2EE や ASP の既製のアプリケーションに組み込もうとすれば、そのアプリケーションの各ページを隈なく探し、当該コードの関連インスタンスをすべて何度も変更しないと、データのキャッシング機能は組み込むことができないでしょう。

コードをページに埋め込むと、同じアプリケーションで複数のマーケット (クライアントサーバーや PDA など) に的を絞ることも難しくなりました。その理由は、コードだと複製しなければならず、プラットフォームごとにまったく設計を変えなければならなかったからです。この問題を解決するため、多くの企業が独自のフレームワークの開発にかかりましたが、Struts と .NET が登場するまでは、包括的なフレームワークはありませんでした。

このセクションでは、Struts と ASP.NET が MVC パターンを利用してどのような方法でアプリケーションの複雑さを解消しているかを説明し、それぞれの長所を確認します。

MVC パターン

Web が登場する以前から、ソフトウェア アーキテクトはコンソール アプリケーションのユーザー インターフェイスについても、まったく同じ問題に取り組んでいました。ソフトウェア アーキテクトは、こうした問題を詳しく調べることにより、Model-View-Controller (MVC) パターンを定義することが可能になりました。MVC は最初に、商用として Smalltalk MVC framework (英語) に実装されました。これは Smalltalk-80 のユーザー インターフェイスの標準化に使用されました。

MVC パターンでは基本的に、1 個のアプリケーションが Model、View、Controller という 3 つのパーツに分かれます。MVC ではそれぞれ次のように定義されています。Model は、1 個のアプリケーションを対象に、利用可能なアクションとビジネス ロジックをすべてカプセル化します。View は、アプリケーションのプレゼンテーション層に相当します。Controller は、イベントの発生時に適切なアクションを必ず起こすためのメカニズムに相当します。

ユーザー インターフェイスに絡む問題を解消するため、これまで MVC パターンは J2EE と .NET というエンタープライズ アプリケーション プラットフォームに採用され、それに合わせて調整され、組み込まれてきました。次の 2 つのセクションでは、MVC パターンが Struts と ASP.NET でどのように実装されているかを詳述します。

J2EE の MVC と ASP.NET の MVC

J2EE MVC : Struts

Struts のアーキテクチャは、基本的には Front Controller と Intercepting Filter の両パターンを組み合わせたものが出発点になっています。Struts フレームワークには、アプリケーション イベントを管理するコントローラが 1 つあります。フィルタは、出入りするイベントを捕らえて処理し、MVC の各コンポーネントに必要な情報が正確に受信されるようにします。たとえば Struts Validator というのは、妥当性検査を受けた要求のみがコントローラに受信されるよう講じているフィルタのことです。

Struts フレームワークは、MVC パターンに定義されている Model、View、Controller という各コンポーネントにアプリケーションのコードを分割するためのフレームワークとなることで、Java アプリケーションにとってのファサードとして機能します。さらに Struts フレームワークには、そうした各層どうしでやりとりをするためのカスタム タグがあり、イベントとアクションを管理するための一元化コントローラもあります。詳細については、「Struts の MVC 実装」のセクションを参照してください。

ASP.NET MVC : Page Controller

ASP.NET は、Page Controller パターンにより MVC を実装しています。一方 Struts の実装は、アプリケーション レベルでの完全な制御ができますが、Page Controller パターンはそれとは異なり、個々のページ レベルでコントローラを使用します。ASP.NET ランタイムは、ページ要求をインターセプトし、要求されたアクションをモデルに対して実行し、生成されるページに使用する適切なビューを決定します。インターセプトとディスパッチのロジックは自動化されていて、開発者からは見えません。ASP.NET では、各ページが 2 つのパーツに分かれます。1 つは、さまざまなコントロールを含んだ View です。もう 1 つは、ページを処理するのと同時に ASP.NET Controller で引き起こすことのできるイベントごとのイベント ハンドラを含んだ分離コードです。開発者は、実際の制御メカニズムと対話する必要はなく、Model および View という各コンポーネントをつなぐイベント ハンドラを作成するだけです。詳細については、「ASP.NET の MVC 実装」のセクションを参照してください。

非常に複雑で規模の大きいアプリケーションには、通常、ページ間およびページとプロセス間でのナビゲーションに柔軟性が必要です。この柔軟性を実現するため、2 とおりの方法で ASP.NET コントローラのメカニズムを改善することができます。1 つは Page Controller を一元化する方法で、もう 1 つは Front Controller パターンを ASP.NET に実装する方法です。

Page Controller の一元化

オブジェクト指向のプログラミングに不慣れな開発者は、継承の能力と Page Controller を見過ごしがちです。その場合は、アプリケーションの規模が大きくなるほど、アプリケーションの複雑さに絡む問題の発生につながるおそれがあります。ただし、必ずそうなるというわけではありません。継承を使用すると、各ページでは基本ページ クラスからコントローラとビューの各コンポーネントを継承することができます。継承を使用すると、中央の 1 か所から変更を連続して行うことができ、比較的複雑で手の込んだコントラーラ パターンを実装しなくても、コードの複雑さを軽減することができます。ただし、大規模のアプリケーションを一から実装する場合は、必要に応じて独自の Front Controller の実装か、User Interface Process (UIP) の調査のいずれかを検討するのがよいでしょう。

Front Controller を ASP.NET に実装する

Page Controller に代わる方法の 1 つとして、独自の HttpHandler オブジェクトに基づいてアプリケーション レベルのコントローラを 1 つだけ作成する方法があります。HttpHandler は、ASP.NET ページが要求を受信する前にその要求をインターセプトします。するとコントローラは、Struts コントローラと同様のアクションが実行できます。同じような方法を使用すると、Intercepting Filter という形で前処理と後処理ができます。フィルタはコントローラとは異なり、入ってくる要求または出ていく応答を単に変更するだけです。

.NET の場合、Intercepting Filter と共に Front Controller を実装するのはごく簡単です (「frontcontrollerdemo.msi」を参照)。その実装の Controller 部分は、通常 Handler および Command Processor という 2 つの部分に分かれます。Handler オブジェクトは、Web サーバーから要求を受信し、それを処理し、Web.Config ファイルに書かれている各種 XML パラメータに従って、適切なコマンドを 1 つ選択します。Command Processor は、その要求を満たすのに必要な特定のコマンドをすべて実行します。処理が終了すると、各コマンドは適切なページが表示できるよう、何らかのメカニズムを通じて転送されます。

Front Controller および Intercepting Filter を ASP.NET に実装する詳細については、「Patterns & Practices」の Web サイトを参照してください。Microsoft の Patterns & Practices (P&P) グループでは、アーキテクチャとして安定したソリューションの設計、構築、導入、運用のための方法について指導と助言を行っています。P&P では、パターン、基準アーキテクチャ、ビルディング ブロック、ライフサイクルの実施について指導をしています。さらに P&P の Web サイトには、Front Controller および Intercepting Filter の両パターンを始めとして、この資料で説明しているすべてのパターンについて、総合的な解説を行い、実装に関する案内をしています。

• Front Controller pattern
• Implementing the Front Controller pattern in ASP.NET using HTTP Handler
• Intercepting Filter pattern
• Implementing Intercepting Filter in ASP.NET Using HTTP Module

Front Controller パターンを実装したものが、次のバージョンの ASP.NET に搭載されます (コード ネーム ASP.NET "Whidbey" は Microsoft Visual Studio® .NET の次のリリースにちなんだものです)。ただし、タイミングが問題である場合は、UIP アプリケーション ブロックの使用を検討するのがいいでしょう。

User Interface Process (UIP)

User Interface Process (UIP) は Front Controller パターンとよく似ています。Patterns & Practices の作成した UIP Application Block は、Page Controller パターンを拡張したものです。これにより、さらに堅牢なコントローラ メカニズムとなり、きわめて複雑なアプリケーションでも Front Controller を構築する必要がなくなります。

UIP は、ユーザー インターフェイスから制御フローと状態管理を取り出し、それを、基本的には構成駆動型の状態マシンである別の層に移します。UIP は、Windows、Web、PDA の各アプリケーションなど、いくつのユーザー インターフェイスからでも利用できるよう設計されています。これを使用すると、そうしたさまざまな種類のアプリケーション用として、フロントエンドの制御フローと状態管理とを行う汎用コードを書くことができます。その結果、複数のターゲット クライアントの間で簡単に切り替えられる汎用性の高いアプリケーションになります。UIP の重要な要素 (灰色) を次の図 2 に示します。

図 2. User Interface Process の重要な要素 (灰色)

UIP Application Block には、付属のコードについて学びやすいように、ソース コードすべて、スタータ キットのサンプル、総合的な資料が付いています。これは、Patterns & Practices の Web サイトからダウンロードできます。

今後の動向

Web は、適応性のある J2EE フレームワークおよび .NET フレームワークを試しつつ発展を続けています。Struts と ASP.NET にとって将来はどうなるのでしょうか。このセクションでは、J2EE および .NET の最前線に登場しつつあるテクノロジの一部を簡単に検討します。

Struts と J2EE の未来

Struts フレームワークは十分に発達したものであり、その主要なコンポーネントの多くが既にメインの J2EE フレームワークに吸収されました。今後 Struts が発展するとした場合、Tiles や JavaServer Faces など、新たな J2EE システムを利用する可能性があります。しかし、フレームワークそのものが大きく変化する可能性は低いでしょう。

Struts のプラグインと IDE の一体化

Struts フレームワークを拡張し、それを開発環境に一体化するためのさまざまな作業が現在進行しています。Struts フレームワークに使用されるイベント コードを自動生成するためのプラグイン (ベータ版) を現在いくつか利用できます。これらのプラグインを使用することで、Struts の開発者は生産性が大きく上がるはずです。また、いくつかの IDE ベンダでは、Struts フレームワークを開発環境に取り入れる IDE プラグインの開発が既に済んでいるか、あるいは現在開発中です。これらプラグインを利用すると、はるかに効率的な方法で、開発環境から直接 Struts を使用するための統合システムを効率よく実現できます。

Struts のエクステンションとプラグインのリストは Struts Applications (英語) の Web サイトにあります。

JSP と Tiles

Tiles を利用すると、比較的小さなフラグメントから簡単にページが組み立てられます。Tiles は、JavaServer Page (JSP) 仕様に定められている、いわゆるインクルード機能を土台に構築されているので、各種のコンポーネント パーツからプレゼンテーション ページを組み立てるための、堅牢かつ機能満載のフレームワークが実現されます。各パーツ (これを "タイル" と呼ぶ) は、アプリケーション全体を通じて何度でも好きなだけ再使用することができます。これにより、管理しなければならないマークアップの量が削減され、Web サイトのルック アンド フィールを容易に変更できます。

このフレームワークでは、そうした各タイルの整理に XML 構成ファイルが使用されます。このフレームワークでは、タイルの再使用ができるだけでなく、その各タイルを整理するレイアウトも再使用できます。

基本的に、タイルは ASP.NET のカスタム タグおよびコントロールとよく似ていますが、分離コードの中で操作できるという意味では、ASP.NET のタグの方が有力です。

Tiles の詳細については、以下のサイトにアクセスしてください。

• Javaworld - UI Design with Tiles and Struts (英語)
• Jakarta Struts - Tiles Guide (英語)

JavaServer Faces

JavaServer Faces (英語) テクノロジの目的は、JSP アプリケーションのユーザー インターフェイスの構築を簡略化することです。開発者は自分の技術レベルに左右されることなく、再使用可能な UI コンポーネントをページ内で組み立て、そのコンポーネントをアプリケーション データ ソースに接続し、クライアント側で生成されるイベントをサーバー側のイベント ハンドラに連結するという方法で、迅速かつ簡単にアプリケーションが構築できます。JavaServer Faces テクノロジを使用して構築されたアプリケーションでは、ユーザー インターフェイスの管理に関連したあらゆる複雑な処理がサーバー上で行えるため、アプリケーション開発者はアプリケーション コードの作業に集中することができます。

JavaServer Faces テクノロジには、次のものが含まれます。

• UI コンポーネントの表示とその状態の管理、イベントと入力妥当性検査の処理、ページ ナビゲーションの定義、国際化とアクセシビリティのサポートを行うための一連の API
• JSP ページの中に JavaServer Faces インターフェイスを示すための JavaServer Page (JSP) カスタム タグ ライブラリ

これは、ASP.NET の機能とほぼ同じです。

ASP.NET と .NET Framework の未来

Microsoft では .NET を強く推し進めています。これは同社の長期戦略の要の 1 つです。.NET Framework は、現在同社のオペレーティング システムに組み入れられており、Windows の次のバージョン (コード ネーム Longhorn) の一部としてリリースされます。また Microsoft は、現在同社の製品群を .NET に移行している最中であり、そのすべての製品の開発環境に Visual Studio .NET が利用されています。

ASP.NET は、.NET の主要なコンポーネントの 1 つです。Microsoft は次のリリースに向けて、以下に示した大幅な改良と新機能の実現に取り組んでいます。

• メンバシップと役割管理の各サービスのためのビルトイン サポート
• ユーザーの好みに応じた設定や、その設定値を検索するための新しいパーソナライズ サービス
• 新しいサイト ナビゲーション システム
• 45 を超える新しいサーバー コントロール
• モバイル デバイスに対する自動レンダリング
• グラフィカルな手法による、構成ファイルの編集
• 簡略化されたアプリケーション管理

さらに Microsoft では、 MVC 実装を変更して Front Controller パターンを組み込むことも計画しています。ASP.NET の次のバージョン (コード ネーム Whidbey) に関する詳細については、ASP.NET (英語) の Web ページにアクセスしてください。

サードパーティでの開発

現在相当数のサードパーティ各社で、.NET の機能を拡張するためのツールが開発されています。中でも Avanade の製品の ACA .NET は優れています。これは、開発行程を短縮できるよう調整を図ったフレームワークと一連の設定済み Web サービス/アプリケーション コンポーネントの両方を提供することにより、Visual Studio .NET の補完的役割を果たす製品です。

Struts と J2EE のアプリケーションを ASP.NET に移行する

Struts ベースのアプリケーションを C# や ASP.NET に移行する場合は、Java Language Conversion Assistant (JLCA) と「JSP to ASP.NET Migration Guide 」に掲載されている資料を利用できます。MSDN(R) ライブラリにあるこのガイドには、Struts ベースの Web サイトを C# や ASP.NET の Web サイトに移行するための手順が網羅されています。Front Controller (XML ルックアップと CommandFactory が付属) の sample code (英語) が見つかるだけでなく、JLCA によって Struts の既存のアクションをほぼ直接変換できることがわかるでしょう。

Struts アプリケーションを .NET に変換する際、特に問題なのは Controller の機能を置き換える作業です。前述したように、ASP.NET には、ActionServlet の原理に直接相当するものがありません。そのため、Struts の各クラスを 1 対 1 で変換するには、Front Controller パターンを活用し、Struts ActionServlet の機能を実行する HttpHandler を記述する必要があります。このコンポーネントを開発すれば (または、「JSP to ASP.NET Migration Guide」からダウンロードすれば)、JLCA を使用して残りの Action クラスをそれぞれに相当する C# クラスに直接移行できます。プロセス全体は実に単純であり、同移行ガイドに詳しく解説されています。変換を終えると、ASP.NET の環境の中に Struts のようなアプリケーションができあがります。ただし、Java を中心としたソリューションは依然 ASP.NET の中で作動しているのです。移行作業の次の段階は、ASP.NET の機能とベスト プラクティスの活用に取りかかることです。たとえば、Struts の妥当性検査コードを ASP.NET の妥当性検査コントロールに置換するなどの作業を行うのがよいでしょう。また、ASP.NET コントロール (DataGrid など) と .NET Framework の機能を利用するため、特定のアクションとビューを書き直す必要があるかもしれません。

まとめと結論

Web アプリケーションが成熟するにつれ、完全に一体化された堅牢な開発システムがますます求められています。J2EE と .NET Framework は、どちらもそのようなシステムを実現します。どちらのフレークワークも、オペレーティング システムを底辺にして、ランタイム、言語、API という各層の重なったスタックの上に構築されます。どちらのフレームワークにも、アプリケーションの開発に利用できるさまざまな機能と利点があります。これまで述べてきたように、こうしたスタックに各種のパターンを追加すれば、質の高いアプリケーションの実現性が一段と高まります。

.NET Framework スタックには、それに相当する J2EE スタックと比較して、際立った長所がいくつかあります。.NET は、Windows オペレーティング システムに完全に一体化されており、また同 OS にはアプリケーション サーバーがあるため、.NET アプリケーションは統合の度合い、機能コンテンツの豊富さ、および処理速度において、ほとんどの J2EE システムに比べてはるかに勝っています。開発レベルで ASP.NET を使用すれば、JSP と比較して少ないコードで済みます。さらに、ASP.NET には妥当性検査、キャッシング、トレーシングなど多くの機能が組み込まれていますが、JSP にはサードパーティ製のコンポーネントが必要です。

長期的に見れば、ASP.NET、.NET Framework、User Interface Process は、Web アプリケーションの開発、展開、サポートが行える強力で完全なフレームワークを実現できます。Microsoft では、Web 開発に関連する作業の改善を推進しているので、ASP.NET および .NET Framework は、短期的にも長期的にも、企業レベルでの開発に対するニーズを満たし続けることでしょう。

参考資料

このホワイト ペーパーは、多くのさまざまな情報源から情報を得て作成されました。主な参考資料のうち、いくつかをここに列挙します。

ASP.NET ライフサイクル

• ASP.NET でのパイプライン処理の詳細については、MSDN Magazine の記事「Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET (英語)」を参照してください。

Framework の類似点

• ASP.NET の状態管理

Java アプリケーション

• CodeNotes for J2EE ? Random House Publishing Inc., 2001, New York, New York
• CodeNotes for Java ? Random House Publishing Inc., 2001, New York, New York

ASP.NET 妥当性検査コントロール : Web フォームにおける検証

Struts

• Struts のホームページ (英語)
• Mastering Jakarta Struts ? James Goodwill.Wiley Publishing Inc., 2002, Indianapolis, Indiana

Microsoft のパターンとプラクティス

• FrontController のサンプル コードは、ASP.NET の Sample Code (英語) のページにあります。
• JSP to ASP.NET Migration Guide

User Interface Process

• Microsoft Application Blocks for .NET (英語)
• .NET Rocks ? 2003 年 4 月 28 日 Microsoft Consulting Services (MCS) のシニア コンサルタント Michael Stuart 氏へのインタビュー (英語) : Microsoft の次世代型アプリケーション Blocks、BlueBricks について

執筆者紹介

M. Keith Mortensen 氏は、Infusion Development のシニア ソフトウェア開発者兼コンサルタントです。Rob McGovern 氏は、Infusion Development の シニア プロジェクト マネージャであり、『CodeNotes for Java』、『CodeNotes for J2EE』、『CodeNotes for ASP.NET』、『CodeNotes for J#』、『CodeNotes for Web Services』、『CodeNotes for Oracle 9i』の著者です。Charles Liptaak 氏は、Microsoft の Platform Strategy and Partner Group のパートナー ソリューション アーキテクトです。

Brian Goldfarb、Steve Ellis、Brent Williams、Greg Brill、Cortez La Palme、Dale Baik の各氏から頂いたご支援に対し、執筆者一同感謝の意を表します。

補足

フォーム認証の拡張

フォーム認証を実行するのは FormsAuthenticationModule であり、これは、入ってきた要求が HttpHandler に渡される前にその要求をインターセプトする働きをします (ASP.NET のモジュールとハンドラの詳細については、「ASP.NET の MVC 実装」のセクションを参照してください)。

認証モジュールが OnAuthentication イベントを起こすと、開発者はデータベースなど何らかの ID ストアを相手に認証を実行した後に、認証チケットが作成できます。それに続く要求によって、同じイベント ハンドラの中でこのチケットの妥当性が検査され、チケットが失効している場合には、その要求はログイン ページにリダイレクトされます。ASP.NET は、要求のヘッダーに埋め込まれて発行されるクッキーを利用して、ユーザー ID の再取得と、複数の要求にまたがる認証チケットの作成を行います。

ロールベースのセキュリティ

URL 認可機能におけるユーザーとロールは Identity と Principal の各オブジェクトに対応付けられ、そのオブジェクトは認証のときにランタイムによりその時点でのスレッドにアタッチされます。Windows 認証の場合、これらオブジェクトは Windows のユーザーとグループに直接対応付けられます。

URL 認可機能で実現する、ロールベースのセキュリティの他にも、ASP.NET はカスタムメイドのロールベースのセキュリティに対応しています。ロールベースのセキュリティでは、適切なロールを持った独自の "Principal" オブジェクトを作成し、スレッドの既定のオブジェクトを独自のオブジェクトに置き換えることができます。この種のセキュリティは、通常データ ストアからカスタム ロールを取り出した後に OnAuthentication イベントの中で使用します。

Model View Controller (MVC) パターン

MVC パターンとは、基本的にアプリケーションのユーザー エクスペリエンスを Model、View、Controller という 3 つのコンポーネントに分類する方法のことです。多くの場合、これらの用語は開発の世界では実にさまざまな意味を持ちます。明確にするため、MVC フレームワークについて言及する場合は次のようにアプリケーションがどのようにセグメントされるかを表す用語とします。

• Model は、ビジネス ロジックへと通ずる出入口のことであり、機能性という視点からユーザー エクスペリエンスを管理する働きをします。
• View は、プレゼンテーション層のことであり、利用可能なアクション、およびそのアクションを使用するのに必要な情報をユーザーに提供します。
• Controller は、Model と View をつなぐブリッジのことであり、ユーザーからの要求を読み取り、適宜 Model や View に変更命令を下す働きをします。

図 3 に、一般的なデータ フローを示します。

図 3. Web コンテキストでの Model View Controller (MVC) パターン

ページ要求などのイベントが発生すると、MVC パラダイムでは次のように処理されます。

1. 発生したイベントを Controller がインターセプトします。
2. Controller は、そのイベントを調べて Model 内の適切なハンドラに対応付けます。
3. Model はアクションまたは状態変更を行い、その結果が Controller に返されます。
4. Controller は、表示する適切な View を決定し、アプリケーションから View へ転送させます。
5. View は、ロード中、データ インターフェイスを通じて Model からデータを取り出せますが、データベース コールなどのアクションは直接実行できません。
6. View がユーザーに表示されます。

MVC パターンで作成された各コンポーネントを別々に分けると、それぞれのコンポーネントが論理的にグループ化された一連のタスクごとにその処理を受け持つことになり、UI の依存関係を解消するのに役立ちます。

Struts の MVC 実装

Struts プロジェクトの目的は、MVC パターンを J2EE プラットフォームに持ち込んで、拡張可能なアプリケーションを構築するための柔軟なフレームワークを開発者に提供することでした。開発の 1 年後、MVC に足りない部分を補うために J2EE の世界に Struts が登場しました。Struts のアーキテクチャは Java アプリケーションのラッパーとして機能し、そのコードを MVC パターンに定義されている Model、View、Controller に分割します。

MVC 分析

Struts では、ただ 1 つのコントローラですべてのアプリケーション イベントが管理できるよう実装されています。出入りするこれらのイベントは、入ってきたデータを特定の用途に合わせて変更、作成するフィルタでインターセプトすることができます。これは、MVC パターンの Intercepting Filter バリエーションを利用した Front Controller によく似ています。

Model

Model にはほとんど制約がなく、サードパーティ製のさまざまな実装に対応できます。最も一般的な実装の 1 つでは、データの永続性、トランザクションのサポート、標準的なフレームワークを実現するため、Enterprise JavaBean (EJB) を活用しています。他の Model 実装には、Data Access Object (DAO) や Plain Old Java Object (POJO) などの他に、Object Relational Mapping (ORM) ツールなど、他の形式をした、ロジックのカプセル化やデータの永続性 が含まれています。これら Model 実装はすべて、Java で開発するか、Java ベースのインターフェイスを持つ必要があります。

View

View コンポーネントは通常、JavaServer Pages (JSP) として実装されます。JSP は、本質的には、HTML やサーブレットに適用するマークアップ言語のことです。JSP マークアップ言語はカスタム タグ ライブラリの開発に対応しています。カスタム タグ ライブラリは、JSP の中で使用するときには、バックエンド クラスにアクセスして特定の関数を実行する HTML のようなタグに相当します。カスタム タグ ライブラリを Struts で使用する目的は、JSP を拡張し、View と Model がシームレスに対話できるようにすることです。

Controller

既定のコントローラは、1 つのサーブレット インスタンスに一元化され、そのインスタンスがクライアント要求をすべて処理し、要求ごとに適切なアクションを実行します。Struts フレームワークから Controller に既定の実装が提供されます。開発者の主な作業は、イベントが発生した結果として起きるアクションを登録し、実装することです。アクションは、拡張する必要のある共通基本クラスの 1 つとして定義され、すべてのイベントと応答は、1 個の XML 構成ファイルに登録されます。たとえばアクション マッピングは、要求の着信 URI が適切な Action クラスに正しく対応付けられるよう入力する必要があり、Action クラスは、入ってきた要求が処理されるよう実装する必要があります。また、アクションの転送条件については、アクションの完了時にどの View が必要なのかが Controller に把握されるように登録する必要があります。

Struts におけるページ読み込み処理の順序

典型的な要求は、次のように複数段の工程を経ます。

図 4. Struts におけるページ処理の順序

1. サーバーごとに物理インスタンスを 1 個持っている Action Servlet クラスが、ブラウザ要求を発行して処理します。
2. Action Servlet が Request Processor をコールして、要求/応答オブジェクトの作成やアクション マッピングなどを行います。
3. Request Processor が、対応する Action Form ビーンを作成 (再使用) し、そこに HTML フォームに基づいて入力フィールドを設け、必要に応じてフォームの妥当性検査を行います。
4. その構成ファイルの中でアクション マッピングを使用することにより、Request Processor が適切な Action クラスに制御権を渡します。Struts フレームワークは Action クラスのインスタンスをプールします。そのため、既に要求済みのアクションは、要求 ごとに作成されるのではなく、インスタンス プールから取り出されます。ただしマルチスレッドの機能がないと、複数のユーザーが同じアクションにアクセスしている最中は、かなりの衝突が起きる可能性があります。
5. Action クラスがビジネス ロジック ビーンを起動し、Action Form (またはその一部) をモデルに渡します。このモデルは、EJB ベースでも、普通の Java オブジェクトで構成されるものでも、どちらでもかまいません。
6. アクションは実行後、要求のターゲットを決定する Action Forward オブジェクトとして戻ってきます。
7. 最後に制御権が Request Processor に戻り、要求が適切なターゲットに転送されます。
8. JSP ページは、一連のタグ ライブラリを利用して Model からデータを得ることができます。

このプロセスは一見複雑に思えるかもしれませんが、その処理のほとんどは、Struts フレームワークのおかげで自動的に実行されます。開発者としての主な作業は、マッピングの設定と Action クラスの作成です。

ASP.NET の MVC 実装

生産性を上げるため、また信頼性が高くてスケーラブルなソリューションの開発を支援するため、ASP.NET には、特に設定をしなくてもそのままで使用できる、既定の MVC フレームワークが用意されています。ASP.NET の MVC 実装は、ページごとにコントローラを 1 個持っていることから Page Controller パターンと呼ばれています。

ASP.NET におけるこの Page Controller パターンは、イベントを捕らえてそれをクライアントから適切なハンドラに転送する処理が、開発者に意識されずに自動で実行されるような形で実装されています。開発者は、複雑なハンドラを開発する代わりに、イベントの処理に必要なアクションの実装のみを考えることができます。

MVC 分析

各 ASP.NET ページは、さまざまなコントロールを含む View と、Controller として機能する分離コードの 2 つに分類されます。分離コードには、イベントの生成時に Controller が起こせるすべてのアクションに対応した関数が含まれています。これらの関数は、必要に応じて、Model と生成される View に関連させることができます。

Model

Model は単純なオブジェクト (C# クラスなど) または管理コンポーネント (Enterprise Services や COM+ など) で構成することができます。さらに、このフレームワークからは、トランザクションのサポート (ADO.NET と COM+)、データの永続性 (ADO.NET)、キャッシングなども含め、さまざまなサービスとシステムにネイティブ アクセスすることができます。ASP.NET Model は、C#、VB.NET、J#、Perl をはじめとして、.NET Framework が対応している多くの言語のどれを使用しても実装できるという点で、Struts Model とは異なります。

View

.NET Framework ベースのアプリケーションにおける View は、ASP.NET と .NET 対応の言語のいずれかを利用して実装されています。ASP.NET では、スクリプトの代わりにコンパイル済み言語に対するサポートを提供し、ブラウザごとに出力を自動生成するという方法で ASP を拡張しています。ASP.NET は、Controller と View がシームレスに対話できるよう、多彩でカスタマイズ可能なコントロール ライブラリを備えています。ASP.NET は、JSP と比較して、ドラッグ アンド ドロップ式の開発インターフェイス (Visual Studio .NET または Web Matrix) や、改良されたコントロール、ブラウザに依存した HTML の自動生成など、優れた点がいくつかあります。すなわち、ASP.NET におけるコントロールは、自動的にブラウザの種類を突きとめ、そのブラウザ固有のコードを生成するのです。J2EE には同じような機能はありませんが、Java ベンダの一部では同様の機能を持つタグ ライブラリが既に開発されています。

Controller

Page Controller の手法は、実装を行う開発者から見れば Struts よりはるかに単純です。その理由は、コントローラがページに直接組み込まれるからです。開発者は、アプリケーション全体に関連するすべてのイベントをマッピングするのではなく、1 枚のページに関連するすべてのイベントを処理するだけで済みます。これにより、View と Controller は継承が利用できるため、非常に強力な実装にすることが可能です。ただし、この実装の設計が不適切な場合は、アプリケーションがきわめて複雑になって管理が非常に困難になるおそれがあり、前述した構成関連の問題が再び発生する可能性があります。予防策については「Page Controller の一元化」のセクションで説明し、代替方法については「Front Controller」、「User Interface Process」の各セクションで説明します。

ASP.NET ページの処理 : 内部の動き

ASP.NET ページの処理の大半は開発者には見えませんが、たとえばセキュリティなど使用する必要のある場合はモジュラ方式で利用できます。このセクションでは、ASP.NET ページの処理される際に裏で実行されるアクションについて説明します。

図 5. ASP.NET におけるページ処理の順序

IIS は要求を受信すると、それを aspnet_wp.exe という ASP.NET ワーカー プロセスに転送します。現在、ワーカー プロセスはコンピュータ 1 台につき 1 個しかありませんが、これは ASP.NET バージョン 2.0 では変更される予定です。同じコンピュータ上で複数のワーカー プロセスが実行できるようになり、その結果、同じ物理ハードウェア上で稼動している Web サイトを完全に区別して扱えるようになります。

ワーカー プロセスは要求を受信すると、HttpRuntime のインスタンスを使用してその要求を処理します。HttpRuntime は、入ってきた要求を調べて、その要求がどのアプリケーションに対するものなのかを判断し、オブジェクト ファクトリを使用して HttpApplication のインスタンスを作成します。HttpApplication には、入ってきた要求を検査して認証や状態管理などよくあるタスクを実行する HttpModules のコレクションが含まれています。HttpModules がそのタスクを実行し終えると、HttpApplication は別のオブジェクト ファクトリを使用して HttpHandler のインスタンスを作成します。パフォーマンスを上げるため、HttpApplication オブジェクトと HttpHandler オブジェクトがプールされます。

ここが、実際の ASP.NET ページの出番です。特に指定しない限り、すべてのページが、IHttpHandler インターフェイスを実装している System.Web.UI.Page クラスを拡張します。そのページが読み込みを開始すると、さまざまなイベントが開始され、分離コードが実行を始めます。そうなれば、分離コードからビジネス ファサード層、またはビジネス ロジック層をコールしてアドレスの変更や新しい連絡先氏名の追加など、さまざまなビジネス ファンクションが実行できます。