特集 .NET Framework 3.0概説（前編） .NET Framework 3.0がソフトウェア開発にもたらす価値とは？ マイクロソフト株式会社　中原 幹雄 2006/11/15
Page1 Page2 Page3 Page4

3. WCF（Windows Communication Foundation）

　WCFは、分散アプリケーション開発のためのコンポーネントと新しいプログラミング・モデルを提供する。

●分散テクノロジの統合と統一プログラミング・モデル

　いままでの.NET Frameworkでは、分散アプリケーション開発におけるさまざまな通信要件に対応するために、通信要件ごとに以下のコンポーネントを提供していた。

コンポーネント	説明
ASMX （ASP.NET Webサービス）	WS-I Basic Profile準拠の、異種プラットフォームとの相互運用性の高いWebサービス
WSE （Web Services Enhancements）	ASMXを拡張し、WS-*と呼ばれるWebサービスのオプショナルな仕様をサポート。主にWS-SecurityやWS-Trustといったセキュリティ関連の機能や、MTOMというバイナリ・データ送信仕様が必要な場合に使用
.NETリモート処理 （.NET Remoting）	.NETアプリケーション間の通信に最適化された、分散オブジェクト通信技術。バイナリ・エンコードによる高速通信やステートフルな状態管理が可能
Enterprise Services	.NETからCOM+サービスの機能を使用する技術。主にMSDTCを使用した分散トランザクションの実装や、DCOMプロトコルでの通信に使用
System.Messaging	.NETアプリケーションから非同期のキュー型通信をサポートするMSMQを使用する技術
既存の.NET分散テクノロジ一覧

　このため、「通信する」という基本的に同じ問題を解決するために、アプリケーションの通信要件ごとに異なるプログラミング・モデルやAPIセットを使い分ける必要があり、学習コストのかかる構造になっていた。また、プログラミング・モデルやAPIが異なるため、安易に通信方式を変更することは難しく、通信要求の変化への追随が難しかった。

　WCFはこのような問題を解決し、1つのプログラミング・モデルによってさまざまな通信要件の分散アプリケーション開発が可能になる。

　またWCFの提供する新しいプログラミング・モデルは、単純に既存のプログラミング・モデルを統合しているだけでなく、いままで実際の開発現場で培われてきた分散アプリケーション開発のベスト・プラクティスを織り込み、SOA（サービス指向アーキテクチャ）システム開発のための通信基盤となるべく提供されている。

　例えば、.NETリモート処理（.NET Remoting）やDCOMなどの分散オブジェクト通信技術では、位置透過なリモート・オブジェクトによってサービスとクライアントの境界を意識しない方式が採用されているが、この方式ではサービスとクライアントが非常に密に結合してしまう、という大きな欠点を持っている。サービス指向の考え方では逆に境界を明確にし、サービスとクライアントを疎に結合させることが重要となる。

　そこでWCFではサービスの境界を明確にするため、エンドポイント（Endpoint）やコントラクト（Contract）、バインディング（Binding）、アドレス（Address）といった、サービス設計の指針がそのままプログラミング・モデルに取り入れられており、従来の分散オブジェクト通信技術とは一線を画している。

エンドポイントとコントラクト、バインディング、アドレス

メッセージの出入り口となるエンドポイントは、コントラクト（Contract）、バインディング（Binding）、アドレス（Address）の3要素で構成されている。 「C」……コントラクトは、サービスとして提供する機能を外部に公開するインターフェイスに当たる。サービス自体を定義するサービス・コントラクト、メッセージを定義するメッセージ・コントラクト、メッセージを構成するデータ要素（エンティティ）を定義するデータ・コントラクトという3つの要素によって構成されている。 「B」……バインディングは、実際に通信で使用するトランスポート、メッセージのエンコード方式、セキュリティやトランザクションなどの品質要件など、通信プロトコルとしての具体的な内容を決定するもので、分散テクノロジの選択そのものを表す。つまり、ASMXや.NET Remotingなどの各分散テクノロジがそれぞれプログラミング・モデルで提供していた通信プロトコルに依存する部分が、このバインディングという要素に集約されている。 「A」……アドレスは、サービスの物理的なアクセス先を表す。具体的にはサービスを公開するURLになる。

　またWCFは、構成ファイルによってエンドポイントが構築可能になっていることや、さまざまな形態のアプリケーションでWCFをホストすることが可能であるなど、柔軟性が高いプログラミング・モデルが採用されている。

　さらに、例えばUDPトランスポートやCSVフォーマットのメッセージなど、WCFがビルトインでサポートしていない要素については、カスタマイズしてWCFに組み込んでいくことが可能になっており、非常に拡張性が高いアーキテクチャに基づいて設計されている。

　なお、クライアント側からサービスを呼び出すためのプロキシは、ASMXと同様にツールによるプロキシ生成がサポートされている。

●品質保証機能の強化

　WCFのバインディングでは、セキュリティ、リライアブル・メッセージング（信頼性の高い通信）や分散トランザクションなどの通信の品質保証機能、いわゆる非機能要件をビルトインでサポートしている（もちろん通信プロトコルによっては品質保証機能を持たないものもあり、これらの品質保証機能をすべてのバインディングでサポートしているわけではない）。

　またこれらの品質保証機能は、（コードや構成ファイルによる）バインディングのプロパティ設定によって容易に使用することが可能である。このため、サービスの開発者はいままで以上にサービスの本質的な設計・実装（＝機能要件）に注力することができる。

●Webサービス仕様への対応強化による相互運用性への取り組み

