Developing a single application with the required features to meet a company’s demands is complex, involving a lot of customized code to ensure the right outcome. For smaller applications, it’s not as cumbersome, but for medium-to-large scale applications, it can be challenging to develop and manage. To help with bigger applications, Enterprise Integration Patterns provide a complete set of standards to integrate existing legacy application systems, company-developed host applications, and third-party vendor applications.
Four Approaches to Application Integration
There are four application integration approaches with each approach addressing some of the integration guidelines better than others. The four integration approaches include File Transfer, Shared Database, Messaging, and Remote Procedure Invocation. Here is a brief explanation of each one:
- File Transfer: One application produces files of shared data for others to consume, and vice versa.
- Shared Database: Applications can store the data they wish to share in a common database.
- Messaging: An application connects to a shared messaging system, exchanges data, and invokes behavior using messages.
- Remote Procedure Invocation: An application exposes its APIs so that they can be invoked remotely by other applications to run its behavior and exchange data.
In using these approaches, there are a few eminent integration frameworks available in the market, for example, Spring Integration, Apache Camel Integration, and Mule ESB. All these frameworks are available in the JVM environment and offer a standardized, domain-specific language to integrate applications. Out of them all, I’d like to discuss the Apache Camel Integration Framework.
What is Apache Camel?
Apache Camel is an integration framework, which implements all Enterprise Integration Patterns for easy integration of different applications using the required patterns. We can use Java, Spring XML, Scala, or Groovy. Almost all technologies are available, for example, HTTP, FTP, JPA, RMI, JMS, JMX, LDAP, JMS, EJB, and many more. Apache Camel is also used with Apache ServiceMix, Apache ActiveMQ, and Apache CXF in service-oriented architecture projects.
We can deploy Apache Camel in a web container like Tomcat, in a JEE Application Server like WebSphere, and as a standalone application as well.
Apache Camel Architecture Diagram
Camel Architecture and its Concepts
Apache Camel Architecture consists of a Camel Context that contains a collection of Component instances. A Component is a factory of Endpoint instances. We can explicitly configure Component instances in Java code, or they can be auto-discovered using URIs.
An Endpoint is either a URI or URL in a web application or a Destination in a JMS system. We can communicate with an endpoint either by sending messages to it or consuming messages from it. We can then create a Producer or Consumer on an Endpoint to exchange messages with it.
Overall, the architecture of Camel is simple. Camel Context represents the Camel runtime system, and it wires different concepts such as routes, components, or endpoints. Additionally, processors handle routing and transformations between parameters, while endpoints integrate disparate systems.
(If you’re interested in learning more about Apache Camel and its Architecture, feel free to visit their website here.)
Why Apache Camel?
We have so many integration frameworks in the software market, open-sourced, and licensed. Out of all, the Apache Camel integration framework is one of the best open-source software, having a rich set of features. Using these features, we can develop loosely coupled applications with ease.
Apache Camel provides the following features.
- Light-weight Open Source
- Easy Configuration
- Routing and Mediation Engine
- Payload-agnostic router
- A domain-specific language (DSL) and POJO Model
- Enterprise integration patterns (EIPs)
Following is the example for Java DSL:
from(“direct:sampleInput”).log(“Received Message is ${body} and Headers are
${headers}”).to(“mock:output”);
When to Use Apache Camel
Apache Camel is used to integrate various applications with different technologies and protocols. No matter the technology, protocol, or domain-specific language we use either, it will serve the same purpose. Here, one application consumes the other application’s developed services and vice versa. There is a producer, there is a consumer, there are endpoints, there are EIPs, there are custom processors (or beans), and there are parameters for credentials.
Apart from the above features that Apache Camel provides are support for error-handling and automatic testing. Again, we always use the same concepts, no matter which technology or protocol we use.
(Commercial support for Apache Camel Integration Framework is available by Fuse Source and can be found here.)
When Not to Use Apache Camel
Even though Fuse Source offers commercial support for Apache camel, we don’t recommend using Apache Camel for substantial integration projects. An ESB (like Mulesoft, TIBCO, etc.) is the right choice for those types of projects. Although it offers many features such as BPM and BAM, you’ll still want to use something other than Apache Camel.
If there is a situation to integrate just two or three technologies like reading a file or sending a JMS message, it is probably much easier and faster to use some existing libraries such as Apache Commons IO or Spring JMS Template.
Conclusion
Apache Camel is an excellent framework for integrating applications with different technologies and protocols. The best part — besides exceptional support for various technologies — is that we can always use the same concepts. It also has excellent error handling and automatic testing that make it optimal for specific integration projects.
As the number of applications and technologies increases, Apache Camel is a good option for integrating them. We hope to see Apache Camel continue to develop and expand its reach as an exceptional integration framework in the JVM/Java environment.