Understanding OneMM Message Middleware Architecture and ActiveMQ Configuration

1. Basic Introduction and Component Architecture

Message‑oriented Middleware (MOM) is software infrastructure focused on sending and receiving messages between distributed systems.

As enterprise information systems become increasingly interconnected, data fragmentation and high coupling arise. Using MOM provides unified data access, decouples interactions, and offers two core functions: asynchrony and decoupling , which improve efficiency, availability, stability, and scalability.

The OneMM middleware enables decoupled and asynchronous communication between application modules and external systems such as ERP or payment platforms, replacing direct database sharing and addressing cross‑region data exchange challenges.

OneMM system component logical architecture diagram:

Message Middleware Main Components

(1) Message Sending Component: Receives external system call requests from application servers and forwards messages to local or cross‑center queues.

(2) Message Receiving Component: Retrieves messages from local or cross‑center queues and invokes business interfaces of external systems.

(3) Message Forwarding Component: Facilitates message forwarding between centers (e.g., Center 1 ↔ Center 2).

(4) Message Proxy Component: Receives cross‑center messages and routes them to appropriate topic subscription queues or detailed business queues.

(5) Queue Management Component: Configures and manages all message queues across centers.

(6) Message Queue Component: Provides creation, destruction, and management of queues using ActiveMQ.

(7) Message Cache Component: Uses Redis to cache asynchronous messages and retrieve results.

2. Message Flow Architecture

2.1 Synchronous Message Flow: The sending component creates a session and issues an asynchronous message; the synchronous process loops to receive broadcast messages from the Topic response queue, matches them by session ID, and returns results or times out. Diagram:

2.2 Asynchronous Message Flow: Asynchronous messages are cached in Redis; results are returned via newly created sessions, allowing producers to close sessions without waiting.

In practice, some projects keep the session open to poll Redis for results, enabling the callee to actively send back results and decide processing strategies such as batch handling.

3. Cross‑Center Message Sequence Diagrams

3.1 Cross‑Center Asynchronous Sequence Diagram 1

Asynchronous results are returned through newly created sessions; producers close sessions immediately.

3.2 Cross‑Center Asynchronous Sequence Diagram 2

When the callee does not close the session instantly, it polls Redis using the session ID to determine if a result is available, then sends the result back. This approach allows the callee to decide processing methods, such as batch processing, and improves decoupling.

3.3 Cross‑Center Synchronous Sequence Diagram 1

After sending an asynchronous message, the session blocks and repeatedly receives broadcast messages from the Topic response queue, using the session ID to identify the correct result.

3.4 Cross‑Center Synchronous Sequence Diagram 2 (Temporary Queue)

Synchronous results are returned via a temporary queue that holds messages only for the current session; the producer must keep the session open until the result arrives.

4. High Availability (Master‑Slave) and Load Balancing

All URLs for Topic subscription results, message receiving queues, broker send/receive queues, and forwarding topics must be configured as Failover addresses. ActiveMQ is set up in a master‑slave mode, so every component connects using a Failover URL.

5. ActiveMQ Configuration for the Message Queue Component

5.1 ActiveMQ Notification Configuration

Enabling advisory notifications can generate excessive messages, especially when using temporary queues for synchronous messaging. To disable them, add the following to activemq.xml:

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" advisorySupport="false">

5.2 Deleting Inactive Queues

Configure the broker to automatically purge inactive queues after a timeout:

<broker xmlns="http://activemq.apache.org/schema/core" schedulePeriodForDestinationPurge="10000" advisorySupport="false">
  <destinationPolicy>
    <policyMap>
      <policyEntries>
        <policyEntry queue=">" gcInactiveDestinations="true" inactiveTimoutBeforeGC="10000"/>
      </policyEntries>
    </policyMap>
  </destinationPolicy>
</broker>

5.3 Dead Letter Queue (DLQ) Configuration

DLQ stores failed or expired messages. To customize, use an individual dead‑letter strategy:

<policyEntry queue=">">
  <deadLetterStrategy>
    <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true"/>
  </deadLetterStrategy>
</policyEntry>

5.4 Reducing Excessive Queue Threads

Enable optimizedDispatch="true" to improve dispatch performance when many queues exist:

<policyEntry queue=">" optimizedDispatch="true"/>

6. Summary

6.1 Why Temporary Queues Cannot Implement Synchronous Messaging in ActiveMQ

Each message would create a temporary queue, leading to high concurrency without true queue behavior; maintaining open sessions for many simultaneous requests causes network congestion and blocking.

6.2 Advantages of Asynchronous Messaging

Asynchronous transmission decouples applications, uses short‑lived connections, and speeds up data transfer, resulting in higher stability, reduced latency, and better scalability under heavy load.