Messaging Conceptual Fundamentals

Feb 4, 2019
-
4
minute read

Message-centric systems are naturally flexible, since they focus on the communication patterns of a system instead of concrete behaviors, they are loosely coupled, and they expose the information needed to trace data flows and replace or enrich behavioral components of the system. Building well-designed message-driven systems requires a strong understanding of general messaging patterns and message types. What are the messaging fundamentals?

1. Messaging Basics

What is a message?

A message is any communication of information between one sender and one intended receiver.

A message with a single intended receiver may still be received by others, either due to relaying the message, or due to the nature of the medium.

What is the value of a message?

Messages are inherently flexible, replicable, and asynchronous. They are the foundations of all communication.

What are the chief limitations of messages?

Messages require a shared communication protocol, and shared context.

How many types of message exist?

There are a near infinite number of subtypes of messages, but only two fundamental message types.

2. High-Level Message Types

Event Notification Messages

A message created solely as a one-way means of providing information. No expectations are attached. Recipients are allowed to interpret the message as they see fit. No acknowledgement is required.

When a subtype or subcategory of Event is used, this is a means of providing additional context to the recipient. Message headers are another means of providing message context.

Examples:

Sign with text: “Store Hours: 9am-5pm, M-F”

Company email: “Donuts are available in the breakroom downstairs. First come, first serve.”

Request / Response Messages

A request is a message sent with the expectation of a response message sent back to the sender. The content of the message contains the context needed to differentiate the type of response desired.

A response is expected to be either the requested information, information about the requested information, or a reason why the request could not be satisfied. Strictly speaking, the response message is a Event Notification to the sender that the Request has been processed.

2b. Hybrid Message Types

Reliable-Delivery Event Notifications

In systems that aren’t concerned with how recipients process messages, but that wish to ensure the message was successfully delivered, Event Notification Messages are sent as a the content of a Request Message, with the expectation of an Acknowledgement Response from the recipent, or an Error Response if the message could not be delivered to the recipient.

In most modern communication systems, Event Notifications are sent using some form of Reliable Delivery. Pure one-way communication is rare. Conceptually, this distinction occurs at the transport level and doesn’t affect the high-level messaging design. It makes it easier to reason about a system, since dropped messages don’t have to be considered.

Examples:

Exactly-once delivery Message Queues

Read receipts on Messaging Applications

To roommate: “I’m going out for the evening. Steak is thawing on the counter for dinner.” -> “Ok”

Command Requests

A request sent to a recipient with the expectation of some action being taken or work performed. No response (or simply an Acknowledge Response) is expected if the work can be performed. If the work cannot be performed, then an Error Response is generally expected.

Typically, the work for any given command is expected to performed no more than once.