Web サービス リソース フレームワーク

Web サービス リソース フレームワーク( WSRF ) は、 OASIS が公開したWeb サービス仕様のファミリーです。主な貢献者には、Globus Alliance やIBM などがあります。

ウェブサービス自体は名目上はステートレスであり、呼び出し間でデータを保持しません。これにより、ウェブサービスで実行できることが制限されます。

WSRF 以前は、Web サービス ファミリの仕様の標準では、リモート リソースとのステートフルな対話の処理方法が明示的に定義されていませんでした。これは、Web サービスがステートフルにならないという意味ではありません。必要に応じて、Web サービスはデータベースから読み取ったり、Cookie または WS-Session を介してセッション状態を使用したりすることができます。

WSRF は、Web サービスがステートフルなインタラクションを実装するために使用できる一連の操作を提供します。Web サービス クライアントは、データの保存と取得を可能にするリソースサービスと通信します。クライアントが Web サービスと通信する場合、要求内で使用される特定のリソースの識別子がWS-Addressingエンドポイント参照内にカプセル化されます。これは単純なURIアドレスの場合もあれば、問題の特定のリソースを識別したり完全に記述したりするのに役立つ複雑な XML コンテンツの場合もあります。

明示的なリソース参照の概念に加えて、リソース プロパティを取得/設定するための標準化された一連の Web サービス操作があります。これらを使用すると、オブジェクトのメンバー変数をそのメソッドと一緒に持つのと似た方法で、リソースの状態を読み取ったり、場合によっては書き込んだりできます。このようなモデルの主な受益者は管理ツールです。管理ツールは、リソースに関するその他の知識がなくても、リソースを列挙して表示できます。これがWSDMの基礎です。

WSRF には議論がないわけではありません。最も基本的なのはアーキテクチャです。つまり、状態と操作を持つ分散オブジェクトは、リモート リソースを表す最良の方法なのでしょうか。これは、 CORBAやDCOMなどの分散オブジェクトパターンを XMLに移植したものにほぼ相当します。WSRF リソースは、複数のクライアントがリソース参照を持つ状態のあるエンティティである可能性があり、WSRF 仕様自体は分離や可用性などの懸念事項を扱っておらず、Web サービス仕様の構成可能な性質に従ってこれらに対処しています。多くの WSRF スタックは、これらの懸念事項を回避するために、WSRF リソース参照からローカル オブジェクト インスタンスに 1:1 でマッピングする低可用性にしているように見えますが、C++ や Java では、通常、ローカル オブジェクト インスタンスはまったく永続的ではありません (何らかの永続メカニズムを介してデータベースにバインドされているものを除く)。ただし、リソースの永続性、クラスタリング、高可用性をサポートする WSRF 実装もあります (たとえば、WebSphere Application Server )。

ネットワークの分散オブジェクト ビューでは、WSRF は、すべてがリソースであるものの、すべてのアクションが限定された標準化された一連の操作を通じて有効になるネットワークのRESTモデルとも対立しています。いくつかの点では、これら 2 つのモデルは純粋なSOAPとRESTよりも近いと言えます。どちらも遠端にステートフル リソースがあるためです。ただし、HTTPで実装される REST では、リソースのアドレス指定に必要なのはURLだけであると想定しており、 WS-Addressing ReferenceParametersの複雑さは必要ありません。更新可能なリースを通じてリモート コンテンツの有効期間を管理するというアイデアは、特に批判されています。REST コミュニティのアーキテクチャに関するもう 1 つの問題は、WS-Notification で説明されているコールバック/通知がファイアウォールを通過しないことです。これが、REST 設計で RSS フィードやAtom (標準)フィードなどのポーリングが好まれる理由です。WSRF は、SOAP を REST コミュニティでより受け入れやすくするために何もしていません。

WSRF の導入は、WS-* 界にも分裂を引き起こしました。2004年 2 月のGlobal Grid Forumイベントで、 Open Grid Services Infrastructureの後継として初めて世界に発表されました。主流のWS-Iアーキテクチャとの互換性が限られていたため、英国のグリッド コミュニティから反対意見が出ました。^{[1] Global Grid Forum は最終的に、} Open Grid Services ArchitectureのWSRF プロファイルで WSRF への依存関係を切り離しました。WSRF プロトコルは、 WSDM で記述された管理可能なリソースを操作する手段としてもWSDMによって使用されていました。ただし、WS-* 界は Web サービス管理の単一標準に統一されておらず、Microsoft、Sun などがWS-Management の採用を選択し、管理可能なリソースを記述する手段として WS-Transfer に依存していました。

• WS-Resource は、リソースと、そのリソースにアクセスできる Web サービスの構成としてWS-Resource を定義します。
• WS-ResourceProperties は、標準的な方法で読み取りおよび操作できる WS-Resource に型指定された値のセットを関連付けるインターフェイスを記述します。
• WS-ResourceLifetime は、 WS-Resource の有効期間を管理するためのインターフェースを記述します。
• WS-BaseFaults は、豊富な SOAPFaults のための拡張可能なメカニズムを記述します。
• WS-ServiceGroup は、 WS-Resources のコレクションを操作するためのインターフェースを記述します。

また、何が起こっているかについて他の Web サービスに情報をプッシュする方法を規定する WS-Notification も関連しています。

WSRF リソースの基本的なプロパティの取得/設定セマンティクスを実装するのは比較的簡単です。最も難しい問題は、仕様で要求されている場合にフォールトを WSRF ベース フォールトとして返すことです。これは、SOAP スタック自体が SOAPFault フォールトを生成することを好むためです。リソースの有効期間の管理はより困難ですが、これはオプションです。WS-Notification も同様で、テストが最も困難です。

• Globus Toolkit バージョン 4 には、WSRF の Java および C 実装が含まれています。他の多くの Globus ツールも WSRF を中心に再構築されています。
• WebSphere Application Serverバージョン 6.1 は、シンプルな WSRF エンドポイントとクラスター化された高可用性 WSRF エンドポイントの両方をサポートする WSRF 環境を提供します。
• Apache Foundation は、 Wayback Machineプロジェクトに、WSRF、WS-Notification、およびWSDM仕様の Java ベースの実装である Muse 2.0 (2006-10-13 アーカイブ) を保有しています。
• WSRF::Lite Archived 2007-11-12 at the Wayback Machineは、エンドポイント参照のAddress要素を排他的に使用する Perl ベースの実装であり、これによりURI経由で WS-Resources を識別できるようになります。さらに、WSRF::Lite はHTTP動詞を WSRF 操作にマッピングし、 RESTアーキテクチャ スタイルで WS-Resources を使用できるようにします。
• WSRF.NET は、バージニア大学の研究チームによる WSRF 仕様に関する .NET ベースのプロジェクトです。
• UNICOREの最新バージョン 6.0 は、WS-ResourceLifetime と WS-Notification の部分的な実装を含む WSRF 1.2 標準の Java 実装に基づいて構築されています。

• WS-I
• オープングリッドサービスアーキテクチャ
• WS 管理
• ウェブサービス仕様一覧

• OASIS WSRF ページ
• ウェブサイトのデザインと開発
• Globus Toolkit 4 プログラマー向けチュートリアルの WSRF ガイド (2006 年 6 月 30 日、Wayback Machineにアーカイブ)