HPや現在のRed Hat/JBossによるトランザクション技術(リンク)を元々手がけたArjuna Technologies(リンク)が、フォルトトレラントなグリッドインフラストラクチャに取り組んでいる(参考記事)、と昨年報告した。当時はトライできることに限りがあったが(リンク)、その記事により、多くの人が興味を持った。しかし、それから1年弱の時を経てArjunaは先頃、「Arjuna Agility Federated Cloud Platform」(リンク)という、より具体的なもののリリースを発表した。必須になっているホワイトペーパー(PDF)とオンラインセミナー(リンク)（かなり良くできている）もあるが、Agilityについて重要なことの大半(リンク)はブラウズ(リンク)できる。また、次のように説明されている。
このプラットフォームは、「多種多様なアクセスプロトコル向けに、プロトコルゲートウェイを用いたサービスベースになっている」と至るところで説明があるため、ESBを中心に据えているように思われる。管理の境界線を超えて制御しながら共有するサービス(リンク)や、サービスの動的供給(リンク)など、クラウド・プラットフォームで当たり前とされるような常連の機能が若干見受けられるが、このプラットフォームがいっそう面白くなるような、斬新ともいえる以下の特徴もある。:
〔Agility〕とは、より柔軟性に富んだインフラストラクチャというアプローチを通じてビジネスのアジリティを改善するべく設計された「クラウドコンピューティングを統合したプラットフォーム」です。「統合した」と呼ぶ所以は、企業内外の自律的かつ協力関係にあるビジネス関係者が指定したITリソースによって、Agility™が構築されているからです。説明はさらに次のように続く。
組織でリソースを共有する場合に実際の障壁となっているのは信頼と権限ですが、Agility™は管理の行き届いた方法を提供することにより、企業が「内部クラウド」を有機的に拡大できるようにします。リソース所有者は、指定のリソースにポリシーを添付することによりそのリソースに対する管理権を持ち続けますが、ポリシーが記述しているのは、Agility™によってこのリソースを共有可能にする条件です。ひとたび指定され、ポリシーの対象となったリソースは、ビジネスで常に変化するIT需要を満たすように、Agility™が動的に供給します。他のクラウド・プラットフォームの中には、こうした供給を実現する上で必要なサービスやツールが、既存インフラストラクチャの投下資本と共存出来るものもある(リンク)。しかし約束された利益をもたらすためには、Agilityは究極的には、クラウド全体を制御する必要がある。
Whilst Agility™は既存インフラを傷つけることなく、既存インフラ上にデプロイできますが、Agility™の管理下に入るITリソースが増えるにつれて、Agility™は能力を発揮するようになります。この新しいプラットフォームを既存のソリューションと比較・対照するのもいいが、Agility™は明らかにまだ開発の初期段階にある。しかし、更新版のホワイトペーパー(PDF)には多少の手がかりを見ることができる。
他のアプローチとは異なり、Agilityは企業のITインフラストラクチャやアプリケーションに「大改革」を強いるようなことはありません。完全な管理が必要という説明があるため、「大改革を強いない」ことと当初は矛盾するように思われるが、この不可能を可能にするために多大な努力が費やされたようである(リンク)。実際、入手できた情報によれば、Agilityでは「既存インフラストラクチャのいかなる再構成や変更も必要とせず」、さらに、「リソース所有者が許可しなければ、そのリソースを共有する必要もない」。こうした非侵襲的なアプローチはユーザーまでおよぶので、ユーザーはサービス利用時に、Agilityの存在を認識する必要さえない。
このプラットフォームは、「多種多様なアクセスプロトコル向けに、プロトコルゲートウェイを用いたサービスベースになっている」と至るところで説明があるため、ESBを中心に据えているように思われる。管理の境界線を超えて制御しながら共有するサービス(リンク)や、サービスの動的供給(リンク)など、クラウド・プラットフォームで当たり前とされるような常連の機能が若干見受けられるが、このプラットフォームがいっそう面白くなるような、斬新ともいえる以下の特徴もある。:
- サービスとリソースはポリシーの定義を通じて、Agilityから利用可能になる。例を挙げれば、残りのインフラストラクチャがオーバーロードになってビジネスが危機に直面している時などといった、特別な状況において、Agilityのリソースを他のユーザーが利用できるようにするポリシーである。残念ながら、Agilityでポリシーをどのように定義するのかについて明確な説明はなく、たとえば、WS -Policyのようなものなのか？ 実際、すべての関係はサービスアグリーメント(リンク)という表現になっている。クラウドコンピューティング全般にさらにSOAのガバナンスアプローチを取り入れることを目指した、一段階なのか。
- その上、高度のバーチャルデプロイメント記述言語を備えており、この言語を使って、サービスとサービスが必要とするハードウェアリソースとソフトウェアリソース、サービスとリソース間の関係を記述する。 ここでも、SOAガバナンス(リンク)とサービスの依存性グラフ(リンク)の作業面で、若干の類似がある。しかし、クラウドコンピューティングでは斬新なアプローチと思われる。そうでなければ、ベンダーロックインの問題を軽減するのに役立つ標準化を施すべき箇所なのかもしれない。
…障害が検知されたらいつでも、リソースの動的な再デプロイメントをサポートすることにより、信頼性を向上できます。障害後には、サービス要件がITインフラストラクチャから切り離されるため、Agilityはサービス要件を満たすのに利用可能な代替リソースを識別でき、その後、サービス要件を引き続き確実に実現するべく、そうしたリソースを使用するように、Agilityがシステムを再構成できます
Agilityが既存の障害警戒メカニズム(リンク)と連動するか、あるいはAgility独自のメカニズムを使うかについては説明がない。より詳細なアーキテクチャの説明なくしては、どちらとも言えない。しかし確実なことが1つあるようだ。今回、循環トランザクション(リンク)は（インフラストラクチャの隠れた一部分になっていない限り）計画には入っていないようである。