Home > コンセプトペーパ > Magic xpi 4.x のアーキテクチャ > アーキテクチャーの概要
Magic xpi 4.xは、以下のソフトウェア・コンポーネント/要素から構成されています。
インメモリ・データグリッド (IMDG) …… インメモリ・データグリッドはメモリ内に大量のデータを保存するために、一緒に動作する複数のマシンのインスタンス(物理的または仮想)上で実行する複数のサーバプロセスから構成されるミドルウェアソフトです。そして、これによって高性能で弾力性があるスケーラビリティとフェイルセーフ冗長性を提供します。
Space …… Spaceは、データグリッド上で実行するデータとビジネスロジック・コンテナ(データベースインスタンスと同じ)です。データグリッドには、複数のSpaceを含めることができます。しかし、Magic xpi 4.xは、複数のプロジェクトを実行するために、単一Spaceを使用します。冗長性とスケーラビリティのために、Spaceのデータとビジネスロジックはデータグリッドに参加しているすべてのマシン全体で複製され、分割されます。そして、マシンまたはソフトウェアに障害が発生しても、継続してサービスを提供することができます。
Magicプロセスユニット (PU) …… Magic xpa PUは、Space上で動作するソフトウェア・モジュールです。プロジェクトオブジェクト上でさまざまな管理タスクを実行します。このPUは、すべてのMagic xpiオブジェクトをモニタし、管理して、サーバが適切に実行していることを確認します。Magic PUには、以下のような機能があります。
フロータイムアウト状況を確認して、復旧を行います。
ハング/クラッシュしたワーカとサーバを特定して、復旧を行います。
管理メッセージを実行サーバに送ります。
完了したフローリクエストをクリアにします。
プロジェクトエンティティに関する統計を集めます。
様々なPUは、GigaSpaces UIのEvent Containersで表示されます。GigaSpaces UIには、追加情報が表示されます。例えば、[Processed]カラムには、各PUで処理されたリクエスト数や、発生したタイムアウトの数、などが表示されます。
Magic xpiサーバ …… Magic xpiサーバは、Magic xpi 4.x統合プロジェクトのロジックを実行する複数のサーバプロセスから構成されているアプリケーションサーバ・ソフトウェアです。各Magic xpiサーバのプロセス(エンジン)は、複数のスレッド(ワーカ)から構成されています。各ワーカは、さまざまな統合プロジェクト・ロジックを実行することができます。.
メッセージ・フロー –…… Magic xpiエンジンは、GigaSpacesプロキシを経由してSpaceと通信します。これはクライアント・アプリケーションをSpaceに接続するソフトウェア・モジュールです。各Magic xpiエンジンは、フロースレッドとトリガスレッドを実行させることができます。さらに、他のプロセス・Space(例えばHTTPトリガ、またはWeb Serviceトリガ)で実行する外部トリガがあります。トリガは、ワーカによって同期または、非同期で処理される新しいフロー呼出リクエストメッセージを作成します。
トリガーアーキテクチャ
外部トリガ
Magic xpiはさまざまなリクエストを受け取ることができます。
HTTP IISに渡されるMagic xpiのリクエストは、<Magic xpiインストールフォルダ>\Runtime\scripts\config\mgreq.ini に従って、<Magic xpiインストールフォルダ>\Runtime\scripts\bin\MgWebRequester.dll ファイルによって処理されます。
Apache Tomcatサーバ(Java)に渡されるMagic xpiのリクエスタは、-Dcom.magicsoftware.requester.confパラメータの CATALINA_HOME\bin\startup.batファイルで定義されるmgreq.iniファイルに従って<Magic xpiのインストール>\Runtime\Support\JavaWebRequester\TomCat\magicxpi4.warファイルによって処理されます(Magic xpi - Java-Based Installation Instructions.pdf を参照してください)。
Systinetサーバ(WSサーバ)に渡されるMagic xpiのリクエストは、-Dcom.magicsoftware.requester.confパラメータの<SSJ for Magic xpi>\bin\server.batファイルの中で定義されるmgreq.iniファイルに従って、<Magic xpiインストールフォルダ>\lib\MgRequester.jarファイルによって処理されます。
これらのすべては、SpaceのTemp msg(上記のイメージで黄色で表示されています)に置かれます。
各トリガタイプは、独自のTemp msgタイプを持っていて、GigaSpaces UIで表示されます。このイメージでは、Temp msgは、アーキテクチャを説明するためにすべてのトリガで使用されます。 |
プッシュトリガ
プッシュトリガから渡されるMagic xpiのリクエストは、Magic xpiサーバープロセス(mgreq.iniファイルは関係しません)内の<Magic xpi installation>\Runtime\java\lib\uniRequester.jar ファイル(の Mgrequest クラス)によって処理されます。これは、Spaceに Temp msgを置きます。これは、WS/HTTPとは異なり、個別のプロセスでリクエストを処理します。
ポーリングトリガ
トリガを呼び出す他のすべてのリクエストは、直接、SpaceにFlowRequestメッセージを書き込むMagic xpiサーバプロセス(mgreq.iniファイルは関係ません)で処理されます。
MagicxpiServer.exeファイルで利用可能なワーカは、FlowRequestメッセージを受け取り、プロジェクトの制約(最大インスタンス数やライセンス数など)を考慮して処理します。
* ユーザリクエスト= mgrqcmdl, CallRemote
プロセスユニット (PUs)
Spaceには、2つの専用jのPU(1つは、http2ifr という名前のHTTPトリガタイプのPU、もう一つはexternalRequestToFlowRequest*という名前の他のすべてのためのPU)があります。これらは、Tempo msg をFlowRequestメッセージに変換します。これらのFlowRequestメッセージは、MagicxpiServer.exeファイルによって処理され、モニタやGigaSpaces UI(データタイプの名前は、com.magicsoftware.xpi.server.messages.FlowRequestです)に表示されます。
* http2ifrとexternalRequestToFlowRequest PUは、GigaSpaces UIのイベントコンテナセクションに表示されます。
サーバアーキテクチャについての徹底的に理解することは、プロジェクトのリカバリ設定を定義する際に非常に有益です。以下の図は、サーバアーキテクチャがどのように動作するかを示しています。
ROOTFSID 1 |
ルートフローシーケンスID(ルートFSID)は、実行ツリー内のすべてのフローと分岐に対して共通です。 |
ROOTFSID 4 |
新しい実行ツリーを開始するスタンドアロンの分岐。 |
ROOTFSID # |
番号は、初期のFSIDと同じ数値です。 |
FSID |
各新規委フローは、新規フローシーケンスID(FSID)を受け取ります。スタンドアロンの分岐は、個別のフローと考えられるので、独自の新しいFSIDを取得します。 |
1...5 = Flow Request ID |
呼び出された各フロー、並列分岐、またはスタンドアロンの分岐は、フローリクエストメッセージによって呼び出されます。それぞれ独自のIDを持っています。「フロー呼出」ステップと「フロー呼出」の送り先は、リニア実行の一部で、独自のフローリクエストメッセージを持っていません。 |
I, II |
各フロー呼出の繰返しのために、起動されたフロー(I)には新しいFSIDが割り当てられます。起動されたフロー(I)が起動元に返ると、フロー呼出(II)は、そのオリジナルのFSIDを残します。 |