Integration Patterns

Integration Styles

File Transfer

Have each application produce files of shared data for others to consume, and consume files that others have produced.

Remote Procedure Invocation

Remote procedure invocation (RPI) is a pioneer in the integration space and was the go-to manner to implement an API in the early days of computing. In this approach, a provider will allow an external process to make requests into a closed application. The external caller has the specifications to make the request and an expectation on what the response will be, but all the logic takes place using a black-box approach. In this case, RPI is the mechanism used to perform some action against the target system.

Consider an application which handles financial transactions. Prior to the popularity of RESTful APIs, the vendor may offer an API to allow transactions to be posted from an external source. This API was implemented using RPI.

The developer would write a program to gather the required information, then connect to the application using RPI. The results of the RPI/API requests were packaged into a response and that information was processed by the calling application.

Shared Database

The shared database integration style leverages a database for the connectivity between two or more applications. As a result, each application would maintain a connection to a shared database containing the information that will be integrated.

As an example, use of an INSERT statement to a staging table in the database could trigger a stored procedure which would perform business logic — ultimately updating attributes elsewhere in the database for other applications utilizing that same shared database integration.

Messaging

The messaging integration style started to gain momentum with service-oriented architecture (SOA) implementations — leveraging an enterprise service bus (ESB) as the foundation for the message itself.

Using the financial transaction example, the custom application may simply place a message on the ESB requesting a certain transaction be posted. That system submits the message and relies on the messaging integration style to handle any remaining tasks.

On the financial system side, the message being placed on the bus triggers and event which consumes the message and takes the appropriate action based upon the nature of the message. Based on the message queue used and/or metadata within the message itself, the financial system understands the task that needs to be performed.

When completed, the financial system may place a new message on the bus, which could be consumed by the original system. In this case, it might be related to unique transaction information to append to the original request for auditor validation purposes.

Pros

A major benefit of the messaging concept is that the asynchronous messages do not require both systems to be online and available at the same time. One system may place a message with an ESB, which could be processed immediately by another system or on a schedule hours later. Either way, both conditions can be handled without impacting the other.

The message system employs channels (or queues) to organize and categorize the information that needs to be integrated. For example, if the source system needs to communicate with a financial system and an HR system, the messages would use different channels for each message type.

• Broadcast

The broadcast can also be called “one-way sync from one to many”, and it is the act of moving data from a single source system to many destination systems in an ongoing and real-time (or near real-time), basis. 

• Bi-Directional Sync

Reference : https://dzone.com/articles/introduction-to-integration-patterns