Book Image

Mastering Apache Camel

By : Bilgin Ismet Ibryam, Jean Baptiste Onofre, Jean-Baptiste Onofré
5 (1)
Book Image

Mastering Apache Camel

5 (1)
By: Bilgin Ismet Ibryam, Jean Baptiste Onofre, Jean-Baptiste Onofré

Overview of this book

Table of Contents (15 chapters)
Mastering Apache Camel
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

What is Apache Camel?


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.

However, JBI suffered mostly from two issues:

  • In JBI, all messages between endpoints are transported in the Normalized Messages Router (NMR).

    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.