Architecture DistributedSystem

【Distributed System】Message Oriented Middleware

Posted by 西维蜀黍 on 2021-10-24, Last Modified on 2023-09-29

Message Oriented Middleware (MOM)

Message Oriented Middleware is a concept that involves the passing of data between applications using a communication channel that carries self-contained units of information (messages).

Note that since the message broker is the most component in a Message Oriented Middleware, therefore, message broker sometimes is used with Message Oriented Middleware interchangeably.

In a MOM-based communication environment, messages are usually sent and received asynchronously. Using message-based communications, applications are abstractly decoupled; senders (producers) and receivers (consumers) are never aware of each other. Instead, they send and receive messages to and from the messaging system. It is the responsibility of the messaging system (MOM) to get the messages to their intended destinations.

Messaging System

The messaging system is the core of a Message Oriented Middleware, which is responsible for managing the connection points between multiple messaging clients, and for managing multiple channels of communication between the connection points.

The messaging system is usually implemented as a software process, which is commonly known as a message server or a message broker. Message servers are usually capable of being grouped together to form clusters that provide advanced capabilities such as load balancing, fault tolerance, and sophisticated routing using managed security domains.

MOM and ESB

Enterprise messaging is at the core of an ESB architecture. A MOM is a key part of the ESB architecture, as it provides the underpinnings of the network of virtual channels that an ESB uses to route messages throughout an extended enterprise and beyond.

Messaging Models: Pub/sub and P2P

There are two kinds of scenarios in terms of the maximum number of the conmuser applications for a specific message:

  • The publish-and-subscribe (pub/sub) model is intended for a one-to-many broadcast（Multicast） of information
  • The point-to-point (P2P) model is intended for a one-to-one communication （Unicast） between two specific applications.

Pub/sub model

In the pub/sub model, multiple consumers may register an interest with, or subscribe to, a topic. A producer sends a message on that channel by publishing on that topic. Each subscriber receives a copy of that message.

Point-to-point (P2P) model

In the point-to-point model, only one consumer may receive a message that is sent to a queue.

A point-to-point queue may have multiple consumers listening for the purposes of load-balancing or “hot backup”; however, only one receiver may consume each individual message.

There may also be no receivers listening, in which case the message stays in the queue until a receiver attaches itself to the queue to retrieve messages.

In the publish-and-subscribe model, messages not flagged as reliable can be discarded if no subscribers are registered to receive them at the time they are published.

Message Transmission Direction

There are two kinds of scenarios in terms of the message transmission direction when using MOM:

  • One-way communication: The whole process involves that an application send a message to the messaging system, and the messaging system then fowards the messages to their intended destination(s) (another application(s)).
  • Two-way communication (synchronous or asynchronous request/response, known as The Request/Reply Messaging Pattern): The whole process involves:
    • An application (requestor) send a request message to the messaging system
    • The messaging system then fowards the messages to the specific application (replier)
    • Once the replier application finishes the processing the of request message, it sends a response message back to the the messaging system
    • The messaging system routes this message back to the requestor application, with a correlation ID that is used to correlate the request message with the response message.

MON versus RPC

Messaging allow for loose coupling of components in which an application doesn’t need to know the intimate details of how to reach and interface with other applications, While Remote Procedure Call (RPC) is a typical tightly coupled communication approach, i.e., when one procedure calls another, it must wait for the called procedure to return before it can do anything else.

When choosing a type of communication infrastructure, it is important to consider the tradeoffs between loosely coupled and tightly coupled interfaces, and asynchronous and synchronous interaction modes.

Remote Procedure Call (RPC)

In RPC-style programming, an object and its methods (or a procedure and its parameters) are “remoted” such that an invocation of a procedure or method can happen across a network separation.

The application making the procedure calls is known as a “client,” and the remote implementation is referred to as a “server” or “service.” The client executes what looks like a local method invocation or procedure call.

