Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。本稿では、もっともよく耳にするWS*プロトコルについてまとめるというのが私の意向です。いうのも、(Javaと.Netにフォーカスした)Webサービスプラットフォーム、それらの採用と準備の度合い、.Netでの特定の統合シナリオのための適用性と共に、実際の実装という点で現在利用するであろう最も関連性のある標準を重視しているので、もしあなたが、WebサービスかWS*プロトコルの体験するのが始めて、もしくは、この分野における変更のペースについていくのが困難であるならば、本稿が、一番耳にするプロトコルに関することやそれらの目的について理解するための大きな手助けとなるでしょう。発展している標準に関するインターオペラビリティの様相についても簡単に説明したいと思います。SOAPとWSDLを振り返るそれは、インターオペラビリティを促進するために、XMLをコアとするアプリケーション間のメッセージフォーマットの方法について記述した簡潔な仕様です。考えてみれば、SOAPはヘッダーの場所やメッセージペイロードの場所、リクエスト(もしくはアクション)の意図を示す方法(プラットフォームが動作する際に、SOAPメッセージを処理するための基本的な要求)といった、メッセージのラップを単に記述しているだけなのです。これはすごいことです。プラットホーム特有のランタイムタイプに変えることになっているならば、取得したヘッダーやボディ要素も理解する必要があります。ここで、WSDLの登場です。WSDLでは、サービスがアクセス可能なURL、そのロケーションでサポートされたオペレーション(アクション)、メッセージフォーマット、XSDスキーマによって記述された関連する型の定義を記述します。メッセージはSOAPで構成されており、WSDLではアプリケーション特有のメッセージ要求を記述します。Language)とSOAPを組み合わせているので、データを共有するシステムを開発する際の、開発者の生産性を実際に高めるものとなります。インターオペラビリティの問題は以前から数多く存在していました。現在では、プラットフォームによるSOAP、WSDL、XMLシリアライズの型のサポートによって、あらゆるプラットフォーム上でのWebサービスの開発とホスト、メッセージ要求を記述したWSDLの作成、オペレーション呼び出しのためのクライアントコードの作成といったものが、少しの努力でできるようになっています。XML")のアプローチでは解決できなかった問題が解決されたので、「SOAPのお陰だ」と言えるかもしれせん。WS*なのか?メッセージヘッダーとボディ要素の実際の内容は、SOAP仕様によって定義されません。いったヘッダーを必要としているのか、特定のオペレーションで有効に動作するためにボディにどういったデータを含めるのかといったことについては、アプリケーションで完全にカスタマイズできます。メッセージルーティングやアドレッシング、巨大なメッセージペイロードの扱い、最前線のセキュアで信頼性のある通信といったSOAPに係る実装については、一般的に必要とされているものが共有されています。そこでWS*プロトコルの登場となるわけです。SOAP仕様に基づいた標準プロトコルの集まりで、一見したところずっと進化しているものであり、業界の広い支援を受けて作られています。それらの目的は、システム間の共通のメッセージ要求を簡単にすることにあります。開発者が至るところで同じようなカスタムSOAPヘッダーを作っているため、例えば、ユーザー名とパスワードの認証を送信するための標準が必要であるということが、ある時点で明確になりました。その結果、WS-Securityが誕生しました。バイナリデータを送信して処理する際のオーバーヘッドを減らすための仕様が必要だったので、それはすぐにはっきりと理解できるものとなっています。それ故、委員会がMTOM形式と決着をつけるまでは、最適化されたバイナリ転送エンベロープが代替となります。いった共通シナリオにおける標準を作ることで、ベンダーは自身の開発を容易にするためのツールを作成することができるのです。メッセージ交換の単純化以上に、開発者の生産性が改善されるのです。Webサービスに関連するプロトコルに適合する主要カテゴリを図示しています。このようにまとめれば、さほどおびえることもないと思います。あなたが各々のカテゴリーの範囲内で標準のリストを拡張するならば、容易に圧倒されてしまうことでしょう。以下のセクションでは、各々のカテゴリーから主要な標準について、現状に関する概要を説明したいと思います。WCFでの適用性についても説明したいと思います。注釈:今回の説明では、.NETプラットフォームとしてのWCFについてのみ言及するつもりです。それがマイクロソフトの実装だからです。Java側にはWS*の実装が多々ありますが、本稿の目的を鑑み、プラットフォーム間で採用される標準という観点での一般論を述べたいと思います。トランスポートプロトコル当然のことながら、トランスポートプロトコルはメッセージ配信を容易にするために必要とされるものです。(英語)では、メッセージ転送をサポートするためにどのようにプロトコルのバインディングを定義するのかについて記述されています。以下、2つの公式ドキュメントがあります。(英語)一般的に、SOAPメッセージはHTTPまたはHTTPS上で転送されるものとして考えます。Javaと.NETの間のインターオペラビリティのためというのが最も一般的なシナリオです。実際、SOAPとWS*の本質は、様々なプロトコル上でサービスを公開できるところにあり、TCP、名前つきパイプ、UDP、カスタムプロトコルといったものでさえもバインディング形式として記述することができます。(WCF)プラットフォームでは、一般的なメッセージフォーマットをベースとしているので、これらを含めた様々なプロトコル上でSOAPメッセージを使用します。当然ですが、HTTPでない実装についてのインターオペラビリティはありません。プロトコルバインディングは、適切なアドレス情報をプロトコルヘッダーにマップする方法を含め、特定のプロトコル上でメッセージを転送する方法について記述します。実際、WS-Addressingは、トランスポートプロトコルからアドレスヘッダの結合を取り除きます。メッセージペイロードに完全にカプセル化された、アドレッシングセマンティクスの代替を記述します。ウェブサービスにおける従来のプラットフォームのサポートに関しては、インターオペラビリティが関係するので、一般的にはHTTPまたはHTTPSを使用します。当然ながら、XMLとXSDスキーマはSOAP、WSDL、WS*の心臓部です。ドキュメントのメッセージング要求を可能とします。XMLデジタル署名とXML暗号化は、XMLドキュメント(もしくはSOAPメッセージ)のセキュアな部分に関する標準なので、WS-Securityプロトコルによって適切に利用されます。この最後の点で重要なことは、WS-Securityが導入されたとき、認証やその他のメッセージ部分についてメッセージセキュリティを実現するために、初めからやり直さなかったということです。存在している、XMLドキュメントを保護するためのデジタル署名や暗号化ライブラリに関する仕様を活用したということです。メッセージング関連プロトコル一般的なメッセージング機能をサポートするいくつかのプロトコルがあります。全体的なメッセージフォーマットとしてSOAPがあります。1.2フォーマットの両方をサポートしており、1.2ではドキュメントリテラルなメッセージフォーマット(エンコードの対語としてのスキーマベース)となっています。1.2は、現在のプラットフォームにおけるデフォルトセットです。1.1を使用しているシリアライズメッセージのサービス設定であることを明確にしなければならないかもしれません。トランスポートレイヤーからアドレッシングとルーティングを分離します。メッセージを送信することができるということです。それは、非同期オペレーションに対するWebサービスのエンドポイントや、パブリッシュ/サブスクライブパターンを記述するための標準的な手法を提供しているとも言えます。WS-Addressingは、その他多くのWS*群に関係する中心的なものです。今日、ほとんどのプラットフォームでは、WS-Addressingプロトコルをサポートしています。1.2をサポートしています。通常、アドレッシングヘッダーを見ることは無いでしょう。それは、そのプロトコルをサポートしているプラットフォームで、Webサービスを公開するか利用した時に「起こる」ものだからです。いくつかのプラットフォームではWS-Addressingに準拠していないものもあるので、インターオペラビリティの精神に基づいてより古いバージョンをサポートする上で、クライアントやサービスを構成するときにアドレッシングヘッダーが必要になるかもしれません。SOAPメッセージングを通してCRUDオペレーションをサポートします。verbsからこれらのアクションを分離します。私は、アドレッシングのセマンティクスが完全に異なっていることから、HTTP上のRESTfulアーキテクチャに代わるものとしてWS-Transferの提案をするということは無いと考えています。オペレーションとは対照的に、リソースへのアクセスが集中するサービスに対して役に立ちます。あなたのサービスがCRUDにフォーカスしたものであるならば、Webサービス提供の一部としてこの仕様の実装を目にすることができるかもしれません。実装のほとんどが、事実上固有のものです。仕様それ自身がWebサービスプラットフォームにおける主要部分ではないということです。仕様に従って自身のものを実装することは十分簡単なことです。データセットに対するフォワードオンリー、あるいはリードオンリーカーソルのような大きなデータセットを要求するためのプロトコルを定めます。Transferのように、この仕様はプラットフォームの主要部分ではありませんが、このようなアクセスパターンを必要とする場合、その仕様を実装することは容易です。パブリッシュやサブスクライブのシナリオなどの場合に、トランスポートプロトコルに独立した形で、分散されたイベントと通知をサポートするための方法を記述します。いう他の競合する仕様の統一を図る作業を行っているところです。よって記述されました。統一は、仕様が承認されたときでさえWS-NotificationがOASISであったように、標準に関する業界の同意を得ることができたので、プラットフォームがインターオペラビリティを持つことができるということを示しています。特定の目的のための標準が競合している限りは、(それは時々起こることですが)プラットフォームベンダーによる実装は減り、インターオペラビリティを難しくします。)のためになされることはないでしょう。軽く採用してWS-NotificationやWS-Eventingを実装することはあります。効率的な方法でSOAPメッセージの一部としてバイナリデータを転送する方法を記述します。MIMEエンコーディングはこれらのプロトコル全ての基本となるものです。その目的は、SOAPメッセージ(XMLインフォセット)に組み込まれたbase64エンコードされたバイナリデータに関するオーバーヘッドを解析し、肥大化を取り除くことにあります。infosetの正しい位置に戻すことができます。別の方法として、バイナリデータは、SOAPボディの特定の要素によって参照することができます。通常は、それがオペレーションのパラメータとして評価されることを意味しています。2004年6月にW3Cに提案されるにとどまりました。Profileに組み込んだことで、多くのプラットフォームがこの仕様を実装しました。DIMEもまた、多くのプラットフォームで実装されています。(以前のWCF)とのインターオペラビリティを実現したいJavaプラットフォームによって実装されています。現在では、SwAとDIMEの両方は時代遅れであると考えられており、承認されてから2年たつMTOMは、広くプラットフォームで採用され、インターオペラビリティでも成功事例があります。MTOM実装の詳細を見る必要はありません。バイナリコンテキストを含むかもしれないメッセージ用のプロトコルを選択できるように、プラットフォームでのサービスとクライアントの設定を行ってください。セキュリティプロトコルセキュリティプロトコルは、WS*が発展し始めたときに、プラットホームでいち早く安定したものとなりました。初期のドライバーは、どういった証明書がシリアライズされるかということに関して、標準化のために必要なものをベースとしていました。従って、個々の実装を一から始める必要はありませんでした。早くに現れた追加的なセキュリティのシナリオは、特にワイヤー上のメッセージプロテクション、セキュアセッション、独自のフェデレーションと関連していました。トランスポート対メッセージセキュリティ転送間のメッセージを保護するためには、整合性を確保するためのデジタル署名やプライバシー保護のための暗号化が必要となります。これは、トランスポートレベル、もしくはメッセージセキュリティを利用することで実現可能です。セキュリティプロトコルを利用するためのすべてのシナリオでメッセージセキュリティを利用するとは限りませんが、推奨されるアプローチです。トランスポートセキュリティが利用される時は、下図のようにメッセージがポイント・トゥ・ポイントでのみ保護されます。:それと比べると、メッセージセキュリティはSOAPエンベロープで証明書を渡して、メッセージ部分を署名・暗号化するためにOASISのSOAPメッセージセキュリティを利用します。メッセージセキュリティで最も重要な点の1つは、メッセージ転送を保護するためのインターオペラビリティのある標準を使用しているということです。メッセージセキュリティが転送とは独立したメッセージを保護するので、下図に示すように、エンド・トゥ・エンドのセキュリティを提供する最後のメッセージレシーバ(あるいは、対象のアプリケーション)までの道のりで、メッセージを保護することが可能です。:これにより、コンテントベースのルータを通じてメッセージを渡すこと、あるいは(例えば)機密情報が漏れることなく中継を管理することができます。メッセージセキュリティを使用する方が、より安全であると考えられています。あなたが自身に尋ねなければならないことは、何らかの仲介者に到達し、下流サービスを通過した時に保護されていないメッセージに関連して、不必要な負担やリスクがあるかどうかです。通常、仲介者は下流サービスの信頼されたドメインの一部で、他のメッセージルートも可能です。-Securityは、セキュリティトークンの形式で証明書を提供し、メッセージのトークンを安全に渡すために、メッセージの部分を(XMLデジタル認証とXML暗号化プロトコルを利用して)署名・暗号化するためのオープンフォーマットです。OASISによってバージョン1.0が承認され、2006年の2月にバージョン1.1に更新されました。Security)と、UserNameトークンプロファイル、X.509トークンプロファイル、Kerberosトークンプロファイル、SAMLトークンプロファイルを含むいくつかのトークンプロファイルを含んでいます。トークンプロファイルは、プラットフォームを通じてしっかりとした方法で証明書をシリアライズすることが可能で、なによりもWS-Security採用の推進力となっているものの一つです。WS-Securityが2002年以降進化し、この分野でアーリーアダプタを悩ますインターオペラビリティの問題のほとんどが解決したということは、驚くべきことではありません。初期の段階では単純なUserNameトークンを渡すことでさえ、プラットフォーム間での課題でした。今ではフォーマットの合意が十分になされているので、Webサービスプラットフォームにおけるより最近のバージョンでは、実装上できちんと合意されています。同種の課題が、仕様の他の面で存在していましたが、結局のところ、最も一般的なシナリオで解決しています。現在、WS-Securityを実装するための最も一般的なシナリオは、以下の通りです。実装に必要とされる「十分に良いセキュリティ」として多くの人に見なされていることから、おそらくこれが、現時点で最も一般的なセキュアなサービスのための手法です。これは、ルータのような何らかの仲介者を通過するセキュアメッセージを望んでいるケースで利用されます。メッセージセキュリティはこれらのシナリオでの負荷を低減することができます。これは一般的に、呼び出し側がユーザー名とパスワードの代わりにX.509証明書によって特定されるビジネスパートナーのケースで用いられます。UserNameトークンは、認可と監査証跡のためにサービス呼び出しをしているユーザーを特定するためにも提供されるので、X.509がパートナーを証明するために利用されるケースがあります。Kerberosトークン認証は、イントラネットにおいて重要であるものの、一般的にはファイアウォールの外で公開されているWebサービスのために利用しません。SAMLも、フェデレーションを含むケースで一般的に利用されますが、それについては後述します。あなたは、JavaとWCFプラットホームがSSLまたは署名と暗号化のメッセージセキュリティを用い、WS-Securityの一般的なケースで十分に相互運用することが理解できたと思います。複数呼び出しの交換のオーバーヘッドを減らす安全なセッションの概念を記述する仕様です。セキュリティコンテキストトークン(SCT)は、WS-SecureConversationプロトコルを利用している呼び出し側とサービスの間での最初の交換によって発生します。このトークンは、その後のメッセージ交換を認証するために利用されます(SSL認証に似ています)。セキュアセッションの識別子はメッセージ交換の際に生成され、セッション内でメッセージを相互に関連付けるためにも用いられます。このプロトコルは、証明書が各々の呼び出しで渡され、それぞれの呼び出しで認証する際に、1回のメッセージセキュリティのパフォーマンスを向上させる上で、とても重要な標準です。ネゴシエーションを通じて共通のセッションキーを作成することによって、メッセージの署名と暗号化に要するキーのサイズがより小さくなります(非対象暗号鍵の代わりに対照暗号鍵を使用します)。加えて、処理時のオーバーヘッドも低減します。-SecureConversationは最近になって承認され、複数のJavaプラットフォームやWCFで実装されました。このようにして、今日ではインターオペラビリティが実現されています。言っても、現時点でWebサービスを幅広い顧客に利用してもらいたいのならば、サービスの通信が可能なクライアントプラットフォームの数を制限するわけにはいかないので、WS-SecureConversationではなく別の構成を公開する必要があります。それは、Webサービスプラットフォームがセキュアなセッション識別子をキャッシュし、証明されている呼び出し側と連携すべきであるということを意味しているので、セッションを導入するということは、ロードバランスとの密接な関係があるということでもあります。呼び出し側がセキュアセッション中に同じサーバに戻るよう指示しなければ、プラットフォームがこの情報をキャッシュする場所を決定してしまうでしょう。セキュリティトークンの発行、更新、交換をサポートするプロトコルです。それは、WS-SecureConversationプロトコルによって記述され、セキュリティコンテキストトークンを発行するために使用されます。それはフェデレートされたセキュリティモデルのキーでもあります。フェデレートされたセキュリティモデルのWS-Trustは、トークン発行者、若しくはセキュリティトークンサービス(STS)と呼ばれ、アプリケーションサービスによって受け入れられたセキュリティトークンの発行に責任を持ち、集中型のサービスのような認証や認可のデリゲーションをサポートします。理論上は、全てのトークン形式がSTSによって発行されることが可能であるものの、それらが十分に相互運用可能なXMLトークンフォーマット(それは、呼び出し側を特定し、アプリケーション機能の正当性を記述する際に使用することができます)であったときから、SAMLトークンはかなり人気があります。アプリケーションサービスが、特定の信頼されたSTSによって発行されたSAMLトークンを渡すように、呼び出し側に求めた単純なケースです。このケースでは、UserNameトークンがSTSと返却されたSAMLトークンによって伝えられ、それらはアプリケーションサービスの認証に利用することができます。WS-TrustのIssue()オペレーションは、呼び出し側の認証に責任を持っており、成功した場合はアプリケーションサービスによって利用されうるトークンを生成します。そのトークンは、STSによるデジタル認証がなされているので、アプリケーションサービスは、それが信頼された発信元からのものであるのか、あるいは途中でいじられていないかどうかを検証することができます。このケースでは、一般的には、アプリケーションサービスと信頼されたSTSは同じ組織に属しています。-Trustをベースとしたフェデレートされた識別モデルは、特定のタイプの証明書から独立した呼び出しを認可するアプリケーションサービスを構築することを可能にします。代わりに、インターネットパートナーのためのUserNameトークンと、インターネットユーザーのためのKerberosトークンを認証するためのサービスロジックを含みます。STSの認証を要求します。STSが異なる証明書に対するサポートを後で加えるならば、それらはSAMLトークンに依存し続けるので、アプリケーションサービスに影響を及ぼしません。STSは、特定のサービスやオペレーションの中に、認証された呼び出し側の正当性が記述されたSAMLトークンを要求することもできます。このようにして、STSへ権限を委任します。全てのプラットフォームにおいて、プロトコルのガイドラインに従い、トークンの発行をサポートするための相互運用可能なWS-Trustのエンドポイントを実装することができます。スクラッチから作成することはないでしょう。あなたが利用するSTSによる通信の実装の一部となる、簡単なトークンの発行を実装すると思います。それは、JavaもしくはWCFプラットフォームにて実装され、特定の必要性に応じてそれを修正します。これは、あなたの労力を大きく省くでしょう。Services)といった商用製品を選ぶべきでしょう。後者に関して言えば、次リリースでWebサービス上のフェデレーションをサポートする予定です。いずれのアプローチを使用しても、インターオペラビリティはWS-Trustの実装、認証のためのSTSによってサポートされたトークン形式、STSによって発行されることが可能なトークンフォーマットを含んだ多くの要素に依存するでしょう。WS-Trustは、OASIS委員会のWS-SXに掲載されています。-Federationは、信頼されたドメイン間での識別子のフェデレーションサポートと、シングルサインオン・サインオフによるマッピングした識別子をサポートするために、WS-Security、WS-SecureConversation、WS-Trustにもとづいて構築された仕様です。WS-Federationには、2つのプロファイルがあります。このプロファイルは、現在、PingFederateやADFSといった製品によってサポートされています。ブラウザーをベースとしたシングルサインオン(SSO)やアイデンティティフェデレーション(ID連携)を可能にします。このプロファイルは、現在、PingTrustによってサポートされており、将来的にはADFSでサポートされる予定です。Webサービス上のアイデンティティフェデレーションをサポートします。Language)2.0と類似した問題を解決しますが、他のWS*プロトコルで構成可能です。それは例えば、信頼メッセージングやトランザクションに関連するものです。従って、あなたがエンタープライズレベルのフェデレーションをソリューションとして組み込みたいのなら、ドメイン内の参加者によってどのプロトコルが実装されているのかについて注意を払わなければならないでしょう。2.0やWS-Federationの両方をサポートしています。IDは、WS-Federationだけをサポートしています。2.0とWS-Federationが標準化されることを期待します。信頼メッセージングプロトコル信頼メッセージングは、以下の方法でアプリケーションの信頼性を高めるように設計されています。:メッセージは正確に一回、順番に届けられることを保証することができます。ネットワーク通信の一時的な中断にも対応することができます。これらの配信保証は、特定のプロトコルに依存しません。従って、例えばHTTPプロトコルであっても信頼性があります。メッセージ配信が複数のホップ上で信頼できるように、エンド・ツー・エンドの信頼性がサポートされます。信頼性は、全てSOAPメッセージをベースとしているので、単に個々のIPパケットではありません。信頼メッセージングがプラットフォーム間でどのようにして機能することができるのかに関する高度な考え方を示しています。そのアイデアは、クライアント(イニシエーター)とサービス(レシーバー)の両方のプラットフォームが、出たり入ったりするメッセージのバッファを確保したり、「信頼できるセッション」である間、バッファからメッセージを削除する前にメッセージ受信の確認を待っています。設定したタイムアウトで確認されなかったメッセージは、設定可能なリトライ数分再送されます。プロトコルは非常に早くからOASISに承認されました。それは、信頼されたメッセージングを達成する方法を記述しているものの、トランザクション、セキュアなセッション、その他のWS*プロトコルに関する考慮はされていません。2、3のプラットフォームは、この仕様をサポートしています。プロトコルは、WS-Reliabilityより多くの業界支援を受けており、WS*プロトコルスタックも考慮しています。それがまだ承認されないにもかかわらず、多くのプラットホームでこの仕様を実装しています。混乱を減らすために2つの標準を収束させようと取り組んでいます。ReliableMessagingのサポートのあるなしでサービスを広く公開するかを判断したいところです。セキュアなセッションである信頼メッセージングは、セッションがキャッシュされた特定のサーバーマシンへの親和性を必要とする可能性のあるセッションであるということを意味しています。プラットフォームの境界を越えて分散トランザクションをサポートする相互運用可能なプロトコルです。標準として批准されました。WS-Coordinationは、境界を越えて調整コンテキストを共用するためのプロトコルを定義しています。AtomicTransactionとWS-BusinessActivityは、そういった調整コンテキストの実装を表します。BusinessActivityは、トランザクションの保証を含んだ、長く実行されるトランザクションを容易にするものです。少数のプラットフォームでは、既にWS-AtomicTransactionでWS-Coordinationをサポートしています。プラットフォームを超え、ファイヤーウォールを通してHTTPプロトコル上での分散トランザクションを可能とします。現在、トランザクションに参加する全てを所有するのか、もしくは(プラットフォーム側の)仲間すべてとの強い信頼関係があるときに、トランザクションをサポートするサービス実装を考慮する傾向にあります。サービスがあまり知られていないクライアントのトランザクション制御下に入るということは、不確かなトランザクションでリソースがロックされた場所にいるというリスクを被っているのです。インターネットに公開するWebサービスでトランザクションをサポートする前に、慎重に検討してください。(英語)メタデータプロトコルオペレーション、メッセージフォーマット、WS*プロトコルのサポートといった、Webサービスの必要条件を記述する方法が無いならば、プラットホームが開発者生産性を向上し、実装全体の一貫性をもった信頼性を高めるために必要なツールを提供することは不可能です。実際、それはインターオペラビリティを現実的なゴールとするツールです。WSDLは、WS*なしでのアプリケーションメッセージングを可能とします。WS-MetadataExchangeは、WS*のサポートにWSDLが加わったものです。-Policyは、MTOM、セキュリティ、信頼メッセージング、トランザクションといったWS*の機能に対する、拡張したプロトコル機能とサービスの必要条件を記述してます。加えて、WS-Policyでは、WSDLドキュメントか直接、あるいはWS-PolicyAttachmentで記述されたアタッチメントとしてポリシー表明を含めるための方法を記述しています。WS-PolicyはWS*、WSDLは標準的なSOAPメッセージということです。-Policyの背景にある考えは、結局、WS*の機能サポートを記述するために、プラットホームがWSDLの一部としてWS-Policyの表明を公開するということだと思います。故に、特定のポリシー表明のセットは、それぞれの機能について記述し、合意済みであるべきです。トークン、メッセージ保護、サービスによってサポートされたその他のセキュリティ機能を記述します。内容は、このドキュメント(PDF・英語)に記載されています。サービスをサポートするWS-ReliableMessagingの機能を記述します。内容は、このドキュメント(source)に記載されています。サービスをサポートするWS-AtomicTransactionの機能を記述します。WS-AtomicTransactionの仕様については、こちら(PDF・英語)。あなたがサービスに対してカスタムプロトコルを定義するのであれば、WS-Policyはカスタムの表明を作ることが十分可能な拡張可能な仕様です。ポイントは、WS-Policyが拡張可能であり、全てのWS*機能を記述するための基盤として利用することができるということです。WSDLで書かれたポリシー表明を含むものであれば何でも、コードを生成したりクライアントの設定に活用することができます。これにより、開発者の生産性を改善します。現在、未だWS-Policyは承認されておらず、プラットフォームもWS-Policyに対する広いサポートを行っていません。WCFは、メタデータ交換とプロキシの生成を容易にするために、これを広く利用しています。SunのTangoでは、WCFによって作られたWS-Policyとのインターオペラビリティを提示しています。プロトコルは、WSDL文書、WS-Policyの設定、特定のサービスに関連したメッセージやスキーマ型の発見をサポートします。SvcUtilは、サービスの記述からWSDLドキュメントを生成するために、このプロトコルを使用しています。これにより、ツールを利用してプロキシや設定を生成するための要求をプログラムで見つけることができます。ポリシーセクションやオペレーションを含む、特定のWSDLセクションのリクエストを容易にします。このプロトコルは、フェデレートされたセキュリティ(例えば、STSにログインするために必要な証明書を動的に発見する必要があるときがあります)に関するものといった、その他のWS*の実装にとっても重要なものです。最初に導入された1999年から現在まで、「従来からのSOAP」が長い道のりを経て、プラットホーム間のインターオペラビリティの物語に同意することができたと思います。一般的に言って、WSDLを一貫して生成・解釈したり、スキーマ、XMLパーサーによって記述されたシリアライズ化された型の解釈について、一般的な問題のほとんどが解決したので、(「ほぼ何時でも」という意味で)互換性が存在することになります。早期採用からテスト、初期リリース、ベンダー実装、安定した実装に至るまで、WS*プロトコルごとに似たような進化が存在します。ReliableMessaging、WS-AtomicTransactionといったその他の最近の標準は、ベンダー実装も比較的初期段階の状態です。開発者がインターオペラビリティを実現するために設定やXMLをいじる必要がなくなる状態まで、ベンダー実装とツールが到達するまでは、沢山の標準を幅広く採用することはないでしょう。早期段階で参加する人たちは、実世界のケースによる標準を通じて、その支援をするでしょう。結局、歴史がそれを証明しています。開発者が、背後にあるXML標準を理解するための65ページに渡る仕様書を読むことなく、サービスを作り、クライアントコードを生成することで、WS*ツールが、きちんと機能するのです。WS*の機能を採用するために、あなたがどのくらい必要もしくは望んでいるかということによってもたらされる効用であると言えるでしょう。本稿では、WS*プロトコル、特にプラットフォーム境界を越えた分散メッセージを可能にするという点にフォーカスしました。具体的には、アドレッシング、巨大メッセージのサポート、セキュリティ、信頼メッセージング、トランザクション、メタデータ交換などより関連性のあるものです。この記事が、あなたにとって様々な標準の各々が持つ目的や、それらを採用する上での高度な考え方の一助となれれば幸いです。Inc.のチーフアーキテクトです。マイクロソフトのサンディエゴ地域ディレクター、通信システムにおけるマイクロソフトのMVP、BEAの技術ディレクターでもあります。Micheleは、IDesignでWebサービス、スケーラビリティ、.NETでのセキュアなアーキテクチャ設計、グローバルアーキテクチャにフォーカスしたトレーニング、指導、ハイエンドアーキテクチャのコンサルティングサービスを行っています。Extensionのプログラムアドバイザーです。