After a quick introduction about what Apache Camel is, this chapter will introduce the key features provided by Camel. It provides just an overview of these features; the details will come in dedicated chapters.
In an enterprise, you see a lot of different software and systems in the IT ecosystem. In order to consolidate the data and sync the systems, the enterprise would want to implement communication and integration of these systems. This communication or integration is not so easy, as we have to deal with the specifications on each system the protocol and the message's data format are different most of the time, so we have to transform and adapt to each system.
Using point-to-point communication is one option. However, the problem with this approach is that we tighten the integration of a couple of systems. Changing to other systems or protocols requires refactoring of the implementation. Moreover, dealing with multiple systems is not so easy with point-to-point.
So, instead of point-to-point, we use mediation. Mediation reduces complexity and provides a more flexible approach by adding and using a tier between the systems (man in the middle). The purpose is to facilitate the information flow and integration of the systems.
Apache Camel is a mediation framework.
Apache Camel originated in Apache ServiceMix. Apache ServiceMix 3 was powered by the Spring framework and implemented in the JBI specification. The Java Business Integration (JBI) specification proposed a Plug and Play approach for integration problems. JBI was based on WebService concepts and standards. For instance, it directly reuses the Message Exchange Patterns (MEP) concept that comes from WebService Description Language (WSDL).
Camel reuses some of these concepts, for instance, you will see that we have the concept of MEP in Camel.
In the NMR, a message has a standard XML format. As all messages in the NMR have the same format, it's easy to audit messages and the format is predictable.
However, the JBI XML format has an important drawback for performances: it needs to marshall and unmarshall the messages. Some protocols (such as REST or RMI) are not easy to describe in XML.
For instance, REST can work in stream mode. It doesn't make sense to marshall streams in XML.
Camel is payload-agnostic. This means that you can transport any kind of messages with Camel (not necessary XML formatted).
JBI describes a packaging. We distinguish the binding components (responsible for the interaction with the system outside of the NMR and the handling of the messages in the NMR), and the service engines (responsible for transforming the messages inside the NMR).
However, it's not possible to directly deploy the endpoints based on these components. JBI requires a service unit (a ZIP file) per endpoint, and for each package in a service assembly (another ZIP file). JBI also splits the description of the endpoint from its configuration.
It does not result in a very flexible packaging: with definitions and configurations scattered in different files, not easy to maintain. In Camel, the configuration and definition of the endpoints are gathered in a simple URI. It's easier to read.
Moreover, Camel doesn't force any packaging; the same definition can be packaged in a simple XML file, OSGi bundle, and regular JAR file.
In addition to JBI, another foundation of Camel is the book Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.
This book describes design patterns answering classical problems while dealing with enterprise application integration and message oriented middleware.
The book describes the problems and the patterns to solve them. Camel strives to implement the patterns described in the book to make them easy to use and let the developer concentrate on the task at hand.
This is what Camel is: an open source framework that allows you to integrate systems and that comes with a lot of connectors and Enterprise Integration Patterns (EIP) components out of the box. And if that is not enough, one can extend and implement custom components.
We can see:
The connectivity components that allow exposure of endpoints for external systems or communicate with external systems. For instance, the FTP, HTTP, JMX, WebServices, JMS, and a lot more components are connectivity components. Creating an endpoint and the associated configuration for these components is easy, by directly using a URI.
The internal components applying rules to the messages internally to Camel. These kinds of components apply validation or transformation rules to the inflight message. For instance, validation or XSLT are internal components.
Thanks to this, Camel brings a very powerful connectivity and mediation framework.
Moreover, it's pretty easy to create new custom components, allowing you to extend Camel if the default components set doesn't match your requirements.
It's also very easy to implement complex integration logic by creating your own processors and reusing your beans. Camel supports beans frameworks (IoC), such as Spring or Blueprint.
It means that we have to define expressions or predicates in the Enterprise Integration Patterns. An expression returns any kind of value, whereas a predicate returns true or false only.
Camel supports a lot of different languages to declare expressions or predicates. It doesn't force you to use one, it allows you to use the most appropriate one.
Camel is payload-agnostic. This means that it can support any kind of message. Depending on the endpoints, it could be required to convert from one format to another. That's why Camel supports different data formats, in a pluggable way. This means that Camel can marshall or unmarshall a message in a given format. For instance, in addition to the standard JVM serialization, Camel natively supports Avro, JSON, protobuf, JAXB, XmlBeans, XStream, JiBX, SOAP, and so on.
Depending on the endpoints and your need, you can explicitly define the data format during the processing of the message. On the other hand, Camel knows the expected format and type of endpoints. Thanks to this, Camel looks for a type converter, allowing to implicitly transform a message from one format to another.
You can also explicitly define the type converter of your choice at some points during the processing of the message. Camel provides a set of ready-to-use type converters, but, as Camel supports a pluggable model, you can extend it by providing your own type converters. It's a simple POJO to implement.
The URI is human readable and provides the details of the endpoint, which is the endpoint component and the endpoint configuration.
As this URI is part of the complete configuration (which defines what we name a route, as we will see later), it's possible to have a complete overview of the integration logic and connectivity in a row. We will cover this in detail in Chapter 2, Core Concepts.
Camel itself is very light. The Camel core is only around 2 MB, and contains everything required to run Camel. As it's based on a pluggable architecture, all Camel components are provided as external modules, allowing you to install only what you need, without installing superfluous and needlessly heavy modules.
As we saw, Camel is based on simple POJO, which means that the Camel core doesn't depend on other frameworks: it's an atomic framework and is ready to use. All other modules (components, DSL, and so on) are built on top of this Camel core.
Moreover, Camel is not tied to one container for deployment. Camel supports a wide range of containers to run. They are as follows:
A J2EE application server such as WebSphere, WebLogic, JBoss, and so on
A Web container such as Apache Tomcat
An OSGi container such as Apache Karaf
A standalone application using frameworks such as Spring
Camel gives a lot of flexibility, allowing you to embed it into your application or to use an enterprise-ready container.
The application to integrate with has not yet been purchased or not yet ready
The remote system to integrate with has a heavy cost, not acceptable during the development phase
Multiple teams work in parallel, so we may have some kinds of deadlocks between the teams
As a complete integration framework, Camel provides a very easy way to prototype part of the integration logic. Even if you don't have the actual system to integrate, you can simulate this system (mock), as it allows you to implement your integration logic without waiting for dependencies. The mocking support is directly part of the Camel core and doesn't require any additional dependency.
Along the same lines, testing is also crucial in an integration project. In such a kind of project, a lot of errors can happen and most are unforeseen. Moreover, a small change in an integration process might impact a lot of other processes. Camel provides the tools to easily test your design and integration logic, allowing you to integrate this in a continuous integration platform.
Apache Camel uses the Java Management Extension (JMX) standard and provides a lot of insights into the system using MBeans (Management Beans), providing a detailed view of the following current system:
The different integration processes with the associated metrics
The different components and endpoints with the associated metrics
Moreover, these MBeans provide more insights than metrics. They also provide the operations to manage Camel. For instance, the operations allow you to stop an integration process, to suspend an endpoint, and so on. Using a combination of metrics and operations, you can configure a very agile integration solution.
The Apache Camel community is very active. This means that potential issues are identified very quickly and a fix is available soon after. However, it also means that a lot of ideas and contributions are proposed, giving more and more features to Camel.
Another big advantage of an active community is that you will never be alone; a lot of people are active on the mailing lists who are ready to answer your question and provide advice.
Apache Camel is an enterprise integration solution used in many large organizations with enterprise support available through RedHat or Talend.