.NET Framework 3.0 の紹介

David Chappell
Chappell & Associates

July 2006
日本語版最終更新日 2006 年 10 月 16 日

適用対象:
.NET Framework 3.0 (旧名称 WinFX)
Windows Development

概要:Microsoft .NET Framework バージョン 3.0 には、今日のアプリケーション開発で直面する重要な課題を解決するためのさまざまなテクノロジが実装されています。

.NET Framework 3.0 の説明

アプリケーション開発の課題はいつの場合でも、短期間にベストなソフトウェアを開発することです。しかし、ソフトウェア開発のベースとなるプラットフォームが進化するにしたがって、その達成はますます難しくなっています。Windows の場合は、オリジナルの Win32 インターフェイスはさらに機能的な .NET Framework に統合されていきました。2002 年にリリースされたフレームワークバージョン 1、および 2005 年にリリースされたバージョン 2.0 のいずれによっても、Windows ソフトウェアを設計および記述する開発者の環境は、さらに効率的で生産的なものに進化しています。

これらに続く次のステップが、.NET Framework 3.0 (旧名称 WinFX) です。この新バージョンのフレームワークで構築されるアプリケーションは Visual Studio 2005 で作成できます。したがって、ほとんどの Windows ソフトウェア開発者にとって、.NET Framework 3.0 はなじみのあるものです。とはいえ、.NET Framework 3.0 も進化を遂げており、フレームワークバージョン 2 にはない機能が追加されています。2006 年末にリリースされる .NET Framework 3.0 は、Windows Vista、Windows Server 2003、および Windows XP に対応する予定です。

この文書では、新リリースについての説明、そのテクノロジの使用方法、それらのテクノロジについての簡単な説明をとおして、.NET Framework 3.0 およびそのコンポーネントの全体像を示します。

現代のアプリケーション構築: その課題

今日の標準的なアプリケーション開発は多くの要件が関係するため、もはや単純な作業ではなくなりました。保存データの操作や Web ブラウザによるアクセスなどについて考慮することは従来どおり重要ですが、それだけでは不十分です。現代のアプリケーション開発には、次のような新しい課題が伴います。

組織の業務は、ますますプロセス指向で捉えられるようになっています。ほとんどのアプリケーションはビジネスプロセスの一部を自動化するため、このプロセスのステップをコードで明示的に定義することが非常に有益になります。これを行う効果的な方法として、ワークフローテクノロジの使用があります。この方法を実現するには、ワークフローベースアプリケーション のサポートが必要です。
通常、アプリケーションは、組織内外の他のアプリケーションと通信します。したがって、現代のアプリケーションは、サービス指向アーキテクチャ (SOA) を備えている必要もあります。これにより、アプリケーション機能の一部を相互運用可能なサービスとして公開し、他のソフトウェアはその機能にアクセスできるようになります。これを実現するには、サービス指向アプリケーションのサポート が必要です。
通常、アプリケーションを使用するユーザーは、何らかの方法で認証する必要があります。しかし、デジタル ID の定義とその使用方法は多種多様で複雑なうえ、フィッシングなどの問題も一般的になっています。このような状況を考えると、現代のアプリケーションとそのユーザーには、統一されたデジタル ID ユーザー管理 が必要です。
今日、ユーザーインターフェイスの要件は、ますます大きくなっています。一般的に、ビジネスバリューの創出には、さまざまなドキュメントの操作、2 次元や 3 次元グラフィックの使用、ビデオの表示などを伴います。そして、これらのすべてがネイティブの Windows クライアントと Web ブラウザの両方で使用できる必要があります。これらのニーズを満たすには、多種多様なユーザーインターフェイスに対する統一されたアプローチ が必要です。

今日のアプリケーションで、これらの課題に対する取り組みが必要であることを考えると、アプリケーションのベースとなるプラットフォームでも、一貫した実際的な手法でこれらの課題に取り組むことが必要です。.NET Framework 3.0 は、Windows アプリケーションでまさにこれを実現するために用意されました。

問題への取り組み: .NET Framework 3.0 で提供される機能

図 1 が示すように、.NET Framework バージョン 3 は旧バージョンの上に構築されています。実際、.NET Framework バージョン 2 から引き継いだ機能の変更点はありません。したがって、バージョン 2 上で作成された既存のアプリケーションは、バージョン 3 上でも問題なく作動します。とはいえ、.NET Framework 3.0 には Windows Workflow Foundation、Windows Communication Foundation、Windows CardSpace、および Windows Presentation Foundation という新しい 4 つのコンポーネントが追加されています。ここでは、.NET Framework 2.0 を概観し、新たに追加された各コンポーネントで提供される機能について説明します。

図 1

.NET Framework 2.0: Windows アプリケーション用の汎用基盤

現在でも Win32 インターフェイスを直接使用するソフトウェアを記述することは可能ですが、新しい Windows アプリケーションでは .NET Framework が主要な環境となっています。.NET Framework で重要なコンポーネントの一部は次のとおりです。

ASP.NET: Web アクセス可能なアプリケーションの作成をサポートします。
ADO.NET: アプリケーションがリレーショナルデータやその他データにアクセスできるようにします。
Windows フォーム: Windows アプリケーションのグラフィカルユーザーインターフェイス (GUI) の作成をサポートします。
System.XML: XSLT および XPath の使用を含め、アプリケーションが XML データを処理できるようにします。

フレームワークバージョン 2.0 では、旧バージョンにいくつかの便利な機能を追加しました。たとえば、ASP.NET Web アプリケーションの作成を大幅に改善するテクノロジ、64 ビットバージョンの Windows で実行される 64 ビットアプリケーションのサポート、新しいトランザクション処理アプローチなどです。したがって、.NET Framework 2.0 の機能の一部が、バージョン 3.0 に追加された新しいコンポーネントに取って代わられるとはいえ、バージョン 2.0 のテクノロジはバージョン 3.0 においても引き続き基礎をなしています。この点は、後で詳しく述べます。

Windows Workflow Foundation: ワークフローベースアプリケーションのサポート

ワークフローとは単純な概念で、ある決まった順序で実行される一連のステップのことです。ある人は、どのアプリケーションも何らかのプロセスを実行するので、アプリケーションにはワークフローが実装されていると考えるかもしれません。しかし、C#、Visual Basic、および他のプログラミング言語でアプリケーションを作成するという従来のアプローチでは、プロセスのステップがコード内で暗黙的になります。この方法でもアプリケーションは作動しますが、プロセス自体がプログラムのロジック内に埋もれてしまい、プロセスの実装や変更が困難になります。

ワークフローテクノロジを使用してプロセスロジックを実装すると、この問題を解決できます。ロジックを通常のコードに絡める代わりに、プロセスの各ステップを明示的に定義し、その後ワークフローエンジン で実行します。これにより、プロセス自体を実装できます。

ワークフローエンジンの使用は今に始まったことではなく、Windows や他のシステムで既にいくつか使用されています。たとえば、マイクロソフトは、一部の製品にワークフローエンジンを組み込んでいます。とはいえ、アプリケーションの作成で、ワークフローによるアプローチが主流になりつつある今、Windows 向けに統一されたワークフローテクノロジを提供することは当を得ています。これこそ、Windows Workflow Foundation (正式略称は WF) で実現されることなのです。Windows 向けに共通のワークフローテクノロジを用意することで、WF はどのワークフローベースアプリケーションにも同一の構築ファウンデーションを提供します。他のベンダで今後開発されるアプリケーションと同様、Microsoft Office 2007 system や Windows SharePoint Services などのマイクロソフト提供のソフトウェアも WF を使用する予定です。

しかし、共通のワークフローテクノロジにはいくつかの課題もあります。たとえば、さまざまなワークフローアプリケーションが必要とする多種多様な要件を、1 つのアプローチでどのように満たせるのでしょうか?その答えは、WF で採用されているワークフローの一般的な概念にあります。図 2 に示すように、WF ワークフローは WF エンジンによって実行されるアクティビティ のグループにすぎません。各アクティビティは実際にはクラスであり、ワークフローの作成者が意図する任意の作業を含むことができます。アクティビティは、別のワークフローで再利用することができ、新しい問題に対する自動化ソリューションを作成しやすくなります。

図 2

共通のワークフローテクノロジで生じる別の問題は、ヒューマン指向とシステム指向という従来の区分によるワークフローの相違です。主にユーザーによって使用されるワークフローアプリケーションには、すぐにプロセスを変更できるような柔軟性が必要です。逆に、主にシステム (ソフトウェア) によって使用されるワークフローアプリケーションは静的になる傾向がある一方で、効率性が求められます。WF はこれら両方の使用を念頭に入れて設計されています。つまり、実行中のワークフローを変更できるようなヒューマン指向的な特徴を持ちながらも、システム指向的な処理もサポートしています。

.NET Framework 3.0 の WF で Windows 向けの共通ワークフローテクノロジが提供されることにより、開発者はソフトウェア作成にこの便利なパラダイムを利用できます。プロセス指向のソフトウェアが普及するにしたがって、ワークフローの使用はますます一般的になるでしょう。

Windows Communication Foundation: サービス指向アプリケーションのサポート

