Enterprise Integration Patterns – the basics

Basic Synchronous Push Model

This is essentially the reverse of the basic synchronous pull model, whereby instead of say WizAStore requesting (pulling) information from EntMine regarding stock levels, in this case WizAStore is sending (pushing) information to EntMine. A great example of this is an order that we have taken from the on line store.

So let’s keep it simple, here is pretty much the same sequence flow for sending an order synchronously from WizAStore to EntMine.

Synchronous Push Data Call

 

Again this is a simple flow and follows exactly the same flow as our earlier pull request but the information is essentially going from WizAStore to EntMine which is storing the information and returning a new order number.

Well that’s easy then, and we can make it more efficient again by using our little multi-threading trick to speed up the user interface if we so wish.

Synchronous Push Data called Asynchronously

Hold on though, there is something we are missing here, in our basic pull model if something went wrong and we are pulling information from a back end service, we can handle that immediately and tell the user ‘we can’t get the stock levels right now’ and give them options. Here though what do we do if the call is not successful?

Well in all honesty it really does depend, in our example we are looking at orders, orders are kind of important so displaying to the user ‘sorry we can’t take your order right now can you come back later’ is probably going to lead to a lost sale. Equally if we were to look at another example say we reversed the call and made it about EntMine updating a cache of products in WizAStore using the push technique, then if the update fails  WizAStore could be displaying the wrong product set.

In actual fact this makes the basic asynchronous push model dangerous to use in the wild unless we can handle failures and re-trying in a much more robust manner, the next two patterns explain some of the ways this can be achieved.

One small foot note here is that this is a great candidate for new ‘event driven’ architectures where we need to send information on as soon as it is available. However, if we built an architecture like this then the chance of data loss (in this case loss of orders) is quite large in the case of system failure and we come back to the need to make this model more robust.

Leave a Reply

Your email address will not be published. Required fields are marked *