Integration Patterns¶

There is more than one approach to meeting integration needs. This section provides a view of the most appropriate patterns. Each approach addresses some of the integration criteria better than others. These various approaches to integration can be broadly grouped into four main integration styles. In terms of adhering to the Integration Team Principles and policies, the priority order in which group to use is as follows:

Service Oriented Methods – have each application expose some of its capability as services that can be invoked remotely, and have applications invoke those to run behaviour and exchange data. This is also known as remote procedure invocation.

If an application needs to access information that is owned by another system, then the system asks for it directly by calling a service or a remote procedure call. If data needs to be updated, then a system can also maintain that remotely via a service call. Full details of how to implement service oriented methods are discussed in the book “SOA Design Patterns”

Messaging – have each application connect to a common messaging system and exchange data and invoke behaviour using messages.

This style of integration is well suited for transferring data frequently, immediately and reliably in an asynchronous fashion between systems. A common data format can also be used to provide further de-coupling and re-use. Various styles of integration can be implemented such as fire and forget, reply-request publish subscribe in order to best meet requirements. This style of integration is supported by both a message queuing mechanism or by an Enterprise Service Bus – which provides further capabilities such as message transformation, orchestration, enrichment and validation. Full details of the different types of integration using messaging paradigms are discussed in the book “Enterprise Integration Patterns”

Batch oriented – have each application produce sets of data for others to consume, and these sets, or batches of data are shared or consumed either as a set of files or as a set of data that is extracted, transformed and loaded (ETL) into the consuming system.

With this style of integration, the integration environment would take responsibility of transforming the data into different formats. Producers would have to create the data sets at regular intervals according to the nature of the business. When using files, the format for the files needs to be agreed. It will be rare when the output of the producing application is in the exact format that the consumer wants, so several processes may be involved to process the files.

Shared Database – have applications store the data they wish to share in a common database, where it can be combined and enriched to meet business requirements, then distributed to systems for consumption.

With this method, care needs to be taken to ensure that data is always consistent. If there are simultaneous updates to the same piece of data from multiple sources, then transactions will need to be managed and changes captured in a consistent way.

The groups should not be used in a mutually exclusive fashion – that is, for larger IT programs, and for entire business solutions, there is usually a mix of strategies that gives the most appropriate solution. It needs to be understood when to use the appropriate pattern correctly. Hence, the above core groups have been taken a step further in this section and expressed as a set of patterns that can be used to meet the integration requirements in a standardised way. The table below lists the different integration patterns. It also indicates which technology is best suited to implement the pattern and links the scenarios when the pattern should be used.