Chapter 4. Core Architecture

HornetQ core is designed as a set of Plain Old Java Objects (POJOs). It has also been designed to have as few dependencies on external jars as possible. As a result HornetQ core has only one more jar dependency than the standard JDK classes: netty.jar. This is because some of the netty buffer classes are used internally.

Each HornetQ server has its own ultra high performance persistent journal, which it uses for messaging and other persistence.

Using a high performance journal allows persistence message performance, which is something not achievable when using a relational database for persistence.

HornetQ clients, potentially on different physical machines interact with the HornetQ server. HornetQ currently provides two APIs for messaging at the client side:

JMS semantics are implemented by a thin JMS facade layer on the client side.

The HornetQ server does not associate with JMS and does not know anything about JMS. It is a protocol agnostic messaging server designed to be used with multiple different protocols.

When a user uses the JMS API on the client side, all JMS interactions are translated into operations on the HornetQ core Client API before being transferred over the wire using the HornetQ wire format.

The server always just deals with core API interactions.

A schematic illustrating this relationship is described in Figure 4.1, “HornetQ Application Interaction Schematic”.

Figure 3.1 shows two user applications interacting with a HornetQ server. User Application 1 is using the JMS API, while User Application 2 is using the core Client API directly.

You can see from the diagram that the JMS API is implemented by a thin facade layer on the client side.