Is camel the right choice for me?

[pangea <ya...@gmail.com>]

Helo all -

we have a home grown communication framework (based on other open source
components like apache commons, axis etc) that we have been using so far. It
works great but 

- It has many limitations like no connection pooling, 
- only supports tcp/ip, http(s), soap (Axis 1.4 only), and JDBC (hibernate
2.1.8)
- we doesnt want to maintain it anymore

I am looking into replacing it with open source framework. I like the DSL
based approach of Camel and seems like its lightweight unlike Mule and
others. Appreciate if someone can let me know if camel supports the below
usecases. Thank you in advance

MUST

1) I should be able to configure/set all the protocol level properties (for
e.g. in case of http custom headers, keep-alive, GET or POST etc, for tcp-ip
- so_linger etc) thru configuration and also runtime from code. 

2) Ability to pool the connections

3) Ability to configure multiple URLs for a given endpoint. Our partners
expose multiple URLs each for DEV, TEST, QA, PROD etc. Idea is to configure
all the URLs for these different regions during development and choose which
one to use while deployment.

4) Ability to expose all the protocol aspects so that we can modify if
required

5) Support for REST

6) Support for SOAP (ability to choose Axis or CXF or others)

7) Proxy configuration, NTLM auth for HTTP

8) Re-try strategies

9) Performant

NICE TO HAVE

1) Support for polling

2) Client certs (keystore) support
-- 
View this message in context: http://old.nabble.com/Is-camel-the-right-choice-for-me--tp26704160p26704160.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Is camel the right choice for me?

[Tim McNerney <mu...@gmail.com>]

I'm a very new user of Camel, so take that for what it is worth. I
started off using Mule and became disenchanted by it very quickly
(especially when trying to troubleshoot an issue I had with it). It
felt like overkill for what I needed. I was quite pleased by my
attempts with a few test cases in Camel. It was cleaner, more
lightweight and really felt like it was working with me, rather than
trying to push me into its idioms. I've been very happy with it so
far.

Let me throw in one other *huge* plus for using Camel. I have rarely
worked with a more helpful community than the Camel folks. Claus and
Willem and Charles have been hugely helpful for me and I'm pretty sure
they are not real people, but teams of developers answering questions
24/7/364 (they can have New Year's Day off). I'm feeling very
comfortable with my choice to use Camel.

To your specific issues, I'll let Clauemles answer.

--Tim

On Tue, Dec 8, 2009 at 6:22 PM, pangea <ya...@gmail.com> wrote:
>
> Helo all -
>
> we have a home grown communication framework (based on other open source
> components like apache commons, axis etc) that we have been using so far. It
> works great but
>
> - It has many limitations like no connection pooling,
> - only supports tcp/ip, http(s), soap (Axis 1.4 only), and JDBC (hibernate
> 2.1.8)
> - we doesnt want to maintain it anymore
>
> I am looking into replacing it with open source framework. I like the DSL
> based approach of Camel and seems like its lightweight unlike Mule and
> others. Appreciate if someone can let me know if camel supports the below
> usecases. Thank you in advance
>
> MUST
>
> 1) I should be able to configure/set all the protocol level properties (for
> e.g. in case of http custom headers, keep-alive, GET or POST etc, for tcp-ip
> - so_linger etc) thru configuration and also runtime from code.
>
> 2) Ability to pool the connections
>
> 3) Ability to configure multiple URLs for a given endpoint. Our partners
> expose multiple URLs each for DEV, TEST, QA, PROD etc. Idea is to configure
> all the URLs for these different regions during development and choose which
> one to use while deployment.
>
> 4) Ability to expose all the protocol aspects so that we can modify if
> required
>
> 5) Support for REST
>
> 6) Support for SOAP (ability to choose Axis or CXF or others)
>
> 7) Proxy configuration, NTLM auth for HTTP
>
> 8) Re-try strategies
>
> 9) Performant
>
> NICE TO HAVE
>
> 1) Support for polling
>
> 2) Client certs (keystore) support
> --
> View this message in context: http://old.nabble.com/Is-camel-the-right-choice-for-me--tp26704160p26704160.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: Is camel the right choice for me?

[pangea <ya...@gmail.com>]

thx to both of u for the helpful response...i will start looking into
camel...i am glad the camel team is more responsive unlike mule team...
-- 
View this message in context: http://old.nabble.com/Is-camel-the-right-choice-for-me--tp26704160p26719625.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Is camel the right choice for me?

