第4章 コアアーキテクチャー

HornetQ コアは、Plain Old Java Object (POJO) のセットとして設計され、できるだけ外部の jar に依存しないよう設計されています。結果として、HornetQ コアは標準的な JDK クラスよりも １ つだけ多くの jar 依存関係 （netty.jar） を持ちます。これは、 いくつかの netty バッファクラスが内部で使用されているためです。

Each HornetQ サーバーは、メッセージと他の永続化に使用する独自の非常に高いパフォーマンスの永続ジャーナルを持ちます。

高パフォーマンスのジャーナルを使用すると、永続メッセージのパフォーマンスが向上します。これは、永続化のためにリレーショナルデータベースを使用する場合は、実現できません。

HornetQ クライアント (異なる物理マシンにある場合がある） は、HornetQ サーバーと対話します。HornetQ は現在クライアント側でのメッセージに対して ２ つの API を提供します。

JMS セマンティクスは、クライアント側のシン JMS ファサードレイヤーによって実装されます。

HornetQ サーバーは JMS と関連付けられず、JMS に関して何も知りません。HornetQ サーバーは、さまざま複数のプロトコルで使用するよう設計されたプロトコルアグノスティックメッセージサーバーです。

ユーザーがクライアント側で JMS API を使用する場合、すべての JMS の対話は、HornetQ ワイヤーフォーマットを使用してワイヤー上で転送する前に HornetQ コアクライアント API で操作に変換されます。

サーバーは常にコア API の対話だけを処理します。

この関係を示す概略図は、図4.1「HornetQ アプリケーションの対話の概略図」 で示されています。

図 3.1 は、HornetQ サーバーと対話している 2 つのユーザーアプリケーションを示しています。ユーザーアプリケーション 1 は JMS API を使用し、ユーザーアプリケーション 2 はコアクライアント API を直接使用しています。

図では、JMS API がクライアント側のシンファサードレイヤーによって実装されていることを確認できます。