Hi Subbu, Processor is basic build block of Camel route, each route has bunch of chained processors to do the EIP work. When you add a processor, camel will add trace, error handler interceptors to wrap the processor for you. These interceptor just add some method call stack, and it doesn't cost much unless you have 100 processors need to add.
From code perspective, my suggestion is keep your business logic in some places and just use processor to inject it into the camel route. Don’t treat the processor as the functional units for your business logic, as it could lead your code too close with the Camel API. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On September 23, 2014 at 4:03:53 PM, Subbu (subramaniam.ven...@gmail.com) wrote: > Thanks Christian for your response. > > But my question was do we have any implication if we write too many > processor to a given request. > > The way we have written our application is we have exposed a webservice and > we have number of processor in a route to process the request.. > > The question is more should we consider processor like functions so that > each Camel Processor does a functionality or should we use Camel Processor > for getting the request from the endpoint(webservice) and have the business > delegate design pattern to processor the request instead of writing too many > camel processor and using > camel processor as a function. > > If we use camel processor as a function what is the implication. Does it add > to the performance? > > Thanks & Warm Regards, > Subbu. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Best-Practice-to-write-Processor-tp5756514p5756884.html > > Sent from the Camel Development mailing list archive at Nabble.com. >