Technologies using RPC-style communication include Common Object Request Broker Architecture (CORBA), Remote Method Invocation (RMI), DCOM, ActiveX, Sun-RPC, Java API for XML-RPC (JAX-RPC), and Simple Object Access Protocol v1.0 and v1.1.

Tightly Coupled Interfaces

In a tightly coupled RPC environment, each application needs to know the intimate details of how every other application wants to be communicated with—the number of methods it exposes and the details of the parameters that each method accepts.

Loosely Coupled Interactions

Asynchronous messaging allows each communication operation between two processes to be a standalone unit of work. Each participant in a multistep business process flow need only be concerned with ensuring that it can send a message to the messaging system.

However, there are side effects due to these loose coupling. Since producers (senders) don’t know the existences of consumers (receivers), if the consumer applications fail for any reason, the producers know nothing about it, which results in the difficulties of error handling. Meanwhile, debugging code and modifying application workflows become more difficult as well.

Asynchronous Message Reliability

With asynchrony comes the need for reliability. When an application sends an asynchronous message, there often needs to be some sort of assurance that the message will get to where it needs to go.

Message Persistence

When messages are marked persistent, it is the responsibility of the messaging system to utilize a store-and-forward mechanism to fulfill its contract with the sender. The storage mechanism is used for persisting messages to disk to ensure that it can be recovered if there is a failure of either the messaging system or the consuming client. The forwarding mechanism is responsible for retrieving messages from storage, and subsequently routing and delivering them.

Message Acknowledgments

Message acknowledgment at the wire protocol level is a key factor in guaranteed messaging. The acknowledgment protocol allows the messaging system to monitor the progress of a message so that it knows whether the message was successfully produced and consumed. With this knowledge, the messaging system can manage the distribution of messages and guarantee their delivery.

Standards and protocols

An early attempt to make message queuing more ubiquitous was Sun Microsystems’ JMS specification, which provided a Java-only abstraction of a client API.

Several protocol standards have emerged which are used in open source message queue implementations:

  • Advanced Message Queuing Protocol (AMQP) – feature-rich message queue protocol, approved as ISO/IEC 19464 since April 2014
  • Streaming Text Oriented Messaging Protocol (STOMP) – simple, text-oriented message protocol
  • MQTT (formerly MQ Telemetry Transport) - lightweight message queue protocol especially for embedded devices
  • XMPP (eXtensible Messaging and Presence Protocol) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language).

Example

There are a number of open source choices of messaging middleware systems (known as message broker software), including Apache ActiveMQ, Apache Kafka, Apache Qpid, Apache RocketMQ, Beanstalkd, Enduro/X, HTTPSQS[6], JBoss Messaging, JORAM, RabbitMQ, Sun Open Message Queue, and Tarantool.

Apache ActiveMQ

Apache ActiveMQ is a typical message-oriented middleware written in Java together with a full Java Message Service (JMS) client.

It supports a relatively large number of transport protocols, including OpenWire, STOMP, MQTT, AMQP, REST, and WebSockets.

RabbitMQ

RabbitMQ is another open source message-oriented middleware that originally implemented the Advanced Message Queuing Protocol (AMQP) and has since been extended with a plug-in architecture to support Streaming Text Oriented Messaging Protocol (STOMP), Message Queuing Telemetry Transport (MQTT), and other protocols.

Reference

FEATURED TAGS
algorithm algorithmproblem architecturalpattern architecture aws c# cachesystem codis compile concurrentcontrol database dataformat datastructure debug design designpattern distributedsystem django docker domain engineering freebsd git golang grafana hackintosh hadoop hardware hexo http hugo ios iot java javaee javascript kafka kubernetes linux linuxcommand linuxio lock macos markdown microservices mysql nas network networkprogramming nginx node.js npm oop openwrt operatingsystem padavan performance programming prometheus protobuf python redis router security shell software testing spring sql systemdesign truenas ubuntu vmware vpn windows wmware wordpress xml zookeeper
FRIENDS

TOC