152 lines
10 KiB
XML
152 lines
10 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!-- ============================================================================= -->
|
|
<!-- Licensed to the Apache Software Foundation (ASF) under one or more -->
|
|
<!-- contributor license agreements. See the NOTICE file distributed with -->
|
|
<!-- this work for additional information regarding copyright ownership. -->
|
|
<!-- The ASF licenses this file to You under the Apache License, Version 2.0 -->
|
|
<!-- (the "License"); you may not use this file except in compliance with -->
|
|
<!-- the License. You may obtain a copy of the License at -->
|
|
<!-- -->
|
|
<!-- http://www.apache.org/licenses/LICENSE-2.0 -->
|
|
<!-- -->
|
|
<!-- Unless required by applicable law or agreed to in writing, software -->
|
|
<!-- distributed under the License is distributed on an "AS IS" BASIS, -->
|
|
<!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -->
|
|
<!-- See the License for the specific language governing permissions and -->
|
|
<!-- limitations under the License. -->
|
|
<!-- ============================================================================= -->
|
|
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % BOOK_ENTITIES SYSTEM "ActiveMQ_User_Manual.ent">
|
|
%BOOK_ENTITIES;
|
|
]>
|
|
<chapter id="architecture">
|
|
<title>Architecture</title>
|
|
<para>In this section we will give an overview of the ActiveMQ high level architecture.</para>
|
|
<section>
|
|
<title>Core Architecture</title>
|
|
<para>ActiveMQ core is designed simply as set of Plain Old Java Objects (POJOs) - we hope you
|
|
like its clean-cut design.</para>
|
|
<para>We've also designed it to have as few dependencies on external jars as possible. In
|
|
fact, ActiveMQ 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.</para>
|
|
<para>This allows ActiveMQ to be easily embedded in your own project, or instantiated in any
|
|
dependency injection framework such as JBoss Microcontainer, Spring or Google
|
|
Guice.</para>
|
|
<para>Each ActiveMQ server has its own ultra high performance persistent journal, which it
|
|
uses for message and other persistence.</para>
|
|
<para>Using a high performance journal allows outrageous persistence message performance,
|
|
something not achievable when using a relational database for persistence.</para>
|
|
<para>ActiveMQ clients, potentially on different physical machines interact with the ActiveMQ
|
|
server. ActiveMQ currently provides two APIs for messaging at the client side:</para>
|
|
<para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>JMS client API. The standard JMS API is available at the client
|
|
side.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
<para>JMS semantics are implemented by a thin JMS facade layer on the client side.</para>
|
|
<para>The ActiveMQ server does not speak JMS and in fact does not know anything about JMS,
|
|
it is a protocol agnostic messaging server designed to be used with multiple different
|
|
protocols.</para>
|
|
<para>When a user uses the JMS API on the client side, all JMS interactions are translated
|
|
into operations on the ActiveMQ core client API before being transferred over the wire
|
|
using the ActiveMQ wire format.</para>
|
|
<para>The server always just deals with core API interactions.</para>
|
|
<para>A schematic illustrating this relationship is shown in figure 3.1 below:</para>
|
|
<para>
|
|
<graphic fileref="images/architecture1.jpg" align="center"/>
|
|
</para>
|
|
<para>Figure 3.1 shows two user applications interacting with a ActiveMQ server. User
|
|
Application 1 is using the JMS API, while User Application 2 is using the core client
|
|
API directly.</para>
|
|
<para>You can see from the diagram that the JMS API is implemented by a thin facade layer on
|
|
the client side.</para>
|
|
</section>
|
|
<section>
|
|
<title>ActiveMQ embedded in your own application</title>
|
|
<para>ActiveMQ core is designed as a set of simple POJOs so if you have an application that
|
|
requires messaging functionality internally but you don't want to expose that as a
|
|
ActiveMQ server you can directly instantiate and embed ActiveMQ servers in your own
|
|
application.</para>
|
|
<para>For more information on embedding ActiveMQ, see <xref linkend="embedding-activemq"
|
|
/>.</para>
|
|
</section>
|
|
<section>
|
|
<title>ActiveMQ integrated with a JEE application server</title>
|
|
<para>ActiveMQ provides its own fully functional Java Connector Architecture (JCA) adaptor
|
|
which enables it to be integrated easily into any JEE compliant application server or
|
|
servlet engine.</para>
|
|
<para>JEE application servers provide Message Driven Beans (MDBs), which are a special type
|
|
of Enterprise Java Beans (EJBs) that can process messages from sources such as JMS
|
|
systems or mail systems.</para>
|
|
<para>Probably the most common use of an MDB is to consume messages from a JMS messaging
|
|
system.</para>
|
|
<para>According to the JEE specification, a JEE application server uses a JCA adapter to
|
|
integrate with a JMS messaging system so it can consume messages for MDBs.</para>
|
|
<para>However, the JCA adapter is not only used by the JEE application server for <emphasis
|
|
role="italic">consuming</emphasis> messages via MDBs, it is also used when sending
|
|
message to the JMS messaging system e.g. from inside an EJB or servlet.</para>
|
|
<para>When integrating with a JMS messaging system from inside a JEE application server it
|
|
is always recommended that this is done via a JCA adaptor. In fact, communicating with a
|
|
JMS messaging system directly, without using JCA would be illegal according to the JEE
|
|
specification.</para>
|
|
<para>The application server's JCA service provides extra functionality such as connection
|
|
pooling and automatic transaction enlistment, which are desirable when using messaging,
|
|
say, from inside an EJB. It is possible to talk to a JMS messaging system directly from
|
|
an EJB, MDB or servlet without going through a JCA adapter, but this is not recommended
|
|
since you will not be able to take advantage of the JCA features, such as caching of JMS
|
|
sessions, which can result in poor performance.</para>
|
|
<para>Figure 3.2 below shows a JEE application server integrating with a ActiveMQ server via
|
|
the ActiveMQ JCA adaptor. Note that all communication between EJB sessions or entity
|
|
beans and Message Driven beans go through the adaptor and not directly to
|
|
ActiveMQ.</para>
|
|
<para>The large arrow with the prohibited sign shows an EJB session bean talking directly to
|
|
the ActiveMQ server. This is not recommended as you'll most likely end up creating a new
|
|
connection and session every time you want to interact from the EJB, which is an
|
|
anti-pattern.</para>
|
|
<para>
|
|
<graphic fileref="images/architecture2.jpg"/>
|
|
</para>
|
|
<para>For more information on using the JCA adaptor, please see <xref
|
|
linkend="appserver-integration"/>.</para>
|
|
</section>
|
|
<section>
|
|
<title>ActiveMQ stand-alone server</title>
|
|
<para>ActiveMQ can also be deployed as a stand-alone server. This means a fully independent
|
|
messaging server not dependent on a JEE application server.</para>
|
|
<para>The standard stand-alone messaging server configuration comprises a core messaging
|
|
server, a JMS service and a JNDI service.</para>
|
|
<para>The role of the JMS Service is to deploy any JMS Queue, Topic and ConnectionFactory
|
|
instances from any server side <literal>activemq-jms.xml</literal> configuration files.
|
|
It also provides a simple management API for creating and destroying Queues, Topics and
|
|
ConnectionFactory instances which can be accessed via JMX or the connection. It is a
|
|
separate service to the ActiveMQ core server, since the core server is JMS agnostic. If
|
|
you don't want to deploy any JMS Queue, Topic or ConnectionFactory instances via server
|
|
side XML configuration and don't require a JMS management API on the server side then
|
|
you can disable this service.</para>
|
|
<para>We also include a JNDI server since JNDI is a common requirement when using JMS to
|
|
lookup Queues, Topics and ConnectionFactory instances. If you do not require JNDI then
|
|
this service can also be disabled. ActiveMQ allows you to programmatically create JMS and
|
|
core objects directly on the client side as opposed to looking them up from JNDI, so a
|
|
JNDI server is not always a requirement.</para>
|
|
<para>The stand-alone server configuration uses JBoss Microcontainer to instantiate and
|
|
enforce dependencies between the components. JBoss Microcontainer is a very lightweight
|
|
POJO bootstrapper.</para>
|
|
<para>The stand-alone server architecture is shown in figure 3.3 below:</para>
|
|
<para>
|
|
<graphic fileref="images/architecture3.jpg"/>
|
|
</para>
|
|
<para>For more information on server configuration files see <xref
|
|
linkend="server.configuration"/>. $ </para>
|
|
</section>
|
|
</chapter>
|