システム管理者のための.NET入門 第1回 なぜ.NETが必要なのか？ 2．これからの情報システムに何が必要なのか？（1） デジタルアドバンテージ　小川 誉久 2006/11/17

　ここからは、環境変化に対応するために、情報システムに何が必要なのか、それに対して.NETが何をどうサポートをしてくれるのかをもう少し具体的に見ていくことにしよう。ただし以下の説明では、ソフトウェア開発者向けの話題が多いことをお断りしておく。ミクロ的にはソフトウェア開発者にしか関係のないことでも、マクロ的に見たライフサイクル全体では、システム管理者にも関係するものだという観点でお付き合いを願いたい。

コード再利用性の向上：OOPと高度なクラス・ライブラリ

　変化に柔軟に対応可能なアプリケーション開発で非常に重要となるのは、コードの再利用性を高めることだ。環境が変化するといっても、すべてがガラリと変わるわけではない。コアとなる基本部分は大して変わらないものだ。それにもかかわらず、ユーザー要求が変わるたびにいつもゼロからアプリケーションを開発していたのでは、とても短期開発などおぼつかない。すでにあるプログラム・コードのうち、使えるものはできるだけ再利用しながら、必要な部分だけの改修で済ますことが、ソフトウェアの開発生産性向上のカギになる。

　共通コードのサブルーチン化やライブラリ化など、コードの再利用性を高めるための工夫は古くからある。しかし昨今主流となっているのは、そういったライブラリ化（コンポーネント化）がより促進しやすいオブジェクト指向プログラミング（OOP：Object Oriented Programming）の導入と、OOPを全面的に導入することにより構築可能となったクラス・ライブラリだ。

　.NETアプリケーション開発で利用可能な言語処理系は、すべてOOP対応である。具体的には、Java言語を意識しながら.NET向けに最適化し新開発したというC#（シー・シャープ）や、C++、Visual Basicなどがある。またサードパーティ製品を含めれば、COBOLやFORTRANなどを利用して.NET対応アプリケーションを開発することもできる。

　.NET以前からマイクロソフトは、C++言語向けのWindowsアプリケーション用クラス・ライブラリとしてMFC（Microsoft Foundation Class）などを提供していた。それらがサポートしていた低レベル・サービスをさらに洗練するとともに、ビジネス・アプリケーションを意識した、より高度なアプリケーション・フレームワークをも包含した最新クラス・ライブラリ、これが.NET Frameworkのクラス・ライブラリである。

　.NET Frameworkクラス・ライブラリでは、データ・アクセスやネットワーク・アクセスなどの低レベルなサービスばかりでなく、Webアプリケーション開発では必須の、煩雑なHTML制御を抽象化して扱えるようにする機能（ASP.NET）や、入力データの検証を支援する機能、データベース内のデータとWebページ表示を関連付けることで、DBアプリケーション開発を大幅に効率化するデータバインド機能（ADO.NET）など、Java環境などでは別途サードパーティ製のフレームワークが必要な高度な領域までをも標準でカバーしている（CLRについては後述）。

.NET Frameworkの基本構成

実行エンジンであるCLRの上位に、低レベルな機能を提供する.NETクラス・ライブラリが存在する。さらにこの上位には、ビジネス・アプリケーションを想定した、高度なアプリケーション・フレームワーク（ASP.NET、ADO.NETなど）が標準で提供されている。

　フレームワークで実行できる処理が増えれば、必然的にアプリケーション側で実行しなければならない処理は減るので、開発生産性が向上するとともに、結果として、フレームワーク部分を積極的に再利用することにつながり、アプリケーション全体でのコードの再利用性も高まることになる。

コード再利用性の向上：Webサービス対応によるSOAサポート

　いま述べたコードの再利用性は、単一のアプリケーション・レベルの話だったが、さらに情報システムをマクロ的に見れば、すでに開発され稼働している独立したアプリケーションを、そのまま活用するというアイデアもある。このようなモデルはSOA（Service Oriented Architecture）として知られる。

