This topic has not yet been written. The content below is from the topic description.
5.1. Core Architecture HornetQ core is designed simply as set of Plain Old Java Objects (POJOs) - we hope you like it's clean-cut design. We've also designed it to have as few dependencies on external jars as possible. In fact, HornetQ core has only one jar dependency, netty.jar, other than the standard JDK classes! This is because we use some of the netty buffer classes internally. This allows HornetQ to be easily embedded in your own project, or instantiated in any dependency injection framework such as JBoss Microcontainer, Spring or Google Guice. Each HornetQ server has its own ultra high performance persistent journal, which it uses for message and other persistence. Using a high performance journal allows outrageous persistence message performance, 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: Core client API. This is a simple intuitive Java API that allows the full set of messaging functionality without some of the complexities of JMS. JMS client API. The standard JMS API is available at the client side. JMS semantics are implemented by a thin JMS facade layer on the client side. The HornetQ server does not speak JMS and in fact does not know anything about JMS, it's 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 shown in figure 3.1 below: 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.