First of all we should define what are the EIPs and why should we use them. As the name implies, these are proven (by experts) and tested solutions of specific design problems encountered during many years in the development of IT systems. And what is all the more important is that they are technology-agnostic which means it does not matter what programming language or operating system you use.
Patterns are divided into seven sections:
1. Messaging Systems,
2. Messaging Channels,
3. Message Constructions,
4. Message Routing,
5. Message Transformation,
6. Messaging endpoints,
7. System management.
The purpose of this article is to encourage you to use the patterns so I will discuss briefly only one or two such patterns from each of above sections. If you want to explore then further, visit http://www.eaipatterns.com/ or read Gregor Hohpe’s book mentioned in the introduction of this series.
Message Channel (from Messaging Systems)
A message channel is a logical channel which is used to connect the applications. One application writes messages to the channel and the other one (or others) reads that message from the channel. Message queue and message topic are examples of message channels.
Message Translator (from Messaging Systems)
Message translator transforms messages in one format to another. For example one application sends a message in XML format, but the other accepts only JSON messages so one of the parties (or mediator) has to transform XML data to JSON. This is probably the most widely used integration pattern.
Publish-Subscribe Channel (from Messaging Channels)
This type of channel broadcasts an event or notification to all subscribed receivers. This is in contrast with a point-to-point channel . Each subscriber receive the message once and next copy of this message is deleted from channel. The most common implementation of this patter is messaging topic.
Dead Letter Channel (from Messaging Channels)
The Dead Letter Channel describe scenario, what to do if the messaging system determines that it cannot deliver a message to the specified recipient. This may be caused for example by connection problems or other exception like overflowed memory or disc space. Usually, before sending the message to the Dead Letter Channel, multiple attempts to redeliver message are taken.
Correlation Identifier (from Message Construction)
Correlation Identifier gives the possibility to match request and reply message when asynchronous messaging system is used. This is usually accomplished in the following way:
Producer: Generate unique correlation identifier.
Producer: Send message with attached generated correlation identifier.
Consumer: Process messages and send reply with attached correlation identifier given in request message.
Producer: Correlate request and reply message based on correlation identifier.
Content-Based Router (from Message Routing)
Content-Based Router examines message contents and route messages based on data contained in the message.
Content Enricher (from Message Transformation)
Content Enricher as the name suggests enrich message with missing information. Usually external data source like database or web service is used.
Event-Driven Consumer (from Messaging Endpoints)
Event-Driver Consumer enables you to provide a action that is called
automatically by the messaging channel or transport layer. It is
asynchronous type of pattern because receiver does not have a running
thread until a callback thread delivers a message.
Polling Consumer (from Messaging Endpoints)
Polling Consumer is used when we want receiver to poll for a message, process it and next poll for another. What is very important is that this pattern is synchronous because it blocks thread until a message is received. This is in contrast with a event-driven consumer. An example of using this pattern is file polling.
Wire Tap (from System Management)
Wire Tap copy a message and route it to a separate channel, while the original message is forwarded to the destination channel. Usually Wire Tap is used to inspect message or for analysis purposes.
Saturday, April 28, 2012
Saturday, April 14, 2012
Enterprise Integration using patterns
In my first series of articles I will try to smoothly introduce you to the world of Enterprise Integration using patterns introduced by Gregor Hophe in his excellent book “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions“. In order not to implement all the patterns from the begging, I will use Apache Camel integration framework, which will also serve the purpose of being the tutorial in how to use Camel.
Each section of this series will address a different issue:
1.Enterprise Integration Patterns (EIP). This article will describe what are EIPs, the reason of they use and also we will examine a few patterns.
2.Mediation routing using Apache Camel. This part will show the use of EIPs with Apache Camel mediation routes. I will present some simple examples of integration.
3.Apache Camel deployment modes. In this article I will try to run examples in several modes. I will introduce you to the Apache Servicemix – open source ESB based on OSGi.
4.EIP in action. This part will show example of integration of three applications which use different transport protocols, data formats and programming platforms.
5.Monitoring Apache Camel using JMX. Last article will show how Camel can be monitored and managed using Java Management Extensions.
Before going to the first section we should ask ourselves why we do we need integration. For example a company A has two applications: CRM and Point of Sale. If a seller sells a product it has to enter the buyers data so that to be stored into CRM and PoS. Does he have to enter the data in two systems separately? Does the seller need to know how to use the CRM system? Obviously not! All he has to do is to enter the data into PoS and then it will send the data to CRM automatically. But how to communicate two systems if they are written in different programming languages, use different data formats, use different protocols? Integration tries to solve such problems.
Now let’s go to the first section (EIP).
Each section of this series will address a different issue:
1.Enterprise Integration Patterns (EIP). This article will describe what are EIPs, the reason of they use and also we will examine a few patterns.
2.Mediation routing using Apache Camel. This part will show the use of EIPs with Apache Camel mediation routes. I will present some simple examples of integration.
3.Apache Camel deployment modes. In this article I will try to run examples in several modes. I will introduce you to the Apache Servicemix – open source ESB based on OSGi.
4.EIP in action. This part will show example of integration of three applications which use different transport protocols, data formats and programming platforms.
5.Monitoring Apache Camel using JMX. Last article will show how Camel can be monitored and managed using Java Management Extensions.
Before going to the first section we should ask ourselves why we do we need integration. For example a company A has two applications: CRM and Point of Sale. If a seller sells a product it has to enter the buyers data so that to be stored into CRM and PoS. Does he have to enter the data in two systems separately? Does the seller need to know how to use the CRM system? Obviously not! All he has to do is to enter the data into PoS and then it will send the data to CRM automatically. But how to communicate two systems if they are written in different programming languages, use different data formats, use different protocols? Integration tries to solve such problems.
Now let’s go to the first section (EIP).
Subscribe to:
Posts (Atom)