Database Reference
In-Depth Information
Request-response messages
There is also the message exchange pattern of request-response; you can refer to
ht-
tp://en.wikipedia.org/wiki/Request-response
. The concept is simple: we send a request to a
specific endpoint and get a response only from that endpoint. There are no additional sub-
scribers listening in to process the message. This is done using a
Bus.Send(command)
function, where command is a type of message, in NSB. In the request-response pattern, we
send a message to a specific queue indicating that only one endpoint is being listened to
and no one else. We can send a message to each service as a heartbeat or to get an update of
the status of each service.
Saga services
As messages move through the workflow of service-to-service, new messages are created
and sent to the next service. There is a need to keep track of the relationship of messages
when responses are sent back to the service. A lookup of message states, or sessions, needs
to be done in a saga entity object saved to a database. This concept is like a session cookie
for session state information when a user moves from web page to web page. A service
needs to respond to the original service to provide a progress of the original message. In or-
der to do this, the saga entity also stores the originator of the message to be able to provide
a response to the original message.
The saga entity is an interface derived from IContainSagaData that will contain the man-
datory getter/setter fields of
Id
,
Originator
and
OriginalMessageId
. These prop-
erties are needed to reply to the client with information from the original message.
