added image on basic communication. Fixed some urls and did some polishing.

Author: Sharifuzzaman Nakib

documentation/docs/concepts/generic-broker.md

@@ -1,5 +1,5 @@
 
-The generic broker concept is an abstraction of all the Broker supported by OpenTransit. It contains all the common features of all the supported brokers. 
+The generic broker concept is an abstraction of all the Brokers supported by OpenTransit. It contains all the common features of all the supported brokers. 
 
 ## Common Broker Features
 
@@ -8,11 +8,11 @@ In practice, these common features cover the majority of real-world use cases.
 
 For example:
 
-- All of them offer a **Publish Endpoint** where messages can be published.  
+- All of them offer **Publish Endpoints** where messages can be published.  
   - RabbitMQ calls this an **Exchange**.  
   - Azure Service Bus, ActiveMQ, and Amazon SNS call it a **Topic**.
 
-- All of them provide a **Receive Endpoint**, typically referred to as a **Queue**, where consumers subscribe.
+- All of them provide **Receive Endpoints**, typically referred to as **Queue**, where consumers subscribe.
 
 Producers publish messages to Publish Endpoints, and Consumers subscribe to Receive Endpoints.
 

documentation/docs/patterns/commands-and-events/overview.md

@@ -50,7 +50,7 @@ Examples:
 The messages and Consumers classes are kept on the **Shared** Project.
 
 ### Command Implementation
-Since the [Receive Endpoint](generic-broker.md#receive-endpoint) natively implements the [Competing Consumers Pattern](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html), 
+Since the [Receive Endpoint](../../concepts/generic-broker.md#receive-endpoint) natively implements the [Competing Consumers Pattern](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html), 
 no additional configuration is needed. 
 
 In the [Example Project](https://github.com/OpenTransitLab/Tutorials/tree/main/CommandsAndEvents) you will see both **ApplicationA** and **ApplicationB** subscribed for the `ProcessOrder` message. 

documentation/docs/tutorials/basic-communication.md

@@ -65,7 +65,7 @@ In this example, messages are published from two places:
 - From inside the **SubmitOrderConsumer**
 [!code-csharp[](code-sample/OrderService.SubmitOrderConsumer.cs#L6-L18)]
 
-Both `IBus` and `ConsumeContext<T>` act as Producers, because you can call `Publish(T message)` on either of them.
+Both `IBus` and `ConsumeContext<T>` are Producers. You may call `Publish(T message)` on either of them.
 
 When publishing inside a [Consumer](#publishing-from-inside-a-consumer), it is **highly recommended** to use the `ConsumeContext<T>` Producer as we have done in the SubmitOrderConsumer. We’ll discuss why in the dedicated Producers section.
 
@@ -106,16 +106,17 @@ In this step, we perform three main tasks:
 
 3. **Register the consumers**(if any)
 
-All the above 3 tasks is done onthe `Program.cs` of OrderService
+All the above 3 tasks is done on the `Program.cs` of OrderService
 [!code-csharp[](code-sample/OrderService.Program.cs#L12-L25)]
 
+However, the Client doesn't consume any messages. So no Consumer is registered, and the `ConfigureEndpoints()` method isn't called.  
 
 ---
 
 ### 5. The Topology:
 
-This example uses **[broker-agnostic](../concepts/topology#broker-agnostic-way)** configuration, so you don’t need to understand the underlying broker [topology](../concepts/topology) for basic communication.  
-Here, we only used the `UsingRabbitMq` method to provide the Connection Configuration and to configure the Publish and Receive [Endpoints](../concepts/generic-broker#generic-broker-terminologies)(a generic concept among all the brokers) on the broker. 
+This example uses **[broker-agnostic](../concepts/topology#broker-agnostic-way)** configuration, so you don’t need to understand the broker's internal [topology](../concepts/topology) for basic communication.  
+Here, we only used the `UsingRabbitMq` method to provide the Connection Configuration and to configure the Publish and Receive [Endpoints](../concepts/generic-broker#endpoints)(a generic concept among all the brokers) on the broker. 
 
 Since this Configurations aren't RabbitMQ specific, and you may use any other broker here and, the Message Communication would work fine. We will add examples with other brokers soon.
 
@@ -125,6 +126,8 @@ Since this Configurations aren't RabbitMQ specific, and you may use any other br
 In this project, we work with two message types: **SubmitOrder** and **ProcessOrder**.  
 Based on these message types, the topology is set up in the following way:
 
+![ Generic Broker Topology](/images/tutorials/basic-communication/topology.png)
+
 1. **Two Publish Endpoints and Two Receive Endpoints are created**, one pair for each message type.
 2. Each `IConsumer<T>` is automatically subscribed to the **Receive Endpoint** for its message type **T**.
 3. When you call `Publish(T message)`, the message is sent to the corresponding **Publish Endpoint** for type **T**.
@@ -136,7 +139,7 @@ Based on these message types, the topology is set up in the following way:
 #### Broker's internal topology
 
 # [RabbitMQ](#tab/rabbitmq)
-However, knowing the underlying broker [topology](../concepts/topology) is very helpful when debugging message-routing issues.
+However, knowing the broker's internal [topology](../concepts/topology) is very helpful when debugging message-routing issues.
 
 In our example, Each Consumer is consuming a single message type. 
 Here, for each MessageType, 2 **Exchanges** and one **Queue** are being created.