Well-defined Integration Architecture


This page details a list of accepted Enterprise Integration Patterns (EIP). All integration design patterns exhibit some common characteristics.

Well-defined Integration Architecture

In distributed systems, a well-defined integration architecture has components designed around the Open Systems Interconnect (OSI) conceptual model and the respective set of Internet Protocol Suits/RFCs including proposed specs outlined by the Internet Engineering Task Force (IETF).

A high-fidelity Enterprise Integration Pattern will involve the following loosely-coupled subsystems:

Building Blocks of EIP

Messaging Systems

The messaging system is the platform responsible for sending or receiving messages. In an event-driven architecture, a message sender platform might be a LOB application. The endpoint receiver does not need to be an active and responsive system, it can also be a data store.

Message Construction

Message Systems are responsible for constructing the message that will ultimately be sent down a Message Channel. The message construction process involves creating the message Header and the Body (Payload). Before constructing a message the following layers of the OSI model must clearly be understood; Application layer, Transport layer, Internet Layer and Link Layer. Web traffic typically flows through TCP/IP, however, if you are building a listening service for a high availability system, you’ll want to implement UDP over TCP.

An application creating a message should clearly define the message format. It’s typical for web services to communicate in JSON/XML format, however proprietary applications communicate with well-defined EDI formats for their industry such as AMQP, AS2, EDIFACT, X12, RosettaNet working with a multitude of application layer protocols (see the extensive list here).

Message Endpoint

A message endpoint is an interface between an application and the messaging channel. A message endpoint sits in two distinct categories; the sender endpoint and the receiver endpoint. Think of message endpoints as sub-systems to a core application. In Microsoft Power Platform for instance; the message endpoint is the SOAP/REST endpoint.

Message Channels

Channels are the plumbing for message transfer. Although messages are transported via TCP/IP which operates at the OSI 4 layer, messaging channels operate at the OSI layer 7 (Application Layer). The most common type of channel is point-to-point, where one application communicates with another application directly.

Message Routers

Message routing defines guidelines for routing messages to its target endpoint receiver. Routing can be as simple as sending all messages to a single receiver, or it can be dynamically configured based on several criteria and using several methods. For instance, a single event message is sometimes broadcast to dozens of receiver endpoints in high-availability systems.

In Apache Camel, for instance, the following routing rules define the endpoint systems:

        .when(simple("${header.crm} == 'salesforce'"))
        .when(simple("${header.erp} == 'oracle'"))

Message Transformers

Message transformation defines rules for transforming messages for additional processing or to match the expected document format of the service to which the message will be sent (see Message Construction). A message may require transformation because the structure of the received message is not in the expected standard or because the message must be converted from a non-standard format to XML. For example; a flat-file CSV document may need transforming into a serialised JSON before the message is transported on the Message Channel.

Although Message Transformation typically occurs on the Message Receiver endpoint, Message Transformation can be handled at either senders or the recipient’s endpoint (see Content Enricher).

System Management

Integrated systems need some capability to monitor, log, debug and manage workloads. Apache Fink and Airflow have a robust set of internal tools for system management. Microsoft provides several management tools with their integration services (Logic Apps, Azure Functions, Container app with Azure Application Insights).

Comments (4)


Feb 14, 2022 at 9:36 AM

One item that’s missing is the Bi-Directional Sync. Thanks for sharing this list.


syed hussain

Jul 06, 2022 at 6:37 AM

Thank you for your comment. Integration is usually documented as a one-way stream, of course, it can be reversed so that the Receiver is also responding to a Sender making this bi-directional. If you are speaking of two-way communication (duplex) then this is a different communication protocol altogether, for this I have Azure Pub/Sub and Relays documented, but also posts on both Web Sockets and SignalR, both provide duplex capabilities.



Jun 06, 2022 at 9:32 AM

I know this page is work in progress, but where would you classify something like X12 and EDIFACT?


syed hussain

Jul 06, 2022 at 6:33 AM

I have some commentary on the Application Adapter pattern, although not explicit to EDI, it should provide some guidance.


Leave a comment