Windows Communication Foundationとは：Windows Communication Foundation概説（1/4 ページ）

Windows Vistaに搭載予定の新しい通信基盤技術「WCF」の思想やそれがもたらす意味、プログラミン グ・モデルを紹介。

[伊藤英豪，マイクロソフト株式会社]

　

連載目次

・Webサービスの新実装「Indigo」 サービス指向アーキテクチャをメインストリームに

　今回から数回にわたり、Windows Vistaリリースのタイミングで登場する新しいコミュニケーション基盤技術「Windows Communication Foundation」（以降、WCF。以前はIndigoというコードネームで呼ばれていた）に関して、その登場の背景から、主要概念、プログラミング、既存資産の移行などなどを順にご紹介する。

　そもそもマイクロソフトはなぜ新しい通信インフラ技術を提供することになったのか、そこにはどんな狙いがあるのか、さらにはそのテクノロジを採用するメリットは何なのか、また既存の分散アプリケーション・テクノロジからの移行性や相互運用性はどうなっているのか、などWCFに対してはいろいろな疑問を持たれている方が少なくないはずだ。当記事を読み進める中でそういった当初遭遇するさまざまな疑問を解消し、WCFをより知っていただくためのきっかけとなれば幸いである。

　なお、ここに記載した内容は製品出荷前の現段階（2006 February CTP段階）での内容であるため、将来変更される可能性が十分あることをあらかじめご了承いただきたい。

WCF登場の背景

　まずはWCFが登場するに至った背景について、3つの観点から説明する。

■1. 既存分散テクノロジの選択に伴う煩雑さからの解放

　従来のマイクロソフトの分散アプリケーション・テクノロジは、主に以下の表のように分かれている。

分散テクノロジ名	主な特徴
ASMX（ASP.NET Webサービス）	相互運用可能な一般的なWebサービス（Basic Profile 1.1準拠）を構築するためのテクノロジ
WSE（Web Services Enhancements）	WS-*と呼ばれるWebサービスの最新の拡張仕様をできるだけサポートした、相互運用を意識した次世代のWebサービス構築のためのテクノロジ
.NETリモート処理（.NET Remoting）	オブジェクトの位置透過性を供給し、リモート・コールとローカル・コールの違いを隠ぺいしたプログラミングを可能とする、分散オブジェクトを構築するためのテクノロジ
Enterprise Services	分散トランザクションやオブジェクト・プーリングなど、コンポーネントの作成と使用を単純化しながら、アプリケーションのスケーラビリティとフレキシビリティを向上させるための高度な機能を提供するテクノロジ
MSMQ（Microsoft Message Queuing）	直ちに応答を必要としない非同期メッセージ交換のアプリケーションを構築するためのテクノロジ
マイクロソフトの従来の分散アプリケーション・テクノロジ

　それぞれの分散アプリケーション・テクノロジはやみくもに分かれているわけではない。目的とふさわしい対象領域が異なっているため分かれているといえる。しかし、いろんな場面に応じたテクノロジが存在することは便利なようで、実は非常に悩ましいものである。

　アプリケーション開発者（ソリューション・アーキテクトやデベロッパー）は、まず、実装しようとするアプリケーションの要件に応じてふさわしい分散テクノロジを選択することから始める。

　もちろん、自社の開発標準として、選択すべき技術が既定されている場合や適用する拡張フレームワーク製品が既定されている場合もあるため、必ずしも分散テクノロジを選択する必要性に迫られるとは限らない。しかし、システム開発要件（非機能要件、機能要件、納期、開発者のスキルセット、費用、などなど）が対象システムによって大きく異なる今日、単一の開発標準や拡張フレームワークの適用により分散アプリケーション選択といったフェイズが削減できるとはいいにくい。

　以下に一例として「Microsoft patterns & practices : Smart Client Architecture and Design Guide」の第3章で提示されている「クライアントとサーバ間の分散テクノロジの選択肢の一覧表」を掲載してみた。

