So far the only asynchronous pattern we have seen is in code where we created another process or thread to make an API request and either ignored the response or let that call us back when it was done. Oddly enough we also skirted on asynchronous on the Push/Push and Push Pull models but we only got about half way there.
Let’s look at a sequence diagram often drawn of an asynchronous call.
Ok, that looks so much simpler than the diagrams we have seen so far… The reason behind this is that this is a meta-pattern in that it relies on other patterns to work. The diagram above is typical of diagrams that can cause confusion at a design level as the lines here don’t imply a single step, but actually a whole series of steps in a much more detailed process.
(yes you technicians out there we were already doing that on our earlier diagrams – true – but like at school teachers used to lie to you and keep it simple then when you understood that lie to you a little less, we are doing the same…)
The diagram above for example does not mean that the WizAStore process is necessarily blocked until the update is received – it may be – and infact if you gave this to a development team you may well end up with this being developed as a synchronous call!
An asynchronous call can come in many flavours, but essentially the pattern is akin to that of sending a message via say email. When you send an email, you send it to one or more addressee’s and you get confirmation that it has been sent. At the point you send the email you have essentially lost control of it, you can keep a copy in your sent box to prove you sent it, but other than that it is now outside of your control and you can get on with your life. The email however will be bounced from server to server until it arrives at its destination, where the recipient(s) can either respond to it (through the previously agreed response protocol – in this case email!) or act on it in some other way with the expectation that through those actions you will find out through some other mechanism.
In computer API’s this pattern tends to be used for any service that is likely to take a significantly long time, for example rendering a document, processing, packing and dispatching an order etc.
Looking back on the patterns we have described so far this concept of “Asynchronousness” (if that’s a word) has been implemented within the one message flow with the API being synchronous (i.e. a network connection, or NFS accessed file is opened, the data is moved and the connection is closed). In a truly asynchronous API we would expect a minimum of two network requests. One to supply the data and agree the mechanism by which we will accept a response, and the other separate one to deliver the response back to the client.
In our email example this could be:
- Email sent with the expectation to email back
- Email sent with request to set up a meeting (the response being a meeting request appearing in your calendar)
- Email send with a request to call at your earliest opportunity (the response being a phone call)
To summarise, asynchronous patterns consist of two or more of the synchronous patterns described above interacting together in some way. The first being the request for action and the second being the response through the expected channel (call backs, other data feeds, polled web services, some kind of ticketed response etc.).
A more accurate picture of the above sequence could be:
The time between the SendOrder message and the Fraud Check Complete message could be days. Notice that the sending pattern here is a simple asynchronous pattern as is the return – just in reverse, but they could be any of the base synchronous patterns.
Examples of truly asynchronous API’s in our simple enterprise could include order processing. In this case the order is batched in a file (so all we get back is an acknowledgement that it has been sent) and the response comes back through email, and also through an order updates API which is used by EntMine to tell WizAStore about order updates (e.g. order accepted, payment confirmed, order dispatched). Note that the receiving protocol could again be any of the methods described earlier.
It is usual that the request and response are tied together with some kind of identifier to ensure that the sender can associate the response with a request that has been made.