1 2 3 Previous Next 33 Replies Latest reply: Feb 3, 2011 1:42 PM by jumanji4u RSS

Camel integration input requested

David Ward Master

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:

 

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
    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.
    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.
    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.
    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

  • 1. Re: Camel integration input requested
    Edgar Silva Newbie

    Hi David,

     

    This is very interesting, and I also vote for this idea. I've been doing some initial working on this at breakingwoods project. What we have done for awhile is basically to listen some routes (URIs) from Apache Camel. I believe some components can be just "Event Producers", but several others can be even the final destinations, for instance, I am figuring out an way to create a kind of "CamelNotifier", that can use the ready Camel infrastructure.

     

    Looking from a developer perspective, downloading or building the actual Apache Camel Suppor for JBoss ESB 4.7 hosted at breakingwoods, anybody can just add the "Apache Camel Gateway/Listener" according the following XML config in jboss-esb.xml service section:

     

    <listener name="ApacheCamel" busidref="ApacheCamel" is-gateway="true">
     <property name="gatewayClass" value="org.jboss.soa.esb.listeners.gateway.camel.ApacheCamelListener" />
     <property name="protocol-uri" value="irc:breakingwoods@irc.freenode.net/#esbtest" />
     <property name="destination-category" value="sample-apachecamelESBService" />
     <property name="destination-name" value="sample-apachecamelESBServiceListener" />
    </listener>
    

     

     

     

     

    The class org.jboss.soa.esb.listeners.gateway.camel.ApacheCamelListener , is the listener based on AbstractThreadedManagedLifecycle, which is responsible to interact with Camel, the other properties are useful for the following purposes:

    • protocol-uri - This is the Apache Camel URI that will receive the Events and the message itself, this message will be forwarded to JBoss ESB Services pipelines.
    • destination-category - Service Category that will receive the message arrived from Camel layer
    • destination-service - The Service that will handle the message arrived from Camel, this service for instance can be a simple Smooks CBR, or anyother able to marshal or unmarshal the message.

     

    As David said, Camel is not an ESB, but I consider it a valuable piece for any solution that aims to promote integration in any kind of architecture.


    Cheers

     

    Edgar

  • 2. Re: Camel integration input requested
    Hans Wolffenbuttel Expert

    Hi Edgar,

     

    The gateway/listener is placed inside a service right? Why not use the internal parameters for the destination instead of configured parameters?

     

    so instead of:

    <listener name="ApacheCamel" busidref="ApacheCamel" is-gateway="true">
    <property name="gatewayClass" value="org.jboss.soa.esb.listeners.gateway.camel.ApacheCamelListener"></property>
    <property name="protocol-uri" value="irc:breakingwoods@irc.freenode.net/#esbtest"></property>
    <property name="destination-category" value="sample-apachecamelESBService"></property>
    <property name="destination-name" value="sample-apachecamelESBServiceListener"></property>
    </listener>

    this would be:

    <listener name="ApacheCamel" busidref="ApacheCamel" is-gateway="true">
    <property name="gatewayClass" value="org.jboss.soa.esb.listeners.gateway.camel.ApacheCamelListener"></property>
    <property name="protocol-uri" value="irc:breakingwoods@irc.freenode.net/#esbtest"></property>
    </listener>

     

    where as the retrieval of the parameters would be changed from:

    String serviceCategory = listenerConfig.getRequiredAttribute(DESTINATION_CATEGORYNAME_TAG);
    String serviceName = listenerConfig.getRequiredAttribute(DESTINATION_SERVICENAME_TAG);
    

     

    to:

     

    String serviceCategory = ListenerUtil.getValue(config, ListenerTagNames.SERVICE_CATEGORY_NAME_TAG);
    if (Util.isNullString(serviceCategory))
    {
     throw new ConfigurationException("No service category defined!") ;
    }
    
    String serviceName = ListenerUtil.getValue(config, ListenerTagNames.SERVICE_NAME_TAG) ;
    
    if (Util.isNullString(serviceName))
    {
      throw new ConfigurationException("No service name defined!") ;
    }
    
    

     

     

     

    Or am I missing something here?

     

    Regards,

     

    Hans

  • 3. Re: Camel integration input requested
    Edgar Silva Newbie
      Yes, you are right, this gateway is inside the services section:

     

    <service category="Custom" name="Listener" description="" invmScope="GLOBAL">
    
    <listeners>
    
    <listener name="ApacheCamel" busidref="ApacheCamel" is-gateway="true">
    
      <property name="gatewayClass" value="org.jboss.soa.esb.listeners.gateway.camel.ApacheCamelListener" />
      <property name="protocol-uri" value="irc:breakingwoods@irc.freenode.net/#esbtest" />
      <!--  property name="protocol-uri" value="file:///home/esilva/esb/camel/inbox?noop=true" /> -->
      <property name="destination-category" value="sample-apachecamelESBService" />
      <property name="destination-name" value="sample-apachecamelESBServiceListener" />
    
      </listener></listeners>
    
    <actions mep="OneWay">
    
    <action name="dump"
    class="org.jboss.soa.esb.actions.SystemPrintln">
      <property name="printfull" value="false" /></action>
    </actions>
    
    </service>
    

     

     

    Based on your tips, I will improve this gateway source at breakingwoods SVN  now

     

    Thanks

     


  • 4. Re: Camel integration input requested
    Hans Wolffenbuttel Expert

    Hi Edgar,

     

    Can I join the  breakingwoods club, and if so, how?

     

    Regards,

     

    Hans

  • 5. Re: Camel integration input requested
    Edgar Silva Newbie

    Easy, just send me your gmail account and we will add you there!

     

    We would love have your help there!

     

     

     

    Edgar

  • 6. Re: Camel integration input requested
    Edgar Silva Newbie
    You just need to have a gmail/google account

    If you don't have a Gmail account, let me know....

    E
  • 7. Re: Camel integration input requested
    Edgar Silva Newbie

    David and friends,

     

    Seems that this discussion will go far away

     

    http://jazoon.com/Conference/Wednesday/Silva

     

    I was approved to be speaking at Jazoon, thanks Tom Fenelly for reviewing my paper

     

    And please, If you also wanna see some like that in US, please vote for my session during JUDConf here:

     

    https://community.jboss.org/poll.jspa?poll=1042

     

    This session is pretty close what I will gonna show at Jazoon in Zurich.

     

    Thank you

     

    Edgar

  • 8. Re: Camel integration input requested
    Tom Fennelly Master

    Well done Ed.... and vote cast

  • 9. Re: Camel integration input requested
    Hans Wolffenbuttel Expert

    Hi Edgar,

     

    I have made the changes locally (as earlier explaned) to the camel listener but haven't had the time to check if it works ok. As soon as I can find the time I will test the code and after a succesfull test I will check it in, and you can see if you like it.

     

    Regards,

     

    Hans

  • 10. Re: Camel integration input requested
    David Ward Master

    Everyone: Please check out this page:

    http://community.jboss.org/wiki/CamelasaJBossESBRoutingEngine

    and let me know what you think in this forum thread.  Thanks!

  • 11. Re: Camel integration input requested
    Kevin Conner Master

    Just had a quick look at it and my only comment at the moment is that we would be unlikely to add that to 4.x as it stands, certainly not with the camel/camel-context part of the schema.  It would appear that area is really a camel configuration in another guise and this would be better handled (in 4.x) through the normal camel mechanisms.

     

    This does look promising for 5.x though.

     

    Kev

  • 12. Re: Camel integration input requested
    Edgar Silva Newbie

    David,

     

    Awesome job man! Congratulations, I am really happy with this kind of directions that ESB is taking!

     

    If we get Camel, add some annotation stuff, an effective monitoring stuff out of the box (JOPR/JON) on JBoss App Server 6.0, our ESB will be a really cool solution for integrating scenarios (SOA).

     

    Keep going !

     

    Cheers

     

    Edgar

  • 13. Re: Camel integration input requested
    Tom Fennelly Master

    Dave, another twist on this could be a new <camel-listener> in the ESB, which lists a series of "from" addresses:

     

    <listeners>
        <jms-listener ....>
    
        <camel-listener from="file://xxx" />
        <camel-listener from="ftp://aaaaa" />
    </listeners>
    

     

    And then in the listener intialization, you programatically create the camel context and routebuilder, routing from the specified from endpoint, to the service in question....

     

    from(configuredFromEndpoint)
        .to("jbossesb://service?category=<theservicecat>&name=<theservice>");

     

    And then maybe a CamelRouter action for routing to Camel endpoints.

     

    Just a thought.

  • 14. Re: Camel integration input requested
    David Ward Master
    ...not with the camel/camel-context part of the schema.  It would appear that area is really a camel configuration in another guise and this would be better handled (in 4.x) through the normal camel mechanisms...

    I understand what you're saying, and it is "more" configuration.  However, it's not really Camel configuration at all - that is all done in the RoutesBuilder implementation, defined by the class attribute.  The RoutesBuilder approach is very much the normal camel mechanism.  It is their Java DSL, after all.  The extension to jboss-esb.xml is just so we can tell the ESB about it.

     

    However, in retrospect I would agree that maybe this is too much for the 4.x stream, and a better "baby step" for 4.x would be in order, like what Tom Fennelly just suggested.  We can do something "braver" in 5.x. 

1 2 3 Previous Next