In this post, I’m going to talk about the importance of how you integrate your various software components together.
As I mentioned in my last blog post, when a user clicks on your web page to start a process, there’s no guarantee the process will complete successfully. Even if your website is working correctly, any number of the services going on behind the scenes could conspire against you: the authentication servers, the message brokers, the line of business servers, the audit servers… at some point something is going to go wrong.
Planning for the ‘happy path’ through the system, (where everything works as it should), is obvious, but the ‘unhappy path’ is where you really have to put the thought in.
Many different services come together to make a system. The Agency is designing the integration between those services using asynchronous rather than synchronous messaging where it can.
As it’s almost Christmas, let’s use a festive analogy to illustrate this approach: the annual Christmas party.
Asynchronous messaging – ordering drinks at a fancy restaurant
Imagine you and your team are in the middle of your office Christmas meal; let’s call you and the team the ‘Customer Service’. The over-attentive server is hovering nearby with his or her colleagues (we’ll call them the Order Management Service). You order another fancy cocktail, and a few of your colleagues ask for another pint each. The server who represents the ‘Order Management Service’ acknowledges the order and moves across to the bar to prepare the respective beverages. In the meantime you get back to your conversations knowing that at some point your drinks will appear.
You have performed an asynchronous transaction here in that you have ‘handed off’ the process to another party to complete. You have passed the responsibility for the next stage of the process to someone else. The ‘handing off’ part here is important: you are waiting for the ‘Order Management Service’ to ‘hand off’ the process back to you again, ie, for the drinks appear on the table.
Synchronous messaging – ordering drinks at a busy bar
A synchronous transaction may occur later in the evening when the polite and orderly lunchtime meal has eventually given way to drinks in a busy bar.
The ordering of drinks at the bar tends to be a synchronous transaction in that you are locked into the process from start to finish – there is no hand-off. In this case you give the order to the person behind the bar and don’t do anything else until the drink is on the desk in front of you. You then complete the transaction by passing across the money.
Unlike lunchtime drinks earlier in the day, you can’t do anything else while you’re waiting to be served. You’re concentrating solely on the process at hand and are unlikely to deviate until your ‘exit condition’ has been achieved.
Why we choose asynchronous over synchronous
Sometimes transactions need to be synchronous. For example, when using online banking to move money between your accounts. Once the money has been debited from your current account, you want the system to wait and not do anything else until it’s completed the transaction by crediting the money to your savings account.
At the Agency, some of our transactions need to be synchronous. For example, paying Skills Providers when they are confirmed as delivering training. A BACS transaction will be set up and the internal systems will wait until the transaction has been confirmed before they update the internal accounting systems.
More often than not however, asynchronous transactions are ‘good enough’ for what we’re are trying to do, and bring some advantages.
Asynchronous messaging gives our services a greater level of control around their individual part of the process. Service A can request something from Service B, then get on with something else until B lets A know it has a response ready. It also has an advantage if things don’t go as planned. For example, if B doesn't response in a reasonable amount of time, A could opt for an alternative path, perhaps sending the request to Service C instead.
With synchronous messaging, Service A would be “stuck” in the process while it waited for B to respond. Service A couldn't do anything else while it waited, and if something went wrong with B, A couldn't try any alternative paths. From a digital service users’ point of view this would effectively mean a ‘locked’ session with that user unclear about what exactly was happening with their transaction.
A more technical look at messaging in SFA systems
The SFA uses open standards REST-based message queues wherever it can to perform complex business processes and transactions. Business events and supporting data are logged in the message queues and dependent processes subscribe to those queues and act accordingly.
In the Contract Management space for example, the fact that a contract has been approved is not communicated directly to any specific clients. Instead the Data Collections system that allows Skills Providers to let the Agency know how they are performing against their contracts and the Data Warehouse both subscribe to the ‘Contract Approval’ feed, kicking off internal processes in those respective systems as a consequence.
The Agency likes REST-based message queues as they place no proprietary technology constraints on the consumers and allows the stringing together of these services in a number of different ways.
The diagram opposite illustrates a typical example using two on-line customer portals using a single Order Management service. Importantly, this method removes the operational dependencies on the individual services.
If you can switch off the ‘Order Management’ Service, the ‘Fantastic Things’ portal will continue to operate. When the Order Management Service comes online again, it just needs to ‘catch up’ with the order messages. As discussed in my last blog, this is why the messages back to consumers are so important and why the Agency is very careful not to pre-empt the outcomes of those transactions.
This mechanism does introduce additional complexity, however, and requires services to break a transaction request into two parts rather than just the one: deal with the ‘send’ and deal with the ‘receive’. Overall, though, it’s an approach which is reaping benefits and its one that the Agency intends to continue.
1 comment
Comment by Tim Maude posted on
Thanks for the "drinks ordering" analogy, Chris - great explanation. I expect I will use it some time!