A slight variant of the Push/Pull model described above is the push/push model as shown by the sequence diagram below:
The process here is that the WizAStore software, as before stores the information in a local filestore, queue or database ready for receipt by EntMine. However, the key difference is that we fire up another process or thread in the custom integration layer to read this local repository and try and send the information to EndMine instead of waiting for EntMine to read the information from us, hence Push/Push and not Push/Pull. If there are any issues sending the information all we do is stop trying to send the information and let it pile up in our repository until such a time as we can start to send it again.
The key benefit of this model is that the frequency of events being sent is determined by WizAStore and not EntMine. This enables us to work very near ‘real time’ event models which is where a lot of enterprise architectures are currently moving.
There is a another slight variant again of this which is essentially we only persist the calls if the network fails, and when the network returns we send all the events that have queued up and then continue to send further requests immediately. This is a combination of the basic synchronous push method and the push/push method. The advantage of this is that we have a true event driven integration but we have added a layer of resilience and self healing included for when we have failures.
We could further complicate this model by calling the push/cache on fail model asynchronously in code using multiple threads to give our users the impression of a more performant system, but it is unlikely to make much difference as any delay is local and not an over the network call.