[Claus Ibsen <cl...@gmail.com>]

Hi

Welcome to the Camel community

On Wed, Dec 9, 2009 at 3:22 AM, pangea <ya...@gmail.com> wrote:
>
> Helo all -
>
> we have a home grown communication framework (based on other open source
> components like apache commons, axis etc) that we have been using so far. It
> works great but
>
> - It has many limitations like no connection pooling,
> - only supports tcp/ip, http(s), soap (Axis 1.4 only), and JDBC (hibernate
> 2.1.8)
> - we doesnt want to maintain it anymore
>

Yeah I have been there too. That was even before Mule existed.



> I am looking into replacing it with open source framework. I like the DSL
> based approach of Camel and seems like its lightweight unlike Mule and
> others. Appreciate if someone can let me know if camel supports the below
> usecases. Thank you in advance
>
> MUST
>
> 1) I should be able to configure/set all the protocol level properties (for
> e.g. in case of http custom headers, keep-alive, GET or POST etc, for tcp-ip
> - so_linger etc) thru configuration and also runtime from code.
>

Camel provides endpoint configuration using URLs which allows you to
configure, lets say 90%+ of your needs.
However for more advanced configurations the endpoints are just java
beans and can be configured / wried the traditional way
using setters / IoC stuff. And we strive to expose all configurations.
Camel often leverages a 3rd part framework underneath and thus the
configuration depends on what this framework offers (e.g. Apache Mina
for TCP stuff)


> 2) Ability to pool the connections
>

Again Camel often leverages the 3rd part framework underneath and its
features. e.g. JMS connections are pooled by AMQ, or your broker of
choice.
The same for JDBC as they are often pooled by spring-jdbc, the jdbc
driver or your container. For example with HTTP often Jetty or CXF
offers some form of pooling that you should leverage.

Camel although have pooling for FTP connections and there is a
ServicePool which allows you to pool yourself. And extend pooling with
Camel if there is an are we are missing.


> 3) Ability to configure multiple URLs for a given endpoint. Our partners
> expose multiple URLs each for DEV, TEST, QA, PROD etc. Idea is to configure
> all the URLs for these different regions during development and choose which
> one to use while deployment.
>

Yeah for example using spring property placeholders. You can use Camel
routes with reference for endpoints
and then have different endpoint impl for DEV, TEST, QA etc. Endpoint
is just object so you can also use IoC or whatever.


> 4) Ability to expose all the protocol aspects so that we can modify if
> required
>

The 3rd party framework is very often expose for you so you can modify
it as you like


> 5) Support for REST
>

CXF-RS, Restlet and camel-web (Jersey) is supporting REST.

camel-web is the web console
http://camel.apache.org/web-console.html

But definitely also an area we will improve over time. REST is just so
much cooler than e.g. SOAP.



> 6) Support for SOAP (ability to choose Axis or CXF or others)
>

CXF is integrated as a first class citizen
http://camel.apache.org/cxf

Albeit CXF is has alot of features and moving parts and can take more
than 5 min to grasp if coming from plain old but goodie Axis 1.4

Axis 1.4 is not integrated specially but its very easy to use anyway
http://camel.apache.org/tutorial-axis-camel.html

I would assume the same principles applies for Axis 2.x. However we
have not yet created a special camel-axis2 component.
But we love contributions if anyone is up for the task
http://camel.apache.org/contributing.html


> 7) Proxy configuration, NTLM auth for HTTP
>

Again the 3rd party framework has to support this, but most of them
do. We recently let the NTML auth be easy to setup and use with
camel-http


> 8) Re-try strategies
>

Yeah a lot of features here.
http://camel.apache.org/error-handling-in-camel.html



> 9) Performant
>

There will always be a little footprint with Camel versus low level
optimized code.
We are looking to improve performance in the 2.x series.
http://camel.apache.org/camel-2x-speed-optimizations.html

But it does run fast, but it can always be faster :)

For example Sabre have Camel and SMX running very very fast
http://fusesource.com/collateral/35




> NICE TO HAVE
>
> 1) Support for polling
>
> 2) Client certs (keystore) support
> --
> View this message in context: http://old.nabble.com/Is-camel-the-right-choice-for-me--tp26704160p26704160.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus