introducing the .net framework 3.5download.microsoft.com/download/3/c/7/3c7278ac-ea… · web...

.NET Framework 3.5 の紹介

David Chappell、Chappell & Associates

September 2007 日本語版最終更新日 2007 年 11 月 29 日

© Copyright Microsoft Corporation 2007. All rights reserved.

.NET FRAMEWORK 3.5 の紹介

目次現在のアプリケーションのビルドの課題...............................................................................................3課題への取り組み : .NET FRAMEWORK 3.5 の特色....................................................................................4

ASP.NET AJAX: 応答性の高いブラウザアプリケーションのサポート..............................................4統合言語クエリ (LINQ) : 多様なデータへの統一されたアクセス.......................................................5Windows Communication Foundation: サービス指向アプリケーションのサポート.............................5Windows Workflow Foundation: ワークフローベースアプリケーションのサポート...........................6Windows Presentation Foundation: 多様なユーザーインターフェイスに対する統一されたアプローチ............................................................................................................................................................7Windows CardSpace : 統一されたデジタル ID ユーザー管理..............................................................9

進化の総括 : .NET FRAMEWORK 3.5 と旧バージョン..............................................................................11ASP.NET AJAX.....................................................................................................................................14統合言語クエリ (LINQ)..........................................................................................................................15WINDOWS COMMUNICATION FOUNDATION...................................................................................................16

サービスとクライアント..................................................................................................................17REST および RSS/ATOM のサポート...............................................................................................18通信オプション.................................................................................................................................19セキュリティ、信頼性、トランザクション......................................................................................20ツールのサポート.............................................................................................................................20Windows Communication Foundation と他のマイクロソフトテクノロジ.........................................21

WINDOWS WORKFLOW FOUNDATION..........................................................................................................21ワークフロー....................................................................................................................................22Base Activity Library...........................................................................................................................23Windows Workflow Foundation のツール : ワークフローデザイナ...................................................24ランタイムエンジンとランタイムサービス...................................................................................25ワークフロー対応サービス...............................................................................................................26Windows Workflow Foundation と他のマイクロソフトテクノロジ...................................................26

WINDOWS PRESENTATION FOUNDATION.....................................................................................................27Windows Presentation Foundation の機能..........................................................................................27Windows Presentation Foundation の使用..........................................................................................28Windows Presentation Foundation のツール.......................................................................................29Windows Presentation Foundation と他のマイクロソフトテクノロジ..............................................30

WINDOWS CARDSPACE............................................................................................................................31Windows CardSpace と ID メタシステム..........................................................................................31フィッシング対策.............................................................................................................................34Windows CardSpace と他の Microsoft テクノロジ............................................................................35

2


.NET Framework 3.5 の説明

アプリケーション開発の目標は、いつの場合でも、短期間に可能な限り最善のソフトウェアを開発することです。しかし、顧客からの要求が高まるにつれて、その実現はますます難しくなっています。このような要求に応えるために、開発基盤となるプラットフォームと開発者が使用するツールは、さらなる進化を続ける必要があります。

.NET Framework は、間違いなくその代表的な例です。2002 年の初期リリースから、3 年後には .NET Framework 2.0 がリリースされました。2006 年にリリースされた .NET Framework 3.0 は、多数の新しいテクノロジが追加されたメジャーアップデートでしたが、最新バージョンの .NET Framework 3.5 にはさらに有益な機能が追加されています。こうした進化と合わせて、 .NET アプリケーションを作成するためのマイクロソフトの主力ツールも進歩しています。最新リリースの Visual Studio 2008 では、.NET アプリケーションの作成に役立つ機能が広範にわたって強化されています。ここに至るまでの一歩一歩はすべて、Windows ソフトウェアを作成する方々に、より優れた、生産性の高い環境を提供することを目的としています。

ここでは、.NET Framework 3.5 の概要について説明します。.NET Framework の基本的な知識がある方を対象読者として想定し、 .NET Framework 3.0 および 3.5 で追加されたテクノロジについて主に説明しています。Windows アプリケーションの基盤として広く使用されているこのフレームワークが現在提供している機能を明らかにすることが目標です。

現在のアプリケーションのビルドの課題

現在のアプリケーション開発は、極めて多くの要件が関係するため、単純な作業ではありません。有効なビジネスロジックの作成や Web ブラウザによるアクセスなどについて考慮することは従来どおり重要ですが、それだけでは不十分です。現代のアプリケーション開発には、次のような新しい課題が伴います。

Web ブラウザインターフェイスが、インストールされている Windows アプリケーションのように動作することが、ますます期待されています。何かが変更されるたびに新しいページが読み込まれるのでは、もはや十分ではありません。それでは動作が遅すぎます。求められているのは、"応答性の高いブラウザアプリケーションのサポート" の強化です。

データは依然として、ほとんどのアプリケーションで中心的な存在です。しかし、データの表現方法は大きく拡張されています。オブジェクトとリレーション間のマッピングなど、リレーショナルデータは今でも重要です。ただし、XML を使用して表現されるデータ量は増え続けており、この傾向はおそらく変わらないでしょう。また、このように見られることはないとしても、実行中のプログラムのオブジェクトには、データが含まれています。"多様なデータに統一された方法でアクセスできる" テクノロジがあれば、アプリケーション開発の時間が短縮され、エラーも抑えることができるでしょう。

3


通常、アプリケーションは、組織内外の他のアプリケーションと通信します。したがって、現代のアプリケーションは、サービス指向アーキテクチャ (SOA) を備えている必要もあります。これにより、アプリケーション機能の一部を相互運用可能なサービスとして公開し、他のソフトウェアはその機能にアクセスできるようになります。これを実現するには、"サービス指向アプリケーションのサポート" が必要です。

組織の業務は、ますますプロセス指向で捉えられるようになっています。ほとんどのアプリケーションはビジネスプロセスの一部を自動化するため、このプロセスのステップをコードで明示的に定義することが非常に有益になります。これを行う効果的な方法として、ワークフローテクノロジの使用があります。この方法を実現するには、"ワークフローベースアプリケーションのサポート" が必要です。

今日、ユーザーインターフェイスの要件は、ますます大きくなっています。一般的に、ビジネスバリューの創出には、さまざまなドキュメントの操作、2 次元や 3 次元グラフィックの使用、ビデオの表示などを伴います。これらのニーズを満たすには、"多種多様なユーザーインターフェイスに対する統一されたアプローチ" が必要です。

通常、アプリケーションを使用するユーザーは、なんらかの方法で認証する必要があります。しかし、デジタル ID の定義とその使用方法は多種多様で複雑なうえ、フィッシングなどの問題も一般的になっています。このような状況を考えると、現代のアプリケーションとそのユーザーには、"統一されたデジタル ID ユーザー管理" が必要です。

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

課題への取り組み : .NET Framework 3.5 の特色

.NET Framework 3.5 には、前出の課題を解決するうえで役立つさまざまなテクノロジがあります。これらは、.NET Framework 3.0 で提供されていたものもあれば、3.5 リリースで新たに導入されたものもあります。ここでは、これらのテクノロジのうち、最も重要なものを紹介します。

ASP.NET AJAX: 応答性の高いブラウザアプリケーションのサポート

Web ブラウザは、新しいアプリケーションのユーザーインターフェイスとして最もよく利用されています。それでも、Web ブラウザは、従来からかなりの制限に悩まされています。たとえば、ユーザーが新たな要求を行うたびに、Web サーバーとのラウンドトリップが必要になり、通常は新しいページの読み込みが行われます。よりインテリジェント (で高速) な方法は、可能であればバックグラウンドでデータにアクセスし、ページの変更部分のみを更新する方法です。この方法であれば、待ち時間が新しいページの読み込みにかかる時間よりも少なくてすむため、より応答性の高いアプリケーションが得られます。

4


これこそ、まさに Web アプリケーションをビルドするにあたり AJAX が実現している方法です。ユーザーが要求を行うたびに新しいページを読み込むのではなく、ブラウザがあらかじめ非同期にデータを要求します。この要求を行うコードには、通常、JavaScript が使われ、データには多くの場合 (常にそうとは限りませんが) XML 形式が使われます。非同期 (Asynchronous)、JavaScript、XML というこれら 3 つの特徴から、AJAX という名前が付けられました。

AJAX の基盤となる中核のテクノロジが最初に登場したのは 1999 年にリリースされた Internet Explorer 5 ですが、この方法が普及するまでには数年を要しました。しかし、現在では、大半の新しい Web ブラウザアプリケーションでは、AJAX が使用されるようになっています。この傾向に応じて、 .NET Framework 3.5 には、ASP.NET AJAX というテクノロジが取り入れられています。これは本来の ASP.NET の拡張機能であり、AJAX アプリケーションの開発を支援することを目的としています。

LINQ (統合言語クエリ) : 多様なデータへの統一されたアクセス

ほとんどのアプリケーションは、なんらかの形でデータを操作します。こうしたデータは、リレーショナルデータベースのテーブル、XML ドキュメント、メモリ内に保持されるオブジェクトなど、さまざまな形で表現されます。従来、これらのデータにアクセスするには、それぞれ異なる方法を使用する必要があります。たとえば、一般にはリレーショナルデータの操作には SQL を、XML データの場合は XQuery を、メモリ内のデータであればカスタムコードを使用します。しかし、いずれも目的は同じで情報にアクセスすることです。どの場合でも共通して利用できる方法はないのでしょうか。

これが、.NET Framework 3.5 が提供する新しいテクノロジである LINQ (統合言語クエリ) の目指すところです。LINQ は、データの種類ごとに専用の言語や異なる方法を必要とすることなく、共通の方法で多様な情報へのアクセスを実現する一連の C# と VB の拡張を追加します。このテクノロジは、オブジェクトとリレーショナル間のマッピングをはじめ、多くの領域に対応しています。つまり、データを操作する .NET Framework アプリケーションの開発と保守をより容易に、効率よく行うためのテクノロジです。

Windows Communication Foundation: サービス指向アプリケーションのサポート.NET Framework は当初から、さまざまな通信テクノロジを提供しています。たとえば、次のようなテクノロジがあります。

ASP.NET Web サービス (通称 ASMX) : 相互運用可能な SOAP ベースの通信を提供

.NET リモート処理 : .NET アプリケーション間の通信に特化

エンタープライズサービス : スケーラブルなトランザクションアプリケーションのサポートを提供

System.Messaging : Microsoft メッセージキュー (MSMQ) によるメッセージキューイングをサポート

5


Web Services Enhancements (WSE) : WS-Security などの最近の規格をサポートする ASP.NET Web サービスの拡張

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

これこそ、まさに Windows Communication Foundation (WCF) によって解決される点です。開発者は通信の種類ごとに異なるアプリケーションプログラミングインターフェイスを介して種々のテクノロジを扱う代わりに、WCF が提供する共通の API を介し、一貫した方法で開発を行えます。WCF は本来 .NET Framework 3.0 の一部としてリリースされたもので、現在ではマイクロソフトが推奨する通信テクノロジとなっています。上記のテクノロジのいずれかを使用している大半のアプリケーションでは代わりに WCF を通信に使用することをお勧めします。

以下の図からわかるように、WCF の基本的なモデルは単純です。クライアントがサービスにアクセスし、必要な操作が起動されます。WCF は、特に決められたホストを必要としないため、どのようなホストプロセス内でも、この通信テクノロジを自由に使用できます。

WCF は、現代のコンピューティングで欠かせない SOAP による相互運用可能な通信を強力にサポートします。これには、 WS-Security、WS-ReliableMessaging、WS-AtomicTransaction など、一部の WS-* 仕様のサポートも含まれます。とはいえ、SOAP は WCF の必要条件ではありません。したがって、最適化されたバイナリプロトコル、MSMQ を使用するメッセージキューイング、直接 HTTP を基盤としているより単純な REST ベースの通信など、他の方法を使用することもできます。

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

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

ワークフローとは単純な概念で、ある決まった順序で実行される一連のステップのことです。ある人は、どのアプリケーションもなんらかのプロセスを実行するので、アプリケーションにはワークフローが実装されていると考えるかもしれません。しかし、C#、Visual Basic などのプログラミング言語でアプリケーションを作成するという従

6


来のアプローチでは、プロセスのステップがコード内に覆い隠されてしまいます。この方法でもアプリケーションは機能しますが、プロセス自体がプログラムのロジック内に埋もれてしまい、プロセスの作成や変更が困難になります。

ワークフローテクノロジを使用してプロセスロジックを実装すると、この問題を解決できます。ロジックを通常のコードに絡める代わりに、プロセスの各ステップを明示的に定義し、その後 "ワークフローエンジン" で実行します。これにより、プロセス自体を実装できます。Windows Workflow Foundation (WF) という形で Windows 向けに共通のワークフローテクノロジを用意することで、どのワークフローベースアプリケーションにも共通のビルド基盤を提供します。.NET Framework 3.0 での導入以来、WF はマイクロソフトが提供するソフトウェア (Windows SharePoint Services など) でも、他の組織が作成するアプリケーションでも使用されてきています。

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

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

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

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

7


これらの操作すべては、アプリケーションがスタンドアロンデスクトップクライアントまたは Web ブラウザのどちらで実行されていても行える必要があります。

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

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

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

8


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

Windows 上で直接実行されるスタンドアロン WPF アプリケーションを作成する場合、開発者は WPF のすべての機能を使用できます。一方、Web ブラウザ内で実行されるクライアントを作成する場合、開発者は XBAP と呼ばれる "XAML ブラウザアプリケーション" をビルドできます。XBAP がスタンドアロン WPF アプリケーションと同

9


じ基盤上にビルドされることで、ダウンロードされるブラウザアプリケーション内で、同じスタイルのユーザーインターフェイスを表示できます。また、両方のアプリケーションで同じコードを使用できるので、開発者はデスクトップクライアントとブラウザクライアントで異なるテクノロジスキルを使用する必要がなくなります。インターネットからダウンロードされる XBAP は、この種のリッチインターネットアプリケーションと同様にセキュリティが確保されるサンドボックス内で実行されるため、このアプリケーションで行える機能は限られます。それでも、スタンドアロン WPF アプリケーションで使用できるユーザーインターフェイス機能の大部分を XBAP でも使用できます。

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

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

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

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

さまざまなサイトで設定するユーザー名やパスワードをユーザーがすべて記憶することは困難である。この記憶の問題を避けるため、多くのユーザーが異なるサイトで同じユーザー名とパスワードを使用しており、結果としてセキュリティリスクが増大しています。

ユーザー名、パスワード、およびその他の個人情報が、フィッシング詐欺によって盗まれるおそれがある。詐欺メールを送りつけることで、フィッシング詐欺犯は本物と見分けがつかない Web サイト (たとえば被害者の銀行のサイト) にログインするよう被害者を誘導します。そのサイトは実際にはフィッシング詐欺犯によって制御されており、被害者が一度ユーザー名とパスワードを入力すると、詐欺犯はそれらの情報を用いて本人になりすまし、実際のサイトにアクセスできるようになります。

10


このような重大なリスクを抑えるには、デジタル ID を管理するための新しいアプローチが必要です。そのアプローチで重要な部分を占めるのが、.NET Framework 3.0 で導入された Windows CardSpace です。ユーザーが自分のデジタル ID を管理できるように、CardSpace では各 ID が固有の "情報カード" として表されます。Web サイトが CardSpace ログインを受け付けると、ログインしようとするユーザーに、下図のような CardSpace 選択画面が表示されます。ユーザーはカードを選択することで、そのサイトへのアクセスに使用されるデジタル ID を選択できます。異なるカードには別の情報を含めることもでき、各サイトで必要とされる正確な ID を管理できます。

これらのカードによって表される ID は、1 つ以上の "ID プロバイダ" によって作成されます。どのような組織でも ID プロバイダを提供できますし、CardSpace 自体にも、クライアントコンピュータで実行する自己発行型 ID プロバイダが含まれています。ユーザーはこのプロバイダを使用して、パスワードに頼らない認証用 ID を作成できます。Web サイトは、通常のパスワードベースの認証に代わって、このような自己発行型 CardSpace ID を使用できます。これにより、パスワードに関連する問題を減らすことができます。

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

11


の中心的な役割を果たします。また、 ID に関する根本的な問題に取り組むことで、.NET Framework 3.5 における重要な部分を担います。

進化の総括 : .NET Framework 3.5 と旧バージョン

.NET Framework 3.5 は、マイクロソフトの主力開発プラットフォームの最新の進化形です。いずれのリリースも、その前身を基盤に開発されています。この最新リリースは、.NET Framework 3.0 のスーパーセットであり、資産の継承に問題が生じるような変更は加えられていません。同様に、.NET Framework 3.0 は 2.0 リリースのスーパーセットであり、このときも資産の継承に問題が生じるような変更は加えられませんでした。この進化の過程がわかるように、次の図に 3.0 および 3.5 リリースで追加されている機能を示します。

当初から .NET Framework の構成要素はすべて、共通言語ランタイム (CLR) に依存しています。.NET Framework クラスライブラリと呼ばれる大規模なクラス群が、CLR 上に構築されています。このライブラリは、図に示すようにリリースのたびに拡張されてきています。 .NET Framework 2.0 では、基本クラスライブラリ、ASP.NET 、 ADO.NET など、現代の開発環境の基礎が形成されました。 .NET Framework 3.0 ではこれらを変更してはいませんが、 WCF、WF、WPF、および Windows CardSpace という 4 つの重要なテクノロジが追加されました。

.NET Framework 3.5 での変更は、3.0 リリースの一部に影響します。たとえばASP.NET には AJAX サポートが追加され、LINQ が ADO.NET で使用できるようになっています。基本クラスライブラリには、型サポートセット (一意の要素の順序なしコレクション) や強化された暗号化サポートの追加など、さまざまな追加が施されています。後半で概要を説明しますが、WCF、WF、および WPF もそれぞれ強化されています。.NET Framework が実行されるオペレーティングシステムの種類も変更されています。 .NET Framework 3.5 を実行できるのは、 Windows Server 2008、Windows Server 2003、Windows Vista、および Windows XP のみです。

各リリースはその前のリリースを基盤としているため、以前のリリースでビルドされたアプリケーションを再びテストする必要性が、最小限に抑えられます。また、これら 3 バージョンは同時実行が可能であるため、必要であれば古いバージョンの .NET

12


