グリッド入門講座【後編】

グリッドの標準化動向とビジネスへの適用

（2007年04月05日）

前のページへ < ｜1｜2｜3｜4｜ > 次のページへ

OGSIとWRSF

　繰り返すようだが、OGSAの登場以前－－例えば、Globus Toolkitがまだ「Globus Toolkit 2（GT2）」のころは、グリッドの構築に多種多様なプロトコルが用いられていた（図3）。

図3：OGSA登場以前のグリッド環境

　それを、Webサービスのプロトコルで統一し、その上にグリッド・サービスを載せることで、全体の構造が非常に分かりやすくなり、しかも、アプリケーションという上位層の部分だけを考えれば、グリッドのサービスが実現できる格好になる（図4）。

図4：OGSA登場後のグリッド環境のイメージ

　こうしたOGSAの登場に伴い、Globus Toolkitについても変更が施され、基盤の部分にOGSIを用いた「Globus Toolkit 3（GT3）」が登場した。しかし、その次のバージョンである「Globus Toolkit 4（GT4）」では、OGSIではなく、「WSRF（Web Services Resource Framework）」と呼ばれる仕様が採用されている。

　WSRFは、OGSIに代わる仕様として、2004年1月に「Globus Alliance」と呼ばれるチームとIBMが発表したものだ。

　当時、OGSIは非常に大きな仕様になっていたために、これを6つのWebサービス・コンポーネントに分けて、再構成しようというアイデアが浮上した。それに基づき、策定されたのがWSRFである。

　ただし、この登場により、現在のOGSAではOGSIの層がWSRFに置き換えられ、結果として、GT3も過去の遺物と化すことになった。

　ともあれ、基本的に、Webサービスのサービス・コンポーネントは「状態」を保持しないステートレスなものだ。しかし、グリッドのサービスは、状態を保持できなければならない。そこで、OGSIでは、「グリッド・サービス・データ」というモデルの下で状態を表現したり、ファクトリ・サービスによって、リソースの生成やライフタイムを管理したりするといった概念が採用された。

　これに対して、WSRFでは、オペレーションを行うサービスと、リソースを管理する（つまり、状態の管理だけを扱う）サービスとを分離するという考え方が採用されている。すなわち、リソースをきちんと分離することで、Webサービスを非常に拡張しやすいかたちでグリッドに適用しようと考えたのである。

　なお、OGFは、OGSAを含めたさまざまな技術の仕様や、ドキュメントの作成を進めているが、今や、OGGFの取り組みとWebサービス技術は、切り離すことができない関係になっている。

　そのため、W3Cが策定する標準技術や、OASISで定義される仕様も、OGFの中できわめて重要な位置づけとなっており、互いのワーキング・グループやタスクフォースが交流しながら、仕様作りを進めている。

前のページへ < ｜1｜2｜3｜4｜ > 次のページへ