経営者の視点から見た.NETの技術的優位性、採用のポイントはどこに？

　おそらく、コンピューティングの歴史において、Microsoftの.NETほどぐちゃぐちゃになり、誤解されたブランドはないだろう。.NETはこれまで、COMの代替として登場し、同社の発表する全ソフトウェア製品の基盤と引用され、さらにはJavaキラーとして評されてきた。当のMicrosoftですら、.NETコンセプトのアピール方法に関して揺れ続けている。CIOの多くは、.NETとは何か、その優位性は何かについて、ただ単に知る手がかりを持てない状態だ。

　Microsoftは昨年、次世代のサーバOSをWindows .NET Server 2003と改名した。そしてつい最近、今度は180度回転して、Windows Server 2003という元の名称に戻した。では、この新サーバOSの機能にも何か変更があったのだろうか？　名称は変わっても、.NET FrameworkをOSに組み込んだWindowsの最初のサーババージョンであることに変わりはない。

　そういうわけで、Windows Server 2003はいまや“.NETコネクテッド”ブランドとなった。この新しいブランディングの目的は、製品が.NETベースか、あるいはMicrosoftやサードパーティが提供する他の.NET製品と相互運用性があるかを示すことにある。だが、CIOが派手な宣伝文句からコンセプトの価値だけを取り出せるようにするためには、ブランドの変更だけでは不十分だろう。

　CIOが最初に把握すべき重要なコンセプトは、システムリソースへの全アクセスを管理する中央のカーネルを中心にして、このプラットフォーム全体が展開しているという点だ。この関係を理解するためには、既存のWindowsアーキテクチャを思い出してみると良い。Windowsは開発者にシステムリソースのアクセス手段として、サービスとAPI（Application Programming Interface）を提供している。だが、開発者がシステムリソース（メモリやポート、ハードウェア）に直接アクセスする必要がある場合（または、したい場合）は、WindowsのサービスやAPIを“迂回する”ことができる。だが、その後これらのリソースを正しく開放しなかった場合、Windows環境とその下のハードウェア環境の間で整合がとれなくなり、かなりの割合でシステムクラッシュやメモリのリークを起こし、システムを不安定にしてしまう。

　さらに、WindowsのAPIはかなり安定しているものの、Windowsの上位に構築された他のサービス（データアクセス、メッセージキュー、HTTPへのアクセス、ネットワークプログラミング、セキュリティなど）へのAPIは、それぞれ独特の特徴を持ち、独特の習得方法が必要なクセ者だ。

　.NET Platformは、このようなシステムのインターフェースの入り口を、単一のコアとなるカーネルに置き換える。このコア・カーネルは、ハードウェアとシステムリソースへのアクセス全部に責任を持つ。.NET Framework上で開発されたアプリケーションは本質的に安定しているはずだ。というのも、このカーネルにより、アプリケーションがお互いを邪魔することがなくなるからだ。カーネルのインターフェースは、結合力があり、理解しやすく、拡張しやすい階層構造を持つクラス群として表現される。このクラスは、システムの下にあるハードウェアとシステムリソースへのインターフェースだけではない。SOAP、WSDL、HTTP、SMTP、HTMLなど業界標準の仕様をラッピングしたものもある。これにより、.NET Platformを使う開発者は標準クラスを使ってコードを書くことができ、Frameworkが必要な翻訳機能を提供してくれる。

　.NET Frameworkでは、あらゆるハードウェアやシステムリソースは、プロセッサやOSに依存しない一貫性のあるアーキテクチャとして提供される。そのため、Microsoft（および他社）は、.NET FrameworkのバージョンをWindows以外のOSに実装することもできる。

　Microsoftは、Windowsバージョンが動作するx86マシン向けに.NET Frameworkバージョンをリリースした。まずはWindows 98 Second Editionから提供された。また、MIPS、ARM、SH3、インテルのPAアーキテクチャ上で動作するWindows-Powered Pocket PC向けにもバージョンを提供している。さらには、学術向けとしてBSD UNIX上で動く.NET Frameworkバージョンもリリースされている。

　.NET Platformの第1のレイヤは、CLR（Common Language Runtime）だ。これは、プラットフォーム上で実行される全プログラムを代表して、システムリソースへのアクセスと許可を管理するものだ。CLRは、概念としてはJava仮想マシン（JVM）のようなものだが、重要な違いがいくつかある。