Framework でアプリケーションを実行することもできます。Visual Studio 2008 では、.NET Framework の特定のバージョンを指定してプロジェクトを作成することもできます。このような形でビルドされたアプリケーションは、指定されたバージョン用のバイナリのみを使用します。開発時には、そのバージョンで有効な Visual Studio の機能と .NET Framework の機能しか提供されません。たとえば、 .NET Framework 2.0 用のアプリケーションを新たにビルドする場合、この古いバージョンの .NET Framework しか利用できないかのように環境を整えることができます。

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

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

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

13


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

顧客は、Web 経由で保険加入の申し込みを行うこともできます。これを可能にするため、アプリケーションは ASP.NET AJAX を使用して Web ブラウザと通信し、顧客に応答性の高いユーザーインターフェイスを提供しています。図の左下に示すように、Web ブラウザからこのアプリケーションにアクセスする顧客は、CardSpace を使用して目的の ID を選択できます。

インターネット経由でこのアプリケーションにアクセスする保険代理店には、顧客用のインターフェイスよりも機能的なインターフェイスが必要になるでしょう。この場合、保険代理店では AJAX インターフェイスではなく、XBAP を使用できます。これにより、図の下中央に示すように、代理店はコールセンターの WPF デスクトップアプリケーションが提供するユーザーインターフェイス機能の大部分を使用できるようになります。どちらも同じ基盤上にビルドされているため、アプリケーション開発者は両方の種類のクライアントに同じコードを再利用できます。また、他のクライアントコンピュータと同様に、代理店も CardSpace を使用し、目的の ID でアプリケーションにログインできます。

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

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

.NET Framework 3.5 について : テクノロジ

.NET Framework 3.5 で何ができるのかを実感するにあたって、 .NET Framework 3.5 のコンポーネントの理解を深めることは非常に効果的です。ここでは、前述した各テクノロジの簡単なチュートリアルを提供します。

14


ASP.NET AJAX

ASP.NET は、Web ベースのアプリケーションの開発テクノロジとして、現在最もよく利用されているテクノロジの 1 つです。このようなアプリケーションを設計する場合、AJAX が一般的に使用されるようになってきています。この 2 つの事実からASP.NET AJAX は、.NET Framework 3.5 のテクノロジのうち最も広く使用されるテクノロジとなることが予想されます。下の図は、このテクノロジの 2 つの主要コンポーネントを示しています。

この図からわかるように、ASP.NET アプリケーションでは ASP.NET 2.0 AJAX Extensions を使用できます。これは、Web ブラウザのコードと通信するためのサーバー側のコントロールセットを提供します。このコントロールのうち最も重要なのは UpdatePanel です。これは、ページ全体を再表示するのではなく、ユーザー側に表示されているページの一部のみを更新できるようにするコントロールです。ASP.NET 2.0 AJAX Extensions には、アプリケーションが提供する情報にアクセスするために、ブラウザコードから起動できる Web サービスも用意しています。

クライアント向けには、ASP.NET AJAX は Microsoft AJAX Library を用意しています。このライブラリは、クライアントスクリプトを作成するためのフレームワークを実装しており、Internet Explorer、Firefox、Opera、および Safari で実行できます。すべての AJAX 実装と同様に、このクライアントコードでは、XMLHttpRequest と呼ばれる Web ブラウザから提供されるオブジェクトを使用できます。スクリプトはこのオブジェクト内のメソッドを呼び出すことで、ASP.NET、または PHP など他のテクノロジを使用してビルドされたアプリケーションから、HTTP 経由でデータを要求できます。この要求は非同期に行えるため、応答を待機している間にユーザーがブロックされることなく、データを取得できます。返されたデータは、ドキュメントオブジェクトモデル (DOM) を使用して、XML 形式のデータとしてアクセスできます。XML と組み合わせることで、ASP.NET AJAX では、JavaScript Object Notation (JSON) を使用して表現されたデータも交換できます。

AJAX スタイルの Web アプリケーションは、JSON が登場した 1999 年の時点では、すばらしい考え方でした。このテクノロジが主流になるまでは数年を要しましたが、AJAX アプリケーションは現在では標準になっています。マイクロソフトが ASP.NET AJAX の .NET Framework 3.5 への実装を決めたことで、この有用なテクノロジの普及が促進されることは疑う余地がありません。

統合言語クエリ (LINQ)

多様なデータへのアクセスに共通して使用できるテクノロジの開発は、容易なことではありません。また、これを、複雑で扱いにくいテクノロジとすることなく、包括的

15


な開発テクノロジとすることはさらに困難です。この課題に対処するため、 LINQ では、データ操作に共通する非常に使い慣れた構文を使用しています。

以下は、C# で表現したデータ読み取りの簡単な LINQ クエリです。

var exampleQuery = from s in Studentswhere s.Gender == "M"select s.Name

このクエリでは、変数 exampleQuery に文字列の一覧として格納された、すべての男子学生の名前が返されます。この一覧を出力するプログラムは、次のようになります。

foreach (string name in exampleQuery) {Console.WriteLine(name);

}

このクエリの構文は、現在のリレーショナルデータアクセスの標準言語である SQL を連想させます。SQL は広く使用されている言語で、多くの開発者が理解しているため、これはもっともなことです。それでも、SQL に似ているとはいえ、上記の LINQ クエリは埋め込み SQL ステートメントではないことを理解しておく必要があります。これは純粋な C# であり、C# 言語自体の一部です。つまり、このクエリでは他のプログラム変数を使用したり、デバッガからアクセスしたりすることができます。このテクノロジは、多様なデータに対するクエリのステートメントがプログラミング言語に直接統合されているため、“統合言語クエリ (LINQ)” と呼ばれます。

また、SQL と似ているにも関わらず、このサンプルクエリでアクセスできるのは、リレーショナルデータだけではありません。実際、.NET Framework 3.5 にはいくつか異なる種類の LINQ があります。これらはいずれもクエリに対して同じ基本構文を使用します。具体的には、次のような種類があります。

LINQ to ADO.NET: オブジェクト/リレーショナル (O/R) マッピングを提供します。この LINQ には、2 つのオプションがあります。1 つは LINQ to SQL で、上記のようなクエリを SQL クエリに変換後、SQL Server データベースのテーブルに対してクエリを発行します。2 つ目は LINQ to DataSet で、上記のようなクエリを ADO.NET によって返されたデータセットの内容に対して実行します。

