Apache Camel is an open source integration Java framework that provides a routing and mediation engine API based on its configuration and number of components, which allows a developer to quickly connect various systems consuming or producing data. Apache Camel helps to develop very complex applications by providing re-usable solutions or patterns for solving problems of application integration using message-oriented middleware. These patterns are also called Enterprise Integration Patterns and we briefly describe what they are later in the book.
First, Apache Camel is open source; this means that anyone can try it and see if it meets their needs. For the project manager, this means that there are probably a number of people who know how to work with this framework, so finding a solution or a developer should be easy. For a developer, it means easy access to the source code and the ability to fix things that don't work or get things fixed by someone else who finds the bug first and submits a patch.
Second, Apache Camel, at its core, is comparatively smaller in size than its counterpart and, hence, can be easily explored by going through the source code. For instance, one can easily browse through the existing components just to figure out how to make one's own component.
Third, Apache Camel has a very modular structure. Its core is small, but it comes with a lot of components that range from those working with e-mails to the ones that work as gates to the queues on AS/400 systems. Modularity also allows you to make your own components and weave them effortlessly into the existing infrastructure.
Enterprise Integration Patterns or EIP are reusable solutions for the organization of communication between applications. At the end of the book, we will provide information about the book that goes by the same title, authored by Gregor Hohpe and Bobby Woolf as well as the website and a community around it.
In short, EIP helps us express the complex interactions between parts of the complex system as a network of subsystems or nodes that communicate by producing and consuming messages. Messages are pieces of data with some meta-information. There's no requirement that a message should be in a particular format, such as XML, or conform to a certain schema, such as SOAP. In this book, we will create an application that will orchestrate communications between systems by routing and transforming these messages.
Apache Camel, at its core, is the routing and mediation or transformation engine as well as an API for its configuration. Thus, Apache Camel does only a few things—routing messages, creating/transforming messages, and monitoring—but does them very well.
Routing is an instruction or a list of instructions describing what to do with the message. EIP provides an exhaustive list of all possible routing schemes, including the following to name a few:
Filtering: Describes how to get rid of the messages that are not necessary
Re-sequencing: Describes how to change the order of the messages based on, for example, the last modified timestamp
Splitter: Describes how to split the message, which consists of different elements
Aggregator: Describes how to combine several messages into one
There are many others and we will look at most of them later in the book. Apache Camel implements all of them. Further, routing is the primary objective of Apache Camel. The routing strategies can be easily defined using any of the following domain-specific languages (DSL):
Java DSL: Using Fluent Interface pattern
XML DSL: Routes are written in the XML configuration file
Scala DSL: Using Scala programming language
Groovy DSL: Using Groovy programming language
Annotations DSL: Using runtime annotations as in JSR-175
Transformation changes the message passed between the systems based on its content. Examples of the components performing the transformation could be Content Enricher and Content Filter. Content Enricher adds information to the message from an external resource while Content Filter removes information from the message. For example, Content Enricher could add personal information about an employee based on his employee ID, which has been passed in the message, while the Content Filter could do the opposite by stripping the personal information from the message, leaving only the employee ID.