　SOAとは、ソフトウェアから呼び出し可能な、標準化されたインターフェイスを備えたサービス群により、情報システム全体を構成するモデルである。例えば、受注システムと顧客管理システムがすでにあったとして、これらがソフトウェアから呼び出し可能な標準的なインターフェイスを備えていれば、新しい用途のシステムを開発する際でも、受注や顧客管理といった共通性の高い処理部分で、これらのアプリケーションの機能を活用できるというものだ。つまりSOAでは、アプリケーション全体を1つのサービスとして再利用してしまうわけだ。

　この際の「標準化されたインターフェイス」として、ほぼ業界標準の位置を獲得したのがWebサービスである。Webサービスは、トランスポート・プロトコルとしてWebなどで普及したHTTPを利用可能なSOAP（Simple Object Access Protocol）を使い、XMLベースのメッセージをやりとりすることで、アプリケーション間通信を可能にする。Webサービス以前にも、CORBA（Common Object Request Broker Architecture：コルバ）やDCOM（Distributed COM）などがアプリケーション連携のためのインターフェイスとして考案されたが、広く普及するには至らなかった。

　これに対しWebサービスは、Windowsアプリケーションばかりでなく、UNIX−Javaアプリケーションでもすでに標準的なアプリケーション連携プロトコルとなっており、プラットフォームに依存しない標準プロトコルとして不動の地位を築いている。

　.NETの中心的な技術の1つがこのWebサービスである。.NET対応アプリケーションは、.NET Frameworkが提供する高度なWebサービス・サポートを利用して、容易にWebサービス・インターフェイスを備えたり、外部にあるWebサービスを呼び出したりできる。これにより.NETでは、異機種間接続が可能な相互運用性の高いアプリケーションを容易に開発できるようになっている。

目的や用途によらない単一のアプリケーション・インターフェイス

　Windows OSには、Windows API（Application Programming Interface）と呼ばれる関数呼び出し形式によるアプリケーション・インターフェイスが用意されている。APIに必要なパラメータを指定して呼び出せば、OSが提供する機能をアプリケーションで使うことができる。

　基本的にAPIは、機能に対応して用意する必要がある。従ってOSに新しい機能が追加されたときには、それを使うためのAPIも追加しなければならない。事実、Windows発展の歴史は、API拡張の歴史であったといってもよい。一説によれば、いまやWindows APIの数は、1万5000を超えるという。もはや階層構造を持たないフラットなAPIを的確に使いこなしながら、アプリケーションを開発することは不可能である。今後もWindowsの機能向上が続くことを考えれば、Windows APIに代わるアプリケーション・インターフェイスが必要であることは明かだ。

　オブジェクト指向プログラミング・モデルとMFCクラス・ライブラリの導入には、掌握困難になったAPI群を階層的に整理し、よりシンプルに扱えるようにするという目的もあった。その後もマイクロソフトは、コンポーネント技術のCOM（Component Object Model）やDCOM（分散COM）、ATL（Active Template Library）など、必要に応じてさまざまなアプリケーション・インターフェイスやクラス・ライブラリを開発してきた。当時のプログラマーは、用途に応じてAPIやクラス・ライブラリを使い分けたり、異なるコンセプトに基づいて設計された複数のクラス・ライブラリを使いこなしたりしなければならなかったわけだ。

　これに対し.NET Frameworkでは、これら複数のアプリケーション・インターフェイスの機能をすべてカバーするワンセットのクラス・ライブラリが提供される。目的ごとに異なるインターフェイスやクラス・ライブラリを使い分ける必要はない。統合的な単一インターフェイスに従ってアプリケーションを開発しておけば、たとえ今後システムの複雑化が進んだとしても、.NET Frameworkの将来バージョンがその違いを可能なかぎり吸収してくれるだろう。少なくとも、乱立した複数のインターフェイスに依存したアプリケーションを開発することに比べれば、リスクは数段小さくなるはずだ。システム側から見れば、過去のアプリケーションとの互換性維持に足を取られることなく、時代の要請に応じたシステム拡張が行いやすい環境ともいえる。

特定言語に依存しないアプリケーション・インターフェイス