　まず、JVMでは、プログラムが動くたびにJava Byte Codesを翻訳処理するのに対し、CLRでは、アプリケーションの初回動作時のみネイティブコードにコンパイルし、このコンパイルイメージをそれ以降の作業で実行する。

　2つ目の違いは、CLRは.NET Platform向けに設計されたあらゆるコンパイラをサポートしている点だ。

　そのため、企業は無理にJavaへ移行しなくても、既存の言語スキル（Visual Basic、C、C++、C#、Javaと互換性のある言語、COBOL、FORTRANの他、約20の言語）を.NET Platformで活かすことができる。CLRは、セキュリティ、言語の実行処理、メモリ管理、ハードウェアやシステムへのアクセス、その他システムサービスを一括して管理する窓口の役割を果たす。.NET Framework向けに開発されたプログラムをロード、実行、そして管理できるため、この環境で動作するコードは“マネージド・コード（managed code）”と呼ばれる。開発者はCLRが提供する“アンマネージド（unmanaged）”なインターフェースからシステムサービスを呼び出すことも可能だが、CLRはこのインターフェースを使うアプリケーションに振るまいがよくないものがあれば、それをシャットダウンすることもできる。

　.NET Platformの第2、第3のレイヤは、総して“.NET Framework”と呼ばれる。

　第2レイヤはコアとなるクラス群で、これにより開発者はスレッドや文字列、セキュリティコンテキスト、ネットワークプロトコル、データベースシステム、メッセージキュー、アプリケーション・マネジメント・インターフェース（WMI）、生のXMLプロトコル、XML Webサービスのクラスなどのシステムリソースにアクセスできる。

　このレイヤの存在により、開発者はWindowsにプログラミングできる既存のツールや無数にあるシステムAPIを使用して、堅牢で安全な分散型データマネジメントアプリケーションをたちまちのうちに作成できる。この時間の節約が実現するのは、CLRの管理下で、マネジメントが容易で安定した環境にある全リソースの統一ビューを提供するという.NET Frameworkの機能があってこそだ。開発時間が短縮できるだけではない。デバッグもかなりシンプルになり、パワーアップしている。そして、CLRのリソースへのアクセスコントロール機能により、見つけ出すのが難しいメモリのリークやシステムリソース管理に関するバグを開発者が誤って混入してしまうことを最小限に防いでくれるというメリットもある。

　.NET Platformの最後のレイヤには、.NET Frameworkを構成する各種プレゼンテーションサブシステムが含まれる。このうち重要なのは、Windows Formsライブラリ、ASP.NETライブラリの2つだ。Windows Formsライブラリは、標準Windowsコントロール（テキストボックス、リストボックス、グリッドなど）を含むクラス群で構成される。

　また、開発者はWindows Formsライブラリを用いると、.NETと互換性のある言語を使い高機能なフォームとコントロールを作成できる。これらはそのままでも使用できるし、新しいコントロールが継承して振るまいを付け加えることができるベースとしても使用できる。

　この機能を利用すれば、企業の開発チームはあらゆるソース言語で書かれた社内の重要なプレゼンテーション資産を再利用できる。ASP.NETライブラリは、XML WebサービスインターフェースやWeb FormsなどのWebベースの.NETアプリケーションへのアクセスを管理するものだ。ASP.NET Web Formsライブラリは、Windows Formsと似た機能を持つ。開発者は堅牢で、継承可能で、コンパイル済みのフォームとコントロールを生成でき、これらは複数のアプリケーションから利用できる。Web FormsライブラリのアドオンであるMobile Internet Toolkitを利用すれば、携帯電話やPalm PCなど、あらゆるWeb対応デバイスで動作するWebアプリケーションを構築できる。

　CIOにとって、.NET Platformに投資する決定的理由は何だろうか？　一言で言うと次のようになる：コスト削減。

　開発者は、より堅牢なアプリケーションをより短い時間で.NET Platform上に作成できる。既存の言語スキルを活用できるし、作成したアプリケーションにかかる管理と保守のコストも少なくて済む。さらに、.NET Platformにより、SOAP、XML、Webサービスなどの業界標準の相互運用性技術を用いたアプリケーションを短期に構築できる。相互運用性のあるアプリケーションは今後、他社のプラットフォームから要求されるようになるだろう。

　すでにある程度の額をMicrosoftの技術に投資している企業は、そろそろ.NETへの移行計画を立てる必要がある。逆にJ2EE側ならば、少なくとも、SOAP、Webサービスを使って.NETアプリケーションと結合する方法を把握しておくべきだ。今後1年間、その必要が生じることは間違いないからだ。