LINQ to Objects: オブジェクト階層など、メモリ内データ構造のコレクションに対するクエリを実現します。上記のクエリは、このようなデータに対しても発行できます。SQL に似ていますが、テーブル内のデータ以外のデータへのアクセスも可能です。

LINQ to XML: XML データのクエリを可能にします。この LINQ では、XML とプログラミング言語間のマッピング特有の要件を反映してやや異なる構文を使用しますが、LINQ クエリの基本構造は変わりません。

SQL と同様、LINQ でもその他のクエリ演算子が定義されています。結果の並べ替え方法を指定する OrderBy、選択したデータをグループにまとめる GroupBy、Sum の

16


ような算術演算子などがあります。また、これらも基本的に各種 LINQ で使用できます。LINQ to SQL オプションだけのものではありません。

LINQ の開発者が目指したのは、.NET アプリケーション用の O/R マッピングや、多様なデータ操作に共通して使用できる構文の実現、そのような構文のプログラミング言語への直接的な統合など、いくつかあります。本書で取り上げている他のすべてのテクノロジと同様に、Visual Studio 2008 と .NET Framework 3.5 を利用した開発を支援することを目的としています。

Windows Communication Foundation

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

サービスとクライアント

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

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

[OperationContract] bool CheckStatus(int applicationNumber);

[OperationContract] bool Cancel(int applicationNumber);}

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

17


と、WCF は自動的に OperationContract でマークされたメソッドを、このサービスのクライアントからアクセスできるようにします。

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

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

"アドレス" は、このエンドポイントが存在する場所を示します。この図に示すように、アドレスは URL で表されます。

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

"コントラクト" は、このエンドポイントを使用して呼び出し可能な操作を示します。コントラクトは、これらの操作を定義するインターフェイスの名前だけで識別できます。この場合は IInsurance になります。

18


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

REST および RSS/ATOM のサポート

.NET Framework 3.0 で初めてリリースされた時点では、WCF の Web サービスサポートは、SOAP に主眼を置いていました。しかし、状況によっては、別の Web サービステクノロジの方が好ましい場合があります。 Representational State Transfer (REST) と呼ばれるこのテクノロジは、Web 自体のテクノロジの上に直接構築されています。SOAP の開発者が行ったように新しいプロトコルを定義するのではなく、REST では GET、POST など、HTTP に組み込まれている操作を利用しています。SOAP で通常行われているように、XML 内で定義するパラメータによってアクセスする情報を指定するのではなく、REST ではすべて URL によって指定されることを想定しています。

このテクノロジをサポートするために、.NET Framework 3.5 の WCF では、HTTP 経由で直接情報を送信する新しいバインディング WebHttpBinding が追加されています。また、2 つの新しい属性も追加されています。以下に、例を示します。

[ServiceContract]interface IAccount{ [OperationContract] [WebGet] int GetBalance(string account);

[OperationContract] [WebInvoke] int UpdateBalance(string account, int amount);}

この単純なインターフェイスでは、口座残高の読み取りと更新用に RESTful サービスを公開します。GetBalance への呼び出しが直接 HTTP GET 経由で渡されることを示すため、この操作には WebGet 属性が指定されています。同様に、UpdateBalance 操作には WebInvoke 属性が指定されているため、この操作は HTTP POST 経由で渡されます (この属性が指定されている操作では、PUT や DELETE などの HTTP 操作を使用するように指定することもできます)。SOAP や WS-* プロトコルを使用するのではなく、このより簡潔な RESTful スタイルは、従来からある Web ベース通信の基盤テクノロジに準じています。適しているテクノロジは状況に応じて変化するため、.NET Framework 3.5 の WCF では両方をサポートしています。

RSS および ATOM によって定義された XML 形式を送信できることは、WCF の登場以降、ますます重要性が高まっています。このため、.NET Framework 3.5 の WCF には、これら 2 つの形式のサポートが組み込まれています。いずれかの形式の情報は、どの WCF バインディングでも送信できますが、新しい WebHttpBinding が最も一般的に使用されると考えられます。WCF が提供しているフォーマッタを使用すると、.NET Framework 3.5 アプリケーションは RSS または ATOM フィードを作成や利用できるので、ますます重要性を増しているこのようなコンテンツを簡単に処理できます。

19


通信オプション

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

また、WCF には他のオプションもあります。これらのオプションを次に示します。

応答がない呼び出し。属性 OneWay でマークされる通信は、イベントを送る場合や他の一方向のやり取りを行う場合に便利です。

非同期メッセージベースの通信。MSMQ により直接送受信を行います。

SOAP メッセージの明示的な操作。SOAP ヘッダーに要素を直接挿入する機能を含みます。

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

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

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

通信の信頼性を確保することも、多くのアプリケーションにとってきわめて重要ですHTTP 経由で SOAP を送信する従来の Web サービスアプローチで十分な場合はbasicHttpBinding を使用できます。しかし、一般に広く使用されているとはいえ、多くの場合 BasicHttpBinding では十分にニーズを満たすことができません。たとえば、1 つ以上の SOAP 仲介者を経由するメッセージでエンドツーエンドの信頼性を確保しようとする場合、この単純なアプローチに頼ることはできません。 WCF は、このような問題に対処するために WS-ReliableMessaging を実装しています。

20


WsHttpBinding など、このオプションをサポートするバインディングを選択するだけで、開発者は相互運用可能な信頼性の高いメッセージ送受信を行うことができます。

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

ツールのサポート

優れたツールは、あらゆる開発者の負担を軽くします。このため、 .NET Framework 3.5 の WCF では、次のような Visual Studio 2008 の機能をサポートしています。

プロジェクトの種類 : WCF アプリケーションの開発に着手する際に役立ちます。次のものをビルドするためのプロジェクトがあります。

WCF サービスをホストする Web サイトまたは Web アプリケーション

WCF サービスのライブラリ実装

RSS または ATOM を使用した配信フィードを公開する WCF アプリケーション

AJAX クライアントが使用するようデザインされた WCF サービス。このサービスは、JavaScript Object Notation (JSON) (このバインディングが提供するエンコードの 1 つ) を指定して WebHttpBinding を使用するように自動的に構成されます。

WCF Autohost : ライブラリベースの WCF サービスを自動的にホストできます。

サービス構成エディタ : WCF 構成ファイルの作成と変更を支援するツール

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

