Backend Development 6 min read

Key Challenges and Transmission Models of Message Oriented Middleware (MOM)

The article explains the widespread use of message oriented middleware, outlines its core challenges such as synchronous vs. asynchronous delivery, security, persistence, redelivery, ordering, and describes the two main transmission models—point‑to‑point and publish/subscribe—while comparing JMS and AMQP standards.

Architecture Digest
Architecture Digest
Architecture Digest
Key Challenges and Transmission Models of Message Oriented Middleware (MOM)

Current RPC middleware technologies are widely used across many fields, and server‑to‑server message communication is a core function of these middleware solutions. Abstracting this functionality yields Message Oriented Middleware (MOM), which has become mainstream, with JMS and AMQP as the primary standards and a variety of implementations.

Message middleware must address several key problems:

1. Synchronous or asynchronous message transmission, especially asynchronous transmission. Synchronous sending blocks until a success response (or timeout) is received, while asynchronous sending returns immediately and can use callbacks (e.g., Java listeners) to handle success notifications.

2. Message security and persistence. In distributed systems, many stages exist between sending and receiving, any of which can cause message loss. Ensuring reliable delivery often relies on message persistence mechanisms.

3. Message redelivery. If the system is not idempotent, some scenarios require guaranteeing that messages are not redelivered, which is difficult; most solutions use state machines to enforce idempotency.

4. Message ordering. When required, preserving order in large‑scale, unreliable environments while maintaining efficiency and safety is challenging. Small‑scale systems can use server time queues or sequence numbers; local ordering can be achieved by batching sorted messages.

5. Transmission models: point‑to‑point (PTP) and publish/subscribe (Pub/Sub). PTP binds a unique identifier to a receiver, establishing a one‑to‑one relationship. Pub/Sub uses tags or group IDs so that any subscriber with the same tag receives the messages.

JMS (Java Message Service) is a J2EE‑specific specification that defines interfaces, transmission models, and message types but does not prescribe implementations or server architecture, nor does it guarantee ordering, security, or redelivery.

AMQP (Advanced Message Queuing Protocol) is a language‑agnostic, finance‑originated protocol that has become a focus in the messaging community. Unlike JMS, AMQP specifies an asynchronous application‑layer protocol intended to provide a universal toolkit for building message queue architectures.

Source: http://blog.csdn.net/huyiyang2010/article/details/5969944
backend architectureAMQPasynchronous messagingMessage MiddlewareJMSMOM
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.