User:Mwgabriel/EnterpriseIntegrationPatterns

Background

Many corporates and organizations require a multitude of software solutions to run their day to day operations. Users expect instant access to various software functions an enterprise offers through a comprehensive portal that integrates the many functions and ensures that actions taken within one system is synchronized through out the various systems. This requires disparate applications to be connected into a larger, integrated solution, which is generally achieved through some form of "middleware". Middleware provides the "plumbing" such as data transport, data transformation, and routing.

Building integration solutions is often complex and greatly depends on the workings of existing software components. As a result, there is typically many possible right solutions and integration can be more of an art than a hard process. Integration Patterns emerged as a way to capture experts' knowledge of the most effective ways in enterprise integration.

There are four general solutions to share information across a set of integrated systems:

File transfer: systems write to and read from a file. This solution typically works well when extreme asynchronicity is used and many distributed systems are accessing this information. Systems should read from the file every several hours.
Shared database: systems that share information share a database. The main advantage of this solution is speed, so systems that are physically close get the most benefit of this system.
Remote Procedure Invocation: applications call other application’s APIs directly. This is most useful when information must be shared in real time, but it requires a high level of synchronicity.
Messaging: applications publish information to a shared messaging channel. This is in many ways a lightweight version of the file transfer method that can handle a higher frequency of access and even more interfacing systems.

The Problem

Applications do not exist in isolation. Frequently, they must interface with other applications, which may be written in different languages, for different platforms, or provide functionality that doesn’t work well with integrated programs.

Example

Consider a point-of-sale machine. Its main functions are to scan and interpret barcodes, reference those barcodes with a table of prices, and accept payment. There are 10 of these in a particular store, and they run on iPads.

This setup introduces problems for the manager because he has to submit requests for more inventory midmorning once per week. He can’t close out each POS machine when there are customers in the store to check how much has been sold that morning, and placing his order without that information could result in a week’s worth of shortages.

He has an inventory database, but it runs on an MS-DOS machine and it only ever gets updated during quarterly inventory checks.

A good solution to this problem would be to integrate the POS system and the inventory database. But how should this be done?

First, let the systems speak in the same language. Add an application to the POS machines and the database machine that translates their proprietary message formats and APIs to a common XML message format. The result of this is that when the POS machines process payment for an order, an XML message is created that shows which items were purchased, as well as how many were purchased.

On the database side, when an XML message is received it is translated into a command that decrements the database entry for each item.

Next, the messages must be able to be sent from the POS machines to the database. Since there are only 10 POS machines, it’s actually completely feasible to maintain 10 open TCP socket connections, so we’ll do that. The XML messages are encapsulated into TCP/IP packets, which guarantee delivery.

Solution

The example above is extremely simple, but these integration issues increase in complexity very quickly, and trying to develop a completely custom solution in each case is time-consuming and error-prone.

Enterprise integration patterns describe a set of solutions to make an integrator’s life easier. An integrator can choose a standard solution that fits scaling, synchronicity, and infrastructure requirements and then develop scripts that translate information from proprietary systems to the standard.

These information sharing solutions are implemented in different patterns to solve the following sets of problems:

Information Portals: visually display data from different systems on the same page.
Data Replication: different systems need to use the same data (customer's email address)
Shared Business Functions: different systems need to use the same methods (change_customer_email)
Service-Oriented Architectures: managing a large set of shared business functions.
Distributed Business Processes: manage business processes split across multiple systems.
Business-to-Business Integration: communicating between multiple businesses.

Applications

Enterprise Integration Patterns are implemented in various products such as:

Background

The Problem

Example

Solution

Applications

References