レベル: 中級 David A. Cafaro (dac@cafaro.net), Computational Researcher, Consultant
2007年 7月 31日 Web サービス・グループは WSRF (WS-Resource Framework) 標準から WS-RT (WS-ResourceTransfer) フレームワークへの移行を完了しました。WS-RT は、元の WSRF 標準の要素を WS-Management 標準に組み合わせ、異なるコンポーネント間でリソース情報とオブジェクトを交換しやすくするための仕様です。この記事では、この 2 つの標準とその違いについて説明し、また互換性を目的に 2 つの標準の間で移行する方法を説明することで、他のアプリケーションとの相互運用性を実現するための新しい標準に移行するお手伝いをします。
はじめに
ネットワーキングの拡大、そしてコンピューティング負荷を分散するという構想により、グリッド・コンピューティングの概念と実装は成熟期を迎えています。「グリッド・コンピューティング」の定義は、それを解釈するグループによって異なる可能性がありますが、一般的には構造化または管理されたシステムにおけるネットワーク上の異種混合リソースの相互運用性と通信を意味します。グリッド・インフラストラクチャーを実装する方法の 1 つは、Web ベースのサービスを使用することです。WSRF (WS-Resource Framework) はこの Web をベースとしたグリッド・サービスの実装を目的とする仕様の 1 つで、WSN (WS-Notification) 仕様と一体となって、Web サービス・ベースのグリッド・コンピューティングを実現するための絶好の出発点となります。
WSRF と時期を同じくして、競合する標準も開発およびデプロイされました。その 1 つが WS-Transfer です。WSRF と WS-Transfer は互いに競合し、相互に通信することはなかったため、別々に開発されたグリッド・リソースをネットワーク接続するという構想の障害となっていました。
そこで、WS-Transfer と WSRF の開発者たちが 2005年3月に計画を発表したのが、新しい仕様、WS-RT (WS-ResourceTransfer) です。WS-RT は WS-Transfer を拡張および強化したもので、元の WS-Transfer にはなかった WSRF の機能を追加しています。WS-RT が追加したのは、具体的に言うと WS-ResourceProperties および WS-ResourceLifetime の機能です。この 2 つの WSRF のコンポーネントには、WS-Transfer に欠けていた特定のきめ細かな制御メカニズムがありました。
この記事では、WSRF が提供する機能 (特に WS-ResourceProperties と WS-ResourceLifetime) と WS-RT が提供する機能、そして両仕様がどのように重複しているかを検討するとともに、WSRF から WS-RT に移行する際に考えられる手法について説明します。
WSRF (WS-Resource Framework)
WSRF 仕様は、WS-ResourceProperties、WS-ResourceLifetime、WSRF-SG (WS-ServiceGroup)、そして WSRF-BF (WS-BaseFaults) という 4 つの主要コンポーネントから構成されています。これらのコンポーネントのうち、WS-ResourceLifetime への移行を検討する際に大きく関わってくるのは WS-ResourceProperties と WS-ResourceLifetime です。この 2 つのコンポーネントは主にリソース・オブジェクトの表現とアクセスを対象とし、Web サービス同士が互いのリソースをやりとりするための主要な仕様を規定しています。以下に、WSRF 標準仕様の各コンポーネントが提供する内容を簡単に説明します。
まずは、この記事で注目する 2 つの主要な仕様のうちの 1 つ、WS-ResourceProperties に目を向けてみましょう。
WS-ResourceProperties
WS-ResourceProperties が扱っているのは、特定のリソースに関連付けられるプロパティーと、そのリソースの特性です。WS-ResourceProperties 仕様の文書では、Web サービス・アーキテクチャー内でリソースのプロパティー定義を表す方法を標準化しています。これらの仕様を用いることで、利用可能なリソースと、そのリソースに WSRF によってアクセスする方法とを、標準化されたビューで表すことが可能になります。WS-ResourceProperties では、公開されたリソース内でプロパティー値を照会および更新するために要求側が使用できる一連の標準メッセージを規定しています。これらのメッセージは、特定のサービスおよびリソース用に定義されたリソース・プロパティーを基準とするサブセットになっています。詳細は、「参考文献」を参照してください。
WS-RT では、WS-ResourceProperties に含まれる get 、put 、create 、および destroy 文の拡張機能を一部使用して、リソース文書へのフラグメント・アクセスを提供します。このフラグメント・アクセスについては後で詳しく説明するとして、次は、WS-RT に関連するもう 1 つの WSRF 仕様、WS-ResourceLifetime を取り上げます。
WS-Resource Lifetime
WS-ResourceLifetime が扱うのは、特定のリソースを破棄 (削除) する方法、そしてリソースのこの「存続時間」に設定される制約です。存続時間の制約では、即時にリソースを破棄することも、時間を基準に破棄するようスケジュールすることもできます。存続時間の制約は WS-ResourceProperties 内に設定されるため、照会することが可能です。詳細は、「参考文献」を参照してください。
WS-RT では WS-ResourceLifetime の仕様に基づいて、リソース・プロパティーに存続時間の制限という概念を追加しています。これにより、以前は WS-Transfer が単独で規定していたリソース・リストの時間的な側面に対する制御が一層強化されます。
ここでは WS-SG と WS-BF について触れますが、WSRF から WS-RT への移行の説明ではそれほど重要でありません。この 2 つの仕様は元来いずれもコア仕様でカバーされており、ある程度重複します。
WSRF-SG (WS-Service Group)
WS-SG はこの記事の焦点ではありませんが、この仕様も WSRF の一部となっています。WSRF-SG が重点とするのは、異種の Web サービスおよびリソースの集合を作成することです。エントリーと呼ばれるコンポーネントによって表現されるサービス・グループは、それ自体がリソースとしてみなされます。ある意味、サービス・グループは最上位レベルの WSRF フレームワーク内に存在する WSRF に基づいて複数のグループをサブグループ化したものです。サービス・グループには、グループ内で収集された WSRF 準拠の個別リソースに利用可能なプロパティーおよびオブジェクトのほとんどを含めることができます。詳細は、「参考文献」を参照してください。
WSRF-BF (WS-Base Faults)
WSRF-BF もこの記事の焦点ではありませんが、WS-RT が規定する障害標準化は、元の WS-Transfer 仕様だけでなく WS-RT に対して行われた拡張もカバーします。WSRF-BF では簡易化した障害情報の標準セットを用意しており、この情報をレポートして Web サービス内での問題解決に役立てることができます。また、WSRF-BF はこれらの標準障害の拡張ならびに Web サービスでの基本使用法についてのルールも規定しています。詳細は、「参考文献」を参照してください。
これで、この記事で焦点とする WSRF の仕様とその仕様が提供する内容をすべて紹介したので、ここからは新しい WS-RT 仕様が扱う内容と旧 WSRF 仕様との関連について説明していきます。
WS-RT (WS-ResourceTransfer)
WS-RT は WS-Transfer から誕生しました (したがって、WS-Transfer の拡張です)。WS-RT の開発者たちは WS-Transfer と WSRF を検討し、WSRF にはあって WS-Transfer には欠けている機能を WS-RT に追加しました。このような流れにより、この既存の 2 つの仕様のいずれかから新規 WS-RT への移行を容易にするために必要な基礎を築くことができたわけです。WS-RT は WS-Transfer の拡張であるため、WS-Transfer の機能は以前と同じく維持されています。WSRF とまったく一致する操作は存在しないとしても、WS-RT にはこれらの操作を変換するための機能が備わっています。
WS-RT 仕様が対象とするのは、リソースの定義とその情報へのアクセス方法です。この仕様は、ストレージ・リソース、計算リソースやその他のリソース、そしてこれらのリソースに関連付けられた時間制約を表す方法を詳細に規定しています。WS-RT は WS-Transfer に規定されていた元の get 、put 、create 、および delete によるリソース操作を拡張し、「フラグメント・アクセス」機能を追加しています。この機能は、XML リソース表現全体の一部分のみに、操作によってアクセスできるようにするもので、WS-Transfer にはなかった WSRF の機能です。また、メタデータ・サポートも改訂され、WS-ResourceLifetime 仕様で定義された内容と同様の情報を含む存続時間要素が提供されています。
WS-RT が規定する内容とその実装方法については、連載「仕様を知る」を読んでください (「参考文献」を参照)。この「仕様を知る」の連載記事では、WS-RT 仕様で規定されている内容とその内容を実装する方法を非常に詳細に説明しています。
以上で説明した WSRF 仕様と WS-RT 仕様の基礎知識を念頭に、ここからは新規 WS-RT フレームワークへの移行を実現するために考えられる 2 つの移行手法を検討していくことにします。
WSRF から WS-RT への移行
WSRF から WS-RT に移行するには、主に 2 つの手法があります。まず 1 つは、代行によって WSRF と WS-RT の両方にアクセスできるようにするという手法です。そしてもう 1 つの手法では、XSLT を使用して直接 WSRF と WS-RT との間の変換を行います。以降のセクションでは、この 2 通りの移行手法がどのように実行されるか、その詳細の一部を説明します。その他の詳細については、「参考文献」を参照してください。
代行による二重サービス
この手法では WS-RT 操作は対応する WSRF 操作にほとんど完全にマッピングされるため、WSRF ベースのサービスと WS-RT ベースのサービスを同時に実行できます。図 1 は、このセットアップ方法の概略図です。
図 1. 代行による移行のセットアップ例
上記の図を見ると、WSRF クライアントが引き続き既存の WSRF サービスを使用する仕組みがわかります。WS-RT クライアントが使用する WS-RT サービスは、これらのサービスを提供するサーバー内で WSRF 操作のサービスにマッピングされます。そのため、移行期間中にサーバーは WS-RT クライアントと WSRF クライアントの両方にサービスを提供できるというわけです。今後の開発では、コア・リソースを一般的な方法で定義して、アプリケーション・スタックから WSRF に提供できるようにすることをお勧めします。このようにすれば、後で WSRF クライアントを段階的に廃止する準備をする際にコア・リソースを一新しなくても、WS-RT サービスが直接リソースを操作できるようになります。この手法の参考となる例を見るには、Apache Muse にアクセスしてください (「参考文献」を参照)。プロジェクトのプレビュー・ツリーの下に、WS-RT 代行のリファレンス実装が記載されています。
移行期間中、公開されたプロパティーと操作はある程度重複します。つまり、WSRF と WS-RT の両方を公開し、wsrl:Destroy() (WSRF) や ws-t:Delete() (WS-RT) などの重複していない仕様で同じような機能をそれぞれのクライアントに提供するわけですが、WSRF 固有の公開項目については、最終的にクライアントが WS-RT のみに移行する際に削除されることになります。
この手法の欠点は、サービスが代行モデルを規定していない場合、代行層をサービス・エンジンにコーディングしなければならないことです。サービス・エンジンが代行モデルをサポートするのであれば、既存のサービスにモジュールを追加するだけで済みます。
XSLT による変換サービス
もう 1 つの移行手法は、XSLT を使用する手法です。XSLT が変換するのは WS-Transfer ですが、WSRF クライアントと WS-RT クライアントは、サーバーが WSRF であるか WS-RT であるかに関わらず Web サービスのサービスを受けられます。図 2 は、この場合のセットアップ例です。
図 2. XSLT 変換のセットアップ例
上記に示すように、XSLT を使用してサービス要求を変換することで、現行の WSRF Web サービスを維持しつつも、新しい WS-RT ベースのクライアントに移行することが可能になります。WSRF クライアントが XSLT 層を通る際には変換の必要がありませんが、WS-RT クライアントが XSLT 層を通る際には WSRF への XML 間の変換が行われます。これとは逆に、WSRF クライアントから WS-RT Web サービスへの方向で変換することも可能です。
この手法には大きな 2 つの欠点があります。まず 1 つ目は、クライアントと Web サービス間で XSLT 変換を行うためには、変換層とサービスをコーディングしなければならないという点です。そしてもう 1 つの欠点として、XSLT 変換を適用できるタイミングは限られています。XML 間の変換には、両方の仕様 (WS-RT と WSRF) に特定の変換に対する直接的な 1 対 1 のマッピングがなければならないからです。
XSLT 変換と代行システムについての詳細は、「WSDM/WS-Man Reconciliation」を参照してください (「参考文献」を参照)。「WSDM/WS-Man Reconciliation」では、この記事では取り上げていない関連問題について詳細に検討しています。
まとめ
この記事では、移行の手法を計画する上で関わってくる問題を検討する準備として、WS-RT (WS-ResourceTransfer) 仕様とこの仕様に関連する WSRF (WS-Resource Framework) 仕様について概説した上で、WSRF から WS-RT への移行に取り組む際に採用できる 2 つの手法を検討しました。XSLT 変換と代行というこの 2 つの手法は、考えられるほとんどすべての移行状況に対処するための手法となります。いずれもあらゆる状況を解決するわけではありませんが、自分自身のニーズと将来的な計画を調査すれば、どちらか一方の手法 (あるいはその組み合わせ) が WS-RT をベースとした Web サービスへの円滑な移行に導いてくれるはずです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | David A. Cafaro は現在、Georgetown University の ARC (Advanced Research Computing) グループに勤務しています。Linux およびオープン・ソース技術を使用してコンピューターによる調査のニーズをサポートする彼は、Red Hat 認定エンジニアです。Program Committee for LinuxWorld Expo and Summit の一員でもある彼は、開発トラック・コンテンツおよび技術重視を支援しています。Tresys Technology ではセキュリティー・アナリストとして SELinux ポリシーを重点に取り組んでいました。ux.org Board of Directors のメンバーとして、オープン・ソース・コミュニティーと Linux コミュニティーで積極的に活躍しています。 |
記事の評価
| 