アプリケーションがワークフローを使用して構築されているかどうかにかかわらず、ほとんどのアプリケーションは他のアプリケーションと通信する必要があります。この通信方法については、過去数年で大きな進歩がみられています。十数年にわたる混乱の末、主要ベンダはアプリケーションの通信に同一プロトコルをサポートするという合意に達しました。SOAP に基づくこの Web サービスの世界的な合意により、さまざまなプラットフォーム (J2EE や .NET Framework など) で構築されたアプリケーション間の相互運用が、過去と比べて格段に容易になりました。さらに、ほとんどの組織にとって、サービス指向のアーキテクチャというアイデアがより現実的なものになりました。

通信には、既に多くの方法が存在します。一例として、.NET Framework 2.0 には、次のオプションがあります。

ASP.NET Web Services: 相互運用可能な SOAP ベースの通信を提供
.NET Remoting: .NET アプリケーション間の通信に特化
Enterprise Services: スケーラブルなトランザクションアプリケーションのサポートを提供
System.Messaging: Microsoft Message Queuing (MSMQ) によるメッセージキューイングをサポート
Web Services Enhancements (WSE): WS-Security などの最近の規格をサポートする ASP.NET Web Services の拡張

これらのテクノロジには、それぞれの意義と役割があります。しかし、基本的に同じ問題を解決するために、なぜ異なるソリューションが必要なのか、相互運用可能なサービスを使用するアプリケーション通信で、単一のファウンデーションを構築する方が良いのではないか、といった点が疑問として残ります。

これこそ、まさに Windows Communication Foundation (WCF) によって解決される点です。開発者は通信の種類ごとに異なるアプリケーションプログラミングインターフェイスを介して種々のテクノロジを扱う代わりに、WCF (オリジナルコードネームは "Indigo") が提供する共通の API を介し、一貫した方法で開発を行えます。.NET Framework 3.0 環境では、通信に上記テクノロジを使用していたほとんどのアプリケーションに、WCF が使用されます。

WCF は、現代のコンピューティングで欠かせない SOAP による相互運用可能な通信を強力にサポートします。これには、WS-Security、WS-ReliableMessaging、および WS-AtomicTransaction など、一部の WS-* 仕様のサポートも含まれます。とはいえ、SOAP は WCF の必要条件ではありません。したがって、最適化されたバイナリプロトコル、MSMQ を使用するメッセージキューイング、単純な REST ベースの通信など、他の方法を使用することもできます。さらに、WCF は通信に明示的なサービス指向のアプローチを採用しています。WCF は、オブジェクト間で透過的な通信を行う代わりに、わずかに異なる抽象化されたサービスを通信パーティ間に挿入します。この結果、分散オブジェクトシステムに存在する密結合を解消でき、エラーの発生を防いだり、変更を簡単に行ったりできるようになります。

組織の内外を問わず、アプリケーション間の通信は、現代のソフトウェアで重要な部分を占めています。.NET Framework 3.0 は、WCF のサービス指向のアプローチにより、この課題に対応します。

Windows CardSpace: 統一されたデジタル ID ユーザー管理

今日、インターネットでユーザーが認証を受ける方法を考えてみましょう。ほとんどの場合、ユーザーのデジタル ID は単純なユーザー名で表されます。この ID はパスワードと組み合わされて、電子メールアカウント、インターネットショッピング、オンラインバンク、その他商用サイトへのアクセスに使用されます。しかし、ユーザー名とパスワードには、その単純さ (および遍在性) に起因するいくつかの問題があります。その中で特に重要な問題を次に 2 つ挙げます。

さまざまなサイトで設定するユーザー名やパスワードをユーザーがすべて記憶することは困難である。この記憶の問題を避けるため、多くのユーザーが異なるサイトで同じユーザー名とパスワードを使用しており、結果としてセキュリティリスクが増大しています。
ユーザー名、パスワード、およびその他の個人情報が、フィッシング詐欺によって盗まれるおそれがある。詐欺メールを送りつけることで、フィッシング詐欺犯は本物と見分けがつかない Web サイト (たとえば被害者の銀行のサイト) にログインするよう被害者を誘導します。そのサイトは実際にはフィッシング詐欺犯によってコントロールされており、被害者が一度ユーザー名とパスワードを入力すると、詐欺犯はそれらの情報を用いて本人になりすまし、実際のサイトにアクセスできるようになります。

このような重大なリスクを抑えるには、デジタル ID を管理するための新しいアプローチが必要です。そのアプローチで重要な部分を占めるのが Windows CardSpace (オリジナルコードネームは "InfoCard") です。ユーザーが自分のデジタル ID を管理できるように、CardSpace では各 ID が固有のインフォメーションカード として表されます。Web サイトが CardSpace ログインを受け付けると、ログインしようとするユーザーに、図 3 のような CardSpace 選択画面が表示されます。ユーザーは、カードを選択することで、そのサイトへのアクセスで使用されるデジタル ID を選択できます。これにより、ユーザーは大量のユーザー名とパスワードを覚える代わりに、使用するカードを識別するだけでよくなります。異なるカードには別の情報を含めることもでき、各サイトで必要とされる正確な ID を管理できます。

図 3

これらのカードによって表される ID は、1 つ以上の ID プロバイダ によって作成されます。どの組織も ID プロバイダを提供できます。各 ID プロバイダが提供する ID には、単純なユーザー名とパスワードの代わりに、強力な暗号化メカニズムを使用します。ユーザーは、この ID で認証を受けることができます。CardSpace 自体にも、クライアントマシンで実行する自己発行型 ID プロバイダが含まれています。このプロバイダを使用し、ユーザーはパスワードに頼らない自分の認証用 ID を作成できます。Web サイトは、通常のパスワードベースの認証に代わって、これらの自己発行型 CardSpace ID を使用できます。これにより、パスワードに関連する問題を減らすことができます。

サイトのログイン時にパスワードを使用しなければ、フィッシング詐欺でパスワードが盗まれることはなくなります。とはいえ、フィッシング詐欺犯がユーザーをだまして偽サイトにログインさせた後、医療情報などの他の個人情報を盗み出すおそれはあります。これを防ぐには、ユーザーが本物のサイトと詐欺犯によって作成された偽物のサイトを見分けることが必要です。これを実現するため、Web サイトを有する組織は高信頼性証明書 を取得できます。今日の単純な SSL 証明書とは異なり、組織がこの新しい証明書を取得するにはさらに厳格な認証プロセスが求められます。たとえば、証明を受けようとする組織は、自己を証明するためにさらに厳しい要件を満たさなければなりません。高信頼性証明書には企業のロゴやその他の情報が含まれており、この証明書を使用するサイトの信頼性をユーザーが確認するのに役立ちます。ユーザーが新しいサイトにアクセスすると、CardSpace は標準画面を使用して、サイトの証明書に含まれる情報を表示します。また、受信した証明書の認証レベルに応じて、サイトの信頼性に関する保証レベルを示します。この目的は、サイトの信頼性についてユーザーが自主的に判断するように働きかけること、またどのサイトを信頼するかについて正しく判断できるようにユーザーを助けることです。

Windows CardSpace は、実際にはより大規模な ID メタシステム の一部を構成しています。完全にオープンで公開されたプロトコルに基づくこのメタシステムは、さまざまなプラットフォーム (Windows 以外のオペレーティングシステムも含む) やアプリケーション (Internet Explorer 以外の Web ブラウザも含む) 間で、多種多様なデジタル ID テクノロジを統一して使用する方法を定義します。Windows 向けに ID を選択するための共通の方法やその他機能を提供することで、CardSpace は ID メタシステムの中心的な役割を果たします。また、ID に関する根本的な問題に取り組むことで、.NET Framework 3.0 における重要な部分を担います。

Windows Presentation Foundation: 多種多様なユーザーインターフェイスに対する統一されたアプローチ

ほとんどのアプリケーションにとって、ユーザーインターフェイスは重要な部分を占めています。ところが、アプリケーションのインターフェイスに対するユーザーの要求は、ますます大きくなっています。アプリケーションで、従来のメニュー駆動型 GUI は依然として欠かせませんが、ビデオの表示、アニメーションの実行、2 次元や 3 次元グラフィックの使用、さまざまなドキュメントの処理も必要です。しかも、これらの操作すべては、アプリケーションがスタンドアロンデスクトップクライアントまたは Web ブラウザのどちらで実行されていても行える必要があります。

従来、ユーザーインターフェイスのこれらの側面は、さまざまな方法で Windows に実装されてきました。たとえば、開発者は .NET Framework の一部である Windows フォームを使用し、Windows GUI を構築できます。Web ブラウザインターフェイスの作成には、HTML に加えて、通常 Java アプレットか JavaScript コードが必要です。さらに、ビデオ表示には Windows Media Player か Adobe の Flash Player などのソフトウェアが必要ですし、ドキュメント形式は Microsoft Word か Adobe の PDF などで定義されます。したがって、開発者が直面する課題は明白です。つまり、多種多様なテクノロジを使用し、かつさまざまなクライアントにも対応できる一貫したユーザーインターフェイスの構築は簡単ではないということです。

WPF (Windows Presentation Foundation。オリジナルコードネームは "Avalon") は、主にこの課題を解決するために用意されました。WPF はユーザーインターフェイスのこれらの側面に対応する技術的に統一された基盤を提供することで、開発者の作業を軽減します。また、ビデオ、アニメーション、2 次元や 3 次元グラフィック、多様なドキュメントのサポートなどの新しいアプローチにより、今までにないユーザーエクスペリエンスを実現します。加えて、デスクトップクライアントとブラウザクライアントに共通のファウンデーションを提供し、それら両方で実行できるアプリケーションを簡単に構築することが可能になります。

