Windows Server 2008 – Application Platform

マイクロソフト畠山です。
Windows Server 2008ばっかりですが(笑)、本当にいろんなOSとしての機能強化が図られているのです。と同時に、新機能を列挙する過程で、「あ、こんな機能もあったんだ」と皆さんに気づきも持ってもらえればと思っています。というのも、直接いろんな方とお話をする中で、私の中では既に一般化していた事(つまり、暗黙知になっていた)が、そうで無いことに気づいたことが多々ありました。OSとして、こんなにUser Modeでアプリケーションを搭載しているのも、それはそれとしてすごいなと改めて感じております。

今日は、私が最も好きな、そしてかなり趣味に走りがちな「Application Platform」としてのWindows Server 2008について。以下に全体像を示します。
Windows Server 2008 Application Platform

  • .NET Framework 3.0

これは標準搭載されてくる事が大事です。ServerCoreインストールをしない限り、ついてきます (2007年8月時点)。これはとても大事で、いちいちインストールしたり、構成をする必要が無い、ということですよね。逆に言えばアンインストールが難しいかもしれません・・・
間違いなくMicrosoftの長期的戦略の中で「.NET」の位置しているところは非常に重要です。PowerShellの実行環境でもあり、WPFがその一部であり、SharePoint Technologyの実行環境でもあります。一つ覚えていると、応用範囲が本当に広いんです。私がPowerShellで最初に叩いたコマンドは「ps」ではありません。「[System.DateTime]::Now」です!!!
上記の図を参照してもらえればより明解ですが、皆さんが直接操作されるプログラムコードは殆ど.NET Frameworkを通じてOSの機能を呼び出すことになっていきます。OSの更なる抽象化ですね。これによって、OSのバージョンが変わっても、アプリケーションは.NET Framework上に対しての呼び出しをするわけですから、プラットフォームに影響されないアプリケーション構築が可能になります。
Serverである、Windows Server 2008では、特に、WCFWFに注目してみてもらいたいです。インターネットを前提に、そこで出てきた相互互換性の対応技術としてのXML。そのXML自身がもっている、メタデータのメタデータとしての可能性。つまりメタデータに意味をもたせるということ。そのXMLベースで記述が可能なのが、WPF、WCF、WFです。これも.NETが、実装技術として一貫性をもっているところです。つまり、長期にわたって利用できる可能性が高く、他のプラットフォームとの相互接続への道が開かれている、というところです。

  • KTM (Kernel Transaction Manager)

簡単に言います。File Systemがトランザクションの機能をサポートするために導入されたようなものです。TxFと呼ばれています。レジストリのアクセスでもトランザクション機能をサポートされるようになります。TxRと呼ばれています。
これによってできることの例を。
– ファイルへの書き込みとDBへの書き込みの一貫性保障 (つまり、MSDTCとの連携)
– アプリケーションのインストール処理時間の短縮
– ファイルバックアップ/リストアの信頼性向上
どうです?皆さんの身近なところでメリットありそうですよね?個人的には、robocopyがこれをサポートしてくれると、超嬉しいです。
技術的には、これらの処理をKernelレベルで実行するために、トランザクションモニタがKernelに実装された、ということですよね。
ちなみに、.NET Framework 2.0にLTM (Lightwight Transaction Manager)というのが実装され、.NETアプリケーションは、LTMに指示を送ることが基本となります。LTMが他のトランザクションモニタにメッセージを送るんですね。
残念なのが、TxFに関しては、現時点では.NET用のライブラリが用意されておらず、LTMも使えない模様・・・がんばれ!Microsoft!
ちなみに、.NET FrameworkからMSTDCを使う場合には、System.Transactoins名前空間のライブラリを使えばOKですローカルかリモートかはそんなに意識しないで使うことができます。

Microsoft Message Queuing です。MQですね。あるの知っていました?????????????????OSの標準機能でっせ!!!
MSMQ1.0からCOM APIがありましたので、VBなどのCOM Automationをサポートしている環境から使うことができたのですが、勿論、.NET Frameworkも1.0からしっかりサポートしています。
Messege Queuingをよくご存じない方に一言でいうなら、複数のアプリケーション間での、確実な電文の受け渡しを行うための仕組み、と言えます。
処理を他の誰かに依頼するとします。その時に、依頼側が実行結果を待つのが通常の処理。これは実装も簡単なのですが、依頼先の処理が終わるまでの間、依頼側が待たないといけない。という制限が出てしまいます。これは「同期通信」と言われている方式です。
じゃ、他に何があるかといえば、「非同期通信」。つまり、依頼側が、お願いね、といったら、その結果を待たずに、先に進んじゃう。依頼先で処理が終わったら、何らかの形で受け取る。という方式です。
この場合の電文をMessageと定義し、それを、仲介者がためておく。つまりQueuingですね。その仲介サービスをするのがMicrosoft 技術の場合MSMQです。仲介者がいることで、メリットもでてきます。
– 相手の場所を意識しなくてよい
– 相手の通信プロトコルを意識しなくてよい (データ本体は当然キメが必要ですが)
– 相手が都合の良いときに処理をすればよい。つまり、相手が負荷が高い時でも、仲介者が受け付けてくれる。
– Queuingは、CPUのアーキテクチャと非常に親和性が高い
一つの製品になるくらいの管理機能ももっているんですよ。実は。

WCFという技術によって、通信技術が統合され、アプリケーションは統一された柔軟性の高い宣言型のインターフェースを持つことができるようになりました。IISというのは、WCFアプリケーションのホスティング環境ともいえます。つまり、IISは、マルチスレッドのホスティング環境へと自身のサービスの場を広げています。HTTP通信はあくまでその中の一つ。.NET 2.0時代にも、.NET Remotingのホスティングサービスとして活用できたのですが、いよいよ本格化したと言えます。つまり、Windows Serverの外部I/FはIISに統合。その裏で動くApplication Platformとして、.NET Framework、MSMQ、トランザクション機能などが備わっているのです。

私が思うにWindowsを選択して、Platformがどうなるかといえば、標準化を適用し易くなると思います。それは、OSではなくて、OS+ミドルウェアという意味でです。ミドルウェアって、大体システム開発の時には、「共通機能」とか「フレームワーク」と呼ばれる部分で実装されますよね。個々のサブシステムは、それらを「利用」するだけ。つまり、アプリケーションに踏み込んだ「標準化」が可能になるわけです。
標準化をして良いことは:
・変化への対応。OSのアップグレード、修正プログラム適用などに検討事項が最小化。
・TCO削減。管理対象が最小化される。アプリケーション開発よりも、アプリケーション保守(ここではコードに手を入れることを「保守」と呼びます)、運用時に必要なツール・人がそろえやすい。
結果、ビジネス的な要求に応えやすくなるのではと思っています。

J2EEが出だした頃、「Application Serverって何?なんでそんなに高いの???」と素朴な疑問をもっていた私は、当時からWindows ServerにApplication Serverと呼ばれている機能が付属していることを知っていました。
後は、それがおまけでないことを確認する作業が必要ですよね。ご自身の技術要件にマッチするようでしたら、お手元のWindows Server。もしくは、お手元のWindows NT Client (2000、XP、Vista)で試されてはいかがでしょうか?

2007年8月20日
マイクロソフト株式会社
畠山 大有

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中