Any issues having Camel Processor doing all the Works

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Any issues having Camel Processor doing all the Works

JamesG
Hi,

Instead of doing the routing using DSL, web service calling with CXF component, enriching, intercepting, etc , why not just have a Processor and put all the java codes there? For a Camel beginner, this seems pretty much easier to get the things done (definitely for those with java background), but I am not sure how effective or correct this approach is.

Below is a sample scenario:
1)  Call a web service to retrieve some result.
2)  Based on the result, decide whether to proceed calling another service.

If I would to achieve the above through Processor, it's merely few lines of codes.
But if I'm using DSL to do it, the work is going to be more (cxf endpoint, enrich, when, simple).

Appreciate any advises and comments.


Thanks in advance.
 
Reply | Threaded
Open this post in threaded view
|

AW: Any issues having Camel Processor doing all the Works

Jan Matèrne (jhm)
Of course you could do all in plain Java.
Using Camel introduces a lot of dependencies and you have to think about its
benefits and drawbacks (as by each architectural decision).

What you earn (IMO):
- code is easier to read
- easier asynchronous behaviour
- easier integration with other technologies

And of course, learning new things requires time.
You have to decide if it's worth (for you/your project).


Jan



> -----Ursprüngliche Nachricht-----
> Von: JamesG [mailto:[hidden email]]
> Gesendet: Donnerstag, 11. August 2016 18:52
> An: [hidden email]
> Betreff: Any issues having Camel Processor doing all the Works
>
> Hi,
>
> Instead of doing the routing using DSL, web service calling with CXF
> component, enriching, intercepting, etc , why not just have a Processor
> and put all the java codes there? For a Camel beginner, this seems
> pretty much easier to get the things done (definitely for those with
> java background), but I am not sure how effective or correct this
> approach is.
>
> Below is a sample scenario:
> 1)  Call a web service to retrieve some result.
> 2)  Based on the result, decide whether to proceed calling another
> service.
>
> If I would to achieve the above through Processor, it's merely few
> lines of codes.
> But if I'm using DSL to do it, the work is going to be more (cxf
> endpoint, enrich, when, simple).
>
> Appreciate any advises and comments.
>
>
> Thanks in advance.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Any-
> issues-having-Camel-Processor-doing-all-the-Works-tp5786330.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Any issues having Camel Processor doing all the Works

Vitalii Tymchyshyn
In reply to this post by JamesG
Look at it as data flow vs IoC. It's much easier to split data flow to
parallelize of externalize some part. Especially since Camel is able to do
this in non-blocking way. I am able to process few hundred simultanious
requests in few threads without adaptation of the beans to non-blocking or
concurrent calls, just by using camel.

Best regards, Vitalii Tymchyshyn

Пт, 12 серп. 2016 05:13 користувач JamesG <[hidden email]> пише:

> Hi,
>
> Instead of doing the routing using DSL, web service calling with CXF
> component, enriching, intercepting, etc , why not just have a Processor and
> put all the java codes there? For a Camel beginner, this seems pretty much
> easier to get the things done (definitely for those with java background),
> but I am not sure how effective or correct this approach is.
>
> Below is a sample scenario:
> 1)  Call a web service to retrieve some result.
> 2)  Based on the result, decide whether to proceed calling another service.
>
> If I would to achieve the above through Processor, it's merely few lines of
> codes.
> But if I'm using DSL to do it, the work is going to be more (cxf endpoint,
> enrich, when, simple).
>
> Appreciate any advises and comments.
>
>
> Thanks in advance.
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Any-issues-having-Camel-Processor-doing-all-the-Works-tp5786330.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Any issues having Camel Processor doing all the Works

souciance
In reply to this post by JamesG
Hi,

Yes it can be done in the processor but I find the code is easier to read in dsl form. Also, I can easily change the dsl to something else (change endpoint or predicate) much easier than rewrite the code in a processor. There are things you get that you don't in a processor, easier way to communicate with systems, message formats, protocols and easier to handle errors and completion and do simple processing using other languages like groovy. I only do processors if it is something I want to hide or complicate enough to warrant a processor.

Best
Souciance

On Thu, Aug 11, 2016 at 6:51 PM, JamesG [via Camel] <[hidden email]> wrote:
Hi,

Instead of doing the routing using DSL, web service calling with CXF component, enriching, intercepting, etc , why not just have a Processor and put all the java codes there? For a Camel beginner, this seems pretty much easier to get the things done (definitely for those with java background), but I am not sure how effective or correct this approach is.

Below is a sample scenario:
1)  Call a web service to retrieve some result.
2)  Based on the result, decide whether to proceed calling another service.

If I would to achieve the above through Processor, it's merely few lines of codes.
But if I'm using DSL to do it, the work is going to be more (cxf endpoint, enrich, when, simple).

Appreciate any advises and comments.


Thanks in advance.
 


If you reply to this email, your message will be added to the discussion below:
http://camel.465427.n5.nabble.com/Any-issues-having-Camel-Processor-doing-all-the-Works-tp5786330.html
To start a new topic under Camel - Users, email [hidden email]
To unsubscribe from Camel - Users, click here.
NAML