Home » Enterprise Java » Apache Camel » Apache Camel Headers vs Properties Example

About Shubham Aggarwal

Shubham is a Java Backend and Data Analytics Engineer with more than 3 years of experience in building quality products with Spring Boot, MongoDB, Elasticsearch, MySQL, Docker, AWS, Git, PrestoDB tools and I have a deep knowledge and passion towards analytics, Micro-service based architecture, design patterns, antipatterns and software design thinking.

Apache Camel Headers vs Properties Example

In this article, we provide an Apache Camel Headers vs Properties Example.

1. Introduction

With the development and acceptance of distributed systems in big enterprises that solve big problems by putting small pieces together, there are situations when multiple components need to be integrated to solve a single problem. It is possible these components run beyond frameworks and APIs to get the work done. That being said, building distributed systems sounds fun but is equivalently a complex task. Just how it sounds, a distributed system consists of multiple components that fit together like a jigsaw puzzle to present a bigger picture.

We can think of many real-life examples where these distributed systems are on the play and solve a problem for us without us realizing that we have communicated with so many components. When you searched for this lesson, there were thousands of components that were brought together to bring you here.

In this lesson, we will study two basic concepts of a framework which makes integration between software components much easier, Apache Camel, and what is the difference between its Headers and Properties along with their usages. Let’s see Apache Camel Headers vs Properties.

2. Apache Camel

Apache Camel is an integration framework that acts like a glue that brings multiple pieces of a puzzle together. Camel is an open-source project, available under the liberal Apache 2 license, and it has gained strong community support after its inception in 2007.

The most powerful and at the heart of Camel lies its routing engine builder. Please note that we use the term builder as Camel allows you to define your own routing rules which can be as complex as you need, you can define the sources from where you want your destination system to consume the messages, define custom routes and components for it. The best thing with Camel is that it makes no assumption regarding the type of data the source and the destination systems pass along to communicate and these systems can really be disparate.

camel headers vs properties - Glue between disparate systems
Apache Camel acts as a Glue between disparate systems.

Apache camel offers high-level abstraction components which allow you to construct your own integration systems to manage different protocols and data types. Many Open source projects already make use of these integration components, projects like Apache ActiveMQ, Karaf and ServiceMix. Although Camel supports routing, transformation, orchestration, monitoring, and so forth, we should not term it as an Enterprise Service Bus (ESB) because it lacks a container or a reliable message bus, it can be mixed with one, such as the Apache ServiceMix.

Although this lesson is not about getting started with Apache Camel, we will still offer you a command which you can use to setup a runnable Camel project from a single command:

Create new Camel project
mvn archetype:generate -DgroupId=com.javacodegeeks -DartifactId=javacodegeeks-camel -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -Dversion=1.0.0-SNAPSHOT  

This command will create a runnable project which should help you to get started.

When we check Camel from a birds-eye view, it’s functionality stands against traditional Enterprise Service Bus products. We think of a Camel Route being a “mediation” or an orchestration component that is present on the server-side, but because of the reason that it’s a Java library and it’s easy to embed. It can also stay on the client-side app too and help us integrate it with a point to point services. We can also take our POJOs that process the messages inside the Camel route and easily change them off into one’s own remote consumer processes, e.g. if we needed to scale just one piece independently.

We can use Camel to join routes or processor components through any number of different remote transport/protocols depending on our needs. Do we need an extremely efficient and fast binary protocol or one that is more human-readable and easy to test? What if we want to make a switch? With Camel, this is as easy as modifying a line or two in our route and not changing any business logic at all. Or we could support both – we’re free to run many Routes at once inside of a Camel Context.

3. Glossary – Apache Camel

Just before we move on to the main topic of this lesson, we should go through (very quickly) some of the terms you hear whenever you read about Apache Camel:

  1. Message (org.apache.camel.Message) – This is the core/basic entity in Camel which does the task of carrying the data and routed in Camel. Generally, each message contains a unique String identifier, key-value pair of headers, a generic body object, and a fault flag.
  2. Exchange (org.apache.camel.Exchange) – Camel Exchange represents an abstraction for an exchange of messages which involves a request message and its corresponding reply or an exception message.
  3. Camel Context – The camel context is an entity that acts as a glue to bring all other entities together. It is a container that contains all the components and endpoints for the system. It can be considered very similar to Spring’s Application Context.
  4. Endpoint – Endpoints in Camel are represented via URIs through which a producer/consumer can, well, produces or consumes messages.

4. Characteristics of Headers

In general, camel’s exchange headers are not for custom data exchange (even though it is possible for us to use them in that way) but usually for protocol-related parameters such as HTTP method/uri/sftp-path etc. The headers are related to exchange in general (not to in or out message) and stay until you will not remove them. Almost all (if not all) route processors like split/loop/multicast are preserving them.

To demonstrate a simple example of setting a Header, here is the code snippet we can refer to:

Setting Headers
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("direct:a")
            .setHeader("myHeader", constant("test"))
            .to("direct:b");
    }
};

The above code’s equivalent in XML will look like:

Setting Headers with XML
<camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
        <from uri="direct:a"/>
        <setHeader name="myHeader">
            <constant>test</constant>
        </setHeader>
        <to uri="direct:b"/>
    </route>
</camelContext>

We have to note that .setHeader() creates a header that exist within the current route.

5. Characteristics of Properties

As mentioned in above section, headers should not be used for custom data exchange. For transferring our own data between different route parts (including processors) we should make use of exchange properties.

To demonstrate a simple example of setting a property, here is the code snippet we can refer to:

Setting Headers
RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("direct:a")
            .setProperty("myProperty", constant("test"))
            .to("direct:b");
    }
};

The above code’s equivalent in XML will look like:

Setting Headers with XML
<camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
        <from uri="direct:a"/>
        <setProperty name="myProperty">
            <constant>test</constant>
        </setProperty>
        <to uri="direct:b"/>
    </route>
</camelContext>

6. Core Difference

A simple difference between, as already laid out in previous sections is that properties are more long-lived in route headers.

The headers and properties in Apache Camel framework are sometimes used interchangeably to communicate values between the processes within a single route, but when we want to carry data across different routes that is when the behaviours start to differ. Headers can be lost at endpoints basically as they usually represent some component-specific things.

7. Conclusion

In this lesson, we looked at a very basic difference between a short-lived header and long-lived properties within the great Apache Cael integration framework.

Whenever we study the framework, we will always find a number of concepts that will be new for us so I highly recommend studying few concepts for it, like Discovering the power of Apache Camel, Apache Camel Components Example and how to perform Load balancing with Apache Camel.

All of these examples above are a great way of getting started with Apache Camel framework and getting in-depth and hands-on with it because of its ability to offer som many concepts to reduce as much boilerplate code in an application as possible.

8. Download the source code

This was an example of headers and properties in Apache Camel.

Download
You can download the full source code of this example here: Apache Camel Headers vs Properties Example

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

 

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments