複数のアプリケーションをクラウドプラットフォームに簡単に追加できるプラットフォームを開発し、アプリケーションをSaaSベースで提供できるようにするプロジェクトに取り組んでいます。すべてのアプリへのシングル サインオン アクセスがあります (おそらく Open SSO を介して)。
1. Mule ESB (さまざまな言語で開発されたアプリを統合するため) 2. GigaSpaces XAP (スケーラビリティーのため) 3. Appistry Cloud IQ Platform (アプリケーションをアップロードするため) 4. ホスティング用の GoGrid
これは正しいツールの組み合わせですか? 他の組み合わせをお勧めできますか？
私は Appistry の最初のエンジニアの 1 人であり、現在はプロダクト マネージャーであることを前もって述べておきます。技術的な事実に固執します。:-)
おっしゃるとおり、Appistry CloudIQ Manager を使用して、クラウド サーバー全体でアプリケーションと関連サービスの展開、管理、ライフサイクルを簡素化できます。Manager は、任意のサービスまたはサービスとアプリケーションの組み合わせでこれを行うことができ、それらが各サーバーで稼働していることを確認します。Manager は、サーバーの増減に合わせてアプリケーションをスケールアップおよびスケールダウンします。CloudIQ Manager は、Mule および GigaSpaces で正常に動作します。
他の組み合わせ、特にスケーラビリティの要件、および異なる言語で開発されたアプリの統合については、CloudIQ エンジンをアプリケーション プラットフォームと見なすことができます。エンジンは、対処する部分に応じて、GigaSpaces の代わりに使用することも、GigaSpaces と組み合わせて使用することもできます。
CloudIQ Engine は、完全に分散化されたアプリケーション コンテナーです。エンジンは、クライアント側とクラウド側の両方で、統合のために複数の言語をサポートしています。
クライアント側では、Spring と .NET リモーティングを使用してエンジンがホストするオブジェクトを呼び出したり (呼び出し元と呼び出し先が同じ言語である必要があります)、CloudIQ クライアント API (C/C++/Java/.NET/SWIG ラップ可能) を使用したりできます。ユーザー定義のプロセス フローでリクエストを送信するため、ESB が不要になる可能性があります。フローはエンジン上のクラウドで実行され、1 つのリクエストで複数のメソッドの呼び出しを調整できます。メソッドは異なる言語にすることができます。
クラウド側では、Java オブジェクト (POJO および Spring Bean) と .NET オブジェクト (PONO)、および C/C++ ライブラリをエンジン アプリケーションとしてデプロイできます。Java および .NET オブジェクトは変更せずにデプロイできます。C/C++ (およびその他のバイナリ ライブラリ) には、ラッパー コードが必要になる可能性があります。メタデータは、コードのワークロード ポリシーとその他のクラウド側の動作を記述します。
エンジン アプリケーションは完全に対称的です。クラウド内のすべてのサーバーがアプリケーション コードを実行します。組み込みのソフトウェア ベースの負荷分散機能により、ジョブを最も適切に処理できるサーバーに要求が送信されます。コードは、コードを変更することなく、プラットフォームからスケーラビリティを継承します。スケールを超えて、アプリケーションは信頼性と自動フェイルオーバーを無料で利用でき、障害に応じてアプリケーションがどのように動作するかをメタデータで定義する機能も備えています。エンジンは、非スレッドセーフでない限り、使用可能なすべての CPU コアにわたってコードを自動的にスケーリングします。コードがスレッドセーフでない場合、CloudIQ は効率的に実行できますが、すべてのコアを利用しないという犠牲が伴います。
簡単に試すことができます。CloudIQ Platform Community Edition では、最大 5 台のサーバーおよび/または 10 個の処理コア (実稼働を含む) でソフトウェアを無制限に無料で使用できます。コミュニティ エディションは Appistry Peer2Peer で入手できます (登録が必要です): Appistry Peer2Peer
Appistry の顧客である Presidio Health は、Java ベースの CloudIQ Engine アプリケーションを GoGrid 上で実行しており、大きな成功を収めています。ここに技術的な議論を含むウェビナーとケーススタディがあります（登録が必要です）：Appistry Resource Library
あなたは実際に非常に優れたスタックを選択しています。Mule と Gigaspaces は頻繁に一緒に使用され、Mule ESB Enterprise (オープン ソース バージョンではない) は実際に Gigaspaces テクノロジを組み込んで高可用性を提供します。
GoGrid は優れたプラットフォームを備えており、Mule ESB、GigaSpaces、Appistry をサポートする企業はすべて GoGrid のパートナーであるため、そのスタックを使用した優れたサポートが期待できます。私は Appistry にあまり詳しくないので、それらについて直接コメントすることはできません。