　Webサービスが唯一の選択肢のように思われがちであるが、例えばイントラネットで相互運用性の考慮は必要なく、メッセージのセキュリティ確保も特に必要なく、高速に通信を実現したいといった要件があった場合、.NETリモート処理といった選択肢も有力視されてくる。つまり、最適な分散テクノロジ選択はそれほど単純ではないのである。

選択肢	利点	欠点	備考
Enterprise Services	・COM+サービスのさまざまな機能を利用可能	・クライアントへの配置が必要	・サーバサイドでのサービス・バウンダリ内での使用 ・または、クライアント・ローカルでの使用
Web サービス	・業界標準 ・拡張可能である ・ベンダ非依存、プラットフォームや言語に非依存 ・セキュア	・冗長 ・.NETリモート処理より遅い性能	・今後の疎結合なアプリケーションのベースとなるプロトコル ・非常に高性能を要求されるニーズには注意を要する
.NETリモート処理（.NET Remoting）	・高速 ・プラグイン可能 ・カスタム・チャネル	・.NET Frameworkが動作することを要求する ・独自である ・セキュリティ・インフラはない	・サーバサイドでのサービス・バウンダリ内での使用 ・または、クライアント・ローカルでの使用
MSMQ	・セキュアで安全な非同期通信が可能、メッセージ配送保証	・クライアントへのインストールが必要	・相互運用性の確保は容易ではない
クライアントとサーバ間の分散テクノロジの選択肢

　ここで問題となるのは、適用する分散アプリケーション・テクノロジによってプログラミング・モデルが大きく異なっていることである。このことは、いったん採用する分散テクノロジを決めて、開発を進めた後で、別の分散テクノロジに移行するような場合に後戻り工数が発生することを意味している。

　この問題を改善するためには、分散テクノロジとプログラミング・モデルの結合度を下げる（つまり、すべての分散テクノロジでプログラミング・モデルを統一する）必要があったのである。

■2. サービス指向へのスムーズな対応

　真に価値のある分散アプリケーションを構築するためには、新しい開発パラダイムも必要となってくる。WCFでは「サービス指向」と呼ばれるパラダイムを取り入れている。サービス指向というと経営戦略やビジネスプロセス管理のいわばビジネス寄りのトップダウンの視点やあるいは実装技術からボトムアップな視点もあり議論が拡散しがちなので、ここではサービス指向に至る経緯を、まずはサービス指向の話に移る前に、まずはプログラムの再利用の観点からシステム開発の歴史を簡単に振り返っておこう。

　汎用機（メインフレーム）全盛のころ、手続き型言語での再利用単位はコードであった。しかし多くの場合、コードのコピー＆ペーストでのメンテナンスは非常に煩雑であったため、「モジュール化してサブルーチンとして呼び出す」といった形で再利用性を向上させていった。

　しかしこの段階においても使用しているサブルーチン・コードの修正により、関連するモジュールの再コンパイルの発生など、コード変更時の保守性には依然として問題があったといえる。

　次にオブジェクト指向が登場し、オブジェクトに機能を隠ぺいして再利用性を向上させ、かつ、保守性の向上も図るアプローチが取られるようになった。

　今日、オブジェクト指向開発は（オブジェクト指向分析・設計が一般的となっているかどうかは別として）、少なくとも実装段階においては非常に一般的な存在になっているといえる。開発者の多くは、C#、Visual Basic（.NET／2005）、Javaといった開発言語に慣れ親しんでおり、オブジェクト指向開発に困惑する状況はいまとなっては減少してきているだろう。

　しかし、オブジェクトの再利用は単一プラットフォーム内での同一メモリ空間内のプログラムの再利用であり、呼び出し粒度も往々にして非常に細かく、分散アプリケーションでオブジェクトに何も手を加えずに再利用性を拡張するといったことは困難であった。そこで分散オブジェクト技術の登場となる。

　分散オブジェクト技術とは、IIOP（Internet Inter-ORB Protocol）、DCOM（Distributed Component Object Model）といった分散オブジェクトを呼び出すためのプロトコルを用いて、ネットワークをまたいだオブジェクトの再利用性を提供するものである。さまざまなベンダがCORBA（Common Object Request Broker Architecture）によって相互運用性を確保しようとしたものの、結果として分散オブジェクトは普及したとはいいにくい。

