アーキテクチャー
MCIアーキテクチャーは、インターフェースを処理するオンラインアーキテクチャーとセッションを管理するセッションアーキテクチャーに区分され、ロギング時に必要なロギングアーキテクチャーおよびL4 Switchの役割をするポーリングアーキテクチャーで構成されている。
オンラインアーキテクチャー
APtoAPなどの一般取引インターフェースが実行される環境で、ゲートウェイコンポーネントとインターフェースコンポーネントで構成される。
ゲートウェイコンポーネント
A. 通信プロトコル処理
通信プロトコル処理のために、コネクション情報とコネクショングループ情報を管理する。
コネクション情報は、接続対象の接続情報および通信処理のための詳細属性で、コネクショングループは、同じインターフェースを複数のコネクションが処理する場合に各コネクションの負荷分散ポリシーを管理する。
コネクション情報の詳細設定は、コネクション設定を参照する。
B. 電文伝送
連携対象から受信した電文を、インターフェースコンポーネントで伝達するか、インターフェースコンポーネントで受信した電文を連携対象に送信する。
この時、キャラクターセットのエンコーディング/デコーディング処理、および全電文の暗号・復号化処理を行う。
インターフェースコンポーネント
インターフェースコンポーネントは、インターフェース処理を行い、イベントハンドラと処理フローで構成される。
A. イベントハンドラ
イベントハンドラは、ゲートウェイコンポーネントから非同期方式で伝達された電文を解析し、インターフェースIDと要求/応答を区分する。
また、インターフェース制御状態を確認して処理フローに伝達する。
B. 処理フロー
処理フローは、電文変換などのインターフェース処理を行う。
要求処理を行う要求フローと応答処理を持つ応答フローがあり、インターフェースごとに定義する。
それぞれのフローは、多数のルーターで構成される。
- フロー
Apache Camelのルーターグループを意味する。 それぞれの単位機能のルーターを順序に呼び出し、オンラインインターフェースを処理する。
BXIでは、電文変換などのインターフェース処理時に必要な基本フローを提供する。 特化したインターフェース要件を処理するために、フローを開発して適用することができる。
- ルーター
Apache CamelのRouteのことで、フローで処理される単位機能である。
例えば、電文をマップに変換するUnmarshalは、１つのルーターが提供する機能である。 BXIは、インターフェースの取引処理で一般的に使用されるルーターを提供する。
一般的に提供されるルーターの機能以外の追加機能が必要な場合は、新規にルーターを開発して適用することができる。 開発方法は、Customizingを参照する。
セッション管理アーキテクチャー
MCIは、IMDG(In-Memory Data Grid)のInfinispanをEmbeddedモードで使用してセッション情報を管理する。
Engineのオンラインインスタンスが複数実行される場合、Infinispanは自動的にクラスタを構成してセッション情報を互いに共有する。
Infinispanは、クラスタ構成にJGroupsメッセージングライブラリを使用する。 JGroupsメッセージ通信のためのTCP方式とUDP方式をサポートする。 JGroupsメッセージ通信方式は、オンラインインスタンス起動シェル（container.sh）のbxi.infini.configオプションから選択する。 デフォルトはUDP方式を使用する。
TCP
インスタンスの各Embedded Infinispanは、listen状態のソケットをオープンし、互いを発見してクラスタを構成し、データを共有する。 TCP方式は、他のネットワーク上に存在するノードとクラスタを構成できる。
UDP
UDP方式は固定ポートでマルチキャストを送信して互いを発見する。
その後、互いの特定ポート(無作為決定)に向けてユニキャストを利用してデータを共有する。 このため、UDP方式は、ノード間の利用ポートをすべてオープンする必要があり、またマルチキャストを利用するため、同じサブネット上に存在する必要がある。
通信方式は、サイト環境およびセキュリティポリシーによって選択できる。
ロギングアーキテクチャー
BXIのログ処理方式は、オンラインインスタンスが直接ロギングするローカル(L)方式と、別のロギングアーキテクチャーを活用したリモート(R)方式に区分される。
ローカル(L)方式
インスタンスが、オンラインインターフェースを処理しながら、直接DB/ファイルにログを格納する方式である。 オンライン取引量が多くない場合に使用する。
リモート(R)方式
インターフェース処理時に発生するログデータを非同期でロギングする。 オンライン取引量が多い場合、インターフェース処理の性能向上のために使用する。
ログデータは、非同期ロギングアーキテクチャーで、Apache Kafkaに非同期で伝達され、レシーバーコンポーネントおよびロギングコンポーネントで構成された、別のロギングインスタンスでDB/Fileに記録される。
☑ Apache Kafka
大容量のリアルタイムログ処理に特化したアーキテクチャーを提供するオープンソースソフトウェアである。
☑ ロギングインスタンス
ロギングインスタンスは、下記のコンポーネントで構成される。
- レシーバーコンポーネント : Kafkaに格納されているログをKafkaコンシューマーから読み込んでロギングコンポーネントに伝達する。
- ロギングコンポーネント : DBやファイルにログ情報を格納する。 ログ設定およびログ管理は、ログ管理を参照する。
ポーリングアーキテクチャー
BXIでは、システムとの連携時にL4 Switchを使用しない場合、L4 SwitchのFail-Over機能に代わる機能を提供する。
定期的なメッセージポーリング方式でこれに対応するため、インターフェース処理を実行するインスタンス以外に別のシステムポーリングインスタンスが必要である。 インターフェース処理を行うオンラインインスタンスは、システムポーリングインスタンスのシステム状態情報を利用して取引を処理する。
システムポーリングインスタンス
HTTPでシステムと定期的にメッセージを送受信しながら状態を確認する。
システム状態情報は、メモリー上で管理され、別のDB同期スレッドが、システムポーリング状態をDBに同期する。
オンラインインスタンス
定期的にDBのシステムポーリング状態情報をメモリーに同期し、このシステム状態情報を使用して、正常に取引処理が可能だと判断されたシステムに対して、取引を要求する。
システムポーリングインスタンスはノード別に１つだけ登録することができ、１つのシステムポーリングインスタンス情報として複数のノードで使用することができる。 ポーリングアーキテクチャーを使用するための詳細設定はシステムポーリングを参照する。