User:Mwgabriel/EnterpriseIntegrationPatterns

Background

Michael

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.

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.

Applications