[jboss-dev-forums] [JBoss ESB Development] New message: "Camel integration input requested"

[David Ward]

JBoss development,

A new message was posted in the thread "Camel integration input requested":

http://community.jboss.org/message/528084#528084

Author  : David Ward
Profile : http://community.jboss.org/people/dward

Message:
--------------------------------------------------------------
Hi everybody,
 
I've been doing a lot of studying and playing around with Camel lately ( http://camel.apache.org/ ), and I think if we could integrate it well with JBoss ESB, we could win a lot of great functionality all at once.  Camel does not claim to be an ESB, but a routing and mediation engine.  I think it would be great if we could leverage it, especially given all the cool connectors it has out-of-the-box ( http://camel.apache.org/components.html ).
 
FYI: Edgar S. and Tom F. have already done some playing around with Camel integration:
* http://ankiewsky.blogspot.com/2008/10/integrating-apache-camel-with-jboss-esb.html
* http://ankiewsky.blogspot.com/2009/02/combining-apachecamelbsf-to-make-jboss.html
* http://blog.smooks.org/2010/02/22/apache-camel-smooks/
 
What I am requesting in this developer forum thread is for people to brainstorm how they would like to see it integrated as a 1st class JBoss ESB citizen, any thoughts or concerns, etc.  I will go ahead and list some *+possibilities+* here:
* *Deployment*

0.1. Extend the jboss-esb.xml config format to allow for Camel XML DSL to be defined.  This is currently a bit yucky as we actually duplicate a considerable amount of java code whenever we add a new version of jboss-esb.xml config.
0.2. Augment the ESB deployer mechansim to pickup and hot-deploy Camel XML DSL by some sort of naming convention in the .esb archive structure.
0.3. Similar to #1 and/or #2 above, but allow for Java DSL.  Personally I like the Java DSL much better than the XML (Spring) DSL.  I am not suggesting putting it in the jboss-esb.xml itself, but maybe define a class in the XML which extends Camel's RouteBuilder.  That way we can have compile-time safety.
0.4. Don't add anything to jboss-esb.xml but instead do .esb archive class scanning for any class which extends Camel's RouteBuilder, and deploy it.
* *Components*1. Create our own Camel component representing invoking a JBossESB-deployed service via service category + service name.  It would be represented by our own custom URI but use our ServiceInvoker under-the-hood.
2. What else?

* *Message Translation*1. We would need to be able to translate between Camel's concept of Messages (and Exchanges) to/from our concept of Messages, possibly as part of the consumer/producer work.
2. We might need to come up with our own Camel DataFormat for body transformation.

* *Actions/Listeners/Gateways*1. We could technically create a new Action and/or Listener that builds the Camel routes, but I feel we could do a tighter (more "elegant") and feature-rich integration than this.

 
What else?  I know I'm missing a lot here (it's late and I'm tired), but I wanted to get this discussion kicked off.  I would really like to hear your sugestions!
 
Thanks in advance for your help,
David

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/528084#528084