　現実的には、オブジェクトの依存性がネットワークを越えて影響するためにメンテナンスの独立性が下がってしまったり、IIOPでのネットワーク通信でインターネット・ファイアウォールでは一般に通過できないポートを動的に使用する必要があったりするなど、分散オブジェクト技術がインターネットを基盤として発展するにはいくつかの高いハードルがあったのだ。

●分散アプリケーションへ分散オブジェクト技術を適用する際の問題：

• オブジェクト間の依存性の問題
• ローカル・コールとリモート・コールを意識させない位置透過性が、逆に、独立した保守性を低下させてしまう
• 再利用は単一プラットフォーム内でのみ
• 異プラットフォーム連携＝付加価値創造というよりも、むしろコスト増加要因と見なされ、迅速な開発が困難
• ファイアウォール・フレンドリではない。つまり、インターネットを基盤として利用することが困難

　このように、プラットフォームを越えた連携が必要になるにつれ、分散アプリケーションへのオブジェクト指向の適用に限界が出てきたため、新しいパラダイムとしてサービス指向が登場してきたわけである。

　サービス指向では、プラットフォーム依存性を排除して、ネットワークに分散したサービスを連携させることにより、再利用性を確保することが初めから考慮されている。

　複数のサービスの連携によって業務アプリケーションの構築が可能になってくると、サービスとしてのアプリケーション資産が増えれば増えるほど再利用性も増加し、変動が激しいサービス連携部分を柔軟に構成し直すだけで、より迅速なアプリケーション開発が可能となる。また個々のサービスはそれぞれ独立しているので、それぞれでメンテナンスが可能であり、責任範囲も明確だ。

　なお、サービス指向の定義は十人十色であるため、マイクロソフトが定義するサービス指向の4原則を以下に掲げる。

1. サービスの境界が明確であること
   　従来の分散オブジェクトのようなローカル・コールとリモート・コールの位置透過性を排除し、あえてサービスの境界を明確化し、ネットワークを越えてメッセージ（単なるデータ）が授受されることを意識しておく。
2. サービスが自律していること
   　サービス提供者と消費者はおのおのが自律した存在であり、独立したバージョン管理、展開、メンテナンスが可能であること。つまりおのおのがどのように実装されているかはブラック・ボックスであり、また互いの内部実装に関与する必要もない。
3. クラスではなくスキーマ＆コントラクト*1を共有すること
   　サービス利用者と提供者とが共有するものは、振る舞いを持たない単なるデータである。厳密には交換するメッセージのスキーマと、どんなサービスがあるのかといったコントラクトのみを共有することになる。また、データと振る舞いを保持するオブジェクトは、ローカルでの使用のみとなり、リモート・コールでの使用は行わない。

*1 コントラクト：サービス提供者と消費者の取り決め（契約）。

　4. ポリシーによって互換性を保つこと
　サービス提供者はサービス利用者に対して必要なポリシーを提示し（例えばセキュリティ上X.509の証明書がないとこのサービスは利用できないなど）、サービス利用者はそのポリシーに適合するように振る舞うことでメッセージ交換を行う。

　上記の原則は、いわゆるビジネス面からのサービスの定義というよりも、実装寄りの概念となる。ここでは、サービス提供者とサービス利用者がいかに相互の依存性を排除し、自律した存在として独立にメンテナンス可能とするのか、つまりより疎結合性を高めるための原則が書かれている。

　さて、こういったサービス指向のアプリケーションを意識して構築することは容易なのだろうか。簡単にいえば、先に掲げたサービス指向の4原則に従ったアプリケーションを構築すればよいわけだが、それを容易にするには、従来のオブジェクト指向開発を行っている開発者がすんなりと理解できるプログラミング・モデルでなければならないだろう。

　サービス内部の実装にはオブジェクト指向が、サービスの境界ではサービス指向が、といったことが自然に実現可能なプログラミング・モデルが必要になっているわけである。