先に述べたように、WCF は、マイクロソフトでこれまで使用されてきた分散アプリケーションの作成に関連するテクノロジに取って代わるものです。これまで ASP.NET Web サービス、.NET リモート処理、エンタープライズサービス、または WSE を使用してビルドされていたアプリケーションのほとんどは、今後 WCF を基にビルドされます。WCF アプリケーションは、ASP.NET Web サービスアプリケーション (どちらも標準の SOAP をサポートしている)、およびエンタープライズサービス、MSMQ、WSE のバージョン 3.0 を基にビルドされたアプリケーションと相互運用できます。WCF に取って代わられる従来のテクノロジが新しい .NET Framework 3.5 アプリケーションで積極的に使用されることはありませんが、それらのテクノロジは依然として .NET Framework 3.0 の一部を構成しており、すべて従来どおりにサ

21


ポートされます。これらの旧テクノロジを使用してビルドされたアプリケーションは正常に実行されます。.NET Framework 3.5 のインストールや使用により、既存のコードが機能しなくなることはありません。

Windows Workflow Foundation

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

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

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

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

22


ワークフロー

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

定義した順序でアクティビティを実行するシーケンシャルワークフロー。従来のフローチャートのように、シーケンシャルワークフローには、分岐、ループなどの制御構造を含めることができます。ただし、既定では、アクティビティが 1 つずつ順番に実行されます。

従来の有限状態マシンを実装するステートマシンワークフロー。ステートマシンと同様に、ある時点でどのアクティビティが実行されるかは、現在の状態と受け取ったイベントの組み合わせによって決まります。

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

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

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

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

23


IfElse: 条件が満たされているかどうかに基づき、複数の候補パスに含まれるアクティビティを実行します。

While: 条件が真である間、1 つ以上のアクティビティを繰り返し実行します。

Sequence: グループ化されたアクティビティを、定義された順序で一度に 1 つずつ実行します。

Parallel: 複数のアクティビティグループを並列に実行します。

Code: 定義済みの一連のコードを実行します。

Listen: 特定のイベントを受け取るまで待機し、そのイベントを受け取ったら 1 つ以上のアクティビティを実行します。

InvokeWebService: ASP.NET Web サービスを使用して Web サービスを呼び出します。

State: ワークフローのステートマシンの状態を表します。

EventDriven: 特定の状態にあり、かつ特定のイベントを受け取る場合に実行される、1 つ以上のアクティビティを含む推移を定義します。

Policy: WF 提供のルールエンジンを使用して、ビジネスルールを実行できます。

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

Windows Workflow Foundation のツール : ワークフローデザイナ

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

24


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

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

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

保存 : なんらかのイベントを待機しているためにブロックされたワークフローは、このサービスを使用して、そのインメモリ状態を自動的にディスクへ格納します。イベントが発生すると、このサービスは自動的にワークフローの状態を再度読み込み、実行を再開します。このサービスは、ユーザーが関

25


係するワークフローで特に役立ちます。ユーザーからの応答は、数時間、数日、場合によってはそれ以上かかる場合があるためです。

追跡 : ワークフロー内のアクティビティは、そのアクティビティが実装するプロセスの実行を明確に区分します。WF の追跡サービスを使用すると、開発者はワークフローの実行に関する情報を自動的にデータベースに書き込むことができます。たとえば、開発者はワークフローの開始時刻と終了時刻、各アクティビティの開始時刻と終了時刻、およびその他の情報を追跡できます。

ワークフロー対応サービス

WF と WCF は、組み合わせて使用すべきことは明らかです。ワークフローは通常サービスを呼び出す必要があり、ワークフローと共にサービスを実装することが適している場合は多くあります。.NET Framework 3.0 で提供された WF の初期リリースでは、この 2 つのテクノロジを組み合わせることは特に簡単ではありませんでしたが、.NET Framework 3.5 ではこの状況が大幅に改善されています。このバージョンでは、簡単に WF と WCF を組み合わせてワークフロー対応のサービスを作成できます。

この組み合わせの実現は、2 つの新しい WF アクティビティに依存しています。

Send: WCF を使用して要求を送信し、応答を待機します。呼び出す操作や、その操作を検索できるエンドポイントを指定することができます。

Receive: WCF を使用して着信する要求を受信し、応答を送信します。着信する要求を受け付ける操作の名前を指定するだけです。

この 2 つのアクティビティは、他のアクティビティと同様に WF ワークフローにドラッグアンドドロップでき、その後、必要に応じて構成できます。これらは、 WF と WCF を有用な形で組み合わせることを目的としています。

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

新しいアプローチの導入が、既存のアプローチに与える影響は避けられません。特に WF による影響が顕著に現れているのは、Windows SharePoint Services、Microsoft Office 2007 System、および BizTalk Server です。

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

BizTalk Server を使い慣れたユーザーなら、オーケストレーション機能と WF 提供の機能が似ていることに気付くはずです。実際、BizTalk Server 2006 R2 の次期メジャーリリースから、既存のオーケストレーション機能が WF に置き換えられる予定で

26


す。その際、既存のオーケストレーションを WF ワークフローに移行するためのツールも提供されます。

WF は Windows の標準ワークフローテクノロジであるため、他のマイクロソフト製品やテクノロジでも採用されるでしょう。WF は、独立系ソフトウェアベンダ (ISV) によって作成される多くのアプリケーションでも定着するでしょう。すべての Windows アプリケーションをワークフローとして構築する必要はありませんが、ワークフローとして構築されるアプリケーション開発において、WF は役に立ちます。

Windows Presentation Foundation

サービス指向の通信とワークフローベースのロジックは、どちらも現代のアプリケーションにとって重要です。しかし、多くのユーザーが注目するのは目に映るもの、つまりユーザーインターフェイスです。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 では、Button、TextBox、ComboBox、Menu などのコントロールが提供されています。これらのコントロールがどのように配置されるかは、選択されるパネルのタイプによって異なります。たとえば、Grid では指定されたグリッド上にコントロールが配置されますが、Canvas では開発者がパネルの境界内の任意の場所にコントロールを配置できます。GUI と同様、ユーザーによって生成されるイベントは、アプリケーションのさまざまなコントロールやクラスによって捕捉および処理されます。また、コントロールのグループに対してスタイルやテンプレートを適用することもできます。これは、アプリケーションのインターフェイスに統一感を与えることのできる簡単な方法です。

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