図 4 に、WPF によって提供されるイメージ、ライブグラフィック、3 次元ビューなどを含むインターフェイスの例を示します。多種多様なテクノロジのスキルがなくても、開発者はこのようなインターフェイスを一貫した方法で作成できます。

図 4

ユーザーインターフェイス作成者が長い間直面してきた課題の 1 つは、効果的なインターフェイスの構築に必要な役割が異なることに端を発しています。インターフェイスの背後にあるロジックを作成するにはソフトウェア開発者が必要ですが、これらの開発者がインターフェイスの外観や操作性を定義する上で適任かというと疑問が残ります。むしろ、ヒューマンマシンインタラクションのスペシャリストであるデザイナの方が適任です。ところが、Windows フォームなどの旧テクノロジでは、完全に開発者だけを念頭に置いて設計されています。したがって、開発者とデザイナが効果的に共同作業することはできません。この問題に対処するため、WPF は XAML (eXtensible Application Markup Language) をベースにしています。XML ベース言語の 1 つである XAML により、ユーザーインターフェイスをコードで指定する代わりに、宣言で指定することが可能になります。これにより、デザイナが作成したインターフェイスの外観デザインに基づき、ツールでインターフェイスの仕様を生成または操作することが容易になります。実際、マイクロソフトはこれを行うための新製品 Expression Interactive Designer を提供する予定です。デザイナはこのツール (またはサードパーティ提供の他のツール) を使用し、インターフェイスの外観を作成し、そのインターフェイスの XAML 定義を生成できるようになります。開発者はその定義を Visual Studio にインポートし、インターフェイスで必要なロジックを作成できます。

Windows 上で直接実行されるスタンドアロン WPF アプリケーションを作成する場合、開発者は WPF のすべての機能を使用できます。一方、Web ブラウザ内で実行されるクライアントを作成する場合、開発者は XBAP と呼ばれる XAML ブラウザアプリケーション を構築できます。XBAP がスタンドアロン WPF アプリケーションと同じファウンデーションで構築されることで、ダウンロードされるブラウザアプリケーション内で、同じスタイルのユーザーインターフェイスを表示することが可能です。また、両方のアプリケーションで同じコードを使用できるので、開発者はデスクトップクライアントとブラウザクライアントで異なるテクノロジスキルを使用する必要がなくなります。インターネットからダウンロードされる XBAP は、この種のリッチインターネットアプリケーションと同様にセキュアなサンドボックス内で実行されるため、このアプリケーションで行える機能は限られます。それでも、スタンドアロン WPF アプリケーションで使用できるユーザーインターフェイス機能の大部分を XBAP でも使用できます。

WPF スタンドアロンアプリケーションと XBAP の両方は、WPF でサポートされる最新グラフィックを利用できます。これには、ハードウェアアクセラレータの使用やベクトルグラフィックのサポートなどがあります。さらに WPF は高性能なグラフィックをサポートしており、Windows フォームや他の旧テクノロジでは不可能だった多彩なデータビジュアル化オプションが可能になっています。加えて、WPF は XPS (XML Paper Specification) のファウンデーションも提供します。XPS により、固定書式ドキュメントを表示、配布、印刷するための標準形式が定義されます。

ユーザーインターフェイスは、現代のアプリケーションにおいて重要な部分を占めており、しかもその機能は複雑化しています。.NET Framework 3.0 の WPF は、これらのユーザーインターフェイスで生じる課題を解決するための完成度の高い一貫したソリューションを提供します。その目的は、ユーザーインターフェイスの作成にかかわる開発者とデザイナの両方が、さらに効率良く作業できるようにすることです。

.NET Framework 3.0 の使用: シナリオ

紹介したさまざまなテクノロジがどのように連携するのか理解するために、テクノロジの使用方法を示す実例を考えましょう。例として、顧客と代理店が保険加入の申し込みに使用するアプリケーションについて考えます。.NET Framework 3.0 で実装すると、このアプリケーションは図 5 のようになります。

図 5

図の左上に示すアプリケーションのビジネスロジックは、WF ワークフローを使用して実装されています。保険加入の申し込み処理はマルチステッププロセスであり、その申し込みを保険会社の加入者規則に照らして評価すること (申し込み者のクレジットカードの確認やマネージャの承認など) が含まれます。ワークフローは、これらのステップをアクティビティとして実装しており、必要に応じて他のソフトウェアを使用します。一例として、このワークフローでは、保存されているデータにアクセスするために ADO.NET が使用されています。

この保険会社にはコールセンターがあり、顧客が電話で保険加入の申し込みを行えるようになっています。このコールセンターのスタッフが使用するクライアントソフトウェアは、図の右上に示すように、スタンドアロン WPF アプリケーションとして実装されています。このクライアントソフトウェアは、WCF-WCF 通信に最適化されたバイナリプロトコルを介し、WCF を使用するアプリケーションビジネスロジックと通信します。この図が示すように、コールセンターのスタッフはこのアプリケーションにログインするとき、Windows CardSpace を使用して ID を選択します。

顧客は Web を介して保険加入の申し込みを行うこともできます。また、保険代理店も同様に申し込みを提出できます。これを可能にするには、アプリケーションが ASP.NET を使用して Web ブラウザと通信する必要があります。図表の左下にあるように、Internet Explorer で通常の HTML インターフェイスを介してこのアプリケーションにアクセスする顧客も、CardSpace を使用して目的の ID を選択できます。サードパーティは、他のクライアントオペレーティングシステムおよびブラウザ向けに ID の選択メカニズムを実装することもできます。これにより、ID メタシステムを Windows 以外のクライアントや Web ブラウザに拡張することが可能になります。

インターネットでこのアプリケーションにアクセスする保険代理店は、さらに機能的なインターフェイスを必要とする場合があります。この場合、保険代理店では単純な HTML インターフェイスではなく、XBAP を使用できます。これにより、図表の下中央にあるように、代理店はコールセンターの WPF デスクトップアプリケーションが提供するユーザーインターフェイス機能の大部分を使用できるようになります。どちらの場合も同じファウンデーション上に構築されているので、アプリケーション開発者は両方のクライアントタイプに同じコードを再利用できます。また、他のクライアントマシンと同様に、代理店も CardSpace を使用し、目的の ID でアプリケーションにログインできます。

最後に、このアプリケーションの他のアプリケーションとの相互アクセスについて考えます。たとえば、顧客の承認にクレジットカードの確認が必要な場合、通常この処理は外部サービスを呼び出して行うことになります。また、他のソフトウェアからの要求を直接受け付ける場合もあります。この場合は、それらの外部アプリケーションがサービスを呼び出せるように、そのサービスを公開しなければなりません。これらの場合、図の右下に示すように、アプリケーションは WCF をベースにし、標準的な Web サービスを使用して通信することができます。これらの外部アプリケーションがどのテクノロジで構築されていても、WCF は SOAP をサポートするので、それらのアプリケーションと直接に相互アクセスすることが可能です。

このシナリオは、.NET Framework 3.0 で最も重要なコンポーネントの一部の使用例を示したものにすぎません。オプションの大部分は省略されているため、この簡単なシナリオで .NET Framework 3.0 テクノロジファミリのすべてが網羅されているわけではありません。このシナリオの目的は、実際のビジネス上の問題を解決する上で、.NET Framework 3.0 のさまざまな機能をどのように使用できるのかをわかりやすく紹介することです。

.NET Framework 3.0 の理解: テクノロジ

.NET Framework 3.0 で何ができるのかを実感するにあたって、.NET Framework 3.0 を構成する各テクノロジの理解を深めることは非常に効果的です。ここでは、.NET Framework 3.0 を構成する 5 つの部分について、簡単なチュートリアルを紹介します。各部分の詳細な紹介については、巻末の「参考情報」を参照してください。

The .NET Framework 2.0

図 6

今日、.NET Framework 2.0 は Windows ソフトウェア開発の基礎をなしており、.NET Framework 3.0 の基盤ともなっています。図 6 は、Framework の 2 つのコンポーネントである CLR (Common Language Runtime) と .NET Framework クラスライブラリを示しています。WF、WCF、および WPF など、.NET Framework 3.0 の一部のコンポーネントは、そのほとんどが .NET Framework クラスライブラリの拡張として実装されています。ただし、前述のように、クラスライブラリの大部分が引き続き開発者環境で重要な部分を占める一方で、.NET Framework 3.0 で提供された新しいテクノロジに統一された機能もあります。たとえば、ブラウザにアクセス可能なアプリケーションを作成するには、これからも ASP.NET がベースになり、保存データの処理には引き続き ADO.NET が使用されます。一方、.NET Framework 3.0 開発者は、ネイティブの Windows GUI の作成に Windows フォームではなく WPF を使用し、ASP.NET Web Services、.NET Remoting、または Enterprise Services よりも WCF を使用したいと思うでしょう。このように機能の使用方法に変化があるとはいえ、NET Framework 3.0 環境でも前バージョンの Framework が中心的な位置を占めていることを理解しておくことは重要です。

Windows Workflow Foundation

