EIP Pattern in Apache Camel (Part- 1)

Table of contents

Reading Time: 5 minutes

If you are reading this blog I assume you are already familiar with the Apache Camel. If not, firstly, visit “Overview of Apache Camel”.
Here, In this blog, we are going to discuss the EIP pattern (Enterprise Integration Patterns) in Apache camel.

What is EIP?

EIP is a catalog of design patterns for developing systems to integrate new and existing software in a business environment. Moreover, EIP provides 65 design patterns and includes an icon-based pattern language called GregorGrams.
Most of the Enterprise Integration Patterns from the excellent book by Gregor Hohpe and Bobby Woolf are supported by Apache Camel.

Messaging Patterns

All EIPs are categorized under 7 categories:

Messaging Systems – reviews the six root messaging patterns, giving an overview of the entire pattern language.
Messaging Channels– Applications communicate via channels. Channels outline the logical pathways a message will follow. Overall, It shows how to determine what channels your applications need.
Message Construction– Once you got message channels, you need messages to transport on them. Moreover, It explains the ways that the messages are often used and how to take advantage of their special properties.
Message Routing– As a messaging topography becomes very complex, usually senders know very less about the recipient of their messages. Rather, they send the messages to adjacent applications that send them to others until the messages finally find their path to their final destination.Moreover, It teaches you the roles and responsibilities of the routing applications.
Message Transformation– Independently developed applications don’t agree on formats of messages, the form and meaning of supposedly unique identifiers, and even on the used character encoding. Therefore, intermediate components needed to convert messages from the form that one application produced for consumption by other applications.In addition, It shows how to implement or design these transformer applications.
Messaging Endpoints– In a messaging solution, many applications aren’t design to take part. As a result, they explicitly linked to the messaging system. Further, This defines a messaging layer in the applications, which is responsible for sending and receiving the messages, making your application an endpoint for messages.
System Management– Once you had a messaging system in place to integrate your applications, how do you make sure that it’s running correctly and doing what you want? Overall, This explores how to test and monitor a running messaging system.

Let’s understand each category one by one.

Messaging System:

Here, we will understand the fundamental building blocks of a messaging system.

Message:

In a messaging system, the smallest unit for transmitting data is a message. The message might contain multiple parts.

Types of the message:

In Apache Camel, org.apache.camel.Message interfaces have the following message types:

In message — A message sent from a consumer to a producer endpoint.
Out message — A message sent back from the producer endpoint to a consumer endpoint. In addition, It is typically a response to an In message).

Message structure:

In Apache Camel, the default structure for all message types:

Headers — usually contain metadata extracted from the message.
Body — generally, it is the original form of the entire message.
Attachments — are Message attachments, used for integration with certain messaging systems, such as JBI.

Example: from(SourceURL).setHeader("username", "John.Doe").to(TargetURL);

Message Channel

A message channel is a logical channel (not a physical channel) in a messaging system. That is, sending messages to different message channels provides a unique way of sorting messages into different message types.
Examples of Message Channels are Message Queues and Message Topics.

Message-oriented components

There are 26 Core Components and 314 Non-Core Components. The following are the message-oriented components in Apache Camel:

In ActiveMQ, JMS, and AMQP, message channels are represented by queues or topics.

Examples: The endpoint URI for a specific queue (QueueName), or topic (TopicName) has the following format:

ActiveMQ

activemq:QueueName

activemq:topic:TopicName

JMS

jms:QueueName 

jms:topic:TopicName

AMQP

amqp:QueueName

amqp:topic:TopicName

Message Endpoint

A Message Endpoint is an interface between an application and a messaging system. you can have a sender endpoint, sometimes called a service consumer, which is responsible for sending In messages, and a receiver endpoint, which is responsible for receiving In messages.

Types of endpoint

In Apache Camel, the endpoints are of 2 types:

Consumer endpoint — It appears at the start of a Camel route and reads In messages from an incoming channel (equivalent to a receiver endpoint).
Producer endpoint — Appears at the end of an Apache Camel route and writes In messages to an outgoing channel (equivalent to a sender endpoint). A route can have multiple producer endpoints.

Endpoint URIs

An endpoint is represented by an endpoint URI. It has the following general form:

ComponentPrefix:ComponentSpecificURI

ComponentPrefix identifies a particular Apache Camel component.
ComponentSpecificURI has a syntax defined by the specific component.

Example:

To connect to the JMS queue, Foo.Bar, the endpoint URI is jms:Foo.Bar
To define a route that connects the consumer endpoint, file://local/router/messages/foo, directly to the producer endpoint, jms:Foo.Bar, you can use the following Java DSL fragment:

from("file://local/router/messages/foo").to("jms:Foo.Bar");

Pipes and Filters

The Pipes and Filter pattern describes a way of constructing a route by creating a chain of filters, where the output of one filter is the input of the next filter in the pipeline. Further, The advantage of the pipeline approach is that it enables you to create more complex forms of message processing.

Pipeline for the InOut exchange pattern

The pipeline connects the output of each endpoint to the input of the next adjacent endpoint. The Out message from the last endpoint is sent back to the original caller. Moreover, You can define a route for this pipeline, as follows:

from("jms:RawOrders")
           
.pipeline("cxf:bean:decrypt", "cxf:bean:authenticate", "cxf:bean:dedup", 

"jms:CleanOrders");

In the Java DSL, you can define a pipeline route using either of the two syntaxes:

Using the pipeline() processor command —

from(SourceURI).pipeline(FilterA, FilterB, TargetURI);

Using the to() command —

from(SourceURI).to(FilterA, FilterB, TargetURI);
                 
                      or

from(SourceURI)

.to(FilterA)

.to(FilterB)

.to(TargetURI);

Generally, the to() command syntax is avoided as to() can be modified by the preceding command in the route. For Example, when the multicast() command precedes the to() command, instead of binding it with a pipeline pattern, it binds the listed endpoints into a multicast pattern.

Message Router

A message router is a type of filter that consumes messages from a single consumer endpoint and redirects them to the specific endpoint, based on a particular decision criterion. Generally, It does not modify the message content, only redirects the messages.

A message router can be easily implemented using the choice() processor, where each of the alternative target endpoints can be selected using a when() subclause.

The Java DSL example shows how to route messages to three alternative destinations (either seda:a, seda:b, or seda:c) depending on the contents of the foo header:

from("seda:a").choice()

.when(header("foo").isEqualTo("bar")).to("seda:b")

.when(header("foo").isEqualTo("cheese")).to("seda:c")

.otherwise().to("seda:d");

Firstly, Each of them defines a predicate expression(AND/OR) to check a condition. If it is true, the destination target declared using the to() method call will be executed. If none of the conditions in the when() method calls are true, the destination after the otherwise() method will be executed.