In this post we have described the two key integration patterns, Push and Pull, we have also described the basic techniques for making them persistent and reliable, and we have shown through the asynchronous pattern how they can be combined to produce the complex interaction models required by an enterprise.
We also skirted around the use of files, batch processing, shared database and shared queue systems as alternatives to transport mechanisms and understood how these technologies hide the chosen implementation pattern from us. We also briefly showed how diagrams can often be misused to cause confusion by presenting different levels of information, as we need to be careful.
- Basic Synchronous Pull Pattern
- This is best used when we need an immediate response of information from a service, can be called asynchronously in code to make user interfaces look more performant. It is up to the caller to deal with failures.
- Basic Synchronous Push Pattern
- This is a very dangerous pattern in its raw form as it’s used to attempt to deliver information with no guarantee. It is best mixed with a persistent model unless data is disposable.
- Basic Push/Pull Pattern with Persistence
- This is the push model with batch, it’s very reliable but is based on scheduled jobs which is going out of favour in preference to event driven models.
- Basic Push/Push Pattern with Persistence
- This is the push model with a multi-threaded push to the server, it offers the advantage of being capable of true event processing with the advantage of persistence where required.
- Basic Asynchronous Pattern
- This is a meta pattern and is commonly miss-represented on design diagrams as it relies on other sub patterns.
- This is to be used for long running services where you don’t want to keep a connection open between the two systems, or block the calling process.
- This generally involves two or more calls one to initiate the request and one to receive or request the actual result of the operation.
- In a general sense the caller will get an acknowledgement and an optional transaction identifier as a response to the initial call, this identifier can be used to match request and response when they arrive.
The other thing to take from this post is that when you see a diagram talking about communication between two systems, be they email systems (SMTP), replicated databases, enterprise level clustered messaging systems, etc. Under the covers they will all rely on these patterns, or combinations of them, to communicate. If you take a look at them, and compare them to what we have shown above, you will probably be able to take a decent guess as to what they are actually doing.