ワークフローによるプロセス指向の設計は、ほとんどの Windows ソフトウェアにとって理想的なアプローチといえます。WF の目的は、開発者がこれらのワークフローベースアプリケーションを作成し、実行できるようにすることです。図 7 は、これを実現するために WF で提供されるコンポーネントを示しています。

図 7

前述のように、各ワークフローは、いくつかのアクティビティで構築されます。ワークフローもアクティビティもクラスにすぎないので、どちらもコードで直接作成できます。また、WF には、Visual Studio をホストとするワークフロー構築用グラフィックツールの Workflow Designer も用意されています。どちらを使用するにしても、ワークフローを作成すると、WF 提供の BAL (Base Activity Library) やその他のソースから、そのアクティビティを引き出すことができます。

ワークフローが定義されると、WF ランタイムエンジンによりそのワークフローが実行されます。このエンジンは、ランタイムサービスグループに基づき、ワークフローの状態を記録し、ワークフローの実行やその他の情報を追跡します。これらすべて (ランタイムサービス、ランタイムエンジン、およびワークフロー自体) は、いずれかのホストプロセスに含まれます。このプロセスは、デスクトップで実行される簡単なコンソールや WPF アプリケーションから、スケーラブルなサーバープロセスまで、どの Windows プロセスにも使用できます。

WF を理解するには、少なくともそのコンポーネントすべてについて最低限のことを知っておく必要があります。次の部分では、各コンポーネントについて簡単に説明します。

ワークフロー

本質的に、ワークフローはアクティビティのグループにすぎません。WF は、次の 2 つのスタイルのワークフローをビルトインサポートしています。

定義した順序でアクティビティを実行するシーケンシャルワークフロー。従来のフローチャートのように、シーケンシャルワークフローには、分岐、繰り返し、その他の制御構造を含めることができます。ただし、既定でアクティビティは 1 つずつ順番で実行されます。
従来の有限状態マシンを実装するステートマシンワークフロー。ステートマシンと同様に、ある時点でどのアクティビティが実行されるかは、現在の状態と受け取ったイベントの組み合わせによって決まります。

シーケンシャルオプションは、純粋にソフトウェアベースプロセスで使用されるワークフローのように、十分に定義されたワークフローに適しています。このワークフローの作成と理解は比較的簡単であり、ほとんどの開発者にとって初めはこのワークフローの方がなじみやすいでしょう。一方、ステートマシンワークフローは、実行パスを予測しにくい場合に適しています。たとえば、ユーザーとのやり取りが絡むワークフローがその良い例です。この場合、どのユーザーも任意の時点でワークフローをキャンセルする可能性があります。この状況にシーケンシャルワークフローで対応することも可能ですが、"ワークフローがキャンセルされなかったらこの操作を実行する、キャンセルされたら別の操作を実行する" というように、ステップすべてが分岐になってしまいます。この種の挙動は、ステートマシンを使用すると非常に簡単にモデリングできます。これは、ワークフローをキャンセルする要求が、任意の時点で受け取って処理することができるもう 1 つのイベントにすぎないためです。

ステートマシンワークフローのサポートは、WF でどのようにヒューマンワークフローとシステムワークフローの両方がサポートされるのかを示す良い例です。別の例は、ワークフローの実行の変更をサポートする WF の機能です。人は気紛れです。したがって、ワークフローが進行している間に、関係するユーザーがステップを追加、削除したり、プロセスに他の変更を加えたりする場合があります。この気紛れなユーザーの要求を制御するため、WF にはワークフローを作成する開発者が、その実行中にワークフローの変更を許可するか、またどのような変更を許可するかを指定するための機能があります。

Base Activity Library

開発者は、自由にカスタムアクティビティを作成できます。実際、マイクロソフトの目標は、再利用可能な豊富なアクティビティで構成される WF エコシステムの構築を促進していくことです。とはいえ、基本的なアクティビティの共通セットが用意されているなら、開発を始めることが容易になります。この共通セットの配布という役割を担うのが、BAL (Base Activity Library) です。

ワークフローに、必ずしも BAL のアクティビティを使用する必要はありません。しかし、多くの開発者にとって、特に開発初期段階では BAL が役立つでしょう。BAL には、次のアクティビティが含まれます。

IfElse: 条件が満たされているかどうかに基づき、複数の候補パスに含まれるアクティビティを実行します。
While: 条件が真である限り、1 つ以上のアクティビティを繰り返し実行します。
Sequence: グループ化されたアクティビティを、定義された順序で一度に 1 つずつ実行します。
Parallel: 複数のアクティビティグループを並列で実行します。
Code: 定義されたコードチャンクを実行します。
Listen: 特定のイベントを受け取るまで待機し、そのイベントを受け取ったら 1 つ以上のアクティビティを実行します。
InvokeWebService: Web サービスを呼び出します。
State: ワークフローのステートマシンの状態を表します。
EventDriven: 特定の状態にあり、かつ特定のイベントを受け取る場合に実行される、1 つ以上のアクティビティを含む推移を定義します。
Policy: WF 提供のルールエンジンを使用し、ビジネスルールの定義と実行を行えます。

WF では、ワークフローの作成に特定の言語を指定する代わりに、アクティビティの使用に関して幅広いアプローチをとっています。したがって、BAL で 1 つの "言語" が提供されるとはいえ、WF を使用する開発者は自分が使用したいアクティビティを自由に定義することができます。

Windows Workflow Foundation のツール: Workflow Designer

ワークフローを使用してアプリケーションを作成することには、ワークフローを視覚的に定義できるという利点があります。WF の Workflow Designer は、図 8 に示すようにこのワークフローの視覚化を実現します。既定では、BAL のアクティビティがツールボックスに表示されます。開発者は、それらのアクティビティをツールのデザイン画面にドラッグアンドドロップし、ワークフローを作成できます。

図 8

開発者によっては、視覚的な設計よりもコードの記述を好む場合があります。WF では、この方法も使用できます (場合によっては、コードの記述が必要になります。通常、アクティビティは直接コードで構築されます)。これら 2 つの方法を組み合わせ、Workflow Designer とコード記述の両方を使用してワークフローを作成することもできます。この目的は、開発者が最も生産的なアプローチを使用できるようにすることです。また、さまざまなツールをサポートできるように、WPF で使用される言語と同じ XAML でワークフローを表すこともできます。実際、Workflow Designer を使用して作成されるワークフローでは、既定で XAML 定義が使用されます。

ランタイムエンジンとランタイムサービス

前述のように、WF ランタイムエンジンには、ワークフローでアクティビティを実行する役割があります。その過程で、WF ランタイムエンジンはランタイムサービスのグループを使用します。WF はこれらのランタイムサービスを標準で実装しますが、意欲的な開発者は必要に応じてサービスを置き換えることができます。ランタイムサービスは 2、3 の異なる機能をサポートしますが、特に注目すべきものを 2 つ挙げます。

永続性: 何らかのイベントを待機しているためにブロックされたワークフローは、このサービスを使用して、そのインメモリ状態を自動的にディスクへ格納します。イベントが発生すると、このサービスは自動的にワークフローの状態を再ロードし、実行を再開します。このサービスは、ユーザーが関係するワークフローで特に役立ちます。ユーザーからの応答は、数時間、数日、場合によってはそれ以上かかる場合があるためです。
追跡: ワークフローのアクティビティは、そのアクティビティが実装するプロセスの実行を明確に区分します。WF の追跡サービスを使用すると、開発者はワークフローの実行に関する情報を自動的にデータベースに書き込むことができます。たとえば、開発者はワークフローの開始時刻と終了時刻、その各アクティビティの開始時刻と終了時刻、およびその他の情報を追跡できます。

Windows Workflow Foundation と他のマイクロソフトテクノロジ

新しいアプローチの導入が、既存のアプローチに与える影響は避けられません。この点、.NET Framework 3.0 の新しいテクノロジも、例外なく他のマイクロソフトテクノロジに影響を与えています。特に WF による影響が最初に顕著に現れるのは、Windows SharePoint Services、Microsoft Office 2007 システム、および BizTalk Server です。

開発者が、ドキュメントコラボレーションや他の情報共有ワークフローアプリケーションをさらに簡単に作成できるように、Windows SharePoint Services バージョン 3 は WF ランタイムをホストします。Office 2007 システムを構成する Office SharePoint Server 2007 は、Windows SharePoint Services の WF サポート上に構築されています。他にも、このサービスを追加することで、Office 2007 クライアントアプリケーションで InfoPath フォームを直接表示したり、文書の承認など、共通シナリオ用の定義済みワークフローセットを使用したりすることが可能です。

BizTalk Server を使い慣れたユーザーであるなら、そのオーケストレーション機能と WF 提供の機能が似ていることに気付くはずです。実際、BizTalk Server 2006 の次期リリースから、既存のオーケストレーション機能が WF に置き換えられる予定です。その際、既存のオーケストレーションを WF ワークフローに移行するためのツールも提供されます。とはいえ、WF と BizTalk Server 2006 で扱う課題はまったく別個であることを理解しておくことは重要です。

WF は、ワークフローベースの Windows アプリケーションを作成するための汎用的枠組みを提供します。つまり、WF はどのプロセスでもホストでき、あらゆる種類のアクティビティを使用します。WF はヒューマンおよびシステムワークフローを含め、すべてのビジネス課題に対応します。
一方、BizTalk Server はライセンス製品であり、エンタープライズアプリケーションの統合、ビジネスツービジネスの統合、およびビジネスプロセスの管理に特化しています。BizTalk Server は、多種多様なシステムとソフトウェアを接続する豊富なアダプタセット、RosettaNet および SWIFT などの標準を実装するアクセラレータ、およびビジネスアクティビティ監視機能のサポートを提供します。さらに、BizTalk Server は管理インフラストラクチャとツール、およびスケーラビリティの拡張も提供します。

