You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Jared Hodge <Ja...@pervasive.com> on 2011/07/01 17:19:20 UTC

Customizable message layout design?

So I'm trying to create a framework for processing messages though Camel.  I want to have a user customizable/configurable receiver, some internal routing for queue and logging, etc., it run through a custom processor, and then have an output message make a similar trip back to a customizable/configurable sender.  I'm trying to figure out how to do this in Camel.  Specifically:


1.       Some of my connectors will need to be composites of camel concepts, like a timer with a setBody on it.  Is there a good abstraction layer for this already?

2.       I need to internally pass around some sort of reference to a connector.  I assume I should use either an Endpoint or a URI.  Which or should it be something else?

3.       What is the best way to let someone easily create a new connector?  Should I have them create the Component, the Endpoint, just a producer or consumer, or maybe a processor?  I've read enough of the manual to see that Components are basically Endpoint factories, maybe I should provide that and let the users customize the producers and consumers.

4.       What is the best way to let the users configure their routes?  Is there a canned java method to parse Spring-style xml that I can call?  I want to do this on-the-fly, so I don't think using spring/blueprint directly is what I'm after.

I'm new to Camel, hence the somewhat rudimentary questions.



Re: Customizable message layout design?

Posted by boday <be...@initekconsulting.com>.
a few comments...

for #1 - if you need to reuse groups of DSL commands, just define them as
routes (using  http://camel.apache.org/direct.html direct , etc) and you can
call them like methods using a 
http://camel.apache.org/producertemplate.html producer template , etc...

for #2 - not sure what you mean exactly, but I generally define route
endpoints as constants or in properties files to promote reuse

for #3/4 - it depends on what level of abstraction you are going for and
what the user needs/capabilities are.  you might look at the 
http://camel.apache.org/recipient-list.html recipient list  pattern as this
provides an abstraction layer to allow for dynamic/POJO defined routing,
etc.  

good luck...


Jared Hodge wrote:
> 
> So I'm trying to create a framework for processing messages though Camel. 
> I want to have a user customizable/configurable receiver, some internal
> routing for queue and logging, etc., it run through a custom processor,
> and then have an output message make a similar trip back to a
> customizable/configurable sender.  I'm trying to figure out how to do this
> in Camel.  Specifically:
> 
> 
> 1.       Some of my connectors will need to be composites of camel
> concepts, like a timer with a setBody on it.  Is there a good abstraction
> layer for this already?
> 
> 2.       I need to internally pass around some sort of reference to a
> connector.  I assume I should use either an Endpoint or a URI.  Which or
> should it be something else?
> 
> 3.       What is the best way to let someone easily create a new
> connector?  Should I have them create the Component, the Endpoint, just a
> producer or consumer, or maybe a processor?  I've read enough of the
> manual to see that Components are basically Endpoint factories, maybe I
> should provide that and let the users customize the producers and
> consumers.
> 
> 4.       What is the best way to let the users configure their routes?  Is
> there a canned java method to parse Spring-style xml that I can call?  I
> want to do this on-the-fly, so I don't think using spring/blueprint
> directly is what I'm after.
> 
> I'm new to Camel, hence the somewhat rudimentary questions.
> 


-----
Ben O'Day
IT Consultant -http://consulting-notes.com

--
View this message in context: http://camel.465427.n5.nabble.com/Customizable-message-layout-design-tp4542481p4554490.html
Sent from the Camel - Users mailing list archive at Nabble.com.