レベル: 中級 Abel W. Lin (awlin@ncmir.ucsd.edu), Software Architect, National Center for Microscopy and Imaging Research
2005年 11月 29日 「統合グリッドの構築、第 1 回」では、エンドツーエンド・プロセスを「グリッド対応」にすることの意味について考察し、NationalCenter for Microscopy and Imaging Research (NCMIR) の Telescience Projectで開発されたグリッド・ベース・システムのアーキテクチャーについて説明しました。今回はグリッド・インターフェースを取り上げ、なぜグリッド・インターフェースがエンドツーエンド・プロセスにとって重要なのか、また、NCMIRのグリッド・プロジェクトにおいて、ポートレットの使用がどのようにしてよりリッチなグリッド・ユーザー環境をもたらしたのかを解説します。
IT インフラストラクチャーにおける最近の進歩の大きな特徴と言えば、大量の情報やデータを収集し、処理する能力です。従来、膨大な量の情報を処理し、管理する、さらにはそれに基づいて意思決定を行う能力は、巨大な「ビッグ・アイアン」級のスーパーコンピューターにアクセスする権限のあるごく一部の人々に限られたものでした。それが今や、グリッド・コンピューティングによって機会の均等化が実現され、誰でもコンピューティング能力の大きなプールへのアクセス(または作成) を行えるようになりました。とはいえ、グリッド・インフラストラクチャーの開発や配備は、エンド・ユーザーへのアクセス拡大に向けた一つのステップにすぎません。あらゆるエンドツーエンド・プロセスがグリッドを最大限に利用できるようにするには、グリッドが、それぞれのユーザーに固有の自然な作業プロセスに透過的に組み込まれなければなりません。
グリッド・インターフェースがエンドツーエンド・プロセスにとって重要である理由
グリッド・ポータルの従来の理論的根拠は、グリッド・テクノロジーがわかりにくかったり、使いにくかったりすることがしばしばあることです。そのため、シンプルで直感的なWeb インターフェースが、さまざまなアプリケーションを起動する方法をユーザーに提供するのだ、ということです。「統合グリッドの構築、第 1 回」で説明したような統合グリッドでは、確かにシンプルで直感的な Web インターフェースは重要です。しかし、統合グリッドに必要なのは、単にシンプル化されたグリッド・インターフェースだけではありません。既存のアプリケーション・インターフェース環境にグリッド機能を透過的に統合するための方法が必要なのです。このグリッドの透過的な統合こそが、統合グリッドのためのインターフェースの大きな特徴です。
グリッド・インターフェースには、ラジオ・ボタンやチェック・ボックス以上のものが必要
第 1 世代のグリッド (およびその前身のスーパーコンピューティング・センター)のユースケース・モデルは、航空産業で使用されるハブアンドスポーク・モデルと似ています。ユーザー・データ環境は「ハブ」として扱われ、ユーザー(およびそのデータ) は、ステップごとに、全国にいくつかあるスポーク (または仮想組織)のいずれかにルーティングされ、そのコンピューティング・リソースを使用するにはログインを行う必要があります。グリッド実装の初期には、コマンドライン・インターフェースを使用して最適に機能させる能力がエンド・ユーザーにしばしば要求されたため、理想的なものではありませんでした。ほどなく、ログイン・メカニズムはグリッド・ポータルに統合されました。その結果、ユーザーは、コマンド・プロンプトを介してログインする代わりに、Webページに誘導されるようになりました。しかし、これらの第 1 世代のグリッド・ポータルは、複雑なコマンドライン引数や構文をラジオ・ボタンとチェック・ボックスで単に置き換えたものでした。これは、構文インターフェースをシンプル化するうえでは効果的な方法でしたが、ユーザー固有のワークフロー・プロセスにグリッドを統合するものではありませんでした。
図1. 第 1 世代のグリッド・ポータル・インターフェース
「統合グリッドの構築、第 1 回」で私は、統合グリッドは、より大量のデータのより高速な処理を可能にするだけでなく、プロセス全体に対する意識を変えてしまう能力を持っていると指摘しました。統合グリッドの構築という挑戦は、アーキテクチャーのあらゆる側面に及んでいます。統合グリッドの要件の一部として、次世代のポータル・インターフェースは、エンド・ユーザーのアプリケーション環境に固有のワークフロー・プロセスを正確に反映できるものでなければなりません。この環境では、ポイントツーポイントの流れがより忠実に反映され、データや情報は、各ステップの後にハブに返されるのではなく、外部のアプリケーション間を自由に流れます。端的に言えば、(訳注:従来のような)グリッド・ポータルはもはや不要であり、アプリケーション・ポータルだけが必要とされるということです。
ポートレットと JSR168
ポータルは、アプリケーションや情報配信の主要なソースとして浮上していますが、これは驚くことではありません。ある主要アナリストは、関連する情報、アプリケーション、ビジネス・プロセス、および人的資源に対して、特定の対象者が高度にパーソナライズされた形でアクセスや対話を行うことを可能にするメカニズムとして、ポータルを支持してきました。そのアナリストによれば、エンタープライズ・ポータルは、Global2000 企業において最も求められているユーザー・インターフェースとなっており、CIOが重点を置く技術分野のトップ 10 にランクされています。
ところが、つい最近まで、アプリケーション・ポータルの創造性とダイナミズムはポータル・ツールによって制限されていました。たいていの場合、それらのツールは、SunMicrosystems の Java? 2 Platform, Enterprise Edition (J2EE) のWeb アプリケーション・モデルをベースとする、カスタム開発されたアプリケーション・コンポーネントに基づいて開発されていました。ポータル開発の黎明期には、開発またはカスタマイズ用のポータルAPI が単一のポータル・フレームワーク向けだけに限定されることが多かったので、コンポーネントの相互運用性や再利用はあまり重要視されませんでした。さらに、アプリケーション・ポータルは生まれたばかりの概念でしたので、一貫したプレゼンテーション層の管理や、特定のアプリケーションをカプセル化するようなより大きなプロセスの管理も、あまり重要視されませんでした。
最近、可搬性のあるポータルの開発に対処する二つの重要な標準が登場しました。それは、WebServices for Remote Portlets Specification (WSRP) と Java SpecificationRequest 168 Portlet Specification (JSR168) です。WSRP は、プログラミング言語やプラットフォームに依存しない、プレゼンテーション指向のWeb サービスのための Web サービス記述言語 (Web Services Description Language(WSDL)) インターフェースおよびセマンティクスを定義したものです。一方のJSR168 は、標準の Java ポートレット API、ポートレット・コンテナー、およびAPI とコンテナー間のコントラクトを定義したものです。これら二つの新しい標準が、GridSphereProject などの新しい堅固なポータル・フレームワーク・プロジェクトと相まって、統合グリッド・インターフェースの開発を可能にしたのです。これらの標準を備えたポートレットは、ポータル環境の表現方法において最もエキサイティングな分野の一つとなっており、ポートレットをサポートするベンダー(およびオープン・ソース・プロジェクト) の数がそれを物語っています。それらの例としては、IBMWebSphereR、Sun ONE Portal Server、Oracle 9iAS、Jetspeed、GridSphere プロジェクトがあります。
Telescience など、アプリケーション中心のポータルは、ポートレットの可搬性のあるプレゼンテーション層のほか、ポータル間の(さらには外部アプリケーションに渡される)パーシステンス・ロジックとステート情報も利用します。これは、ポイントツーポイントの統合グリッド・インターフェースを実現するうえでなくてはならない情報です。
Telescience Portal
Telescience Portal の基本機能は、三次元顕微鏡検査データの取得、処理、可視化、および有用な情報の抽出に必要な一連のステップを、直感的なシングル・サインオンWeb 環境内でユーザーに提供する、ユーザーによって管理される三次元顕微鏡検査のワークフローです。すべての第1 世代のポータルと同様、Telescience V1.0 の大きな成果は、各種ミドルウェアに対して、単一のユーザー名とパスワードによるシンプルでWeb アクセス可能なインターフェースを作成したことでした。Telescience V1.0により、ユーザーは、カスタム・インターフェースを介してデータ・グリッドをブラウズしたり、Webにラップされたミドルウェアのコマンドを用いてジョブを開始したりすることができるようになりました。しかし、これらのインターフェースは、特定のミドルウェア・ツールに対するコマンドライン・インターフェースを反映させるように開発された個々の対話機能に合わせてばらばらに設計されたものでした。
第 1 回で説明した Telescience V2.0 のインフラストラクチャーは、個々のアクションによるインターフェースの枠を越え、グリッド・ミドルウェアではなく、ユーザーのプロセスに合わせて自動化されたよりリッチな環境への統合を可能にするものとなっています。たとえば、データ・グリッド・ポートレットによって表示される情報は、メインのワークフロー・ポートレット内でのアクションによって完全に制御することができます。ユーザーがワークフローのコンテキスト内で各種のアプリケーションを操作すると、データ・グリッド・ポートレットやその他のポートレットは、ユーザーのアクションを反映して動的に変化します。これは、作成や削除といった単純なディレクトリー操作から、オンザフライのフォーマット変換などの高度なファイル操作に至るまでのさまざまなアクションが対象となります。
図2. Telescience Portal
その機能は、各ユーザー固有のステートフルな情報をトラッキングする能力によって可能になったものです。TelescienceV1.0 は、ユーザーの進捗を実験のワークフローの全体から見た視点で追跡するという基礎的なことしか行えませんでした。それに対して、TelescienceV2.0 は、特定のアプリケーションの起動に使用される個々のパラメーターに至るまでのあらゆるユーザー情報を記録し、トラッキングします。この機能を実現したのが、ポートレット・フレームワークを介してパーシステンス・ロジックとステートに関する情報を管理する能力です。こうしたきめ細かい情報が手に入るようになったことにより、Telescienceのポートレットおよびアプリケーション・ミドルウェア間対話コンポーネント(Application to Middleware Interaction Component (ATOMIC)) ツールは、監査情報が法的に要求されるプロジェクトに従ったものとなりました。例としてはHIPAA法 (Health Insurance Portability and Accountability Act) の臨床データの管理要件が挙げられます。
また、第 1 回で説明したように、オンデマンドの統合グリッドでは、分析結果データが自由に流れて機器に伝わり、データ収集のパラメーターを精緻化することができます。Telescienceでは、ポータルによって管理されるリアルタイムのユーザー・アクションやステートに関する情報をフェデレーテッド・データベースに格納された過去の実験に基づくメタデータと組み合わせ、実験プロセスの最中にフィードバック・シナリオを作成することにより、そうしたプロセスを実現し始めています。このフィードバックこそが、前回の記事で紹介した統合グリッドの概念にとって、ひいてはデータを高速化する手段のみならずデータの質を向上させる手段としてのグリッドのビジョンにとって、極めて重要なものなのです。
よりリッチなグリッド・ユーザー環境へ
統合グリッドは、基礎となるミドルウェアのアクションがエンド・ユーザーに対して完全に透過的なアプリケーション環境への移行を可能にします。今や、この透過性をユーザー・インターフェースの構成要素全体に反映させることができるようになっています。端的に言って、コマンドライン引数を使いやすいチェック・ボックスやラジオ・ボタンに置き換えるだけのミドルウェア・ツールに対するインターフェースならば、もう十分にそろっています。ポートレット・インターフェースを備える統合グリッドは、よりリッチなユーザー環境への移行を可能にするとともに、そうした環境を特徴付けるものです。その環境では、ミドルウェアの機能は自然科学に固有のワークフロー内にネイティブにカプセル化され、特定のミドルウェア・ツールに対する明示的なインターフェースはもはや必要ではないのです。
参考文献 学ぶために
製品や技術を入手するために
著者について  | | | Abel W. Lin is the architect and technical lead for the Telescience Project at the National Center for Microscopy and Imaging Research. He has more than five years' experience applying grid and other computer science technologies to scientific processes. He designed and led the implementation of the first-generation proof-of-concept systems for the Telescience Portal and ATOMIC components of the Telescience Project, and is an interdisciplinary scientist with published research in biology and computer science. His interests include distributed systems architecture, software project management, and structural biology. Outside of the office, he is an avid reader, golfer, and bodysurfer.
|
記事の評価
| 
