Edition 0 Updated to asp. Net core 0

Additional resources 
•
Martin Fowler. Richardson Maturity Model
A description of the REST model. 
https://martinfowler.com/articles/richardsonMaturityModel.html
 
•
Swagger
The official site. 
https://swagger.io/
 
Push and real-time communication based on HTTP 
Another possibility (usually for different purposes than REST) is a real-time and one-to-many 
communication with higher-level frameworks such as 
ASP.NET SignalR
 and protocols such as 
WebSockets
. 
As Figure 4-17 shows, real-time HTTP communication means that you can have server code pushing 
content to connected clients as the data becomes available, rather than having the server wait for a 
client to request new data. 

---

54 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-17. One-to-many real-time asynchronous message communication 
SignalR is a good way to achieve real-time communication for pushing content to the clients from a 
back-end server. Since communication is in real time, client apps show the changes almost instantly. 
This is usually handled by a protocol such as WebSockets, using many WebSockets connections (one 
per client). A typical example is when a service communicates a change in the score of a sports game 
to many client web apps simultaneously. 
Asynchronous message-based communication 
Asynchronous messaging and event-driven communication are critical when propagating changes 
across multiple microservices and their related domain models. As mentioned earlier in the discussion 
microservices and Bounded Contexts (BCs), models (User, Customer, Product, Account, etc.) can mean 
different things to different microservices or BCs. That means that when changes occur, you need 
some way to reconcile changes across the different models. A solution is eventual consistency and 
event-driven communication based on asynchronous messaging. 
When using messaging, processes communicate by exchanging messages asynchronously. A client 
makes a command or a request to a service by sending it a message. If the service needs to reply, it 
sends a different message back to the client. Since it’s a message
-based communication, the client 
assumes that the reply won’t be received immediately, and that there might be no response at all.
A message is composed by a header (metadata such as identification or security information) and a 
body. Messages are usually sent through asynchronous protocols like AMQP. 
The preferred infrastructure for this type of communication in the microservices community is a 
lightweight message broker, which is different than the large brokers and orchestrators used in SOA. 
In a lightweight message broker, the infr
astructure is typically “dumb,” acting only as a message 
broker, with simple implementations such as RabbitMQ or a scalable service bus in the cloud like 

---

55 
CHAPTER 3 | Architecting container and microservice-based applications 
Azure Service Bus. In this scenario, most of the “smart” thinking still lives in the endpoints that ar
e 
producing and consuming messages-that is, in the microservices. 
Another rule you should try to follow, as much as possible, is to use only asynchronous messaging 
between the internal services, and to use synchronous communication (such as HTTP) only from the 
client apps to the front-end services (API Gateways plus the first level of microservices). 
There are two kinds of asynchronous messaging communication: single receiver message-based 
communication, and multiple receivers message-based communication. The following sections 
provide details about them.