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

» 2006年03月21日 00時00分公開

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

■3. 相互運用性の確保

　単一プラットフォーム内の再利用であれば、オブジェクトの再利用がまず検討される。しかし現実には、マルチ・プラットフォームでのアプリケーション資産が再利用可能かどうか、つまりは相互運用性が重要となってくる。

　なぜなら、過去の汎用機時代であればまだしも、現在では単一プラットフォームですべての業務アプリケーションを構築している場合の方が少ないからである。汎用機の資産も、UNIXの資産も、Windowsの資産もあるといったマルチ・プラットフォーム環境が現実であり、それらの相互運用性を考慮する場合、現在であればまず検討されるのが、Webサービスによるサービス・インターフェイスの提供である。

　マルチ・プラットフォーム間で相互運用を可能にするには、各アプリケーションの実装言語、実装されているプラットフォーム依存性を排除して、極力標準技術に合わせる方式を取るべきである。その方が相互運用にかかる時間や工数を圧縮できるし、資産の耐用年数をより長くすることが可能となる。そこで、

　　　サービス指向のアプリケーションの実装＝Webサービスによる実装

といった図式が出来てくる。

　本質的には、「サービス指向＝Webサービスでの実装」というわけではないが、現段階でマルチ・プラットフォーム連携を検討する場合、最も有力な選択肢はWebサービス技術であるといえる。相互運用性はサービス指向時代を支える重要な要素なのである。

　しかし、Webサービス技術の発展は日進月歩である。Webサービス関連の仕様も当初のWSDLやSOAPといった基本的なものだけではなく、WS-*と呼ばれるWebサービス拡張仕様群*2まで含めると、その仕様は膨大な量に達する。

*2 WS-*には主に次のようなWebサービス拡張仕様がある。
【メッセージング仕様】WS-Addressing
【セキュリティ】WS-Security、WS-SecureConversation、WS-SecurityPolicy、WS-Trust
【高信頼性】WS-ReliableMessaging
【トランザクション】WS-Coordination、WS-AtomicTransaction
【メタデータ】WS-Policy、WS-PolicyAttachment、WS-MetadataExchange
などなど。これらの仕様の内容については、＠IT Special（広告）の「.NET／Java相互運用の現在・未来第3回」に掲載されている最新Webサービス事情の一覧表が参考になるだろう。

　果たしてこれだけの仕様すべてを開発者は理解する必要があるのだろうか。そうは筆者は考えない。これらすべてを理解しなければWebサービスでの相互運用が不可能だとするならば、そのテクノロジを自由に誰もが使いこなすことは非常に難しく、現実的だとはいえない。本来注力すべき機能要件の実装に集中するためには、むしろこういったプロトコル・ベースの詳細を意識させない通信インフラ技術の提供が必要である。

　さて、相互運用性といえばマルチ・プラットフォーム連携に注目しがちだが、既存のマイクロソフトの分散テクノロジとの相互運用性も確保しておく必要がある。なぜならWCFが出たからといって、既存のアプリケーション資産をすぐにリプレイスすることは困難であるし、現実的ではない。既存資産も有効活用しながら、より高度な要件への対応が必要になったタイミングで、段階的にWCFに切り替えていくことが重要である。

WCFとは

　前置きが長くなってしまったが、以上がWCF登場の背景だ。今後のサービス指向時代を考えた場合、既存分散テクノロジの選択に伴う煩雑さから解放され、開発者のサービス指向へのスムーズなシフトを可能とする、なおかつ既存資産への投資を保護し、ほかのプラットフォームとの相互運用性も確保する通信インフラ技術の提供が必要である。そこで登場したのがWCFなのである。

　仮にWCFが単に続々と標準化されているWS-*仕様（Webサービス拡張仕様）に対応するためだけの目的であれば、開発期間に数年もかからなかっただろう（単にWSEを順次強化していくだけでよかったはずである）。

　実は、マイクロソフトは前述の狙いの下で、次世代のプラットフォームにふさわしい分散アプリケーション・テクノロジにかなり以前から着手しており、今日ようやくWCFとして徐々にその姿を明らかにするまでに至ったのである。

■WCFの特徴

　では、WCFとは何か。一言でいうと、

　　　「サービス指向のアプリケーションを迅速に構築するための
統一プログラミング・モデルであり、実行基盤」

と表現できる。WCFの主な特徴としては以下のとおりである。

●高生産性：

既存の分散テクノロジを統一したプログラミング・モデルの提供
属性およびコンフィグレーションによる容易な開発スタイル
Visual Studio 2005に統合されることによる各種ジェネレータ・ツールなどのサポート

●サービス指向開発：

新たなプログラミング・モデルに準拠することによる疎結合サービスの容易な開発
属性およびコンフィグレーションによる容易な保守と拡張

●相互運用性：

WS-*仕様の広範なサポートによる他プラットフォームとの相互運用性の向上
既存のマイクロソフトの分散テクノロジとの相互運用性の確保（WCFへの移行を強要しない）

■WCFプログラミングの実際

　次のC#のコードは、文字列を返すだけの機能しか持たない単純なクラスを実装したものである。

public class MyClass
{
public string MyOperation1(string myValue1)
{
return "Hello: " + myValue1;
}
}

単純なクラスのソース・コード
このクラスは、文字列を返すメソッドのみを持つ。あまりにも単純なものだが、説明するうえでは単純な方が理解しやすいので、このサンプル・コードを用いる。

　このクラスの持つ機能を利用するには、通常どおり、クラスをインスタンス化して、メソッドを呼び出せばよい。しかし、このような利用形態は、単一のプラットフォーム内（この場合は.NET FrameworkのCLR上）での同一メモリ空間内における実行を前提としている。分散環境、つまりこのクラスとクラスを利用する側がネットワークをまたがって分散することを想定してはいない。

　ではこれをリモート呼び出しに対応させようと考えた場合どうするか。（WCFを使わない）従来の.NET Frameworkプログラミング・モデルでは、まずどの分散テクノロジを採用するか決定する。

　例えばここでASP.NET Webサービスを使用すると決定したとしよう。すると、ASMXファイルのコードビハインドでWebサービスのメソッドを実装して、WebMethod属性（Attribute）をそのメソッドに付与する、といった具合でリモート呼び出しに対応させる。

　それでは、ほかの分散テクノロジを選択した場合はどうだろうか。分散テクノロジとして.NETリモート処理（.NET Remoting）を採用した場合は、MarshalByRefObjectクラスを継承するし、Enterprise ServicesならServicedComponentクラスを継承することになる。このように、それぞれの分散テクノロジに応じた作法で通信用のクラスを実装することになるのだ。

　しかしすでに述べたように、WCFでは、さまざまな分散テクノロジごとに多様なプログラミング・モデルを、単一のプログラミング・モデルに統一してくれる。