Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 92 posts at DZone. You can read more from them at their website. View Full User Profile

Why Choose Apache Camel with Apache Tomcat

05.09.2013
| 3768 views |
  • submit to reddit

Apache Camel with Apache Tomcat provides a low-cost and lightweight integration framework. Is Apache Camel with Apache Tomcat a good fit for your project requirements?

Apache Camel

Apache Tomcat is known for it’s ease-of-use and minimal footprint when building servlet and JavaServer Page applications, while Apache Camel is known for supporting Enterprise Integration Patterns, routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL.

Developers and architects find a straightforward learning curve when using Apache Camel’s Java based DSL, yet they find better tools exist when building simple connections or implementing large integration projects. See Kai Wahner’s writeup on lightweight frameworks.  For larger integration projects requiring reliable messaging, scalability, eventing, business process execution, or web agent hosting, selecting an Enterprise Service Bus provides a better fit.  Kai has another good article placing ESB and integration suites in context.  Apache Camel is often integrated with ActiveMQ, ServiceMix, or Fuse to obtain additional capabilities required to deliver medium to complex integration projects.  The WSO2 ESB team is looking to embrace the simplicity of Apache Camel (by incorporating the project similar to embedding Apache CXF), and extend with multi-tenancy, failover, performance, and scalability enhancements.

Similar to RedHat JBoss Fuse, WSO2 ESB delivers service container clustering and reliable failover functions.   In addition to extensive mediation primitives, the products provide service monitoring and management support not available in the basic Apache Camel with Apache Tomcat combination.

To combat server proliferation, WSO2 ESB inherently supports multi-tenancy.  The multi-tenancy goes beyond simple Tomcat virtual domains by using OSGI class loaders and security managers to provide adequate tenant isolation and separate administration console interfaces.  A single WSO2 ESB instance can support multiple business units with appropriate data, logic, and execution isolation.

SpringSource, MuleSoft, and WSO2 have extended Apache Tomcat to provide better server management and ability to install features within the integration platform.    WSO2 ESB can install over 100+ features (e.g. business process execution, complex event execution, business activity monitoring) into the integration platform.

From a performance perspective, Apache Camel with Apache Tomcat depends on the Tomcat transport to provide high performant message transfer.   The WSO2 ESB pass through transport and binary relay transports are optimized to provide the best streaming, non-blocking performance by tightly integrating the transport and mediation layers.

Camel + Tomcat depends on what ever the Tomcat transport support but I believe ESB PT and NHTTP transports are preforming efficiently here but i also don’t have any reference.  If you install Apache Camel on top of Apache Tomcat then you are not going to get the same performance and scalability.   The latest ESB performance benchmarks are posted for reference and replication.

Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)