連載 ASP→ASP.NET移行テクニック 第1回　ASP.NET移行へのプロローグ 山田　祥寛 2004/04/21

Page1 Page2 Page3

　

≪今回の内容≫ 　・移行の3つのアプローチ 　・＜統合＞移行パターンの類型化 　・どの移行方式を選択するべきか？ 　・構造上の変更点

　いまさら声を大にしていうまでもなく、ASP.NETは大変優れたアーキテクチャだ。かつてWindowsサーバにおける標準的なサーバ・サイド技術であった旧来のASP（以降、「レガシーASP」と呼ぶ）もまた優れた技術であったが、末期にはさまざまな問題点が指摘されていた。ASP.NETは、レガシーASPで指摘されていた問題点に対するMicrosoft社の解答であり、次世代アーキテクチャへの試みであるといえる。

　開発生産性、パフォーマンス、スケーラビリティ、セキュリティなどなど……、ASP.NETがもたらす効果については、すでに多くの記事が解説しているので、ここでは繰り返さない。詳細については、別稿「プログラミングASP.NET」や「ASP.NETで学ぶVisual Studio .NETの魅力」などを参照していただきたい。

　これらの解説記事をご覧いただければお分かりになるように、新しいASP.NETにはレガシーASPから移行するだけの十分なメリットがある。では、すべての既存資産を無条件にASP.NETで置き換えるべきなのか？ それが可能であれば話は非常に簡単で、そのような幸福な方々は本稿をこれ以上読み進める必要はない。

　しかし、そのような恵まれた環境は恐らく希少であるし、多くの現場では膨大な過去の資産と付き合い続けなければならないだろう。

　というのも、ASP.NETはもはやASP 3.0の後継バージョンではないからだ。後述するように、限りなく互換性を意識した仕組みがASP.NETには用意されているが、それでもただ単に拡張子を「.asp」から「.aspx」に置き換えれば、それで即座に移行できるというものではない。つまり、移行に当たっては、（多かれ少なかれ）開発者の貴重な時間を犠牲にしなければならないということだ。である以上、無条件にASP.NETへの移行（または置き換え）を推進すればよいというものではないし、移行することによる「効果」と移行にかかる「工数・コスト」とをあらかじめ慎重に判断しなければならない。

移行の3つのアプローチ

　「移行（Migration）」と一口にいっても、その形態は一通りではない。移行の技術的な留意点について論じるに先立って、まずはどのような移行の形態があり得るのかを概観しておく必要があるだろう。

○パターン1：レガシーASPアプリケーションとASP.NETアプリケーションの＜共存＞

　ここでいう＜共存＞とは、レガシーASPアプリケーションはそのままに、新しいアプリケーション開発から順にASP.NETを導入していくパターンをいう。

　まず大前提の知識として、レガシーASPとASP.NETは＜共存＞可能だ。拡張子「.asp」と「.aspx」ファイルは同一のサーバ上、同一の仮想ディレクトリ上に配置することができる。つまり、読者諸兄が現存のレガシーASPアプリケーションに何の不満も覚えていない、追加的な要望・機能要件もないというならば、あえて「いま正常に動いている」アプリケーションを、コストや工数をかけてまでASP.NETアプリケーションに置き換える必要はない。レガシー・アプリケーションはそのままに、新しいアプリケーションから順次ASP.NETを導入していけばよい。

問題のないシステムを無理して直す必要はない。

　これはシステム運用における絶対の鉄則だ。

○パターン2：レガシーASPアプリケーションとASP.NETアプリケーションの＜統合＞

　ここでいう＜統合＞とは、レガシーASPアプリケーションの一部のコードをASP.NETに置き換える、あるいは追加機能をASP.NETで開発し、ASP⇔ASP.NET間のインターフェイスだけを開発することをいう。いわばレガシーASPとASP.NETとが相互に連携し合う「部分移行、または相互運用（Inter-Operability）」ともいうべきパターンだ。

　＜統合＞は、少ない時間と人員の中で効果的な移行を行うのに適したアプローチであるといえる。旧来のアプリケーションをすべてASP.NETで置き換えるのは難しいにせよ、パフォーマンス上のボトルネックとなっている個所にポイントを絞って改善できるので、コスト・パフォーマンスにも優れている。恐らく移行に当たって、最も現実的な解が、この＜統合＞パターンだろう。以降、本稿で単純に「移行」といった場合には、基本的に＜統合＞パターンを指すものとする。

　しかし、＜統合＞パターンには、いくつかの問題点もある。

（1）アプリケーション・セッション変数は共有できない

　上でASP／ASP.NETは共存可能であると述べたが、残念ながら、完全な共存関係を保証しているわけではない。というのもASP／ASP.NETは、見掛け上の同居を許してはいるが、基本的には完全に独立したプロセスで動作する「別個のアーキテクチャ」だからである。つまり、それぞれのプロセスで管理されているアプリケーション・セッション変数もまったく別個に保持されており、互いを参照することはできない。

　もしもASP／ASP.NET間で共通の情報を管理したいならば、サーバ上のデータ・ストア（例えば、データベース・サーバ）を利用するか、クライアント依存の仕組みであるクッキーを介する必要がある。

ASPとASP.NETは独立したプロセスで動作する

（2）境界越えのオーバーヘッドが大きい

　ASP.NETアプリケーションは、.NET Frameworkの実行環境であるCLR（Common Language Runtime）上で管理されて動作するマネージ・コードであるのに対して、レガシーASPアプリケーションはCLRによって管理されないアンマネージ・コードだ。マネージ・コードとアンマネージ・コードとは多くの点で相違点がある。

	マネージ・コード	アンマネージ・コード
プログラミング・モデル	オブジェクト・ベース	インターフェイス・ベース
型の識別	厳密名	GUID（Globally Unique IDentifier）
型の互換	CTS（Common Type System：共通データ型）	バイナリ・ベース
型の定義	メタデータ	タイプ・ライブラリ
エラー処理	例外機構	HRESULT
バージョニング管理	可能	不可
オブジェクト管理	ガベージ・コレクタ	リファレンス・カウンタ
マネージ・コードとアンマネージ・コードの相違点

　この相違のために、ASP.NETからASPにアクセスするに当たっては（また逆に、ASPからASP.NETにアクセスするに当たっては）、両者の「境界」を越えるためのオーバーヘッドが発生する。本件に関する解決策は、連載第3回であらためて詳説することにしたい。

境界越えは大きなオーバーヘッド

○パターン3：ASP.NETアプリケーションへの完全な＜置換＞

　ここでいう＜置換＞とは基本的には、レガシー資産を完全に破棄し、1からコードを起こし直すことをいう。

　システム的には最も理想的なパターンだ。1からコードを書き直すならば、レガシー資産とのしがらみに惑わされることもないし、そこにかかる工数を度外視するならば、開発者にとっても恐らく最も幸せなパターンでもある。ASP／ASP.NETが混在することによる運用コストやレガシーASPの将来性をかんがみても、中長期的には完全な＜置換＞を行うのが望ましいだろう。

　しかし、先述したように、コスト・パフォーマンスを考えれば、必ずしもすべてのケースに適用できるものではない。少なくとも当面のところでは、＜置換＞を適用できるケースはごく限定的な局面にならざるを得ないだろう。

INDEX
	ASP→ASP.NET移行テクニック
	第1回　ASP.NET移行へのプロローグ
	1．移行の3つのアプローチ
	2．＜統合＞移行パターンの類型化
	3．構造上の変更点

　

「ASP→ASP.NET移行テクニック」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）