27


ドキュメント : WPF アプリケーションでは、XAML の FixedDocument タグを使用して XPS ドキュメントを表示できます。また、FlowDocument タグを使用してフロードキュメントを表示することもできます。フロードキュメントは、従来の画面上のドキュメントと同じように動作させることができます。この場合、ユーザーはスクロールしてドキュメントの内容を表示します。一方、このタグでさまざまな属性を設定して、環境に対する高度な適応性を備えたドキュメントを作成することもできます。たとえば、読者が何度もスクロールを行わなくて済むように、ドキュメントを 1 ページずつ表示することができます。この機能が目的とするのは、画面上のドキュメントをできる限り読みやすくすることです。

グラフィックス : WPF では、2 次元や 3 次元のベクタグラフィックスの作成もサポートされています。2D グラフィックスでは、図形、ブラシ、ペンなどの標準の抽象クラスが提供されています。3D グラフィックスでは、モデルを定義して、光源やカメラ位置の情報を割り当てることができます。グラフィックスの処理を GDI+ に任せていた Windows フォームなどの従来のテクノロジとは異なり、WPF のグラフィックスは他の要素とは分離されていません。したがって、開発者がグラフィックスの作成に関する概念を別個に習得する必要もなくなります。グラフィックスに使用される XAML 要素は、ユーザーインターフェイスで使用される他の XAML 要素と簡単に組み合わせることができます。

画像 : XAML の Image タグを使用すると、JPEG や GIF など多様な形式の画像を WPF アプリケーションに表示できます。

メディア : WPF アプリケーションでは MediaElement タグを使用して、WMV、AVI、MPEG など、さまざまな形式のビデオやオーディオを表示できます。

アニメーション : WPF では、ユーザーインターフェイスのほとんどの場所にアニメーションに対するサポートが組み込まれています。たとえば、伸び縮みする円や滑らかに大きさを変えるボタンなどのアニメーションを表示できます。また、タイムラインを含むストーリーボードを定義し、一連のアニメーションを連動して動かすこともできます。

データバインディング : 多くの WPF アプリケーションでデータが表示されることを考えると、データをユーザーインターフェイス要素にマッピングするための自動サポートは便利な機能といえます。WPF では、オブジェクトや他のソースに格納されている情報に対してこのようなデータバインディングを実行できます。

Windows Presentation Foundation の使用

WPF が提供する多様なユーザーインターフェイス機能により、開発者やデザイナは魅力的なユーザーインターフェイスを作成することができます。しかし、クライアントアプリケーションのインターフェイスがいくら魅力的であっても、展開に伴う問題のために、その使用をためらう企業があります。クライアントのアップグレードを実行するのに、アプリケーションがインストールされているすべてのデスクトップ

28


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

ClickOnce を使用して展開されたスタンドアロン WPF アプリケーションは、多くの場合最適な選択肢となります。または、XBAP を直接ブラウザにダウンロードすることもできます。このアプリケーションは、ユーザーに WPF ベースのユーザーインターフェイスを提供することができます。悪意のある開発者からユーザーを保護するため、インターネットからダウンロードされるすべての XBAP は部分的に信頼されたサンドボックス内で実行されます。.NET Framework が提供するコードアクセスセキュリティに基づくこのサンドボックスは、XBAP の機能を制限します。サンドボックスによって制限が課されるとはいえ、XBAP は WPF の大半の機能を使用することができます。これには、2D および 3D のグラフィックス、アニメーション、画面上のドキュメント、イメージ、ビデオなどが含まれます。

前に述べたとおり、WPF アプリケーションでは、XAML の FlowDocument 要素を使用して環境に適応するドキュメントを表示することができます。ただし、環境によって外観が変わるドキュメントが常に適切な選択肢であるとは限りません。場合によっては、画面上でもプリンタ上でも常に外観が変化しない固定書式ドキュメントの方が適切であることがあります。WPF の XPS ドキュメントはこの問題を解決します。XAML のサブセットによって定義された XPS ドキュメントは、XPS リーダーを備えたシステムで読み取ることができます。このドキュメントによって Windows に追加される新しい印刷書式では、複雑なグラフィックスも忠実に再現して印刷できます。

Windows Presentation Foundation のツール

WPF ユーザーインターフェイスは、基本的な機能を備えたテキストエディタでコードまたは XAML を使用して直接作成することができます。しかし、より洗練されたツールを求める人々のために、Visual Studio 2008 では WPF デザイナを用意しています。このツールを使用することにより、開発者はイメージどおりのユーザーインターフェイスをグラフィカルに作成し、インターフェイスのコードをツールに生成させることができます。

しかし、多くの場合、ユーザーインターフェイスの定義を行う適任者は開発者ではありません。人とのコミュニケーションを専門とするデザイナの方が適しています。しかし、ほとんどのデザイナはコードを記述しないため、WPF デザイナはデザイナにとって効果的なツールではありません。そこで、マイクロソフトでは、デザイナが

29


WPF 環境で効果的に作業できるよう、Expression Blend を開発しました。次の図は、これらのツールがどのように連携するかを示しています。

この図からわかるように、デザイナは、Expression Blend を使用してインターフェイスの外観や操作性の定義、アニメーションの指定などを行います。作成したインターフェイスの XAML コードは、ツールに生成させることができます。開発者は、この XAML を Visual Studio にインポートし、イベントの処理などを行うコードを追加します。Visual Studio と Expression Blend はどちらも同じビルドシステムを使用しているので、開発者とデザイナはそれぞれ使いやすいツールを使用しながら、対話的に 1 つのプロジェクトを進めていくことができます。このツールの目的は、デザインとソフトウェアエンジニアリングという異なる分野の専門家が共同で効率的に作業できるようにすることです。

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

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

Windows フォーム : Windows フォームは .NET Framework がアプリケーション GUI を作成するために当初採用していたアプローチで、現在でも多くのアプリケーションで使用されています。WPF が登場した今でも、基幹業務 (LOB) アプリケーションなど、一部のソフトウェアの新規作成には、Windows フォームが適しています。これらのテクノロジを併用できるよう、Windows フォームのコントロールを WPF アプリケーションでホストし、WPF のコントロールを Windows フォームアプリケーションでホストすることができます。たとえば、Windows フォームアプリケーションが 3D データを視覚化する WPF コントロールをホストしたり、WPF アプリケーションが Windows フォームで提供される DataGridView コントロールを使用したりできます。いくつか制限事項もありますが、両方のテクノロジを使用するアプリケーションの作成には差し支えません。