　異種プラットフォームとの相互運用性としては、Webサービスの最新仕様への対応が挙げられる。

　現在WSEがサポートしているWS-SecurityやWS-Trustなどのセキュリティ関連仕様に加え、トランザクション処理仕様であるWS-AtomicTransationやリライアブル・メッセージングの仕様であるWS-ReliableMessagingなどに対応し、より品質保証レベルの高いWebサービスによる相互運用が可能となる。

　なお、WCFの詳細については、「Windows Communication Foundation概説」を参照いただきたい。

4. WF（Windows Workflow Foundation）

　WFはワークフロー、すなわちビジネス・プロセスの実装という、いままでの.NET Frameworkではサポートされていなかったビジネス・ロジックという領域に対して、新しいコンポーネントとプログラミング・モデルを提供するものだ。

●モデル駆動でのワークフロー開発

　従来の.NETアプリケーションにおける一般的なビジネス・ロジックの実装方法では、ビジネス・プロセス（≒業務の流れ）およびそのビジネス・プロセスの中で実行される詳細レベルのビジネス・ロジックも、すべてC#やVisual Basicのコードで実装する。この場合、ビジネス・プロセスがソース・コード内に埋没してしまい、ビジネス・プロセス部分だけを切り分けることは難しく、保守性が高い実装ができているとはいいにくい状況であった。

　WFはこうした問題を解決すべく、ビジネス・プロセスであるワークフローの実装に特化した新たなフレームワークを提供するものであり、ビジュアル・デザイナによるモデル駆動でのワークフロー開発が可能になる（ビジュアル・デザイナは後述しているWF用のVisual Studio 2005エクステンションで利用可能）。

WFのビジュアル・デザイナ

このビジュアル・デザイン可能なワークフロー・モデルにより、実行可能なモデルによるワークフローの開発と保守が可能になる。また、このワークフロー・モデルはモデル上にブレークポイントを配置してビジュアルにデバッグすることも可能だ。なお、ワークフロー・モデルはXAMLをベースとしたXMLファイルで表現されている。

　WFにより、ビジネス・プロセス部分（WFでは「ワークフロー」と呼ぶ）と、プロセスの内部のビジネス・ロジック（WFでは「アクティビティ」と呼ぶ）が明確に分離し、可読性や保守性の高いソース（ソース・コードとモデル）の管理が可能になる。

●WFのアーキテクチャと機能

　WFは、ワークフロー、アクティビティ、ランタイム・エンジンおよびランタイム・サービスで構成されており、これらの組み合わせによってワークフローを構築していく。

　WFでは、システム・ワークフローおよびヒューマン・ワークフローのどちらにも適応できるよう、次の2種類のワークフロー・モデルがサポートされている。

• シーケンシャル・ワークフロー
• ステートマシン・ワークフロー

　シーケンシャル・ワークフローは、フローチャートやUMLのアクティビティ図に似た、分岐／繰り返しなどを用いて構造的に処理順序を決定可能なプロセスの記述を行うためのワークフロー・モデルである。一方、ステートマシン・ワークフローは、UMLの状態マシン図に似た、イベント駆動的振る舞いをするプロセスの記述を行うためのワークフロー・モデルである。この2つのワークフロー・モデルを使い分けることで、大抵のビジネス・プロセスを表現することが可能だ。

　ワークフロー内の処理はアクティビティと呼ばれる単位で実装し、それをワークフロー内に配置していくことでワークフロー全体を構築していく。このアクティビティはWFがビルトインで提供しているものを使うことも、必要に応じてカスタマイズすることも可能になっている。このため、将来的にはActive XコントロールやWindowsフォームのUIコントロールのように、サードパーティ・ベンダやコミュニティで作られたアクティビティを活用することや、社内でライブラリ化したカスタム・アクティビティを再利用することにより、より迅速にワークフローを構築可能になっていくことが期待できる。

　実行環境については、WFは特定のアプリケーション形態には特化しておらず、ランタイム・エンジンを明示的にプロセスにホスティングして使用する仕組みになっているため、Webアプリケーション、Webサービス、Windowsアプリケーションなど、さまざまな形態のアプリケーション内でWFを利用することが可能だ。また、ランタイム・サービスと呼ばれるトラッキングやステート管理などの機能が提供されており、ワークフロー実行の配管的コードの実装から開発者を解放している。

●WFの製品への活用

　WFはアプリケーション開発のフレームワークとしてだけでなく、マイクロソフトの製品群への取り込みも積極的に進められており、Windows SharePoint Services／SharePoint Portal Serverの後継製品であるMicrosoft Office SharePoint Server 2007のドキュメント・ワークフロー機能や、BizTalk Serverの次期バージョン（BizTalk Server 2006 R2の次のバージョン）のオーケストレーション・エンジンの実装でもWFを採用することがすでに発表されている。

　WFの詳細については、「Windows Workflow Foundation概説」を参照いただきたい。

INDEX
	[特集] .NET Framework 3.0概説（前編）
	.NET Framework 3.0がソフトウェア開発にもたらす価値とは？
	1．.NET Framework 3.0とは何か？
	2．WPF（Windows Presentation Foundation）
	3．WCF（Windows Communication Foundation）、WF（Windows Workflow Foundation）
	4．対応プラットフォームと開発環境
	[特集] .NET Framework 3.0概説（後編）
	.NET Framework 3.0新技術の使い分け指針
	1．WPF活用時の考慮点
	2．WCF活用時の考慮点
	3．WF活用時の考慮点

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）