WF は Windows の標準ワークフローテクノロジであるため、今後他のマイクロソフト製品やテクノロジでも採用されるでしょう。マイクロソフトの方針が何であれ、WF は開発者によって作成される多くのアプリケーションで定着するでしょう。

Windows Communication Foundation

通信のサービス指向への変化は、アプリケーションの対話方法に影響を与えます。サービス指向のアプリケーションをサポートするよう明示的に設計された WCF は、この変化を反映しています。ここでは、WCF で最も重要な部分である、サービスとクライアント、通信オプション、およびセキュリティ、通信の信頼性、トランザクションのサポートについて説明します。

サービスとクライアント

図 9

図 9 に示すように、WCF の基本的なアイデアは、クライアントによってアクセス可能なインターフェイスをサービスが公開するというシンプルなものです。このインターフェイスは、Web Services Description Language (WSDL) を使用して定義し、その後コードに変換することができます。また、C# や Visual Basic などの言語で直接定義することもできます。保険アプリケーションサービスを公開する簡単なインターフェイスの場合、言語で直接記述すると次のようになります。

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

この C# インターフェイスの定義は、ServiceContract 属性でマークされています。この属性は、WCF でこのインターフェイスのメソッドをリモート呼び出し可能な操作として公開できることを示します。インターフェイス内のどのメソッドが公開されるかは、OperationContract 属性でマークされているかどうかによります。この簡単な例では、各メソッドがこの属性でマークされています。したがって、これらすべてのメソッドがリモートの呼び出しに公開されます。ただし、すべてのメソッドにマークする必要はありません。インターフェイスの一部のメソッドだけに OperationContract を適用することも可能です。どちらの方法をとるにしても、アプリケーションのいずれかのクラスでこのインターフェイスを実装し、インターフェイスが定義するメソッドの実際のコードを提供する必要があります。これが完了すると、WCF は自動的に OperationContract でマークされたメソッドを、このサービスのクライアントにアクセスできるようにします。

図 10 に、サービスが実際にそのクライアントに公開される様子をさらに詳しく示します。インターフェイスに直接アクセスする代わりに、クライアントは特定のエンドポイント に接続します。サービスでは複数のエンドポイントを公開でき、さまざまなクライアントが異なった方法でアクセスすることを可能にします。

図 10

図が示すように、各エンドポイントは 3 つの事柄を指定します。

コントラクト は、このエンドポイントを使用して呼び出し可能な操作を示します。コントラクトは、これらの操作を定義するインターフェイスの名前だけで識別できます。この場合、IInsuranceApplication になります。
バインディング は、エンドポイントの操作の呼び出し方法を定義します。各バインディングは、操作の呼び出しに使用するプロトコルの種類、使用されるセキュリティの種類など、さまざまな事柄を定義します。WCF には、この図に示す BasicHttpBinding のように、汎用の定義済みバインディングセットが含まれています。カスタムバインディングを定義することも可能です。さらに、1 つのサービスで複数のエンドポイントを公開できるため、異なるプロトコルやセキュリティオプションを使用して、さまざまな種類のクライアントに同時にアクセスすることが可能です。
アドレス は、このエンドポイントが存在する場所を示します。この図に示すように、アドレスは URL で表されます。

WCF の基本はシンプルです。とはいえ、ほとんどの通信テクノロジと同様に、詳細な部分では多くのオプションがあり複雑です。とはいえ、通常の WCF アプリケーションの作成は難しくありません。

通信オプション

さまざまな分野の開発者によって構築された多種多様なアプリケーションでは、異なる通信方法が必要です。ほとんどの開発者にとって最も簡単なアプローチは、リモートプロシージャコール (RPC) を使用する方法です。この方法では、ほとんどローカルの感覚で、クライアントからリモート操作を呼び出せます。前述のインターフェイスを例にすると、クライアントは通常の同期の方法で任意の操作を呼び出し、応答が返ってくるまで待機することができます。このオプションは開発者にとって簡単なアプローチですし、状況によっては適切です。

また、WCF には他のオプションもあります。オプションは次のとおりです。

応答がない呼び出し。属性 OneWay でマークされる通信は、イベントを送る場合や他の一方向のやり取りを行う場合に便利です。
非同期メッセージベースの通信。XML メッセージで、直接送受信を行います。
SOAP メッセージの明示的な操作。SOAP ヘッダに要素を直接挿入する機能を含みます。

WCF により、開発者はサービスの挙動に関するさまざまなローカル設定を制御することもできます。たとえば、ServiceBehavior 属性を使用し、サービスがシングルまたはマルチスレッドか、各呼び出しに新しいサービスインスタンスを作成するかなど、さまざまなオプションを設定できます。

セキュリティ、信頼性、トランザクション

システム間でデータのやり取りを行う基本的な通信機能は有用な機能ですが、それだけでは不十分です。ほとんどのアプリケーションでは、さらに高度な機能が求められます。たとえば、分散アプリケーションは、通常なんらかのセキュリティ対策を必要とします。しかし、使用されるアプローチやテクノロジが多様化している現在、セキュリティの実装は複雑な作業となります。詳細な点をすべて把握していなくても、開発者が安全な分散アプリケーションを作成できるようにするため、WCF ではセキュリティの実装に主にバインディングが用いられます。たとえば、前述の BasicHttpBinding は HTTP ではなく、HTTPS を使用するよう設定できます。セキュリティオプションを提供するバインディングは他にもあります。一例として、WS-Security をサポートしている WSHttpBinding を使用すると、相互運用可能な SOAP ベースの認証を行い、データ整合性、データ機密性を確保することができます。開発者は、アプリケーションが必要としているセキュリティサービスを提供するよう、バインディングをカスタマイズすることもできます。

通信の信頼性を確保することも、多くのアプリケーションにとってきわめて重要です。HTTP を介して SOAP を送信する従来の Web サービスアプローチで十分である場合は、basicHttpBinding を使用することができます。しかし、一般に広く使用されているとはいえ、多くの場合 BasicHttpBinding では十分に必要を満たすことができません。たとえば、1 つ以上の SOAP 仲介者を経由するメッセージでエンドツーエンドの信頼性を確保しようとする場合、この単純なアプローチに頼ることはできません。WCF は、このような問題に対処するために WS-ReliableMessaging を実装しています。WsHttpBinding など、このオプションをサポートするバインディングを選択するだけで、開発者は相互運用可能な信頼性の高いメッセージ送受信を行うことができます。

一部のアプリケーションでは、分散トランザクションも非常に重要です。WCF は .NET Framework 2.0 の機能である System.Transactions を基に構築されているため、WCF を使用することによって、トランザクションソフトウェアを作成することができます。メソッドでは、OperationBehavior 属性を使用して、トランザクションが必要であることを指定し、トランザクションの動作を定義することができます。ベンダの垣根を越えた分散トランザクションを可能にするため、WCF は WS-AtomicTransaction 仕様を採用しています。複数のベンダの合意により定義されたこのテクノロジにより、WCF アプリケーションは J2EE など、多様なテクノロジが混在する環境においてもトランザクションに参加できるようになっています。

Windows Communication Foundation と他のマイクロソフトテクノロジ

先に述べたように、WCF は、マイクロソフトでこれまで使用されてきた分散アプリケーションの作成に関連するテクノロジに取って代わるものです。これまで ASP.NET Web Service、.NET Remoting、Enterprise Services、System.Messaging、または WSE を使用して構築されていたアプリケーションのほとんどは、今後 WCF を基に構築されます。WCF アプリケーションは、ASP.NET Web Service アプリケーション (どちらも標準の SOAP をサポートしている)、および Enterprise Services、MSMQ、WSE のバージョン 3.0 を基盤とするアプリケーションと相互運用できます。さらに、WCF は BizTalk Server 2006 で使用することもできます。BizTalk Server の今後のバージョンでは、WCF の提供する機能がより直接的に活用されることになります。

WCF に取って代わられる従来のテクノロジが新しい .NET Framework 3.0 アプリケーションで積極的に使用されることはありませんが、それらのテクノロジは依然として .NET Framework 3.0 の一部を構成しており、すべて従来どおりにサポートされます。これらの旧テクノロジを使用して構築されたアプリケーションも正常に実行されます。.NET Framework 3.0 のインストールや使用により、既存のコードが破壊されることはありません。

Windows CardSpace

Web ブラウザを使用するか、その他のタイプのクライアントを使用するかにかかわらず、ユーザーは日常的にネットワークを介してアプリケーションにアクセスしています。これらのアプリケーションでは、ユーザーの身元を確認することが一般的となっています。結果として、ユーザーは頻繁に ID 情報を取得し、リモートソフトウェアにその情報を提供することを求められています。一般的な例としては、ブラウザを介してインターネットアプリケーションにアクセスする場合が挙げられますが、イントラネットのユーザーも同様の問題に直面しています。