Silverlight: XBAP によって、ブラウザで実行される WPF ベースのアプリケーションを作成できますが、このようなアプリケーションは .NET Framework がインストールされている Windows システムでしか利用できません。リッチインターネットアプリケーション (RIA) は、通常、あらゆる種類のクライア

30


ントからアクセスできることが必要です。このニーズを満たすため、マイクロソフトは Silverlight を用意しています。この無償でダウンロード提供されているテクノロジは、WPF 機能のサブセットとして、2D グラフィックス、アニメーション、ビデオなどの機能を提供しています。また、Windows、Macintosh、および (Novell を利用して) Linux システム上のさまざまなブラウザから実行できます。

ASP.NET および ASP.NET AJAX : Windows アプリケーションは WPF (または、おそらく Windows フォーム) を、マルチプラットフォーム RIA は Silverlight を、ユーザーインターフェイスに使用できます。また別の選択肢としては、ブラウザで提供されているもののみを使用して、標準ベースの Web インターフェイスを提供することもできます。この場合は、ダウンロードが必要ありません。これこそ、まさに ASP.NET と ASP.NET AJAX が実現していることです。このようなインターフェイスは、ビデオなど、RIA の一部の機能を提供するには適していませんが、特に AJAX を使用する場合は、応答性の高い有効なユーザーエクスペリエンスを提供できます。

Windows CardSpace

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

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

Windows CardSpace と ID メタシステム

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

セキュリティトークンの形式が 1 つに統一される日が来るというのは魅力的な考えですが、現実的ではありません。実際のところ、多様なアプローチは今後も使用され続けるでしょう。財布の中に車の免許証、クレジットカード、飛行機のマイレージカードなど、何枚もの ID カードがあるのと同様、ユーザーは引き続きさまざまな種

31


類のセキュリティトークンによって表されるいくつものデジタル ID を持つことになります。このような現実に対して、単一の ID システムによる普遍的な解決策を示すことは不可能であり、複数のセキュリティトークンは今後も必要になると考えられます。

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

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

ユーザー : 正式にはサブジェクトとも呼ばれます。ユーザーはデジタル ID を所有するエンティティです。

ID プロバイダ : ID プロバイダはユーザーにデジタル ID を提供します。たとえば、仕事で使用するデジタル ID の場合は、雇用企業が ID プロバイダとなり、セキュリティトークンはおそらく Active Directory などのシステムによって発行されます。Amazon で使用するデジタル ID の場合、自分でユーザー名とパスワードを定義するので、ID プロバイダは実質的に自分自身です。デジタル ID が伝達する情報や、それに含まれる情報が正確であることが保証される度合いは、デジタル ID を作成した ID プロバイダによって異なる場合があります。

証明書利用者 : 証明書利用者とは、デジタル ID をなんらかの目的で使用するアプリケーションのことです。証明書利用者は ID (ID のセキュリティトークンに格納されている情報) を頻繁に使用してユーザーを認証し、ユーザーに特定の情報へのアクセスを許可するかどうかなどの承認を行います。証明書利用者は、クレジット番号を入手する、同じユーザーが複数回情報にアクセスしていることを確認するなどの目的で、ID を使用する場合があります。証明書利用者の一般的な例には、銀行、オンライン商店、オークションサイトなどのインターネット Web サイト、また Web サービスを使用して要求を受信するアプリケーションがあります。

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

32


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

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

33


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

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

CardSpace では、セキュリティトークンで使用されている形式やテクノロジを認識する必要がないことに注意してください。メタシステムの目的は、デジタル 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 を証明します。信頼される側の当事者でサポートされていれば、

34


これらのトークンは従来のユーザー名やパスワードと同じ役割を果たすことができます。この方法の利点は、フィッシング詐欺犯が盗むことのできるパスワードがもはや存在しないことです。パスワードの使用機会を削減することで、フィッシングの問題を大幅に縮小できます。

Windows CardSpace と他の Microsoft テクノロジ

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

WCF: CardSpace は、WS-Security や WS-Trust などの Web サービス標準に依存しているため、WCF を使用して通信を行います。WCF アプリケーションの作成者は、特定のバインディングを指定することにより、CardSpace を使用するようアプリケーションを構成することができます。

Active Directory: 現時点ではまだ実現していませんが、Active Directory は将来的にメタシステムの ID プロバイダとして機能する予定です。これが実現されれば、Windows CardSpace が企業内部だけでなく、インターネット上でも使用できるようになるでしょう。

Windows Live ID: マイクロソフトの "Live ID" ID システムは、現在 Windows CardSpace のマネージ ID プロバイダとして機能できます。CardSpace は Live ID (旧称 : Passport) に取って代わるものではありません。これら 2 つは、それぞれ異なる問題に対応しています。

まとめ

.NET Framework 3.5 は、主流である Windows プログラミング環境の最新バージョンです。前のバージョンを基盤としつつ、さらにその機能を拡張し、現代のアプリケーションの作成をサポートすることを目的としています。多様なテクノロジを共通基盤上に構築することにより、マイクロソフトは 1 + 1 が 2 以上になるよう努力を続けており、開発者が一貫した方法で .NET Framework 3.5 のさまざまなテクノロジを用いてアプリケーションを作成できるよう支援しています。

2002 年の初期リリース以来、.NET Framework は、新しい Windows アプリケーション開発において最もよく利用されるプラットフォームへと成長を遂げています。現在各企業、ISV、およびマイクロソフト自体と広範に使用されており、その価値を認められています。Visual Studio 2008 と併用することで、.NET Framework 3.5 はマイクロソフトの現在のアプリケーション開発における最先端のテクノロジを具現化します。

著者について

David Chappell は、カリフォルニア州サンフランシスコにある Chappell & Associates (www.davidchappell.com) の社長です。全世界の IT プロフェッショナルがエンタープライズソフトウェアを理解して使用し、的確な判断を下せるようにするために、講演、執筆、コンサルティングを行っています。

35

introducing the .net framework 3.5download.microsoft.com/download/3/c/7/3c7278ac-ea… · web...

Documents