You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Subbu <su...@gmail.com> on 2014/09/15 06:38:58 UTC

Best Practice to write Processor

Hello All,

Currently in my application we are defining a Processor for a particular
functionality to be achieved. 

For example, we have a webservice based service, we are using CXF to expose
a webservice the endpoint.

At the start of the route, the "camel:from" is configured as the webservice
endpoint, then followed a Processor for RequestValidation then followed by
Processors. This service which we are  developing is more of integration
between multiple services, so after the RequestValidation, there is a
Processor to construct the Request to be sent to DownStream System and
invoke of downstream service using cxf client, then there is another
Processor created for handling the response and constructing the response
and return to calling client of our service.

So, if you consider an operation in our service we have some 3 or 4
processor written for a specific route.

Can someone tell me whether this is good approach to write a Processor to
fulfill a given functionality or is it better to consider a Camel Processor
in parlance with Struts Action classes. Where we receive the request and
hand it over to a business delegate, which then taken returns the final
response to be send to the GUI.

Thanks & Warm Regards,
Subbu.



--
View this message in context: http://camel.465427.n5.nabble.com/Best-Practice-to-write-Processor-tp5756514.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Best Practice to write Processor

Posted by Subbu <su...@gmail.com>.

Does anyone have an answer. Please reply it will be very helpful.

Thanks & Regards,
Subbu.



--
View this message in context: http://camel.465427.n5.nabble.com/Best-Practice-to-write-Processor-tp5756514p5756554.html
Sent from the Camel Development mailing list archive at Nabble.com.

AW: Best Practice to write Processor

Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> I have another question, can we design an application service with
> Camel to have a mini state managed workflow. For example, we receive an
> webservice request from consumer which needs to be asynchronously
> processed. The asynchronous processing can involve invocation of
> multiple webservices and provide a final update to the consumer.

I have problems with "asynchronous webservice".
Do you want to split your ws-call in call-ws and get-response (two different
webservices)?

Here I would think something like this
from( call-ws-endoint )
  .multicast()
    .to("jms:processCall")
    .to( synchronous-answer-of-ws-call ) // 'your call was recieved'
;

from("jms:processCall)
   // do you other ws-calls
   .to("jdbc:write-answer-to-database")

from( get-result-ws-call )
   // look into db for returning the result



Jan


> 
> I looked into the AsyncProcessor of Camel and as this AsynProcessor of
> Camel is not using persistence store I am a bit reluctant to use it and
> have some sort of persistent store involved so that in case there is a
> Error then I will be able to process the request from where it failed.
> 
> Do you think Camel is a good framework for this kind of use cases.
> 
> Thanks & Regards,
> Subbu.
> 
> 
> 
> --
> View this message in context: http://camel.465427.n5.nabble.com/Best-
> Practice-to-write-Processor-tp5756514p5757163.html
> Sent from the Camel Development mailing list archive at Nabble.com.


Re: Best Practice to write Processor

Posted by Subbu <su...@gmail.com>.
Thanks Willem for your response.

I have another question, can we design an application service with Camel to
have a mini state managed workflow. For example, we receive an webservice
request from consumer which needs to be asynchronously processed. The
asynchronous processing can involve invocation of multiple webservices and
provide a final update to the consumer. 

I looked into the AsyncProcessor of Camel and as this AsynProcessor of Camel
is not using persistence store I am a bit reluctant to use it and have some
sort of persistent store involved so that in case there is a Error then I
will be able to process the request from where it failed.

Do you think Camel is a good framework for this kind of use cases.

Thanks & Regards,
Subbu.



--
View this message in context: http://camel.465427.n5.nabble.com/Best-Practice-to-write-Processor-tp5756514p5757163.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Best Practice to write Processor

Posted by Willem Jiang <wi...@gmail.com>.
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.venkat@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.
>  


Re: Best Practice to write Processor

Posted by Subbu <su...@gmail.com>.
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.

Re: Best Practice to write Processor

Posted by Christian Müller <ch...@gmail.com>.
If the request is SOAP based and you validate the request against an XML
schema, CXF can already do that. No processor needed for this requirement.
To transform between different types/objects, I recommend to use the Camel
TypeConverter mechanism [1] and implement your own type converters. No
processor needed for this requirement.
Your route could looks like (without error handling):

from("cxf:...")
  .convertBodyTo(MyOtherRequest.class)
  .to("cxf:...")
  .convertBodyTo(MyResponse.class);

[1] http://camel.apache.org/type-converter.html

Best,

Christian
-----------------

Software Integration Specialist

Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member

https://www.linkedin.com/pub/christian-mueller/11/551/642

On Mon, Sep 15, 2014 at 6:38 AM, Subbu <su...@gmail.com> wrote:

> Hello All,
>
> Currently in my application we are defining a Processor for a particular
> functionality to be achieved.
>
> For example, we have a webservice based service, we are using CXF to expose
> a webservice the endpoint.
>
> At the start of the route, the "camel:from" is configured as the webservice
> endpoint, then followed a Processor for RequestValidation then followed by
> Processors. This service which we are  developing is more of integration
> between multiple services, so after the RequestValidation, there is a
> Processor to construct the Request to be sent to DownStream System and
> invoke of downstream service using cxf client, then there is another
> Processor created for handling the response and constructing the response
> and return to calling client of our service.
>
> So, if you consider an operation in our service we have some 3 or 4
> processor written for a specific route.
>
> Can someone tell me whether this is good approach to write a Processor to
> fulfill a given functionality or is it better to consider a Camel Processor
> in parlance with Struts Action classes. Where we receive the request and
> hand it over to a business delegate, which then taken returns the final
> response to be send to the GUI.
>
> Thanks & Warm Regards,
> Subbu.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Best-Practice-to-write-Processor-tp5756514.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>