前述のように、ユーザーは通常、デジタル ID としてユーザー名とパスワードを使用していますが、この方法には多くの問題も伴います。Windows CardSpace は、このような問題に対処する新たなアプローチを提供します。Windows CardSpace は ID メタシステムの構成要素です。したがって、CardSpace がどのように動作するのかを理解するには、まず ID メタシステムの基本的な概念を理解する必要があります。

Windows CardSpace と ID メタシステム

Web ブラウザ、アプリケーション固有のクライアント、またはその他のいずれを使用する場合でも、アプリケーションにアクセスするユーザーは、通常、なんらかのデジタル ID を提示することになります。デジタル ID はさまざまな形態をとりますが、ネットワーク上ではほとんどの場合、セキュリティトークン によって表されます。単純なセキュリティトークンはユーザー名のみで構成されますが、もう少し複雑なものになると X.509 証明書や XML ドキュメントを含むこともあります。このように異なる種類が存在しますが、セキュリティトークンは今やネットワーク上でデジタル ID を表す代表的なメカニズムとなっています。

セキュリティトークンの形式が 1 つに統一される日が来るというのは魅力的な考えですが、現実的ではありません。実際のところ、多様なアプローチは今後も使用され続けるでしょう。財布の中に車の免許証、クレジットカード、飛行機のマイレージカードなど、何枚もの ID カードがあるのと同様、ユーザーは引き続きさまざまな種類のセキュリティトークンによって表されるいくつものデジタル ID を持つことになります。このような現実に対して、単一の ID システムによる普遍的な解決策を示すことは不可能であり、複数のセキュリティトークンは今後も必要になると考えられます。

しかし、多様なデジタル ID に対して一貫した管理を行えるシステムが必要であることも事実です。単一の ID システムによってその必要を満たすことはできませんが、ID システムを統括するシステム (ID メタシステム) を作成することは可能です。このシステムにより、無数のデジタル ID を一貫した方法で使用することが可能になります。マイクロソフトは、他社と共同で、このメタシステムを定義する作業を進めてきました。WS-Security や WS-Trust などのオープン Web サービステクノロジに基づくこのメタシステムは、デジタル ID が依存するセキュリティトークンのタイプにかかわりなく、デジタル ID の取得および使用方法を定義します。

デジタル ID の発行、取得、使用という一連の流れには、3 つの異なる役割が関係すると考えられます。この 3 つの役割とは、次のものを指します。

ユーザー: 対象とも呼ばれます。ユーザーはデジタル ID を所有するエンティティです。
ID プロバイダ: ID プロバイダはユーザーにデジタル ID を提供します。雇用主によって割り当てられたデジタル ID の場合は、通常 Active Directory などのシステムが ID プロバイダとなります。一方、Amazon でユーザーが使用するデジタル ID の場合、ユーザー名とパスワードはユーザーによって定義されるので、事実上ユーザー自身が ID プロバイダとなります。作成元の ID プロバイダが異なれば、デジタル ID に格納される情報も、ユーザーの身元がどの程度まで保証されるかも異なることになります。
依拠当事者: デジタル ID をなんらかの目的で使用するアプリケーション。依拠当事者は ID (ID のセキュリティトークンに格納されている情報) を頻繁に使用してユーザーを認証し、ユーザーに特定の情報へのアクセスを許可するかどうかなどの承認を行います。また、クレジットカード番号の取得、同一ユーザーによる繰り返しアクセスの確認、あるいはその他の目的のために ID を使用することもあります。依拠当事者の一般的な例には、銀行、オンライン商店、オークションサイトなどのインターネット Web サイト、また Web サービスを介して要求を受信するアプリケーションがあります。

ID メタシステムでは、これら 3 つのエンティティが互いに情報をやり取りします。図 11 に、これらのやり取りと CardSpace の役割を示します。

図 11

一連のプロセスは、まず CardSpace を認識できるアプリケーションを使用してユーザーが依拠当事者にアクセスすることにより開始されます。依拠当事者が要求するセキュリティトークンのタイプを知るため、アプリケーションは依拠当事者のポリシーを取得します (ステップ 1)。一般的なケースとして、Web サイトにアクセスするブラウザの場合、サイトのポリシーは HTML 形式で記述され、Web ページの一部として返されます。一方、Web サービスを介してアプリケーションにアクセスする場合は、WS-MetadataExchange によって定義された業界標準のプロトコルを使用して依拠当事者にポリシーの送付を依頼します。この場合、ポリシーは、別の業界標準である WS-SecurityPolicy を使用して記述されます。いずれの方法で入手された場合でも、ポリシーには、依拠当事者が受け入れるセキュリティトークンの種類とトークンに含める必要のある情報の指定が含まれています。

必要なセキュリティトークンのタイプが通知されると、上に示されている ID 画面が表示されます。この画面には、ユーザーが使用できるすべてのデジタル ID が情報カードとして表示されます。外部の依拠当事者によって発行されたカードはマネージ カードと呼ばれ、CardSpace の自己発行プロバイダによって発行されたカードは自己発行 カードと呼ばれます。これらのカードは両方とも画面に表示されるので、ユーザーはいずれかのタイプのカードを選択することができます。決定を助けるため依拠当事者の要求を満たしていないカードはグレー表示されるので、ユーザーは適切なカードを見分けることができます。表示されているカードの中から、ユーザーはデジタル ID として使用するカードを選択します (ステップ 2)

ただし、セキュリティトークンそのものがカードに格納されているわけではありません。カードには、該当する ID プロバイダを特定し、ユーザーのセキュリティトークンを要求するのに必要な情報が格納されています。(すべてのカードは、もともといずれかの ID プロバイダが作成したものです。)CardSpace は、ユーザーによって選択されたカードの内容を使用し、カードを発行した ID プロバイダに対してセキュリティトークンを要求します (ステップ 3)。この要求は、また別の業界標準プロトコルである WS-Trust を使用して行われます。ユーザーは、Kerberos、X.509 証明書、デジタル署名、または他のメカニズムを使用し、ID プロバイダに対して自らを認証します。暗号化されたトークンが送り返されます。トークンには、そのトークンが経路を外れて盗まれ、将来盗用されることのないように、タイムスタンプが含まれています。

要求したセキュリティトークンが返されると、そのトークンは依拠当事者に送信されます (ステップ 4)。トークンに格納されている情報が依拠当事者によってどのように使用されるかは、ケースごとに異なります。たとえば、トークンに X.509 証明書が含まれており、デジタル署名が添付されている場合は、依拠当事者がトークンを使用してユーザーの認証を行うと考えられます。ただし、トークンは必ず認証あるいは他のセキュリティ関連の目的で使用しなければならないわけではありません。(実際のところ "セキュリティトークン" というのは正確な名称ではありません。)トークンには、ユーザーの年齢を証明したり、インターネットのショッピングサイトで割引を受ける資格があるかどうかを示したりする情報が含まれる場合もあります。セキュリティトークンが認証に使用されることが多いとはいえ、他の目的で使用することも可能です。

重要な点として、CardSpace でも、ID メタシステム全体としても、個々のセキュリティトークンで使用されている形式やテクノロジは認識されません。メタシステムの目的は、デジタル ID のソースを 1 つに統合したり、セキュリティトークンの標準形式を作成したりすることではなく、あらゆる種類のセキュリティトークンに基づくデジタル ID を一貫した方法で使用できるようにすることです。メタシステムの中核を Windows に実装することで、CardSpace は、デジタル ID を管理する包括的アプローチを現実のものとする重要な役割を果たしています。

フィッシング対策

多くの場合、ID プロバイダとユーザーとは明確に区別されます。たとえば、雇用主によって ID が割り当てられる場合などがそうです。しかし、ID プロバイダがユーザー自身であるというケースも少なくありません。CardSpace を使用しない場合、Web サイトへのアクセスで要求されるユーザー名やパスワードは、どちらもユーザーによって定義されます。ユーザーは一度 ID を作成すると、その後はそのユーザー名とパスワードを入力して、残高照会や本の購入など、そのサイトで可能な操作を行うことができます。

このようなパスワードに依存する自己発行 ID は、前に述べたように攻撃者のターゲットとなります。このような攻撃を減らすため、CardSpace は自己発行 ID を作成する新たな方法を提供しています。この自己発行 ID プロバイダは、ユーザーの Windows システムでローカルに実行されます。ユーザー名やパスワードに頼る代わりに、自己発行 ID プロバイダによって作成されるセキュリティトークンは、OASIS 定義の標準である Security Assertion Markup Language (SAML) を使用して定義されます。これらのトークンは、パスワードではなく、公開キーテクノロジを使用してユーザーの ID を証明します。依拠当事者の側でサポートされていれば、これらのトークンは従来のユーザー名やパスワードと同じ役割を果たすことができます。この方法の利点は、フィッシング詐欺犯が盗むことのできるパスワードがもはや存在しないということです。パスワードへの依存を減らし、前述の高信頼性証明書によるサイトの ID 証明を利用するなら、フィッシングは大きな脅威ではなくなります。

Windows CardSpace と他のマイクロソフトテクノロジ

CardSpace は、次のようなマイクロソフトテクノロジと関連しています。

