グラフィックス基盤戦略を大幅転換、WPF/EはAdobeを振り払えるか？（2/3 ページ）

[Greg DeMichillie，Directions on Microsoft]

　Microsoftの当初の計画では、.NET Frameworkを使わずに、WPF/Eは各プラットフォーム用のブラウザプラグインとして実装される予定だった。WPF/Eがサポートするのはブラウザアプリケーションのみで、プログラミングにはクライアントサイドJavaScriptの利用が予定されていた。

　今回の変更では、対応プラットフォームごとに.NET Frameworkバージョンが作成されることになり、WPF/Eは.NET Framework上で動作する見通しとなった。ただし、この新しい.NET FrameworkバージョンのWPF/Eについての詳細は、まだ固まっていない。このような.NET Frameworkの特化バージョンについては、既にいくつか提供されているものがある。例えば、Windows Mobileのようなデバイス用のCompact Frameworkや、サードパーティが.NET Frameworkを他のプラットフォームに移植する場合に使用できるRotorと呼ばれる共有ソースコードバージョンなどだ。しかし、同社は、WPF/Eシナリオでのダウンロードを考えた場合、RotorやCompact Frameworkのサイズは大きすぎると考えており、WPF/Eについてはダウンロードサイズを2MB未満に抑えることを目標としている。これは、Compact Frameworkのシンプルなグラフィックスではなく、WPF/Eの高度なグラフィックスをサポートしなければならないことを考えると、極めて野心的な試みだ。

企業開発者への訴求力を強化

　.NET Frameworkへ移行するということは、WPF/EにVBやC#などの言語を使用できることになり、企業開発者にとってはWPF/Eの魅力が高まる。JavaScriptの知識はさておき、既にVBの知識を有している企業開発者は多いからだ。

　また、.NETへの移行で、Microsoftの標準の開発ツールでもWPF/Eをサポートしやすくなる。同社の統合開発ツールスイートのVisual Studioは、ほぼ完全に.NET Frameworkを基盤にしており、スクリプト言語のサポートはほぼないに等しい。例えば、Visual Studioには、VB、C#、J#、C++を使ったアプリケーション作成用のプロジェクトテンプレート一式を備えているが、JavaScriptはサポートされていない。

　しかし、Visual Studioが既に.NET Frameworkをサポートしているとしても、WPF/EのXAMLサブセットをサポートし、WPF/Eと互換性のあるXAMLを作成できるグラフィックスツールを提供しない限り、WPF/Eが企業開発者に広く受け入れられることはないだろう。例えば、MicrosoftはXAMLを用いたUI設計の支援製品「Expression Interactive Designer」の提供準備を進めているが、同製品では、WPF/EプロジェクトをWPF/Eがサポートする範囲のXAMLに制限する必要があるだろう。同様に、Visual Studioの次期バージョンにどのようなXAMLツールを搭載するとしても、WPF/Eプロジェクトについては、このような制限を適用する必要がある。

高まるAdobeの脅威

　この新しいWPF/Eのプランは、企業開発ツール市場での競争の激化を反映している。特にAdobeは、Flash製品の成功を足がかりに、企業アプリケーション開発市場への進出を試みている。Flashは、Webでのインタラクティブなグラフィックス作成ツールとして広く使われている製品だ。

　Adobeは、Javaベースのツール、ライブラリ、フレームワークをまとめたFlexという製品のプロモーションを展開している。従来のFlashアプリケーションは、通常テキストやグラフィックスのアニメーションで構成されるが、FlexではFlashよりも複雑なアプリケーションを構築できる。最近リリースされたFlexのβ版では、Webサービスを介した通信のサポートや、会社のデータベースシステム内のデータの取得および更新機能も追加されている。