Camel introduces a few novel ideas into the integration space, which is why its authors
decided to create Camel in the first place instead of using an existing framework. We’ll
explore the rich set of Camel features throughout the book, but first let’s look at the main
innovations behind Camel, listed in table 1. We’ll detail these features in the following
sections.
Table 1 Noteworthy features in Camel
Table 1 Noteworthy features in Camel
|
Routing and mediation
|
Payload agnostic
|
Enterprise integration
patterns (EIPs)
|
Domain-specific
language (DSL)
|
|
Modular and pluggable
architecture
|
Automatic type converter
system
|
70+ components
|
Real programming
languages as DSLs
|
|
POJO model
|
Noninvasive
|
Lightweight and
runnable anywhere
|
Java DSL, XML DSL,
Scala DSL, Groovy DSL
|
|
Easy configuration using
URLs
|
No XML needed
|
Maven tooling
|
Visual integration
designer in Eclipse
|
|
Integrated in popular
frameworks
|
Data mapping and
transformation
|
Test Kit provided
|
OSGi ready
|
Table 1 lists 20 features that are highlights of Camel. In the following sections, we’ll take
a closer look at the majority of these features.
Routing and mediation
The core feature of Camel is its stellar routing and mediation engine. When you are more acquainted with Camel, you’ll understand why. The Camel blog sphere has many testimonies from people getting started with Camel and finding it easy to route messages. Later, when we take our first Camel ride, you’ll start to see why.
Payload agnostic
Camel can route any kind of payload. You aren’t restricted to carrying XML payloads. This freedom means that you don’t have to transform your payload into a canonical format to facilitate routing.
Enterprise integration patterns
Although the integration problems are diverse, authors Gregor Hohpe and Bobby Woolf noticed that many problems and their solutions are quite similar. They catalogued them in their book Enterprise Integration Patterns, a must-read for every integration professional. If
Routing and mediation
The core feature of Camel is its stellar routing and mediation engine. When you are more acquainted with Camel, you’ll understand why. The Camel blog sphere has many testimonies from people getting started with Camel and finding it easy to route messages. Later, when we take our first Camel ride, you’ll start to see why.
Payload agnostic
Camel can route any kind of payload. You aren’t restricted to carrying XML payloads. This freedom means that you don’t have to transform your payload into a canonical format to facilitate routing.
Enterprise integration patterns
Although the integration problems are diverse, authors Gregor Hohpe and Bobby Woolf noticed that many problems and their solutions are quite similar. They catalogued them in their book Enterprise Integration Patterns, a must-read for every integration professional. If
you haven’t read it, we encourage you to do so. At the least, it will help you understand the
Camel concepts faster and easier.
The enterprise integration patterns, or EIPs, are helpful not only because they provide a proven recipe for a given problem, but also because they help define and communicate the problem itself. Patterns have known semantics. The difference between using a pattern language and describing the problem at hand is similar to using spoken language rather than sign language. If you’ve ever visited a foreign country, you’ve probably experienced the difference.
Camel is heavily based on the EIPs. Although EIPs describe integration problems and solutions as well as provide a common vocabulary, the vocabulary isn’t formalized. Camel tries to close this gap and provides a language to describe the integration solution. There’s almost a one-to-one relation between the patterns described in Enterprise Integration Patterns and the Camel DSL.
The next topic that sets Camel apart from the pack is the use of domain-specific language.
Domain-specific language
Domain-specific language (DSL) is a major contribution of Camel to the integration space. As of now, a few other integration frameworks feature a DSL (note that some frameworks do allow you to use XML to describe routing rules), but unlike Camel their DSL is based on a custom language. Camel is unique because it offers multiple DSLs in regular programming languages such as Java, Scala, Groovy, and an XML variation.
The purpose of the DSL is to allow the developer to focus on the integration problem rather than the tool, the programming language. Although written mostly in Java, Camel does support and allows you to mix multiple programming languages, such as Java, XML, Groovy, Scala, Ruby, and Python. Each of these languages has its own strengths, and you may want to use them for different tasks. With as few constraints as possible, you have the freedom to build a solution your way.
Here are some examples of the DSL using different languages: Java DSL
from("file://acme/inbox").to("jms:queue:order");
XML DSL
The enterprise integration patterns, or EIPs, are helpful not only because they provide a proven recipe for a given problem, but also because they help define and communicate the problem itself. Patterns have known semantics. The difference between using a pattern language and describing the problem at hand is similar to using spoken language rather than sign language. If you’ve ever visited a foreign country, you’ve probably experienced the difference.
Camel is heavily based on the EIPs. Although EIPs describe integration problems and solutions as well as provide a common vocabulary, the vocabulary isn’t formalized. Camel tries to close this gap and provides a language to describe the integration solution. There’s almost a one-to-one relation between the patterns described in Enterprise Integration Patterns and the Camel DSL.
The next topic that sets Camel apart from the pack is the use of domain-specific language.
Domain-specific language
Domain-specific language (DSL) is a major contribution of Camel to the integration space. As of now, a few other integration frameworks feature a DSL (note that some frameworks do allow you to use XML to describe routing rules), but unlike Camel their DSL is based on a custom language. Camel is unique because it offers multiple DSLs in regular programming languages such as Java, Scala, Groovy, and an XML variation.
The purpose of the DSL is to allow the developer to focus on the integration problem rather than the tool, the programming language. Although written mostly in Java, Camel does support and allows you to mix multiple programming languages, such as Java, XML, Groovy, Scala, Ruby, and Python. Each of these languages has its own strengths, and you may want to use them for different tasks. With as few constraints as possible, you have the freedom to build a solution your way.
Here are some examples of the DSL using different languages: Java DSL
from("file://acme/inbox").to("jms:queue:order");
XML DSL
from "file://acme/inbox" -> "jms:queue:order"
These examples are real code that shows how easily we can route files from an inbox folder to a JMS queue.
A great benefit of the Camel DSLs is that there’s programming language underneath, so you can use all the existing tooling support such as code completion and compiler error detection.
We continue by looking at another Camel feature from table 1, which is all the
components you get out of the box. After this, there are nine features left to explore, but
they are all worth your while to understand.
Extensive component library
Camel provides an extensive component library, which ships with more than 70 components. To those you can add third-party components written by Camel end users and provided free of charge for other users.
Modular and pluggable architecture
Camel has a modular architecture, which allows any component to be seamless and easily embedded with Camel, regardless whether the component ships with Camel, is a third-party component, or is your own component. From Camel’s point of view, all components are the same and treated as equal.
Next we focus on another area where Camel innovates, the POJO (Plain Old Java Object) programming model.
POJO model
Extensive component library
Camel provides an extensive component library, which ships with more than 70 components. To those you can add third-party components written by Camel end users and provided free of charge for other users.
Modular and pluggable architecture
Camel has a modular architecture, which allows any component to be seamless and easily embedded with Camel, regardless whether the component ships with Camel, is a third-party component, or is your own component. From Camel’s point of view, all components are the same and treated as equal.
Next we focus on another area where Camel innovates, the POJO (Plain Old Java Object) programming model.
POJO model
Easy configuration
Camel adheres to convention concerning configuration, which minimizes configuration requirements. Camel also uses easy and intuitive URI configuration, which allows you to configure endpoints directly in routes.
For example, we could configure the file consumer to scan recursively in a subfolder and
include only a .txt file, as follows:
from("file://acme/inbox?recursive=true&include=*.txt") .to("jms:queue:order");
The next feature is one of the top favorites from the Camel community. After a while you should start wondering why it wasn’t provided in Java itself.
Automatic type converters
Camel has a built-in type-converter mechanism that ships with more than 150 type converters. The best part is that it works under the covers, so you don’t have to worry about it. You no longer need to configure type converter rules to go from byte arrays to strings, for example. The Camel API provides methods that accept a desired type as an argument, and Camel will provide the data as that type.
For example, to get a payload as a string you can do the following:
String payload = exchange.getIn().getBody(String.class);
The Camel components also leverage this feature; they can accept data in most types and convert the data into a type they’re capable of using. Camel is pluggable as well, so you can easily provide your own type converters.
We’re almost there! There are only four more features from table 1 that we want to explain.
Lightweight and runs anywhere
The Camel core is lightweight, with the camel-core.jar file being only 1 MB. It depends only on commons-logging.jar. Camel doesn’t set any preconditions or requirements for your application or platform. You can think of Camel as an API that’s another .jar file.
Camel isn’t a server or ESB but instead is designed to be embedded with your platform of choice. That allows you to embed Camel in any way you like it, such as a standalone application, web application, Spring application, J2EE application, JBI container, OSGi bundle, Java WebStart, or Google App engine. Camel makes your platform agile and capable of running inside your existing infrastructure.
In some situations your application need to communicate with another system. Because Camel provides a lot of existing transports and protocols and is lightweight and embeddable as well, you can use Camel as a client to simplify integration with that other system. Add the Camel .jars you need, and you can use Camel as an API in your application to integrate with the other system.
You can also use Camel to make your existing applications more open to the world. For instance, you can expose an endpoint over another protocol, opening it up to another set of clients, without the need for a hub in the middle. A common example is exposing legacy applications as web services.
Test Kit provided
Camel provides a Test Kit that makes it easier for you to test your own Camel applications. The same Test Kit is used extensively to test Camel itself, with more than 3500 unit tests. The Test Kit contains test-specific components, which, for example, can help you mock real endpoints. It also contains setup expectations, which Camel can use to determine whether an application satisfied the requirements or failed.
Camel adheres to convention concerning configuration, which minimizes configuration requirements. Camel also uses easy and intuitive URI configuration, which allows you to configure endpoints directly in routes.
For example, we could configure the file consumer to scan recursively in a subfolder and
include only a .txt file, as follows:
from("file://acme/inbox?recursive=true&include=*.txt") .to("jms:queue:order");
The next feature is one of the top favorites from the Camel community. After a while you should start wondering why it wasn’t provided in Java itself.
Automatic type converters
Camel has a built-in type-converter mechanism that ships with more than 150 type converters. The best part is that it works under the covers, so you don’t have to worry about it. You no longer need to configure type converter rules to go from byte arrays to strings, for example. The Camel API provides methods that accept a desired type as an argument, and Camel will provide the data as that type.
For example, to get a payload as a string you can do the following:
String payload = exchange.getIn().getBody(String.class);
The Camel components also leverage this feature; they can accept data in most types and convert the data into a type they’re capable of using. Camel is pluggable as well, so you can easily provide your own type converters.
We’re almost there! There are only four more features from table 1 that we want to explain.
Lightweight and runs anywhere
The Camel core is lightweight, with the camel-core.jar file being only 1 MB. It depends only on commons-logging.jar. Camel doesn’t set any preconditions or requirements for your application or platform. You can think of Camel as an API that’s another .jar file.
Camel isn’t a server or ESB but instead is designed to be embedded with your platform of choice. That allows you to embed Camel in any way you like it, such as a standalone application, web application, Spring application, J2EE application, JBI container, OSGi bundle, Java WebStart, or Google App engine. Camel makes your platform agile and capable of running inside your existing infrastructure.
In some situations your application need to communicate with another system. Because Camel provides a lot of existing transports and protocols and is lightweight and embeddable as well, you can use Camel as a client to simplify integration with that other system. Add the Camel .jars you need, and you can use Camel as an API in your application to integrate with the other system.
You can also use Camel to make your existing applications more open to the world. For instance, you can expose an endpoint over another protocol, opening it up to another set of clients, without the need for a hub in the middle. A common example is exposing legacy applications as web services.
Test Kit provided
Camel provides a Test Kit that makes it easier for you to test your own Camel applications. The same Test Kit is used extensively to test Camel itself, with more than 3500 unit tests. The Test Kit contains test-specific components, which, for example, can help you mock real endpoints. It also contains setup expectations, which Camel can use to determine whether an application satisfied the requirements or failed.
Eclipse users will be glad to know that Camel also provides tooling in this area. The rest
of us can seek comfort in the Maven tooling that Camel provides.
Tooling
You can easily get started with Camel projects from Eclipse because Camel is listed in m2eclipse. Camel also ships with Maven plug-ins to easily run Camel.
Progress provides a commercial state-of-the-art visual integration designer running inside Eclipse, which we look at in chapter 10—yes, screenshots are included.
We’re nearly done; only one more to go.
OSGi ready
All Camel modules are OSGi (formerly known as the Open Services Gateway initiative) bundles and are ready to run in any OSGi container, such as Equinox, Felix, or Spring DM.
We made this last feature a short one because we know you must be dying to get your hands dirty and see the Camel in action. Don’t despair; you’ll soon get dirty and have a great and fun ride on the Camel. For now, you should take comfort in the fact that figure 1 and the DSL snippets we revealed are real Camel code.
At this time we want to ensure that you’re well prepared for Camel; we need to cover some Camel basics and the integration space in general. We’ll turn our attention to the architecture.
Camel’s architecture
We talked about the things that make Camel a great integration framework. Let’s now look
at how Camel is designed to deliver on those items. We’ll be going over only the
CamelContext, components, endpoints, processors, and DSL so that we can quickly get to a
real example in the next section. A lot more is going on under the hood, but we’ll leave that
discussion for the book! Tooling
You can easily get started with Camel projects from Eclipse because Camel is listed in m2eclipse. Camel also ships with Maven plug-ins to easily run Camel.
Progress provides a commercial state-of-the-art visual integration designer running inside Eclipse, which we look at in chapter 10—yes, screenshots are included.
We’re nearly done; only one more to go.
OSGi ready
All Camel modules are OSGi (formerly known as the Open Services Gateway initiative) bundles and are ready to run in any OSGi container, such as Equinox, Felix, or Spring DM.
We made this last feature a short one because we know you must be dying to get your hands dirty and see the Camel in action. Don’t despair; you’ll soon get dirty and have a great and fun ride on the Camel. For now, you should take comfort in the fact that figure 1 and the DSL snippets we revealed are real Camel code.
At this time we want to ensure that you’re well prepared for Camel; we need to cover some Camel basics and the integration space in general. We’ll turn our attention to the architecture.
Camel’s architecture
No comments:
Post a Comment