WCF: CardSpace は、WS-Security や WS-Trust などの Web サービス標準に依存しているため、WCF を使用して通信を行います。WCF アプリケーションの作成者は、特定のバインディングを指定することにより、CardSpace を使用するようアプリケーションを構成することができます。
Active Directory: 現時点ではまだ実現していませんが、Active Directory は将来的にメタシステムの ID プロバイダとして機能することになります。
Windows Live ID (旧名称 Passport): Active Directory と同様に Live ID 認証システムも ID プロバイダとして機能するよう修正されることが発表されています。CardSpace は Live ID に取って代わるものではありません。これら 2 つは、それぞれ異なる問題に対応しています。Live ID は、他の ID プロバイダと同様に ID メタシステムの一部となります。

マイクロソフトは、他にも ID に関連したテクノロジを提供しています。それらのテクノロジは、それぞれ CardSpace とは異なる課題に応えています。たとえば、Active Directory フェデレーションサービス (ADFS) は、組織の壁を越えたフェデレーテッドアイデンティティの実現という課題に焦点を合わせています。これは重要な課題であり、他社との共同作業を行う多くの企業が直面してきた問題でもあります。しかし、CardSpace や ID メタシステムが取り組んでいる広範囲な問題とは、性質の異なるものといえます。

Windows Presentation Foundation

ワークフローベースのロジック、サービス指向の通信、ID はすべて現代のアプリケーションにとって重要です。しかし、多くのユーザーが注目するのは目に映るもの、つまりユーザーインターフェイスです。WPF の目的は、現代のアプリケーションのユーザーインターフェイスを作成するという課題に応えることです。次に説明するように、WPF はインターフェイスの作成に役立つさまざまな機能を備えています。

Windows Presentation Foundation の機能

開発者は、WPF アプリケーションのインターフェイスをすべて C#、Visual Basic、またはその他の CLR ベース言語で作成することができます。しかし、前述のように、WPF では XML ベースの XAML を使用してインターフェイスを指定することができます。XAML の要素と属性は、WPF が提供するクラスやプロパティに直接対応します。たとえば、XAML では、単純なボタンは次のように定義されます。

<Button Background="Red">
No
</Button>

この例では、"No" というテキストラベルを持つ赤いボタンが作成されます。これとまったく同じボタンを、次のようなコードで作成することもできます。

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

定義方法にかかわりなく、事実上すべての WPF アプリケーションは同じ基本モデルに従います。アプリケーションは、基本的なメソッド、イベント、プロパティを提供する WPF の標準 Application オブジェクトを継承します。WPF アプリケーションは、従来のダイアログ駆動型インターフェイス、またはブラウザアプリケーションのように機能するナビゲーションインターフェイスのいずれかを実装することができます。後者のスタイルで構築されるアプリケーションは、通常、ページのグループとして実装されます。各ページは、XAML で定義されたユーザーインターフェイスと、コードで定義されたロジックで構成されます。これらのページ同士をリンクするには、HTML と同様に Hyperlink 要素が使用されます。アプリケーションは一度に 1 つのページを表示し、ユーザーは各ページを行き来することができます。アプリケーションには、履歴リストの維持などの機能もあります。ナビゲーションアプリケーションを XBAP として Web ブラウザ内で実行することもできますが、必ずしもこの方法を使用する必要はありません。開発者は、スタンドアロンの WPF アプリケーションでこのインターフェイススタイルを使用することもできます。WPF が目指しているのは、ブラウザインターフェイスとネイティブ Windows インターフェイスそれぞれの長所を組み合わせたソフトウェアの作成です。

いずれのインターフェイススタイルを選択する場合でも、WPF アプリケーションの基本的なレイアウトはパネル に依存します。通常、各パネルにはコントロール が含まれます。WPF では、Button、TextBox、ComboBox、Menu などのコントロールが提供されています。これらのコントロールがどのように配置されるかは、選択されるパネルのタイプによって異なります。たとえば、Grid では指定されたグリッド上にコントロールが配置されますが、Canvas では開発者がパネルの境界内の任意の場所にコントロールを配置できます。GUI と同様、ユーザーによって生成されるイベントは、アプリケーションのさまざまなコントロールやクラスによって捕捉および処理されます。また、コントロールのグループに対してスタイルやテンプレートを適用することもできます。これは、アプリケーションのインターフェイスに統一感を与えることのできる簡単な方法です。

WPF は、これらの基本的なユーザーインターフェイス機能に加えて、次のような機能も備えています。

ドキュメント: WPF アプリケーションでは、XAML の FixedDocument タグを使用して XPS ドキュメントを表示することができます。また、FlowDocument タグを使用してフロードキュメント を表示することもできます。フロードキュメントは、従来の画面上のドキュメントと同じように動作させることができます。この場合、ユーザーはスクロールしてドキュメントの内容を表示します。一方、このタグでさまざまな属性を設定して、環境に対する高度な適応性を備えたドキュメントを作成することもできます。たとえば、読者が何度もスクロールを行わなくて済むように、ドキュメントを 1 ページずつ表示することができます。また、ウィンドウのサイズに合わせて、ドキュメントの段組を自動的に選択できる機能もあります。この機能が目的とするのは、画面上のドキュメントをできる限り読みやすくすることです。
グラフィックス: WPF では、2 次元や 3 次元のベクタグラフィックスの作成もサポートされています。2D グラフィックスでは、図形、ブラシ、ペンなどの標準の抽象クラスが提供されています。3D グラフィックスでは、モデルを定義して、光源やカメラ位置の情報を割り当てることができます。グラフィックスの処理を GDI+ に任せていた Windows フォームなどの従来のテクノロジとは異なり、WPF のグラフィックスは他の要素から隔離されていません。したがって、開発者がグラフィックスの作成に関する概念を別個に習得する必要もなくなります。グラフィックスに使用される XAML 要素は、ユーザーインターフェイスで使用される他の XAML 要素と簡単に組み合わせることができます。たとえば、ボタン上にグラフィックスを表示したり、テキストとグラフィックスを組み合わせたりすることができます。
イメージ: XAML の Image タグを使用すると、JPEG や GIF など多様な形式のイメージを WPF アプリケーションに表示できます。WPF は、WIC (Windows Imaging Component) を使用して、コーデック (イメージを表示および格納するソフトウェア) の標準フレームワークを提供します。Image 要素も他の要素と組み合わせることが可能です。一例として、ボタンに単純なテキストラベルではなく、イメージを表示させることができます。
メディア: WPF アプリケーションでは MediaElement タグを使用して、WMV、AVI、MPEG など、さまざまな形式のビデオやオーディオを表示できます。この要素も他の XAML 要素と組み合わせることができるため、たとえば、3D の立方体の各面にビデオを表示することが可能です。
アニメーション: WPF では、ユーザーインターフェイスのほとんどの場所にアニメーションに対するサポートが組み込まれています。たとえば、伸び縮みする円や滑らかに大きさを変えるボタンなどのアニメーションを表示できます。また、タイムラインを含むストーリーボードを定義し、一連のアニメーションを連動して動かすこともできます。
データバインディング: 多くの WPF アプリケーションでデータが表示されることを考えると、データをユーザーインターフェイス要素にマッピングするための自動サポートは便利な機能といえます。WPF では、オブジェクトや他のソースに格納されている情報に対してこのようなデータバインディングを実行できます。WPF のデータバインディングでは、データを表示する前に並べ替えたり、フィルタリングしたりすることもできます。

Windows Presentation Foundation の適用

WPF の提供する多様なユーザーインターフェイス機能により、開発者やデザイナは魅力的なユーザーインターフェイスを作成することができます。しかし、クライアントアプリケーションのインターフェイスがいくら魅力的であっても、展開に伴う問題のために、その使用をためらう企業があります。クライアントのアップグレードを実行するのに、アプリケーションがインストールされているすべてのデスクトップマシンを物理的に操作しなければならないとすれば、そのコストは莫大なものとなります。この問題を回避するのに、ネイティブ Windows クライアントの代わりにブラウザベースのクライアントを作成するという方法がとられています。しかし、一般的にブラウザのユーザーインターフェイスは、性能や応答性の面でネイティブ Windows クライアントに劣ります。クライアントの展開に関連するこのような課題を解決するため、スタンドアロンの WPF アプリケーションは ClickOnce を使用して展開することができます。ClickOnce は、.NET Framework 2.0 で発表されたテクノロジです。ClickOnce を使用すると、Internet Explorer ユーザーは Web を介してアプリケーションを選択し、ローカルマシンに自動的にインストールすることができます。また、インストールされたアプリケーションが新しいバージョンのリリース時に自動的に更新されるよう設定することもできます。このテクノロジの目的は、両方の長所、つまり Web クライアントの単純さや展開コストの安さと、スタンドアロン WPF アプリケーションのパフォーマンスや機能性を活かすことです。

ClickOnce を使用して展開されたスタンドアロン WPF アプリケーションは、多くの場合クライアントとして最適な選択肢となります。ただし、WPF の提供するインターフェイスをユーザーが利用できる場合でも、このようなアプリケーションの使用が適切でないケースもあります。たとえば、前述のシナリオに登場したリモートの保険代理店や、3D グラフィックス、ビデオ、および WPF がサポートする他の最新機能を提供するインターネット商店のようなケースがあります。このような場合、サイトにアクセスするため、ユーザーがネイティブの WPF アプリケーションをインストールすることは期待できません。より良い解決策は、Web ブラウザ内で WPF スタイルのインターフェイスを提供することです。