　前出のMFCを利用できるのは基本的にC++言語だけであり、かつてのVisual Basic（Visual Basic Ver.6.0、以下Visual Basic 6.0）には独自のアプリケーション・インターフェイスが提供されていた。つまり当時のプログラマーは、用途や目的ばかりでなく、使用する言語によっても、異なるアプリケーション・インターフェイスを使い分ける必要があった。

　逆にいえば、目的ごとに、効率的な開発が可能なプログラミング言語がある程度決まっていた。すなわち、異なるタイプのアプリケーションを開発するには、新しい言語の学習を余儀なくされることもあったわけだ。

　これに対し.NET Frameworkは、言語によらず共通して利用可能なクラス・ライブラリを提供する。.NET Framework上では、基本的にあらゆる言語は対等である（厳密には、特定言語でのみ可能な機能も一部にあるが、過去との互換性維持などを目的とするごく一部分である）。必要ならば、異なる言語を組み合わせて、1つのアプリケーションを開発することも可能だ。.NET環境では、プログラマーが持つ言語スキルを最大限生かしたアプリケーション開発が可能である。

　.NETプラットフォームにおいて、これを可能にしているのが、CLR（Common Language Runtime：共通言語ランタイム）とよばれるメカニズムである。

言語を選ばない.NETアプリケーション環境

どの言語で開発されたソース・コードも、コンパイラによって言語に依存しない中間言語（IL）に変換される。CLRは、ILをネイティブ・コード（x86やItaniumなど、特定のCPUごとのバイナリ命令コード）に変換してから実行する。

　例えばVisual Basic 2005で開発されたソース・コードは、Visual Basic 2005コンパイラによってコンパイルされるのだが、この際でも特定のマイクロプロセッサに依存したバイナリ・コードではなく、IL（Intermediate Language）と呼ばれる中間言語に変換される。こうして生成されるILコードは、言語コンパイラの種類によらず共通なので、ソース・コードがどの言語で作られたものであっても、ILレベルでは違いはない。言語によらないアプリケーション開発が可能なのはこのためだ。

　コンパイルされたILコードは、CLRが備えるJITコンパイラ（Just-in-time compiler）によってネイティブ・コードに変換され、実行される。このようにCLRでの実行を前提とするコードはマネージ・コード（manage code）と呼ばれる（CLRによって管理されることからこう呼ばれている。これに対比させる意味で、CLRを前提としない従来型のWindowsプログラムはアンマネージ・コードと呼ばれる）。

CLRによるマネージ・コードの実行

マネージ・コードを実行すると、CLR内のクラス・ローダが.NETクラスをロードし、JITコンパイラによってILコードをネイティブ・コードに変換する。以後はCLRの実行サポートの管理下でプログラムが実行される。

　ランタイム環境により、下位プラットフォームの違いを吸収するという点で、.NETのCLRとJavaプラットフォームのJVM（Java VM：Java仮想マシン）は概念的には似たところもある。ただしJVMは実質的にJava言語のみが対象であるのに対し、CLRでは、複数言語がサポートされる点が異なる。またCLRでは、ILは必ずコンパイルされて実行される。JVMのように、インタープリタ方式で逐次中間コードを解釈しながら実行されることはない。

　CLRの実行サポートには、面倒なメモリ管理処理をシステム任せにできるようにするガーベジコレクタや、CAS（Code Access Security）と呼ばれるセキュリティ制御機構が組み込まれている。CASは、通常のロールベースのセキュリティ（ログオンしているユーザーの権限で実行を制限する機能）に加え、コードのダウンロード元や署名情報などに基づいて実行を制限できる機能を提供する。例えばこのCASの機能により、Webサーバからダウンロードしたプログラムは、実行者権限によらず、デフォルトではローカル・ディスクへの書き込みなどが制限される。

INDEX
	システム管理者のための.NET入門
	第1回 なぜ.NETが必要なのか？
	1．変化に柔軟に対応できる情報システム
	2．これからの情報システムに何が必要なのか？（1）
	3．これからの情報システムに何が必要なのか？（2）

　

「システム管理者のための.NET入門」

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