Enterprise Integration Patterns – Overview

Enterprise Integration is a complex field to work on, it involves various systems coming together and working as a single unit. Just like any other fields once you start working on the enterprise integration you will notice that their are patterns emerging out of solutions to common problems.

What is a Pattern?

Patterns are accepted solutions to recurring problems within a given context. Patterns are abstract enough to apply to integration technologies but specific enough to provide hands-on guidance to designers and architects, It also provides a common vocabulary for developers to efficiently describe their solutions.

Patterns are not invented, they appear with the repeated implemented solutions to commonly occurring problems, There is a high possibility that knowingly or unknowingly you may have used a EI patterns in your integration project, You may call it with different name but in its core it will be similar to some EI patterns.

Integration System Solution

Any integration solution typically involves two systems communicating with each other, For example in the below image Application A produces a message that is transmitted through a channel and based on the routing logic gets passed through a translator which changes the form of message or converts it into information understandable by Application B.

All the above components involved in achieving a Integration system solution has associated patterns that have been created to give a starting point to developers and architects to design and implement their own solutions.

The image above shows few of the patterns associated with each integration system solution this list is not exhaustive and there can be more patterns associated with each.

Integration Styles and Types

File Transfer
Shared Database
Remote Procedure Invocation
Messaging
Information portal
Data Replication
Shared Business Function
Service Oriented Architecture
Distributed Business Process
Business-to-Business Integration
Tightly Coupled Interaction vs. Loosely Coupled Interaction

Messaging

Message Channel
Message
Pipes and Filters
Message Router
Message Translator
Message Endpoint

Message Construction

Command Message
Document Message
Event Message
Request-Reply
Return Address
Correlation Identifier
Message Sequence
Message Expiration
Format Indicator

Message Router

Content-Based Router
Message Filter
Dynamic Router
Recipient List
Splitter
Aggregator
Resequencer
Composed Message Processor
Scatter-Gather
Routing Slip
Process Manager
Message Broker

Message Transformation

Envelope Wrapper
Content Enricher
Content Filter
Claim Check
Normalizer
Canonical Data Model

Message Endpoint

Messaging Gateway
Messaging Mapper
Transactional Client
Polling Consumer
Event-Driven Consumer
Competing Consumers
Message Dispatcher
Selective Consumer
Durable Subscriber
Idempotent Receiver
Service Activator

System Management

Control Bus
Detour
Wire Tap
Message History
Message Store
Smart Proxy
Test Message
Channel Purger

Since it is impossible to cover each and every pattern in single blog, I will be writing separate future blogs to cover different patterns. Today I will be talking about Messaging.

What is Messaging?

Messaging is a method of communication between software components or applications. A messaging system is a peer-to-peer facility: A messaging client can send messages to, and receive messages from, any other client. Each client connects to a messaging agent that provides facilities for creating, sending, receiving, and reading messages.

Messaging enables distributed communication that is loosely coupled. A component sends a message to a destination, and the recipient can retrieve the message from the destination. However, the sender and the receiver do not have to be available at the same time in order to communicate.

In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only which message format and which destination to use.

In this respect, messaging differs from tightly coupled technologies, such as Remote Method Invocation (RMI), which require an application to know a remote application’s methods.

Message-oriented middleware

MOM provides software elements that reside in all communicating components of a client/server architecture and typically support asynchronous calls between the client and server applications. MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism.

This was just an overview about Integration Patterns, Please look at link below for more detailed information.

http://www.enterpriseintegrationpatterns.com/ This is one of the best place to get information about patterns.

In future blogs I would try to give more practical implementation of some of above patterns that I have seen in my working experience with Pros and Cons in practical environment.