XAML ブラウザアプリケーション (XBAP) は、この目的のために設計されました。スタンドアロン WPF アプリケーションを展開するのではなく、Internet Explorer ユーザーが直接 XBAP をブラウザにダウンロードできるようにするのです。Internet Explorer 内で実行されるこのアプリケーションは、ユーザーに WPF ベースのユーザーインターフェイスを提供することができます。とはいえ、インターネット Web サイトからコードをダウンロードして実行することには危険が伴います。悪意のある開発者からユーザーを保護するため、インターネットからダウンロードされるすべての XBAP は部分的に信頼されたサンドボックス内で実行されます。.NET Framework が提供するコードアクセスセキュリティに基づくこのサンドボックスは、XBAP の機能を制限します。たとえば、インターネットからダウンロードされた XBAP がスタンドアロンウィンドウを作成したり、新しいウィンドウを開いたりすることはできません。また、XBAP 自身によって起動された保存ダイアログを表示することや、分離された記憶域以外の場所にあるファイルシステムにアクセスすることもできません。サンドボックスによって制限が課されるとはいえ、XBAP は WPF の大半の機能を使用することができます。これには、2D および 3D のグラフィックス、アニメーション、画面上のドキュメント、イメージ、ビデオなどが含まれます。

前に述べたとおり、WPF アプリケーションでは、XAML の FlowDocument 要素を使用して環境に適応するドキュメントを表示することができます。ただし、環境によって外観が変わるドキュメントが常に適切な選択肢であるとは限りません。場合によっては、画面上でもプリンタ上でも常に外観が変化しない固定書式ドキュメントの方が適切であることがあります。WPF の XPS ドキュメントはこの問題を解決します。XAML のサブセットによって定義されたXPS ドキュメントは、XPS リーダーを備えたシステムで読むことができます。このドキュメントによって Windows に追加される新しい印刷書式では、複雑なグラフィックスも忠実に再現して印刷できます。また、異なるタイプのドキュメントを一貫した方法で処理できるようにするため、XPS ドキュメントと Office 2007 ドキュメントの両方でマイクロソフトの Open Packaging Conventions が使用されています。Open Packaging Conventions は、ドキュメント内容の保存や、ドキュメントへのデジタル署名などを行う共通の方法を定義します。

Windows Presentation Foundation のツール

WPF ユーザーインターフェイスは、基本的な機能を備えたテキストエディタでコードまたは XAML を使用して直接作成することができます。しかし、より洗練されたツールを求める人々のために、WPF アプリケーションを作成できる拡張機能が Visual Studio 2005 に追加されました。Visual Studio の次のリリース (コードネームは "Orcas") では、Visual Designer for Windows Presentation Foundation によってさらに充実した機能が提供されます。このツールを使用することにより、開発者はイメージどおりのユーザーインターフェイスをグラフィカルに作成し、インターフェイスのコードをツールに生成させることができます。

しかし、多くの場合、ユーザーインターフェイスの定義を行う適任者は開発者ではありません。人とのコミュニケーションを専門とするデザイナの方が適しています。ほとんどのデザイナはコードを記述しないため、Visual Studio に含まれる Visual Designer for Windows Presentation Foundation はデザイナにとって効果的なツールではありません。デザイナが WPF 環境で効果的に作業できるよう、マイクロソフトは Expression Interactive Designer を作成しました。デザイナは、このツールを使用してインターフェイスの外観や操作性の定義、アニメーションの指定などを行います。作成したインターフェイスの XAML コードは、ツールに生成させることができます。開発者は、この XAML を Visual Studio にインポートし、イベントの処理などを行うコードを追加します。Visual Studio と Expression Interactive Designer はどちらも同じ構築システムを使用しているので、開発者とデザイナはそれぞれ使いやすいツールを使用しながら、対話的に 1 つのプロジェクトを進めていくことができます。これらのツールの目的は、デザインとソフトウェアエンジニアリングという異なる分野の専門家が共同で効率的に作業できるようにすることです。

Windows Presentation Foundation と他のマイクロソフトテクノロジ

他の .NET Framework 3.0 コンポーネントと同様に、WPF も既存のマイクロソフトテクノロジに影響を与えます。影響を受けるテクノロジのうち重要なものを次に挙げます。

Windows フォーム: Windows フォームは .NET Framework がアプリケーション GUI を作成するために当初採用していたアプローチであり、現在でも多くのアプリケーションで使用されています。この点を考慮して、WPF では Windows フォームのコントロールを WPF アプリケーションでホストし、WPF のコントロールを Windows フォームアプリケーションでホストすることが可能になっています。たとえば、Windows フォームアプリケーションは 3D データを視覚化する WPF コントロールをホストできます。いくつかの制限事項も存在しますが、両方のテクノロジを使用するアプリケーションの作成には差し支えません。既存の Windows フォームアプリケーションは、.NET Framework 3.0 環境においてもこれまでどおりに動作します。
Win32 および MFC (Microsoft Foundation Classes): Windows フォームと同様、既存のテクノロジを使用して構築された既存のアプリケーションで WPF コントロールをホストすることができます。また、その逆にホストすることも可能です。ただし、Win32 ベースおよび MFC ベースのアプリケーションは CLR を基に構築されていないため、Windows フォームほど簡単に相互運用を行うことはできません。WPF と相互運用するには、CLR ベースのコードとネイティブ Win32 コードとの間でマッピングを行う必要があります。
Direct3D: API の DirectX ファミリに属する Direct3D を使用すると、アプリケーションで 3D グラフィックスを作成および表示できます。.NET Framework 3.0 の登場により、主流の Windows アプリケーションは、Direct3D の提供する特化されたアプローチの代わりに、WPF の 3D 機能を使用できるようになりました。とはいえ、より高度なパフォーマンスが要求される 3D ゲームなどの一部のアプリケーションでは、今後も Direct3D が使用されます。実際のところ、レンダリングに関しては WPF は全面的に Direct3D に依存しています。
Windows Communication Foundation: 前に説明したシナリオにあるように、WPF アプリケーションでは WCF を使用することができます。ただし、XBAP は通常 WCF を使用することができません。これは、WCF が完全信頼を要求するのに対し、インターネットからダウンロードされた XBAP は部分的信頼のサンドボックスで実行されるため、WCF へのアクセスが禁止されるからです。その代わりに、XBAP は ASP.NET Web Services を使用して、WCF や実装されている他の Web サービスと相互運用する SOAP 呼び出しを行うことができます。
"WPF/E": "WPF/E" は .NET Framework 3.0 の一部ではないものの、ここで言及しておく価値のある WPF のテクノロジです。"WPF/E" というコードネームを持つこのテクノロジが目指しているのは、WPF そのものをサポートしていないシステムで WPF スタイルのインターフェイスをサポートすることです。コードネームの "E" が示しているように、このテクノロジは Macintosh、小型デバイス、その他のシステムなど、どんな場所 (everywhere) においても使用できるように設計されています。WPF に少し遅れて出荷される予定のこの WPF/E は、2D グラフィックス、アニメーション、ビデオなど、WPF のすべての機能のサブセットを備えています。

.NET Framework 3.0 の入手: 配布オプション

アプリケーションで .NET Framework 3.0 を使用するには、アプリケーションを実行するマシンにこのバージョンの Framework をインストールする必要があります。Windows Vista の場合は、既定で .NET Framework 3.0 がインストールされているため、新たにインストールを行う必要はありません。つまり、Windows Vista が搭載された新しいマシンと Vista にアップグレードされた既存のマシンでは、.NET Framework 3.0 アプリケーションを実行することが自動的に可能となっています。.NET Framework 3.0 は、Windows XP や Windows Server 2003 で実行することもできます。これらのシステムの既存ユーザーも新しい .NET Framework 3.0 コンポーネントを使用できるようにするため、このソフトウェアは無料でダウンロードすることが可能になっています。

まとめ

.NET Framework 3.0 は、Windows プログラミングモデルの進化した形です。.NET Framework 2.0 を基盤としつつ、さらにその機能を拡張した Framework 3.0 は、現代のアプリケーションの作成をサポートすることを目的としています。そのため、.NET Framework バージョン 3.0 には、今日のアプリケーション開発で直面する重要な課題を解決するためのさまざまなテクノロジが実装されています。多様なテクノロジを共通のファウンデーションの上に構築することにより、マイクロソフトは 1 + 1 が 2 以上になるよう努力を続けており、開発者が一貫した方法で .NET Framework 3.0 のさまざまなテクノロジを用いてアプリケーションを作成できるよう支援しています。

新しいリリースに含まれるいずれのテクノロジを取り入れる場合でも、企業の Windows ソフトウェア環境には必ず大きなインパクトがあります。開発者であれ、設計者であれ、意思決定者であれ、Windows のソフトウェア環境で作業するユーザーはすべて、.NET Framework 3.0 のもたらすメリットについて今すぐ検討を始めてください。

参考情報

『Understanding .NET, Second Edition 』David Chappell, Addison-Wesley, 2006

Windows Workflow Foundation の紹介 (英語)

Windows Communication Foundation の紹介 (英語)

Windows CardSpace の紹介

Windows Presentation Foundation の紹介

著者紹介

David Chappell 氏は、カリフォルニア州サンフランシスコにある Chappell & Associates (www.davidchappell.com) (英語) の社長を務めています。講演、著書、およびコンサルティングを通じて、世界中の IT プロフェッショナルがエンタープライズソフトウェアを理解し、使用すること、および適切な判断を下すことを支援しています。