Page 458 in the book.
"Still, we can overcome this to some extent by making dependence on RESTful resources a lesser obstacle to consumer autonomy. Even when RESTful (or RPC for that matter) is your only means to integrate, you can create the illusion of temporal decoupling by using timers or messaging in your own system. That way your system will reach out to any remote systems only when a timer elapses or when a message is received. If the remote system is unavailable, the timer threshold can be backed off, or if using messaging the message can be negatively acknowledged to the broker and redelivered"
Context:
I have a Client service C
I have a Server service S
C --calls--> S
I want to increase the autonomy of C and lessen the dependency on S
Questions:
The book says (in the above paragraph ) I can use "Temporal Decoupling" using timers or messaging. So that to me means that C no longer has to block and wait for an immediate response from S? is that correct?
Temporal Decoupling using Timers: C only makes a call on S when timer elapses and if the remote system (S) isn't available the timer threshold is backed off. What does that mean? can you clarify this?
I understand that C makes call only when timer is more than 10 sec for example? is that correct?
Not clear how "timer threshold is backed off" can help in this?
Temporal Decoupling using Messaging: C only makes a call on S when a message is received and if the remote system (S) isn't available the message is negatively acknowledged. What does that mean? can you clarify?
C only calls S when "a message is received" received from where?
and if no message is received then "... the message can be negatively acknowledged to the broker and redelivered", not clear of sequence of events here?
Please clarify with examples if you can. Thank you.
The book says (in the above paragraph ) I can use "Temporal Decoupling" using timers or messaging. So that to me means that C no longer has to block and wait for an immediate response from S? is that correct?
Yes, it is for implementing async integration between two bounded contexts (BCs) when the upstream BC (the server "S") offers a REST API instead of publishing messages to a middleware queue.
Temporal Decoupling using Timers: C only makes a call on S when timer elapses and if the remote system (S) isn't available the timer threshold is backed off. What does that mean? can you clarify this? I understand that C makes call only when timer is more than 10 sec for example? is that correct? Not clear how "timer threshold is backed off" can help in this?
So, the downstream BC (C) integrates with the upstream BC (S) by polling the REST API of S everytime a timer elapses (say every 10 sec, as you said for example). To back the timer threshold off when the API is unavailable, means that the client will retry the polling on normal intervals, it doesn't matter the timer.
Example:
C --POLL--> S @ 00:00
C --POLL--> S @ 00:10
C --POLL--> S @ 00:20
C --POLL--> S @ "every 10 sec"
S is-down
C --POLL--> S @ 00:00 (timer is backed-off)
S is-down
C --POLL--> S @ 00:00 (timer is backed-off)
S is-up
C --POLL--> S @ 00:10
C --POLL--> S @ 00:20
C --POLL--> S @ "every 10 sec"
Temporal Decoupling using Messaging: C only makes a call on S when a message is received and if the remote system (S) isn't available the message is negatively acknowledged. What does that mean? can you clarify? C only calls S when "a message is received" received from where? and if no message is received then "... the message can be negatively acknowledged to the broker and redelivered", not clear of sequence of events here?
Instead of using a timer, the polling is done every time C receives a message, published by an internal broker within the client BC (not a message queue between C and S). To return a negative acknowledge to the broker is for saying to the broker that it has to redeliver the message (since the call to S couldn't be performed). So the broker will send again the same message to C, and C will retry the call to S.
UPDATE:
The following is what Vaughn Vernon says in his other book "DDD distilled" about this topic:
"Going Asynchronous with REST
It’s possible to accomplish asynchronous messaging using REST-based polling of a sequentially growing set of resources. Using background processing, a client would continuously poll for a service Atom feed resource that provides an ever-increasing set of Domain Events. This is a safe approach to maintaining asynchronous operations between a service and clients, while supplying up-to-date events that continue to occur in the service. If the service becomes unavailable for some reason, clients will simply retry on normal intervals, or back off with retry, until the feed resource is available again.
This approach is discussed in detail in Implementing Domain-Driven Design."