From 5dfeab0474429e3daee7411329c8e7b75d1eb7ea Mon Sep 17 00:00:00 2001 From: auke Date: Sun, 1 Mar 2020 10:19:02 +0000 Subject: [PATCH] Update page 'Message Queue Endpoint' --- Message-Queue-Endpoint.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Message-Queue-Endpoint.md b/Message-Queue-Endpoint.md index bd95a65..59921b5 100644 --- a/Message-Queue-Endpoint.md +++ b/Message-Queue-Endpoint.md @@ -15,7 +15,7 @@ Now, there are two things that external services can do. * An external service (like a sensor) could **publish a message to a certain topic**. For example, a temperature sensor would publish the temperature at a specific time and location to the "temperatureMeasurements" topic. * An external service can **"subscribe" to this topic** by connecting to the broker. This service will then recieve every temperature measurement. -When the subscribed service temporarily disconnects from the broker, it will not recieve any messages, but the messages will remain stored at the broker. Depending on configuration, messages will be kept longer or shorter, or be deleted after they recieve the subscribers but the intent is always to ensure the messages get from the **publisher** to the **subscriber**. +When the subscribed service temporarily disconnects from the broker, it will not recieve any messages, but the messages will remain stored at the broker. Depending on configuration, messages will be kept longer or shorter, or be deleted after they reach the subscribers but the intent is always to ensure the messages get from the **publisher** to the **subscriber**. Setting applications up like this makes things a lot more flexible than connecting systems directly and provides a central point to manage the communication between applications.