Microservice Patterns - 3.3 Interprocess communication in a microservice architecture - Communicating using the Asynchronous messaging - 1

Reference

https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543

Pattern: Messaging

A client invokes a service using asynchronous messaging. See http://microservices .io/patterns/communication-style/messaging.html.

messaging-based application

1. message broker: broker acts as an intermediary between the services
2. brokerless architecture:  the services communicate directly with each other

Messages

consists of a header and a message body:  

1. The header is a collection of name-value pairs
2. provided by the message's sender
3. such as a unique message id generated by either the sender or the messaging infrastructure

The message body is the data being sent

• Document: contains only data.  The reply to a command is an example of a document message
• Command:  equivalent of an RPC request.
• Event:  A message indicating that something notable has occurred in the sender

Message Channel

1. sender invokes a sending port interface
2. sending port is implemented by a message sender adapter class, sends a message to a receiver via a message channel.
3. A message channel is an abstraction of the messaging infrastructure
4. message handler adapter class in the receiver is invoked to handle the message
5. Message handler invokes a receiving port interface implemented by the consumer's  business logic.
6. 2 types of channels
1. point-to-point:  delivers a message to exactly one of the consumers
2. publish-subscribe:  delivers each message to all of the attached consumers

Implementing the interaction styles using messaging

• The client sends a command message that has a reply channel header
• The server writes the reply message, which contains a correlation id that has the same value as message identifier, to the reply channel
• The client uses the correlation id to match the reply message with the request

IMPLEMENTING ONE-WAY NOTIFICATIONS

The service subscribes to the channel and processes the message

IMPLEMENTING PUBLISH/SUBSCRIBE

A client publishes a message to a publish-subscribe channel that is read by multiple consumers

The service that publishes the domain events owns a publish-subscribe channel, whose name is derived from the domain class

IMPLEMENTING PUBLISH/ASYNC RESPONSES

A client publishes a message that specifies a reply channel header to a publish-subscribe channel

A consumer writes a reply message containing a correlation id to the reply channel.

The client gathers the responses by using the correlation id to match the reply messages with the request

Creating an API specification for a messaging-based service API

The specification for a service’s asynchronous API must specify the names of the message channels, the message types that are exchanged over each channel, and their formats.

DOCUMENTING ASYNCHRONOUS OPERATIONS

• Request/async response-style API
• service’s command message channel
• types and formats of the command message
• types and formats of the reply messages
• One-way notification-style API
• service’s command message channel
• types and format of the command message types
• A service may use the same request channel for both asynchronous request/response and one-way notification

DOCUMENTING PUBLISHED EVENTS

A service can also publish events using a publish/subscribe interaction style

• event channel
• types and formats of the event messages