Figure 4-6 Sequence diagram fire-and-forget 4.4.2 Request-reply Sometimes it is not reasonable to send a message without expecting a reply. Although there are advantages to decoupling consumer and provider, there are scenarios in which confirmation or results of the remote processing is needed in the form of a reply. The request-reply pattern supports two-way communication between a consumer and a provider. Based on the request from the consumer, the provider sends back a reply. The reply may either contain an acknowledge for the arrival of the request or a result based on the provider's request processing. The request-reply pattern exists for both asynchronous and pseudo-synchronous communication. The difference is based on the blocked or running consumer thread during the request processing on the provider side. The request-reply pattern provides a tighter coupling between consumer and provider. Additional logic is needed to correlate request and reply, to handle reply delays or even failures in receiving replies. Figure 4-7 on page 72 shows two sequence diagrams of the request-reply pattern. With asynchronous communication thread A continues processing after triggering thread B. The reply of thread B is handled on the consumer side by a third thread C. With pseudo-synchronous communication thread A blocks its processing after triggering thread B until it receives the reply. Chapter 4. Application design 71