SOAP とWSDL(Web Service Description Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。SOAP とWSDL(Web Service Description Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。
本稿では、もっともよく耳にするWS*プロトコルについてまとめるというのが私の意向です。というのも、(Javaと.Netにフォーカスした)Webサービスプラットフォーム、それらの採用と準備の度合い、.Netでの特定の統合シナリオのための適用性と共に、実際の実装という点で現在利用するであろう最も関連性のある標準を重視しているので、もしあなたが、WebサービスかWS*プロトコルの体験するのが始めて、もしくは、この分野における変更のペースについていくのが困難であるならば、本稿が、一番耳にするプロトコルに関することやそれらの目的について理解するための大きな手助けとなるでしょう。発展している標準に関するインターオペラビリティの様相についても簡単に説明したいと思います。
SOAPとWSDLを振り返る
それは、インターオペラビリティを促進するために、XMLをコアとするアプリケーション間のメッセージフォーマットの方法について記述した簡潔な仕様です。考えてみれば、SOAPはヘッダーの場所やメッセージペイロードの場所、リクエスト(もしくはアクション)の意図を示す方法(プラットフォームが動作する際に、SOAPメッセージを処理するための基本的な要求)といった、メッセージのラップを単に記述しているだけなのです。これはすごいことです。しかし、プラットホーム特有のランタイムタイプに変えることになっているならば、取得したヘッダーやボディ要素も理解する必要があります。ここで、WSDLの登場です。WSDLでは、サービスがアクセス可能なURL、そのロケーションでサポートされたオペレーション(アクション)、メッセージフォーマット、XSDスキーマによって記述された関連する型の定義を記述します。メッセージはSOAPで構成されており、WSDLではアプリケーション特有のメッセージ要求を記述します。
結局、WSDL (Web Services Description Language)とSOAPを組み合わせているので、データを共有するシステムを開発する際の、開発者の生産性を実際に高めるものとなります。インターオペラビリティの問題は以前から数多く存在していました。しかし現在では、プラットフォームによるSOAP、WSDL、XMLシリアライズの型のサポートによって、あらゆるプラットフォーム上でのWebサービスの開発とホスト、メッセージ要求を記述したWSDLの作成、オペレーション呼び出しのためのクライアントコードの作成といったものが、少しの努力でできるようになっています。プログラムで検索可能な記述とコード生成を支援するツールといった、 POX ("plain old XML")のアプローチでは解決できなかった問題が解決されたので、「SOAPのお陰だ」と言えるかもしれせん。
何故WS*なのか?
メッセージヘッダーとボディ要素の実際の内容は、SOAP仕様によって定義されません。どういったヘッダーを必要としているのか、特定のオペレーションで有効に動作するためにボディにどういったデータを含めるのかといったことについては、アプリケーションで完全にカスタマイズできます。しかしながら、メッセージルーティングやアドレッシング、巨大なメッセージペイロードの扱い、最前線のセキュアで信頼性のある通信といったSOAPに係る実装については、一般的に必要とされているものが共有されています。そこでWS*プロトコルの登場となるわけです。
WS* は、SOAP仕様に基づいた標準プロトコルの集まりで、一見したところずっと進化しているものであり、業界の広い支援を受けて作られています。それらの目的は、システム間の共通のメッセージ要求を簡単にすることにあります。開発者が至るところで同じようなカスタムSOAPヘッダーを作っているため、例えば、ユーザー名とパスワードの認証を送信するための標準が必要であるということが、ある時点で明確になりました。その結果、WS-Securityが誕生しました。バイナリデータを送信して処理する際のオーバーヘッドを減らすための仕様が必要だったので、それはすぐにはっきりと理解できるものとなっています。それ故、委員会がMTOM形式と決着をつけるまでは、最適化されたバイナリ転送エンベロープが代替となります。こういった共通シナリオにおける標準を作ることで、ベンダーは自身の開発を容易にするためのツールを作成することができるのです。つまり、メッセージ交換の単純化以上に、開発者の生産性が改善されるのです。
図1: Webサービスプロトコルの主要カテゴリ
図1 では、Webサービスに関連するプロトコルに適合する主要カテゴリを図示しています。このようにまとめれば、さほどおびえることもないと思います。しかし、あなたが各々のカテゴリーの範囲内で標準のリストを拡張するならば、容易に圧倒されてしまうことでしょう。以下のセクションでは、各々のカテゴリーから主要な標準について、現状に関する概要を説明したいと思います。さらには、それらの承認状況、主要目的と価値、そして現在のJavaプラットフォームと WCFでの適用性についても説明したいと思います。
注釈：今回の説明では、.NETプラットフォームとしてのWCFについてのみ言及するつもりです。何故なら、それがマイクロソフトの実装だからです。また、 Java側にはWS*の実装が多々ありますが、本稿の目的を鑑み、プラットフォーム間で採用される標準という観点での一般論を述べたいと思います。
トランスポートプロトコル
当然のことながら、トランスポートプロトコルはメッセージ配信を容易にするために必要とされるものです。SOAPプロトコルのバインディングフレームワーク(http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew) (英語)では、メッセージ転送をサポートするためにどのようにプロトコルのバインディングを定義するのかについて記述されています。以下、2つの公式ドキュメントがあります。:
- HTTP: http://www.w3.org/TR/2007/REC-soap12-part2-20070427/#soapinhttp (英語)
- SMTP: http://www.w3.org/TR/soap12-email (英語)
一般的に、SOAPメッセージはHTTPまたはHTTPS上で転送されるものとして考えます。そして、Javaと.NETの間のインターオペラビリティのためというのが最も一般的なシナリオです。実際、SOAPとWS*の本質は、様々なプロトコル上でサービスを公開できるところにあり、TCP、名前つきパイプ、UDP、カスタムプロトコルといったものでさえもバインディング形式として記述することができます。マイクロソフトのWindows Communication Foundation (WCF)プラットフォームでは、一般的なメッセージフォーマットをベースとしているので、これらを含めた様々なプロトコル上でSOAPメッセージを使用します。当然ですが、HTTPでない実装についてのインターオペラビリティはありません。
プロトコルバインディングは、適切なアドレス情報をプロトコルヘッダーにマップする方法を含め、特定のプロトコル上でメッセージを転送する方法について記述します。実際、WS-Addressingは、トランスポートプロトコルからアドレスヘッダの結合を取り除きます。メッセージペイロードに完全にカプセル化された、アドレッシングセマンティクスの代替を記述します。
ウェブサービスにおける従来のプラットフォームのサポートに関しては、インターオペラビリティが関係するので、一般的にはHTTPまたはHTTPSを使用します。
XML標準
当然ながら、XMLとXSDスキーマはSOAP、WSDL、WS*の心臓部です。即ち、ドキュメントのメッセージング要求を可能とします。XMLデジタル署名とXML暗号化は、XMLドキュメント(もしくはSOAPメッセージ)のセキュアな部分に関する標準なので、WS-Securityプロトコルによって適切に利用されます。この最後の点で重要なことは、WS-Securityが導入されたとき、認証やその他のメッセージ部分についてメッセージセキュリティを実現するために、初めからやり直さなかったということです。つまり、既に存在している、XMLドキュメントを保護するためのデジタル署名や暗号化ライブラリに関する仕様を活用したということです。
メッセージング関連プロトコル
一般的なメッセージング機能をサポートするいくつかのプロトコルがあります。まず、全体的なメッセージフォーマットとしてSOAPがあります。今日、ほとんどのプラットフォームではSOAP 1.1とSOAP 1.2フォーマットの両方をサポートしており、1.2ではドキュメントリテラルなメッセージフォーマット(エンコードの対語としてのスキーマベース)となっています。SOAP 1.2は、現在のプラットフォームにおけるデフォルトセットです。しかし、レガシークライアントと後方互換性を保たなければならないサービスを公開しているならば、SOAP 1.1を使用しているシリアライズメッセージのサービス設定であることを明確にしなければならないかもしれません。
WS-Addressing: 2005年8月W3C勧告 (source)
先に述べたとおり、WS-Addressing は、トランスポートレイヤーからアドレッシングとルーティングを分離します。このことは、任意のプロトコル上で複数のホップを通じて、一貫した方法でSOAP メッセージを送信することができるということです。それは、非同期オペレーションに対するWebサービスのエンドポイントや、パブリッシュ/サブスクライブパターンを記述するための標準的な手法を提供しているとも言えます。WS-Addressingは、その他多くのWS*群に関係する中心的なものです。今日、ほとんどのプラットフォームでは、WS-Addressingプロトコルをサポートしています。実際、WebサービスのほとんどがWS- Addressingに対応したSOAP 1.2をサポートしています。
通常、アドレッシングヘッダーを見ることは無いでしょう。それは、そのプロトコルをサポートしているプラットフォームで、Webサービスを公開するか利用した時に「起こる」ものだからです。しかし、いくつかのプラットフォームではWS-Addressingに準拠していないものもあるので、インターオペラビリティの精神に基づいてより古いバージョンをサポートする上で、クライアントやサービスを構成するときにアドレッシングヘッダーが必要になるかもしれません。
WS-Transfer: 2006年9月W3C提案 (source)
WS-Transfer は、SOAPメッセージングを通してCRUDオペレーションをサポートします。RESTのトランスポートに依存しない実装を提供するためにHTTP verbsからこれらのアクションを分離します。私は、アドレッシングのセマンティクスが完全に異なっていることから、HTTP上のRESTfulアーキテクチャに代わるものとしてWS-Transferの提案をするということは無いと考えています。しかし、オペレーションとは対照的に、リソースへのアクセスが集中するサービスに対して役に立ちます。例えば、あなたのサービスがCRUDにフォーカスしたものであるならば、Webサービス提供の一部としてこの仕様の実装を目にすることができるかもしれません。
WS-Transfer の実装のほとんどが、事実上固有のものです。つまり、仕様それ自身がWebサービスプラットフォームにおける主要部分ではないということです。しかし、仕様に従って自身のものを実装することは十分簡単なことです。
WS-Enumeration: 2006年3月W3C 提案 (source)
WS-Enumeration は、データセットに対するフォワードオンリー、あるいはリードオンリーカーソルのような大きなデータセットを要求するためのプロトコルを定めます。WS- Transferのように、この仕様はプラットフォームの主要部分ではありませんが、このようなアクセスパターンを必要とする場合、その仕様を実装することは容易です。
WS-EventNotification
WS-EventNotification は、パブリッシュやサブスクライブのシナリオなどの場合に、トランスポートプロトコルに独立した形で、分散されたイベントと通知をサポートするための方法を記述します。それは、WS-Notification とWS-Eventing という他の競合する仕様の統一を図る作業を行っているところです。WS-Notification とそれに関連する標準 (WS-BaseNotification、WS-BrokeredNotification、WS-Topics) は、2006年10月にOASIS標準として承認されました (http://www.research.ibm.com/journal/sj/444/niblett.html) (source) 。WS-Eventing は、2006年3月にW3Cに提案され(http://www.w3.org/Submission/WS-Eventing) (source) 、それより単純な通知のインフラストラクチャが WS-Notification によって記述されました。
これらの標準(ここ(source)で議論されています) の統一は、仕様が承認されたときでさえWS-NotificationがOASISであったように、標準に関する業界の同意を得ることができたので、プラットフォームがインターオペラビリティを持つことができるということを示しています。ただ、特定の目的のための標準が競合している限りは、(それは時々起こることですが)プラットフォームベンダーによる実装は減り、インターオペラビリティを難しくします。WS -EventNotificationが承認に(近い)状態になるまでは、十分なインターオペラビリティが、通知(notification )のためになされることはないでしょう。しかし、軽く採用してWS-NotificationやWS-Eventingを実装することはあります。
MTOM: 2005年1月W3C 勧告 (source)
MTOM (Message Transmission Optimization Mechanism) は、より効率的な方法でSOAPメッセージの一部としてバイナリデータを転送する方法を記述します。この仕様は、SwA (SOAP with Attachments) と DIME (Direct Internet Message Encapsulation) が発展したものです。MIMEエンコーディングはこれらのプロトコル全ての基本となるものです。その目的は、SOAPメッセージ(XMLインフォセット)に組み込まれたbase64エンコードされたバイナリデータに関するオーバーヘッドを解析し、肥大化を取り除くことにあります。一方で、MTOMはSOAPエンベロープから抽出されたバイナリコンテキストを参照するためにXOP (XML-Binary Optimized Packaging)を利用するため、メッセージレシーバーはバイナリデータをXML infosetの正しい位置に戻すことができます。別の方法として、バイナリデータは、SOAPボディの特定の要素によって参照することができます。そして、通常は、それがオペレーションのパラメータとして評価されることを意味しています。
SwA は、2004年6月にW3Cに提案されるにとどまりました。しかし、WS-Iがこの標準をBasic Attachments Profileに組み込んだことで、多くのプラットフォームがこの仕様を実装しました。DIMEもまた、多くのプラットフォームで実装されています。特に、SwAをサポートしていない.NETやWeb Services Enhancements (WSE) (以前のWCF)とのインターオペラビリティを実現したいJavaプラットフォームによって実装されています。現在では、SwAとDIMEの両方は時代遅れであると考えられており、承認されてから2年たつMTOMは、広くプラットフォームで採用され、インターオペラビリティでも成功事例があります。
MTOM実装の詳細を見る必要はありません。むしろ、バイナリコンテキストを含むかもしれないメッセージ用のプロトコルを選択できるように、プラットフォームでのサービスとクライアントの設定を行ってください。
セキュリティプロトコル
セキュリティプロトコルは、WS*が発展し始めたときに、プラットホームでいち早く安定したものとなりました。初期のドライバーは、どういった証明書がシリアライズされるかということに関して、標準化のために必要なものをベースとしていました。従って、個々の実装を一から始める必要はありませんでした。早くに現れた追加的なセキュリティのシナリオは、特にワイヤー上のメッセージプロテクション、セキュアセッション、独自のフェデレーションと関連していました。
トランスポート対メッセージセキュリティ
転送間のメッセージを保護するためには、整合性を確保するためのデジタル署名やプライバシー保護のための暗号化が必要となります。これは、トランスポートレベル、もしくはメッセージセキュリティを利用することで実現可能です。セキュリティプロトコルを利用するためのすべてのシナリオでメッセージセキュリティを利用するとは限りませんが、推奨されるアプローチです。トランスポートセキュリティが利用される時は、下図のようにメッセージがポイント・トゥ・ポイントでのみ保護されます。:
それと比べると、メッセージセキュリティはSOAPエンベロープで証明書を渡して、メッセージ部分を署名・暗号化するためにOASISのSOAPメッセージセキュリティを利用します。メッセージセキュリティで最も重要な点の1つは、メッセージ転送を保護するためのインターオペラビリティのある標準を使用しているということです。そして、メッセージセキュリティが転送とは独立したメッセージを保護するので、下図に示すように、エンド・トゥ・エンドのセキュリティを提供する最後のメッセージレシーバ(あるいは、対象のアプリケーション)までの道のりで、メッセージを保護することが可能です。:
これにより、コンテントベースのルータを通じてメッセージを渡すこと、あるいは(例えば)機密情報が漏れることなく中継を管理することができます。
メッセージセキュリティを使用する方が、より安全であると考えられています。あなたが自身に尋ねなければならないことは、何らかの仲介者に到達し、下流サービスを通過した時に保護されていないメッセージに関連して、不必要な負担やリスクがあるかどうかです。通常、仲介者は下流サービスの信頼されたドメインの一部で、他のメッセージルートも可能です。
WS-Security: 2004年3月OASIS標準、2006年2月更新 (source)
WS -Securityは、セキュリティトークンの形式で証明書を提供し、メッセージのトークンを安全に渡すために、メッセージの部分を(XMLデジタル認証とXML暗号化プロトコルを利用して)署名・暗号化するためのオープンフォーマットです。そのロードマップは2002年に遡り、2004年の中ごろに OASISによってバージョン1.0が承認され、2006年の2月にバージョン1.1に更新されました。このグループのコア標準には、WS- Securityのコア(SOAP Message Security)と、UserNameトークンプロファイル、X.509トークンプロファイル、Kerberosトークンプロファイル、SAMLトークンプロファイルを含むいくつかのトークンプロファイルを含んでいます。トークンプロファイルは、プラットフォームを通じてしっかりとした方法で証明書をシリアライズすることが可能で、なによりもWS-Security採用の推進力となっているものの一つです。
WS-Securityが2002年以降進化し、この分野でアーリーアダプタを悩ますインターオペラビリティの問題のほとんどが解決したということは、驚くべきことではありません。例えば、初期の段階では単純なUserNameトークンを渡すことでさえ、プラットフォーム間での課題でした。しかし、今ではフォーマットの合意が十分になされているので、Webサービスプラットフォームにおけるより最近のバージョンでは、実装上できちんと合意されています。同種の課題が、仕様の他の面で存在していましたが、結局のところ、最も一般的なシナリオで解決しています。現在、WS-Securityを実装するための最も一般的なシナリオは、以下の通りです。:
- トランスポートセキュリティ上でのUserNameトークン: 実装に必要とされる「十分に良いセキュリティ」として多くの人に見なされていることから、おそらくこれが、現時点で最も一般的なセキュアなサービスのための手法です。
- メッセージセキュリティ上でのUserNameトークン: これは、ルータのような何らかの仲介者を通過するセキュアメッセージを望んでいるケースで利用されます。メッセージセキュリティはこれらのシナリオでの負荷を低減することができます。(私の見解では、可能であればどこでも利用すべきだと思います)
- 相互の証明書認証: これは一般的に、呼び出し側がユーザー名とパスワードの代わりにX.509証明書によって特定されるビジネスパートナーのケースで用いられます。UserNameトークンは、認可と監査証跡のためにサービス呼び出しをしているユーザーを特定するためにも提供されるので、X.509がパートナーを証明するために利用されるケースがあります。
Kerberosトークン認証は、イントラネットにおいて重要であるものの、一般的にはファイアウォールの外で公開されているWebサービスのために利用しません。SAMLも、フェデレーションを含むケースで一般的に利用されますが、それについては後述します。
あなたは、JavaとWCFプラットホームがSSLまたは署名と暗号化のメッセージセキュリティを用い、WS-Securityの一般的なケースで十分に相互運用することが理解できたと思います。
WS-SecureConversation: 2007年3月 OASIS標準 (PDF・英語)
WS-SecureConversation は、複数呼び出しの交換のオーバーヘッドを減らす安全なセッションの概念を記述する仕様です。セキュリティコンテキストトークン(SCT)は、WS-SecureConversationプロトコルを利用している呼び出し側とサービスの間での最初の交換によって発生します。そして、このトークンは、その後のメッセージ交換を認証するために利用されます(SSL認証に似ています)。セキュアセッションの識別子はメッセージ交換の際に生成され、セッション内でメッセージを相互に関連付けるためにも用いられます。
このプロトコルは、証明書が各々の呼び出しで渡され、それぞれの呼び出しで認証する際に、1回のメッセージセキュリティのパフォーマンスを向上させる上で、とても重要な標準です。ネゴシエーションを通じて共通のセッションキーを作成することによって、メッセージの署名と暗号化に要するキーのサイズがより小さくなります(非対象暗号鍵の代わりに対照暗号鍵を使用します)。加えて、処理時のオーバーヘッドも低減します。
WS -SecureConversationは最近になって承認され、複数のJavaプラットフォームやWCFで実装されました。このようにして、今日ではインターオペラビリティが実現されています。そうは言っても、現時点でWebサービスを幅広い顧客に利用してもらいたいのならば、サービスの通信が可能なクライアントプラットフォームの数を制限するわけにはいかないので、WS-SecureConversationではなく別の構成を公開する必要があります。それは、Webサービスプラットフォームがセキュアなセッション識別子をキャッシュし、証明されている呼び出し側と連携すべきであるということを意味しているので、セッションを導入するということは、ロードバランスとの密接な関係があるということでもあります。呼び出し側がセキュアセッション中に同じサーバに戻るよう指示しなければ、プラットフォームがこの情報をキャッシュする場所を決定してしまうでしょう。
WS-SecureConversationは、OASIS委員会の下で、WS-SXとして記載されています: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx (英語)
WS-Trust: 2007年3月 OASIS標準 (PDF・英語)
WS-Trust は、セキュリティトークンの発行、更新、交換をサポートするプロトコルです。それは、WS-SecureConversationプロトコルによって記述され、セキュリティコンテキストトークンを発行するために使用されます。しかし、それはフェデレートされたセキュリティモデルのキーでもあります。フェデレートされたセキュリティモデルのWS-Trustは、トークン発行者、若しくはセキュリティトークンサービス(STS)と呼ばれ、アプリケーションサービスによって受け入れられたセキュリティトークンの発行に責任を持ち、集中型のサービスのような認証や認可のデリゲーションをサポートします。理論上は、全てのトークン形式がSTSによって発行されることが可能であるものの、それらが十分に相互運用可能なXMLトークンフォーマット(それは、呼び出し側を特定し、アプリケーション機能の正当性を記述する際に使用することができます)であったときから、SAMLトークンはかなり人気があります。
図2 は、アプリケーションサービスが、特定の信頼されたSTSによって発行されたSAMLトークンを渡すように、呼び出し側に求めた単純なケースです。このケースでは、UserNameトークンがSTSと返却されたSAMLトークンによって伝えられ、それらはアプリケーションサービスの認証に利用することができます。WS-TrustのIssue()オペレーションは、呼び出し側の認証に責任を持っており、成功した場合はアプリケーションサービスによって利用されうるトークンを生成します。そのトークンは、STSによるデジタル認証がなされているので、アプリケーションサービスは、それが信頼された発信元からのものであるのか、あるいは途中でいじられていないかどうかを検証することができます。このケースでは、一般的には、アプリケーションサービスと信頼されたSTSは同じ組織に属しています。
図2: WS-Trustを使用したシンプルな発行シナリオ
WS -Trustをベースとしたフェデレートされた識別モデルは、特定のタイプの証明書から独立した呼び出しを認可するアプリケーションサービスを構築することを可能にします。代わりに、インターネットパートナーのためのUserNameトークンと、インターネットユーザーのためのKerberosトークンを認証するためのサービスロジックを含みます。つまり、サービスは両方のケースにおいて信頼されたSAMLトークンを要求し、証明書のサポートと信頼された STSの認証を要求します。STSが異なる証明書に対するサポートを後で加えるならば、それらはSAMLトークンに依存し続けるので、アプリケーションサービスに影響を及ぼしません。STSは、特定のサービスやオペレーションの中に、認証された呼び出し側の正当性が記述されたSAMLトークンを要求することもできます。このようにして、STSへ権限を委任します。
全てのプラットフォームにおいて、プロトコルのガイドラインに従い、トークンの発行をサポートするための相互運用可能なWS-Trustのエンドポイントを実装することができます。しかし、スクラッチから作成することはないでしょう。むしろ、あなたが利用するSTSによる通信の実装の一部となる、簡単なトークンの発行を実装すると思います。それは、JavaもしくはWCFプラットフォームにて実装され、特定の必要性に応じてそれを修正します。これは、あなたの労力を大きく省くでしょう。企業品質の結果を求めるならば、大抵の場合は、Ping IdentityのPingTrustやMicrosoftのADFS(Active Directory Federation Services)といった商用製品を選ぶべきでしょう。後者に関して言えば、次リリースでWebサービス上のフェデレーションをサポートする予定です。いずれのアプローチを使用しても、インターオペラビリティはWS-Trustの実装、認証のためのSTSによってサポートされたトークン形式、STSによって発行されることが可能なトークンフォーマットを含んだ多くの要素に依存するでしょう。
WS-Trustは、OASIS委員会のWS-SXに掲載されています。: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx (英語)
WS-Federation: 2006年12月 パブリックドラフト (PDF・英語)
WS -Federationは、信頼されたドメイン間での識別子のフェデレーションサポートと、シングルサインオン・サインオフによるマッピングした識別子をサポートするために、WS-Security、WS-SecureConversation、WS-Trustにもとづいて構築された仕様です。
WS-Federationには、2つのプロファイルがあります。:
- パッシブリクエスタプロファイル: このプロファイルは、現在、PingFederateやADFSといった製品によってサポートされています。ブラウザーをベースとしたシングルサインオン(SSO)やアイデンティティフェデレーション(ID連携)を可能にします。
- アクティブリクエスタプロファイル: このプロファイルは、現在、PingTrustによってサポートされており、将来的にはADFSでサポートされる予定です。Webサービス上のアイデンティティフェデレーションをサポートします。
WS-Federationは、SAML(Security Assertion Markup Language)2.0と類似した問題を解決しますが、他のWS*プロトコルで構成可能です。それは例えば、信頼メッセージングやトランザクションに関連するものです。従って、あなたがエンタープライズレベルのフェデレーションをソリューションとして組み込みたいのなら、ドメイン内の参加者によってどのプロトコルが実装されているのかについて注意を払わなければならないでしょう。PingFederateやPingTrustのような製品は、SAML 2.0やWS-Federationの両方をサポートしています。また、Liberty Allianceは、SAML 2.0を、ADFSやWindows Live IDは、WS-Federationだけをサポートしています。
WS-Federationのパブリックドラフトは、最近、OASIS WSFED 技術委員会へのインプットとして受け入れられました: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed (英語) この委員会の下で、SAML 2.0とWS-Federationが標準化されることを期待します。
信頼メッセージングプロトコル
信頼メッセージングは、以下の方法でアプリケーションの信頼性を高めるように設計されています。:
- メッセージは正確に一回、順番に届けられることを保証することができます。そして、ネットワーク通信の一時的な中断にも対応することができます。
- これらの配信保証は、特定のプロトコルに依存しません。従って、例えばHTTPプロトコルであっても信頼性があります。
- メッセージ配信が複数のホップ上で信頼できるように、エンド・ツー・エンドの信頼性がサポートされます。
- 信頼性は、全てSOAPメッセージをベースとしているので、単に個々のIPパケットではありません。
図3 は、信頼メッセージングがプラットフォーム間でどのようにして機能することができるのかに関する高度な考え方を示しています。そのアイデアは、クライアント(イニシエーター)とサービス(レシーバー)の両方のプラットフォームが、出たり入ったりするメッセージのバッファを確保したり、「信頼できるセッション」である間、バッファからメッセージを削除する前にメッセージ受信の確認を待っています。設定したタイムアウトで確認されなかったメッセージは、設定可能なリトライ数分再送されます。
図3: 信頼メッセージングの高度な考え方
WS-Reliability: 2004年11月 OASIS標準 (source)
多くの他のWS*の前に、WS-Reliability プロトコルは非常に早くからOASISに承認されました。それは、信頼されたメッセージングを達成する方法を記述しているものの、トランザクション、セキュアなセッション、その他のWS*プロトコルに関する考慮はされていません。しかし、2、3のプラットフォームは、この仕様をサポートしています。
WS-ReliableMessaging: 2004年11月 OASIS標準 (source)
WS-ReliableMessaging プロトコルは、WS-Reliabilityより多くの業界支援を受けており、WS*プロトコルスタックも考慮しています。それがまだ承認されないにもかかわらず、多くのプラットホームでこの仕様を実装しています。実際、WS-RX OASIS副委員会(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx) (英語) が、混乱を減らすために2つの標準を収束させようと取り組んでいます。
メッセージベースの信頼性は明らかに望ましいものであるものの、プラットホームのサポートに関してはかなり新しいので、WS- ReliableMessagingのサポートのあるなしでサービスを広く公開するかを判断したいところです。また、セキュアなセッションである信頼メッセージングは、セッションがキャッシュされた特定のサーバーマシンへの親和性を必要とする可能性のあるセッションであるということを意味しています。
トランザクションに関連したプロトコル
WS-Coordination、WS-AtomicTransaction、WS-BusinessActivity は、プラットフォームの境界を越えて分散トランザクションをサポートする相互運用可能なプロトコルです。そのプロトコルセットは、2007年3月にOASIS 標準として批准されました。WS-Coordinationは、境界を越えて調整コンテキストを共用するためのプロトコルを定義しています。WS- AtomicTransactionとWS-BusinessActivityは、そういった調整コンテキストの実装を表します。WS-AtomicTransaction は、メッセージベースの2フェーズ層コミット(2PC)プロトコルを容易にするものであるのに対し、WS- BusinessActivityは、トランザクションの保証を含んだ、長く実行されるトランザクションを容易にするものです。
少数のプラットフォームでは、既にWS-AtomicTransactionでWS-Coordinationをサポートしています。プラットフォームを超え、ファイヤーウォールを通してHTTPプロトコル上での分散トランザクションを可能とします。
現在、トランザクションに参加する全てを所有するのか、もしくは(プラットフォーム側の)仲間すべてとの強い信頼関係があるときに、トランザクションをサポートするサービス実装を考慮する傾向にあります。サービスがあまり知られていないクライアントのトランザクション制御下に入るということは、不確かなトランザクションでリソースがロックされた場所にいるというリスクを被っているのです。インターネットに公開するWebサービスでトランザクションをサポートする前に、慎重に検討してください。
これらのトランザクションプロトコルは、OASIS委員会(WS-TX)の下でリストされています: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx (英語)
メタデータプロトコル
オペレーション、メッセージフォーマット、WS*プロトコルのサポートといった、Webサービスの必要条件を記述する方法が無いならば、プラットホームが開発者生産性を向上し、実装全体の一貫性をもった信頼性を高めるために必要なツールを提供することは不可能です。実際、それはインターオペラビリティを現実的なゴールとするツールです。WSDLは、WS*なしでのアプリケーションメッセージングを可能とします。WS-Policy とWS-MetadataExchangeは、WS*のサポートにWSDLが加わったものです。
WS-Policy: 2006年4月 W3Cに提出 (source)
WS -Policyは、MTOM、セキュリティ、信頼メッセージング、トランザクションといったWS*の機能に対する、拡張したプロトコル機能とサービスの必要条件を記述してます。加えて、WS-Policyでは、WSDLドキュメントか直接、あるいはWS-PolicyAttachmentで記述されたアタッチメントとしてポリシー表明を含めるための方法を記述しています。WS-PolicyはWS*、WSDLは標準的なSOAPメッセージということです。
WS -Policyの背景にある考えは、結局、WS*の機能サポートを記述するために、プラットホームがWSDLの一部としてWS-Policyの表明を公開するということだと思います。故に、特定のポリシー表明のセットは、それぞれの機能について記述し、合意済みであるべきです。そのような例をいくつか挙げます:
- WS-SecurityPolicy: トークン、メッセージ保護、サービスによってサポートされたその他のセキュリティ機能を記述します。内容は、このドキュメント(PDF・英語)に記載されています。
- WS-ReliableMessaging Policy: サービスをサポートするWS-ReliableMessagingの機能を記述します。内容は、このドキュメント(source)に記載されています。
- WS-AtomicTransaction Policy: サービスをサポートするWS-AtomicTransactionの機能を記述します。WS-AtomicTransactionの仕様については、こちら(PDF・英語)。
あなたがサービスに対してカスタムプロトコルを定義するのであれば、WS-Policyはカスタムの表明を作ることが十分可能な拡張可能な仕様です。ポイントは、WS-Policyが拡張可能であり、全てのWS*機能を記述するための基盤として利用することができるということです。WSDLで書かれたポリシー表明を含むものであれば何でも、コードを生成したりクライアントの設定に活用することができます。これにより、開発者の生産性を改善します。現在、未だWS-Policyは承認されておらず、プラットフォームもWS-Policyに対する広いサポートを行っていません。WCFは、メタデータ交換とプロキシの生成を容易にするために、これを広く利用しています。また、SunのTangoでは、WCFによって作られたWS-Policyとのインターオペラビリティを提示しています。
S-MetadataExchange: 2006年9月 パブリックドラフト (PDF・英語)
WS-MetadataExchange プロトコルは、WSDL文書、WS-Policyの設定、特定のサービスに関連したメッセージやスキーマ型の発見をサポートします。SvcUtilは、サービスの記述からWSDLドキュメントを生成するために、このプロトコルを使用しています。これにより、ツールを利用してプロキシや設定を生成するための要求をプログラムで見つけることができます。さらに、ポリシーセクションやオペレーションを含む、特定のWSDLセクションのリクエストを容易にします。このプロトコルは、フェデレートされたセキュリティ(例えば、STSにログインするために必要な証明書を動的に発見する必要があるときがあります)に関するものといった、その他のWS*の実装にとっても重要なものです。
WS*のインターオペラビリティ
SOAP が最初に導入された1999年から現在まで、「従来からのSOAP」が長い道のりを経て、プラットホーム間のインターオペラビリティの物語に同意することができたと思います。一般的に言って、WSDLを一貫して生成・解釈したり、スキーマ、XMLパーサーによって記述されたシリアライズ化された型の解釈について、一般的な問題のほとんどが解決したので、(「ほぼ何時でも」という意味で)互換性が存在することになります。
早期採用からテスト、初期リリース、ベンダー実装、安定した実装に至るまで、WS*プロトコルごとに似たような進化が存在します。MTOM、WS- Addressing、WS-Securityといった標準は、ほとんどの部分で安定した実装を実現できる一方、WS-Trust、WS- ReliableMessaging、WS-AtomicTransactionといったその他の最近の標準は、ベンダー実装も比較的初期段階の状態です。
開発者がインターオペラビリティを実現するために設定やXMLをいじる必要がなくなる状態まで、ベンダー実装とツールが到達するまでは、沢山の標準を幅広く採用することはないでしょう。しかし、早期段階で参加する人たちは、実世界のケースによる標準を通じて、その支援をするでしょう。結局、歴史がそれを証明しています。開発者が、背後にあるXML標準を理解するための65ページに渡る仕様書を読むことなく、サービスを作り、クライアントコードを生成することで、WS*ツールが、きちんと機能するのです。それは、それらが承認される前に進んで採用するかどうかということ、そして、それらの早い実装においては、 WS*の機能を採用するために、あなたがどのくらい必要もしくは望んでいるかということによってもたらされる効用であると言えるでしょう。
本稿では、WS*プロトコル、特にプラットフォーム境界を越えた分散メッセージを可能にするという点にフォーカスしました。具体的には、アドレッシング、巨大メッセージのサポート、セキュリティ、信頼メッセージング、トランザクション、メタデータ交換などより関連性のあるものです。この記事が、あなたにとって様々な標準の各々が持つ目的や、それらを採用する上での高度な考え方の一助となれれば幸いです。
著者について
Michele Leroux Bustamanteは、IDesign Inc.のチーフアーキテクトです。マイクロソフトのサンディエゴ地域ディレクター、通信システムにおけるマイクロソフトのMVP、BEAの技術ディレクターでもあります。Micheleは、IDesignでWebサービス、スケーラビリティ、.NETでのセキュアなアーキテクチャ設計、グローバルアーキテクチャにフォーカスしたトレーニング、指導、ハイエンドアーキテクチャのコンサルティングサービスを行っています。彼女は、International .NET Speakers Association (INETA)のメンバーの一人であり、頻繁にカンファレンスで発表し、SD Westでの学会主催者、UCSD Extensionのプログラムアドバイザーです。彼女の最近の書籍は、Learning WCF (O'Reilly 2007)です。(ブログは、こちら (source) 。連絡先は mlb@idesign.net 、もしくは、www.idesign.net (英語)で彼女の主要ブログである www.dasblonde.net(英語)を見てください。)
原文はこちらです：http://www.infoq.com/articles/ws-standards-wcf-bustamante
（このArticleは2007年5月16日に原文が掲載されました）